Введение #
Архитектура «нулевого доверия» требует непрерывной проверки личности и строгого контроля доступа. В гибридных и распределенных средах идеальным местом для обеспечения этого контроля становится уровень доставки приложений.
В этом руководстве объясняется, как внедрить принципы «нулевого доверия» с помощью:
- Взаимный TLS (mTLS)
- Проверка JWT
- Политики маршрутизации на основе идентификаторов
- Сегментация приложений
1. Внедрить взаимную TLS (mTLS) #
mTLS гарантирует взаимную аутентификацию клиента и сервера с использованием сертификатов X.509. Это предотвращает взаимодействие неавторизованных служб.
Пример концептуальной конфигурации mTLS #
server { listen 443 ssl; ssl_certificate /etc/ssl/server.crt; ssl_certificate_key /etc/ssl/server.key; ssl_client_certificate /etc/ssl/ca.crt; ssl_verify_client on; location / { proxy_pass http://backend_pool; } }
Данная конфигурация:
- Требуется проверка клиентского сертификата.
- Отклоняет неаутентифицированные сервисы
- Обеспечивает проверку подлинности между сервисами.
2. Проверка JWT-токенов на уровне доставки. #
Идентификационные данные и роли пользователей часто кодируются в токенах JWT. Проверка токенов на ADC обеспечивает подтверждение подлинности до того, как запросы достигнут бэкэнд-сервисов.
Концептуальная логика проверки JWT #
if (jwt_verify(token, public_key) == false) { return 401 Unauthorized; } if (jwt_claim["role"] != "admin") { return 403 Forbidden; }
Бенефиты:
- Предотвращает несанкционированный доступ на ранней стадии
- Снижает нагрузку на серверную часть при обработке данных.
- Обеспечивает последовательное применение политики.
3. Политики маршрутизации на основе идентификаторов #
Концепция «нулевого доверия» выходит за рамки аутентификации. Она включает в себя сегментацию. Маршрутизация трафика может зависеть от атрибутов идентификации.
Пример: Маршрутизация на основе ролей #
if (request.header["X-User-Role"] == "finance") { route to finance_backend; } else if (request.header["X-User-Role"] == "engineering") { route to engineering_backend; } else { deny access; }
Это предотвращает горизонтальный доступ между отделами или сегментами приложений.
4. Внедрить микросегментацию на уровне 7. #
Микросегментация ограничивает горизонтальное перемещение. Вместо сегментации только на уровне сети используйте сегментацию с учетом приложений.
- Ограничьте обмен данными между API.
- Ограничьте доступ к бэкэнду
- Применяйте политики доступа на основе путей.
Внедрение концепции «нулевого доверия» с помощью RELIANOID #
RELIANOID обеспечивает применение принципа «нулевого доверия» непосредственно на уровне доставки приложений.
Поддержка mTLS #
Полная аутентификация на основе сертификатов для связи между сервисами.
Механизм политик уровня 7 #
Детальная проверка на основе заголовков, токенов, путей URI и атрибутов пользователя.
Высокая доступность для обеспечения идентификации личности #
Внедрение принципа «нулевого доверия» не должно приводить к появлению единых точек отказа. RELIANOID Обеспечивает высокую доступность кластеризации с синхронизацией состояний.
Горячая перезагрузка для обновления политики #
Изменения в политике безопасности можно применять без разрыва активных сессий.
Эксплуатационные преимущества #
- Снижен риск боковых движений
- Последовательное применение политики
- Улучшенная позиция соответствия
- Нижняя поверхность атаки бэкэнда
- Централизованная плоскость управления с учетом идентификации.
Заключение #
Концепция «нулевого доверия» не достигается одними лишь средствами защиты периметра. Она требует применения мер по контролю трафика с учетом идентификации пользователей на уровне доставки приложений.
Сочетая mTLS, проверку JWT и применение политик уровня 7, организации могут создать практичную и масштабируемую архитектуру нулевого доверия.
RELIANOID Преобразует уровень доставки приложений в механизм обеспечения соблюдения принципов нулевого доверия, что делает их операционно жизнеспособными в гибридных и мультиоблачных средах. Попытка RELIANOID.
