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

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

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

Основной темой стандарта PCI-DSS 3.2.1 является безопасность. Топология с концентраторами является естественным выбором для настройки регулируемых сред. Проще создать инфраструктуру, которая обеспечивает безопасную связь. Сетевые элементы управления помещаются как в центральные сети, так и следуют модели нулевого доверия Майкрософт. Элементы управления можно настроить с минимальными привилегиями для защиты трафика, предоставляя доступ на основе необходимых данных. Кроме того, можно применить несколько подходов для защиты, добавив элементы управления на каждом сетевом прыжке.

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

Создание и обслуживание безопасной сети и систем

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

Поддержка функций AKS

AKS поддерживает развертывание кластера в частной виртуальной сети в качестве частного кластера. Обмен данными между кластером и сервером API Kubernetes, управляемым AKS, осуществляется через надежную сеть. С помощью частного кластера можно использовать Azure виртуальная сеть, группу безопасности сети (NSG) и другие встроенные сетевые элементы управления для защиты всей среды данных карта заполнителей (CDE). Это позволит запретить любой несанкционированный общедоступный доступ между Интернетом и средой. Дополнительные сведения о подготовке такого кластера см. в статье "Создание частного Служба Azure Kubernetes кластера".

Брандмауэр Azure можно интегрировать с AKS и ограничить исходящий трафик из кластера, который является ключевым компонентом CDE. Конфигурация упрощается с помощью FQDN-тега AKS. Рекомендуемый процесс предоставляется в разделе "Использование Брандмауэр Azure для защиты развертываний Служба Azure Kubernetes (AKS).

Для кластеров AKS требуется доступ к общедоступному Интернету. Ограничение исходящего трафика в Интернет с помощью Брандмауэр Azure и групп безопасности сети в подсети кластера. Дополнительные сведения см. в разделе "Управление исходящим трафиком для узлов кластера" в Служба Azure Kubernetes (AKS).

AKS при необходимости поддерживает возможность определения ПРОКСИ-сервера HTTP, который можно использовать для дополнительного исходящего трафика и мониторинга для кластера. Узлы кластера используют указанную конфигурацию прокси-сервера HTTP для маршрутизации исходящего трафика. Кроме того, параметр MutatingWebhook регистрируется для внедрения сведений о прокси-сервере в модули pod во время создания, поэтому рекомендуется, чтобы рабочие нагрузки могли наследовать те же сведения прокси-сервера. Модули pod могут переопределить сведения о прокси-сервере, поэтому рекомендуется использовать прокси-сервер HTTP в дополнение к Брандмауэр Azure.

Кластеры AKS должны создаваться с помощью подключаемого модуля NetworkPolicy. В AKS у вас есть возможность между Azure или Calico в качестве подключаемого модуля политики сети. С помощью политики сети Calico можно использовать Kubenet или Azure CNI. Для политики сети Azure можно использовать только Azure CNI (а не Kubenet). Политики сети для узлов Windows поддерживаются только в Calico. Подключаемые модули политики сети Azure и Calico открытый код. Дополнительные сведения о Project Calico см. в комплексном техническом документе решения PCI, которое отвечает многим требованиям к брандмауэру, приведенным ниже.

Ваши обязанности

Требование	Обязанности
Требование 1.1	Создайте и реализуйте стандарты конфигурации брандмауэра и маршрутизатора.
Требование 1.2	Создайте конфигурации брандмауэра и маршрутизатора, ограничивающие подключения между ненадежными сетями и любыми системными компонентами в среде данных карта заполнителей.
Требование 1.3	Запретить прямой общедоступный доступ между Интернетом и любым системным компонентом в среде данных карта заполнителей.
Требование 1.4	Установите личное программное обеспечение брандмауэра или эквивалентную функциональность на любых портативных вычислительных устройствах (включая корпоративные и/или сотрудники), которые подключаются к Интернету, когда вне сети (например, ноутбуки, используемые сотрудниками), и которые также используются для доступа к CDE.
Требование 1.5	Убедитесь, что политики безопасности и операционные процедуры управления брандмауэрами документируются, используются и известны всем затронутым сторонам.

Требование 1.1

Установите и реализуйте стандарты конфигурации брандмауэра и маршрутизатора, которые включают следующие:

Требование 1.1.1

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

Ваши обязанности

