Управление доступом к базовому кластеру AKS для PCI-DSS 3.2.1 (часть 6 из 9)

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

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

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

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

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

Требование 7. Ограничение доступа к данным карта для бизнеса необходимо знать

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

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

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

По умолчанию Azure RBAC запрещает доступ ко всем ресурсам без предоставленных разрешений. AKS ограничивает доступ SSH к рабочим узлам AKS и использует политику сети AKS для управления доступом к рабочим узлам pod.

Дополнительные сведения см. в статье "Использование Azure RBAC для авторизации Kubernetes и защита кластера с помощью Политика Azure".

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

Требование	Обязанности
Требование 7.1	Ограничьте доступ к системным компонентам и карта заполнителям только тем лицам, которым требуется такой доступ.
Требование 7.2	Установите систему управления доступом для компонентов систем, ограничивающих доступ на основе необходимости знать пользователя, и имеет значение "запретить все", если только не разрешено.
Требование 7.3	Убедитесь, что политики безопасности и операционные процедуры для ограничения доступа к данным карта заполнителя документируются, используются и известны всем пострадавшим сторонам.

Требование 7.1

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

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

Ниже приведены некоторые рекомендации.

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

Требование 7.1.1

Определите потребности доступа для каждой роли, в том числе:

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

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

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

• Область действия групп управления Azure, подписок или групп ресурсов
• Политика Azure для рабочей нагрузки или подписки
• Операции с контейнерами
• Управление секретами
• Конвейеры сборки и развертывания

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

• Решения о безопасности приложений, Kubernetes RBAC, сетевых политиках, политиках Azure и взаимодействии с другими службами.
• Настройка и обслуживание Брандмауэр Azure, брандмауэра веб-приложения (WAF), групп безопасности сети (NSG) и конфигурации DNS.
• Мониторинг и исправление безопасности сервера, исправлений, конфигурации и безопасности конечных точек.
• Задайте направление использования стратегии защиты RBAC, Microsoft Defender для облака, Администратор istrator и Политика Azure для управления ресурсами Azure.
• Группа мониторинга инцидентов и реагирования. Изучите и исправьте инциденты безопасности в системе управления сведениями и событиями безопасности (SIEM) или Microsoft Defender для облака.

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

Роль	Обязанности	Уровни доступа
Владельцы приложений	Определение и приоритет функций, которые соответствуют бизнес-результатам. Они понимают, как функции влияют на соответствие рабочей нагрузки, а также балансируйте защиту данных клиентов и владение ими с бизнес-целями.	Доступ на чтение к журналам и метрикам, созданным приложением. Им не нужны разрешения для доступа к рабочей нагрузке или кластеру.
Разработчики приложений	Разработка приложения. Весь код приложения применяется к учебным и качественным шлюзам, поддерживающим соответствие, аттестацию и процессы управления выпусками. Может управлять конвейерами сборки, но обычно не конвейерами развертывания.	Доступ на чтение к пространствам имен Kubernetes и ресурсам Azure, которые находятся в область рабочей нагрузки. Нет доступа на запись для развертывания или изменения состояния системы.
Операторы приложений (или SRE)	Глубокое понимание базы кода, наблюдаемости и операций. Выполнение потоковой трансляции и устранение неполадок. Помимо разработчиков приложений, повышение доступности, масштабируемости и производительности приложения. Управляйте конвейером развертывания last-mile и помогайте управлять конвейерами сборки.	Высокий уровень привилегий в область приложения, включающего связанные пространства имен Kubernetes и ресурсы Azure. Скорее всего, имеют постоянный доступ к частям кластера Kubernetes.
Владельцы инфраструктуры	Разработка экономичной архитектуры, включая его подключение и функциональные возможности компонентов. Область может включать облачные и локальные службы. Определите возможности хранения данных, функций непрерывности бизнес-процессов и других.	Доступ к журналам платформы и данным центра затрат. Доступ в кластере не требуется.
Операторы инфраструктуры (или SRE)	Операции, связанные с кластером и зависимыми службами. Создание, развертывание и загрузка конвейера для кластера, в котором развернута рабочая нагрузка. Задайте целевые пулы узлов и ожидаемые требования к размеру и масштабированию. Отслеживайте работоспособность инфраструктуры размещения контейнеров и зависимых служб.	Доступ на чтение к пространствам имен рабочей нагрузки. Высоко привилегированный доступ для кластера.
Политики, владельцы безопасности	Обладайте опытом соответствия требованиям безопасности или нормативных требований. Определите политики, которые защищают соответствие требованиям безопасности и нормативным требованиям сотрудников компании, ее активов и клиентов компании. Работает со всеми остальными ролями, чтобы обеспечить применение политики и аудит на каждом этапе.	Доступ на чтение к рабочей нагрузке и кластеру. Также доступ к данным журнала и аудита.
Сетевые операторы	Выделение виртуальных сетей и подсетей на уровне предприятия. Настройка и обслуживание конфигурации Брандмауэр Azure, WAF, NSG и DNS.	Высоко привилегированный уровень сети. Разрешения на запись в кластере отсутствуют.

