Управление ключами и сертификатами в Microsoft Cloud for Sovereignty
Криптографическая аутентификация и шифрование являются эффективными стратегиями обеспечения требований конфиденциальности, защиты и суверенитета данных. Однако эффективность этих решений зависит от безопасности и устойчивости базовых криптографических технологий и операционных процессов. В этой статье представлены концепции, с которыми вам следует ознакомиться при планировании использования ключей шифрования и цифровых сертификатов для защиты рабочих нагрузок, переносимых в облако.
Управление ключами
Криптографические материалы хранятся и управляются в Azure с помощью Azure Key Vault, которое доступно как в мультиклиентском, так и в одноклиентском режимах развертывания. Azure Key Vault (AKV) обеспечивает собственное облачное управление ключами, секретами и сертификатами в службе, поддерживающей архитектуру обслуживания одним экземпляром приложения нескольких развертываний, поддерживаемой аппаратными модулями безопасности, проверенными по стандарту FIPS 140. Управляемый HSM Azure Key Vault — это служба с одним клиентом, которая предоставляет вам полный административный контроль над доменом безопасности вашей организации и связанными ключами шифрования.
Рекомендации по эффективному управлению ключами
Элементы управления платформой, хотя и являются обязательными, не являются единственным аспектом эффективного управления ключами. Microsoft также представляет несколько рекомендаций по эффективному управлению ключами.
Элементы управление доступом
Если вы используете номера Azure Key Vault SKU Standard или Premium, мы рекомендуем развернуть одно хранилище для каждого приложения, среды и региона, чтобы обеспечить соблюдение минимальных привилегий. Если вы используете управляемый модуль HSM, для управления затратами может быть предпочтительнее развернуть меньшее количество централизованных хранилищ. Независимо от развертываемого SKU, вы должны строго регулировать доступ к хранилищу с помощью управления доступом на основе ролей (RBAC) и гарантировать, что политики доступа в каждом хранилище соответствуют принципу наименьших привилегий. Мы рекомендуем предоставлять доступ пользователям, группам и приложениям в определенной области, например подписке, группе ресурсов или просто определенному хранилищу ключей, используя предопределенные роли RBAC в Azure. Контроль доступа имеет решающее значение и рекомендуется в плоскости управления и данных.
Резервное копирование и восстановление
Вам необходимо иметь регулярные резервные копии на уровне HSM и для определенных ключей. Мы рекомендуем вам настроить функции обратимого удаления и защиты от очистки для предохранения от случайного и злонамеренного удаления. Azure Monitor, полностью интегрированный с управляемым модулем HSM, рекомендуется для мониторинга и регистрации доступа к хранилищам ключей. Дополнительные сведения см. в разделе Рекомендации по управляемому модулю HSM в Azure.
Ротация ключей
Убедитесь, что выполняется регулярная ротация ключей, управляемых клиентом (CMK), с частотой, определяемой политикой вашей организации. Ключи также следует менять, если Администратор с доступом к ключам увольняется или меняет роль, или если какой-либо CMK скомпрометирован. Авторотация поддерживается через Хранилище ключей Azure и управляемый модуль HSM в Azure. По возможности убедитесь, что процесс ротации автоматизирован, выполняется без участия человека и проверен на предмет эффективности. В чрезвычайных ситуациях, таких как компрометация ключа, вам нужна надежная система для немедленного восстановления секретов. Если автоматизация этого процесса невозможна, мы рекомендуем настроить оповещения, чтобы предотвратить истечение срока действия сертификата и сбои в работе.
Заметка
Хотя ротация CMK для конфиденциальных виртуальных машин поддерживается, процесс автоматизации пока не поддерживается. Рекомендации можно посмотреть здесь.
Рекомендации связанные с HSM
Некоторые клиенты выражают заинтересованность в том, чтобы хранить свои ключи отдельно от данных, сохраняя ключи во внешнем модуле HSM, либо в стороннем облаке, либо локально. Хотя этот шаг может показаться естественным переходом от управления локальными средами, внешний модуль HSM может создать новые риски на уровнях идентификации, сети и программного обеспечения. Внешний модуль HSM может также увеличить риски производительности и вызвать такие проблемы, как проблемы с сетью, вызывающие задержки, проблемы с соглашением об уровне обслуживания, вызванные проблемами со сторонним модулем HSM, а также затраты на обслуживание и обучение. Кроме того, сторонние модули HSM могут не предоставлять важные функции, такие как обратимое удаление и защита от очистки.
Дополнительную информацию о технических средствах управления, встроенных в Суверенную целевую зону (SLZ) для соблюдения соответствующих практик управления ключами, см. в статье Портфель политики.
Управление сертификатами
Сертификаты цифровой безопасности широко используются для защиты связи в облачных приложениях. Накладные расходы, связанные с деятельностью по управлению сертификатами, включая выдачу, ротацию и отзыв сертификатов, могут быстро расти по мере переноса большего количества рабочих нагрузок в облако. Клиенты, планирующие перенести свои рабочие нагрузки в Microsoft Cloud for Sovereignty, должны понимать сценарии использования цифровых сертификатов безопасности, чтобы иметь возможность разработать планы управления сертификатами в рамках миграции в облако.
Распространенные сценарии использования цифровых сертификатов
В этом разделе описаны распространенные облачные сценарии, в которых для защиты связи используются цифровые сертификаты.
Аутентификация и шифрование веб-сайта
Веб-сайты используют сертификаты TLS для подтверждения своего удостоверения посетителям и для шифрования сообщений. Общедоступные веб-сайты обычно используют сертификаты общедоступных центров сертификации (ЦС), но организации часто используют сертификаты частного ЦС для веб-сайтов, которые не доступны для общественности. В любом случае сертификаты веб-сайтов необходимо обновлять по истечении срока их действия или когда целостность сертификата оказывается под вопросом. Для организаций с большим присутствием в Интернете управление этими сертификатами может потребовать значительного планирования и усилий.
Проверка подлинности служб
Распределенные приложения и микрослужбы часто используют модель сеанса без отслеживания состояния, которая обеспечивает гибкость в обработке запросов приложений, но также может потребовать дополнительной аутентификации и шифрования для снижения рисков безопасности. Сертификаты часто используются для взаимной аутентификации между уровнями приложений и компонентами. Часто этими компонентами управляют децентрализованные группы разработчиков приложений, что затрудняет отслеживание и мониторинг управления цифровыми сертификатами на предприятии.
Аутентификация инфраструктуры
Серверы и сетевые устройства часто используют клиентские сертификаты для аутентификации в корпоративной сети и во время обслуживания. Организациям, использующим такие решения, как Active Directory или Kerberos, обычно приходится управлять клиентскими сертификатами для своей развернутой инфраструктуры.
Другие сценарии с сертификатами
Решения по управлению конечными точками часто используют сертификаты устройств для аутентификации устройств конечных пользователей, таких как ПК, ноутбуки и мобильные устройства. Сертификаты подписи кода используются в средах разработки для проверки издателя программного обеспечения в рамках подхода организации к обеспечению безопасности приложений.
Управление жизненным циклом сертификатов в облаке
Сертификаты, управляемые платформой, и сертификаты, управляемые клиентом
Службы Azure PaaS, обеспечивающие шифрование передаваемых данных, обычно реализуют шифрование с использованием цифровых сертификатов, управляемых платформой и связанных с именем узла по умолчанию, которое назначается при создании ресурса. Если вы хотите использовать собственное доменное имя с ресурсами, которые вы развертываете в облаке, вам необходимо настроить сертификат, который смогут использовать внешние пользователи при доступе к службе. Для внутрисервисного взаимодействия между службами Azure, которые не настроены на использование личных доменных имен, сертификаты, управляемые платформой, являются средством по умолчанию для шифрования данных при передаче. Если вы хотите использовать сертификаты, связанные с именами личных доменов, см. документацию по службам Azure, которые вы планируете развернуть, например следующие примеры.
- Пользовательские домены в службе приложений Azure
- Пользовательские домены в приложениях-контейнерах Azure
Создание сертификатов с Azure Key Vault
Azure Key Vault предоставляет клиентам облачные функции управления сертификатами, которые позволяют платформе Azure использовать сертификаты, созданные или импортированные клиентами. Вы можете создать самозаверяющие сертификаты в Key Vault, запросить сертификат у издателя или импортировать сертификат из собственного центра сертификации. Key Vault также помогает указать политики для сертификатов, например, можно ли сделать сертификаты экспортируемыми или неэкспортируемыми.
- Начало работы с сертификатами Key Vault
- Интеграция Key Vault с интегрированными центрами сертификации
- Создание и объединение запроса на подпись сертификата в Key Vault
Создание локальных сертификатов и управление ими в Azure
Если вы хотите выдавать сертификаты из локального центра сертификации, вы можете импортировать эти сертификаты в Azure Key Vault для использования другими службами Azure. После экспорта сертификата в виде файла PEM или PFX его можно импортировать в Azure Key Vault.
Локальное создание сертификатов и управление ими с помощью сторонних решений
Организации, у которых уже есть возможности управления сертификатами корпоративного уровня, могут рассмотреть возможность интеграции своих локальных решений со своими рабочими нагрузками в облаке. Многие локальные центры сертификации и решения по управлению сертификатами могут интегрироваться с Key Vault с помощью REST API и управляемых удостоверений.
Децентрализованное управление сертификатами
Одним из подходов к масштабированию возможностей управления сертификатами организации является децентрализация выдачи сертификатов и управления ими для рабочих групп приложений и инфраструктуры. Такие решения, как Azure Key Vault, позволяют организации стандартизировать приемлемые технологии и процессы управления ключами без централизации администрирования этих процессов управления ключами в одной операционной группе. Можно использовать несколько стратегий, чтобы делегировать обязанности по управлению ключами ближе к рабочим группам приложений и инфраструктуры.
Управляемые сертификаты
Общедоступные веб-сайты, которым требуются сертификаты из общедоступного центра сертификации, могут использовать преимущества управляемых сертификатов в службах Azure PaaS, таких как Служба приложений Azure или Azure Front Door. Сертификаты интегрированных центров сертификации также можно создавать, управлять ими и чередовать их в Azure Key Vault. Дополнительные сведения см. на следующих ресурсах:
- Пользовательские домены и сертификаты в службе приложений Azure
- Пользовательские домены в Azure Front Door
- Интеграция Key Vault с центром сертификации DigiCert
Автоматизация выдачи сертификатов в конвейерах CI/CD
Организации, внедряющие процессы Dev/Ops, могут автоматизировать выдачу сертификатов в рамках своих конвейеров CI/CD. Этот подход делегирует некоторые обязанности по управлению сертификатами рабочим группам приложений и позволяет им предоставлять свои собственные сертификаты с помощью собственных служб Azure, таких как Azure DNS, Служба приложений Azure и Azure Key Vault.
Управление сертификатами конечных точек
Сертификаты конечных точек используются в рабочих нагрузках IaaS, где серверы и службы используют сертификаты для аутентификации. Поскольку этот сценарий связан с виртуальными машинами, организации могут управлять этими сертификатами с помощью тех же инструментов управления конфигурацией или создавать инструменты автоматизации, которые используются для управления конфигурациями виртуальных машин.