Управление доверием – фундаментальная задача серверной инфраструктуры. Каждая конкретная сущность в системе должна решить доверять ли другой сущности и в какой степени. Классический подход в виде определения границ периметра и автоматического доверия устройствам внутри него перестал быть безопасным.
Индустрия столкнулась с необходимостью адаптироваться и сделанный вывод был неутешителен: доверие по умолчанию стало слишком дорогой ошибкой и нужно выстраивать архитектуру так, словно любое из устройств или рабочая нагрузка в системе могут быть скомпрометированы. Иными словами - доверие больше нельзя предоставлять по умолчанию только на основании того, что устройство или соединение находится внутри периметра. Это легло в основу архитектурной модели, которую мы знаем как Zero Trust.
Идентичность как новый периметр
«Раз ты внутри – тебе можно доверять» – эта парадигма, создающая зону неявного доверия, в современном мире превратилась в уязвимость. С точки зрения злоумышленника достаточно одного скомпрометированного устройства с доступом внутрь сети, чтобы превратить его в инструмент бокового перемещения и эскалации привилегий.
Защититься от такого можно лишь полностью переосмыслив критерии, дающие основания для доверия. Возведя идею в абсолют, получаем Zero Trust – систему в которой сетевое расположение перестаёт влиять на доверие, а центральное место начинает занимать идентичность, проверяемая при каждом запросе.
Возникает необходимость выстраивания системы непрерывного обнаружения и мониторинга – каждый девайс от ноутбука до «умной лампочки» надо увидеть и изолировать раньше, чем оно сможет расширить поверхность атаки. Парк оборудования обычно растёт быстро, так что необходимо изначально заложить возможность оперативного масштабирования этих систем.
В отношении пользователей работает та же логика - идентичность ставится на первое место, но при этом должен быть учтён ряд параметров, таких как контекст запроса и поведенческие сигналы. Важно понимать не только кто подключается (сотрудник, обслуживающий персонал, представитель подрядчика и т.д.), но и как он прошёл проверку, а также какой уровень доступа ему необходимо присвоить.
В корпоративной среде принято задействовать обычный RBAC - привязку прав к роли. Из плюсов - легкость реализации, доступность инструментов и простоту аудита. С точки зрения архитектуры - страдает гранулярность. Как только реальные потребности перестают совпадать с границами ролей - начинается массовое размножение ролей вида «manager-sales-readonly-eu-prague». В противном случае нужный срез прав попросту не выдать.
Там где этого не хватает, начинают применять ABAC, принимающий решение по атрибутам пользователя, окружения и ресурса, а также PBAC, убирающий логику доступа в централизованно описанные политики. Подобная, более тонкая, гранулярность хорошо ложится на концепцию Zero Trust, но увеличивает сложность управления. В итоге приходится сознательно балансировать между безопасностью и эксплуатационной стоимостью.
Безопасность между сервисами
До текущего момента речь шла в основном о традиционном взаимодействии пользователей и устройств. Однако в облачной инфраструктуре чаще встречается координация разных систем без участия человека вообще. Микросервисы общаются друг с другом напрямую и им никакой посредник не нужен. Фоновые задачи обрабатывают данные, забирая их из очереди, а pod в Kubernetes запрашивает необходимый для работы секрет.
Для Zero Trust каждый подобный вызов является полноценной попыткой доступа, а не внутренним «безопасным» действием. Сервисы настраиваются таким образом, чтобы даже если они находятся внутри одного VPC или Kubernetes-кластера, это не являлось доказательством легитимности. Если в обычной инфраструктуре могла работать логика, что если запрос поступил из приватной подсети, то ему можно доверять, то в облаке такая предпосылка становится опасной.
Внутри приватной сети может находиться всё, что угодно - от забытого тестового сервиса до скомпрометированного контейнера. По факту это спящая угроза, которая может реализоваться в любой момент и которую необходимо заранее взять под контроль. При выстраивании Zero Trust межсервисное взаимодействие можно построить вокруг трёх простых принципов:
- Каждому сервису нужна идентичность. Имени хоста или IP-адреса недостаточно, в современных реалиях это должна быть криптографически подтверждаемая сущность, например, SPIFFE ID.
- Аутентификация при каждом обращении. Проверять нужно не только сам факт сетевого соединения, но и то, действительно ли вызывающий является тем за кого себя выдаёт, а также наличие права выполнять конкретное действие. Ещё можно проверять, соответствует ли запрос ожидаемому сценарию.
- Шифрование трафика даже в приватной сети. В облачной инфраструктуре, где рабочие нагрузки динамичны (создаются, перемещаются, уничтожаются), любой незашифрованный трафик станет слабым местом. Чтобы снизить риск перехвата и спуфинга нужно применять взаимную TLS-аутентификацию.
Ключевая мысль всего вышеперечисленного – каждый сервис в облаке должен вести себя точно так же, как обычный пользователь, доказывая право на конкретные действия и доступ к определённым корпоративным ресурсам.
Описание правил доступа
В современных реализациях Policy-as-Code до сих пор актуальна модель разделения PDP (Policy Decision Point) и PEP (Policy Enforcement Point). Сервис не самостоятельно принимает решение об авторизации, а делегирует его внешнему движку. Чаще всего в его роли выступает OPA (Open Policy Agent) в паре с декларативным языком Rego. Эта связка хорошо прижилась в экосистеме CNCF – от Kubernetes до Envoy.
Альтернативой Rego можно назвать Cedar, открытый язык авторизации, изначально разработанный AWS, а ныне находящийся под крылом CNCF Sandbox. Он заточен под формальную верификацию и позволяет моделировать RBAC, ABAC и даже ReBAC (Relationship-based access control) подходы. Последний – ещё одна из часто используемых парадигм, решение в которой принимается на основе графа связей между ресурсами, группами и субъектами.
Упомянем ещё одну реализацию модели ReBAC - открытую базу данных SpiceDB, разработанную AuthZed. Создатели вдохновлялись глобальной системой авторизации Google Zanzibar, применяемой во многих сервисах этого гиганта индустрии. SpiceDB удобно применять везде где надо ответить на вопрос “может ли пользователь A выполнить действие B с объектом C”.
Все вышеперечисленные инструменты позволяют эффективно распоряжаться политиками безопасности, точно так же, как программным кодом. Если грубо обобщить, то теперь это такой же важный артефакт разработки, как и исходный код приложения. Параллельно не стоит забывать о классических способах администрирования, вроде ведения логов. Имеет смысл записывать каждое решение PDP, ведь в конечном итоге именно это станет жизненно важным для мониторинга и отслеживания инцидентов.
Управление секретами
Не сосчитать сколько слёз пролили DevOps, пытаясь выстроить грамотную систему, способную безопасно хранить учётные данные и обеспечивать их конфиденциальную доставку. Каждый из них миллион раз натыкался на грабли в виде хранения секретов в файле переменных окружения или команд внутри Dockerfile. Для ИБ это самая натуральная катастрофа, которая произойдёт с вероятностью 100%.
Наиболее простым и универсальным вариантом считается помещение секретов в централизованные хранилища, вроде HashiCorp Vault. С одной стороны это делает возможным выдавать динамические секреты с коротким временем жизни. Это сразу лишает смысла их воровать - пока злоумышленник дойдёт до этапа применения, они попросту “протухнут”. Обратной стороной медали становится то, что для доступа к содержимому Vault требуется свой секрет, который нужно где-то хранить и безопасно доставлять.
Существует интересный трюк, позволяющий красиво и радикально избавиться от “secret zero problem”. Если взять за основу SPIFFE ID, то получится любопытный контур в котором нет ни одного встроенного секрета, а всё доказывается через SVID (SPIFFE Verifiable Identity Document). Локальный агент выдаёт рабочей нагрузке криптографически подтверждаемую сущность исключительно по свойствам самого процесса.
Теперь достаточно предъявить этот SVID непосредственно хранилищу секретов. Vault проверит подпись, назначит SPIFFE ID на конкретную политику и выдаст Vault token (также короткоживущий). В этих условиях окно полезного использования украденного токена резко сокращается. Ну а нулевого секрета в такой цепочке попросту нет и это вполне соотносится с парадигмой Zero Trust. Реализуется трюк несколькими способами.
Раньше часто применялась связка из JWT auth и SPIRE OIDC Discovery Provider. Альтернативой могли служить сторонние плагины, вроде vault-auth-spire (ныне в архиве). В современных версиях Vault Enterprise (требуется соответствующая лицензия) теперь присутствует штатный метод spiffe, а также собственный SPIFFE secrets engine, что позволяет самому Vault выпускать SVID. В некоторых сценариях фича даёт возможность обойтись без отдельного SPIRE-контура, но стоит помнить, что такая схема не заменяет полноценную модель аттестации рабочих нагрузок.
На практике, конечно, не всё так идеально. Если у вас Open source Vault, то придётся не только использовать JWT auth + OIDC Provider, но и правильно настроить работу SPIRE Federation API. В пределах одного кластера или облака это отлично работает, но вот если они разные - придётся позаботиться об ingress, TLS и DNS.
Наблюдаемость
Помимо классической связки из метрик, трейсов и логов у вас появляется “четвёртое измерение” - ивенты аутентификации и авторизации. Каждое решение PDP, каждое успешное обращение к секрету или отказ превращаются в сигналы, позволяющие вовремя обнаружить проблему. В cloud-native среде де-факто стандартным инструментарием становится OpenTelemetry.
Перед администратором встаёт нетривиальная задача - нужно связать разнородные данные (decision log, audit vault log, distributed trace и так далее) в единую картину - полное знание о действии. Всё вышеперечисленное требует установки, настройки и обслуживания пачки разных стеков (Prometheus + Grafana, ELK/OpenSearch, Tempo/Jaeger, SIEM и так далее).
Здесь полезным советом может быть обратить внимание на то, какие managed-сервисы есть у облачного провайдера. Велика вероятность, что почти всё вышеперечисленное можно закрыть именно его силами. Пренебрегать чем-либо тут точно не стоит – Zero Trust это не про какой-либо постоянный уровень доверия, это про его динамический пересмотр в зависимости от входных сигналов поведенческой аналитики. Новая геолокация, нетипичное количество запросов, эскалация привилегий – всё это может служить триггером для реагирования.
Прокси-решения вместо VPN
Довольно любопытно, что привычная концепция виртуальных приватных сетей, где после подключения пользователь получает широкий доступ к сетевому сегменту, плохо сочетается с Zero Trust. Это именно та самая “доверенная зона” от которой мы пытаемся дистанцироваться.
Вместо этого лучше применить стратегию ZTNA (Zero Trust Network Access). Вместо выдачи доступа к сегменту сети, лучше давать его к конкретному ресурсу, основываясь на результатах проверки идентичности и контекста при каждом обращении. Чтобы организовать это с программной точки зрения, можно воспользоваться приложениями, реализующими концепцию проксирования запросов. Благо, сейчас на рынке есть как коммерческие решения, так и с открытым исходным кодом.
Из первых стоит выделить Cloudflare Access - сервис, основанный на edge-сети Cloudflare. Это не просто отдельный прокси, а целая платформа, которая объединяет в себе реализацию ZTNA, защищённого Web-шлюза, CASB (Cloud Access Security Broker), DLP (Data Loss Prevention) и опционально RBI (Remote Browser Isolation). Хорошо подходит тем, кто уже сидит на Cloudflare и кому нужно быстро избавиться от VPN ничего не сломав. Из минусов - vendor lock-in. Примерно тоже самое можно построить на Zscaler и Netskope - это тоже полноценные платформы, где ZTNA лишь один из элементов.
Для self-hosted стоит отметить следующий стек:
- Teleport - обеспечивает SSH/RDP/DB/K8s через прокси с записью сессий и сертификатами с коротким TTL.
- HashiCorp Boundary - типичный представитель IAP (Identity-Aware Proxy), который вначале аутентифицирует пользователя и только потом выдаёт доступ к целевой системе.
- Pomerium - ещё один IAP, но больше направленный на доступ к веб-приложениям и системам по протоколам HTTP/HTTPS. В этом плане он чуть ближе к reverse-proxy.
Заключение
Zero Trust нельзя купить в коробке - это архитектурный подход, а не продукт, и его внедрение почти всегда идёт поэтапно и болезненно. DevOps приходится переучиваться, а разработчикам – переписывать приложения. Построить его практически невозможно поверх legacy-кода без глубокого рефакторинга. В лучшем случае удаётся закрыть что-то одно, например, сетевой слой, в то время как identity и observability остаются за бортом - доказать корректность доступа на уровне приложения будет по-прежнему трудно.
Для новых облачных систем Zero Trust-подход уже следует считать не экзотикой, а базовой архитектурной нормой. А вот при внедрении в существующие сервисы закладывайте достаточно времени на тщательное планирование и поэтапное исполнение: такой переход попросту невозможно завершить за пару спринтов даже с самой продвинутой и лояльной командой.
Используемые источники:
