DevSecOps на Azure Kubernetes Service (AKS)

DevSecOps, также называемый Secure DevOps, основывается на практике DevOps путем включения безопасности на различных этапах традиционного жизненного цикла DevOps. Создайте безопасность в методах DevOps, чтобы:

• Обеспечение безопасности приложений и систем, обеспечение видимости угроз безопасности и предотвращение уязвимостей в развернутых средах.

• Повышение осведомленности о безопасности в группах разработчиков и операций.

• Включите автоматизированные процессы безопасности в жизненный цикл разработки программного обеспечения (SDLC).

• Сокращайте затраты на устранение, находя проблемы безопасности на ранних этапах разработки и проектирования.

При применении DevSecOps к службе Azure Kubernetes (AKS) каждая роль организации имеет определенные аспекты безопасности:

• Разработчики создают безопасные приложения, которые выполняются в AKS.

• Облачные инженеры создают безопасную инфраструктуру AKS.

• Группы операций могут управлять кластерами или отслеживать проблемы безопасности.

Эта статья структурирует руководство по этапам жизненного цикла DevOps и предоставляет рекомендации по элементам управления безопасностью и лучшим практикам. В ней рассматриваются распространенные процессы и инструменты для конвейеров непрерывной интеграции и непрерывной доставки (CI/CD), с акцентом на встроенные инструменты.

Поток процесса

Скачайте файл Visio для этой архитектуры.

1. Microsoft Entra ID настроен в качестве поставщика идентификации для GitHub. Настройте многофакторную проверку подлинности (MFA), чтобы обеспечить дополнительную безопасность проверки подлинности.

2. Разработчики используют Visual Studio Code или Visual Studio с расширениями безопасности, включенными для упреждающего анализа кода для уязвимостей безопасности.

3. Разработчики фиксируют код приложения в корпоративном и управляемом репозитории GitHub Enterprise.

4. GitHub Enterprise интегрирует автоматическую проверку безопасности и зависимостей с помощью GitHub Advanced Security.

5. Пулл-реквесты запускают сборки непрерывной интеграции (CI) и автоматическое тестирование с помощью GitHub Actions.

6. Рабочий процесс сборки CI с помощью GitHub Actions создает образ контейнера Docker и сохраняет его в реестре контейнеров Azure.

7. Вы можете добавить ручные утверждения для развертываний в определённые среды, например, в производственной среде, в GitHub Actions в рамках рабочего процесса непрерывной доставки (CD).

8. GitHub Actions позволяют реализовать CD на AKS. Используйте GitHub Advanced Security для обнаружения секретов, учетных данных и других конфиденциальных данных в файлах источника и конфигурации приложения.

9. Microsoft Defender сканирует реестр контейнеров, кластер AKS и Azure Key Vault для уязвимостей безопасности.

   1. Microsoft Defender для контейнеров проверяет образ контейнера на наличие известных уязвимостей безопасности, когда GitHub Actions отправляет его в реестр контейнеров.

   2. Defender для контейнеров также может сканировать вашу среду AKS и обеспечивать защиту от угроз в процессе выполнения для кластеров AKS.

   3. Microsoft Defender для Key Vault обнаруживает необычные и подозрительные попытки доступа к учетным записям хранилища ключей.

10. Вы можете применить политику Azure к реестру контейнеров и AKS для обеспечения соответствия политик. Политика Azure включает встроенные политики безопасности для реестра контейнеров и AKS.

11. Key Vault безопасно внедряет секреты и учетные данные в приложение во время выполнения, не предоставляя их разработчикам.

12. Механизм сетевых политик AKS настроен для защиты трафика между подами приложений с помощью сетевых политик Kubernetes. Мы рекомендуем Azure CNI Powered by Cilium в качестве подсистемы политики сети. Он предоставляет внедрение на основе расширенного фильтра пакетов Berkeley (eBPF), политику для уровня 7 и фильтрацию полностью квалифицированных доменных имен (FQDN).

13. Вы можете настроить непрерывный мониторинг кластера AKS с помощью Azure Monitor для сбора метрик Prometheus, журналов контейнеров и событий Kubernetes. Используйте панели мониторинга Azure Grafana для визуализации и Log Analytics для оповещений на основе запросов.

    1. Azure Monitor собирает метрики производительности с помощью управляемого Prometheus, а журналы приложений и кластеров — через коллекцию журналов контейнеров.

    2. Рабочая область Log Analytics хранит журналы диагностики и приложений для выполнения запросов журналов.

