Планирование решения для выдачи проверенных учетных данных Microsoft Entra
Важно спланировать ваше решение для выпуска таким образом, чтобы помимо возможности выпуска удостоверений вы имели полное представление о влиянии вашего решения на архитектуру и бизнес. Если вы еще не сделали этого, рекомендуем получить базовые сведения, изучив обзор архитектуры Проверенных учетных данных Microsoft Entra.
Область действия руководства
Эта статья посвящена техническим аспектам проектирования решения для выдачи проверяемого удостоверения. Решение Майкрософт для проверяемых удостоверений основано на стандартах Verifiable Credentials Data Model 1.0 и Decentralized Identifiers (DIDs) V1.0 консорциума W3C, поэтому оно может взаимодействовать со службами сторонних поставщиков. Тем не менее в примерах в данной статье отражен стек решений Майкрософт для проверяемых удостоверений.
В данной статье не рассматриваются вопросы, связанные со вспомогательными технологиями, которые не относятся к решениям для выдачи удостоверений. Например, в решении для выпуска проверяемых удостоверений используются веб-сайты, но планирование развертывания веб-сайтов не рассмотрено подробно.
Компоненты решения
В рамках вашего плана решения по выпуску удостоверений необходимо разработать решение, которое обеспечит взаимодействие между издателем, пользователем и средством проверки. На приведенной ниже схеме показаны компоненты архитектуры вашего решения для выпуска удостоверений.
Архитектура решения для выпуска проверяемых удостоверений Майкрософт
Клиент Microsoft Entra
Предварительным условием для запуска службы Проверенные учетные данные Microsoft Entra является размещение в клиенте Microsoft Entra. Клиент Microsoft Entra предоставляет плоскость управления "Управление удостоверениями и доступом" для ресурсов Azure, входящих в решение.
Каждый клиент использует мультитенантную службу Проверенные учетные данные Microsoft Entra и имеет децентрализованный идентификатор (DID). DID предоставляет доказательства того, что издатель владеет доменом, включенным в DID. DID используется субъектом и средством проверки для проверки издателя.
Службы Microsoft Azure
В службе Azure Key Vault хранятся ключи издателя, создаваемые при активации службы выдачи Проверенных учетных данных Microsoft Entra. Ключи и метаданные используются для выполнения операций управления удостоверениями и обеспечения безопасности сообщений.
У каждого издателя имеется один набор ключей, используемый для подписывания, обновления и восстановления. Этот набор ключей используется при выпуске каждого создаваемого вами проверяемого удостоверения.
Служба "Проверенные учетные данные Microsoft Entra" используется для хранения метаданных и определений учетных данных (в частности, определений правил и отображения для ваших учетных данных).
Определения отображения определяют, как утверждения отображаются в кошельке владельца, а также фирменную символику и другие элементы. Определение отображения может быть локализовано для нескольких языков. См. раздел Настройка проверяемого удостоверения.
Правила создаются по модели, определяемой издателем, и описывают требования к входным данным для проверяемого удостоверения. Также правила определяют доверенные источники входных данных и сопоставление входных утверждений с выходными, хранящимися в проверяемом удостоверении. В зависимости от типа аттестации, который указан в определении правил, входные утверждения могут поступать от разных поставщиков. Входные утверждения могут поступать от поставщика удостоверений OIDC, от id_token_hint или от самозаверяемых утверждений во время выдачи через входные данные пользователя в кошельке.
- Входные данные — это подмножество модели в файле правил для использования клиентом. Подмножество должно описывать набор входных данных, указывать, где можно получить входные данные, и конечную точку, к которой можно совершить вызов, чтобы получить проверяемое удостоверение.
Служба "Проверенные учетные данные Microsoft Entra"
Служба Проверенных учетных данных Microsoft Entra позволяет выпускать и отзывать проверяемые удостоверения на основе вашей конфигурации. Служба
Предоставляет децентрализованный идентификатор (DID). У каждого издателя имеется по одному DID на клиента.
Подготавливает наборы ключей для хранилища Key Vault.
Хранит метаданные конфигурации, используемые службой выпуска удостоверений и Microsoft Authenticator.
Предоставляет интерфейсы REST API, которые позволяют обслуживать внешние интерфейсы поставщиков и проверяющих
Система доверия
Проверенные учетные данные Microsoft Entra в настоящее время поддерживает веб-систему доверияСАЙТ DID Web, где документ DID размещается на веб-сервере издателей.
Приложение Microsoft Authenticator
Microsoft Authenticator — это мобильное приложение. Authenticator управляет взаимодействием между пользователем, службой Проверенные учетные данные Microsoft Entra и контрактом, используемым для выдачи виртуальных машин. Оно выступает в качестве цифрового бумажника, в котором владелец проверяемого удостоверения хранит это проверяемое удостоверение, в том числе закрытый ключ субъекта проверяемого удостоверения. Приложение Authenticator также является механизмом, используемым для предоставления проверяемых удостоверений на проверку.
Бизнес-логика выпуска удостоверений
Решение для выпуска удостоверений включает веб-интерфейс, с помощью которого пользователи запрашивают проверяемые удостоверения, хранилище удостоверений или другое хранилище атрибутов для получения значений для утверждений о субъекте и другие серверные службы.
Клиентский веб-интерфейс обслуживает запросы на выпуск удостоверений в бумажник субъекта, создавая прямые ссылки или QR коды. Чтобы выполнить требования к созданию проверяемых удостоверений, могут потребоваться другие компоненты (в зависимости от конфигурации контракта).
Эти службы предоставляют вспомогательные роли, которые не обязательно должны интегрироваться с службой выдачи Проверенные учетные данные Microsoft Entra. Этот уровень обычно включает в себя указанные ниже элементы.
Служба или службы , совместимые с OpenID Connect (OIDC), используются для получения id_tokens, необходимых для выдачи VC. Существующие системы удостоверений, такие как Идентификатор Microsoft Entra или Azure AD B2C, могут предоставлять службу, совместимую с OIDC, так как могут создавать пользовательские решения, такие как сервер удостоверений.
Хранилища атрибутов — хранилища атрибутов могут находиться вне служб каталогов и предоставлять атрибуты, необходимые для выдачи VC. Например, информационная система со сведениями об учащихся может предоставлять утверждения о полученных степенях.
Дополнительные службы среднего уровня, содержащие бизнес-правила для списков подстановки, проверки, процедуры выставления счетов, а также другие проверки среды выполнения и рабочие процессы, необходимые для выпуска проверяемых удостоверений.
Дополнительные сведения о настройке веб-интерфейса см. в руководстве по настройке идентификатора Microsoft Entra для выдачи проверяемых учетных данных.
Рекомендации по разработке удостоверений
Конструкция учетных данных зависит от конкретных сценариев использования. Вариант использования определяет:
требования к взаимодействию;
способ, когда пользователи должны доказать свое удостоверение, чтобы получить свой VC
утверждения, необходимые для удостоверений;
Значение , если учетные данные необходимо отозвать
Сценарии использования удостоверений
В службе Проверенных учетных данных Microsoft Entra чаще всего применяются следующие варианты использования учетных данных:
Проверка личности: при выпуске удостоверений учитывается много критериев. К нескольким критериям может относиться проверка подлинности выданных правительством документов, таких как паспорт или водительская лицензия, и сопоставление информации в этом документе с другими сведениями, такими как:
селфи пользователя;
проверка актуальности.
Удостоверения этого типа хорошо подходят при добавлении удостоверений новых сотрудников, партнеров, поставщиков услуг, учащихся, а также в других случаях, когда крайне важно выполнить проверить личность.
Подтверждение найма на работу или членства: удостоверения выпускают для подтверждения связи между пользователем и учреждением. Удостоверения такого типа хорошо подходят для доступа к слабо связанным областям применения "бизнес-бизнес", например когда розничные продавцы предлагают скидки сотрудникам или учащимся. Одно из основных преимуществ проверяемых удостоверений — их переносимость: после выпуска проверяемого удостоверения пользователь может применять его в разных сценариях.
Дополнительные сценарии использования см. в статье Сценарии использования проверяемых удостоверений (w3.org).
Взаимодействие с удостоверениями
В рамках процесса разработки изучите специфические для отрасли схемы, пространства имен и идентификаторы, которые можно отрегулировать для достижения максимального уровня взаимодействия и использования. См. примеры на веб-сайтах Schema.org и DIF — Claims and Credentials Working Group.
Для распространенных схем стандарты все еще развиваются и совершенствуются. Один из примеров такой инициативы — Verifiable Credentials for Education Task Force. Мы рекомендуем исследовать новые стандарты, связанные с отраслью, в которой работает ваша организация, и делать вклад в их развитие.
Тип и атрибуты учетных данных
Когда вы определите сценарий использования удостоверений, следует выбрать типы и атрибуты, которые вы будете включать в них. Средства проверки могут считывать утверждения в проверяемых удостоверениях, предоставляемых пользователями.
Все проверяемые удостоверения должны объявлять свой тип в определении правил. Тип удостоверения позволяет различать схемы разных проверяемых удостоверений и помогает организовать взаимодействие между издателями и проверяющими. Чтобы указать тип удостоверения, необходимо указать один или несколько типов, которым удовлетворяет это удостоверение. Каждый тип является уникальной строкой. Часто для обеспечения глобальной уникальности используется универсальный код ресурса (URI). Не требуется, чтобы этот URI указывал на существующую страницу ресурса. Он обрабатывается как строковое значение. Например, диплом Contoso University может объявлять следующие типы:
| Тип | Цель |
|---|---|
https://schema.org/EducationalCredential |
Объявляет, что дипломы, выданные Contoso University, содержат атрибуты, определенные объектом EducationaCredential schema.org. |
https://schemas.ed.gov/universityDiploma2020 |
Объявляет, что дипломы, выданные Contoso University, содержат атрибуты, определенные Министерством образования США. |
https://schemas.contoso.edu/diploma2020 |
Объявляет, что дипломы, выданные Contoso University, содержат атрибуты, определенные Contoso University. |
В дополнение к отраслевым стандартам и схемам, которые могут быть применимы к вашим сценариям, учитывайте перечисленные ниже аспекты.
Минимизация частных сведений: соблюдайте условия сценариев использования, применяя минимально необходимое количество частных сведений. Например, проверяемое удостоверение, используемое для веб-сайтов электронной коммерции, на которых предлагаются скидки сотрудникам и выпускникам учебных заведений, можно создать путем предоставления удостоверения, в котором используются утверждения только для имени и фамилии. Дополнительные сведения, например дата найма на работу, должность, отдел, не требуются.
Отдавайте предпочтение абстрактным утверждениям: каждое утверждение должно соответствовать потребностям и сообщать как можно меньше сведений. Например, утверждение с именем AgeOver с дискретными значениями, такими как 13, 21, 60, более абстрактно, чем дата утверждения на рождение.
Спланируйте возможность отзыва: рекомендуем задать утверждение индекса, чтобы можно было использовать механизм поиска и отзыва удостоверений. Вы ограничиваетесь определением одного утверждения индекса для каждого контракта. Важно отметить, что значения индексированных утверждений не хранятся в серверной части, а только хэш значения утверждения. Дополнительные сведения см. в статье Отзыв выданного ранее проверяемого удостоверения.
Прочие соображения касательно атрибутов удостоверений см. в спецификации Verifiable Credentials Data Model 1.0 (w3.org) (Модель данных для проверяемого удостоверения версии 1.0).
Планирование атрибутов качества
Планирование производительности
Как и в случае с любым другим решением, вам необходимо спланировать производительность. Ключевые области, на которых следует сконцентрироваться, — задержки и масштабируемость. На начальных этапах цикла выпуска удостоверений производительность не должна быть проблемой. Тем не менее если после внедрения решения по выпуску удостоверений вы будете выпускать большое количество проверяемых удостоверений, может оказаться, что планировать производительность очень важно.
Ниже перечислены аспекты, которые следует учитывать при планировании производительности.
Служба выдачи Проверенные учетные данные Microsoft Entra развернута в регионах Западной Европы, Северной Европы, Западной части США 2, Западной части США, Австралии и Японии Azure. Если клиент Microsoft Entra находится в ЕС, служба Проверенные учетные данные Microsoft Entra также находится в ЕС.
Чтобы ограничить задержку, разверните внешний веб-сайт выдачи и хранилище ключей в указанном выше регионе.
Модель, основанная на пропускной способности
На службу издателя распространяются ограничения для служб Azure Key Vault.
Для Azure Key Vault существуют три указанные ниже операции подписывания, используемые при каждом выпуске проверяемого удостоверения.
Одна для запроса на выпуск с веб-сайта
Одна для созданного проверяемого удостоверения
Одна для скачивания контракта
Вам не удастся управлять регулированием. Тем не менее рекомендуется прочитать Руководство по регулированию хранилища ключей Azure.
Если вы планируете крупное развертывание и подключение виртуальных машин, рассмотрите возможность пакетного создания VC, чтобы не превышать пределы.
В рамках плана производительности определите, что вы отслеживаете, чтобы лучше понять производительность решения. Помимо мониторинга веб-сайтов на уровне приложения при определении стратегии мониторинга выпуска проверяемых удостоверений необходимо учитывать указанные ниже моменты.
Для масштабируемости рекомендуется реализовать метрики для следующих элементов:
Определите логические этапы процесса выпуска удостоверений. Например:
Первоначальный запрос
Обслуживание QR-кодов или прямых ссылок
Поиск атрибутов
Вызовы к службе выдачи Проверенных учетных данных Microsoft Entra
Выпущенные удостоверения
Определите метрики на основе указанных ниже этапов.
Общее количество запросов (объем)
Количество запросов на единицу времени (пропускная способность)
Затраченное время (задержка)
Мониторинг Azure Key Vault с помощью следующей ссылки:
Отслеживайте компоненты, используемые для уровня бизнес-логики.
Планирование для надежности
Чтобы спланировать надежность, рекомендуем выполнить указанные ниже действия.
Определив цели в части доступности и избыточности, разберитесь, как достичь этих целей, с помощью указанных ниже руководств.
Для интерфейсной части и бизнес-уровня можно объявлять ваше решение неограниченным количеством способов. Как и в случае с любым другим решением, убедитесь, что обнаруженные вами зависимости устойчивы и отслеживаются.
Если редкое событие, когда служба выдачи Проверенные учетные данные Microsoft Entra или службы Azure Key Vault становятся недоступными, все решение становится недоступным.
Планирование обеспечения соответствия требованиям
У вашей организации могут быть определенные требования соответствия, связанные с вашей отраслью, типом транзакций или страной или регионом операции.
Место расположения данных: служба выдачи Проверенных учетных данных Microsoft Entra развернута не во всех регионах Azure. Эта служба используется только для вычислительных функций. Мы не храним значения проверяемых удостоверений в системах Майкрософт. Тем не менее в процессе выпуска проверяемых удостоверений мы пересылаем и используем личные данные. Использование службы проверяемых удостоверений не должно нарушать требования о месте расположения данных. Если вы храните личную информацию в рамках проверки личности, это должно храниться таким образом и регионом, который соответствует вашим требованиям соответствия. См. руководство по работе с Azure на веб-сайте центра управления безопасностью Майкрософт.
Отзыв учетных данных. Определите, требуется ли вашей организации отозвать учетные данные. Например, администратору может потребоваться отозвать удостоверение сотрудника, который увольняется из компании. Дополнительные сведения см. в статье Отзыв выданного ранее проверяемого удостоверения.
Истекает срок действия учетных данных. Определите срок действия учетных данных. Пример: вы выпускаете проверяемое удостоверение в качестве подтверждения наличия водительского удостоверения, срок действия которого может истечь через несколько лет. Другие виртуальные машины могут иметь более короткий срок действия, чтобы пользователи периодически возвращались для обновления их VC.
Планирование операций
При планировании операций важно разработать схему для устранения неполадок, создания отчетов и различения различных клиентов, которые вы поддерживаете. Кроме того, если за отзыв проверяемых удостоверений отвечает группа эксплуатации, необходимо четко определить этот процесс. Каждый шаг в этом процессе должен быть скоррелирован, чтобы можно было определить, какие записи журналов могут быть связаны с каждым уникальным запросом на выпуск. Для целей аудита рекомендуется отдельно записывать каждую попытку выпуска удостоверения. В частности:
Создайте уникальные идентификаторы транзакций, на которые при необходимости смогут ссылаться клиенты и инженеры службы технической поддержки.
Продумайте механизм коррелирования журналов транзакций Azure Key Vault с идентификаторами транзакций в части решения, связанной с выпуском удостоверений.
Если вы являетесь службой проверки подлинности, выдающей виртуальные машины от имени нескольких клиентов, отслеживайте и устраняйте проблемы с идентификатором клиента или контракта для отчетности и выставления счетов.
Если вы являетесь службой проверки подлинности, выдающей виртуальные машины от имени нескольких клиентов, используйте идентификатор клиента или контракта для отчетности и выставления счетов, мониторинга и устранения рисков.
Планирование безопасности
В рамках рекомендаций по проектированию, ориентированных на безопасность, мы рекомендуем следующие элементы:
Для управления ключами
Создайте выделенное хранилище Key Vault для выпуска проверяемых удостоверений. Ограничьте разрешения на доступ к Azure Key Vault для службы выдачи Проверенных учетных данных Microsoft Entra и субъекта-службы интерфейсного веб-сайта службы выдачи удостоверений.
Считайте Azure Key Vault системой с большими привилегиями, так как служба Azure Key Vault выпускает удостоверения для клиентов. Рекомендуется, чтобы ни у одного человека не было постоянных разрешений на доступ к службе Azure Key Vault. У администраторов должен быть доступ к службе Key Vault только в нужное время. Дополнительные рекомендации по использованию Azure Key Vault см. в статье Базовые показатели безопасности Azure для Key Vault.
Выполните указанные ниже действия для субъекта-службы, представляющего интерфейсный веб-сайт для выпуска удостоверений.
Настройте выделенный субъект-службу для авторизации доступа к Azure Key Vault. Если ваш веб-сайт находится в Azure, рекомендуется использовать управляемое удостоверение Azure.
Считайте субъект-службу, который представляет веб-сайт, и пользователя одной границей доверия. Хотя можно создать несколько веб-сайтов, существует только один набор ключей для решения выдачи.
Для ведения журнала безопасности и мониторинга рекомендуется использовать следующие элементы:
Включите функцию ведения журналов и предупреждений Azure Key Vault, чтобы отслеживать операции выдачи удостоверений, попытки извлечения ключей, изменения разрешений, а также чтобы отслеживать изменения конфигурации и отправлять оповещения о них. Дополнительные сведения можно найти в статье Включение журналирования Azure Key Vault.
Функция архивирования записывает в журнал информацию из систем обеспечения безопасности и управления событиями (SIEM), например из Microsoft Sentinel, для долгосрочного хранения.
Уменьшите риски спуфинга, используя указанные ниже средства.
Проверка DNS, позволяющая клиентам определить фирменную символику издателя.
Доменные имена, звучащие осмысленно для пользователей.
Доверенная фирменная символика, которую легко распознают пользователи.
Уменьшите риски распределенных атак типа "Отказ в обслуживании" (DDOS) и исчерпания ресурсов Key Vault. Каждый запрос, запускающий запрос на выпуск проверяемого удостоверения, создает операции подписывания Key Vault, которые приближают уровень использования службы к предельным значениям. Для защиты трафика рекомендуем использовать функцию проверки подлинности или CAPTCHA перед созданием запросов на выпуск.
Для управления средой Azure рекомендуется ознакомиться с эталонным показателем безопасности microsoft cloud security и обеспечением безопасности сред Azure с помощью идентификатора Microsoft Entra. В этих руководствах содержатся рекомендации по управлению базовыми ресурсами Azure, включая Azure Key Vault, службу хранилища Azure, веб-сайты и другие службы и возможности, связанные с Azure.
Дополнительные рекомендации
По завершении подтверждения концепции соберите все сведения и созданные документы и рассмотрите возможность удаления конфигурации издателя.
Дополнительные сведения о реализации и эксплуатации Key Vault см. в разделе Рекомендации по использованию Key Vault. Дополнительные сведения о защите сред Azure с помощью Active Directory см. в статье "Защита сред Azure с помощью идентификатора Microsoft Entra".