Не реализуйте конфигурации вручную, например с помощью портал Azure или Azure CLI напрямую. Мы рекомендуем использовать инфраструктуру в качестве кода (IaC). С помощью IaC инфраструктура управляется с помощью описательной модели, которая использует систему управления версиями. Модель IaC создает одну и ту же среду при каждом применении. Распространенными примерами IaC являются Azure Resource Manager или Terraform. Если IaC не является вариантом, у вас есть хорошо документированные процессы для отслеживания, реализации и безопасного развертывания изменений правил брандмауэра. Дополнительные сведения предоставляются в рамках требования 11.2.

Вам потребуется использовать сочетание различных сетевых элементов управления, включая Брандмауэр Azure, группы безопасности сети (NSG) и ресурс KubernetesNetworkPolicy.

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

Требование 1.1.2

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

Ваши обязанности

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

На этом рисунке показана сетевая схема эталонной реализации.

Скачайте файл Visio этой схемы.

Рис. 1.1.2 . Сетевой поток

Описание этого потока представлено в следующих разделах.

Топологию виртуальной сети Azure можно просмотреть, если у вас есть azure Наблюдатель за сетями. Вы можете просмотреть все ресурсы в виртуальной сети, ресурсы, связанные с ресурсами в виртуальной сети, и связи между ресурсами.

Требование 1.1.3

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

Ваши обязанности

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

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

Так как эта архитектура ориентирована на инфраструктуру, а не рабочую нагрузку, мы опущены здесь.

Требование 1.1.4

Требования к брандмауэру для каждого подключения к Интернету и между любой демилитаризованной зоной (DMZ) и внутренней зоной сети.

Ваши обязанности

Четкое определение того, что определяет границу dmZ. Например, среда данных карта заполнителя (CDE) находится в пределах dmZ, защищенной брандмауэром, политикой сети и другими элементами управления. Дополнительные сведения см. в разделе Cloud DMZ.

Для инфраструктуры PCI DSS вы несете ответственность за защиту CDE с помощью сетевых элементов управления, чтобы заблокировать несанкционированный доступ в сеть и выйти из сети с помощью CDE. Сетевые элементы управления должны быть правильно настроены для надежной системы безопасности, и они должны применяться к:

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

Эта архитектура использует различные технологии брандмауэра для проверки потока трафика в обоих направлениях и из кластера, на котором размещается CDE:

• Шлюз приложений Azure брандмауэр веб-приложения (WAF) используется в качестве маршрутизатора трафика и для защиты входящего трафика в кластер.

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

  В рамках обработки транзакций или операций управления кластеру потребуется взаимодействовать с внешними сущностями. Например, кластеру может потребоваться взаимодействие с плоскости управления AKS, получение обновлений Windows и пакетов, а также взаимодействие рабочей нагрузки с внешними API. Некоторые из этих взаимодействий могут быть по протоколу HTTP и должны рассматриваться как векторы атак. Эти векторы предназначены для атаки "человек в середине", которая может привести к краже данных. Добавление брандмауэра в исходящий трафик устраняет эту угрозу.

  Мы рекомендуем использовать даже обмен данными pod в pod с шифрованием TLS. Эта практика показана в эталонной реализации с использованием сетки mTLS.

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

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

• Kubernetes NetworkPolicy

  По умолчанию нет ограничений на обмен данными pod-to-pod. Необходимо применить NetworkPolicy связь в кластере, начиная с сети нулевого доверия и открывая пути по мере необходимости. Эталонная реализация демонстрирует сети нулевого доверия в a0005-i пространствах имен и a0005-o пространствах имен. Все пространства имен (кроме kube-system, gatekeeper-systemи другие пространства имен AKS) применяются строгие NetworkPolicy ограничения. Определение политики зависит от модулей pod, выполняемых в этих пространствах имен. Убедитесь, что вы открываете пути для готовности, живости и запуска проб. Кроме того, откройте путь для oms-agent отправки метрик на уровне узла. Рассмотрите возможность стандартизации портов между рабочими нагрузками, чтобы обеспечить согласованность NetworkPolicy и Политика Azure для разрешенных портов контейнеров.

Требование 1.1.5

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

Ваши обязанности

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

