Управление безопасностью: защита данных

  • Статья

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

DP-1. Обнаружение, классификация конфиденциальных данных и добавление к ним тегов

Идентификаторы элементов управления CIS v8 Идентификатор (-ы) NIST SP 800-53 r4 Идентификаторы PCI-DSS v3.2.1
3.2, 3.7, 3.13 RA-2, SC-28 A3.2

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

Руководство По Azure. Используйте такие средства, как Microsoft Purview, которая объединяет ранее решения azure Purview и Microsoft 365 для соответствия требованиям, а также Azure SQL обнаружение и классификация данных для централизованного сканирования, классификации и маркировки конфиденциальных данных, которые находятся в Azure, локальной среде, Microsoft 365 и других расположениях.

Реализация Azure и дополнительный контекст:

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

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

Примечание. Вы также можете использовать сторонние корпоративные решения из AWS Marketplace для классификации и маркировки данных.

Реализация AWS и дополнительный контекст:

Руководство GCP. Используйте такие средства, как Google Cloud Data Loss Prevention, для централизованного сканирования, классификации и маркировки конфиденциальных данных, которые находятся в GCP и локальных средах.

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

Реализация GCP и дополнительный контекст:

Заинтересованные лица, заинтересованные в обеспечении безопасности клиентов (дополнительные сведения):

DP-2: отслеживание аномалий и угроз, нацеленных на конфиденциальные данные

Идентификаторы элементов управления CIS v8 Идентификатор (-ы) NIST SP 800-53 r4 Идентификаторы PCI-DSS v3.2.1
3.13 AC-4, SI-4 A3.2

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

Руководство по Azure. Используйте Azure Information Protection (AIP) для мониторинга данных, которые были классифицированы и помечены.

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

Примечание. Если требуется для обеспечения соответствия требованиям защиты от потери данных (DLP), можно использовать решение защиты от потери данных на основе узла из Azure Marketplace или решение Microsoft 365 для защиты от потери данных, чтобы применить средства обнаружения и (или) профилактические элементы управления для предотвращения кражи данных.

Реализация Azure и дополнительный контекст:

Руководство AWS. Используйте AWS Macie для мониторинга данных, которые были классифицированы и помечены, и GuardDuty для обнаружения аномальных действий в некоторых ресурсах (S3, EC2, Kubernetes или IAM). Результаты и оповещения можно рассматривать, анализировать и отслеживать с помощью EventBridge и пересылать в Microsoft Sentinel или Центр безопасности для агрегирования и отслеживания инцидентов.

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

Примечание. Если это необходимо для обеспечения соответствия требованиям защиты от потери данных (DLP), можно использовать решение защиты от потери данных на основе узла из AWS Marketplace.

Реализация AWS и дополнительный контекст:

Руководство GCP. Используйте Google Cloud Security Command Center/Event Threat Detection/Anomaly Detection для оповещения об аномальной передаче информации, которая может указывать на несанкционированную передачу конфиденциальных данных.

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

Реализация GCP и дополнительный контекст:

Заинтересованные лица, заинтересованные в обеспечении безопасности клиентов (дополнительные сведения):

DP-3: шифрование передаваемых конфиденциальных данных

Идентификаторы элементов управления CIS v8 Идентификатор (-ы) NIST SP 800-53 r4 Идентификаторы PCI-DSS v3.2.1
3.10 SC-8 3.5, 3.6, 4.1

Принцип безопасности. Защитите передаваемые данные от «внеполосных» атак (таких как захват трафика) с помощью шифрования, чтобы злоумышленники не могли легко прочитать или изменить данные.

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

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

Принудительно применяйте ПРОТОКОЛ HTTPS для рабочих нагрузок и служб веб-приложений, гарантируя, что все клиенты, подключающиеся к ресурсам Azure, используют протокол TLS версии 1.2 или более поздней. Для удаленного управления виртуальными машинами вместо незашифрованного протокола используйте SSH (для Linux) или RDP/TLS (для Windows).