14. Используйте Microsoft Sentinel в качестве централизованной информации безопасности и управления событиями (SIEM) для сопоставления телеметрии AKS с сигналами от Microsoft Defender для облака, идентификатора Microsoft Entra ID и сетевых ресурсов. Microsoft Sentinel обеспечивает обнаружение, исследование и автоматическое реагирование на инциденты безопасности во всей среде AKS.

15. Средства с открытым исходным кодом, такие как Zed Attack Proxy (ZAP), могут выполнять тестирование на проникновение для веб-приложений и служб.

16. Defender для DevOps, служба, доступная в Defender для облака, позволяет командам безопасности управлять безопасностью DevOps в мультипиплайновых средах, включая GitHub и Azure DevOps.

Общие сведения о членах группы и обязанностях

Рассмотрите возможность управления сложностью DevSecOps в развертываниях решений на основе Kubernetes, разделив обязанности между командами. В этом разделе описываются роли и обязанности разработчиков, операторов приложений, таких как инженеры надежности сайта, операторы кластера и группы безопасности.

Разработчики

Разработчики записывают код приложения и фиксируют его в указанном репозитории. Они выполняют скрипты для автоматического тестирования, чтобы убедиться, что их код работает как предполагаемое и интегрируется с остальными приложениями. Разработчики также определяют и скрипты создания образов контейнеров в рамках конвейера автоматизации.

Операторы приложений (инженеры надежности сайта)

Создание приложений с помощью контейнеров и Kubernetes может упростить разработку, развертывание и масштабируемость приложений. Но эти подходы к разработке также создают все более распределенные среды, которые усложняют администрирование.

Инженеры надежности сайта создают решения, автоматизирующие контроль над крупными программными системами. Они служат мостом между командами операторов разработки и кластера. Они помогают устанавливать и отслеживать цели уровня обслуживания (SLOS) и бюджеты ошибок. Инженеры надежности сайта также помогают управлять развертываниями приложений и записывать файлы манифеста Kubernetes (YAML).

Операторы кластера

Операторы кластера настраивают инфраструктуру кластера и управляют ею. Они часто используют лучшие практики инфраструктуры как код (IaC) и такие фреймворки, как GitOps, для развертывания и обслуживания кластеров. Они используют такие средства мониторинга, как управляемая служба Azure Monitor для Prometheus и Azure Managed Grafana для мониторинга общего состояния кластера. Они отвечают за установку патчей, обновление кластера, разрешения и управление доступом на основе ролей (RBAC) в кластере. В командах DevSecOps операторы кластеров сотрудничают с группами безопасности для установления стандартов безопасности и обеспечения соответствия кластеров этим требованиям.

Отдел безопасности

Команда безопасности разрабатывает и применяет стандарты безопасности. Некоторые команды могут создавать и выбирать определения политики Azure, которые применяются в подписках и группах ресурсов, содержащих кластеры. Группы безопасности отслеживают проблемы безопасности и работают с другими командами, чтобы определить приоритет безопасности в процессе DevSecOps.

Этапы жизненного цикла DevSecOps

Каждый этап SDLC реализует элементы управления безопасностью. Эти элементы управления безопасностью являются центральными для DevSecOps и практик "сдвига влево".

Скачайте файл Visio для этой архитектуры.

Этап плана

Этап плана обычно имеет наименьший объем автоматизации, но имеет важные последствия для безопасности, которые влияют на последующие этапы жизненного цикла DevOps. Этот этап включает совместную работу между группами безопасности, разработки и операций. Чтобы учитывать требования и решать проблемы безопасности, включите заинтересованных лиц на этом этапе.

Рекомендация. Разработка безопасной платформы приложений

Чтобы создать безопасную рабочую нагрузку, размещенную в AKS, необходимо включить безопасность в систему на каждом уровне, начиная с самой платформы. Платформа может включать компоненты, внутренние в кластер, такие как агенты безопасности и политики среды выполнения, а также компоненты, внешние для AKS, такие как брандмауэры сети и реестры контейнеров.

Лучшая практика: включение моделирования угроз в ваш процесс

