Модель нулевого доверия (Zero Trust) широко распространена, но часто дает сбои на практике. Организации инвестируют в идентификацию, но забывают о контроле трафика. Проблемы возникают на уровне входа, балансировщиков и межсервисного взаимодействия. — csoonline.com
Концепция нулевого доверия (Zero Trust) стала одной из наиболее распространенных моделей безопасности в корпоративных средах. Организации вкладывают значительные средства в системы идентификации, политики доступа и современные инструменты безопасности. На бумаге эти среды выглядят хорошо защищенными.
Однако во время инцидентов часто проявляется иная реальность.
Я работал с организациями, где инициативы нулевого доверия были полностью реализованы с точки зрения идентификации и политик. Были определены элементы управления доступом. Потоки аутентификации были надежными. Требования соответствия были выполнены. Но когда что-то шло не так, постоянно возникал один и тот же вопрос.
Как этот трафик вообще смог пройти?
Ответ часто бывает неприятным. Стратегия была верной, но принудительное исполнение на уровне трафика было непоследовательным. Именно здесь терпят неудачу большинство архитектур нулевого доверия.
Где нулевое доверие дает сбой на практике
Нулевое доверие строится на простой идее: никогда не доверяй, всегда проверяй. На практике большинство реализаций уделяют большое внимание идентификации. Пользователи проходят аутентификацию. Устройства проверяются. Политики определяют доступ.
Часто упускается из виду, как трафик входит в среду и перемещается по ней до применения этих средств контроля.
Уровень трафика включает пути входящего трафика (ingress), балансировщики нагрузки, API-шлюзы, принудительное применение TLS, проверку запросов и межсервисное взаимодействие. Именно здесь доверие либо устанавливается, либо предполагается.
В нескольких средах, с которыми я работал, эти пробелы возникали не из-за нехватки инструментов. Они были вызваны несогласованной ответственностью между сетевыми командами, командами безопасности и командами разработки приложений.
Одним из наиболее распространенных шаблонов является строгое принудительное применение идентификации в сочетании с разрешающими точками входа. Организации внедряют современные поставщики удостоверений и многофакторную аутентификацию, но при этом допускают устаревшие версии TLS или слабые конфигурации шифров на периметре. Руководство Национального института стандартов и технологий рекомендует базовые уровни безопасных протоколов.
Другая повторяющаяся проблема — фрагментированный входной трафик. Приложения открываются через разные пути, такие как CDN, прямые балансировщики нагрузки, устаревшие конечные точки или недавно развернутые API. Каждый путь ведет себя немного по-разному.
Взаимный TLS (Mutual TLS) также часто реализуется лишь частично. Соединения обрываются и восстанавливаются внутри с более слабыми предположениями.
Трафик между сервисами (East-west traffic) создает еще один пробел. Попав внутрь, трафик часто считается безопасным.
Наконец, существует проблема видимости. Во время реагирования на инциденты команды часто не могут ответить, по какому пути прошел запрос.
Многие из этих проблем совпадают с шаблонами, описанными OWASP.
Почему уровень трафика является реальной точкой принудительного исполнения
Программы безопасности часто преуспевают в определении политик. Они испытывают трудности с их последовательным применением.
Уровень трафика — это то место, где принудительное исполнение становится реальным.
С точки зрения руководства, это не проблема инструментов. Это архитектурная проблема.
Принципы Альянса по безопасности облачных сред (Cloud Security Alliance) подчеркивают размещение средств контроля на входе (ingress).
Что работает в реальных средах
Организации, добившиеся успеха, рассматривают уровень трафика как основную точку принудительного исполнения.
Они стандартизируют пути входа, применяют строгие базовые уровни TLS и устраняют устаревшие исключения.
Они определяют четкие правила для взаимного TLS и обеспечивают постоянную проверку доверия.
Они нормализуют и проверяют запросы до логики приложения.
Они внедряют согласованную телеметрию, чтобы команды безопасности могли отслеживать запросы от начала до конца.
Заключительная мысль
О нулевом доверии часто говорят как о смене мышления. Это правда, но одного мышления недостаточно для защиты систем.
Безопасность — это принудительное исполнение. А принудительное исполнение начинается с того, как обрабатывается трафик.
Именно поэтому большинство архитектур нулевого доверия терпят неудачу на уровне трафика.
Эта статья публикуется в рамках Сети экспертных авторов Foundry.
Хотите присоединиться?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Vishnu Gatla