Для удаленного управления виртуальными машинами Azure вместо незашифрованного протокола используйте SSH (для Linux) или RDP/TLS (для Windows). Для безопасной передачи файлов используйте службу SFTP/FTPS в хранилище BLOB-объектов Azure, Служба приложений приложения и приложения-функции вместо обычной службы FTP.

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

Реализация Azure и дополнительный контекст:

Руководство AWS. Принудительное безопасное перемещение в таких службах, как Amazon S3, RDS и CloudFront, где встроена встроенная функция шифрования данных при передаче.

Примените протокол HTTPS (например, в AWS Elastic Load Balancer) для веб-приложений и служб рабочей нагрузки (на стороне сервера или на стороне клиента или на обеих сторонах), гарантируя, что все клиенты, подключающиеся к ресурсам AWS, используют TLS версии 1.2 или более поздней версии.

Для удаленного управления экземплярами EC2 вместо незашифрованного протокола используйте SSH (для Linux) или RDP/TLS (для Windows). Для безопасной передачи файлов используйте службу AWS Transfer SFTP или FTPS вместо обычной службы FTP.

Примечание. Весь сетевой трафик между центрами обработки данных AWS прозрачно шифруется на физическом уровне. Весь трафик в пределах VPC и между одноранговыми виртуальными машинами в разных регионах прозрачно шифруется на сетевом уровне при использовании поддерживаемых типов экземпляров Amazon EC2. Протокол TLS версии 1.2 или более поздней по умолчанию включен в большинстве служб AWS. Некоторые службы, такие как AWS Load Balancer, могут применять ПРОТОКОЛ TLS версии 1.2 или более поздней версии на стороне сервера.

Реализация AWS и дополнительный контекст:

Руководство по GCP. Обеспечьте безопасную передачу в службах, таких как Google Cloud Storage, где встроена встроенная функция шифрования данных при передаче.

Примените ПРОТОКОЛ HTTPS для рабочих нагрузок и служб веб-приложений, чтобы все клиенты, подключающиеся к ресурсам GCP, использовали протокол TLS версии 1.2 или более поздней.

Для удаленного управления Google Cloud Compute Engine используйте SSH (для Linux) или RDP/TLS (для Windows) вместо незашифрованного протокола. Для безопасной передачи файлов используйте службу SFTP/FTPS в таких службах, как Google Cloud Big Query или Cloud App Engine, вместо обычной службы FTP.

Реализация GCP и дополнительный контекст:

Заинтересованные лица по обеспечению безопасности клиентов (подробнее):

DP-4: включение шифрования неактивных данных по умолчанию

Идентификаторы элементов управления CIS v8 Идентификатор (-ы) NIST SP 800-53 r4 Идентификаторы PCI-DSS v3.2.1
3.11 SC-28 3.4, 3.5

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

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

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

Реализация Azure и дополнительный контекст:

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

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

Реализация AWS и дополнительный контекст:

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

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

Примечание. Дополнительные сведения см. в документе "Степень детализации шифрования для служб Google Cloud".

Реализация GCP и дополнительный контекст:

Заинтересованные лица по обеспечению безопасности клиентов (подробнее):

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

Идентификаторы элементов управления CIS v8 Идентификатор (-ы) NIST SP 800-53 r4 Идентификаторы PCI-DSS v3.2.1
3.11 SC-12, SC-28 3.4, 3.5, 3.6

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

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

Azure Key Vault уровня "Стандартный", "Премиум" и управляемый модуль HSM изначально интегрированы со многими службами Azure для сценариев использования ключей, управляемых клиентом. Вы можете использовать azure Key Vault для создания ключа или использования собственных ключей.

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

Реализация Azure и дополнительный контекст:

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

Служба управления ключами AWS (KMS) изначально интегрирована со многими службами AWS для управляемых клиентом master ключевых вариантов использования. Вы можете использовать службу управления ключами AWS (KMS) для создания ключей master или использовать собственные ключи.

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

Реализация AWS и дополнительный контекст:

Руководство по GCP. Google Cloud предоставляет возможность шифрования с помощью ключей, управляемых вами (ключей, управляемых клиентом) для большинства служб.

