Azure Key Vault

Завершено

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка подлинности

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

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

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

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

Полная безопасность пересылки (PFS) позволяет защитить подключения между клиентскими системами заказчиков и облачными службами Майкрософт с помощью уникальных ключей. Подключения также используют длину ключа шифрования на основе Rivest-Shamir-Adleman (RSA). Благодаря такому сочетанию усложняется перехват данных и доступ к ним во время передачи.

Роли Key Vault

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

Роль	Оператор проблемы	Решение Azure Key Vault
Разработчик приложения 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, соответствующие стандарту FIPS 140-2 уровня 2, с поддержкой HSM. √ Хранилище ключей разработано таким образом, чтобы сотрудники Майкрософт не могли видеть или извлекать ваши ключи. √ Использование ключа протоколируется почти в реальном времени. √ Хранилище предоставляет единый интерфейс, независимо от количества хранилищ в Azure, поддерживаемых регионов и использующих их приложений.

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

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