Требование 7.1.2

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

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

На основе функций заданий старайтесь минимизировать доступ, не вызывая нарушений. Вот некоторые рекомендации:

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

Требование 7.1.3

Назначьте доступ на основе классификации и функции отдельных сотрудников.

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

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

Ниже приведено несколько примеров.

Классификация задания	Роль
Владелец продукта определяет область рабочей нагрузки и определяет приоритеты функций. Балансирует защиту данных клиентов и владение ими с бизнес-целями. Требуется доступ к отчетам, центру затрат или панелям мониторинга Azure. Доступ не требуется для разрешений на уровне кластера или кластера.	Владельцы приложений
Инженер программного обеспечения разрабатывает, разрабатывает и контейнеризирует код приложения. Группа с постоянными разрешениями на чтение в определенных область в Azure (например, приложениях Аналитика) и пространствах имен рабочей нагрузки. Эти область и разрешения могут отличаться между предварительной и рабочей средами.	Разработчик приложения
Инженер надежности сайта выполняет динамические операции, управляет конвейерами и настраивает инфраструктуру приложений. Группировать A с полным контролем в выделенных пространствах имен. Не требуются постоянные разрешения. Группа B для повседневных операций с рабочей нагрузкой. Он может иметь постоянные разрешения в пределах выделенных пространств имен, но не имеют высокой привилегии.	Операторы приложений
Оператор кластера разрабатывает и развертывает надежный и безопасный кластер AKS на платформе. Отвечает за поддержание времени выполнения кластера. Группировать A с полным контролем в выделенных пространствах имен. Не требуются постоянные разрешения. Группа B для повседневных операций с рабочей нагрузкой. Он может иметь постоянные разрешения в пределах выделенных пространств имен, но не имеют высокой привилегии.	Операторы инфраструктуры
Сетевой инженер выделяет корпоративную виртуальную сеть и подсети, локальную среду для облачного подключения и сетевой безопасности.	Операторы инфраструктуры

Требование 7.1.4

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

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

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

Требование 7.2

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

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

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

На основе ролей и обязанностей назначьте роли управлению доступом на основе ролей инфраструктуры (RBAC). Этот механизм может быть следующим:

• Kubernetes RBAC — это собственная модель авторизации Kubernetes, которая управляет доступом к плоскости управления Kubernetes, предоставляемой через сервер API Kubernetes. Этот набор разрешений определяет, что можно сделать с сервером API. Например, вы можете запретить пользователю разрешения на создание или даже список модулей pod.
• Azure RBAC — это модель авторизации на основе идентификатора Microsoft Entra, которая управляет доступом к плоскости управления Azure. Это связь клиента Microsoft Entra с подпиской Azure. С помощью Azure RBAC можно предоставить разрешения на создание ресурсов Azure, таких как сети, кластер AKS и управляемые удостоверения.

Предположим, необходимо предоставить разрешения операторам кластера (сопоставлено с ролью оператора инфраструктуры). Все пользователи, которым назначены обязанности оператора инфраструктуры, принадлежат группе Microsoft Entra. Как указано в версии 7.1.1, для этой роли требуется наивысшая привилегия в кластере. Kubernetes имеет встроенные роли RBAC, такие как cluster-admin, которые соответствуют этим требованиям. Необходимо привязать группу Microsoft Entra для оператора cluster-admin инфраструктуры, создавая привязки ролей. Существуют два подхода. Вы можете выбрать встроенные роли. Кроме того, если встроенные роли не соответствуют вашим требованиям (например, они могут быть слишком неразрешительными), создайте пользовательские роли для ваших привязок.

