Поделиться через

Планируйте решение для проверки удостоверенной личности Microsoft Entra

  • Статья

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

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

Область рекомендаций

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

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

При планировании решения проверки необходимо учитывать, какие бизнес-возможности добавляются или изменяются. Кроме того, необходимо учитывать, какие возможности ит-специалистов можно повторно использовать, а также какие возможности необходимо добавить для создания решения. Кроме того, рассмотрим, какие учебные курсы необходимы для людей, участвующих в бизнес-процессе, и людей, которые поддерживают конечных пользователей и сотрудников решения. Эти статьи не рассматриваются в этом контенте. Мы рекомендуем ознакомиться с Microsoft Azure Well-Architected Framework для получения сведений об этих статьях.

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

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

схема компонентов решения проверки.

Служба проверенного идентификатора Microsoft Entra

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

Клиент Microsoft Entra

Для службы требуется клиент Microsoft Entra, предоставляющий плоскость управления "Управление удостоверениями и доступом" для ресурсов Azure, входящих в решение. Каждая организация Microsoft Entra использует мультитенантную службу Microsoft Entra Verified ID и выдает один документ DID, представляющий проверяющего. Если у вас есть несколько сторон, зависящих от вашей службы проверки, они все используют один и тот же верификатор DID. Средство проверки DID предоставляет указатели на открытый ключ, позволяющий субъектам и издателям проверять сообщения, поступающие от проверяющей стороны.

Azure Key Vault

схема компонентов решения проверки с выделенным хранилищем ключей Azure.

Служба Azure Key Vault хранит ключи проверки, которые создаются при включении службы выдачи проверенных удостоверений Microsoft Entra. Ключи используются для обеспечения безопасности сообщений. Каждый проверяющий имеет единственный набор криптографических ключей, используемый для подписания, обновления и восстановления проверяемых данных. Проверенный идентификатор использует этот набор ключей каждый раз, когда вы обслуживаете запрос проверки. В настоящее время набор ключей Майкрософт использует криптографию эллиптических кривых (ECC) SECP256k1. Мы изучаем другие схемы криптографических подписей, принятые более широким сообществом DID.

API службы запросов

схему компонентов решения проверки с выделенным API службы запросов.

Интерфейсы программирования приложений (API) предоставляют разработчикам метод абстрактного взаимодействия между компонентами решения для выполнения операций проверки.

Система доверия

схема компонентов решения проверки с выделенной системой доверия.

В настоящее время Microsoft Entra Verified ID поддерживает DID Web в качестве системы доверия, где документ DID размещен на веб-сервере выдающей организации.

Приложение Microsoft Authenticator

схема компонентов решения проверки с выделенным приложением Microsoft Authenticator.

Microsoft Authenticator — это мобильное приложение. Authenticator управляет взаимодействием между пользователем, службой Microsoft Entra VC и контрактом, используемым для выдачи удостоверений. Он выступает в качестве цифрового кошелька, в котором владелец VC хранит VC, включая закрытый ключ субъекта VC. Аутентификатор также является механизмом, используемым для предоставления проверяемых удостоверений для верификации.

Доверяющая сторона (RP)

схема компонентов решения проверки с выделенными компонентами проверяющей стороны.

Веб-интерфейс

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

Бизнес-логика

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

Дизайны, специфичные для сценариев

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

Подключение учетной записи

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

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

Другие элементы

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

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

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

  • Внешние удостоверения, подключаемые к идентификатору Microsoft Entra с использованием API для выдачи приглашений для бизнес-партнеров (B2B) или назначения для управления правами доступа на пакеты.

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

