Архитектура регулируемых кластеров AKS для PCI-DSS 3.2.1 (часть 2 из 9)

В этой статье описывается эталонная архитектура для кластера Служба Azure Kubernetes (AKS), на котором выполняется рабочая нагрузка в соответствии со стандартом безопасности данных индустрии платной карты (PCI-DSS 3.2.1). Эта архитектура ориентирована на инфраструктуру, а не рабочую нагрузку PCI-DSS 3.2.1.

Этот материал входит в цикл статей. Ознакомьтесь с введением.

Рекомендации и примеры извлекаются из этой сопровождающей эталонной реализации:

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

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

Эта сетевая архитектура основана на топологии концентратора. Виртуальная сеть концентратора содержит брандмауэр для управления исходящим трафиком, трафиком шлюза из локальных сетей и третьей сетью для доступа к кластеру SRE (инженер надежности сайта). Существует две периферийные виртуальные сети. Одна периферия содержит кластер AKS, который является компонентом среды карта-держателя (CDE) и размещает рабочую нагрузку PCI DSS. Другой периферийный сервер создает образы виртуальных машин, используемые для управляемого доступа SRE к среде.

Компоненты

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

Брандмауэр Azure

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

Бастион Azure

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

Средство создания образов Azure

Подготовленный в отдельной виртуальной сети, он создает образы виртуальных машин с базовой безопасностью и конфигурацией. В этой архитектуре он настраивается для создания защищенных образов узлов с помощью таких средств управления, как Azure CLI, kubectlи предварительно установленного интерфейса командной строки Flux.

Azure Масштабируемые наборы виртуальных машин для экземпляров прыжков

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

Шлюз приложений Azure с интегрированными Брандмауэр веб-приложений (WAF)

Шлюз приложений Azure балансировки нагрузки на уровне 7. WAF защищает входящие трафик от распространенных атак веб-трафика. Экземпляр имеет общедоступную IP-конфигурацию внешнего интерфейса, которая получает запросы пользователей.

Служба Azure Kubernetes (AKS)

Инфраструктура размещения, которая является ключевой частью среды данных карта заполнителей (CDE). Кластер AKS развертывается как частный кластер. Таким образом, сервер API Kubernetes не предоставляется общедоступному Интернету, а трафик к серверу API ограничен частной сетью.

Задачи ACR

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

Azure Key Vault

Хранит и управляет секретами, необходимыми для операций кластера, таких как сертификаты и ключи шифрования.

Конфигурация кластера

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

Сегментация пула узлов

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

Для PCI-DSS 3.2.1 требуется изоляция рабочей нагрузки PCI из других рабочих нагрузок с точки зрения операций и подключения.

• В область: рабочая нагрузка PCI, среда, в которой она находится, и операции.

• Вне область: другие рабочие нагрузки, которые могут совместно использовать службы, но изолированы от область компонентов.

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

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

Контроллер входящего трафика

Контроллер входящего трафика Kubernetes внутри кластера был изменен на NGINX. В базовой архитектуре используется Traefik. Это изменение иллюстрирует, что этот компонент можно изменить на основе требований рабочих нагрузок.

Частный сервер API Kubernetes

Базовая архитектура развернула кластер AKS в общедоступном режиме. Это означает, что все взаимодействие с сервером API Kubernetes, управляемым AKS, осуществляется через общедоступный Интернет. Это недопустимо в этой архитектуре, так как PCI-DSS 3.2.1 запрещает общедоступное воздействие на любые системные компоненты. В этой регламентированной архитектуре кластер развертывается как частный кластер. Сетевой трафик к серверу API Kubernetes ограничен частной сетью. Сервер API предоставляется через частную конечную точку в сети кластера. Безопасность дополнительно улучшается с использованием групп безопасности сети и других встроенных функций. Они описаны в конфигурации сети.

Безопасность объектов pod

