Поделиться через

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

  • Статья

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

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

Идентификаторы CIS Controls v8 Идентификатор (-ы) NIST SP 800-53 r4 Идентификаторы PCI-DSS версии 3.2.1
3.2, 3.7, 3.13 RA-2, SC-28 A3.2

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

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

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

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

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

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

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

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

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

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

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

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

Идентификаторы CIS Controls v8 Идентификатор (-ы) NIST SP 800-53 r4 Идентификаторы PCI-DSS версии 3.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, обнаружения угроз событий или обнаружения аномалий для оповещения об аномальной передаче информации, которая может указывать на несанкционированную передачу конфиденциальных данных.

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

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

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

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

Идентификаторы CIS Controls v8 Идентификатор (-ы) NIST SP 800-53 r4 Идентификаторы PCI-DSS версии 3.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 в служба хранилища Azure BLOB-объектов, Служба приложений приложениях и приложениях-функциях вместо использования обычной службы 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 Controls v8 Идентификатор (-ы) NIST SP 800-53 r4 Идентификаторы PCI-DSS версии 3.2.1
3.11 SC-28 3.4, 3.5

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

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

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

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

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

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

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

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

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

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

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

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

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

Идентификаторы CIS Controls v8 Идентификатор (-ы) NIST SP 800-53 r4 Идентификаторы PCI-DSS версии 3.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 также предоставляет возможность шифрования с помощью ключей, управляемых самостоятельно (управляемый клиентом главный ключ клиента, хранящийся в AWS служба управления ключами) для определенных служб.

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

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

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

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

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

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

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

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

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

Идентификаторы CIS Controls 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 для типов Azure Key Vault и уровня соответствия и проверки FIPS.

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

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

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

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

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

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

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

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

Примечание. Дополнительные сведения см. на уровне FIPS 140-2 для уровня соответствия FIPS в 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 и вашей службе на основе определенного расписания и при наличии выхода на пенсию или компрометации ключей.

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

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

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

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

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

Идентификаторы CIS Controls 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 и Cloud DNS и т. д. Вы также можете использовать службу центра сертификации для создания частного центра сертификации (ЦС) для подписывания частных сертификатов.

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

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

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

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

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

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

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

  • Реализуйте управление доступом с помощью политик RBAC в управляемом HSM Azure Key Vault на уровне ключа, чтобы обеспечить минимальные привилегии и разделение принципов обязанностей. Например, убедитесь, что разделение обязанностей выполняется для пользователей, которые управляют ключами шифрования, поэтому у них нет возможности доступа к зашифрованным данным и наоборот. Для Azure Key Vault уровня "Стандартный" и "Премиум" создайте уникальные хранилища для различных приложений, чтобы обеспечить минимальные привилегии и разделение принципов обязанностей.
  • Включите ведение журнала Azure Key Vault, чтобы обеспечить ведение журнала критически важных действий уровня управления и плоскости данных.
  • Защита Azure Key Vault с помощью Приватный канал и Брандмауэр Azure для обеспечения минимального воздействия службы
  • Используйте управляемое удостоверение для доступа к ключам, хранящимся в Azure Key Vault в приложениях рабочей нагрузки.
  • Перед очисткой фактических данных, резервных копий и архивов убедитесь, что ваши ключи не удалены.
  • Резервное копирование ключей и сертификатов с помощью Azure Key Vault. Включите обратимое удаление и защиту очистки, чтобы избежать случайного удаления ключей. Если ключи необходимо удалить, рассмотрите возможность отключения ключей вместо их удаления, чтобы избежать случайного удаления ключей и криптографических стирания данных.
  • Для создания собственных вариантов использования ключа (BYOK) создайте ключи в локальной среде HSM и импортируйте их, чтобы максимально увеличить время существования и переносимость ключей.
  • Никогда не хранить ключи в формате открытого текста за пределами Azure Key Vault. Ключи во всех службах хранилища ключей по умолчанию не экспортируются.
  • Используйте типы ключей с поддержкой 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 Certificate Manager (ACM) с помощью следующих элементов управления:

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

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

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

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

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

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

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

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