Моделирование угроз обычно представляет собой ручное действие, включающее команды безопасности и разработки. Вы можете моделировать и находить угрозы в системе для решения уязвимостей перед разработкой кода или внесением изменений. Teams проводят моделирование угроз в ответ на значительные изменения программного обеспечения, изменения архитектуры решения или инциденты безопасности.

Мы рекомендуем модель угроз STRIDE. Эта методология начинается с схемы потока данных и классифицирует угрозы с помощью мнемоники STRIDE: спуфинг, изменение, отказ, раскрытие информации, отказ в обслуживании и повышение привилегий. Команды используют эти категории для выявления, устранения и проверки рисков. Средство моделирования помогает нотировать и визуализировать системные компоненты, потоки данных и границы безопасности.

Создание моделирования угроз в SDLC добавляет затраты на процесс и требует поддержания обновленных моделей угроз. Однако она отвечает за безопасность на ранних этапах разработки, что снижает затраты на устранение проблем, обнаруженных позже.

Рекомендации. Применение платформы Azure Well-Architected Framework

• Применяйте рекомендации по обеспечению безопасности , которые предоставляют рекомендации по управлению удостоверениями, безопасности приложений, защите инфраструктуры, безопасности данных и DevOps, которые применяются к облачным средам.

• Применяйте рекомендации по операционному превосходству , так как он применяется к DevSecOps и мониторингу рабочих сред.

Этап разработки

Сдвиг влево — это ключевой принцип мышления DevSecOps. Этот процесс начинается перед тем, как вы зафиксируете код в репозитории и развернете его через сборочный конвейер. Чтобы решить проблемы безопасности, возникающие ранее в жизненном цикле разработки, запустите рекомендации по безопасному написанию кода и используйте интегрированные средства и подключаемые модули среды разработки для анализа кода на этапе разработки.

Лучшие практики: Обеспечение стандартов безопасного программирования

• Используйте установленные рекомендации по безопасному написанию кода и контрольные списки, чтобы защитить код от распространенных уязвимостей, таких как внедрение и небезопасный дизайн. Фонд Open Worldwide Application Security Project (OWASP) публикует отраслевые рекомендации по безопасному кодированию, которые следует принять при написании кода. Эти рекомендации особенно важны при разработке общедоступных веб-приложений или служб.

• Просмотрите безопасные методики написания кода для определенных сред выполнения языка программирования, таких как Java и .NET.

• Применение стандартов ведения журнала для защиты конфиденциальной информации от утечки в журналы приложений. Наиболее популярные платформы ведения журнала, такие как Apache Log4j и Apache log4net, предоставляют фильтры и подключаемые модули для маскирования конфиденциальных данных, таких как номера учетных записей или персональные данные.

Рекомендация: Использование инструментов и подключаемых модулей интегрированной среды разработки (IDE) для автоматизации проверок безопасности

Наиболее популярные интегрированные среды разработки, такие как Visual Studio, VS Code, IntelliJ IDEA и Eclipse, поддерживают плагины, которые можно использовать для получения немедленной обратной связи и рекомендаций по уязвимостям, которые вы можете ввести при написании кода приложения.

• SonarQube для интегрированной среды разработки — это подключаемый модуль интегрированной среды разработки для большинства популярных языков и сред разработчика. SonarQube для интегрированной среды разработки предоставляет отзывы и автоматически сканирует код для распространенных ошибок программирования и потенциальных проблем безопасности.

• Другие бесплатные и коммерческие подключаемые модули сосредоточены на конкретных элементах безопасности, таких как топ 10 распространенных уязвимостей OWASP. Подключаемый модуль Snyk также сканирует исходный код приложения и внешние зависимости и оповещает, если он находит уязвимости.

• Подключаемый модуль Формат обмена статическими результатами анализа (SARIF) для Visual Studio и VS Code позволяет легко просматривать уязвимости, обнаруженные популярными средствами статического тестирования безопасности приложений (SAST), вместо интерпретации необработанных выходных файлов JSON.

Лучшие практики: Установление контрольных мер в репозиториях исходного кода

