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

Безопасность 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: встроенные роли.

Внимание

При использовании модели разрешений политики доступа пользователь с ContributorKey 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.

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

Следующие шаги