Обзор архитектуры Подтвержденных идентичностей Microsoft Entra

Обзор

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

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

• Планирование решения по выпуску

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

Подходы к идентичности

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

Централизованные системы идентификации

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

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

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

• безопасное введение идентификаторов сотрудников и других пользователей, включая в удалённых условиях;

• доступ к ресурсам в пределах границы доверия организации исходя из определенных критериев;

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

Децентрализованные системы идентификации

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

Рассмотрим сценарий на схеме, где Proseware, веб-сайт электронной коммерции, хочет предложить сотрудникам Woodgrove корпоративные скидки.

Терминология, связанная с проверяемыми удостоверениями (VC) может вводить в замешательство, если вы не знакомы с VC. Следующие определения взяты из раздела о терминологии Модель данных проверяемых удостоверений 1.0. После каждого определения они связаны с сущностями на предыдущей схеме.

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

• Компания Woodgrove на предыдущей схеме — это издатель проверяемых удостоверений для своих сотрудников.

"Владелец — это роль, которую сущность может выполнять, обладая одним или несколькими проверяемыми учетными данными и создавая презентации из них. Владелец обычно, но не всегда, является субъектом проверяемых удостоверяющих данных, которые он держит. Владельцы учетных данных хранят свои учетные данные в репозиториях учетных данных.

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

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

• На предыдущей схеме компания Proseware является проверяющей выданных компанией Woodgrove удостоверений.

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

"Децентрализованный идентификатор — это переносимый URI-идентификатор, также известный как DID, связанный с сущностью. Эти идентификаторы часто используются в проверяемых удостоверениях и связаны с субъектами, издателями и верификаторами.

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

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

• Компания Woodgrove (издатель) подписывает проверяемые удостоверения (VCs) своих сотрудников с помощью закрытого ключа; аналогичным образом, компания Proseware (проверяющий) подписывает запросы на представление проверяемого удостоверения, используя свой ключ, который также связан с соответствующим DID.

Система доверия является основой для установления доверия между децентрализованными системами. Это может быть распределенный реестр или даже что-то централизованное, например DID Web.

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

Сочетание централизованных и децентрализованных архитектур идентификации

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

Путь взаимодействия пользователя

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

Субъекты в этих вариантах использования

• Алиса, лицо, подающее заявку на вакансию и трудоустраивающееся в компанию Woodgrove, Inc.

• Фиктивная компания Woodgrove, Inc.

• Компания Adatum, фиктивный партнер компании Woodgrove по проверке личности.

• Компания Proseware, фиктивная организация, состоящая в партнерстве с компанией Woodgrove.

В Woodgrove применяются как централизованные, так и децентрализованные архитектуры идентификации.

Этапы пути взаимодействия пользователя

• Алиса подает заявку на вакансию, принимает предложение и устраивается на работу в компанию Woodgrove, Inc.

• Доступ к цифровым ресурсам в пределах границы доверия компании Woodgrove.

• Доступ к цифровым ресурсам за пределами границы доверия компании Woodgrove без расширения границ доверия компании Woodgrove или ее партнеров.

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

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

Путь взаимодействия пользователя: трудоустройство в компании Woodgrove

Осведомленность: Алиса интересуется работой в компании Woodgrove, Inc. и посещает веб-сайт с вакансиями компании.

Активация: на сайте компании Woodgrove Алисе предлагается способ подтверждения личности, предоставляя QR-код или прямую ссылку для посещения ее доверенного партнера по проверке личности, компании Adatum.

Запрос и отправка: компания Adatum запрашивает у Алисы подтверждение личности. Алиса делает селфи, берет фотографию из водительских прав и отправляет снимки в Adatum.

Издание: после того, как в Adatum проверят личность Алисы, ей выдают проверяемое удостоверение (VC), подтверждающее ее личность.

Предъявление: Алиса (держатель и субъект удостоверения) может затем получить доступ к порталу вакансий компании Woodgrove, чтобы завершить процедуру подачи заявки. Когда Алиса использует VC для доступа к порталу, Woodgrove играет роли проверяющего и доверяющей стороны, доверяя аттестации, выполненной Adatum.

Предоставление начальных учетных данных

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

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

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

• Издатель отвечает за проверку утверждений, относящихся к издаваемому им VC. Компания Adatum подтверждает личность Алисы, чтобы выдать верифицированное свидетельство. В этом случае удостоверения выдаются без учета проверяющей или полагающейся стороны.

• Держатель обладает VC и начинает процесс предъявления VC для проверки. Только Алиса может предоставлять проверяемые удостоверения, которые она держит.

• Проверяющий соглашается с утверждениями в VC, сделанными издателями, которым он доверяет, и проверяет VC, используя децентрализованную возможность реестра, описанную в модели данных проверяемых удостоверений. Woodgrove доверяет утверждениям Adatum о личности Алисы.