Например, знают, кто отвечает за управление безопасностью сети между Azure и Интернетом. В организации ИТ-отдел отвечает за настройку и обслуживание правил Брандмауэр Azure, Брандмауэр веб-приложений (WAF), групп безопасности сети и другого межсетного трафика. Они также могут отвечать за распределение виртуальных сетей на уровне предприятия и подсети, а также планирование IP-адресов.

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

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

Требование 1.1.6

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

Ваши обязанности

Подробные сведения о службах, протоколах и портах, используемых в сетевых элементах управления. Запретить все, кроме явно разрешенных портов. Документируйте бизнес-обоснование и документированные функции безопасности, если использование небезопасных протоколов невозможно избежать. Ниже приведены некоторые примеры из эталонной реализации для Брандмауэр Azure. Правила брандмауэра должны быть область исключительно к связанным ресурсам. То есть только трафик из определенных источников разрешено переходить к определенным целевым объектам FQDN. Ниже приведены некоторые случаи, чтобы разрешить трафик.

Правило	Протокол:порт	Источник	Назначение	Выравнивание по ширине
Разрешить безопасное взаимодействие между узлами и плоскости управления.	HTTPS:443	Авторизованные диапазоны IP-адресов, назначенные пулам узлов кластера	Список целевых объектов FQDN в плоскости управления AKS. Это указано с тегом AzureKubernetesService FQDN.	Узлы должны иметь доступ к плоскости управления для средств управления, сведений о состоянии и конфигурации, а также сведения о том, какие узлы можно масштабировать.
Разрешить безопасное взаимодействие между Flux и GitHub.	HTTPS:443	Пулы узлов AKS	github.com,api.github.com	Flux — это сторонняя интеграция, которая выполняется на узлах. Он синхронизирует конфигурацию кластера с частным репозиторием GitHub.

Требование 1.1.7

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

Ваши обязанности

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

• Брандмауэр Azure правила.
• Правила NSG.
• Шлюз приложений Azure и правила WAF.
• Собственные политики сети Kubernetes.
• Элементы управления брандмауэром в применимых ресурсах Azure. Например, эта архитектура использует правило для Реестр контейнеров Azure, которое разрешает трафик только из частной конечной точки.
• Любые другие сетевые элементы управления, добавленные в архитектуру.

Требование 1.2

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

Ваши обязанности

В этой архитектуре кластер AKS является ключевым компонентом среды данных карта заполнителей (CDE). Настоятельно рекомендуется развернуть кластер в качестве частного кластера для повышения безопасности. В частном кластере сетевой трафик между сервером API Kubernetes, управляемым AKS, и пулами узлов является частным. Сервер API предоставляется через частную конечную точку в сети кластера.

Вы также можете выбрать общедоступный кластер, но этот дизайн не рекомендуется для кластеров, содержащих регулируемые рабочие нагрузки. Сервер API будет предоставляться в Интернете. Запись DNS всегда будет обнаруживаемой. Таким образом, необходимо иметь элементы управления, чтобы обеспечить защиту API кластера от общедоступного доступа. Если требуется использовать общедоступный кластер, рекомендуемый подход заключается в том, чтобы иметь жесткие элементы управления доступом на основе ролей Kubernetes (RBAC), сопряженные с функцией диапазонов разрешенных IP-адресов AKS, чтобы ограничить доступ к серверу API AKS. Однако это решение не рекомендуется для кластеров, содержащих регулируемые рабочие нагрузки.

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

Ненадежные сети — это сети за пределами этого периметра. Эта категория включает другие концентраторы и периферийные узлы, которые могут находиться в той же инфраструктуре, но находятся за пределами периметра рабочей нагрузки, общедоступного Интернета, корпоративной сети или виртуальных сетей в Azure или другой облачной платформы. В этой архитектуре виртуальная сеть, на которой размещен построитель образов, не является доверенным, так как она не имеет никакой роли в обработке CHD. Взаимодействие CDE с такими сетями должно быть безопасно в соответствии с требованиями. С помощью этого частного кластера можно использовать Azure виртуальная сеть, группу безопасности сети и другие встроенные функции для защиты всей среды.

Сведения о частных кластерах см. в статье "Создание частного Служба Azure Kubernetes кластера".

Требование 1.2.1

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

Ваши обязанности

