Zero Trust — инженерная архитектура: каждое действие связано с идентичностью, полномочиями и текущим контекстом. Шесть слоёв показывают, как независимо контролируются обращения, среда исполнения, данные и допуск программного продукта.
Макет доступен для обзора на 360°. Схема помогает исследовать архитектуру с любого направления. Действующие механизмы и направления развития отмечены отдельно.
Выберите архитектурную зону на схеме или в списке, чтобы узнать, какой принцип она реализует и какие технологии используются на практике.
Номера помогают сопоставить элементы макета и разделы. Микросегментация раскрывается внутри Runtime Platform; зона 08 сохраняет функцию поведенческого анализа.
Один механизм оценивает конкретную операцию прямо сейчас. Другой контролирует продвижение программного продукта к рабочей среде.
Decision Factory оценивает идентичность, полномочия, состояние устройства, контекст сессии, текущий риск, целевой сервис, операцию и категорию данных. Результат: разрешить, ограничить, запросить подтверждение или отказать. Решение применяют соответствующие точки контроля.
Development Factory / Secure Development Pipeline ведёт продукт от идеи через разработку, проверки и исправления к допустимому развертыванию. Spirit — платформа разработки; Diameter — компонент управления состоянием безопасности. Непрохождение обязательного Security Gate запрещает следующий этап.
Сетевая достижимость, успешная аутентификация и разрешение конкретной операции — три разных результата. Наличие маршрута и успешный вход сами по себе не дают права выполнять любые действия.
Контекстные сигналы поступают независимо от пользовательского трафика. Decision Factory формирует решение; весь трафик не обязан проходить через неё. Когда события меняют риск, политики определяют реакцию на следующие обращения.
Есть разрешённый маршрут к ресурсу. Это ещё не подтверждение вызывающей стороны.
Установлено, кто обращается. Это ещё не разрешение любой операции.
Проверено право на конкретное действие с конкретным ресурсом и категорией данных.
Каждое действие выполняется от имени определённой идентичности. У каждого типа — свои учётные данные, минимальные полномочия, ограничения и требования доверия.
Доступ соответствует рабочим задачам, организационным полномочиям, политике и текущему контексту. Успешная аутентификация не создаёт безусловного доверия.
Внешние участники с ограниченными функциями. Даже при одинаковой роли дополнительные атрибуты организации и договора могут ограничивать доступные операции.
Идентичности с дополнительными привилегиями. Полномочия ограничены задачей, временем и областью действия; чувствительные операции требуют надёжного подтверждения, подходящего устройства и сессии. Административная роль не даёт God Mode.
Машинные идентичности для межсервисных обращений. Принимающий сервис устанавливает, какая нагрузка его вызывает и разрешено ли именно это взаимодействие.
У агента есть собственная идентичность, инструменты и границы делегирования. Учитывается, от имени какого пользователя или сервиса он действует. Опасные операции требуют подтверждения; все права человека автоматически не наследуются.
ID-Hub отвечает за управление идентичностью и аутентификацией; T-Access — за жизненный цикл прав. Политики учитывают роли вместе с атрибутами организации, ресурса и сессии.
Одинаковая роль не гарантирует одинаковое решение. Для подрядчика, администратора или AI-агента действуют дополнительные условия и границы полномочий.
Подключение предоставляется к нужному сервису, а не автоматически к большим сетевым сегментам. Сетевой путь и разрешение бизнес-операции проверяются разными механизмами.
T-Connect реализует microVPN и персональный сетевой доступ по ролям. После успешной аутентификации маршрутизация ведёт к конкретным ресурсам с учётом сведений каталога сервисов; целые подсети по умолчанию не предоставляются.
Identity Aware Proxy используется в подходящих сценариях публикации и доступа к сервисам; идентичность учитывается в точке обращения.
Desktop as a Service предоставляет удалённую рабочую среду. Наличие сессии не отменяет авторизацию каждой чувствительной операции.
Например, подключение к отчётному сервису не открывает административные интерфейсы и не даёт безусловного права на выгрузку данных.
Контекст шире характеристик пользователя. Он связывает субъекта и устройство с текущей сессией, целевым сервисом, операцией и предполагаемой категорией данных.
Тип идентичности, роли и полномочия, организация, геолокация, недавняя история подключений и обращений. Учитываются события HR-системы, например отпуск.
Аппаратная идентичность, состояние ОС и средств защиты, compliance, признаки компрометации и отклонения конфигурации. Diameter Agent — кроссплатформенный легковесный агент на каждом хосте: собирает основные данные и контролирует compliance устройства.
Время и окружение, последовательность действий, аномальные события, свежесть и надёжность аутентификации.
Целевой сервис и его функциональность, запрошенная операция, предполагаемая категория данных. Эти атрибуты поступают в Decision Factory вместе с остальным контекстом.
Один и тот же субъект может получить разные решения для чтения отчёта, массовой выгрузки или изменения конфигурации — особенно при изменении состояния устройства и сессии.
Сейчас механизм реализован частично: на базе контролей реагирования SOC и внутреннего антифрода. В общую экосистему он пока не интегрирован. Ниже показан принцип его целевого взаимодействия с контекстом и политиками.
Статус: частичная реализация. Общая интеграция сигналов в Decision Factory — направление развития. Целевая роль — обновлять Identity Risk, Device Risk и Session Risk; реакцию задают политики.
Входы и действия в сессиях, обращения к сервисам и данным, состояние устройств, межсервисные вызовы, результаты авторизации, действия AI-агентов и срабатывания корреляционных правил SOC.
Обращения в production и к чувствительным массивам данных требуют внимания к истории и последовательности действий. Анализ событий и вероятных намерений описывает целевой принцип, а не полностью внедрённую функцию.
Обычно сотрудник просматривает несколько отчётов, затем начинает массовую выгрузку. Риск сессии меняется; следующее обращение может потребовать дополнительного подтверждения либо получить отказ.
Decision Factory — общее архитектурное название совокупности механизмов принятия решений. Они объединяют идентичность, полномочия, контекст, актуальный риск и политики с информацией о сервисе и данных. Решение относится к конкретному обращению.
Метод и надёжность аутентификации, признаки компрометации и история поведения. FIDO2 используется для фишинг-устойчивой аутентификации. Управление идентичностью и аутентификацией — ID-Hub.
Аппаратная идентичность через TPM, состояние ОС, средств защиты, compliance и изменения конфигурации. Аттестация платформы, ОС и нагрузок учитывается там, где реализована. Сигналы собирает Diameter Agent.
Время, среда, последовательность операций, изменения активности и аномальные события. Риск постоянно переоценивается по событиям, а не только при входе.
Учитываются организационные роли, права, принадлежность к организации, статус подрядчика, отношения субъекта и ресурса, атрибуты сервиса и данных.
IAM — ID-Hub; IDM — T-Access. ABAC-as-a-Service учитывает атрибуты, T-PDP выполняет роль Policy Decision Point; Conditional Access задаёт условия допустимости действия.
Глобальные политики охватывают множество систем или организацию; локальные уточняют условия конкретного сервиса и функции. Правила задают разрешения, запреты, требования к устройству, категории данных, step-up и ограничения операций.
Это иллюстрации принципа. Они не означают, что каждый сценарий уже внедрён во всех продуктивных системах.
Роль в отчётном сервисе одинакова. Сотрудник читает и выгружает разрешённый отчёт; подрядчик просматривает разрешённые данные, но не может массово выгрузить ПДн из-за атрибута подрядной организации.
Проверяется операция, а не только вход.Утром привычная операция разрешена. Позже появляются нетипичная геолокация, необычная частота запросов или изменение ОС. Та же операция требует step-up аутентификации либо блокируется.
Решение зависит от актуального контекста.Пользователь может открыть сервис, но запрашивает данные категории, на которую у него нет полномочий. Сервис остаётся доступным, конкретное обращение к данным отклоняется.
Подключение не заменяет авторизацию данных.Агенту разрешено читать выбранные документы и создавать черновики. Массовая выгрузка конфиденциальных данных или изменение прав требует отдельного разрешения либо блокируется.
Делегирование имеет явные границы.Диагностика разрешена в пределах задачи. Изменение конфигурации production-сервиса требует более надёжной аутентификации, соответствующего устройства и выполнения дополнительных условий.
Привилегии не безусловны.Нагрузка имеет право читать определённые данные другого сервиса. Обращение к административному интерфейсу или недекларированная операция блокируется.
Проверяются идентичность, цель и взаимодействие.Балансировка обеспечивает вход и распределение обращений к экземплярам сервиса. Она не подменяет проверку идентичности и права на бизнес-операцию.
Load Balancer as a Service направляет обращения к выбранной нагрузке в пределах допустимого маршрута. Решения об авторизации принимаются и применяются соответствующими механизмами.
Запрос может быть корректно доставлен в отчётный сервис, но операция выгрузки конфиденциальных данных всё равно требует самостоятельного разрешения.
Распределённая среда на Kubernetes (k8s) исполняет web-приложения, API, batch-задачи, аналитические, ML-нагрузки и другие сервисы. Единые принципы управления сочетаются с распределённым исполнением для отказоустойчивости.
Минимум доступных функций и возможностей, чтобы уменьшить поверхность атаки.
Максимальная неизменяемость образов и файловых систем исполняемых нагрузок. Изменения доставляются через управляемую замену.
Состояние отделяется от исполняемой нагрузки там, где это возможно: так проще перевыкатка, восстановление и масштабирование.
Привилегированные контейнеры и необоснованный доступ к хостовой системе запрещены по умолчанию.
Произвольные сетевые обращения не разрешены по умолчанию. Разрешение выдаётся на конкретное взаимодействие.
Зависимости и связи сервисов декларируются явно; нахождение в одной сети не создаёт доверия.
Регулярная или непрерывная замена нагрузок и автоматическое восстановление после отказов там, где это возможно.
Трубы между сервисами обозначают разрешённые связи; ворота и границы — точки применения политики. Ограничения действуют на хостах и в сетевом пути. Разделение на сетевые сегменты само по себе не определяет допустимость каждого обращения.
SPIFFE / SPIRE и mTLS уже используются для идентичности нагрузок и проверки сторон связи. Принимающая сторона устанавливает вызывающую нагрузку; право на конкретное взаимодействие проверяется отдельно.
Host-Based Firewall (HBF) и Firewall as a Service (FWaaS) — собственные решения. HBF использует eBPF и XDP для enforcement сетевых правил и микросегментации.
T-Agent — общий базовый блок для приложений-агентов на хостах, а не ИИ-агент. Он задаёт работу с аттестацией хоста, TPM и SPIFFE / SPIRE, а также аттестацией других нагрузок.
Каталог приложений, Network Access Control и база конфигурационных единиц дают сведения о сервисах, ресурсах, зависимостях, принадлежности и разрешённых взаимодействиях.
Декларативный реестр контрактов внешних интерфейсов сервисов. Определяет разрешённые к публикации endpoint и допустимую форму запросов. Не заменяет авторизацию бизнес-операций.
Пример контракта: опубликован API с объявленными параметрами. Неожиданный параметр или запрос к внутреннему endpoint отклоняется как не соответствующий контракту. Это снижает поверхность атаки и пространство нежелательных сценариев фаззинга и динамического анализа.
Операционные и аналитические данные выполняют разные задачи, но их категории становятся общими атрибутами политик доступа и обработки. Hound — один из инструментов этого слоя.
Базы и хранилища работающих приложений обеспечивают текущие бизнес-операции и транзакции.
Аналитические хранилища, подготовленные данные, витрины и отчётность используются для анализа и бизнес-задач.
Подход к хранению и обработке аналитических данных и формированию наборов для дальнейшего использования. Data Lakehouse также обозначается DLH; это архитектурный подход.
Разные категории данных требуют разных правил: персональные данные, медицинская и банковская тайна, тайна связи и другая конфиденциальная информация.
Классификация и категоризация содержимого. Результат описывает, к каким категориям относятся данные.
Взаимосвязанный с Hound каталог и инвентарь данных: схемы, таблицы, атрибуты, описания, связи и инвентарная информация.
Пользователь может иметь право открыть сервис, но не читать медицинские сведения или выгружать ПДн. Категория запрошенных данных поступает обратно в Decision Factory и меняет решение по конкретной операции.
Development ведёт продукт от идеи до допуска в рабочую среду. Проверки находят проблемы, оценка определяет допустимость, исправления возвращаются на повторную проверку. Обязательный Security Gate технически останавливает неприемлемое продвижение.
Основная платформа разработки. Объединяет работу над продуктом с проверками, исправлениями и механизмами допуска.
Application Security Posture: сводит состояние безопасности приложений и сервисов, результаты сканирования и другие сигналы. Через него реализуется и оркестрируется часть проверок и оценок.
ИИ-ассистент в UI Diameter. Через чат позволяет работать со своими данными и сведениями системы так же, как в привычных ИИ-ассистентах.
Сканирование, ведение posture и автоматизация исправлений связаны, но выполняют разные задачи.
ИИ-агент для атак и пентеста: исследует приложения и инфраструктуру, проверяет сценарии атак и ищет уязвимости, в том числе в исходном коде. Использует собственные инструменты и оркестрацию.
Работает с проблемами из любых источников, собранных в Diameter. Формирует предлагаемые исправления или merge requests для устранения уязвимостей. Исправленные изменения проходят повторные проверки.
Code, Image и Application / Deployment — разные объекты контроля. Deployment Security Gate показан отдельно как предлагаемое развитие.
Можно ли принять изменение?
Встроен в GitLab на уровне проверок и виджета. Агрегирует результаты поиска секретов, проблем Infrastructure as Code, уязвимостей и слабостей кода. При непрохождении gate Merge Request блокируется. Проверка MR и merge относится к этому же gate.
Обязательная проверка не пройдена → изменение не принимается.
Допустимо ли использовать образ?
Интегрирован во внутренний Docker Registry Arbocrate. Оценка качества образа с использованием Diameter учитывает уязвимости, секреты и другие проблемы. Заведомо неприемлемый образ блокируется сразу. Если ранее допустимый образ стал небезопасным, политика может дать ограниченный срок исправления с учётом тяжести проблемы.
Срок исправления истёк → образ блокируется автоматически.
Можно ли развернуть приложение целиком?
Предлагаемый механизм на базе Diameter. Может учитывать результаты предыдущих gates, состояние приложения, уязвимости, конфигурацию, зависимости и другие сигналы безопасности. Итог — разрешить или запретить развертывание всего приложения.
Направление развития архитектуры; не заявляется как действующее в production.
Security Gates управляют допуском. При непрохождении обязательной проверки соответствующий следующий этап запрещён.
Устаревшая система — временное исключение. Изоляция снижает риск до её устранения; конечная цель — замена или полное отключение.
Ограничиваются сетевые связи и интеграции. План замены или отказа учитывает технические и организационные обстоятельства и ведёт к максимально быстрому выводу.
Уязвимый сервис перестаёт быть постоянной точкой распространения компрометации. Временные ограничения не заменяют устранение самого legacy.
При компрометации одной идентичности, устройства, сервиса или приложения независимые ограничения усложняют развитие атаки и уменьшают возможные последствия. Они не дают абсолютной гарантии.
Скомпрометированной учётной записи недостаточно, если устройство, подтверждение личности или контекст не соответствуют требованиям.
Захваченный сервис не получает произвольный lateral movement: межсервисные связи декларируются, сетевой доступ ограничен, привилегии минимальны.
Даже после входа в приложение массовая выгрузка чувствительных данных требует отдельного решения с учётом операции, категории и текущего риска.
Обязательные gates блокируют неприемлемые изменения и образы. Если допустимый образ стал небезопасным, после срока исправления его использование блокируется.
Hardening и immutable runtime ограничивают возможности нагрузки, Endpoint Registry — опубликованные интерфейсы, микросегментация — связи. Legacy изолируется и выводится из эксплуатации.
Физические элементы помогают увидеть взаимосвязь механизмов. Их смысл сохраняется при обзоре с любого направления.
Обозначают субъектов и сервисы со своими идентичностями и ограниченными полномочиями.
Трубы обозначают конкретные разрешённые взаимодействия; ворота и границы — применение политики.
Decision Factory показывает решение по операции, а Development — проверки и допуск продукта в рабочую среду.
Для изучения выберите зону на карте, прочитайте принцип, затем механизм реализации и практический пример. Логическая схема отдельно показывает пользовательский маршрут и управляющие сигналы.
Английские названия помогают сопоставить механизмы и внутренние решения. Определения поясняют их роль в архитектуре.
Сплошные связи показывают маршрут обращения; пунктирные — контекст, телеметрию и решения. Два действующих Security Gate отделены от целевого механизма допуска приложения.
