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

  • 3 мин

Azure Key Vault защищает криптографические ключи, сертификаты (и закрытые ключи, связанные с сертификатами), а также секреты (например, строки подключения и пароли) в облаке. Однако при хранении конфиденциальных и критически важных для бизнеса данных необходимо выполнить действия, чтобы максимально повысить безопасность хранилищ и данных, хранящихся в них.

Безопасность сети

Вы можете уменьшить доступность хранилищ, указав, какие IP-адреса имеют к ним доступ. Конечные точки службы виртуальной сети для Azure Key Vault позволяют ограничить доступ к указанной виртуальной сети. Конечные точки также позволяют ограничить доступ к списку диапазонов адресов IPv4 (интернет-протокол версии 4). Доступ любого пользователя, подключающегося к хранилищу ключей из-за пределов этих источников, запрещен.

После применения правил брандмауэра пользователи могут только считывать данные из Key Vault, когда их запросы исходят из разрешенных виртуальных сетей или диапазонов адресов IPv4. Это также относится к доступу к Key Vault с портала Azure. Хотя пользователи могут перейти к хранилищу ключей на портале Azure, они могут не иметь возможности перечислять ключи, секреты или сертификаты, если их клиентский компьютер не входит в список разрешенных.

Служба приватного канала Azure позволяет получить доступ к Azure Key Vault и размещенным службам клиентов или партнеров Azure через частную конечную точку в виртуальной сети. Частная конечная точка Azure — это сетевой интерфейс, который подключает вас к службе, защищенной приватным каналом Azure. Частная конечная точка использует частный IP-адрес из вашей виртуальной сети, фактически интегрируя службу в вашу виртуальную сеть. Весь трафик к службе можно направлять через частную конечную точку, поэтому не требуются шлюзы, устройства преобразования сетевых адресов (NAT), expressRoute или VPN-подключения или общедоступные IP-адреса. Трафик между виртуальной сетью и службой проходит по магистральной сети Microsoft, устраняя доступ из общедоступного Интернета. Вы можете подключиться к экземпляру ресурса Azure, предоставляя наивысший уровень детализации в управлении доступом.

Безопасность транспортного уровня (TLS) и защита протокола гипертекстовой передачи (HTTPS)

Интерфейс Key Vault (плоскость данных) — это мультитенантный сервер. Это означает, что хранилища ключей от разных клиентов могут совместно использовать один и тот же общедоступный IP-адрес. Для обеспечения изоляции каждый HTTP-запрос проходит проверку подлинности и авторизован независимо от других запросов.

Протокол HTTPS позволяет клиенту участвовать в согласовании TLS. Клиенты могут применять версию TLS, и всякий раз, когда клиент делает это, все подключение будет использовать соответствующую защиту уровня. Key Vault поддерживает версии протокола TLS 1.2 и 1.3.

Параметры проверки подлинности Key Vault

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

  • Только для приложений: приложение представляет собой основной субъект-службы или управляемое удостоверение. Это наиболее распространенный сценарий для приложений, которые периодически нуждаются в доступе к сертификатам, ключам или секретам из хранилища ключей. Для работы этого сценария идентификатор объекта приложения должен быть указан в политике доступа, а идентификатор приложения не должен быть указан или должен иметь значение NULL.
  • Только пользователь: пользователь обращается к хранилищу ключей из любого приложения, зарегистрированного в клиенте. Примерами этого типа доступа являются Azure PowerShell и портал Azure. Для работы этого сценария идентификатор объекта пользователя должен быть указан в политике доступа, а идентификатор applicationId не должен быть указан или должен иметь значение NULL.
  • Приложение-пользователь (иногда называемая составной идентичностью): пользователю требуется доступ к хранилищу ключей из определенного приложения, и приложение должно использовать аутентификационный поток от имени пользователя (OBO) для олицетворения пользователя. Для работы этого сценария необходимо указать applicationId и objectId в политике доступа. ApplicationId определяет необходимое приложение, а objectId идентифицирует пользователя. В настоящее время этот параметр недоступен для уровня данных Azure RBAC.

