DevSecOps на Служба Azure Kubernetes (AKS)

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

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

При применении DevSecOps к Служба Azure Kubernetes (AKS) различные роли организации могут иметь различные рекомендации по реализации безопасности. Примерами этих различных ролей организации являются:

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

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

В качестве предварительных требований для этой статьи рекомендуется просматривать сборку и развертывание приложений в AKS с помощью DevOps и GitOps.

Последовательность операций процесса

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

1. Идентификатор Microsoft Entra настроен в качестве поставщика удостоверений для 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. Вы можете ввести утверждения вручную для развертываний в определенных средах, таких как рабочая среда, как часть рабочего процесса непрерывной доставки (CD) в GitHub Actions.
8. GitHub Actions включает CD в AKS. Используйте GitHub Advanced Security для обнаружения секретов, учетных данных и других конфиденциальных данных в файлах источника и конфигурации приложения.
9. Microsoft Defender используется для сканирования Реестр контейнеров Azure, кластера AKS и Azure Key Vault для уязвимостей безопасности.
   1. Microsoft Defender для контейнеров проверяет образ контейнера на наличие известных уязвимостей безопасности при отправке в реестр контейнеров.
   2. Вы также можете использовать Defender для контейнеров для проверки среды AKS и обеспечить защиту от угроз во время выполнения для кластеров AKS.
   3. Microsoft Defender для Key Vault обнаруживает вредоносные и необычные подозрительные попытки доступа к учетным записям хранилища ключей.
10. Политика Azure можно применить к реестру контейнеров и Служба Azure Kubernetes (AKS) для соответствия политик и принудительного применения. Общие политики безопасности для реестра контейнеров и AKS создаются для быстрого включения.
11. Azure Key Vault используется для безопасного внедрения секретов и учетных данных в приложение во время выполнения, разделяя конфиденциальную информацию от разработчиков.
12. Подсистема сетевой политики AKS настроена для защиты трафика между модулями pod приложений с помощью политик сети Kubernetes.
13. Непрерывный мониторинг кластера AKS можно настроить с помощью Azure Monitor и аналитики контейнеров для приема метрик производительности и анализа журналов безопасности приложений и безопасности.
    1. Аналитика контейнеров извлекает метрики производительности и журналы приложений и кластеров.
    2. Журналы диагностики и приложений извлекаются в рабочую область Azure Log Analytics для выполнения запросов журналов.
14. Microsoft Sentinel, который является решением для управления безопасностью и событиями (SIEM), можно использовать для приема и дальнейшего анализа журналов кластера AKS для любых угроз безопасности на основе определенных шаблонов и правил.
15. Средства с открытым исходным кодом, такие как Zed Attack Proxy (ZAP) (ZAP) можно использовать для тестирования на проникновение для веб-приложений и служб.
16. Defender для DevOps, доступная в Defender для облака, позволяет группам безопасности управлять безопасностью DevOps в нескольких средах конвейеров, включая GitHub и Azure DevOps.

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап плана

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

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

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

Рекомендации. Создание моделирования угроз в процессе

• Моделирование угроз обычно представляет собой ручное действие, включающее команды безопасности и разработки. Он используется для моделирования и поиска угроз в системе, чтобы уязвимости могли быть устранены до любой разработки кода или изменений в системе. Моделирование угроз может происходить в разное время, активируется такими событиями, как значительное изменение программного обеспечения, изменение архитектуры решения или инциденты безопасности.
• Мы рекомендуем использовать модель угроз STRIDE. Эта методология начинается с схемы потока данных и использует категории угроз STRIDE mnemonic (spoofing, tampering, Info Disclosure, Repudiation, Отказ в обслуживании и повышение привилегий), чтобы предоставить группам возможность определять, устранять и проверять риски. Она также включает средство моделирования для нотации и визуализации системных компонентов, потоков данных и границ безопасности. Создание моделирования угроз в процессах SDLC представляет новые процессы и больше работы для поддержания обновленных моделей угроз. Но это помогает обеспечить безопасность на ранних этапах, что помогает снизить потенциальные затраты на решение проблем безопасности, обнаруженных на последующих этапах SDLC.

Рекомендация. Применение Azure Well Architect Framework (WAF)

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

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

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

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

