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

Основные понятия об 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: встроенная роль, которая обычно назначается управляемой служебной учетной записи (например, учетной записи хранилища) для шифрования хранящихся данных с помощью ключа, управляемого клиентом.

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

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

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

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

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

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

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

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

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

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

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

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

Роли Key Vault

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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