При описании потребностей в безопасности рабочей нагрузки используйте соответствующие securityContext параметры для контейнеров. Это включает в себя основные параметры, такие как fsGroup,runAsGrouprunAsUser / и значение allowPrivilegeEscalation false (если это не требуется). Будьте ясны о определении и удалении возможностей Linux и определении параметров SELinux в seLinuxOptions.

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

Конфигурации сети

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

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

Безопасность подсети с помощью групп безопасности сети (NSG)

Существует несколько групп безопасности сети, которые управляют потоком и выходом из кластера. Далее приводятся некоторые примеры.

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

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

  • Разрешен только трафик HTTPS.
  • Трафик из плоскости управления Azure разрешен. Дополнительные сведения см. в разделе "Разрешить доступ к нескольким исходным IP-адресам".

• В подсетях, имеющих агенты Реестр контейнеров Azure, группы безопасности сети разрешают только необходимый исходящий трафик. Например, трафик разрешен к Azure Key Vault, идентификатору Microsoft Entra, Azure Monitor и другим службам, с которыми должен взаимодействовать реестр контейнеров.

• Подсеть с полем перехода предназначена для операций управления. Правило NSG разрешает доступ К SSH только из Бастиона Azure в концентраторе и ограниченные исходящие подключения. Флажки перехода не имеют универсального доступа к Интернету и управляются как в подсети NSG, так и в Брандмауэр Azure.

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

Безопасность pod -to-pod с помощью политик сети

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

Примеры сетей нулевого доверия в качестве концепции демонстрируются в реализации в a0005-i пространствах имен, a0005-o предоставляемых пользователем. Все пространства имен рабочей нагрузки должны применяться строгие ограничения NetworkPolicy. Определения политик будут зависеть от модулей pod, выполняемых в этих пространствах имен. Убедитесь, что вы учитываете готовность, живость и пробы запуска, а также пособие на метрики, собранные агентом Log Analytics. Рекомендуется стандартизировать порты между рабочими нагрузками, чтобы обеспечить согласованный сетевой политики и Политика Azure для разрешенных портов контейнеров.

В некоторых случаях это не является практическим для взаимодействия в кластере. Не все предоставленные пользователем пространства имен могут использовать сеть нулевого доверия (например, cluster-baseline-settings не удается использовать ее).

Шифрование TLS

Базовая архитектура обеспечивает зашифрованный tls трафик до тех пор, пока контроллер входящего трафика в кластере, но обмен данными между модулями pod находится в ясном режиме. В этой архитектуре TLS распространяется на трафик pods-to-pod с проверкой центра сертификации (ЦС). Этот протокол TLS предоставляется сеткой служб, которая применяет подключения mTLS и проверку перед разрешением связи.

Реализация использует mTLS. Поддержка mTLS может быть реализована с сеткой службы или без нее. Если вы используете сетку, убедитесь, что она совместима с издателем сертификата вашего выбора. Эта реализация использует Open Service Mesh.

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

Ограничения сети Azure Key Vault

Все секреты, ключи и сертификаты хранятся в Azure Key Vault. Key Vault обрабатывает задачи управления сертификатами, такие как смена. Обмен данными с Key Vault выполняется Приватный канал Azure. Запись DNS, связанная с Key Vault, находится в частной зоне DNS, чтобы ее нельзя было разрешить из Интернета. Хотя это повышает безопасность, существуют некоторые ограничения.

Шлюз приложений Azure не поддерживает сертификаты TLS для прослушивателя HTTP из экземпляров Key Vault, предоставляемых Приватный канал. Таким образом, реализация развертывает Key Vault в гибридной модели. Он по-прежнему использует Приватный канал для подключений, поддерживающих его, но также разрешает общедоступный доступ для интеграции Шлюз приложений. Если этот гибридный подход не подходит для развертывания, переместите процесс управления сертификатами в Шлюз приложений. Это приведет к добавлению затрат на управление, но экземпляр Key Vault будет полностью изолирован. Для получения дополнительных сведений см.:

