Рекомендации по безопасности для экземпляров контейнеров Azure

  • Статья

В этой статье рассматриваются вопросы безопасности при использовании службы "Экземпляры контейнеров Azure" для запуска контейнерных приложений. Разделы включают:

  • Рекомендации по безопасности для управления образами и секретами для экземпляров контейнеров Azure
  • Рекомендации для экосистемы контейнеров в течение жизненного цикла контейнера для любой контейнерной платформы

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

Рекомендации по безопасности для службы "Экземпляры контейнеров Azure"

Использование частного реестра

Контейнеры состоят из образов, которые хранятся в одном или нескольких репозиториях. Эти репозитории могут принадлежать общедоступному реестру, например Docker Hub, или частному реестру. Примером частного реестра является Docker Trusted Registry, который можно установить локально или в виртуальном частном облаке. Существуют также частные облачные службы реестров контейнеров, включая Реестр контейнеров Azure.

Общедоступный образ контейнера не гарантирует безопасность. Образы контейнеров состоят из нескольких программных слоев, у каждого из которых могут быть свои уязвимости. Чтобы снизить опасность атак, следует хранить и извлекать образы из частного реестра, например реестра контейнеров Azure или доверенного реестра Docker. Помимо предоставления управляемого частного реестра, Реестр контейнеров Azure поддерживает проверку подлинности на основе субъекта-службы с помощью идентификатора Microsoft Entra для основных потоков проверки подлинности. Такая проверка подлинности предусматривает доступ на основе ролей в режимах только для чтения (извлечения) или записи (отправки), а также другие виды разрешений.

Мониторинг и сканирование образов контейнеров

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

Например, Реестр контейнеров Azure при необходимости интегрируется с Microsoft Defender для облака, чтобы автоматически проверять все образы Linux, отправляемые в реестр. Встроенное средство проверки Qualys в Microsoft Defender для облака обнаруживает уязвимости образа, классифицирует их и предоставляет рекомендации по исправлению.

Решения для мониторинга безопасности и сканирования образов, такие как Twistlock и Безопасность Aqua, также доступны в Azure Marketplace.

Защита учетных данных

Контейнеры могут распределяться по нескольким кластерам и регионам Azure. Поэтому следует защитить учетные данные, необходимые для входа в систему или доступа к API, такие как пароли или токены. Убедитесь, что только привилегированные пользователи могут получить доступ к этим контейнерам в ходе их передачи и во время хранения. Выполните инвентаризацию всех секретных учетных данных, а затем потребуйте, чтобы разработчики использовали новые инструменты для управления секретными данным, предназначенные для платформ контейнеров. Убедитесь, что решение включает зашифрованные базы данных, TLS-шифрование для секретных данных при передаче и управление доступом на основе ролей Azure (Azure RBAC) с минимальными правами доступа. Хранилище ключей Azure — это облачная служба, которая обеспечивает защиту секретов и ключей шифрования (например, сертификатов, строк подключения и паролей) для контейнерных приложений. Поскольку это конфиденциальные данные, критически важные для бизнеса, необходимо обеспечить защиту доступа к хранилищу ключей, чтобы к ним доступ могли получить только авторизованные приложения и пользователи.

Рекомендации для экосистемы контейнеров

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

Использование управления уязвимостями в рамках жизненного цикла разработки контейнеров

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

Проверка на уязвимости

Новые уязвимости обнаруживаются постоянно, поэтому поиск и идентификация уязвимостей — это непрерывный процесс. Включение проверки уязвимостей в жизненный цикл контейнера

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

Сопоставление уязвимостей образов с работающими контейнерами

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

Убедитесь, что в вашей среде используются только утвержденные образы

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

Эффективным вариантом снижения уязвимости и предотвращения критических ошибок безопасности для разработчиков является управление потоком образов контейнеров в среде разработки. Например, вы можете обозначить отдельный дистрибутив Linux как базовый образ, лучше, чтобы он был экономичным (Alpine или CoreOS, а не Ubuntu), это сокращает поверхность потенциальных атак.

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

Разрешите использовать только утвержденные реестры

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

Обеспечение целостности образов в течение жизненного цикла

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

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

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

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

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

  • Используйте конвейер непрерывной интеграции (CI) со встроенной проверкой безопасности, это позволит создавать защищенные образы и отправлять их в частный реестр конвейеров. Сканирование уязвимостей, встроенное в решение непрерывной интеграции, обеспечивает отправку прошедших все проверки образов в частный реестр, из которого развертываются производственные рабочие нагрузки.

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

Принудительное использование самого низкого уровня привилегий в среде выполнения

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

Сокращение направлений атак на контейнер с помощью удаления ненужных привилегий

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

Предварительное утверждение файлов и исполняемых объектов, которые имеют доступ к контейнеру

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

Управлять безопасным списком гораздо проще, если он используется с самого начала. Безопасный список обеспечивает контроль и управляемость, поскольку вы узнаете, какие файлы и исполняемые объекты необходимы для правильной работы приложения.

Такой список не только сужает возможности для атак, но и может предоставлять базовые показатели аномалий и предотвращать варианты использования по принципу "шумного соседа" и сценарии разрушения контейнера.

Принудительное применение сегментации сети в работающих контейнерах

Чтобы защитить контейнеры в одной подсети от угроз безопасности их другой подсети, настройте сегментацию сети (или нано-сегментацию) или разделение работающих контейнеров. Поддержка сегментации сети также может пригодиться для использования контейнеров в отраслях, в которых необходимо соответствовать мандатам.

Например, партнерский инструмент Aqua предлагает автоматизированный подход к нано-сегментации. Этот инструмент отслеживает действия сети контейнера в среде выполнения. Он определяет все входящие и исходящие сетевые подключения к другим контейнерам, службам, IP-адресам и общедоступному Интернету. Сегментация проводится автоматически на основе наблюдаемого трафика.

Мониторинг активности контейнера и доступа пользователей

Как и в случае с любой ИТ-средой, следует постоянно отслеживать доступ пользователей и действий к экосистеме контейнеров, чтобы можно было быстро выявить подозрительные и вредоносные действия. Azure предлагает решения для мониторинга контейнеров, в том числе следующее.

  • Azure Monitor для контейнеров отслеживает производительность рабочих нагрузок, развернутых в средах Kubernetes в Службе Azure Kubernetes (AKS). С помощью Azure Monitor для контейнеров можно отслеживать производительность, собирая данные метрик памяти и процессора из контроллеров, узлов и контейнеров, доступных в Kubernetes, используя API метрик.

  • Решение для мониторинга контейнеров Azure позволяет централизованно просматривать узлы контейнеров Docker и Windows, находящихся в одном расположении, а также управлять ими. Например:

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

    Решение поддерживает оркестраторы контейнеров, включая Docker Swarm, DC/OS, неуправляемую среду Kubernetes, Microsoft Azure Service Fabric и Red Hat OpenShift.

Мониторинг активности ресурсов контейнера

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

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

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

Ведение журнала доступа всех пользователей с правами администратора для аудита

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

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