• Создайте методологию ветвления для согласованности в организации. Методологии, такие как поток выпуска и поток GitHub , имеют структурированные рекомендации по использованию ветвей для поддержки группы и параллельной разработки. Эти методологии могут помочь командам устанавливать стандарты и контролировать коммиты и слияния кода в ваш рабочий процесс CI/CD.

  Некоторые ветви, такие как main, являются долгосрочными ветвями, которые сохраняют целостность исходного кода приложения. Установите политики слияния для этих ветвей перед фиксацией или слиянием изменений. Например, доступны следующие возможности:

  • Запретить другим разработчикам коммитить код непосредственно в основной ветке.

  • Создайте процесс проведения рецензирования и требуйте минимального числа одобрений перед слиянием изменений в основную ветку. Настройте и примените эти элементы управления с помощью GitHub. При необходимости используйте GitHub для назначения уполномоченных групп утверждающих в ограниченной среде.

• Используйте предварительные перехватчики, чтобы проверять исходный код приложения на наличие конфиденциальной информации и блокировать фиксации при обнаружении проблем безопасности.

  • Используйте встроенные прехуки, предоставляемые GitHub. Легко настроить их для конкретных проектов. Например, некоторые предустановленные перехватчики сканируют на предмет секретов, закрытых ключей и учетных данных, и блокируют фиксацию, если обнаруживают эти проблемы.

• Установите RBAC в системе управления версиями.

  • Создайте четко определенные роли с помощью принципа наименьшей привилегии. Конвейер CI/CD работает в качестве цепочки поставок для производственных развертываний.

  • Применение установленных ролей пользователей или групп в организации. Чтобы группировать отдельных лиц на основе определенной роли и функции в рабочих процессах CI/CD, создайте роли, такие как администратор, разработчик, администратор безопасности и оператор.

• Включите аудит ваших рабочих процессов, чтобы добавить прозрачность и отслеживаемость для конфигурации и других изменений в конвейерах CI/CD.

Рекомендуемая практика: Защита образов контейнеров

• Используйте упрощенные образы с минимальным объемом использования ОС, чтобы уменьшить общую область атаки. Рассмотрите минимальные образы, такие как Alpine или distroless, содержащие только ваше приложение и связанную с ним среду выполнения.

• Используйте только доверенные базовые образы при сборке контейнеров. Извлеките эти основные образы из частного реестра, который вы часто проверяете на наличие уязвимостей.

• Используйте средства разработчика для анализа уязвимостей образов локально. Trivy — это средство с открытым исходным кодом, которое анализирует уязвимости безопасности в образах контейнеров.

• Запрет доступа корневого пользователя или контекста для изображения. По умолчанию контейнеры запускаются с привилегиями root.

  Для контейнеров, которым требуется улучшенная безопасность, рекомендуется использовать профиль AppArmor или seccomp в кластере Kubernetes, чтобы обеспечить безопасность запущенных контейнеров.

Этап сборки

На этапе сборки разработчики работают с инженерами надежности сайта и командами безопасности для интеграции автоматизированных проверок источника приложения в конвейерах сборки CI. Группы настраивают потоки для обеспечения практик безопасности с помощью средств безопасности и расширений платформы CI/CD. К этим практикам относятся SAST, анализ состава программного обеспечения (SCA) и сканирование секретов.

Рекомендация. Выполните SAST, чтобы найти потенциальные уязвимости в исходном коде приложения

• Используйте возможности проверки расширенной безопасности GitHub для сканирования кода и CodeQL.

  • Сканирование кода — это функция, которая анализирует код в репозитории GitHub для поиска уязвимостей безопасности и ошибок кодирования. В нем отображаются проблемы в GitHub Enterprise Cloud.

  • Если сканирование кода находит потенциальную уязвимость или ошибку в коде, GitHub отображает оповещение в репозитории.

  • Правила ветви можно настроить для обязательных проверок состояния. Например, перед слиянием нового кода можно требовать, чтобы ветви компонентов были обновлены с базовой ветвью. Это требование гарантирует, что вы тестируете ветвь с помощью последнего кода.

  • Включите Автофикс Copilot для получения предложений исправления, созданных ИИ, для оповещений о сканировании кода. Copilot Autofix предлагает исправление непосредственно в pull-запросах, что помогает разработчикам быстро устранять проблемы безопасности.

• Используйте такие средства, как kube-score , для анализа объектов развертывания Kubernetes. Это средство выполняет статический анализ кода определений объектов Kubernetes. Он выводит список рекомендаций, чтобы сделать приложение более безопасным и устойчивым.

Лучшая практика: используйте сканирование секретов для обнаружения случайно зафиксированных секретов

• Если включить проверку секретов для репозитория, GitHub сканирует код для шаблонов, соответствующих секретам, которые используют многие поставщики услуг.