По проектированию azure виртуальная сеть невозможно напрямую связаться с общедоступным Интернетом. Весь входящий (или входящий) трафик должен проходить через промежуточный маршрутизатор трафика. Однако все компоненты в сети могут достигать общедоступных конечных точек. Этот исходящий трафик (или исходящий трафик) должен быть явно защищен, позволяя только безопасные шифры и TLS 1.2 или более поздней версии.

• Шлюз приложений Azure интегрированный WAF перехватывает весь трафик входящего трафика HTTP(S) и маршруты проверенного трафика в кластер.

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

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

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

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

  Дополнительные сведения см. в статье Защита развернутой службы Azure Kubernetes Service (AKS) с помощью брандмауэра Azure.

• При необходимости можно использовать HTTP-прокси для мониторинга и защиты исходящего трафика (исходящего трафика) из кластера на внешние ресурсы.

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

  Дополнительные сведения см. в разделе поддержки прокси-сервера HTTP в Служба Azure Kubernetes.

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

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

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

• Группы безопасности сети в подсетях с пулами узлов запрещают доступ SSH к его узлам. У вас есть процесс для JIT-аварийного доступа, сохраняя принцип запрета.
• Группа безопасности сети в подсети с полем перехода для запуска средств управления запрещает весь трафик, кроме Бастиона Azure в центральной сети.
• Группы безопасности сети в подсетях с частными конечными точками в Azure Key Vault и Реестр контейнеров Azure запрещают весь трафик, кроме внутреннего подсистемы балансировки нагрузки и трафика через Приватный канал Azure.

Требование 1.2.2

Защита и синхронизация файлов конфигурации маршрутизатора.

Ваши обязанности

Механизм обнаружения разностности между фактическим развернутым состоянием и требуемым состоянием. Инфраструктура как код (IaC) является отличным выбором для этой цели. Например, шаблоны Azure Resource Manager имеют запись требуемого состояния.

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

В кластере сетевые элементы управления, такие как политики сети Kubernetes, также должны соответствовать потоку, управляемому источником. В этой реализации Flux используется в качестве оператора GitOps. При синхронизации конфигурации кластера, такой как политики сети, журнал Git в сочетании с журналами Flux и API может быть источником журнала конфигурации.

Требование 1.2.3

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

Ваши обязанности

Узлы AKS и пулы узлов не должны быть доступны из беспроводных сетей. Кроме того, запросы к серверу API Kubernetes должны быть отклонены. Доступ к этим компонентам ограничен авторизованными и защищенными подсетями.

Как правило, ограничить доступ от локального трафика к периферийной сети.

Требование 1.3

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

Ваши обязанности

Пулы узлов кластера AKS работают в виртуальной сети и изолированы от общедоступных сетей, таких как Интернет. Обеспечение изоляции путем предотвращения связи общедоступных IP-адресов с узлами кластера и применением правил NSG в подсетях кластера, чтобы убедиться, что интернет-трафик заблокирован. Сведения об управляемом доступе см. в разделе DMZ.

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

Другой критически важный системный компонент — это сервер API, используемый для выполнения собственных задач Kubernetes, таких как поддержание состояния кластера и конфигурации. Преимуществом использования частного кластера является то, что конечная точка сервера API не предоставляется по умолчанию. Сведения о частных кластерах см. в статье "Создание частного Служба Azure Kubernetes кластера".

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

Требование 1.3.1

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

Ваши обязанности

Вот некоторые рекомендации:

• Не настраивайте общедоступные IP-адреса на узлах пула узлов.
• Используйте Политика Azure, чтобы убедиться, что Kubernetes не предоставляет общедоступную подсистему балансировки нагрузки. Трафик в кластере должен направляться через внутренние подсистемы балансировки нагрузки.
• Предоставляет только внутренние подсистемы балансировки нагрузки для Шлюз приложений Azure интеграции с WAF.
• Все сетевые элементы управления должны указывать ограничения источника, назначения, порта и протокола, где это применимо.
• Не предоставляйте серверу API доступ к Интернету. При запуске кластера в частном режиме конечная точка не предоставляется и обмен данными между пулами узлов и сервером API осуществляется через частную сеть.

Пользователи могут реализовать сеть периметра для защиты кластеров AKS. Дополнительные сведения см. в разделе Cloud DMZ.

Требование 1.3.2

Ограничить входящий интернет-трафик IP-адресами в пределах dmZ.

Ваши обязанности