За счет комбинирования централизованных и децентрализованных архитектур идентификации при подключении конфиденциальные сведения об Алисе, необходимые для проверки личности, такие как государственный идентификационный номер, не нужно хранить в компании Woodgrove, поскольку они доверяют, что VC, выданное партнером по проверке личности (компанией Adatum), подтверждает ее личность. Дублирование усилий сводится к минимуму. При этом можно реализовать программный прогнозируемый подход к начальным задачам подготовки к работе.

Путь взаимодействия пользователя: доступ к ресурсам внутри границы доверия

Будучи сотрудником, Алиса работает в пределах границы доверия компании Woodgrove. Woodgrove выступает в качестве поставщика удостоверений (IDP) и обеспечивает полный контроль над удостоверением и конфигурацией приложений, которые Алиса использует для взаимодействия в пределах границы доверия Woodgrove. Чтобы использовать ресурсы в границе доверия Microsoft Entra ID, Алиса может предоставить несколько способов удостоверения личности для входа в границу доверия Woodgrove и доступа к ресурсам внутри технологической инфраструктуры Woodgrove. Несколько проверок — это типичный сценарий, который хорошо поддерживается с помощью централизованной архитектуры идентификации.

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

• Алиса использует только удостоверение, которое Woodgrove поддерживает для доступа к ее ресурсам. Алисе не нужно отслеживать, когда используются учетные данные, так как менеджментом этих данных занимается Woodgrove, и они используются только с ресурсами Woodgrove. Этот идентификатор допустим только внутри границы доверия Woodgrove, когда необходим доступ к ресурсам Woodgrove. Поэтому Алисе не требуется владеть удостоверением.

Использование VC внутри границы доверия

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

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

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

Путь взаимодействия пользователя: доступ к внешним ресурсам

Woodgrove согласует скидку на покупку продукта с компанией Proseware. Все сотрудники Woodgrove имеют право на эту скидку. Компания Woodgrove хочет предоставить Алисе способ доступа к веб-сайту Proseware и получения скидки при приобретении продуктов. Если в Woodgrove используется централизованная архитектура идентификации, существует два подхода к предоставлению Алисе скидки.

• Алиса может предоставить персональные данные для создания учетной записи с помощью Proseware, а затем компания Proseware проверит трудоустройство Алисы в Woodgrove.

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

При использовании децентрализованных идентификаторов Woodgrove может предоставить Алисе проверяемое удостоверение (VC), которое Алиса может использовать для доступа к веб-сайту Proseware и другим внешним ресурсам.

Предоставляя Алисе VC, компания Woodgrove подтверждает, что Алиса является ее сотрудником. Woodgrove является доверенным издателем удостоверений в решении для валидации компании Proseware. Такое доверие к процессу выпуска в Woodgrove позволяет компании Proseware принимать VC в электронном виде как доказательство того, что Алиса является сотрудником компании Woodgrove, и предоставить Алисе скидку. В ходе проверки предъявленного Алисой VC Proseware удостоверяется в допустимости VC с помощью системы доверия. В этом решении:

• Woodgrove позволяет Алисе предоставлять Proseware доказательство трудоустройства без необходимости расширения границы доверия компанией Woodgrove.

• Proseware не требуется расширять границу доверия для проверки того, что Алиса является сотрудником компании Woodgrove. Вместо этого Proseware может использовать VC, предоставляемое Woodgrove. Так как граница доверия не расширяется, управление отношением доверия упрощается, и Proseware может легко завершить отношения, перестав принимать виртуальные удостоверения (VC).

• Алиса не обязана предоставлять Proseware персональные данные, такие как адрес электронной почты. Алиса управляет VC в приложении кошелька на личном устройстве. Единственное лицо, которое может использовать VC, — это Алиса, и Алиса должна инициировать использование удостоверения. Каждое использование VC записывается приложением кошелька, поэтому Алиса имеет запись о том, когда и где используется VC.

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

Изменения с течением времени

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

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

• В централизованных архитектурах идентификации поставщик удостоверений (IDP) издает удостоверения и выполняет проверку этих изданных удостоверений. ПУ обрабатывает сведения обо всех идентичностях. Он либо сохраняет их в каталоге, либо извлекает их из каталога. При необходимости идентификационные провайдеры могут принимать токены безопасности из других систем идентификационных провайдеров, таких как социальные сети или деловые партнеры. Чтобы доверяющая сторона использовала идентификаторы в границах доверия провайдера удостоверений (IDP), она должна быть настроена на прием токенов, выдаваемых IDP.

Как работают децентрализованные системы идентификации

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

