Безопасность Azure Key Vault
Azure Key Vault защищает криптографические ключи, сертификаты (и связанные с ними закрытые ключи) и секреты (например, строки подключения и пароли) в облаке. Однако при хранении конфиденциальных и критически важных для бизнеса данных вы должны предпринять шаги для обеспечения максимальной безопасности ваших хранилищ и данных, хранящихся в них.
В этой статье даны общие сведения о функциях безопасности и рекомендации для Azure Key Vault.
Примечание.
Полный список рекомендаций по безопасности Azure Key Vault см. в Базовом плане безопасности для Azure Key Vault.
Безопасность сети
Вы можете снизить уязвимость хранилищ, указав IP-адреса, к которым они имеют доступ. Конечные точки служб для виртуальной сети для Azure Key Vault позволяют ограничить доступ к определенной виртуальной сети. Также эти конечные точки позволяют ограничить доступ определенным набором диапазонов адресов IPv4 (протокол IP версии 4). Для любого пользователя при попытке подключения к хранилищу ключей из любых других расположений доступ будет отклонен. Для получения полной информации см. Конечные точки службы виртуальной сети для службы Azure Key Vault
После того как правила брандмауэра вступают в действие, пользователи могут считывать данные только из Key Vault, если их запросы исходят из разрешенных виртуальных сетей или диапазонов IPv4-адресов. Это относится и к получению доступа к Key Vault с портала Azure. Пользователь сможет перейти в хранилище ключей с портала Azure, но не сможет получить список ключей, секретов и сертификатов, если клиентский компьютер не включен в список разрешенных. Инструкции по внедрению даны в разделе Настройка брандмауэров и виртуальных сетей Azure Key Vault.
Приватный канал Azure обеспечивает доступ к Azure Key Vault и к размещенным в Azure службам клиентов или партнеров через частную конечную точку виртуальной сети. Частная конечная точка Azure — это сетевой интерфейс, который защищенно и надежно подключается к службе через Приватный канал Azure. Частная конечная точка использует частный IP-адрес из виртуальной сети, по сути перемещая службу в виртуальную сеть. Весь трафик к службе может маршрутизироваться через частную конечную точку, поэтому шлюзы, устройства преобразования сетевых адресов (NAT), подключения ExpressRoute и VPN, а также общедоступные IP-адреса не требуются. Трафик между виртуальной сетью и службой проходит через магистральную сеть Майкрософт. Это позволяет избежать рисков общедоступного Интернета. Вы можете подключиться к экземпляру ресурса Azure, обеспечивая наивысшую степень детализации в управлении доступом. Пошаговые инструкции см. в разделе Интеграция Key Vault с Azure Private Link
TLS и HTTPS
- Внешний интерфейс Key Vault (плоскость данных) представляет собой многоклиентский сервер. Это означает, что хранилища ключей от разных клиентов могут использовать один и тот же общедоступный IP-адрес. Для обеспечения изоляции каждый HTTP-запрос проходит процедуру проверки подлинности и авторизуется независимо от других запросов.
- Протокол HTTPS позволяет клиенту участвовать в согласовании TLS. Клиенты могут применять версию TLS, и всякий раз, когда клиент делает это, все подключение будет использовать соответствующую защиту уровня. Key Vault поддерживает версии протокола TLS 1.2 и 1.3.
Примечание.
Вы можете отслеживать версию TLS, используемую клиентами, отслеживая журналы Key Vault с примером запроса Kusto здесь.
Параметры проверки подлинности службы Key Vault
При создании хранилища ключей в подписке Azure он автоматически связывается с клиентом Microsoft Entra подписки. Все вызывающие объекты в обеих плоскостях должны быть зарегистрированы в этом арендаторе, а также пройти аутентификацию, чтобы получить доступ к этому хранилищу ключей. В обоих случаях приложения могут получить доступ к Key Vault тремя способами:
- Только для приложения: приложение представляет субъект-службу или управляемое удостоверение. Данный идентификатор является наиболее распространенным сценарием для приложений, которым периодически требуется доступ к сертификатам, ключам или секретам из хранилища ключей. Для корректной работы данного сценария
objectId
приложения должен быть указан в политике доступа, аapplicationId
не должен указываться или должен бытьnull
. - Только для пользователя: пользователь получает доступ к хранилищу ключей из любого приложения, зарегистрированного в клиенте. Такой доступ осуществляется с помощью Azure PowerShell и портала Azure. Для корректной работы данного сценария
objectId
пользователя должен быть указан в политике доступа, аapplicationId
не должен указываться или должен бытьnull
. - Приложение плюс пользователь (иногда такая схема называется составным идентификатором): пользователь должен получить доступ к хранилищу ключей из определенного приложения, и при этом приложение должно использовать поток аутентификации от имени (OBO) для олицетворения пользователя. Для корректной работы данного сценария в политике доступа должны быть указаны как
applicationId
, так иobjectId
.applicationId
идентифицирует требуемое приложение, аobjectId
идентифицирует пользователя. В настоящее время данный параметр недоступен для уровня данных Azure RBAC.
Во всех типах доступа приложение проходит проверку подлинности с помощью идентификатора Microsoft Entra. Приложения используют любой из поддерживаемых методов аутентификации в зависимости от своего типа. Приложение получает маркер для ресурса в плоскости, в которой нужно предоставить доступ. Ресурс является конечной точкой в плоскости управления или данных на основе среды Azure. Приложение отправляет запрос REST API в Key Vault с использованием этого маркера. Узнайте больше о полном потоке аутентификации.
Модель единого механизма для аутентификации в обеих плоскостях имеет некоторые преимущества:
- организации могут централизованно управлять доступом ко всем принадлежащим им хранилищам ключей;
- когда пользователь покидает организацию, он мгновенно теряет доступ ко всем этим хранилищам ключей;
- Организации могут настроить проверку подлинности с помощью параметров в идентификаторе Microsoft Entra, например включить многофакторную проверку подлинности для добавленной безопасности.
Дополнительные сведения см. в разделе Основы проверки подлинности службы Key Vault.
Общие сведения о модели доступа
Доступ к хранилищу ключей осуществляется с помощью двух интерфейсов: плоскость управления и плоскость данных. Плоскость управления используется для управления Key Vault. Операции в этой плоскости включают в себя создание и удаление хранилищ ключей, получение свойств Key Vault и обновление политик доступа. Плоскость данных предназначена для работы с данными, хранящимися в хранилище ключей. Вы можете добавлять, удалять и изменять ключи, секреты и сертификаты.
Оба самолета используют идентификатор Microsoft Entra для проверки подлинности. Для авторизации плоскость управления использует систему Управления доступом на основе ролей Azure (Azure RBAC), а плоскость данных — политику доступа Key Vault и Azure RBAC для операций в плоскости данных Key Vault.
Чтобы получить доступ к хранилищу ключей в любой плоскости, все вызывающие объекты (пользователи или приложения) должны иметь надлежащую аутентификацию и авторизацию. Аутентификация позволяет идентифицировать вызывающую сторону. Авторизация определяет, какие операции может выполнять вызывающий объект. Проверка подлинности с помощью Key Vault работает в сочетании с идентификатором Microsoft Entra, который отвечает за проверку подлинности удостоверений любого заданного субъекта безопасности.
Субъект безопасности — это объект, представляющий пользователя, группу, службу или приложение, которые запрашивают доступ к ресурсам Azure. Azure назначает каждому субъекту безопасности уникальный идентификатор объекта.
- Субъект безопасности пользователя определяет пользователя, у которого есть профиль в идентификаторе Microsoft Entra.
- Субъект безопасности группы определяет набор пользователей, созданных в идентификаторе Microsoft Entra. Все роли или разрешения, назначенные группе, предоставляются всем пользователям в этой группе.
- Субъект-служба представляет собой тип субъекта безопасности, который идентифицирует приложение или службу, то есть часть кода, а не пользователя или группу. Идентификатор объекта для субъекта-службы называется идентификатором клиента и применяется аналогично имени пользователя. Секрет клиента или сертификат субъекта-службы действует как его пароль. Многие службы Azure поддерживают назначение Управляемого удостоверения с автоматическим управлением идентификатора клиента и сертификата. Управляемое удостоверение представляет собой наиболее безопасный и рекомендуемый способ проверки подлинности в Azure.
Дополнительные сведения о проверке подлинности в Key Vault см. в статье Проверка подлинности в Azure Key Vault.
Условный доступ
Key Vault поддерживает политики условного доступа Microsoft Entra. С их помощью можно пользоваться необходимыми элементами управления доступом в Key Vault, чтобы поддерживать безопасность организации, не мешая пользователям без необходимости.
Дополнительные сведения см. в статье Общие сведения об условном доступе.
Привилегированный доступ
Авторизация определяет, какие операции может выполнять вызывающая сторона. Авторизация в Key Vault использует управление доступом на основе ролей Azure (Azure RBAC) в плоскости управления, а также политики доступа Azure RBAC или Azure Key Vault в плоскости данных.
Доступ к хранилищам осуществляется через два интерфейса или плоскости. Это плоскость управления и плоскость данных.
- Плоскость управления — это место, где вы управляете Key Vault, а также интерфейс, используемый для создания и удаления хранилищ. Вы также можете читать свойства хранилища ключей и управлять политиками доступа.
- Плоскость данных позволяет работать с хранимыми данными в хранилище ключей. Вы можете добавлять, удалять и изменять ключи, секреты и сертификаты.
Приложения получают доступ к плоскостям через конечные точки. Элементы управления доступом для двух плоскостей работают независимо. Чтобы предоставить приложению доступ для использования ключей в хранилище ключей, вы предоставляете доступ к плоскости данных с помощью политики доступа Azure RBAC или Key Vault. Чтобы предоставить пользователю доступ на чтение к свойствам и тегам службы Key Vault, но не к данным (ключам, секретам или сертификатам), вы предоставляете доступ к плоскости управления с помощью Azure RBAC.
В следующей таблице показаны конечные точки плоскости управления и плоскости данных.
Плоскость доступа | Конечные точки доступа | Операции | Механизм контроля доступа |
---|---|---|---|
Плоскость управления | Международная контактная информация: management.azure.com:443 Microsoft Azure, управляемый 21Vianet: management.chinacloudapi.cn:443 Azure для US Gov : management.usgovcloudapi.net:443 Azure для Германии: management.microsoftazure.de:443 |
Создание, чтение, изменение и удаление хранилищ ключей Настройка политик доступа Key Vault Настройка тегов Key Vault |
Azure RBAC |
Плоскость данных | Международная контактная информация: <vault-name>.vault.azure.net:443 Microsoft Azure, управляемый 21Vianet: <vault-name>.vault.azure.cn:443 Azure для US Gov : <vault-name>.vault.usgovcloudapi.net:443 Azure для Германии: <vault-name>.vault.microsoftazure.de:443 |
Ключи: шифрование, расшифровка, оболочкаKey, unwrapKey, подпись, проверка, получение, создание, обновление, импорт, удаление, восстановление, восстановление, очистка, поворот (предварительная версия), getrotationpolicy (предварительная версия), setrotationpolicy (предварительная версия), release(preview) Сертификаты: managecontacts, getissuers, listissuers, setissuers, deleteissuers, manageissuers, get, list, create, import, update, delete, restore, backup, restore, purge Секреты: get, list, set, delete,recover, backup, restore, purge |
Политика доступа службы Key Vault или Azure RBAC |
Управление административным доступом к Key Vault
При создании хранилища ключей в группе ресурсов вы управляете доступом с помощью идентификатора Microsoft Entra. Можно предоставить пользователям или группе возможность управлять хранилищами ключей в группе ресурсов. Вы можете предоставить доступ на определенном уровне области, назначив соответствующие роли Azure. Чтобы предоставить пользователю доступ к управлению хранилищами ключей, ему необходимо назначить предопределенную роль key vault Contributor
в определенной области. Роли Azure можно назначить следующие области:
- Подписка: роль Azure, назначенная на уровне подписки, применяется ко всем группам ресурсов и ресурсам в рамках данной подписки.
- Группа ресурсов: роль Azure, назначенная на уровне группы ресурсов, применяется ко всем ресурсам в этой группе ресурсов.
- Определенный ресурс: роль Azure, назначенная для определенного ресурса, применяется к данному ресурсу. В этом случае ресурс является определенным хранилищем ключей.
Есть несколько заданных по умолчанию ролей. Если заданные роли не соответствуют вашим потребностям, вы можете определить собственные. Дополнительные сведения см. в статье Azure RBAC: встроенные роли.
Внимание
При использовании модели разрешений политики доступа пользователь с Contributor
Key Vault Contributor
любой другой ролью, включающей Microsoft.KeyVault/vaults/write
разрешения для плоскости управления хранилища ключей, может предоставить себе доступ к плоскости данных, задав политику доступа Key Vault. Чтобы предотвратить несанкционированный доступ и управление хранилищами ключей, ключами, секретами и сертификатами, необходимо ограничить доступ роли участника к хранилищам ключей в модели разрешений политики доступа. Чтобы устранить этот риск, рекомендуется использовать модель разрешений на основе ролей контроль доступа (RBAC), которая ограничивает управление разрешениями ролями "Владелец" и "Администратор доступа пользователей", что позволяет четко разделить операции безопасности и административные обязанности. Дополнительные сведения см. в руководстве по RBAC Key Vault и что такое Azure RBAC?
Управление доступом к данным Key Vault
Вы можете управлять доступом к ключам Key Vault, сертификатам и секретам с помощью Azure RBAC или политик доступа Key Vault.
Дополнительные сведения см. в разделе
Ведение журналов и мониторинг
Ведение журнала Key Vault сохраняет сведения о действиях, выполняемых в вашем хранилище. Для получения полной информации см. Ведение журнала Key Vault.
Вы можете интегрировать Key Vault с Event Grid, чтобы получать уведомления об изменении статуса ключа, сертификата или секрета, хранящегося в службе Key Vault. Дополнительные сведения см. в разделе Мониторинг хранилища ключей с помощью сетки событий Azure
При этом также важно следить за состоянием вашего хранилища ключей, чтобы убедиться, что ваша служба работает корректно. Чтобы узнать, как это сделать, см. Мониторинг и предупреждения для службы Azure Key Vault.
Резервное копирование и восстановление
Защита от обратимого удаления и очистки службы Azure Key Vault позволяет восстанавливать удаленные хранилища и объекты хранилища. Для получения полной информации см. Обзор обратимого удаления Azure Key Vault.
Вы также должны регулярно делать резервные копии своего хранилища при обновлении/удалении/создании объектов в хранилище.