Служба google Cloud Key Management Service (Cloud KMS) изначально интегрирована со многими службами GCP для ключей шифрования, управляемых клиентом. Эти ключи можно создавать и управлять ими с помощью cloud KMS, а также хранить их в виде программных ключей, в кластере HSM или за пределами. Вы можете использовать Cloud KMS для создания ключа или предоставления собственных ключей (предоставленных клиентом ключей шифрования).

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

Реализация GCP и дополнительный контекст:

Заинтересованные лица по обеспечению безопасности клиентов (подробнее):

DP-6: безопасное управление ключами

Идентификаторы элементов управления CIS v8 Идентификатор (-ы) NIST SP 800-53 r4 Идентификаторы PCI-DSS версии 3.2.1
Н/Д IA-5, SC-12, SC-28 3,6

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

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

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

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

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

Примечание. Ниже приведены сведения об уровне FIPS 140-2 для типов Key Vault Azure и уровне соответствия и проверки FIPS.

  • Ключи, защищенные программным обеспечением, в хранилищах (номера SKU уровня "Премиум & Стандартный")): FIPS 140-2 уровня 1
  • Ключи, защищенные модулем HSM, в хранилищах (цен. категория "Премиум"): FIPS 140-2, уровень 2
  • Ключи, защищенные модулем HSM, в управляемом модуле HSM: FIPS 140-2, уровень 3

Azure Key Vault Premium использует общую инфраструктуру HSM в серверной части. Управляемый модуль HSM Azure Key Vault использует выделенные конфиденциальные конечные точки служб с выделенным HSM, когда требуется более высокий уровень безопасности ключей.

Реализация Azure и дополнительный контекст:

Руководство по AWS. Используйте службу управления ключами AWS (KMS) для создания и управления жизненным циклом ключей шифрования, включая создание, распространение и хранение ключей. Смена и отзыв ключей в KMS и службе в соответствии с определенным расписанием, а также в случае прекращения использования или компрометации ключа.

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

  • Используйте иерархию ключей для создания отдельного ключа шифрования данных (DEK) с ключом шифрования ключей (KEK) в KMS.
  • Убедитесь, что ключи зарегистрированы в KMS и реализуются с помощью политик IAM в каждой службе или приложении.

Чтобы максимально увеличить время существования и переносимость материала ключа, добавьте собственный ключ (BYOK) в службы (т. е. импорт ключей, защищенных HSM, из локальных модулей HSM в KMS или Cloud HSM). Следуйте рекомендуемой инструкции для создания и передачи ключей.

Примечание. AWS KMS использует общую инфраструктуру HSM в серверной части. Используйте пользовательское хранилище ключей AWS KMS, поддерживаемое AWS CloudHSM, когда вам нужно управлять собственным хранилищем ключей и выделенными модулями HSM (например, нормативными требованиями для более высокого уровня безопасности ключей) для создания и хранения ключей шифрования.

Примечание. Сведения об уровне соответствия FIPS 140-2 в AWS KMS и CloudHSM см. ниже:

  • AWS KMS по умолчанию: проверка FIPS 140-2 уровня 2
  • AWS KMS с использованием CloudHSM: проверка FIPS 140-2 уровня 3 (для определенных служб)
  • AWS CloudHSM: проверка FIPS 140-2 уровня 3

Примечание. Для управления секретами (учетные данные, пароль, ключи API и т. д.) используйте диспетчер секретов AWS.

Реализация AWS и дополнительный контекст:

Руководство GCP. Используйте облачную службу управления ключами (Cloud KMS) для создания жизненных циклов ключей шифрования и управления ими в совместимых облачных службах Google и приложениях рабочей нагрузки. Смена и отзыв ключей в Cloud KMS и вашей службе в соответствии с определенным расписанием и в случае прекращения использования или компрометации ключа.

Используйте облачную службу HSM Google для предоставления аппаратных ключей в Cloud KMS (служба управления ключами). Это позволяет управлять и использовать собственные криптографические ключи при защите с помощью полностью управляемых аппаратных модулей безопасности (HSM).