• Используя установленные рекомендации по безопасному написанию кода и списки проверка, вы можете защитить код от распространенных уязвимостей, таких как внедрение и небезопасный дизайн. Фонд OWASP публикует отраслевые рекомендации по безопасному кодированию, которые следует применять при написании кода. Эти рекомендации особенно важны при разработке общедоступных веб-приложений или служб.
• Помимо общих рекомендаций по обеспечению безопасности, следует также ознакомиться с рекомендациями по безопасному программированию для определенных сред выполнения языка программирования, таких как Java и .NET.
• Вы можете применить стандарты ведения журнала для защиты конфиденциальной информации от утечки в журналы приложений. Наиболее популярные платформы ведения журнала, такие как log4j и log4net, предоставляют фильтры и подключаемые модули для маскирования конфиденциальных данных, таких как номера учетных записей или персональные данные.

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

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

• SonarLint — это подключаемый модуль интегрированной среды разработки, доступный для большинства популярных языков и сред разработчика. SonarLint предоставляет ценные отзывы и автоматически сканирует код для распространенных ошибок программирования и потенциальных проблем безопасности.
• Другие бесплатные и коммерческие подключаемые модули сосредоточены на определенных элементах безопасности, таких как основные уязвимости OWASP 10 распространенных уязвимостей. Подключаемый модуль Synk , например, сканирует исходные и сторонние зависимости приложений и предупреждает вас, если обнаружены какие-либо уязвимости.
• Подключаемый модуль "Формат обмена статическими результатами анализа" (SARIF) для Visual Studio и Visual Studio Code позволяет легко просматривать уязвимости из популярных средств статического тестирования безопасности приложений (SAST) интуитивно понятным и простым для чтения и интерпретации результатов из необработанных выходных файлов JSON.

Рекомендация. Создание элементов управления в репозиториях исходного кода

• Создайте методологию ветвления, чтобы обеспечить согласованное использование ветвления на предприятии. Методологии, такие как поток выпуска и поток GitHub, имеют структурированные рекомендации по использованию ветвей для поддержки команды и параллельной разработки. Эти методологии помогают командам устанавливать стандарты и элементы управления фиксацией кода и объединять их в рабочий процесс CI/CD.
• Некоторые ветви, такие как main, являются долгосрочными ветвями, которые сохраняют целостность исходного кода приложения. Эти ветви должны быть установлены политики слияния, прежде чем изменения могут быть объединены или зафиксированы в них. Ниже приведены рекомендации.
  • Запретить другим разработчикам фиксацию кода непосредственно в главной ветви.
  • Установите процесс одноранговой проверки и требует минимального количества утверждений, прежде чем изменения можно объединить с основной ветвью. Вы можете легко настроить и применить эти элементы управления с помощью GitHub. GitHub также позволяет назначать группы авторизованных утверждающих, если это необходимо для воротных сред.
• Используйте перехватчики предварительной фиксации, чтобы проверка для конфиденциальной информации в исходном коде приложения и предотвратить фиксацию при обнаружении проблемы с безопасностью.
  • Используйте встроенные перехватчики предварительной фиксации GitHub, которые можно легко настроить для определенного проекта. Например, есть предварительно созданные перехватчики для проверки секретов, закрытых ключей и учетных данных, а также предотвращения фиксации при обнаружении каких-либо из этих проблем.
• Установите управление доступом на основе ролей в системе управления версиями.
  • Создайте четко определенные роли с помощью принципа наименьших привилегий. Конвейер CI/CD — это цепочка поставок для производственных развертываний.
  • Применение установленных ролей пользователей или групп в организации. Роли, такие как Администратор, разработчик, администратор безопасности и оператор, должны быть созданы для группирования отдельных лиц на основе их конкретной роли и функции в отношении рабочих процессов CI/CD.
• Включите аудит рабочих процессов, чтобы обеспечить прозрачность и трассировку для конфигурации и других изменений в отношении конвейеров CI/CD.

Рекомендации. Защита образов контейнеров