• GitHub периодически выполняет полное сканирование истории Git для существующего содержимого в репозиториях и отправляет уведомления.

  • Для Azure DevOps Защитник для облака использует проверку секретов для обнаружения учетных данных, секретов, сертификатов и другого конфиденциального содержимого в исходном коде и выходных данных сборки.

  • Вы можете выполнять сканирование секретов в рамках расширения Microsoft Security DevOps для Azure DevOps.

Рекомендация. Использование средств SCA для отслеживания компонентов с открытым исходным кодом в базе кода и обнаружения уязвимостей в зависимостях

• Проверка зависимостей позволяет перехватывать небезопасные зависимости перед их вводом в среду. Он также предоставляет сведения о лицензии, зависимостях и возрасте зависимостей. Она отображает изменения зависимостей через расширенный дифф на вкладке Измененные файлы в запросе на вытягивание.

• Dependabot выполняет сканирование для обнаружения небезопасных зависимостей и отправки оповещений Dependabot при добавлении новых рекомендаций в базу данных рекомендаций GitHub или при изменении графа зависимостей для репозитория.

Лучшие методы: создавайте SBOM для образов контейнеров

• Перечень материалов программного обеспечения (SBOM) предоставляет полный перечень компонентов, библиотек и зависимостей, составляющих образы ваших контейнеров. Используйте средства создания SBOM, такие как microsoft sbom-tool или Syft во время сборки CI, чтобы создать манифест SPDX или ЦиклонDX.

• Подключите SBOM к образам контейнеров, хранящимся в реестре контейнеров, чтобы включить сканирование уязвимостей и отслеживание соответствия лицензий на всех этапах цепочки поставок.

Передовая практика: сканирование шаблонов IaC для обнаружения неправильных конфигураций перед развертыванием.

• Заранее отслеживайте конфигурации облачных ресурсов в течение жизненного цикла разработки.

• Microsoft Defender для DevOps поддерживает репозитории GitHub и Azure DevOps и может проверять шаблоны IaC для выявления уязвимостей IaC.

Рекомендация. Сканирование образов рабочей нагрузки в реестрах контейнеров для выявления известных уязвимостей

• Defender для контейнеров проверяет контейнеры в Контейнерном реестре и Реестре эластичных контейнеров Amazon (ECR), чтобы уведомить вас о выявленных уязвимостях в ваших образах.

• Вы можете включить политику Azure для оценки уязвимостей на образах, хранящихся в реестре контейнеров, и предоставить подробные сведения о каждом обнаружении.

Рекомендация. Автоматическое создание новых образов на основе обновлений базового образа

• Задачи реестра контейнеров динамически обнаруживают зависимости базового образа при сборке образа контейнера. При обнаружении обновления базового образа приложения можно настроить задачу сборки для автоматического перестроения образов приложений, ссылающихся на базовый образ.

Рекомендация. Использование реестра контейнеров, Key Vault и нотации для цифровой подписи образов контейнеров и настройки кластера AKS для разрешения только проверенных образов

• Key Vault хранит ключи подписывания, которые использует средство нотации . Подключаемый модуль нотации Key Vault (azure-kv) использует эти ключи, чтобы подписывать и проверять образы контейнеров и другие артефакты. Эти подписи можно присоединить к образам реестра контейнеров с помощью команд Azure CLI.

• Подписанные контейнеры гарантируют, что развертывания приходят из доверенного источника и что компоненты не подвергаются изменениям после создания. Подписанный артефакт гарантирует целостность и подлинность, прежде чем пользователь извлекает артефакт в любую среду, что помогает избежать атак.

  • Ratify апробирует метаданные безопасности артефактов и применяет политики допуска перед развертыванием в кластерах Kubernetes. Целостность образов AKS использует Ratify как встроенный верификатор для проверки подписей образов и аттестаций SBOM до того, как pod будут допущены в кластер.

Этап развертывания

На этапе развертывания разработчики, операторы приложений и группы операторов кластеров работают вместе, чтобы установить правильные элементы управления безопасностью для конвейеров CD. Эти элементы управления помогают развертывать код в рабочей среде в безопасной и автоматизированной среде.

Наилучшая практика: Контроль доступа и рабочего процесса конвейера развертывания

