основные понятия Azure Key Vault

Azure Key Vault — это облачная служба для безопасного хранения и доступа к секретам. Секрет — это все, к чему требуется жестко контролировать доступ, например ключи API, пароли, сертификаты или криптографические ключи. служба Key Vault поддерживает два типа контейнеров: хранилища и пулы управляемых аппаратных модулей безопасности (HSM). Хранилища поддерживают хранение программного обеспечения, а также ключей, секретов и сертификатов, поддерживаемых HSM. Управляемые пулы HSM поддерживают только ключи, поддерживаемые HSM. В разделе Azure Key Vault REST API см. полный обзор для получения всех подробностей.

Ниже приведены другие важные термины.

• Тенант: клиент — это организация, которая владеет определенным экземпляром облачных служб Майкрософт и управляет ими. Чаще всего используется для ссылки на набор служб Azure и Microsoft 365 для организации.

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

• Потребитель хранилища: Потребитель хранилища может выполнять действия с ресурсами хранилища ключей, когда владелец хранилища предоставляет доступ. Доступные действия зависят от предоставленных разрешений.

• Администраторы управляемых HSM: пользователи, которым назначена роль администратора, имеют полный контроль над пулом управляемых HSM. Они могут создавать дополнительные назначения ролей, чтобы предоставлять контролируемый доступ другим пользователям.

• Администратор системы шифрования/пользователь управляемого HSM: встроенные роли, которые обычно назначаются для пользователей или субъектов-служб, которые будут выполнять криптографические операции с использованием ключей в управляемом HSM. Пользователь шифрования может создавать новые ключи, но не может удалять ключи.

• Пользователь шифрования службы Crypto Managed HSM: встроенная роль, которая обычно назначается управляемой служебной учетной записи (например, учетной записи хранилища) для шифрования хранящихся данных с помощью ключа, управляемого клиентом.

• Resource: ресурс — это управляемый элемент, доступный через Azure. Распространенными примерами являются виртуальная машина, учетная запись хранения, веб-приложение, база данных и виртуальная сеть. На самом деле их намного больше.

• ГруппаResource: группа ресурсов — это контейнер, содержащий связанные ресурсы для решения Azure. В группу ресурсов могут входить все ресурсы приложения или только те, которыми необходимо управлять совместно. Пользователи могут выбрать оптимальный для своей организации способ распределения ресурсов в группах ресурсов.

• Security principal: субъект безопасности Azure — это удостоверение безопасности, которое используется созданными пользователем приложениями, службами и средствами автоматизации для доступа к определенным ресурсам Azure. Это можно назвать удостоверением пользователя (имя пользователя и пароль или сертификат) с определенной ролью и строго контролируемыми разрешениями. Субъект безопасности должен выполнять только определенные действия, в отличие от идентичности пользователя. Он повышает безопасность, если предоставлен только минимальный уровень разрешений, необходимый для выполнения задач управления. Субъект безопасности, используемый с приложением или службой, называется сервисным субъектом. Дополнительные сведения см. в разделе "Объекты приложения и сервисных принципалов".

• Microsoft Entra ID: Microsoft Entra ID — это служба Active Directory для клиента. Каждый каталог содержит один или несколько доменов. Каталог может иметь много подписок, связанных с ним, но только один клиент.

• идентификатор клиента Azure. Идентификатор клиента — это уникальный способ идентификации экземпляра Microsoft Entra в подписке Azure.

• Управляемые удостоверения: Azure Key Vault предоставляет безопасный способ хранения учетных данных и других ключей и секретов, но коду необходимо пройти проверку подлинности, чтобы получить их из Key Vault. Использование управляемого удостоверения упрощает решение этой проблемы, предоставляя службам Azure автоматически управляемую учетную запись в Microsoft Entra ID. Это удостоверение можно использовать для проверки подлинности для Key Vault или любой службы, поддерживающей проверку подлинности Microsoft Entra, без наличия учетных данных в коде. Дополнительные сведения см. на следующем рисунке и обзор управляемых удостоверений для ресурсов Azure.

Аутентификация

Для выполнения любых операций с Key Vault сначала необходимо выполнить проверку подлинности. Существует три способа проверки подлинности для Key Vault:

• Управляемые удостоверения для ресурсов Azure. При развертывании приложения на виртуальной машине в Azure можно назначить удостоверение виртуальной машине с доступом к "Key Vault". Вы также можете назначить идентичности для других ресурсов Azure. Преимуществом этого подхода является то, что приложение или служба не управляет сменой первого секрета. Azure автоматически поворачивает удостоверение. Мы рекомендуем этот подход в качестве оптимальной практики.
• Учетная запись службы и сертификат: Вы можете использовать учетную запись службы и связанный с ней сертификат, который имеет доступ к Key Vault. Мы не рекомендуем этот подход, так как владелец приложения или разработчик должны сменить сертификат. Для получения дополнительной информации см. Создание учётной записи службы.
• Субъект-служба и секрет. Хотя субъект-служба и секрет можно использовать для проверки подлинности в Key Vault, мы не рекомендуем их использовать. Сложно автоматически обновлять секрет начальной настройки, который используется для аутентификации в Key Vault.