Рекомендации по проектированию

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

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

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

    • новый сотрудник: Когда рабочий процесс отдела кадров достигает стадии, на которой требуется удостоверение личности, РП может создать ссылку с уникальным идентификатором, действующим ограниченное время. Затем RP отправляет его на адрес электронной почты кандидата в системе кадров. Этот уникальный идентификатор должен быть достаточным для сопоставления таких сведений, как firstName, lastName из запроса проверки VC с записью в HR или основными данными. Атрибуты в VC можно использовать для выполнения атрибутов пользователей в системе кадров или проверки точности атрибутов пользователей о сотруднике.

    • Внешних удостоверений — приглашение: когда внешний пользователь приглашён в целевую систему, RP может создать ссылку с уникальным идентификатором, который представляет транзакцию приглашения. Эту ссылку можно отправить на адрес электронной почты внешнего пользователя. Этот уникальный идентификатор должен быть достаточен, чтобы сопоставить запрос проверки VC с записью приглашения или базовыми данными и продолжить процесс предоставления. Атрибуты в VC можно использовать для проверки или завершения атрибутов внешнего пользователя.

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

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

    • Чтобы создать нового пользователя в идентификаторе Microsoft Entra, веб-сайт RP может использовать субъект-службу, которому предоставлена область MS Graph User.ReadWrite.All для создания пользователей, и область UserAuthenticationMethod.ReadWrite.All для сброса метода проверки подлинности.

    • Чтобы пригласить пользователей в Microsoft Entra ID с помощью совместной работы B2B, веб-сайт RP может использовать учетную запись службы, которой предоставлен доступ к области MS Graph с идентификатором User.Invite.All для создания приглашений.

    • Если ваш RP работает в Azure, используйте управляемые идентификаторы для вызовов Microsoft Graph. Использование управляемых удостоверений устраняет риски управления учетными данными служебного принципала в коде или файлах конфигурации. Дополнительные сведения об управляемых удостоверениях см. в разделе Управляемые удостоверения для ресурсов Azure.

Доступ к высокоценным приложениям внутри организаций

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

схема компонентов решения проверки с другими элементами.

Другие элементы

Веб-интерфейс доверяющей стороны — это веб-интерфейс приложения, который расширен с помощью вызовов API службы запросов для презентации и проверки VC в соответствии с вашими бизнес-требованиями.

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

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

Рекомендации по проектированию

  • цель. Цель сценария определяет тип учетных данных и издателя. К типичным сценариям относятся:

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

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

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

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

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

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

Доступ к приложениям вне границ организации

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

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

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

Другие элементы

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

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

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

Рекомендации по проектированию

  • цель. Цель сценария определяет, какие удостоверяющие данные и эмитент необходимы. К типичным сценариям относятся:

    • аутентификация. В этом сценарии пользователь должен иметь VC для подтверждения трудоустройства или своей связи с определённой организацией (или организациями). В этом случае RP следует настроить для принятия удостоверений, выданных целевыми организациями.

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

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

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

Восстановление учетной записи

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

Заметка

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

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

Другие элементы

портал учетной записи: веб-интерфейс, который управляет вызовами API для презентации и проверки VC. Эта оркестрация может включать вызовы Microsoft Graph для восстановления учетных записей в идентификаторе Microsoft Entra.

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

Microsoft Graph: предоставляет API и клиентские библиотеки REST для доступа к данным Microsoft Entra, которые используются для восстановления учетных записей.

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

Рекомендации по проектированию

корреляция атрибутов верифицируемых удостоверений (VC) с идентификатором Microsoft Entra ID: при определении атрибутов верифицируемых удостоверений в сотрудничестве с издателем убедитесь, что вы согласны с утверждениями, которые идентифицируют пользователя. Например, если поставщик проверки личности (IDV) проверяет удостоверение личности до подключения сотрудников, убедитесь, что выпущенные верификационные документы (VC) содержат утверждения, которые можно сопоставить с внутренними системами. Такие утверждения могут быть номером телефона, адресом или датой рождения. RP может в рамках этого процесса запросить информацию, не найденную в VC, например, последние четыре цифры вашего номера социального страхования (SSN).

Роль венчурных капиталистов с существующими возможностями сброса учетных данных Microsoft Entra: Microsoft Entra ID имеет встроенную функцию самостоятельного сброса пароля (SSPR). Верифицируемые учетные данные можно использовать для предоставления другого способа восстановления, когда у пользователей нет доступа к методу SSPR или они утратили контроль над ним. В ситуациях, когда пользователь потерял компьютер и мобильный телефон, он может заново получить VC от выдавшего удостоверение личности и представить его для восстановления учетной записи дистанционно.

Аналогичным образом, можно использовать виртуальную карту (VC) для генерации временного доступа, позволяющего пользователям осуществлять сброс методов аутентификации MFA без пароля.

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

взаимодействие с идентификатором Microsoft Entra ID: обмен данными между веб-фронтендом и идентификатором Microsoft Entra ID должен быть защищен в качестве высокопривилегированной системы, так как она может сбросить учетные данные сотрудников. Предоставьте веб-интерфейсу наименее привилегированные роли. Ниже приведены некоторые примеры:

  • Предоставьте веб-сайту RP возможность использовать основной сервис с областью MS Graph UserAuthenticationMethod.ReadWrite.All для сброса методов проверки подлинности. Не предоставляйте User.ReadWrite.All, что позволяет создавать и удалять пользователей.

  • Если ваш поставщик ресурсов (RP) работает в Azure, используйте службу Managed Identities для вызова Microsoft Graph. Управляемые удостоверения устраняют риски, связанные с управлением учетными данными принципала службы в файлах кода или конфигурации. Дополнительные сведения см. в разделе «Управляемые удостоверения для ресурсов Azure».