Например, если держателям VC нужен доступ к ресурсу, они должны предъявить VC проверяющей стороне. Это делается с помощью приложения кошелька для чтения запроса проверяющей стороны на предъявление удостоверяемого документа. В рамках чтения запроса приложение кошелька использует DID RP для поиска его открытых ключей с помощью системы доверия, проверяя, что запрос на представление VC не подвергся изменению. Чтобы доказать владение доменом, кошелек также проверяет, что DID ссылается на документ метаданных, размещенный в домене RP в DNS.

Поток 1: издание проверяемого удостоверения

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

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

2. Веб-интерфейс издателя вызывает службу Проверенные учетные данные Microsoft Entra для создания запроса на выдачу VC.

3. Внешний веб-интерфейс отображает ссылку на запрос в виде QR-кода или прямой ссылки для устройства (в зависимости от устройства).

4. Владелец сканирует QR-код или глубокую ссылку на шаге 3 с помощью приложения "Кошелек", например Microsoft Authenticator

5. Кошелек скачивает запрос по ссылке. Запрос включает следующее:

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

   • URL-адрес с манифестом VC, который указывает требования к контракту для выпуска VC. Требование контракта может включать id_token, самоподтверждённые атрибуты, которые должны быть предоставлены, или представление другого верифицируемого свидетельства (VC).

   • внешний вид VC (URL-адрес файла логотипа, цвета и т. д.).

6. Кошелек проверяет запросы на эмиссию и обрабатывает условия контракта.

   1. Проверяет, подписано ли сообщение запроса на выдачу ключами издателя, найденными в документе DID, разрешенном через систему доверия. Проверка подписи гарантирует, что сообщение не было изменено.

   2. Проверяет, владеет ли владелец DNS-доменом, на который ссылается документ DID издателя.

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

7. Отправляет документы, требуемые по контракту, в службу Microsoft Entra Verified ID. Служба Microsoft Entra по верификации удостоверений возвращает ВУ (верифицированные удостоверения), подписанные ключом DID издателя, и кошелек надежно сохраняет ВУ.

Подробные сведения о том, как создать решение для издания и рекомендации по архитектуре, см. в статье Планирование решения для издания Проверенных учетных данных Microsoft Entra.

Процесс 2: предъявление проверяемого удостоверения

В этом потоке держатель взаимодействует со стороной доверия для предъявления VC в рамках требований авторизации.

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

2. Веб-интерфейс вызывает службу Проверенные учетные данные Microsoft Entra для создания запроса презентации VC.

3. Внешний веб-интерфейс отображает ссылку на запрос в виде QR-кода или прямой ссылки для устройства (в зависимости от устройства).

4. Держатель сканирует QR-код или переходит по прямой ссылке, описанной в шаге 3, с помощью приложения кошелька, такого как Microsoft Authenticator.

5. Кошелек скачивает запрос по ссылке. Запрос включает следующее:

   • запрос на основе стандартов удостоверений схемы или типа удостоверения;

   • DID доверяющей стороны, который кошелек ищет в системе доверия.

6. Кошелек проверяет запрос презентации и находит сохраненные VC,которые удовлетворяют запросу. Исходя из требуемых проверяемых удостоверений (VC), кошелек направляет субъекта на выбор и согласие на их использование.

   • Субъект соглашается поделиться VC с RP

   Затем кошелек отправляет полезные данные ответа презентации в службу Проверенные учетные данные Microsoft Entra, подписанные субъектом. Она содержит:

   • VC, на применение которых согласился субъект;

   • Тема DID.

   • RP DID в качестве "аудитории" полезных данных.

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

8. После проверки служба Microsoft Entra Verified ID вызывает доверяющую сторону (RP) с результатом.

Подробные сведения о том, как создать решение для проверки и рекомендации по архитектуре, см. в статье Планирование решения для проверки Проверенных учетных данных Microsoft Entra.

Основные выводы

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

Чтобы достичь целей Децентрализованного фонда удостоверений (DIF) и W3C по проектированию, при создании решения проверяемых удостоверений следует учитывать следующие элементы:

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

  • Система доверия позволяет обнаружить децентрализованный идентификатор (DID) любого субъекта.

• Это решение позволяет проверяющим верифицировать любые проверяемые удостоверения (VC) любого издателя.

• Оно не дает издателю возможность управлять авторизацией субъекта или проверяющего (проверяющей стороны).

• Субъекты работают несвязанно, и каждый из них способен выполнять задачи для своих ролей.

  • Эмитенты обрабатывают каждый запрос на VC и не делают различий между обслуживаемыми запросами.

  • После издания VC субъекты начинают владеть ими и могут предъявлять свое VC любому проверяющему.

  • Проверяющие могут проверить любое VC от любого субъекта или издателя.

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

Узнайте больше об архитектуре проверяемых удостоверений

• Планирование решения по выпуску

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

• Начало работы с Microsoft Entra Verified ID