• Важные ветви можно защитить , задав правила защиты ветви. Эти правила определяют, могут ли сотрудники удалить или принудительно отправить в ветвь. Они также задают требования для отправки изменений в ветвь, например, прохождения проверок статуса или линейной истории коммитов.

• Используйте среды для развертывания для настройки правил защиты и секретов.

• Используйте функцию утверждений и шлюзов для управления рабочим процессом конвейера развертывания. Например, перед развертыванием в рабочей среде можно требовать утверждения вручную из группы безопасности или операций.

Рекомендуемая практика: Безопасные учетные данные развертывания

• OpenID Connect (OIDC) позволяет рабочим процессам GitHub Action получать доступ к ресурсам в Azure без необходимости хранить учетные данные Azure в виде секретов GitHub.

• Используйте подход на основе извлечения к CI/CD с помощью GitOps, чтобы переместить учетные данные безопасности в кластер Kubernetes. Такой подход снижает уровень безопасности и риска, удаляя учетные данные из внешнего инструмента CI. Вы также можете уменьшить разрешенные входящий трафик и ограничить доступ на уровне администратора к кластерам Kubernetes.

Рекомендация. Запуск DAST для поиска уязвимостей в работающем приложении

• Используйте GitHub Actions в рабочих процессах развертывания для выполнения динамических тестов безопасности приложений (DAST).

• Используйте такие средства с открытым кодом, как ZAP , для тестирования на проникновение для распространенных уязвимостей веб-приложений.

Рекомендация. Развертывание образов контейнеров только из доверенных реестров

• Используйте Defender для контейнеров, чтобы включить надстройку политики Azure для Kubernetes.

• Настройте политику Azure для Kubernetes, чтобы ограничить развёртывания образов контейнеров только доверенными реестрами.

Этап работы

На этом этапе выполняйте задачи мониторинга операций и мониторинга безопасности для упреждающего мониторинга, анализа и оповещения о потенциальных инцидентах безопасности. Используйте рабочие средства наблюдения, такие как Azure Monitor и Microsoft Sentinel, для мониторинга и обеспечения соответствия корпоративным стандартам безопасности.

Рекомендуется использовать Defender для облака для автоматического сканирования и мониторинга рабочих конфигураций.

• Выполните непрерывную проверку, чтобы обнаружить смещение в состоянии уязвимости приложения и реализовать процесс исправления и замены уязвимых образов.

• Реализуйте автоматизированный мониторинг конфигурации для операционных систем.

  • Используйте рекомендации по контейнерам в Defender для облака (в разделе "Вычисления и приложения") для выполнения базовых проверок кластеров AKS. Defender для облака отображает все проблемы конфигурации или уязвимости на панели мониторинга.

  • Используйте Defender для облака и следуйте рекомендациям по защите сети, чтобы защитить сетевые ресурсы кластера AKS.

• Проводите оценку уязвимостей для образов, хранящихся в реестре контейнеров.

  • Реализуйте непрерывное сканирование работающих образов в реестре контейнеров, включив Defender for Containers.

Лучшие практики: Держите ваши кластеры Kubernetes обновленными

• Kubernetes часто выпускает новые версии. Поддерживайте стратегию управления жизненным циклом, чтобы кластеры оставались поддерживаемыми и в актуальном состоянии. AKS предоставляет средства для управления обновлениями кластера. Используйте функции планового обслуживания AKS для управления периодом обслуживания и обновлением.

• Обновляйте узлы AKS часто. Azure выпускает еженедельные обновления ОС и среды выполнения. Примените эти обновления автоматически через автоматический режим или вручную с помощью Azure CLI для получения дополнительных элементов управления.

Рекомендация. Использование политики Azure для защиты кластеров AKS и управления ими

• После установки надстройки политики Azure для AKS к кластеру можно применить отдельные определения политик или группы определений политик, которые называются инициативами или наборами политик.

• Используйте встроенные политики Azure для распространенных сценариев, таких как предотвращение запуска привилегированных контейнеров или ограничения внешних IP-адресов в список разрешений. Вы также можете создавать пользовательские политики для конкретных вариантов использования.

• Примените определения политик к кластеру и убедитесь, что политика Azure применяет эти назначения.

• Используйте Gatekeeper для настройки контроллера допуска, который разрешает или запрещает развертывания на основе указанных правил. Azure Policy расширяет возможности Gatekeeper.

