Безопасность Azure Key Vault

2025-05-24

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 Private Link. Частная конечная точка использует частный 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 ID. Все роли или разрешения, назначенные группе, предоставляются всем пользователям в этой группе.
Субъект-служба представляет собой тип субъекта безопасности, который идентифицирует приложение или службу, то есть часть кода, а не пользователя или группу. Идентификатор объекта для субъекта-службы называется идентификатором клиента и применяется аналогично имени пользователя. Секрет клиента или сертификат сервисного принципала действует как его пароль. Многие службы 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 для правительства США: management.usgovcloudapi.net:443	Создание, чтение, изменение и удаление хранилищ ключей Настройка политик доступа Key Vault Установка тегов Key Vault	Azure RBAC
Плоскость данных	Международная контактная информация: <vault-name.vault.azure.net:443> Microsoft Azure, управляемый 21Vianet: <vault-name.vault.azure.cn:443> Azure для правительства США: <vault-name.vault.usgovcloudapi.net:443>	Ключи: шифрование, расшифровка, обернутьКлюч, разворачиватьКлюч, подпись, проверка, получение, список, создание, обновление, импорт, удаление, восстановление, резервное копирование, восстановление, очистка, вращение (предварительная версия), получить политику вращения (предварительная версия), установить политику вращения (предварительная версия), выпуск (предварительная версия) Сертификаты: managecontacts, getissuers, listissuers, setissuers, deleteissuers, manageissuers, get, list, create, import, update, delete, restore, 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 разрешения для плоскости управления хранилища ключей, может предоставить себе доступ к плоскости данных, задав политику доступа хранилища ключей. Чтобы предотвратить несанкционированный доступ и управление хранилищами ключей, ключами, секретами и сертификатами, необходимо ограничить доступ роли участника к хранилищам ключей в модели разрешений политики доступа. Чтобы устранить этот риск, рекомендуется использовать модель разрешений на основе ролей контроль доступа (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.

Вы также должны регулярно делать резервные копии своего хранилища во время обновления, удаления или создания объектов в хранилище.