Планирование системы выдачи проверенных удостоверений личности Microsoft Entra

Обзор

Важно спланировать ваше решение для выпуска удостоверений таким образом, чтобы, помимо самих удостоверений, вы имели полное представление о влиянии вашего решения на архитектурные и бизнес-процессы. Если вы еще этого не сделали, ознакомьтесь с обзором архитектуры проверенного идентификатора Microsoft Entra для получения базовых сведений.

Область действия руководства

В этой статье рассматриваются технические аспекты планирования решения по выдаче подтверждаемых учетных данных (VC). Решение Майкрософт для проверяемых удостоверений основано на стандартах Verifiable Credentials Data Model 1.0 и Decentralized Identifiers (DIDs) V1.0 консорциума W3C, поэтому оно может взаимодействовать со службами сторонних поставщиков. Тем не менее в примерах в данной статье отражен стек решений Майкрософт для проверяемых удостоверений.

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

Компоненты решения

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

Архитектура решения Microsoft для выпуска VC удостоверений

Клиент Microsoft Entra

Вам нужен доступ к клиенту Microsoft Entra для размещения проверенного идентификатора Microsoft Entra. Клиент Microsoft Entra предоставляет панель управления "Управление удостоверениями и доступом" (IAM) для ресурсов, являющихся частью решения.

Каждый клиент использует мультитенантную службу Проверенные учетные данные Microsoft Entra и имеет децентрализованный идентификатор (DID). DID предоставляет доказательства того, что издатель владеет доменом, включенным в DID. DID используется субъектом и проверяющим для проверки подлинности издателя.

Службы Microsoft Azure

В службе Azure Key Vault хранятся ключи издателя, создаваемые при активации службы выдачи Проверенных учетных данных Microsoft Entra. Ключи и метаданные используются для выполнения операций управления удостоверениями и обеспечения безопасности сообщений.

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

Microsoft Entra Verified ID Service используется для хранения метаданных и определений цифровых учетных данных; в частности, правил и описаний отображения для ваших учетных данных.

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

• Правила создаются по модели, определяемой издателем, и описывают требования к входным данным для проверяемого удостоверения. Правила также определяют доверенные источники входных данных и сопоставление входных утверждений с выходными утверждениями, хранящимися в VC. В зависимости от типа аттестации, который указан в определении правил, входные утверждения могут поступать от разных поставщиков. Входные утверждения могут поступать от поставщика удостоверений 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 — это мобильное приложение. Аутентификатор управляет взаимодействием между пользователем, службой Microsoft Entra Verified ID и контрактом, используемым для выдачи проверенных учетных данных. Оно действует как цифровой бумажник, в котором владелец VC хранит VC, включая закрытый ключ субъекта VC. Приложение Authenticator также является механизмом, используемым для предоставления проверяемых удостоверений (VC) на проверку.

Бизнес-логика выпуска сертификатов

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

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

Эти службы предоставляют вспомогательные роли, которые не обязательно должны интегрироваться с службой выдачи Проверенные учетные данные Microsoft Entra. Этот уровень обычно включает в себя указанные ниже элементы.

• Служба или службы , совместимые с OpenID Connect (OIDC), используются для получения id_tokens, необходимых для выдачи VC. Существующие системы идентификации, такие как Microsoft Entra ID или Azure AD B2C, могут предоставлять службу, совместимую с OIDC, также как и пользовательские решения, такие как Identity Server.

• Хранилища атрибутов — хранилища атрибутов могут находиться вне служб каталогов и предоставлять атрибуты, необходимые для выдачи 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 может содержать следующие типы:

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

• Минимизация частных сведений: соблюдайте условия сценариев использования, применяя минимально необходимое количество частных сведений. Например, удостоверение, используемое на веб-сайтах электронной коммерции для предоставления скидок сотрудникам и выпускникам, можно предоставить, предъявив данные только об имени и фамилии. Дополнительные сведения, например дата найма на работу, должность, отдел, не требуются.

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

  • Одна для запроса на выпуск с веб-сайта

  • Одна для созданного проверяемого удостоверения

  • Одна для скачивания контракта

• Невозможно контролировать регулирование; Однако ознакомьтесь с руководством по регулированию Azure Key Vault.

• Если вы планируете крупное развертывание и подключение виртуальных машин, рассмотрите возможность пакетного создания VC, чтобы не превышать пределы.

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

Для масштабируемости рекомендуется реализовать метрики для следующих элементов:

• Определите логические этапы процесса выпуска удостоверений. Например:

• Первоначальный запрос