• Обеспечение защищённого трафика между рабочими pod'ами с помощью сетевых политик в Azure Kubernetes Service (AKS).

  • Используйте Azure CNI с помощью Cilium в качестве подсистемы политики сети. Cilium использует плоскость передачи данных на основе eBPF и поддерживает политики, собственные для Kubernetes, политику уровня 7 и фильтрацию полного доменного имени (FQDN).

Лучшая практика: Используйте Azure Monitor для непрерывного мониторинга и оповещений

• Используйте Azure Monitor для сбора журналов и метрик из AKS. Собирайте метрики Prometheus с помощью управляемой службы Prometheus от Azure Monitor, запрашивайте журналы контейнеров и платформы в Log Analytics, а также визуализируйте работоспособность кластера с помощью панелей управления Azure Managed Grafana.

  • Azure Monitor расширяет непрерывный мониторинг конвейеров выпуска. Используйте данные мониторинга для утверждения или отката выпусков. Azure Monitor также воспринимает журналы безопасности и оповещения о подозрительных действиях.

  • Подключите экземпляры AKS к Azure Monitor и настройте параметры диагностики для кластера.

    Дополнительные сведения см. в разделе "Базовые показатели безопасности Azure" для AKS.

Рекомендуемая практика: Используйте Defender для облачных сервисов для активного отслеживания угроз

• Защитник для облака обеспечивает активный мониторинг угроз для AKS на уровне узлов (угрозы ВМ) и нагрузки кластера.

• Используйте Defender для DevOps, чтобы получить полную видимость во всех конвейерах CI/CD. Она предоставляет командам безопасности и операторам централизованную панель мониторинга. Эта централизованная видимость особенно полезна при использовании нескольких конвейерных платформ, таких как Azure DevOps и GitHub, или запуск конвейеров в общедоступных облаках.

• Defender для Key Vault обнаруживает необычные и подозрительные попытки доступа к учетным записям хранилища ключей и может отправлять оповещения администраторам на основе конфигурации.

• Defender для контейнеров может предупреждать об уязвимостях, обнаруженных в образах контейнеров, хранящихся в реестре контейнеров.

Лучшая практика: Включите централизованный мониторинг журналов и используйте продукты SIEM для мониторинга угроз безопасности в режиме реального времени

• Подключите журналы диагностики AKS к Microsoft Sentinel для централизованного мониторинга безопасности на основе шаблонов и правил. Microsoft Sentinel обеспечивает этот доступ через соединители данных.

Рекомендуемая практика: Включите ведение журнала аудита для мониторинга активности в рабочих кластерах

• Используйте журналы действий для мониторинга действий в ресурсах AKS для просмотра всех действий и их состояния. Определите, кто выполнял операции с ресурсами.

• Включите ведение журнала запросов системы доменных имен (DNS), применяя документированную конфигурацию в пользовательской конфигурации ConfigMap CoreDNS.

• Отслеживайте попытки доступа к отключенным учетным данным.

  Интегрируйте проверку подлинности пользователей в AKS с Microsoft Entra ID. Создайте параметры диагностики для идентификатора Microsoft Entra и отправьте журналы аудита и входа в рабочую область Log Analytics. В рабочей области Log Analytics настройте оповещения для событий безопасности, например попытки входа из деактивированных учетных записей.

Рекомендация. Включение диагностики в ресурсах Azure

• Включите диагностику Azure во всех ресурсах рабочей нагрузки для доступа к журналам платформы, предоставляющим подробные диагностические и аудитовые сведения. Эти журналы можно использовать в Log Analytics или решение SIEM, например Microsoft Sentinel для мониторинга безопасности и оповещения.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основной автор:

• Аднан Хан | Старший архитектор облачных решений

Другие участники:

• Ayobami Ayodeji | Диспетчер программ 2
• Ахмед Бэм | Старший архитектор облачных решений
• Chad Kittel | Главный инженер по разработке программного обеспечения — Azure Patterns & Practices
• Джон Пул | Старший архитектор облачных решений
• Барам Рашенас | Старший архитектор решений
• Абеда Сау | Старший архитектор облачных решений

Чтобы увидеть непубличные профили в LinkedIn, войдите в LinkedIn.

Дальнейшие действия

• Defender для контейнеров
• Secure DevOps
• Безопасность в DevOps (DevSecOps)
• Расширенная безопасность GitHub

Связанные ресурсы

• GitOps
• DevSecOps для IaC
• Сдвиг влево