Облачная служба HSM использует модули HSM, проверенные fips 140-2 уровня 3 и всегда работающие в режиме FIPS. FiPS 140-2 уровня 3 проверяется и всегда работает в режиме FIPS. Стандарт FIPS определяет алгоритмы шифрования и генерацию случайных чисел, используемых модулями HSM.

Реализация GCP и дополнительный контекст:

Заинтересованные лица по обеспечению безопасности клиентов (подробнее):

DP-7: безопасное управление сертификатами

Идентификаторы элементов управления CIS v8 Идентификатор (-ы) NIST SP 800-53 r4 Идентификаторы PCI-DSS версии 3.2.1
Н/Д IA-5, SC-12, SC-17 3,6

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

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

Руководство по Azure. Используйте azure Key Vault для создания и управления жизненным циклом сертификата, включая создание и импорт, смену, отзыв, хранение и очистку сертификата. Убедитесь, что создание сертификата соответствует заданному стандарту и не используются небезопасные свойства, такие как недостаточный размер ключа, слишком длинный срок действия, незащищенное шифрование и т. д. Настройте автоматическую смену сертификата в Azure Key Vault и поддерживаемых службах Azure в соответствии с определенным расписанием и по истечении срока действия сертификата. Если автоматическая смена не поддерживается во интерфейсном приложении, используйте ротацию вручную в Azure Key Vault.

Избегайте использования самозаверяющего сертификата и подстановочного сертификата в критически важных службах из-за ограниченной гарантии безопасности. Вместо этого можно создавать общедоступные подписанные сертификаты в Azure Key Vault. Следующие центры сертификации (ЦС) являются партнерскими поставщиками, которые в настоящее время интегрированы с Azure Key Vault.

  • DigiCert, из которого Azure Key Vault предоставляет сертификаты OV TLS/SSL.
  • GlobalSign, из которого Azure Key Vault предоставляет сертификаты OV TLS/SSL.

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

Реализация Azure и дополнительный контекст:

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

Избегайте использования самозаверяющего сертификата и подстановочного сертификата в критически важных службах из-за ограниченной гарантии безопасности. Вместо этого создайте общедоступные подписанные сертификаты (подписанные Центром сертификации Amazon) в ACM и разверните их программным способом в таких службах, как CloudFront, Load Balancers, ШЛЮЗ API и т. д. Вы также можете использовать ACM для создания частного центра сертификации (ЦС) для подписывания частных сертификатов.

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

Реализация AWS и дополнительный контекст:

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

Избегайте использования самозаверяющего сертификата и подстановочного сертификата в критически важных службах из-за ограниченной гарантии безопасности. Вместо этого вы можете создавать подписанные общедоступные сертификаты в диспетчере сертификатов и развертывать их программным способом в таких службах, как Load Balancer, облачная служба DNS и т. д. Службу центра сертификации также можно использовать для создания частного центра сертификации (ЦС) для подписывания частных сертификатов.

Примечание. Вы также можете использовать Google Cloud Secret Manager для хранения сертификатов TLS.

Реализация GCP и дополнительный контекст:

Заинтересованные лица по обеспечению безопасности клиентов (подробнее):

DP-8: обеспечение безопасности репозитория ключей и сертификатов

Идентификаторы элементов управления CIS v8 Идентификатор (-ы) NIST SP 800-53 r4 Идентификаторы PCI-DSS версии 3.2.1
Н/Д IA-5, SC-12, SC-17 3,6

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

