Защита данных в контролируемом кластере AKS для PCI-DSS 3.2.1 (часть 4 из 9)

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

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

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

Защита данных владельцев карт.

Требование 3. Защита сохраненных данных карта заполнителей

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

Требование	Обязанности
Требование 3.1	Сохраняйте хранилище данных карта заполнителя как минимум путем реализации политик хранения и удаления данных, процедур и процессов, которые включают по крайней мере следующее для всех хранилищ данных карта заполнителей (CHD):
Требование 3.2	Не сохраняйте конфиденциальные данные проверки подлинности после авторизации (даже если зашифровано). Если получены конфиденциальные данные аутентификации, сделайте все данные невосстановимыми после завершения процесса авторизации.
Требование 3.3	Маска PAN при отображении (первые шесть и последние четыре цифры являются максимальным числом отображаемых цифр), таким образом, что только персонал с законным бизнес-потребностью может видеть полный PAN.
Требование 3.4	Отрисовка PAN нечитаемая в любом месте хранения (включая переносимые цифровые носители, резервные носители и журналы) с помощью любого из следующих подходов:
Требование 3.5	Документируйте и реализуйте процедуры защиты ключей, используемых для защиты сохраненных карта заполнителей данных от раскрытия и неправильного использования:
Требование 3.6	Полностью документируйте и реализуйте все процессы и процедуры управления ключами для криптографических ключей, используемых для шифрования данных карта заполнителей, включая следующие:
Требование 3.7	Убедитесь, что политики безопасности и операционные процедуры защиты сохраненных карта заполнителей документируются, используются и известны всем пострадавшим сторонам.

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

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

Требование	Обязанности
Требование 4.1	Используйте надежные протоколы шифрования и безопасности (например, TLS, IPSEC, SSH и т. д.) для защиты конфиденциальных данных карта заполнителей во время передачи через открытые общедоступные сети, включая следующие:
Требование 4.2	Никогда не отправлять незащищенные PAN с помощью технологий обмена сообщениями конечных пользователей (например, электронной почты, обмена мгновенными сообщениями, SMS, чата и т. д.).
Требование 4.3	Убедитесь, что политики безопасности и операционные процедуры шифрования передач данных карта заполнителей документируются, используются и известны всем пострадавшим сторонам.

Требование 3.1

Сохраняйте хранилище данных карта заполнителя как минимум путем реализации политик хранения и удаления данных, процедур и процессов, которые включают по крайней мере следующее для всех хранилищ данных карта заполнителей (CHD):

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

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

Не сохраняйте состояние в кластере AKS. Если вы решили сохранить chD, изучите параметры безопасного хранилища. Варианты включают служба хранилища Azure для хранилища файлов или баз данных, таких как База данных SQL Azure или Azure Cosmos DB.

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

• Как и где хранятся данные?
• Зашифрованы ли сохраненные данные?
• Какой период хранения?
• Какие действия разрешены в течение периода хранения?
• Как удалить сохраненные данные после истечения срока хранения?

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

Просмотрите этот список определений политик и примените их к кластеру, если применимо.

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

При выборе технологии хранения изучите функции хранения. Например, Хранилище BLOB-объектов Azure предоставляет политики хранения на основе времени. Другой вариант — реализовать пользовательское решение, которое удаляет данные в соответствии с политиками хранения. Примером является управление жизненным циклом данных (DLM), которое управляет действиями жизненного цикла данных. Решение разработано с помощью таких служб, как Фабрика данных Azure, идентификатор Microsoft Entra и Azure Key Vault.

Дополнительные сведения см. в разделе "Управление жизненным циклом данных с помощью Фабрика данных Azure".

Требование 3.2

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

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

(ПРИМЕНИМО: требование 3.2.1, требование 3.2.2, требование 3.2.3)

Обработка и защита данных выходит за рамки область этой архитектуры. Ниже приведены некоторые общие рекомендации.