В сети кластера в подсети есть группа безопасности сети с внутренней подсистемой балансировки нагрузки. Настройте правила, чтобы принимать трафик только из подсети, которая Шлюз приложений Azure интегрирована с WAF. В кластере AKS используйте Kubernetes NetworkPolicies для ограничения трафика входящего трафика к модулям pod.

Требование 1.3.3

Реализуйте меры защиты от спуфинга для обнаружения и блокировки исходных IP-адресов при входе в сеть.

Обязанности Azure

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

Требование 1.3.4

Не разрешайте несанкционированный исходящий трафик из среды данных карта заполнителей в Интернет.

Ваши обязанности

Ниже приведены способы блокировки несанкционированного исходящего трафика.

• Принудительно принудийте весь исходящий трафик из кластера AKS, чтобы пройти Брандмауэр Azure с помощью определяемых пользователем маршрутов (UDR) во всех подсетях кластера. Сюда входят подсети с пулами системных и пользовательских узлов.
• Ограничить исходящий трафик путем добавления групп безопасности сети в подсети с пулами узлов.
• Используйте Kubernetes NetworkPolicies для ограничения исходящего трафика из модулей pod.
• Используйте сетку службы для обработки дополнительных политик. Например, если разрешен только зашифрованный TLS трафик между модулями pod, прокси-сервер сетки служб может обрабатывать проверку TLS. Этот пример демонстрируется в этой реализации. Envoy развертывается в качестве прокси-сервера.
• Запретить добавление общедоступных IP-адресов в сети в CDE, если только подсети явно не авторизованы, например подсети брандмауэра.
• Используйте http-прокси в дополнение к Брандмауэр Azure, чтобы ограничить исходящий трафик из кластера AKS в Интернет.
• Используйте Azure Monitor Приватный канал Service (AMPLS) для получения журналов из аналитики контейнеров, отправляемых через безопасное частное подключение к Azure Monitor. Узнайте о влиянии включения AMPLS.

Дополнительные сведения см. в разделе "Управление исходящим трафиком для узлов кластера" в Служба Azure Kubernetes (AKS).

Требование 1.3.5

Разрешение только установленных подключений к сети.

Обязанности Azure

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

Требование 1.3.6

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

Ваши обязанности

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

Требование 1.3.7

Не раскрывайте частные IP-адреса и сведения о маршрутизации для несанкционированных сторон.

Ваши обязанности

Для удовлетворения этого требования общедоступный кластер AKS не является вариантом. Частный кластер сохраняет записи DNS вне общедоступного Интернета с помощью частной зоны DNS. Однако по-прежнему можно создать частный кластер AKS с общедоступным DNS-адресом. Поэтому рекомендуется явно отключить эту функцию, чтобы enablePrivateClusterPublicFQDNfalse предотвратить раскрытие частного IP-адреса плоскости управления. Рекомендуется использовать Политика Azure для принудительного использования частных кластеров без общедоступных записей DNS.

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

Служба Azure, подключенная через Приватный канал, не содержит общедоступной записи DNS, предоставляющей IP-адреса. Ваша инфраструктура должна обеспечить оптимальное использование Приватный канал.

Требование 1.4

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

Ваши обязанности

Частный кластер управляется плоскостем управления AKS. У вас нет доступа к узлам напрямую. Для выполнения административных задач необходимо использовать такие средства управления, как kubectl из отдельного вычислительного ресурса. Можно использовать флажок перехода с воздушным изображением, где можно выполнять команды. Кроме того, входящий и исходящий трафик из поля перехода должен быть ограничен и защищен. Если VPN используется для доступа, убедитесь, что клиентский компьютер управляется корпоративной политикой и всеми политиками условного доступа.

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

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

Требование 1.5

Убедитесь, что политики безопасности и операционные процедуры управления брандмауэрами документируются, используются и известны всем затронутым сторонам.

Ваши обязанности

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

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

Ваши обязанности

Требование	Обязанности
Требование 2.1	Всегда изменяйте значения по умолчанию, предоставляемые поставщиком, и удалите или отключите ненужные учетные записи по умолчанию перед установкой системы в сети.
Требование 2.2	Разработка стандартов конфигурации для всех системных компонентов. Обеспечьте для этих стандартов учет всех известных уязвимостей и соблюдение всех признанных отраслевых стандартов защиты систем.
Требование 2.3	Шифрование всего административного доступа, отличного от консоли, с помощью строгой криптографии.
Требование 2.4	Храните инвентаризацию системных компонентов, которые находятся в область для PCI DSS.
Требование 2.5	Убедитесь, что политики безопасности и операционные процедуры для управления значениями по умолчанию поставщика и другими параметрами безопасности документируются, используются и известны всем затронутым сторонам.
Требование 2.6	Поставщики общего размещения должны защищать размещенную среду каждой сущности и данные карта заполнителей.

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