Эталонная реализация демонстрирует предыдущий пример с помощью собственного RBAC Kubernetes. Ту же связь можно выполнить с помощью Azure RBAC. Дополнительные сведения см. в статье "Управление доступом к ресурсам кластера с помощью управления доступом на основе ролей Kubernetes" и удостоверений Microsoft Entra в Служба Azure Kubernetes.

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

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

Помимо пользователей и их ролей ресурсы Azure и даже модули pod в кластере имеют управляемые удостоверения. Эти удостоверения нуждаются в наборе разрешений через Azure RBAC и должны быть тесно область на основе ожидаемых задач. Например, Шлюз приложений Azure должны иметь разрешения на получение секретов (сертификатов TLS) из Azure Key Vault. У него не должно быть разрешений на изменение секретов.

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

• Сохраняйте тщательную документацию по каждой роли и назначенным разрешениям. Четкое различие о том, какие разрешения являются JIT и которые стоят.

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

Требование 7.2.1

Охват всех системных компонентов

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

Ниже приведены некоторые рекомендации по поддержанию мер контроля доступа:

• У вас нет постоянного доступа. Рекомендуется использовать членство в группе JIT AD. Для этой функции требуется управление привилегированными пользователями Microsoft Entra.

• Настройте политики условного доступа в идентификаторе Microsoft Entra для кластера. Это также ограничивает доступ к плоскости управления Kubernetes. С помощью политик условного доступа можно требовать многофакторную проверку подлинности, ограничить проверку подлинности устройствами, управляемыми клиентом Microsoft Entra, или блокировать нетипичную попытку входа. Примените эти политики к группам Microsoft Entra, сопоставленным с ролями Kubernetes с высоким уровнем привилегий.

  Примечание.

  Для выбора технологии JIT и условного доступа требуется идентификатор Microsoft Entra ID P1 или P2.

• В идеале отключите доступ SSH к узлам кластера. Эта эталонная реализация не создает сведения о подключении SSH для этой цели.

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

Требование 7.2.2

Назначение привилегий отдельным лицам на основе классификации заданий и функций.

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

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

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

• Как они должны получить доступ к кластеру?
• Какие источники разрешены для доступа?
• Какие разрешения должны быть в кластере?
• Когда назначаются эти разрешения?

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

Требование 7.2.3

Параметр "Запретить все" по умолчанию.

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

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

• Kubernetes RBAC реализует запретить все по умолчанию. Не переопределяйте путем добавления привязок ролей кластера с высокой степенью разрешения, которые обратно запрещают все параметры.

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

• Все службы Azure, Azure Key Vault и Реестр контейнеров Azure по умолчанию запрещают все наборы разрешений.

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

Требование 7.3

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

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

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

Требование 8. Определение и проверка подлинности доступа к системным компонентам

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

Благодаря интеграции AKS и Microsoft Entra вы можете воспользоваться преимуществами управления идентификаторами и авторизации, включая управление доступом, управление объектами идентификаторов и другие. Дополнительные сведения см. в статье интеграции с Microsoft Entra, управляемой AKS.

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

Требование	Обязанности
Требование 8.1	Определите и реализуйте политики и процедуры, чтобы обеспечить надлежащее управление идентификацией пользователей для пользователей и администраторов, не являющихся потребителями, на всех системных компонентах следующим образом:
Требование 8.2	Помимо назначения уникального идентификатора, убедитесь, что для всех системных компонентов используется хотя бы один из следующих методов для проверки подлинности всех пользователей, не являющихся потребителями, и администраторов.
Требование 8.3	Защита всех отдельных административных прав без консоли и всех удаленных доступа к CDE с помощью многофакторной проверки подлинности.
Требование 8.4	Документируйте и сообщайте процедуры проверки подлинности и политики и процедуры всем пользователям, включая:
Требование 8.5	Не используйте групповые, общие или универсальные идентификаторы, пароли или другие методы проверки подлинности следующим образом:
Требование 8.6	Где используются другие механизмы проверки подлинности (например, физические или логические маркеры безопасности, смарт-карта, сертификаты и т. д.), использование этих механизмов должно быть назначено следующим образом:
Требование 8.7	Доступ ко любой базе данных, содержащей данные карта заполнителей (включая доступ к приложениям, администраторам и всем другим пользователям), ограничен следующим образом:
Требование 8.8	Убедитесь, что политики безопасности и операционные процедуры идентификации и проверки подлинности документируются, используются и известны всем пострадавшим сторонам.