• интеграция Шлюз приложений Azure и Key Vault
• Создайте шлюз приложений с завершением TLS с помощью Azure CLI.

Защита от атак DDoS

Включите защиту сети DDoS Azure для виртуальных сетей с подсетью, содержащей Шлюз приложений с общедоступным IP-адресом. Это позволяет защитить инфраструктуру и рабочую нагрузку от массовых мошеннических запросов. Такие запросы могут привести к нарушению работы службы или маскировки другой параллельной атаки. Служба DDoS Azure имеет значительную стоимость и обычно амортизируется во многих рабочих нагрузках, охватывающих множество IP-адресов. Обратитесь к группе сети, чтобы координировать охват рабочей нагрузки.

Управление доступом к удостоверениям

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

Свести к минимуму постоянный доступ, особенно для учетных записей с высоким уровнем влияния, таких как взаимодействие SRE/Ops с кластером. Плоскость управления AKS поддерживает JIT и политики условного доступа Microsoft Entra ID Privileged Access Management (PAM),а также политики условного доступа, что обеспечивает дополнительные уровни требуемой проверки подлинности для привилегированного доступа на основе правил, которые вы создаете.

Дополнительные сведения об использовании PowerShell для настройки условного доступа см. в статье New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy и Remove-MgIdentityConditionalAccessPolicy.

Шифрование дисков

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

диски служба хранилища

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

Дополнительные сведения см. в статье "Перенос собственных ключей( BYOK) с дисками Azure.

Рассмотрите возможность использования BYOK для любых других дисков, которые могут взаимодействовать с кластером, например с прямоугольниками перехода с интерфейсом Бастиона Azure. При выборе BYOK номер SKU для виртуальных машин и региональной доступности будет ограничен, так как эта функция не поддерживается во всех номерах SKU или регионах.

Узлы виртуальных машин

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

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

Эти функции можно применить с помощью Политика Azure.

Резервные копии кластера (состояние и ресурсы)

Если для рабочей нагрузки требуется хранилище в кластере, у вас есть надежный и безопасный процесс резервного копирования и восстановления. Рассмотрим такие службы, как Azure Backup (для дисков Azure и Файлы Azure), для резервного копирования и восстановления любогоPersistantVolumeClaim. Существуют преимущества, если система резервного копирования поддерживает собственные ресурсы Kubernetes. Вы можете дополнить основной метод, который примиряет кластер с известным состоянием с системой резервного копирования для критически важных методов восстановления системы. Например, это может помочь в обнаружении смещения и изменении состояния системы каталогизации со временем на уровне ресурсов Kubernetes.

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

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

рекомендации по Политика Azure

Как правило, примененные политики Azure не имеют параметров, настроенных на рабочую нагрузку. В реализации мы применяем ограниченные стандарты безопасности pod кластера Kubernetes для инициативы рабочих нагрузок на основе Linux, которая не позволяет настраивать параметры. Рассмотрите возможность экспорта этой инициативы и настройки его значений для конкретной рабочей нагрузки. Вы можете включить все политики Azure Gatekeeper deny в одну настраиваемую инициативу и все audit политики Azure в рамках другой инициативы. Это позволяет классифицировать действия из политик, доступных только для информации.

Рассмотрите возможность включения gatekeeper-systemkube-system пространств имен и пространств имен в политики аудита для добавления видимости. Включение этих пространств имен в политики запрета может привести к сбою кластера из-за неподдерживаемой конфигурации.

Вы можете применить шифрование данных, задав некоторые оповещения Политика Azure. Например, вы можете применить BYOK с оповещением, которое обнаруживает кластеры, не имеющиеся diskEncryptionSetID в ресурсе кластера. Другая политика может определить, включена agentPoolProfilesли шифрование на основе узла. Эталонная реализация не использует диски в кластере, а диск операционной системы является временным. Оба этих примера политик используются в качестве напоминания о функции безопасности. Для политик задано auditзначение , а не block.

