Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Azure Key Vault управляет безопасными данными, включая секреты, ключи шифрования и сертификаты. Функции Key Vault, описанные в этой статье, приносят пользу мультитенантным решениям. Он также содержит ссылки на рекомендации, которые помогут вам спланировать использование Key Vault.
При работе с мультитенантной системой, используюющей Key Vault, определите необходимый уровень изоляции. Модель изоляции зависит от следующих факторов:
Сколько клиентов у вас есть
Совместное использование уровня приложений между несколькими клиентами, развертывание экземпляров приложения с одним клиентом или развертывание отдельных меток развертывания для каждого клиента
Должны ли клиенты управлять собственными ключами шифрования
Есть ли у клиентов требования к соответствию требованиям, которые требуют хранения секретов отдельно от секретов других клиентов
В следующей таблице перечислены различия между основными моделями аренды для Key Vault.
| Рассмотрение | Хранилище для каждого клиента в подписке поставщика | Хранилище для каждого клиента в подписке клиента | Совместный сейф |
|---|---|---|---|
| Изоляция данных | Высокая | Крайне высоко | Низкая |
| Изоляция производительности | Средняя. Высокая пропускная способность может быть ограничена даже с большим количеством хранилищ. | Высокая | Низкая |
| Сложность развертывания | Низкий-средний уровень в зависимости от количества арендаторов | Высокая. Арендатор должен правильно предоставить доступ поставщику. | Низкая |
| Операционная сложность | Высокая | Низкий для поставщика, более высокий для клиента | Наиболее низкий |
| Пример сценария | Отдельные экземпляры приложений для каждого клиента | Управляемые пользователем ключи шифрования | Крупное мультитенантное решение с общим уровнем приложений |
Рассмотрите возможность развертывания хранилища для каждого клиента в подписке Azure (поставщика услуг). Такой подход обеспечивает надежную изоляцию данных между данными каждого клиента. Но необходимо развертывать и управлять растущим числом хранилищ по мере увеличения числа клиентов.
Azure не ограничивает количество хранилищ, которые вы можете создать в рамках одной подписки. Но рассмотрим другие ограничения:
Ограничения на уровне подписки на количество запросов, которые можно выполнить в течение определенного периода времени. Эти ограничения применяются независимо от количества хранилищ в подписке. Следуйте инструкциям по регулированию , даже если у вас есть хранилища для конкретного клиента.
Количество назначений ролей Azure, которые можно создать в подписке. При развертывании и настройке большого количества хранилищ в подписке можно приблизиться к этим ограничениям.
В некоторых сценариях клиенты могут создавать хранилища в собственных подписках Azure и предоставлять приложению доступ к работе с секретами, сертификатами или ключами. Используйте этот подход, когда вы разрешаете ключи, управляемые клиентом, для шифрования в решении.
Чтобы получить доступ к данным в хранилище клиента, клиент должен предоставить приложению доступ к хранилищу. Для этого процесса требуется, чтобы приложение проходило проверку подлинности с помощью экземпляра идентификатора Microsoft Entra. Можно опубликовать мультитенантное приложение Идентификатора Microsoft Entra.
Клиенты должны выполнить однократный процесс согласия, включающий следующие действия:
Зарегистрируйте мультитенантное приложение Microsoft Entra в клиенте Microsoft Entra.
Предоставьте мультитенантному приложению Microsoft Entra соответствующий уровень доступа к их хранилищу.
Предоставьте вам полный идентификатор ресурса для создаваемого хранилища.
После этой настройки код вашего приложения может использовать учетную запись службы, связанную с мультитенантным приложением Microsoft Entra ID в вашем Microsoft Entra ID, чтобы получить доступ к хранилищу каждого клиента.
Вы можете попросить каждого арендатора создать учетную запись службы для использования вашей службой и предоставить вам её учетные данные. Но этот подход требует безопасного хранения учетных данных для каждого клиента и управления ими, что представляет ответственность за безопасность.
Если арендаторы настраивают сетевые элементы управления доступом в своих хранилищах, убедитесь, что у вас есть возможность получить доступ к этим хранилищам. Создайте приложение для обработки ситуаций, когда арендатор меняет правила доступа к своей сети и блокирует ваш доступ к своим хранилищам данных.
Секреты арендаторов можно разделять в одном хранилище. Вы развертываете хранилище в подписке Azure (поставщика решений) и управляете хранилищем. Этот подход является самым простым, но обеспечивает наименьшую изоляцию данных и изоляцию производительности.
Вы также можете развернуть несколько общих хранилищ. Например, решение, которое следует шаблону меток развертывания , скорее всего, развертывает общее хранилище в каждой метки. Аналогичным образом, если вы внедряете решение для нескольких регионов, вам следует создать хранилища в каждом регионе по следующим причинам:
- Чтобы избежать задержки трафика между регионами при работе с данными в хранилище
- Для поддержки требований по месту размещения данных
- Чтобы разрешить использование региональных хранилищ в других службах, которые требуют развертывания в том же регионе
При работе с общим хранилищем следует учитывать количество операций, выполняемых с хранилищем. Операции включают чтение секретов и выполнение операций шифрования или расшифровки. Key Vault накладывает ограничения на количество запросов, сделанных в одном хранилище и во всех хранилищах в подписке Azure. Следуйте инструкциям по регулированию и примените другие рекомендуемые методики. Безопасно кэшируйте секреты, которые вы извлекаете, и используйте шифрование конверта , чтобы избежать отправки всех операций шифрования в Key Vault. Эти рекомендации помогают использовать решения высокой масштабируемости на одном хранилище.
Если вам нужно хранить секреты, ключи или сертификаты для конкретного клиента, рассмотрите возможность использования соглашения об именовании, например префикса именования. Например, можно добавить идентификатор арендатора в начало имени каждого секрета. Затем код приложения может легко загрузить значение определенного секрета для конкретного клиента.
Key Vault поддерживает теги секретов, сертификатов и ключей путем добавления пользовательских метаданных. Тег можно использовать для отслеживания идентификатора арендатора для каждого секрета, связанного с конкретным арендатором. Но Key Vault не поддерживает запросы по тегам, поэтому эта функция лучше всего подходит для целей управления, а не в логике приложения.
Дополнительные сведения см. в следующих ресурсах:
При развертывании большого количества хранилищ убедитесь, что они соответствуют единым стандартам конфигурации сетевого доступа, ведения журнала и управления доступом. Попробуйте использовать политику Azure, чтобы убедиться, что хранилища настроены в соответствии с вашими требованиями.
Дополнительные сведения см. в следующих ресурсах:
Если необходимо выполнить большое количество операций в секунду, а ограничения операций Key Vault недостаточно, рассмотрите возможность использования управляемого HSM или выделенного HSM. Обе продукты предоставляют зарезервированную емкость, но они увеличивают затраты по сравнению с Key Vault. Поймите ограничения на количество экземпляров этих служб, которые можно развернуть в каждом регионе.
Дополнительные сведения см. в следующих ресурсах:
- Определение того, следует ли использовать Key Vault или выделенный HSM
- Определите, подходит ли специализированный аппаратный модуль безопасности (HSM) для вас
Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.
Основной автор
- Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure
Другие участники:
- Джек Личва | Основной диспетчер продуктов, Azure Key Vault
- Арсен Владимирский | Главный инженер клиента, FastTrack для Azure
Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.