Часть 4 серии статей о внедрении безопасности на основе нулевого доверия в Red Hat OpenShift с использованием шаблона Layered Zero Trust Validated Pattern.
Нулевое доверие легко описать. Сложность заключается в том, чтобы сделать его воспроизводимым.
Концепцию нулевого доверия часто кратко описывают запоминающейся фразой: «никому не доверяй, всегда проверяй». Этот принцип звучит здраво и его легко описать, но эта короткая фраза не объясняет сложные моменты: что команда платформы должна развернуть в понедельник утром, как архитектор безопасности должен связать средства контроля в среде Kubernetes или как специалист по комплаенсу может доказать, что эти средства работают.
Именно в этом разрыве при внедрении и заключается истинная ценность Layered Zero Trust Validated Pattern (ZTVP).
В первой статье этой серии мы рассмотрели сетевые политики как последний рубеж обороны, когда организация не может быстро устранить уязвимости. Мы показали, как политика «запрещено по умолчанию» и явные правила входящего и исходящего трафика могут ограничить горизонтальное перемещение и сдержать радиус поражения скомпрометированной рабочей нагрузки. Во второй статье мы изучили Red Hat Advanced Cluster Security for Kubernetes как «активный мозг» безопасности, который отслеживает поведение во время выполнения и может завершать подозрительные рабочие нагрузки. Третья статья была посвящена уроку, который легко упустить: объявление намерений сетевой политики — это не то же самое, что проверка того, что политика работает должным образом в реальном кластере. Каждая из этих статей представляет собой шаг на пути к безопасности с нулевым доверием, как показано на Рисунке 1.
Рисунок 1: Путь к безопасности с нулевым доверием для Red Hat OpenShift
Следующий вопрос более обширен: что на самом деле получает пользователь, когда эти идеи объединяются в развертываемую архитектуру?
Ответ — не очередной продукт безопасности, а шаблон. Layered Zero Trust Validated Pattern — это открытая, управляемая через GitOps реализация скоординированных возможностей нулевого доверия для Red Hat OpenShift. Он предоставляет протестированную отправную точку, показывает, как взаимодействуют компоненты, и дает командам платформы и безопасности конкретные сценарии использования, которые они могут адаптировать для своих собственных приложений.
Нулевое доверие — это архитектура, а не галочка в чек-листе
NIST SP 800-207 определяет нулевое доверие как фундаментальное изменение предположений традиционных архитектур безопасности: никакое неявное доверие не предоставляется активу или учетной записи пользователя просто из-за их местоположения или принадлежности. Аутентификация и авторизация выполняются до предоставления доступа, а доступ постоянно оценивается в контексте.
Для облачно-ориентированного приложения это означает, что не существует единого шлюза на периметре, который мог бы реализовать всю модель безопасности. Пользователь, обращающийся к приложению, рабочая нагрузка, вызывающая базу данных, конвейер, публикующий образ, и администратор, изменяющий политику, — все они участвуют в различных типах транзакций. Каждый тип требует:
- Идентификация: Личность человека, сервисной учетной записи или даже агента, выполняющего действие.
- Решение: Разрешить или запретить запрошенное действие.
- Точка принудительного исполнения: Место, где решения могут быть эффективно реализованы.
- Доказательства: Свидетельства того, какое решение было принято для запрошенного действия и как оно было реализовано.
ZTVP превращает эту архитектуру в набор взаимодействующих уровней. Он использует Red Hat OpenShift GitOps и Validated Patterns framework для развертывания и согласования компонентов, поэтому среда представлена как код и может быть проверена, изменена и восстановлена через привычный рабочий процесс Git.
Это важно для конечных пользователей, поскольку шаблон устраняет большую часть работы по интеграции, которая обычно стоит между проектом безопасности и работающей демонстрацией. Не каждой организации нужно развертывать каждый компонент. Но взаимосвязи между идентификацией, секретами, передачей данных, сетевыми границами, мониторингом выполнения, сканированием на соответствие требованиям и средствами контроля цепочки поставок программного обеспечения являются наглядными и воспроизводимыми, и именно в этом заключается ценность шаблона.
Многоуровневая модель ZTVP
Шаблон организован в 3 разделенных уровня, как показано в Таблице 1. Каждый уровень строится на основе предыдущего, но наборы функций и сценарии использования могут быть выбраны в соответствии с потребностями организации.
Таблица 1: Уровни модели ZTVP
Уровень 1:
Наборы функций
- Red Hat Quay
- Multicloud object gateway
- Red Hat Trusted Artifact Signer
- Red Hat Trusted Profile Analyzer
- Red Hat OpenShift Pipelines
- Оператор сетевой наблюдаемости и оператор Loki для Red Hat OpenShift
Уровень 0:
Фундамент
- Compliance operator
- Red Hat Advanced Cluster Management for Kubernetes
- Red Hat Advanced Cluster Security for Kubernetes
- Оператор cert-manager для Red Hat OpenShift
- HashiCorp Vault
- External secrets operator
- Менеджер идентификации рабочих нагрузок с нулевым доверием
- Red Hat build of Keycloak
Red Hat OpenShift Container Platform
Red Hat OpenShift GitOps, построенный на базе Argo CD: развертывает и постоянно согласовывает все компоненты шаблона
Validated Patterns Operator: выполняет начальную загрузку шаблона, управляет жизненным циклом хаба/периферии и запускает императивные задания
Чтобы понять, как работают эти возможности, давайте сначала изучим фундаментальный уровень, который поддерживает всю архитектуру.
Уровень 0: Фундамент
Фундамент создает базу, которую может использовать любое развертывание. Он включает:
- Red Hat build of Keycloak для аутентификации пользователей и единого входа (SSO) через OpenID Connect (OIDC).
- Менеджер идентификации рабочих нагрузок с нулевым доверием, основанный на Secure Production Identity Framework for Everyone (SPIFFE) и SPIFFE Runtime Environment (SPIRE), для краткосрочных криптографических идентификаторов рабочих нагрузок.
- HashiCorp Vault и оператор внешних секретов для Red Hat OpenShift для централизованной доставки секретов «точно в срок».
- Оператор cert-manager для Red Hat OpenShift для управления жизненным циклом сертификатов и зашифрованной связи.
- Red Hat Advanced Cluster Security for Kubernetes для мониторинга выполнения, обнаружения угроз и реагирования.
- Red Hat Advanced Cluster Management для централизованной политики и сценариев управления несколькими кластерами.
- Compliance operator для постоянного сканирования и исправления в соответствии с доступными профилями безопасности.
Фундамент — это важный переход от изолированных инструментов к контуру контроля безопасности. Рабочая нагрузка может доказать, кто или что она такое, получить только необходимые ей секреты, обмениваться данными по защищенным каналам, работать внутри ограниченной сетевой границы и генерировать доказательства выполнения и соответствия требованиям.
Red Hat build of Keycloak устанавливается по умолчанию как OIDC-провайдер для управления идентификацией и доступом. Шаблон Layered Zero Trust Validated Pattern также поддерживает других OIDC-провайдеров, таких как Azure Entra ID.
Уровень 1: Наборы функций
Наборы функций расширяют фундамент для удовлетворения конкретных операционных требований. Например, возможности цепочки поставок могут добавить Red Hat Quay, Red Hat Trusted Artifact Signer, Red Hat Trusted Profile Analyzer и Red Hat OpenShift Pipelines. Оператор сетевой наблюдаемости может добавить визуализацию потоков через Loki и FlowCollector.
В этом заключается практическое преимущество многоуровневого проектирования: организация может начать с более безопасной базовой платформы, а затем подключать дополнительные возможности по мере развития своих сценариев использования. Команде не обязательно решать задачи идентификации рабочих нагрузок, защиты данных приложений, подтверждения происхождения образов и сетевой аналитики как один неделимый проект.
Сценарии использования ZTVP
В документации по текущим шаблонам представлен ряд сценариев использования, включая защиту данных с нулевым доверием, безопасную цепочку поставок и безопасную цепочку поставок — автоматизированный подход. Они помогут вам понять, как эта архитектура работает на практике. Эти сценарии — не просто игрушечные диаграммы; они показывают транзакции между субъектами и ресурсами и связывают эти транзакции с конкретными точками принудительного контроля. Каждый сценарий или их комбинация могут охватывать различные пользовательские пути. Давайте рассмотрим некоторые из наиболее типичных и интересных.
Пользовательский путь 1: Защита данных приложения без внедрения логики безопасности в само приложение
Представьте себе платформенного инженера, отвечающего за бизнес-приложение с веб-интерфейсом и базой данных PostgreSQL. Приложению требуются аутентификация пользователей, учетные данные базы данных и сетевой доступ к небольшому количеству сервисов. Традиционно эти требования часто превращаются в код приложения, долгоживущие секреты Kubernetes и набор широких сетевых правил.
В сценарии защиты данных ZTVP демонстрационное приложение qtodo показывает другой поток. Пользователь проходит аутентификацию через Red Hat build of Keycloak. Приложение развертывается с сайдкарами, которые обрабатывают идентификацию рабочей нагрузки и получение секретов. База данных PostgreSQL находится в отдельном пространстве имен, и доступ к ней ограничен явной сетевой политикой.
Когда под запускается, SPIRE подтверждает рабочую нагрузку и выдает идентификатор SPIFFE. Сайдкар использует этот идентификатор для аутентификации в Vault. Vault возвращает учетные данные базы данных, соответствующие данной рабочей нагрузке и контексту. Приложение получает то, что ему нужно, без необходимости встраивания долгоживущего пароля базы данных в образ; вместо этого пароль хранится внутри платформы (например, в виде секрета Kubernetes) или зафиксирован в репозитории Git.
Шаблон сайдкара отделяет вопросы безопасности от бизнес-логики. Аутентификация, mTLS, получение учетных данных, аудит и применение политик могут развиваться без необходимости для каждой команды разработчиков последовательно реализовывать эти функции в каждом сервисе. Компромиссом является дополнительный операционный компонент в поде, но поведение системы безопасности становится более централизованным и проверяемым.
Сетевая политика завершает этот путь. Политика «запретить по умолчанию» для всего пространства имен устраняет неявную связность. Явные правила позволяют приложению обращаться к PostgreSQL и необходимым сервисам платформы, в то время как исходящий трафик к несвязанным пространствам имен, API Kubernetes или общедоступному интернету остается заблокированным, если это не обосновано. Если под приложения скомпрометирован, у злоумышленника остается меньше путей для разведки, горизонтального перемещения и эксфильтрации данных.
Для платформенного инженера результатом является рабочий эталон для реализации общего требования: защита конфиденциальных данных при минимизации изменений в приложении. Для архитектора безопасности этот путь демонстрирует доступ на основе идентификации, принцип наименьших привилегий, сегментацию и глубокоэшелонированную защиту. Для разработчика средства контроля безопасности доступны через платформу, а не становятся специализированной функцией приложения.
Пользовательский путь 2: Установление доверия от источника до работающей рабочей нагрузки
Второй путь предназначен для архитектора безопасности или владельца цепочки поставок программного обеспечения. Люди на этих ролях сталкиваются с задачей, выходящей за рамки простого определения того, содержит ли образ известную уязвимость. Они также должны уметь установить, откуда пришел артефакт, что он содержит, был ли он проанализирован и должен ли кластер его принять.
Сценарий безопасной цепочки поставок связывает эти решения. OpenShift Pipelines может собрать артефакт. Trusted Artifact Signer может подписать его с помощью бесключевого рабочего процесса, снижая нагрузку по распространению и защите долгоживущих ключей подписи. Trusted Profile Analyzer может хранить и анализировать спецификации программного обеспечения (SBOM) и сопоставлять компоненты с уязвимостями и бюллетенями безопасности. Red Hat Quay (который является опциональным реестром OCI в ZTVP) предоставляет частный реестр для полученных образов.
Таким образом, цепочка доверия может быть представлена как последовательность: изменение в исходном коде, контролируемая сборка, генерация SBOM, анализ уязвимостей, подписание артефакта, проверка подписи и развертывание. В сценарии автоматизированной цепочки поставок Tekton (реализованный как OpenShift Pipelines в ZTVP) автоматизирует эту последовательность, чтобы проверка стала частью пути доставки, а не ручным действием, выполняемым после развертывания.
Ничто из этого не может гарантировать, что каждая уязвимость будет найдена или что подписанный образ автоматически безопасен. Это создает более надежные точки происхождения и принятия решений. Подпись отвечает на вопрос: «Был ли этот артефакт создан доверенным процессом?». SBOM и анализ уязвимостей помогают ответить на вопрос: «Что внутри и что известно об этих компонентах?». Политика определяет, приемлем ли этот артефакт для конкретной среды.
Пользовательский путь 3: Превращение конфигурации безопасности в доказательства
Третий путь предназначен для специалиста по соответствию требованиям и команд, которые должны объяснять работу платформы аудиторам. Архитектура нулевого доверия не является достоверной только потому, что ее компоненты установлены. Командам нужны доказательства того, что средства контроля настроены, изменения регулируются, а важное поведение системы прозрачно.
ZTVP помогает в этом, делая развертывание управляемым через GitOps. Желаемое состояние сохраняется и проверяется в Git, согласовывается с помощью OpenShift GitOps и отображается как история изменений. Оператор соответствия требованиям (compliance operator) непрерывно сканирует кластер на соответствие поддерживаемым профилям и может помочь в устранении нарушений. Red Hat Advanced Cluster Security предоставляет данные о событиях во время выполнения и наглядность политик безопасности. Наблюдение за сетевыми потоками и методы проверки, описанные в третьей статье этой серии, помогают сравнить предполагаемое взаимодействие с наблюдаемым.
Доказательства, полученные с помощью этих инструментов, не заменяют процесс управления организации. Это более полезная отправная точка, чем разовый скриншот или вручную составленная электронная таблица. Команда платформы может показать, что было развернуто, команда безопасности — что было обнаружено и заблокировано, а команда по соответствию требованиям — связать доказательства реализации с описанием своих контролей.
Какие фреймворки поддерживает развертывание по умолчанию?
Развертывание ZTVP по умолчанию поддерживает согласованность и наличие доказательств; оно не сертифицирует организацию автоматически на соответствие какому-либо фреймворку, не удовлетворяет всем требованиям контроля и не делает кластер авторизованным по FedRAMP. Требования фреймворков также зависят от области применения, конфигурации, организационных процессов и конкретного варианта развертывания.
Базовая конфигурация по умолчанию предоставляет значимую основу для фреймворков, описанных в Таблице 2.
Таблица 2: Как ZTVP работает с различными фреймворками
Важно различать базовые и дополнительные возможности ZTVP. Идентификация, секреты, сертификаты, мониторинг среды выполнения, сканирование на соответствие требованиям и сетевые границы являются частью фундамента, описанного в этом шаблоне. Частный реестр, подпись артефактов, анализ SBOM и автоматизированные конвейеры — это функциональные возможности, используемые в сценарии безопасной цепочки поставок. Организации следует сопоставить выбранный вариант ZTVP со своим планом безопасности системы и моделью наследования элементов управления.
Полную разбивку по возможностям с подробными описаниями см. в разделе сопоставления возможностей ZTVP с фреймворком на GitHub проекта.
От эталонной архитектуры к пути внедрения
ZTVP разработан для поддержки поэтапного внедрения. Команда может начать с развертывания фундамента и использования сценария защиты данных, чтобы разобраться с идентификацией рабочих нагрузок, динамическими секретами и микросегментацией. Затем можно добавить политики среды выполнения и сетевую наблюдаемость по мере того, как станет понятно, какие потоки являются ожидаемыми. Набор функций цепочки поставок можно внедрить, когда организация будет готова обеспечить соблюдение происхождения и принимать решения на основе SBOM.
Наиболее продуктивный цикл реализации остается тем же, что был установлен в предыдущей статье этой серии:
- Спроектируйте транзакцию и определите ее участника, ресурс, контекст и политику.
- Протестируйте политику в работающем кластере и убедитесь, что необходимые потоки по-прежнему функционируют.
- Разверните проверенное состояние с помощью Red Hat OpenShift GitOps.
- Наблюдайте за поведением во время выполнения, результатами проверки на соответствие требованиям и сетевыми потоками.
- Вносите итеративные изменения при изменении приложения, платформы или модели угроз.
Этот цикл — реальный результат использования ZTVP для конечного пользователя. Он предоставляет инженерам платформы готовые к развертыванию строительные блоки, архитекторам безопасности — конкретную архитектуру для оценки, а командам по комплаенсу — путь для сбора доказательств. Он также делает видимыми пробелы: возможность, которая не была включена, политика, которая не была протестирована, или элемент управления, который все еще требует организационного процесса.
Начало работы
Layered Zero Trust Validated Pattern доступен через проект Validated Patterns и его исходный репозиторий. Текущая документация по началу работы описывает предварительные требования Red Hat OpenShift, развертывание GitOps, варианты конфигурации и шаги по проверке.
Начните с одного пользовательского сценария, а не со списка продуктов. Защитите одно приложение и его данные, отследите один программный артефакт от исходного кода до развертывания или возьмите одно требование соответствия и определите доказательства, которые может предоставить платформа. Затем используйте многоуровневую архитектуру, чтобы добавить следующую возможность, не теряя связей, установленных в фундаменте.
Нулевое доверие становится практичным, когда политика явна, точка принудительного исполнения реальна, результат наблюдаем, а процесс повторяем. ZTVP предоставляет такую отправную точку для Red Hat OpenShift — и путь для превращения нулевого доверия из архитектурной амбиции в операционную практику.
Ссылки
- Layered Zero Trust Validated Pattern
- Архитектура ZTVP
- Начало работы с ZTVP
- Модель зрелости нулевого доверия CISA
- Предыдущие публикации в блоге из этой серии: Часть 1: «Не успеваете быстро исправлять уязвимости? Нулевое доверие как последний рубеж обороны» Часть 2: «Свет включен! Реагирование на угрозы в реальном времени с помощью Red Hat Advanced Cluster Security» Часть 3: «Замыкая цикл: от намерения сетевой политики к проверенной реальности»
- Часть 1: «Не успеваете быстро исправлять уязвимости? Нулевое доверие как последний рубеж обороны»
- Часть 2: «Свет включен! Реагирование на угрозы в реальном времени с помощью Red Hat Advanced Cluster Security»
- Часть 3: «Замыкая цикл: от намерения сетевой политики к проверенной реальности»