Управление изображениями

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

Реестр контейнеров Azure поддерживает изображения, соответствующие требованиям Спецификация формата изображения Open Container Initiative (OCI). Это, в сочетании с контроллером допуска, поддерживающим проверку подписей, может гарантировать, что вы выполнили только образы, подписанные с помощью закрытых ключей. Существуют решения с открытым кодом, такие как SSE Connaisseur или IBM Portieris, которые интегрируют эти процессы.

Защита образов контейнеров и других артефактов OCI, так как они содержат интеллектуальную собственность организации. Используйте ключи, управляемые клиентом, и зашифруйте содержимое реестров. По умолчанию данные шифруются неактивных с помощью ключей, управляемых службой, но для соответствия нормативным стандартам иногда требуются управляемые клиентом ключи. Сохраните ключ в управляемом хранилище ключей, например Azure Key Vault. Так как вы создаете и владеете ключом, вы несете ответственность за операции, связанные с жизненным циклом ключей, включая смену и управление. Дополнительные сведения см. в разделе "Шифрование реестра с помощью ключа, управляемого клиентом".

Рабочий доступ к серверу API Kubernetes

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

Агенты сборки

Агенты конвейера должны быть вне область в регулируемый кластер, так как процессы сборки могут быть векторами угроз. Хотя в качестве инфраструктуры агентов эластичной сборки используется Kubernetes, не выполняйте этот процесс в пределах контролируемой среды выполнения рабочей нагрузки. Агенты сборки не должны иметь прямой доступ к кластеру. Например, только предоставить агенту сборки сетевой доступ к Реестр контейнеров Azure для отправки образов контейнеров, диаграмм helm и т. д. Затем развернитесь с помощью GitOps. Как правило, рабочие процессы сборки и выпуска не должны иметь прямой доступ к API кластера Kubernetes (или его узлам).

Операции мониторинга

Действия в кластере

Модули pod в кластере, выполняемые в kube-system журналеomsagent, являются агентом сбора Log Analytics. Они собирают данные телеметрии, скребают контейнер stdout и stderr журналы и собирают метрики Prometheus. Параметры коллекции можно настроить, обновив container-azm-ms-agentconfig.yaml файл ConfigMap. В этой эталонной реализации ведение журнала включается во kube-system всех рабочих нагрузках. По умолчанию kube-system из ведения журнала исключается. Убедитесь, что вы настраиваете процесс сбора журналов, чтобы обеспечить баланс затрат, эффективность SRE при просмотре журналов и требованиях к соответствию требованиям.

Мониторинг безопасности

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

Интегрируйте журналы, чтобы вы могли эффективно просматривать, анализировать и запрашивать данные. Azure предоставляет несколько вариантов. Вы можете включить журналы диагностики AKS и отправить их в рабочую область Log Analytics, которая является частью Azure Monitor. Другим вариантом является интеграция данных в решения по управлению безопасностью и событиями (SIEM), например Microsoft Sentinel.

В соответствии со стандартом для всех рабочих областей Log Analytics задано значение 90-дневного срока хранения. Рекомендуется настроить непрерывный экспорт для долгосрочного хранения. Не сохраняйте конфиденциальную информацию в данных журнала и убедитесь, что доступ к архивным данным журнала распространяется на те же уровни управления доступом, что и последние данные журнала.

Полный взгляд см. в руководстве по подключению Microsoft Defender для облака Enterprise. В этом руководстве рассматриваются регистрация, экспорт данных в решения SIEM, реагирование на оповещения и автоматизация рабочих процессов.

Связанные службы Azure

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

• Служба Azure Kubernetes (AKS)
• Брандмауэр Azure
• Бастион Azure
• Средство создания образов Azure
• Масштабируемые наборы виртуальных машин Azure
• Шлюз приложений Azure с интегрированными Брандмауэр веб-приложений (WAF)
• задачи Реестр контейнеров Azure
• Azure Key Vault

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

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