Во всех типах доступа приложение проходит проверку подлинности с помощью идентификатора Microsoft Entra. Приложение использует любой поддерживаемый метод проверки подлинности на основе типа приложения. Приложение получает маркер ресурса в плоскости для предоставления доступа. Ресурс — это конечная точка в плоскости управления или данных на основе среды Azure. Приложение использует маркер и отправляет запрос REST API в Key Vault.

Модель единого механизма проверки подлинности на обоих плоскостях имеет несколько преимуществ:

  • Организации могут централизованно управлять доступом ко всем хранилищам ключей в своей организации.
  • Если пользователь покидает, он мгновенно теряет доступ ко всем хранилищам ключей в организации.
  • Организации могут настраивать проверку подлинности с помощью параметров в идентификаторе Microsoft Entra, таких как включение многофакторной проверки подлинности для добавленной безопасности.

Обзор модели доступа

Доступ к хранилищу ключей управляется двумя интерфейсами: уровнем управления и уровнем данных. Уровень управления — это то, где вы управляете 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 поддерживает политики условного доступа 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

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 для государственных организаций США:
<vault-name>.vault.usgovcloudapi.net:443

Azure Для Германии:
<vault-name>.vault.microsoftazure.de:443		 Ключи: шифрование, расшифровка, обернутьКлюч, развернутьКлюч, подпись, проверка, получение, список, создание, обновление, импорт, удаление, восстановление, резервное копирование, восстановление, очистка, ротация (предварительная версия), получитьПолитикуРотации (предварительная версия), установитьПолитикуРотации (предварительная версия), выпуск (предварительная версия)

Сертификаты: управление контактами, getissuers, список издателей, установить издателей, удалить издателей, управление издателями, получить, перечислить, создать, импортировать, обновить, восстановить, резервное копирование, восстановить, очистить.

Секреты: получить, перечислить, установить, удалить, восстановить, восстановить, очистить		 Политика доступа Key Vault или Azure RBAC

Управление административным доступом к Key Vault

При создании хранилища ключей в группе ресурсов вы управляете доступом с помощью идентификатора Microsoft Entra. Вы предоставляете пользователям или группам возможность управлять хранилищами ключей в группе ресурсов. Вы можете предоставить доступ на определенном уровне области, назначив соответствующие роли Azure. Чтобы предоставить пользователю доступ к управлению хранилищами ключей, необходимо назначить предопределенную роль участника хранилища ключей пользователю в определенной области. Следующие уровни областей можно назначить роли Azure:

  • Подписка: роль Azure, назначенная на уровне подписки, применяется ко всем группам ресурсов и ресурсам в этой подписке.
  • Группа ресурсов. Роль Azure, назначенная на уровне группы ресурсов, применяется ко всем ресурсам в этой группе ресурсов.
  • Конкретный ресурс: роль Azure, назначенная для определенного ресурса, применяется к данному ресурсу. В этом случае ресурс является определенным хранилищем ключей.

При использовании модели разрешений политики доступа, если у пользователя есть Contributor разрешения на уровень управления хранилищем ключей, пользователь может предоставить себе доступ к уровню данных, задав политику доступа к Key Vault. Необходимо строго контролировать доступ к хранилищам ключей Contributor с помощью модели разрешений политики доступа, чтобы обеспечить доступ только авторизованных лиц к хранилищам ключей, ключам, секретам и сертификатам. Рекомендуется использовать новую модель управления доступом на основе ролей (RBAC), чтобы избежать этой проблемы. При использовании модели разрешений RBAC управление разрешениями ограничено ролями "Владелец" и "Администратор доступа пользователей", что позволяет разделить обязанности между ролями для операций безопасности и общих административных операций.

Управление доступом к данным Key Vault

Вы можете управлять доступом к ключам Key Vault, сертификатам и секретам с помощью политик доступа к Azure RBAC или Key Vault.

Ведение журнала и мониторинг

Ведение журнала Key Vault сохраняет сведения о действиях, выполняемых в хранилище.

Вы можете интегрировать Key Vault с сеткой событий, чтобы получать уведомления о состоянии ключа, сертификата или секрета, хранящегося в хранилище ключей.

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

Резервное копирование и восстановление

Функция мягкого удаления и защита от безвозвратного удаления в Azure Key Vault позволяет восстановить удаленные хранилища и объекты хранилища.

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