Эволюция концепции «нулевого доверия»
Концепция «нулевого доверия» стала одной из наиболее обсуждаемых моделей кибербезопасности за последнее десятилетие. Однако многие её реализации остаются поверхностными.
Организации внедряют поставщиков идентификационных данных, решения для многофакторной аутентификации и инструменты защиты конечных точек, но упускают из виду критически важный вопрос:
Где решения о доступе фактически исполняются?
В гибридных и мультиоблачных средах традиционные сетевые периметры больше не существуют. Приложения распределены. API-интерфейсы взаимодействуют между регионами. Рабочие нагрузки перемещаются динамически.
В этих условиях идентификация должна не только подтверждать личность пользователей, но и регулировать потоки трафика.
Проблема мышления, основанного на периметре.
Предполагается наличие устаревших мер безопасности:
- Доверенная внутренняя сеть
- Ненадежная внешняя сеть
- Межсетевые экраны, обеспечивающие соблюдение границ
Однако современные архитектуры опровергают это предположение. Внутренний трафик может быть скомпрометирован. Внутри центра обработки данных происходит горизонтальное перемещение. Связь между API-интерфейсами является распространенным вектором атаки.
Принцип «нулевого доверия» меняется:
Никогда не доверяйте. Всегда проверяйте. Непрерывно контролируйте.
Идентичность — это новый периметр.
В архитектуре «нулевого доверия» идентификатор становится управляющей переменной:
- Пользовательский идентификатор
- Идентификатор службы
- Идентификация устройства
- Идентификатор рабочей нагрузки
Однако обеспечение идентификации должно происходить на соответствующем архитектурном уровне.
Если проверка личности выполняется при входе в систему, но не применяется на уровне управления трафиком, нарушается согласованность политик.
Почему уровень доставки приложений имеет решающее значение
Уровень доставки приложений находится на стыке следующих элементов:
- Доступ пользователя
- API-взаимодействие
- Облачная маршрутизация
- Доступ к бэкэнд-сервисам
Это делает его идеальной точкой принуждения для реализации концепции «нулевого доверия».
На этом уровне организации могут:
- Обеспечить соблюдение протокола mTLS между сервисами.
- Применяйте маршрутизацию на основе политик для каждого идентификатора.
- Анализ трафика уровня 7.
- Логически сегментируйте приложения.
- Предотвратить боковое движение
Как RELIANOID Обеспечивает практическое применение концепции «нулевого доверия»
At RELIANOIDМы рассматриваем концепцию «нулевого доверия» не как функцию продукта, а как архитектурный принцип, реализуемый на уровне доставки приложений.
Управление трафиком с учетом идентификации личности
RELIANOID Применяет политики доступа на основе идентификационных атрибутов, а не только IP-адресов.
mTLS между сервисами
Взаимная TLS-аутентификация гарантирует, что и клиент, и сервер проверяют подлинность друг друга перед установлением связи.
Применение политик уровня 7
Проверка с учетом специфики приложения позволяет принимать детальные решения на основе следующих факторов:
- JWT утверждает
- Заголовки запроса
- Пути API
- Роли пользователей
Гибридная и мультиоблачная согласованность
Политика «нулевого доверия» должна оставаться единообразной во всех средах: локальной, частной и публичной. RELIANOID централизует контроль на уровне доставки.
Концепция «нулевого доверия» требует архитектурного мышления.
Концепция «нулевого доверия» не реализуется путем добавления новых инструментов. Она достигается за счет перепроектирования того, как идентификация взаимодействует с трафиком.
В современных архитектурах плоскость доставки становится плоскостью контроля.
Именно обеспечение идентификации на уровне трафика превращает концепцию «нулевого доверия» из идеи в реальную практическую реализацию. Свяжитесь с нами для получения дополнительной информации.
Похожие статьи