План управления удостоверениями

Ниже приведены рекомендации по IAM при включении удостоверяющих данных в доверяющие стороны. Доверяющие стороны — это обычно приложения.

Аутентификация

  • Субъект VC должен быть человеком.

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

Авторизация

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

  • Определите, имеет ли истекший VC значение в вашем приложении; если это так, проверьте значение утверждения exp (время окончания срока действия) VC в процессе проверок авторизации. В одном из примеров, когда срок действия не имеет значения, требуется документ, выданный правительством, например водительское удостоверение, чтобы проверить, старше ли субъект старше 18. Утверждение о дате рождения действительно, даже если срок действия VC истек.

  • Определите, имеет ли значение отзыв VC для вашего решения об авторизации.

    • Если это не так, пропустите вызов для проверки API состояния (который включен по умолчанию).

    • Если это важно, добавьте правильную обработку исключений в приложении.

Профили пользователей

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

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

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

  • Если приложению требуется постоянное хранилище профилей пользователей:

    • Рассмотрите возможность использования утверждения sub в качестве неизменяемого идентификатора пользователя. Это непрозрачный уникальный атрибут, который постоянен для заданной пары субъект/RP.

    • Определите механизм для удаления профиля пользователя в приложении. Из-за децентрализованной природы системы проверенных идентификаторов Microsoft Entra нет жизненного цикла подготовки пользователей приложений.

    • Не сохраняйте претензии на личные данные, возвращаемые в токене VC.

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

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

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

Следующие элементы предоставляют области, которые следует учитывать при планировании производительности:

  • Служба выдачи проверенных идентификаторов Microsoft Entra развернута в регионах Западной Европы, Северной Европы, Западной части США 2 и Центрально-Западной части США Azure. Чтобы ограничить задержку, разверните интерфейс проверки (веб-сайт) и хранилище ключей в ближайшем регионе.

  • Модель на основе пропускной способности:

План надежности

Чтобы лучше планировать высокий уровень доступности и аварийное восстановление, мы предлагаем следующие элементы:

  • Служба проверки идентификаторов Microsoft Entra развернута в регионах Azure "Западная Европа", "Северная Европа", "Западная часть США 2" и "Западная часть США", "Австралия" и "Япония". Рассмотрите возможность развертывания вспомогательных веб-серверов и вспомогательных приложений в одном из этих регионов, в частности в тех, из которых вы ожидаете, что большая часть трафика проверки будет получена.

  • Ознакомьтесь с рекомендациями по доступности и избыточности Azure Key Vault по мере разработки целей доступности и избыточности.

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

При проектировании безопасности рассмотрите следующее:

  • Все доверяющие стороны (RP) в одном арендаторе имеют одинаковую границу доверия, так как они разделяют один и тот же децентрализованный идентификатор (DID).

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

  • Только служба Verified ID Microsoft Entra и веб-сервисные субъекты должны иметь разрешения на использование Key Vault для подписывания сообщений с закрытым ключом.

  • Не назначайте административные разрешения для идентификаторов пользователей в Key Vault. Дополнительные сведения о рекомендациях по работе с Key Vault см. в основных принципах безопасности Azure для Key Vault.

  • Ознакомьтесь с руководством Обеспечение безопасности сред Azure с помощью Microsoft Entra ID, чтобы изучить лучшие практики управления вспомогательными службами для вашего решения.

  • Устранение рисков спуфингов путем:

    • Реализация проверки DNS для помощи клиентам в идентификации брендинга эмитента.

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

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

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

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

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

  • Для масштабируемости:

    • Отслеживайте сбой проверки VC в рамках сквозных метрик безопасности приложений.

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

  • Для надежности и зависимостей:

  • Длябезопасности:

    • Включите ведение журнала для Key Vault для отслеживания операций подписывания и отслеживания изменений конфигурации и оповещений о ней. Для получения дополнительной информации см. статью Как включить ведение журнала в Key Vault.

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

Дальнейшие действия

Дополнительные сведения о разработке решений VC

Реализация проверяемых учетных данных

часто задаваемые вопросы