Подробные рекомендации по проверке подлинности см. в разделе Authentication в Azure Key Vault.

Шифрование передаваемых данных

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

Perfect Forward Secrecy (PFS) защищает подключения между клиентскими системами и облачными службами Майкрософт с помощью уникальных ключей. Подключения также используют 2 048-разрядную длину ключа шифрования на основе RSA. Это сочетание затрудняет перехват и доступ к данным, находящимся в процессе передачи.

роли в Key Vault

Используйте следующую таблицу, чтобы лучше понять, как Key Vault может помочь в удовлетворении потребностей разработчиков и администраторов безопасности.

Должность	формулировка проблемы;	Решено с помощью Azure Key Vault
Разработчик для приложения Azure	"Я хочу написать приложение для Azure, использующее ключи для подписывания и шифрования. Но нужно, чтобы эти ключи были внешними по отношению к моему приложению, чтобы решение подходило для географически распределенного приложения. Необходимо, чтобы эти ключи и секреты были защищены и не нужно было писать код самостоятельно, Также требуется, чтобы эти ключи и секреты можно было легко использовать в моих приложениях с гарантией оптимальной производительности".	√ Ключи хранятся в хранилище, и при необходимости их можно вызывать с помощью URI. √ ключи защищены Azure, используя стандартные отраслевые алгоритмы, длины ключей и аппаратные модули безопасности. √ Ключи обрабатываются в модулях аппаратного обеспечения безопасности (HSM), которые находятся в тех же центрах обработки данных Azure, что и приложения. Это обеспечивает более высокую надежность и менее длительную задержку, чем при расположении ключей в другом месте, например в локальной среде.
Разработчик программного обеспечения как услуга (SaaS)	Я не хочу брать на себя ответственность и потенциальные обязательства за ключи и секреты арендаторов моих клиентов. Мне нужно, чтобы заказчики владели и управляли своими ключами, а мне можно было полностью сосредоточиться на своей основной работе, а именно – предоставлением базовых функций программного обеспечения".	√ клиенты могут импортировать собственные ключи в Azure и управлять ими. Когда приложению SaaS необходимо выполнять криптографические операции с помощью ключей клиентов, Key Vault выполняет эти операции от имени приложения. Приложение не видит ключи клиентов.
Руководитель службы безопасности	Я хочу убедиться, что наши приложения соответствуют HSM уровня 3 по стандарту FIPS 140 для безопасного управления ключами. Я также хочу убедиться, что моя организация может управлять жизненным циклом ключей и отслеживать их использование. И хотя мы используем несколько служб и ресурсов Azure, я хочу управлять ключами из единого расположения в Azure.	Выберите хранилища или управляемые HSM для проверенных HSM согласно FIPS 140. √ Выберите управляемые пулы HSM для HSM, проверенных по стандарту FIPS 140-3 уровня 3. √ Key Vault разработан таким образом, чтобы Майкрософт не видел или не извлекает ключи. √ Использование ключа протоколируется почти в реальном времени. √ Хранилище предоставляет единый интерфейс независимо от того, сколько хранилищ вы используете в Azure, какие регионы они поддерживают и какие приложения используют их.

Любой пользователь с подпиской Azure может создавать и использовать хранилища ключей. Хотя Key Vault предоставляет преимущества для разработчиков и администраторов безопасности, его может реализовать и управлять администратор организации, который отвечает за другие службы Azure. Например, этот администратор может войти с помощью подписки Azure, создать хранилище для организации, в которой будут храниться ключи, а затем отвечать за рабочие задачи следующим образом:

• создание или импорт ключа или секрета;
• отзыв или удаление ключа или секрета;
• авторизация пользователей или приложений для доступа к хранилищу ключей с целью управления ключами и секретами или их использования;
• настройка использования ключей (например, подписи и шифрования);
• мониторинг использования ключей.

Этот администратор предоставляет разработчикам универсальные указатели ресурсов (URI) для вызова из их приложений. Этот администратор также передает информацию из журнала использования ключей администратору безопасности.

Разработчики также могут управлять ключами напрямую с помощью API. Дополнительные сведения см. в руководстве разработчика Azure Key Vault.

Дальнейшие действия

• Начало работы с руководством разработчика Azure Key Vault
• Узнайте о функциях безопасности Azure Key Vault
• Сведения об аутентификации в Azure Key Vault
• Сведения о том, как защитить управляемые пулы HSM

Azure Key Vault доступна в большинстве регионов. Дополнительные сведения см. на странице цен Key Vault.