Требование 2.1

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

Ваши обязанности

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

• Отключите доступ администратора в реестре контейнеров.
• Убедитесь, что переходы и агенты сборки выполняют процедуры управления пользователями, удаляя необходимых системных пользователей.
• Не создавайте или не предоставляйте доступ к ключам SSH к узлам администратора. Если требуется экстренный доступ, используйте процесс восстановления Azure, чтобы получить JIT-доступ.

Обязанности Azure

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

Требование 2.1.1

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

Ваши обязанности

Эта архитектура и реализация не предназначены для локальной или корпоративной сети для облачных транзакций через беспроводные подключения. Рекомендации см. в официальном стандарте PCI-DSS 3.2.1.

Требование 2.2

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

Ваши обязанности

Реализуйте рекомендации в тесте безопасности Azure. Он предоставляет единое консолидированное представление рекомендаций по безопасности Azure, охватывающее отраслевые платформы, такие как CIS, NIST, PCI-DSS 3.2.1 и другие. Используйте функции Microsoft Defender для облака и Политика Azure для отслеживания стандартов. Azure security benchmark — это инициатива по умолчанию для Microsoft Defender для облака. Рассмотрите возможность создания дополнительных автоматизированных проверка в решении Политика Azure и решении безопасности клиента Azure (AzTS).

Задокументируйте требуемое состояние конфигурации всех компонентов в CDE, особенно для узлов AKS, поля перехода, агентов сборки и других компонентов, взаимодействующих с кластером.

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

Ответственность Azure

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

Требование 2.2.1

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

Ваши обязанности

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

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

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

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

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

Требование 2.2.2

Включите только необходимые службы, протоколы, daemons и т. д., необходимые для функции системы.

Ваши обязанности

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

Для компонентов, где у вас есть полный контроль, удалите все ненужные системные службы из образов (например, прыжки и агенты сборки).

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

Требование 2.2.3

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

Ваши обязанности

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

Предположим, что у вас есть устаревшее устройство, которое должно взаимодействовать с CDE через Шлюз приложений Azure. Для этого Шлюз приложений должен включать небезопасный протокол. Задокументируйте это исключение и отслеживайте, используется ли этот протокол за пределами этого устаревшего устройства. Отключите этот протокол сразу после прекращения устаревшего взаимодействия.

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

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

Требование 2.2.4

Настройте параметры безопасности системы, чтобы предотвратить неправильное использование.

Ваши обязанности

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

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

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

Регулярно убедитесь, что все исключения документируются и проверяются.

Обязанности Azure

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

Требование 2.2.5

Удалите все ненужные функции, такие как скрипты, драйверы, функции, подсистемы, файловые системы и ненужные веб-серверы.

Ваши обязанности

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

Требование 2.3

Шифрование всего административного доступа, отличного от консоли, с помощью строгой криптографии.

Ваши обязанности

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

Обязанности Azure

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

Требование 2.4

Храните инвентаризацию системных компонентов, которые находятся в область для PCI DSS.

Ваши обязанности

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

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

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

Пометьте объекты в кластере, применяя метки Kubernetes. Таким образом можно упорядочить объекты, выбрать коллекцию объектов и сообщить о инвентаризации.

Требование 2.5

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

Ваши обязанности

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

Требование 2.6

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

Ваши обязанности

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

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

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

Защитите сохраненные данные карта заполнителя. Шифрование передачи данных карта заполнителей через открытые общедоступные сети.

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

• Проектирование архитектуры Служба Azure Kubernetes (AKS)
• Введение в регулируемый кластер AKS для PCI-DSS 3.2.1 (часть 1 из 9)
• Архитектура регулируемых кластеров AKS для PCI-DSS 3.2.1 (часть 2 из 9)
• Базовая архитектура для кластера Служба Azure Kubernetes (AKS)
• Базовые показатели AKS для кластеров с несколькими агрегатами