На основе стандартных конфиденциальных данных проверки подлинности содержатся данные полного отслеживания, карта код проверки или значение, а также данные ПИН-кода. В рамках обработки CHD убедитесь, что данные проверки подлинности не предоставляются в таких источниках, как:

• Журналы, создаваемые из модулей pod.
• Процедуры обработки исключений.
• Имена файлов.
• Cache.

Как общее руководство, торговцы не должны хранить эти сведения. Если требуется документ бизнес-обоснование.

Требование 3.3

Маска PAN при отображении (первые шесть и последние четыре цифры являются максимальным числом отображаемых цифр), таким образом, что только персонал с законным бизнес-потребностью может видеть полный PAN.

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

Основной номер учетной записи (PAN) считается конфиденциальными данными, и их необходимо предотвратить. Одним из способов является уменьшение отображаемых цифр путем маскирования.

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

Дополнительные сведения см. в разделе "Динамическое маскирование данных".

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

Требование 3.4

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

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

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

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

Соответствующие методы маскирования данных также соответствуют этому требованию. Вы несете ответственность за маскирование всех данных основной учетной записи (PAN). Строка служб SQL Azure, включая Azure Synapse Analytics, поддерживает динамическое маскирование данных. См . требование 3.3.

Убедитесь, что PAN не предоставляется в процессе рабочего процесса. Ниже приведены некоторые рекомендации.

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

• Не используйте PAN в качестве ключа подстановки кэша или в составе любого имени файла, созданного этим процессом.

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

Требование 3.4.1

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

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

Как правило, не сохраняйте состояние в кластере AKS. Используйте внешнее хранилище данных, которое поддерживает шифрование уровня хранилища.

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

С помощью служба хранилища Azure можно также использовать самоуправляемые ключи. Дополнительные сведения см. в разделе "Ключи, управляемые клиентом" для шифрования служба хранилища Azure.

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

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

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

Требование 3.5

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

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

Эти моменты описаны в подразделах:

• Соблюдайте практику доступа с минимальными привилегиями для криптографических ключей.
• Azure Key Vault и Идентификатор Microsoft Entra предназначены для поддержки требований авторизации и аудита. Дополнительные сведения см. в статье "Запрос проверки подлинности для Azure Key Vault".
• Защита всех ключей шифрования данных с помощью ключа шифрования ключа, хранящегося на криптографических устройствах.
• Если вы используете самоуправляемые ключи (вместо ключей, управляемых Корпорацией Майкрософт), у вас есть процесс и документация по обслуживанию задач, связанных с управлением ключами.

Требование 3.5.1

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

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

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

Одним из способов хранения конфиденциальной информации (ключей, строка подключения и других) является использование собственного ресурса KubernetesSecret. Необходимо явно включить шифрование неактивных данных. Кроме того, сохраните их в управляемом хранилище, например Azure Key Vault. Из двух подходов рекомендуется использовать службу управляемого хранилища. Одним из преимуществ является сокращение затрат на задачи, связанные с управлением ключами, например смена ключей.

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

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

Требование 3.5.2

Ограничить доступ к криптографическим ключам до наименьшего числа хранителей.

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

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

Требование 3.5.3

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

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

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

Рабочая нагрузка PCI-DSS 3.2.1 должна использовать несколько ключей шифрования в рамках стратегии защиты неактивных данных. Ключ шифрования данных (DEK) используется для шифрования и расшифровки chD, но вы несете ответственность за дополнительный ключ шифрования ключей (KEK) для защиты этого ключа DEK. Вы также несете ответственность за то, что KEK хранится на криптографических устройствах.

Azure Key Vault можно использовать для хранения deK и использования выделенного HSM Azure для хранения KEK. Дополнительные сведения об управлении ключами HSM см. в статье "Что такое выделенный HSM Azure?".

Требование 3.6

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

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

(ПРИМЕНИМО: требование 3.6.1, требование 3.6.2, требование 3.6.3, требование 3.2.4)

