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

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

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

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

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

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

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

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

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

1. Azure Active Directory (Azure AD) настроен в качестве поставщика удостоверений для 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 и Key Vault Azure на наличие уязвимостей системы безопасности.
   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. Open-Source средства, такие как Open Web Application Security Project (OWASP 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 (спуфинг, незаконное изменение, раскрытие информации, отказ в обслуживании, отказ в обслуживании и повышение привилегий), чтобы дать командам возможность выявлять, устранять и проверять риски. Он также включает средство моделирования для нотации и визуализации компонентов системы, потоков данных и границ безопасности. Создание моделировать угрозы в процессы 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 предоставляет ценные отзывы и автоматически проверяет код на наличие распространенных ошибок программирования и потенциальных проблем с безопасностью.
• Другие бесплатные и коммерческие подключаемые модули ориентированы на элементы безопасности, такие как 10 распространенных уязвимостей OWASP. Подключаемый модуль Synk , например, также проверяет исходные и сторонние зависимости приложения и оповещает вас при обнаружении уязвимостей.
• Подключаемый модуль SARIF для Visual Studio и Visual Studio Code позволяет легко просматривать уязвимости из популярных средств тестирования безопасности статических приложений (SAST) интуитивно понятным и понятным способом по сравнению с интерпретацией результатов из необработанных выходных файлов JSON.

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

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

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

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

Этап сборки

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

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

• Используйте GitHub Advanced Security возможности сканирования кода и 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 Connect (OIDC) позволяет рабочим процессам GitHub Action получать доступ к ресурсам в Azure без необходимости хранить учетные данные Azure как долговременные секреты GitHub.
• Используя среды для развертывания, можно настроить среды с правилами и секретами защиты.
  • Подход к CI/CD на основе извлечения с помощью GitOps позволяет перенести учетные данные безопасности в кластер Kubernetes, что снижает уровень безопасности и риск, удаляя учетные данные из хранения во внешних инструментах CI. Вы также можете уменьшить разрешенные входящие подключения и ограничить доступ на уровне администратора к кластерам Kubernetes.

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

• Используйте GitHub Actions в рабочих процессах развертывания для запуска динамических тестов безопасности приложений (DAST).
• Используйте средства с открытым кодом, такие как OWASP 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 расширяет привратник.
• Защита трафика между модулями pod рабочей нагрузки с помощью политик сети в AKS.
  • Установите подсистему политики сети и создайте политики сети Kubernetes для управления потоком трафика между модулями pod в AKS. Сетевую политику можно использовать для узлов и модулей pod под управлением Linux или Windows в 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 с Azure Active Directory (Azure AD). Создайте параметры диагностики для Azure AD, отправляя журналы аудита и входа в рабочую область Azure Log Analytics. Настройка требуемых оповещений (например, при попытке входа отключенной учетной записи) в рабочей области Azure Log Analytics.

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

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

Соавторы

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

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

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

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

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

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

• Microsoft Defender для облака
• Безопасность в DevOps
• Безопасность в DevOps (DevSecOps)
• GitHub Advanced Security
• GitOps

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

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