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

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

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

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

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

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

  • Управляемые АДМИНИСТРАТОРЫ HSM. Пользователи, которым назначена роль администратора, имеют полный контроль над управляемым пулом HSM. Они могут создавать больше назначений ролей для делегирования управляемого доступа другим пользователям.

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

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

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

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

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

  • Azure Active Directory (Azure AD). Это служба Active Directory для клиента. Каждый каталог содержит один или несколько доменов. Каталог может иметь много подписок, связанных с ним, но только один клиент.

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

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

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

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

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

Роли Key Vault

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

Роль Проблема Решение с помощью хранилища ключей Azure
Разработчик приложения Azure "Я хочу написать приложение для Azure, использующее ключи для подписывания и шифрования. Но я хочу, чтобы эти ключи были внешними из моего приложения, чтобы решение было пригодным для географически распределенного приложения.

Необходимо, чтобы эти ключи и секреты были защищены и не нужно было писать код самостоятельно, Я также хочу, чтобы эти ключи и секреты были легко использованы в моих приложениях с оптимальной производительностью».
√ Ключи хранятся в хранилище, и при необходимости их можно вызывать с помощью URI.

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

√ Ключи обрабатываются в аппаратных модулях безопасности, которые находятся в тех же центрах обработки данных Azure, что и приложения. Это обеспечивает более высокую надежность и менее длительную задержку, чем при расположении ключей в другом месте, например в локальной среде.
Разработчик программного обеспечения как услуги (SaaS) "Я не хочу ответственности за ключи и секреты клиента для моих клиентов.

Я хочу, чтобы клиенты владеют своими ключами и управляли ими, чтобы я мог сосредоточиться на том, что я делаю лучше, что предоставляет основные функции программного обеспечения».
√ Клиенты могут импортировать свои ключи в Azure и управлять ими. Если приложению SaaS требуется выполнять криптографические операции с помощью ключей клиентов, Key Vault выполняет эти операции от имени приложения. Приложение не увидит ключи клиентов.
Руководитель службы безопасности «Я хочу узнать, что наши приложения соответствуют стандарту FIPS 140-2 уровня 2 или FIPS 140-2 уровня 3 HSM для безопасного управления ключами.

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

Хотя мы используем несколько служб и ресурсов Azure, я хочу управлять ключами из одного места в Azure. "
√ Выберите хранилища для FIPS 140-2 уровня 2 проверенный HSM.
√ Выберите управляемые ПУЛЫ HSM для проверенного HSM уровня 2 FIPS 140-2.

√ Хранилище ключей разработано таким образом, чтобы сотрудники Майкрософт не могли видеть или извлекать ваши ключи.
√ Использование ключа протоколируется почти в реальном времени.

√ Хранилище предоставляет единый интерфейс, независимо от количества хранилищ в Azure, поддерживаемых регионов и использующих их приложений.

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

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

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

Общие сведения о работе хранилища Azure Key Vault

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

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

Хранилище ключей Azure доступно в большинстве регионов. Дополнительные сведения см. на странице цен на хранилище ключей.