Если вы используете Azure Key Vault для хранения секретов, таких как ключи, сертификаты и строка подключения, защитите его от несанкционированного доступа. Microsoft Defender для Key Vault обнаруживает подозрительные попытки доступа и создает оповещения. Эти оповещения можно просмотреть в Microsoft Defender для облака. Дополнительные сведения см. в Microsoft Defender для Key Vault.

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

• Управление криптографическими ключами.
• Sp 800-133 ред. 2, рекомендация по поколению криптографических ключей
• SP 800-57 часть 1 ред. 5, рекомендация по управлению ключами

См. также Microsoft Defender для Key Vault.

Требование 3.6.7

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

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

• Включите диагностика во всех хранилищах ключей. Используйте Azure Monitor для Key Vault. Он собирает журналы и метрики и отправляет их в Azure Monitor. Дополнительные сведения см. в статье "Мониторинг службы хранилища ключей" с помощью Azure Monitor для Key Vault.
• Предоставьте разрешения только для чтения всем потребителям.
• Не имеют постоянных разрешений для всех субъектов-служб управления. Вместо этого используйте jIT-назначения ролей, активацию роли на основе времени и активацию роли на основе утверждения.
• Создание централизованного представления путем интеграции журналов и оповещений в решения для управления сведениями и событиями безопасности (SIEM), например Microsoft Sentinel.
• Выполните действия по оповещениям и уведомлениям, особенно при непредвиденных изменениях.

Требование 3.6.8

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

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

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

Требование 3.7

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

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

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

Важно обеспечить тщательную документацию по процессам и политикам. Несколько команд участвуют в защите неактивных данных и передаче. В документации предоставьте рекомендации по роли для всех пользователей. Роли должны включать SRE, поддержку клиентов, продажи, сетевые операции, операции безопасности, инженеры программного обеспечения, администраторы баз данных и другие. Персонал должен быть обучен в руководстве NIST и стратегиях хранения данных, чтобы обеспечить актуальность набора навыков. Требования к обучению рассматриваются в требованиях 6.5 и требования 12.6.

Требование 4.1

Используйте надежные протоколы шифрования и безопасности (например, TLS, IPSEC, SSH и т. д.), чтобы защитить конфиденциальные данные карта заполнителей во время передачи через открытые, общедоступные сети, в том числе следующие:

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

Данные держателя карт (CHD), передаваемые через общедоступный Интернет, должны быть зашифрованы. Данные должны быть зашифрованы с помощью TLS 1.2 (или более поздней версии) с уменьшенной поддержкой шифров для всех передач. Не поддерживайте перенаправления TLS без TLS в любых службах передачи данных.

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

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

• Запретить создание любого ресурса входящего трафика, отличного от HTTPS.
• Запретить создание общедоступного IP-адреса или любых общедоступных подсистем балансировки нагрузки в кластере, чтобы обеспечить туннелирование веб-трафика через шлюз.

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

Требование 4.1.1

Убедитесь, что беспроводные сети, передаваемые карта-заполнители или подключенные к среде данных карта, используйте отраслевые рекомендации (например, IEEE 802.11i) для реализации строгого шифрования для проверки подлинности и передачи.

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

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

Требование 4.2

Никогда не отправлять незащищенные PAN с помощью технологий обмена сообщениями конечных пользователей (например, электронной почты, обмена мгновенными сообщениями, SMS, чата и т. д.).

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

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

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

Рекомендации см. в официальном стандарте PCI-DSS 3.2.1.

Требование 4.3

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

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

Важно обеспечить тщательную документацию по процессам и политикам. Это особенно верно, если вы управляете политиками по протоколу TLS. Ниже приведены некоторые области:

• Общедоступные точки входящего интернета. Примером является Шлюз приложений Azure поддержка шифров TLS.
• Сетевые прыжки между сетями периметра и модулями pod рабочей нагрузки.
• Шифрование pod -to-pod (если оно реализовано). Это может включать сведения о конфигурации сетки служб.
• Pod в хранилище (если часть архитектуры).
• Pod для внешних служб, служб Azure PaaS, использующих TLS, шлюз платежей или систему обнаружения мошенничества.

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

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

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