• Обслуживание QR-кодов или прямых ссылок

• Поиск атрибутов

• Обращения к службе выдачи Проверенных учетных данных Microsoft Entra

• Удостоверение выдано

• Определите метрики на основе указанных ниже этапов.

  • Общее количество запросов (объем)

  • Количество запросов на единицу времени (пропускная способность)

  • Затраченное время (задержка)

• Мониторьте Azure Key Vault по следующей ссылке:

  • Мониторинг и оповещения для Azure Key Vault

• Отслеживайте компоненты, используемые для уровня бизнес-логики.

Планирование для надежности

Планирование надежности:

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

  • Доступность и избыточность хранилища ключей Azure

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

В случае маловероятного события, когда служба выдачи Проверенных учетных данных Microsoft Entra или службы Azure Key Vault становятся недоступными, всё решение также становится недоступным.

Планирование обеспечения соответствия требованиям

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

Место расположения данных: служба выдачи Проверенных учетных данных Microsoft Entra развернута в ограниченном числе регионов Azure. Эта служба используется только для вычислительных функций. Значения проверяемых учетных данных не хранятся в системах Майкрософт. Тем не менее, в процессе выдачи удостоверений мы используем и пересылаем личные данные. Использование службы VC не должно влиять на требования о месте расположения данных. Если вы храните личную информацию в рамках проверки подлинности, убедитесь, что она хранится таким образом и регионом, который соответствует вашим требованиям. Инструкции, связанные с Azure, см. в Центре управления безопасностью Майкрософт.

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

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

Планирование операций

При планировании операций важно разработать схему для устранения неполадок, создания отчетов и различения различных клиентов, которые вы поддерживаете. Кроме того, если за отзыв верифицируемых удостоверений отвечает группа эксплуатации, необходимо четко определить этот процесс. Каждый шаг в этом процессе должен быть скоррелирован, чтобы можно было определить, какие записи журналов могут быть связаны с каждым уникальным запросом на выпуск. Для аудита фиксируйте каждую попытку выдачи учетных данных отдельно. В частности:

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

• Продумайте механизм коррелирования журналов транзакций Azure Key Vault с идентификаторами транзакций в части решения, связанной с выпуском удостоверений.

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

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

Планирование безопасности

В рамках рекомендаций по проектированию, ориентированных на безопасность, рассмотрите следующие элементы:

• Для управления ключами

  • Создайте выделенное хранилище Key Vault для выпуска VC. Ограничьте разрешения на доступ к 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, чтобы отслеживать операции выдачи удостоверений, попытки извлечения ключей, изменения разрешений, а также чтобы отслеживать изменения конфигурации и отправлять оповещения о них. Дополнительные сведения можно найти в разделе Как включить журналирование Key Vault.

• Архивируйте журналы в системах управления информацией о безопасности и событиями (SIEM), таких как Microsoft Sentinel, для их долгосрочного хранения.

• Уменьшите риски спуфинга, используя указанные ниже средства.

  • Проверка DNS, позволяющая клиентам определить фирменную символику издателя.

  • Доменные имена, звучащие осмысленно для пользователей.

  • Доверенная фирменная символика, которую легко распознают пользователи.

• Уменьшите риски распределенных атак типа "Отказ в обслуживании" (DDOS) и исчерпания ресурсов Key Vault. Каждый запрос, инициирующий выпуск проверяемого удостоверения, создает операции подписывания с помощью Key Vault, которые засчитываются в лимиты использования службы. Для защиты трафика рекомендуем использовать функцию проверки подлинности или CAPTCHA перед созданием запросов на выпуск.

Для управления средой Azure рекомендуется ознакомиться с Microsoft Cloud Security Benchmark и защитой сред Azure с помощью Microsoft Entra ID. В этих руководствах содержатся рекомендации по управлению базовыми ресурсами Azure, включая Azure Key Vault, службу хранилища Azure, веб-сайты и другие службы и возможности, связанные с Azure.

Другие вопросы

По завершении пилотного проекта соберите все данные и созданные документы, а затем рассмотрите возможность устранения конфигурации издателя.

Дополнительные сведения о реализации и эксплуатации Key Vault см. в разделе Рекомендации по использованию Key Vault. Дополнительные сведения о защите клиентов Microsoft Entra с помощью идентификатора Microsoft Entra см. в статье "Введение в делегированное администрирование и изолированные среды".

Следующие шаги

Прочитайте общие сведения об архитектуре

Спланируйте ваше решение для проверки

Как начать работать с проверяемыми удостоверениями