Руководство Azure. Защита криптографических ключей и сертификатов путем усиления защиты службы azure Key Vault с помощью следующих элементов управления:

  • Реализуйте управление доступом с помощью политик RBAC в Azure Key Vault управляемого устройства HSM на уровне ключей, чтобы обеспечить соблюдение принципов наименьших привилегий и разделения обязанностей. Например, обеспечьте разделение обязанностей для пользователей, которые управляют ключами шифрования, чтобы у них не было возможности доступа к зашифрованным данным, и наоборот. Для Azure Key Vault уровня "Стандартный" и "Премиум" создайте уникальные хранилища для разных приложений, чтобы обеспечить соблюдение принципов наименьших привилегий и разделения обязанностей.
  • Включите ведение журнала azure Key Vault, чтобы обеспечить ведение журнала критически важных действий плоскости управления и плоскости данных.
  • Защита Key Vault Azure с помощью Приватный канал и Брандмауэр Azure для обеспечения минимальной уязвимости службы
  • Используйте управляемое удостоверение для доступа к ключам, хранящимся в Azure Key Vault в приложениях рабочей нагрузки.
  • Перед очисткой фактических данных, резервных копий и архивов убедитесь, что ваши ключи не удалены.
  • Создайте резервную копию ключей и сертификатов с помощью azure Key Vault. Включите обратимое удаление и защиту от очистки, чтобы избежать случайного удаления ключей. Если необходимо удалить ключи, рассмотрите возможность отключения ключей вместо их удаления, чтобы избежать случайного удаления ключей и криптографического удаления данных.
  • Для вариантов использования собственных ключей (BYOK) создайте ключи в локальном устройстве HSM и импортируйте их, чтобы максимально увеличить время существования и переносимость ключей.
  • Никогда не храните ключи в формате открытого текста за пределами Key Vault Azure. Ключи во всех службах хранилища ключей не экспортируются по умолчанию.
  • Используйте типы ключей на основе HSM (RSA-HSM) в Azure Key Vault Premium и Управляемом устройстве HSM Azure для защиты оборудования и самых надежных уровней FIPS.

Включите Microsoft Defender для Key Vault, чтобы получить ориентированную на Azure расширенную защиту от угроз для Azure Key Vault и обеспечить дополнительный уровень аналитики безопасности.

Реализация Azure и дополнительный контекст:

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

  • Реализуйте управление доступом с помощью ключевых политик (управление доступом на уровне ключей) в сочетании с политиками IAM (управление доступом на основе удостоверений), чтобы обеспечить соблюдение принципов наименьших привилегий и разделения обязанностей. Например, обеспечьте разделение обязанностей для пользователей, которые управляют ключами шифрования, чтобы у них не было возможности доступа к зашифрованным данным, и наоборот.
  • Используйте элементы управления детективом, такие как CloudTrails, для регистрации и отслеживания использования ключей в KMS и оповещения о критических действиях.
  • Никогда не храните ключи в формате открытого текста за пределами KMS.
  • Если ключи необходимо удалить, рекомендуется отключить ключи в KMS, а не удалять их, чтобы избежать случайного удаления ключей и криптографического стирания данных.
  • Перед очисткой фактических данных, резервных копий и архивов убедитесь, что ваши ключи не удалены.
  • Для вариантов использования собственных ключей (BYOK) создайте ключи в локальном устройстве HSM и импортируйте их, чтобы максимально увеличить время существования и переносимость ключей.

Для обеспечения безопасности сертификатов защитите сертификаты путем усиления защиты службы ДИСПЕТЧЕРа сертификатов AWS (ACM) с помощью следующих элементов управления:

  • Реализуйте управление доступом с помощью политик уровня ресурсов в сочетании с политиками IAM (управление доступом на основе удостоверений), чтобы обеспечить соблюдение принципов наименьших привилегий и разделения обязанностей. Например, обеспечьте разделение обязанностей для учетных записей пользователей: учетные записи пользователей, создающие сертификаты, отделены от учетных записей пользователей, которым требуется доступ только для чтения к сертификатам.
  • Используйте элементы управления для обнаружения, такие как CloudTrails, для регистрации и отслеживания использования сертификатов в ACM и оповещения о критических действиях.
  • Следуйте указаниям по безопасности KMS, чтобы защитить закрытый ключ (созданный для запроса сертификата), используемый для интеграции сертификата службы.

Реализация AWS и дополнительный контекст:

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

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

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

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

Реализация GCP и дополнительный контекст:

Заинтересованные лица, заинтересованные в обеспечении безопасности клиентов (дополнительные сведения):