Требование 8.1

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

• 8.1.1. Присвойте всем пользователям уникальные идентификаторы, позволяющие им получать доступ к компонентам системы или данным владельцев карт.
• 8.1.2. Управляйте добавлением, удаление и модификацией идентификаторов пользователей, учетных данных и других объектов идентификатора.
• 8.1.3. Немедленно отзывайте доступ для завершивших работу пользователей.
• 8.1.4 Удаление и отключение неактивных учетных записей пользователей в течение 90 дней.
• 8.1.5 Управление идентификаторами, используемыми сторонними сторонами для доступа, поддержки или обслуживания системных компонентов с помощью удаленного доступа следующим образом:
  • Включено только в течение требуемого периода времени и отключено, когда не используется.
  • Отслеживается во время работы.
• 8.1.6. Ограничьте попытки повторного доступа, блокируя идентификатор пользователя после шести попыток.
• 8.1.7. Установите продолжительность блокировки как минимум 30 минут или пока администратор не включит идентификатор пользователя.
• 8.1.8. Если сеанс неактивен более 15 минут, внедрите требование повторной аутентификации пользователя, чтобы повторно активировать окно терминала или сеанс.

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

Ниже приведены общие рекомендации по этому требованию:

ОБЛАСТЬ ПРИМЕНЕНИЯ: 8.1.1, 8.1.2, 8.1.3

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

Расширьте этот субъект удостоверений для назначений управляемых удостоверений в Azure. Не делитесь удостоверениями, управляемыми пользователем, в ресурсах Azure. Назначьте каждому ресурсу Azure собственное управляемое удостоверение. Аналогичным образом, если вы используете Идентификация рабочей нагрузки Microsoft Entra в кластере AKS, убедитесь, что каждый компонент в рабочей нагрузке получает собственное удостоверение вместо использования удостоверения, широко используемого в область. Никогда не используйте то же управляемое удостоверение в предварительной среде и рабочей среде.

Access and identity options for Azure Kubernetes Service (AKS) (Возможности контроля доступа и идентификации в Службе Azure Kubernetes (AKS))

ОБЛАСТЬ ПРИМЕНЕНИЯ: 8.1.2, 8.1.3, 8.1.4

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

ОБЛАСТЬ ПРИМЕНЕНИЯ: 8.1.5

Воспользуйтесь преимуществами Microsoft Entra business-to-business (B2B), предназначенными для размещения сторонних учетных записей, таких как поставщики, партнеры, как гостевые пользователи. Предоставьте соответствующий уровень доступа с помощью условных политик для защиты корпоративных данных. Эти учетные записи должны иметь минимальные постоянные разрешения и обязательные даты окончания срока действия. Дополнительные сведения см. в разделе "Что такое гостевой доступ пользователей" в Microsoft Entra B2B.

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

ОБЛАСТЬ ПРИМЕНЕНИЯ: 8.1.6, 8.1.7, 8.1.8

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

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

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

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

Требование 8.2

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

• 8.2.1. Преобразуйте все учетные данные для аутентификации (такие как пароли или парольные фразы) в нечитаемые во время передачи и хранения во всех компонентах системы, используя устойчивое шифрование.
• 8.2.2. Проверяйте удостоверение пользователя перед изменением любых учетных данных для аутентификации, например, перед выполнением сброса пароля, подготовкой новых маркеров или созданием ключей.
• 8.2.3 Пароли и фразы должны соответствовать следующим требованиям:
  • Минимальная длина — не менее семи знаков.
  • Числовые и буквенные знаки в составе пароля.
• 8.2.4. Изменяйте пароли и парольные фразы хотя бы раз в 90 дней.
• 8.2.5 Не разрешайте пользователю отправлять новый пароль или фразу, которая совпадает с любым из последних четырех паролей или фраз, которые он или она использовали.
• 8.2.6. Установка паролей и фраз для первого использования и при сбросе на уникальное значение для каждого пользователя и изменение сразу после первого использования.

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

Настройте политики условного доступа в идентификаторе Microsoft Entra для кластера. Это также ограничивает доступ к плоскости управления Kubernetes.

