Модель Zero Trust продолжает создавать проблему, которую часто упускают из виду: поддержание точности решений о доступе по мере изменения реальных условий, лежащих в их основе.
За последнее десятилетие ИИ, облачная трансформация, мобильный доступ и удаленная работа фундаментально изменили существующие парадигмы безопасности. Организации осознали, что должны перейти от модели безопасности «огороженного сада», в которой все компьютеры внутри брандмауэра или подключающиеся через VPN считаются доверенными, к модели Zero Trust, где каждый запрос на доступ оценивается независимо.
В модели Zero Trust безопасность основывается на точной оценке того, что должно быть разрешено в рамках каждого запроса на доступ. Изначально считалось достаточным, чтобы корпоративные службы оценивали действительность сессионного файла cookie или токена доступа, связанного с каждым веб-запросом или API-запросом.
Однако этот подход оставил несколько пробелов:
- Что, если организации нужно мгновенно отозвать весь доступ, предоставленный человеку или агенту, из-за срочного события (например, увольнения сотрудника или активности скомпрометированного агента)?
- Что произойдет, если факторы, которые учитывались при принятии решения о выдаче токена доступа или cookie, динамически изменятся, пока срок действия токена или cookie еще не истек?
- Что произойдет, если область доступа, представленная токеном или cookie, изменится после того, как токен был выдан?
Чтобы справиться с этим, организации часто рассматривают две стратегии:
- Использовать токены с коротким сроком действия
- Повторно проверять токен при каждом запросе
Ни одна из стратегий не является идеальной. Если токен используется, скажем, тысячу раз в среднем (крайне консервативная оценка для 24-часового токена), то стратегия «повторной проверки при каждом доступе» создает 1000-кратную нагрузку на систему выдачи (обычно поставщик идентификационных данных, или IdP). Этот подход обычно считается технически нежизнеспособным.
С другой стороны, «токен с коротким сроком действия» создает лишь примерно 24-кратную нагрузку (если предположить, что используется токен, который живет час вместо 24 часов), в зависимости от того, насколько короток срок действия токена. Но такой токен серьезно ухудшает пользовательский опыт, даже если все, что нужно сделать пользователю, — это перенаправиться на IdP и обратно, когда срок действия токена истечет.
Тогда как можно реагировать на изменения, влияющие на свойства доступа, пока токен доступа все еще действителен?
Проблема непрерывной авторизации
Давайте посмотрим, как система определяет, является ли токен действительным или нет. Ей необходимо оценить несколько факторов, таких как:
- Является ли учетная запись пользователя или агента, представленная токеном, действительной?
- Осуществляется ли доступ по-прежнему с устройства, с которым не связано никаких инцидентов безопасности?
- Соответствует ли устройство, с которого осуществляется доступ, политикам управления устройствами?
- Изменились ли задачи пользователя или агента настолько, что им больше не требуется тот же объем доступа, который предоставляет токен?
- Ушел ли пользователь в отпуск? Закончил ли он смену? Был ли агент удален?
Если мы не хотим обращаться к IdP при каждом доступе, нам нужно оценивать эту информацию в той службе, к которой обращается пользователь, в момент доступа и в течение миллисекунд, чтобы пользователь не столкнулся с ухудшением качества работы.
Проблема в том, что все эти данные находятся в разных местах. Информация об учетной записи пользователя находится в каталоге у поставщика идентификационных данных или локально. Инциденты безопасности устройства известны системе расширенного обнаружения и реагирования (XDR). Данные о соответствии устройства находятся в MDM. Информация о задачах находится в системе отслеживания задач, такой как ServiceNow или Jira. Информация об отпуске находится в HR-системе. График работы находится в системе планирования, такой как PagerDuty.
Это подводит нас к проблеме непрерывной авторизации:
Проблема непрерывной авторизации
Решение проблемы
Хотя оценка всей необходимой информации в режиме реального времени в момент доступа кажется практически невыполнимой задачей, хорошо зарекомендовавший себя шаблон может сделать это возможным. Полученная архитектура, возможно, более надежна и безопасна, чем раньше. На практике эта оценка происходит в точке принудительного применения политики, которая может быть вынесена за пределы приложения, а не в самом коде приложения.
Принципы решения заключаются в следующем:
- Асинхронная и надежная доставка любых изменений в данных, необходимых для принятия решений о доступе, в систему, которой они требуются.
- Оценка каждого запроса на доступ на основе данных, которые доступны локально.
Сложность внедрения этой архитектуры заключается в том, что каждая система, хранящая такие данные, может принадлежать разным поставщикам, и асинхронное обновление данных каждой стороны у всех остальных сторон, которым они требуются, будет чрезвычайно сложной задачей.
Стандарты приходят на помощь
Здесь в игру вступают открытые стандарты. Фонд OpenID Foundation в течение более 6 лет разрабатывал Shared Signals Framework (SSF). SSF предоставляет надежный асинхронный механизм для доставки дискретных пакетов информации, называемых токенами событий безопасности (Security Event Tokens, SET). SET — это стандарт, разработанный IETF. Надежная доставка здесь важна, потому что и передатчики, и приемники SSF знают, какие события были правильно переданы какому приемнику. SET — это JWT, подписанные передатчиками SSF и проверяемые приемниками SSF. Поскольку сигналы доставляются асинхронно, распространение происходит почти в реальном времени, а не мгновенно.
На основе SSF профиль Continuous Access Evaluation Profile (CAEP) определил события, которые сообщают об изменениях, необходимых для модуляции доступа в режиме реального времени. К ним относятся:
- Сеанс отозван
- Изменение соответствия устройства требованиям
- Изменение учетных данных
- Изменение уровня риска
Существуют и другие профили на основе SSF, такие как Risk Incident Sharing and Coordination (RISC), используемый для передачи событий безопасности учетных записей, и SCIM Events (используемый для передачи изменений учетных записей).
Системы, внедряющие SSF, обмениваются этими событиями, чтобы необходимые данные были доступны любой доверенной стороне, которой они нужны для принятия решений о доступе почти в реальном времени. Это важный компонент внедрения истинной архитектуры Zero Trust.
Внедрение
SSF и CAEP широко внедряются в отрасли. Популярные технологические провайдеры, такие как Apple, CrowdStrike, Google, IBM, Jamf, Okta, SailPoint, Zscaler и другие, реализовали эти стандарты в своих продуктах.
Недавно CrowdStrike и Zscaler продемонстрировали доступ по модели Zero Trust на основе SSF и CAEP, где доступ к облачным сервисам через Zscaler определяется почти в реальном времени событиями CAEP на основе инцидентов на устройствах, обнаруженных CrowdStrike. Читайте запись в блоге (которая также включает видеодемонстрацию) здесь.
Та же основа общих сигналов применяется, когда ИИ-агенты берут на себя привилегированные задачи: их доступ также должен реагировать на меняющиеся условия в режиме реального времени.
Спросите своих поставщиков решений по безопасности и идентификации, SaaS-провайдеров, облачных провайдеров и MSP о поддержке SSF и CAEP, а также о том, как они участвуют в экосистеме сигналов.
