Планирование решения для проверки Проверенных учетных данных Microsoft Entra
Служба microsoft Проверенные учетные данные Microsoft Entra (Microsoft Entra VC) позволяет доверять подтверждениям удостоверения пользователя без расширения границы доверия. При использовании Microsoft Entra VC вы создаете учетные записи или федеративные учетные записи с другим поставщиком удостоверений. Если решение реализует обмен данными проверки с для проверяемых удостоверений, приложения получают возможность запрашивать учетные данные, которые не привязаны к определенному домену. Этот подход упрощает масштабные операции запроса и проверки учетных данных.
Если вы еще этого не сделали, рекомендуем ознакомиться с обзором архитектуры Проверенных учетных данных Microsoft Entra. Вы также хотите просмотреть решение о выпуске Проверенные учетные данные Microsoft Entra.
Область действия руководства
Это содержимое охватывает технические аспекты планирования проверяемого решения проверки учетных данных с помощью продуктов и служб Майкрософт. Интерфейсы решения с системой доверия, где в настоящее время поддерживается ВЕБ-сайт DID. DID Web — это централизованная инфраструктура открытых ключей.
Вспомогательные технологии, не относящиеся к решениям для проверки, не рассматриваются в этом документе. Например, в решении для проверки проверяемых удостоверений используются веб-сайты, но планирование развертывания веб-сайтов не рассмотрено подробно.
При планировании решения для проверки необходимо учитывать, какие бизнес-возможности вы добавляете. Необходимо также принимать во внимание, какие средства ИТ можно использовать многократно или необходимо добавить для создания решения. Необходимо также учитывать, какие обучающие материалы необходимы для сотрудников, участвующих в бизнес-процессе, для специалистов, которые будут поддерживать конечных пользователей, и для сотрудников решения. Эти статьи не рассматриваются в настоящем документе. Сведения по этим вопросам можно найти в описании платформы Microsoft Azure с продуманной архитектурой.
Компоненты решения
В плане решения для проверки необходимо предусмотреть взаимодействие между проверяющим, субъектом и издателем. В этой статье термины и "проверяющая сторона" и "проверяющий" взаимозаменяемы. На схеме ниже показаны компоненты архитектуры вашего решения для проверки.
Служба "Проверенные учетные данные Microsoft Entra"
В контексте решения для проверки служба Проверенных учетных данных Microsoft Entra предоставляет интерфейс между включенными в решение компонентами корпорации Microsoft и системой доверия. Эта служба предоставляет набор ключей для Key Vault и децентрализованный идентификатор (DID).
Клиент Microsoft Entra
Для службы требуется клиент Microsoft Entra, предоставляющий плоскость управления "Управление удостоверениями и доступом" для ресурсов Azure, входящих в решение. Каждый клиент Microsoft Entra использует службу Проверенные учетные данные Microsoft Entra нескольких клиентов и выдает один документ DID, представляющий проверяющий объект. Если со службой проверки работают несколько проверяющих сторон, все они используют один DID проверяющего. Проверяющий предоставляет указатели на открытый ключ, позволяющие субъектам и издателям проверять сообщения, поступающие от проверяющей стороны.
Azure Key Vault
В службе Azure Key Vault хранятся ваши ключи проверяющего, создаваемые при включении службы выдачи Проверенных учетных данных Microsoft Entra. Ключи используются для обеспечения безопасности сообщений. У каждого проверяющего есть один набор ключей, используемый для подписывания, обновления и восстановления ПУ. Этот набор ключей используется каждый раз при обработке запроса на проверку. В настоящее время для набора ключей Майкрософт используется шифрование на основе эллиптических кривых (ECC) SECP256k1. Мы изучаем другие схемы криптографических подписей, принятые более широким сообществом DID.
API службы запросов
Программные интерфейсы (API) служат для разработчиков средством для абстрактного взаимодействия между компонентами решения для выполнения операций проверки.
Система доверия
Проверенные учетные данные Microsoft Entra в настоящее время поддерживается DID Web в качестве системы доверия, где документ DID размещается на веб-сервере издателей.
Приложение Microsoft Authenticator
Microsoft Authenticator — это мобильное приложение. Authenticator управляет взаимодействием между пользователем, службой Проверенные учетные данные Microsoft Entra и контрактом, используемым для выдачи виртуальных машин. Оно выступает в качестве цифрового бумажника, в котором владелец проверяемого удостоверения хранит это проверяемое удостоверение, в том числе закрытый ключ субъекта проверяемого удостоверения. Приложение Authenticator также является механизмом, используемым для предоставления проверяемых удостоверений на проверку.
Проверяющая сторона
Клиентский веб-интерфейс
Веб-интерфейс проверяющей стороны использует API службы запросов для проверки виртуальных машин путем создания глубоких ссылок или QR-кодов, которые использует кошелек субъекта. В зависимости от сценария внешний интерфейс может быть общедоступным или внутренним веб-сайтом, позволяющим обеспечить взаимодействие с конечными пользователями, которым нужна проверка. При этом конечные точки, к которым обращается бумажник, должны быть общедоступными. В частности, он управляет перенаправлением в бумажник с параметрами конкретного запроса.
Бизнес-логика
Вы можете создать новую или использовать существующую логику проверяющей стороны и улучшить ее с использованием представления ПУ.
Схемы для конкретных сценариев
Ниже приведены примеры схем для конкретных вариантов использования. Первый предназначен для подключения учетных записей и позволяет сократить время, затраты и риски, связанные с адаптацией новых сотрудников. Второй предназначен для восстановления учетных записей и позволяет конечному пользователю восстановить или разблокировать свою учетную запись с помощью механизма самообслуживания. Третий предназначен для доступа к приложениям и ресурсам с высокой ценностью, а именно для сценариев использования, когда доступ предоставляется людям, работающим в других компаниях.
Подключение учетной записи
Проверяемые удостоверения позволяют ускорить подключение, заменяя некоторые взаимодействия, требующие участия человека. Проверяемые удостоверения можно использовать для предоставления сотрудникам, студентам, гражданам или других пользователям доступа к службам и услугам. Например, вместо сотрудника, который должен отправиться в центральный офис, чтобы активировать значок сотрудника, можно использовать проверяемое удостоверение для подтверждения личности и удаленной активации соответствующего значка. Вместо получения кода, который гражданин должен активировать для доступа к государственным услугам, он может подтвердить личность и получить доступ с помощью проверяемого удостоверения.
Другие элементы
Портал подключения. Это веб-интерфейс, который координирует вызовы к API службы запросов для представления и проверки проверяемого удостоверения, а также управляет логикой подключения учетных записей.
Настраиваемая логика или рабочие процессы. Конкретная логика с действиями, характерными для организации, до и после обновления учетной записи пользователя. В число примеров могут входить рабочие процессы утверждения, другие проверки, ведение журнала, уведомления и т. д.
Целевые системы идентификации. Репозитории удостоверений организации, с которым должен взаимодействовать портал подключения при подключения субъектов. Системы, которые требуется интегрировать, зависят от типов удостоверений, которые вы хотите подключать в ходе проверки проверяемых удостоверений. Вот распространенные сценарии проверки удостоверений для подключения:
Внешние удостоверения, подключенные к идентификатору Microsoft Entra с помощью API для выдачи приглашений бизнес-бизнеса (B2B) или назначения управления правами пакетам.
Удостоверения сотрудников, которые в централизованных системах идентификации уже подключены через системы отдела кадров. В этом случае проверка удостоверения может быть интегрирована в существующие этапы рабочих процессов отдела кадров.
Вопросы проектирования
Издатель. Подключение учетных записей часто реализуется для внешней службы проверки удостоверений, которая является издателем проверяемого удостоверения. Примеры проверок для подключения: проверка актуальности, проверка государственных документов, подтверждение адреса или номера телефона и т. д.
Хранение атрибутов проверяемого удостоверения. Если это возможно, не храните атрибуты из проверяемого удостоверения в хранилище определенного приложения. Будьте особенно осторожны с персональными данными. Если для конкретных потоков в приложениях требуются эти сведения, рассмотрите возможность получения утверждений по запросу для VC.
Корреляция атрибутов ПУ с внутренними системами. При определении атрибутов ПУ вместе с издателем создайте механизм сопоставления информации в серверной системе после того, как пользователь предоставляет ПУ. Этот механизм обычно использует ограниченный по сроку действия уникальный идентификатор в контексте проверяющей стороны в сочетании с полученными вами утверждениями. Некоторые примеры:
Новый сотрудник. Когда рабочий процесс отдела кадров доходит до этапа, где требуется проверка личности, проверяющая сторона может создать ссылку с ограниченным по сроку действия уникальным идентификатором. Затем проверяющая сторона отправляет ссылку на адрес электронной почты кандидата в системе отдела кадров. Этот уникальный идентификатор должен быть достаточным для сопоставления такой информации, как имя и фамилия, из запроса на проверку ПУ с данными в кадровых системах или другими базовыми данными. Атрибуты в ПУ можно использовать для подстановки пользовательских атрибутов в кадровой системе или для проверки точности пользовательских атрибутов сотрудника.
Внешние удостоверения — приглашение: когда внешний пользователь приглашен в целевую систему, RP может создать ссылку с уникальным идентификатором, представляющим транзакцию приглашения. Эту ссылку можно отправить на адрес электронной почты внешнего пользователя. Этот уникальный идентификатор должен быть достаточным для сопоставления запроса на проверку ПУ с записью приглашения или базовыми данными и продолжения рабочего процесса подготовки. Атрибуты ПУ можно использовать для проверки или подстановки атрибутов внешних пользователей.
Внешние удостоверения: самообслуживание. Когда внешние удостоверения регистрируются в целевой системе с помощью самообслуживания (например, приложения B2C), атрибуты ПУ можно использовать для подстановки исходных атрибутов учетной записи пользователя. Атрибуты ПУ также можно использовать для определения того, существует ли уже профиль.
Взаимодействие с целевыми системами идентификации. Взаимодействие между службами веб-интерфейса и вашими целевыми системами идентификации должно быть защищено как канал с высоким уровнем привилегий, так как при этом могут создаваться учетные записи. Предоставляйте веб-интерфейсу роли с минимальным возможным набором привилегий. Некоторыми примерами могут служить:
Чтобы создать нового пользователя в идентификаторе Microsoft Entra, веб-сайт RP может использовать субъект-службу, который предоставляет область
User.ReadWrite.AllMS Graph для создания пользователей, и областьUserAuthenticationMethod.ReadWrite.Allдля сброса метода проверки подлинности.Чтобы пригласить пользователей в идентификатор Microsoft Entra с помощью совместной работы B2B, веб-сайт RP может использовать субъект-службу, который предоставляется область
User.Invite.AllMS Graph для создания приглашений.Если проверяющая сторона работает в Azure, используйте управляемые удостоверения для вызова Microsoft Graph. Использование управляемых удостоверений позволит устранить риски, связанные с управлением учетными данными субъекта-службы в файлах кода или конфигурации. Дополнительные сведения об управляемых удостоверениях см. в статье Управляемые удостоверения для ресурсов Azure.
Доступ к приложениям с высокой ценностью в организациях
Проверяемые удостоверения можно использовать в качестве другого средства проверки для доступа к конфиденциальным приложениям внутри организации. Например, ПУ можно также использовать для предоставления сотрудникам доступа к бизнес-приложениям на основе конкретных критериев, например сертификации.
Другие элементы
Веб-интерфейс проверяющей стороны. Это веб-интерфейс приложения, который дополнен вызовами к API службы запросов для представления и проверки проверяемого удостоверения в зависимости от бизнес-требований вашей организации.
Логика авторизации доступа пользователей. Уровень логики в приложении, который разрешает доступ пользователей и расширен для использования атрибутов пользователя в ПУ для принятия решений об авторизации.
Другие серверные службы и зависимости. Представляет остальную часть логики приложения, которая, как правило, не изменяется при проверке удостоверений с использованием ПУ.
Вопросы проектирования
Цель. Цель сценария определяет, какой тип учетных данных и издатель требуется. Распространенные сценарии
Авторизация. В этом сценарии пользователь представляет проверяемое удостоверение, позволяющее принять решение об авторизации. В этом сценарии часто используются ПУ, подтверждающие прохождение обучения или наличие определенной сертификации. Атрибуты ПУ должны содержать подробные сведения, достаточные для принятия решений об авторизации и аудита. Например, VC используется для сертификации личности и может получить доступ к конфиденциальным финансовым приложениям. Логика приложения может проверка утверждение отдела для точной авторизации и использовать идентификатор сотрудника для целей аудита.
Подтверждение проверки личности. В этом сценарии цель состоит в подтверждении того, что тот же человек, который был подключен изначально, действительно пытается получить доступ к приложению с высокой ценностью. Учетные данные издателя проверки удостоверения будут хорошим вариантом. Логика приложения должна проверить, соответствуют ли атрибуты из VC пользователю, вошедшему в приложение.
Проверьте отзыв: при использовании виртуальных машин для доступа к конфиденциальным ресурсам обычно проверка состояние VC с исходным издателем и запретить доступ для отозванных виртуальных машин. При работе с издателями не забудьте явным образом предусмотреть возможность отзыва в проекта своего сценария.
Взаимодействие с пользователем. При использовании проверяемых удостоверений для доступа к конфиденциальным ресурсам следует рассмотреть две схемы.
Поэтапная проверка подлинности. Пользователи начинают сеанс работы с приложением с применением существующих механизмов проверки подлинности. Пользователи должны представлять ПУ для конкретных операций высокой стоимости в приложении, например для утверждения бизнес-процессов. Такая схема часто используется в сценариях, где такие операции с высокой стоимостью легко находить и обновлять в блок-схемах приложений.
Создание сеанса. Пользователи должны предоставлять проверяемое удостоверение в процессе создания сеанса работы с приложением. Представление VC хорошо подходит, когда характер всего приложения является высоким значением.
Доступ к приложениям за пределами границ организации
Проверяемые удостоверения также могут использовать проверяющие стороны, которые предоставляют доступ или определенные возможности по признаку членства или трудоустройства в другой организации. Например, портал электронного магазина может предоставлять такие преимущества, как скидки на сотрудников определенной компании, учащихся определенного учреждения и т. д.
Децентрализованная природа проверяемых удостоверений позволяет реализовать этот сценарий без установления связей федерации.
Другие элементы
Веб-интерфейс проверяющей стороны. Это веб-интерфейс приложения, который дополнен вызовами к API службы запросов для представления и проверки проверяемого удостоверения в зависимости от бизнес-требований вашей организации.
Логика авторизации доступа пользователей. Уровень логики в приложении, который разрешает доступ пользователей и расширен для использования атрибутов пользователя в ПУ для принятия решений об авторизации.
Другие серверные службы и зависимости. Представляет остальную часть логики приложения, которая, как правило, не изменяется при проверке удостоверений с использованием ПУ.
Вопросы проектирования
Цель. Цель сценария определяет, какой тип учетных данных и издатель требуется. Распространенные сценарии
Проверка подлинности. В этом сценарии пользователь должен обладать проверяемым удостоверением для подтверждения своей занятости в определенной организации или отношений с ней. В этом случае необходимо настроить проверяющую сторону для приема проверяемых удостоверений, выданных целевыми организациями.
Авторизация. В зависимости от требований приложения могут на основе атрибутов проверяемых удостоверений принимать точные решения об авторизации и аудите. Например, если веб-сайт электронной коммерции предлагает скидки сотрудникам организаций в определенном расположении, они могут проверить право на скидку на основе утверждения страны или региона в 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: при определении атрибутов VC в сотрудничестве с издателем убедитесь, что вы согласны с утверждениями, определяющими пользователя. Например, если поставщик проверки удостоверений (IDV) проверяет удостоверение перед подключением сотрудников, убедитесь, что выданный VC содержит утверждения, которые можно сопоставить с внутренними системами. Такие утверждения могут быть номером телефона, адресом или датой рождения. RP может запросить информацию, не найденную в VC в рамках этого процесса, например последние четыре цифры их номера социального страхования (SSN).
Роль виртуальных машин с существующими возможностями сброса учетных данных Microsoft Entra: идентификатор Microsoft Entra имеет встроенную функцию самостоятельного сброса пароля (SSPR). Проверяемые учетные данные можно использовать для предоставления другого способа восстановления в тех случаях, когда у пользователей нет доступа к методу SSPR или его потере. В сценариях, когда пользователь потерял компьютер и мобильные устройства, пользователь может повторно перезапустить VC из издателя проверки подлинности и представить его для удаленного восстановления учетной записи.
Аналогичным образом можно использовать VC для создания временного прохода доступа, позволяющего пользователям сбрасывать методы проверки подлинности MFA без пароля.
Авторизация. Создайте механизм авторизации, такой как группа безопасности, который проверяющая сторона проверяет, прежде чем продолжать процедуру восстановления учетных данных. Например, восстановить учетную запись с помощью проверяемого удостоверения могут только пользователи из определенных групп.
Взаимодействие с идентификатором Microsoft Entra: обмен данными между веб-интерфейсом и идентификатором Microsoft Entra должен быть защищен как высоко привилегированная система, так как она может сбросить учетные данные сотрудников. Предоставляйте веб-интерфейсу роли с минимальным возможным набором привилегий. Некоторыми примерами могут служить:
Предоставьте веб-сайту проверяющей стороны возможность использовать субъект-службу, которому предоставлена область прав MS Graph
UserAuthenticationMethod.ReadWrite.Allдля сброса способов проверки подлинности. Не предоставляйте пользователю областьUser.ReadWrite.All, которая позволяет создавать и удалять пользователей.Если проверяющая сторона работает в Azure, используйте управляемые удостоверения для вызова Microsoft Graph. Управляемые удостоверения удаляют риски, связанные с управлением учетными данными субъекта-службы в файлах кода или конфигурации. Дополнительные сведения см. в статье об управляемых удостоверениях для ресурсов Azure.
Планирование управления удостоверениями
Ниже приведены рекомендации по IAM при включении виртуальных машин в проверяющие стороны. Проверяющие стороны обычно являются приложениями.
Проверка подлинности
Субъект проверяемого удостоверения должен быть человеком.
Человек имеет VC в своем кошельке и должен интерактивно представить VC. Неинтерактивные потоки, такие как от имени, не поддерживаются.
Авторизация
Успешное предоставление проверяемого удостоверения может само по себе рассматриваться как шлюз недетализированной авторизации. Атрибуты ПУ можно также использовать для принятия детализированных решений об авторизации.
Определите, имеет ли значение в вашем приложении срок действия ПУ. Если да, проверяйте значение утверждения
exp(время окончания срока действия) удостоверения при проверке авторизации. В одном из примеров, когда срок действия не имеет значения, требуется документ, выданный правительством, например водительское удостоверение, чтобы проверить, старше ли субъект старше 18. Утверждение с датой рождения действительно, даже если срок действия ПУ истек.Определите, имеет ли состояние отзыва удостоверения какое-либо значение при принятии решения об авторизации.
Если это не так, пропустите вызов к API состояния проверка (который включен по умолчанию).
Если это важно, добавьте правильную обработку исключений в приложении.
Профили пользователей
Для создания профиля пользователя можно использовать сведения в предоставленном ПУ. Если вы хотите использовать атрибуты для создания профиля, рассмотрите следующие элементы.
Выдаваемое проверяемое удостоверение содержит моментальный снимок атрибутов на момент выпуска. Виртуальные машины могут иметь длительные сроки действия, и необходимо определить возраст атрибутов, которые будут приниматься как достаточно свежие для использования в качестве части профиля.
Если проверяемое удостоверение должно предоставляться каждый раз, когда субъект запускает сеанс с проверяющей стороной, вы можете создавать непостоянный профиль пользователя на основе атрибутов из ПУ. Профиль пользователя, не сохраняющийся, помогает снизить риски конфиденциальности, связанные с хранением неактивных свойств пользователя. Возможно, приложению потребуется сохранить атрибуты субъекта локально. Если да, сохраните только утверждения, необходимые приложению. Не сохраняйте весь VC.
Если приложению требуется хранить постоянный профиль пользователя:
В качестве неизменяемого идентификатора пользователя рекомендуется использовать утверждение
sub. Это непрозрачный уникальный атрибут, который является константой для заданной пары темы или RP.Определите механизм для отмены подготовки профиля пользователя в приложении. Из-за децентрализованной природы системы Проверенные учетные данные Microsoft Entra жизненный цикл подготовки пользователей приложений отсутствует.
Не сохраняйте утверждения персональных данных, возвращаемые в токене VC.
Сохраняйте только утверждения, необходимые для логики проверяющей стороны.
Планирование производительности
Как и в случае с любым другим решением, вам необходимо спланировать производительность. К важным моментам относятся задержка, пропускная способность и масштабируемость. На начальных этапах цикла выпуска удостоверений производительность не должна быть проблемой. Тем не менее, если внедрение решения приводит к проверке большого количества проверяемых удостоверений, планирование производительности может стать очень важным.
Следующие элементы предоставляют области, которые следует учитывать при планировании производительности:
Служба выдачи Проверенных учетных данных Microsoft Entra развернута в регионах Azure "Западная Европа", "Северная Европа", "Западная часть США 2" и "Центрально-западная часть США". Чтобы ограничить задержку, разверните интерфейс проверки (веб-сайт) и хранилище ключей в ближайшем регионе.
Модель, основанная на пропускной способности
На функции проверки ПУ распространяются ограничения для служб Azure Key Vault.
Для каждой проверки ПУ требуется одна операция подписывания Key Vault.
Управлять регулированием нельзя. Однако рекомендуется ознакомиться с руководством по регулированию Azure Key Vault, чтобы понять, как этот аспект может повлиять на производительность.
Планирование для надежности
Чтобы лучше планировать высокий уровень доступности и аварийное восстановление, мы предлагаем следующие элементы:
служба Проверенные учетные данные Microsoft Entra развернута в регионах Западной Европы, Северной Европы, Западной части США 2 и Западной части США, Австралии и Японии Azure. Вы можете развернуть вспомогательные веб-серверы и приложения в одном из этих регионов, в частности в тех, из которых, как предполагается, будет исходить большая часть трафика проверки.
При установке целей по доступности и избыточности изучите и используйте рекомендации из статьи об обеспечении доступности и избыточности Azure Key Vault.
Планирование безопасности
При проектировании безопасности рассмотрите следующее:
Все проверяющие стороны в одном арендаторе имеют одинаковую границу доверия, так как совместно используют один DID.
Назначьте отдельного субъекта-службу для веб-сайта, обращающегося к Key Vault.
Разрешения на использование Key Vault для подписывания сообщений с помощью закрытого ключа должны иметь только служба Проверенных учетных данных Microsoft Entra и субъекты-службы веб-сайта.
Не назначайте удостоверениям пользователей-людей никаких административных разрешений для доступа к Key Vault. Дополнительные рекомендации по использованию Azure Key Vault см. в статье Базовая конфигурация системы безопасности Azure для Key Vault.
Ознакомьтесь с рекомендациями по защите сред Azure с помощью идентификатора Microsoft Entra, чтобы управлять вспомогательными службами для вашего решения.
Снизить риски спуфинга вам помогут следующие инструменты:
Проверка DNS, позволяющая клиентам определить фирменную символику издателя.
Доменные имена, звучащие осмысленно для пользователей.
Снижение рисков распределенных атак типа "Отказ в обслуживании" (DDOS) и регулирования Key Vault. Каждый запрос на предоставление ПУ создает операцию подписывания Key Vault, которая учитывается относительно ограничений службы. Для защиты трафика рекомендуем использовать альтернативную функцию проверки подлинности или CAPTCHA перед созданием запросов на выпуск.
Планирование операций
При планировании операций рекомендуется предусмотреть регистрацию каждой попытки проверки удостоверения для целей аудита. Используйте эти сведения для аудита и устранения неполадок. Кроме того, вы можете создавать уникальные идентификаторы транзакций, на которые при необходимости могут ссылаться клиенты и специалисты службы поддержки.
В рамках планирования операций вы можете вести мониторинг следующих аспектов:
Масштабируемость
Отслеживайте непройденные проверки ПУ в качестве комплексных метрик безопасности приложений.
Отслеживайте сквозную задержку проверки удостоверений.
Надежность и зависимости
Отслеживайте базовые зависимости, используемых решением для проверки.
Следуйте правилам мониторинга и оповещения для Azure Key Vault.
Безопасность
Включите ведение журнала Key Vault для отслеживания операций подписывания и для мониторинга и отправки оповещений об изменениях конфигурации. Дополнительные сведения можно найти в статье о включении функции ведения журналов Key Vault.
Функция архивирования записывает в журнал информацию из систем обеспечения безопасности и управления событиями (SIEM), например из Microsoft Sentinel, для долгосрочного хранения.
Следующие шаги
Дополнительные сведения о проектировании решений ПУ
Реализация проверяемых удостоверений