Несколько предыдущих наборов требований автоматически обрабатываются идентификатором Microsoft Entra. Ниже приведено несколько примеров:

• Безопасность паролей

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

  Примечание.

  Настоятельно рекомендуется рассмотреть варианты без пароля. Дополнительные сведения см. в статье Планирование развертывания без пароля проверки подлинности в идентификаторе Microsoft Entra.

• Проверка удостоверения пользователя

  Политику условного доступа для входа можно применить, чтобы определить, был ли выдан запрос проверки подлинности идентификатором запроса. Запрос проверяется в отношении источников аналитики угроз. К ним относятся аномалии спрея паролей и IP-адреса. Дополнительные сведения см. в разделе условный доступ: условный доступ на основе входа.

У вас могут быть компоненты, которые не используют идентификатор Microsoft Entra, например доступ к полям перехода с помощью SSH. В таких случаях используйте шифрование открытого ключа по крайней мере с размером ключа RSA 2048. Всегда указывайте парольную фразу. Процесс проверки, отслеживающий известные утвержденные открытые ключи. Системы, использующие доступ к открытому ключу, не должны предоставляться в Интернете. Вместо этого все SSH-доступ должен быть разрешен через посредника, например Бастион Azure, чтобы уменьшить влияние утечки закрытого ключа. Отключите прямой доступ к паролям и используйте альтернативное решение без пароля.

Требование 8.3

Защита всех отдельных административных прав без консоли и всех удаленных доступа к CDE с помощью многофакторной проверки подлинности. Примечание. Многофакторная проверка подлинности требует, чтобы для проверки подлинности использовалось не менее двух из трех методов проверки подлинности (см. требование 8.2 для описания методов проверки подлинности). Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной проверкой подлинности.

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

Используйте политики условного доступа для применения многофакторной проверки подлинности, в частности, для административных учетных записей. Эти политики рекомендуется использовать для нескольких встроенных ролей. Примените эти политики к группам Microsoft Entra, сопоставленным с ролями Kubernetes с высоким уровнем привилегий.

Эту политику можно дополнительно ужесточить с помощью дополнительных политик. Ниже приведено несколько примеров:

• Вы можете ограничить проверку подлинности устройствами, управляемыми клиентом Microsoft Entra.
• Если доступ поступает из сети за пределами сети кластера, можно применить многофакторную проверку подлинности.

Дополнительные сведения см. в разделе:

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

Требование 8.4

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

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

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

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

Требование 8.5

Не используйте групповые, общие или универсальные идентификаторы, пароли или другие методы проверки подлинности следующим образом:

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

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

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

Отключите корневых пользователей в CDE. Отключите использование локальных учетных записей Kubernetes, чтобы пользователи не могут использовать встроенный --admin доступ к кластерам в CDE.

Требование 8.6

Где используются другие механизмы проверки подлинности (например, физические или логические маркеры безопасности, смарт-карта, сертификаты и т. д.), использование этих механизмов должно быть назначено следующим образом:

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

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

Убедитесь, что весь доступ к CDE предоставляется для удостоверений пользователей и расширяется на любые физические или виртуальные маркеры. Это включает в себя любой VPN-доступ в сеть CDE, обеспечивая корпоративный доступ типа "точка — сеть" (если таковой) использует сертификаты для каждого пользователя в рамках этого потока проверки подлинности.

Требование 8.7

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

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

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

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

По возможности получите доступ к базе данных из приложений с помощью управляемого удостоверения. В противном случае ограничьте доступ к строка подключения и учетным данным. Используйте секреты Kubernetes для хранения конфиденциальной информации вместо хранения их мест, где они легко обнаруживаются, например определение pod. Другим способом является хранение и загрузка секретов в управляемое хранилище, например Azure Key Vault. С включенными управляемыми удостоверениями в кластере AKS он должен пройти проверку подлинности в Key Vault, чтобы получить доступ.

Требование 8.8

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

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

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

Требование 9. Ограничение физического доступа к данным карта заполнителя

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

Для этого требования нет применимых функций AKS.

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

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

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

• Настройте время ожидания сеанса в любом доступе к административной консоли, например в окнах перехода в CDE, чтобы свести к минимуму доступ.

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

  • Настройка управления сеансом проверки подлинности с условным доступом.
  • Настраиваемые сроки существования маркеров — платформа удостоверений Майкрософт

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

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

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

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

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