• Используйте упрощенные образы с минимальным объемом операционной системы, чтобы уменьшить общую область атаки на поверхность. Рассмотрите минимальные образы, такие как Alpine или даже бессистемные образы, содержащие только приложение и связанную среду выполнения. Mariner, дистрибутив Linux с открытым исходным кодом Майкрософт, является упрощенным, защищенным дистрибутивом, предназначенным для AKS для размещения контейнерных рабочих нагрузок.
• При создании контейнеров используйте только доверенные базовые образы. Эти базовые образы должны быть получены из частного реестра, который часто сканируется на наличие уязвимостей.
• Используйте средства разработчика для оценки уязвимостей образа локально.
  • Trivy — это пример средства с открытым исходным кодом, который можно использовать для анализа уязвимостей безопасности в образах контейнеров.
• Запретить корневому пользователю доступ или контекст для изображения. По умолчанию контейнеры выполняются в качестве корневого каталога.
  • Для контейнеров, требующих повышенной безопасности, рекомендуется использовать профиль AppArmor в кластере Kubernetes, чтобы обеспечить безопасность запущенных контейнеров.

Этап сборки

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

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

• Используйте возможности проверки расширенной безопасности GitHub для сканирования кода и CodeQL.
  • Сканирование кода — это функция, используемая для анализа кода в репозитории GitHub для поиска уязвимостей безопасности и ошибок кода. Все проблемы, выявленные анализом, отображаются в GitHub Enterprise Cloud.
  • Если сканирование кода находит потенциальную уязвимость или ошибку в коде, GitHub отображает оповещение в репозитории.
  • Можно также настроить правила ветви для обязательная проверка состояния, например, чтобы обеспечить актуальность ветвь компонента базовая ветвь перед слиянием любого нового кода. Эта практика гарантирует, что ваша ветвь всегда тестируется с помощью последнего кода.
• Используйте такие средства, как kube-score , для анализа объектов развертывания Kubernetes.
  • Kube-score — это средство, которое выполняет статический анализ кода определений объектов Kubernetes.
  • Выходные данные — это список рекомендаций, которые можно улучшить, чтобы сделать приложение более безопасным и устойчивым.

Рекомендуется выполнить сканирование секретов, чтобы предотвратить мошенническое использование секретов, которые были случайно зафиксированы в репозитории.

• Если для репозитория включена проверка секретов, GitHub сканирует код для шаблонов, соответствующих секретам, используемым многими поставщиками услуг.
• GitHub также периодически выполняет полную проверку журнала git существующего содержимого в репозиториях и отправляет уведомления об оповещениях.
  • Для Azure DevOps Defender для облака использует проверку секретов для обнаружения учетных данных, секретов, сертификатов и другого конфиденциального содержимого в исходном коде и выходных данных сборки.
  • Сканирование секретов можно выполнять как часть расширения Microsoft Security DevOps для Azure DevOps.

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

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

Рекомендация. Включение проверок безопасности шаблонов инфраструктуры как кода (IaC) для минимизации неправильной настройки облака, достигающей рабочих сред.

• Заранее отслеживайте конфигурации облачных ресурсов на протяжении всего жизненного цикла разработки.
• Microsoft Defender для DevOps поддерживает репозитории GitHub и Azure DevOps.

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

• Defender для контейнеров сканирует контейнеры в реестре контейнеров и Реестре эластичных контейнеров Amazon AWS (ECR), чтобы уведомить вас об известных уязвимостях в образах.
• Политика Azure можно включить для оценки уязвимостей на всех образах, хранящихся в реестре контейнеров, и предоставить подробные сведения о каждом обнаружении.

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

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

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

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

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

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

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

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

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

• OpenID Подключение (OIDC) позволяет рабочим процессам GitHub Action получать доступ к ресурсам в Azure без необходимости хранить учетные данные Azure в виде секретов GitHub.
• Используя среды для развертывания, можно настроить среды с правилами и секретами защиты.
  • Подход на основе извлечения к CI/CD с помощью GitOps позволяет перемещать учетные данные безопасности в кластер Kubernetes, что снижает уровень безопасности и риска, удаляя учетные данные из внешнего средства CI. Вы также можете уменьшить разрешенные входящий трафик и ограничить доступ на уровне администратора к кластерам Kubernetes.

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

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

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

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

Этап работы

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

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

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

Рекомендация. Обновление кластеров Kubernetes

