Основная цель концепции Zero Trust заключается в помощи организациям в сокращении поверхностей атаки и ускорении реакции на угрозы, что требует непрерывного и надежного получения сигналов о состоянии пользователей и устройств. Однако согласно данным Accenture, 88% организаций признают наличие значительных трудностей при внедрении этой модели безопасности. Ключевая причина неудач кроется в том, что инструменты безопасности не обмениваются сигналами надежно: принятие решений о доступе в реальном времени нарушается, когда продукты не могут коммуницировать между собой.
Существенный пробел в инфраструктуре возникает из-за того, что многие инструменты управления идентификацией и доступом (IAM) не имеют нативной поддержки Shared Signals Framework (SSF) или протокола непрерывной оценки доступа (CAEP). Конкретным примером является Kolide Device Trust, который на данный момент не поддерживает SSF. Следствием этого становится то, что критические события устройств, такие как несоответствие требованиям безопасности, никогда не достигают таких систем, как Okta, что затрудняет последовательное применение политик. Команды сталкиваются с тремя основными проблемами: отсутствие нативной поддержки SSF в инструментах, необходимость обогащения или корреляции сигналов, а также накладные расходы на управление конечными точками SSF и обработку токенов.
Решение этой проблемы предложил Скотт Бин, старший инженер по IAM и безопасности в MongoDB. Он разработал рабочий процесс для операционализации SSF в различных средах, используя платформу оркестрации Tines в качестве «связующего звена». Методология основывается на том, что SSF построен на HTTPS-запросах, а стандарт OpenID совместим с HTTP Action в Tines. Это позволяет платформе транслировать вебхуки в стандартные сигналы SSF, устраняя разрыв между инструментами мониторинга и провайдерами идентификации.
Техническая механика процесса начинается с триггера, когда устройство становится несоответствующим требованиям в Kolide. Система отправляет сообщение через вебхук, которое принимается в Tines. Платформа обрабатывает сигнал: обогащает и коррелирует его (сопоставляя устройство с пользователем), создает токен события безопасности (SET) и подписывает его для соответствия спецификациям SSF. На финальном этапе Tines доставляет подписанный SET в Okta или другие провайдеры идентификации. При этом Tines размещает необходимые конечные точки метаданных SSF (префиксы путей API), позволяя потребляющим системам извлекать ключи и расшифровывать токены.
Для реализации данного рабочего процесса необходимы конкретные инструменты: Tines для оркестрации и ИИ, Kolide для контроля состояния устройств и Okta (например, домены
Архитектура рабочего процесса состоит из трех ключевых элементов, первым из которых является генерация и хранение ключей подписи SET. Процесс включает создание пары ключей RSA, их конвертацию в формат JWK (JSON Web Key), публикацию открытого ключа для валидации и сохранение набора закрытых ключей JWK в качестве секрета Tines. Второй элемент — это создание API передатчика SSF. Для этого требуются конечная точка.well-known/sse-configuration (описывающая передатчик) и конечная точка JWK (раскрывающая открытый ключ). Триггер вебхука выступает в роли поверхности API SSF, а регистрация в Okta происходит по пути: Security → Device Integrations → Receive shared signals.
Третий элемент — создание, подписание и отправка токенов SET. Система получает проблему от Kolide через вебхук, который валидируется с помощью секрета подписи. Затем извлекаются метаданные, и формируется SET для события Device Compliance Change CAEP. Токен подписывается закрытым ключом с использованием формулы JWT_SIGN и отправляется на конечную точку security-events в Okta.
Пошаговая конфигурация может быть выполнена с использованием Tines Community Edition. После создания учетной записи и импорта готового рабочего процесса из библиотеки, необходимо собрать учетные данные и ресурсы. Важно отметить, что данная настройка действует как провайдер типа
Внедрение данного решения приносит существенные выгоды как для IT-команд, так и для конечных пользователей. IT-специалисты получают возможность непрерывной оценки рисков в реальном времени, более быстрой реакции на угрозы, гибкой оркестрации политик и упрощенной операционализации Zero Trust. Для пользователей это означает автоматическое исправление проблем, оптимизацию производительности и минимизацию вмешательства со стороны IT-отдела. Данный рабочий процесс Скотта Бина является одним из нескольких реальных паттернов, включенных в руководство Tines IAM, охватывающее модернизацию идентификации и унифицированное доверие к устройствам.
Изображение носит иллюстративный характер
Существенный пробел в инфраструктуре возникает из-за того, что многие инструменты управления идентификацией и доступом (IAM) не имеют нативной поддержки Shared Signals Framework (SSF) или протокола непрерывной оценки доступа (CAEP). Конкретным примером является Kolide Device Trust, который на данный момент не поддерживает SSF. Следствием этого становится то, что критические события устройств, такие как несоответствие требованиям безопасности, никогда не достигают таких систем, как Okta, что затрудняет последовательное применение политик. Команды сталкиваются с тремя основными проблемами: отсутствие нативной поддержки SSF в инструментах, необходимость обогащения или корреляции сигналов, а также накладные расходы на управление конечными точками SSF и обработку токенов.
Решение этой проблемы предложил Скотт Бин, старший инженер по IAM и безопасности в MongoDB. Он разработал рабочий процесс для операционализации SSF в различных средах, используя платформу оркестрации Tines в качестве «связующего звена». Методология основывается на том, что SSF построен на HTTPS-запросах, а стандарт OpenID совместим с HTTP Action в Tines. Это позволяет платформе транслировать вебхуки в стандартные сигналы SSF, устраняя разрыв между инструментами мониторинга и провайдерами идентификации.
Техническая механика процесса начинается с триггера, когда устройство становится несоответствующим требованиям в Kolide. Система отправляет сообщение через вебхук, которое принимается в Tines. Платформа обрабатывает сигнал: обогащает и коррелирует его (сопоставляя устройство с пользователем), создает токен события безопасности (SET) и подписывает его для соответствия спецификациям SSF. На финальном этапе Tines доставляет подписанный SET в Okta или другие провайдеры идентификации. При этом Tines размещает необходимые конечные точки метаданных SSF (префиксы путей API), позволяя потребляющим системам извлекать ключи и расшифровывать токены.
Для реализации данного рабочего процесса необходимы конкретные инструменты: Tines для оркестрации и ИИ, Kolide для контроля состояния устройств и Okta (например, домены
example.okta.com или example.oktapreview.com) для приема событий CAEP. Требуются определенные учетные данные: API-ключ Tines с областью действия Team и ролью Editor, API-ключ Kolide с доступом только для чтения (Read Only) и секрет подписи вебхука Kolide (Webhook Signing Secret). Архитектура рабочего процесса состоит из трех ключевых элементов, первым из которых является генерация и хранение ключей подписи SET. Процесс включает создание пары ключей RSA, их конвертацию в формат JWK (JSON Web Key), публикацию открытого ключа для валидации и сохранение набора закрытых ключей JWK в качестве секрета Tines. Второй элемент — это создание API передатчика SSF. Для этого требуются конечная точка.well-known/sse-configuration (описывающая передатчик) и конечная точка JWK (раскрывающая открытый ключ). Триггер вебхука выступает в роли поверхности API SSF, а регистрация в Okta происходит по пути: Security → Device Integrations → Receive shared signals.
Третий элемент — создание, подписание и отправка токенов SET. Система получает проблему от Kolide через вебхук, который валидируется с помощью секрета подписи. Затем извлекаются метаданные, и формируется SET для события Device Compliance Change CAEP. Токен подписывается закрытым ключом с использованием формулы JWT_SIGN и отправляется на конечную точку security-events в Okta.
Пошаговая конфигурация может быть выполнена с использованием Tines Community Edition. После создания учетной записи и импорта готового рабочего процесса из библиотеки, необходимо собрать учетные данные и ресурсы. Важно отметить, что данная настройка действует как провайдер типа
push (а не poll), что исключает необходимость хранения состояния. Далее следует генерация набора ключей JWK через две трансформации событий и публикация API передатчика SSF с двумя ветвями: триггер для well-known (возвращает конфигурацию SSF) и триггер для JWKs (возвращает открытые ключи). Финальная интеграция позволяет Okta зарегистрировать передатчик. Внедрение данного решения приносит существенные выгоды как для IT-команд, так и для конечных пользователей. IT-специалисты получают возможность непрерывной оценки рисков в реальном времени, более быстрой реакции на угрозы, гибкой оркестрации политик и упрощенной операционализации Zero Trust. Для пользователей это означает автоматическое исправление проблем, оптимизацию производительности и минимизацию вмешательства со стороны IT-отдела. Данный рабочий процесс Скотта Бина является одним из нескольких реальных паттернов, включенных в руководство Tines IAM, охватывающее модернизацию идентификации и унифицированное доверие к устройствам.