• Выпуски Kubernetes часто развертываются. Важно иметь стратегию управления жизненным циклом, чтобы гарантировать, что вы не отстаете от поддержки и не поддерживаете. AKS — это управляемое предложение, которое предоставляет средства и гибкость для управления этим процессом обновления. Вы можете использовать функции планового обслуживания платформы AKS, чтобы иметь больше контроля над окнами обслуживания и обновлениями.
• Рабочие узлы AKS следует обновлять чаще. Мы предоставляем еженедельные обновления ОС и среды выполнения, которые можно применять автоматически с помощью автоматического режима или с помощью Azure CLI для более эффективного управления и комплексных обновлений.

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

• После установки надстройки Политика Azure для AKS можно применить к кластеру отдельные определения политик или группы определений политик, называемых инициативами (также называемыми наборами политик).
• Используйте встроенные политики Azure для распространенных сценариев, таких как предотвращение запуска привилегированных контейнеров или утверждение только разрешенных внешних IP-адресов. Вы также можете создавать пользовательские политики для конкретных вариантов использования.
• Применение определений политик к кластеру и проверка применения этих назначений.
• Используйте Gatekeeper для настройки контроллера допуска, который разрешает или запрещает развертывания на основе указанных правил. Политика Azure расширяет gatekeeper.
• Защита трафика между модулями pod рабочей нагрузки с помощью политик сети в AKS.
  • Установите подсистему политики сети и создайте политики сети Kubernetes для управления потоком трафика между модулями pod в AKS. Сетевая политика может использоваться для узлов и модулей pod под управлением Linux в AKS.

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

• Используйте Azure Monitor для сбора журналов и метрик из AKS. Вы получаете аналитические сведения о доступности и производительности приложения и инфраструктуры. Он также предоставляет доступ к сигналам для мониторинга работоспособности решения и выявления аномальных действий на ранних этапах.
  • Непрерывный мониторинг с помощью Azure Monitor расширяется на выпуск конвейеров для шлюза или отката выпусков на основе данных мониторинга. Azure Monitor также выполняет прием журналов безопасности и может предупреждать о подозрительных действиях.
  • Подключение экземпляров AKS к Azure Monitor и настройка параметров диагностики для кластера.
    • См. базовые показатели безопасности Azure для Служба Azure Kubernetes.

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

• Microsoft Defender для облака обеспечивает активный мониторинг угроз в AKS на уровне узла (угрозы виртуальной машины) и для внутренних элементов.
• Defender для DevOps должен использоваться для комплексной видимости и обеспечивает безопасность и операторы с централизованной панелью мониторинга для всех конвейеров CI/CD. Эта функция особенно полезна, если вы используете много конвейерные платформы, такие как Azure DevOps и GitHub, или выполняете конвейеры в общедоступных облаках.
• Defender для Key Vault можно использовать для обнаружения необычных подозрительных попыток доступа к учетным записям хранилища ключей и может предупреждать администраторов на основе конфигурации.
• Defender для контейнеров может предупреждать об уязвимостях, обнаруженных в образах контейнеров, хранящихся в реестре контейнеров.

Рекомендация. Включение централизованного мониторинга журналов и использование продуктов SIEM для мониторинга угроз безопасности в режиме реального времени

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

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

• Используйте журналы действий для мониторинга действий в ресурсах AKS для просмотра всех действий и их состояния. Определите, какие операции были выполнены для ресурсов и кем.
• Включите ведение журнала запросов DNS, применяя документированную конфигурацию в пользовательской конфигурации ConfigMap CoreDNS.
• Отслеживайте попытки доступа к отключенным учетным записям.
  • Интеграция проверки подлинности пользователей для AKS с идентификатором Microsoft Entra. Создайте диагностические Параметры для идентификатора Microsoft Entra, отправляя журналы аудита и входа в рабочую область Azure Log Analytics. Настройте нужные оповещения (например, когда деактивированная учетная запись пытается войти) в рабочей области Azure Log Analytics.

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

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Автор субъекта:

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

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

• Ayobami Ayodeji | Диспетчер программ 2
• Ахмед Bham | Старший архитектор облачных решений
• Чад Киттель | Главный инженер программного обеспечения
• Джон Пул | Старший архитектор облачных решений
• Барам Рашенас | Старший архитектор решений
• Abed Sau | Старший архитектор облачных решений

Следующие шаги

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

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

• DevSecOps для инфраструктуры в виде кода (IaC)
• Сдвиг влево