Устойчивость с помощью рекомендаций разработчика

Статья
10/15/2024

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

Библиотека проверки подлинности Майкрософт

Библиотека проверки подлинности Майкрософт (MSAL) и библиотека веб-проверки подлинности майкрософт для ASP.NET упростить получение, управление, кэширование и обновление маркеров для приложений. Эти библиотеки оптимизированы для поддержки удостоверений Майкрософт, включая функции, которые повышают устойчивость приложений.

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

Оптимизация операций чтения и записи каталога

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

Оптимизация операций чтения и записи в каталоге

Избегайте записи функций в каталог при входе. Избегайте выполнения записи при входе без предварительных условий (если) в пользовательских политиках. Один из вариантов использования, требующих записи при входе, — это JIT-миграция паролей пользователей. Не требуется запись для каждого входа. Предварительные условия в пути пользователя:
```
<Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>
```
Общие сведения о регулировании. Каталог реализует правила регулирования уровня приложения и клиента. Существуют дополнительные ограничения скорости для операций чтения,GET, Write/POST, Update/PUT и Delete. Каждая операция имеет разные ограничения.
- Запись во время входа попадает под post для новых пользователей или PUT для текущих пользователей.
- Пользовательская политика, которая создает или обновляет пользователя на каждом входе, может попасть на уровень приложения PUT или POST. Те же ограничения применяются при обновлении объектов каталога с помощью идентификатора Microsoft Entra или Microsoft Graph. Аналогичным образом изучите операции чтения, чтобы обеспечить минимальное количество операций чтения для каждого входа.
- Оцените пиковую нагрузку для прогнозирования скорости записи каталогов и избегайте регулирования. Оценки пикового трафика должны включать оценки действий, таких как регистрация, вход и многофакторная проверка подлинности (MFA). Проверьте систему Azure AD B2C и приложение для пикового трафика. Azure AD B2C может обрабатывать нагрузку без регулирования, когда подчиненные приложения или службы не будут.
- Изучите и запланируйте временную шкалу миграции. При планировании миграции пользователей в Azure AD B2C с помощью Microsoft Graph рассмотрите ограничения приложения и клиента, чтобы вычислить время завершения миграции пользователей. Если вы разделяете задание или сценарий создания пользователя с помощью двух приложений, можно использовать ограничение на каждое приложение. Убедитесь, что он остается ниже порогового значения для каждого клиента.
- Узнайте о влиянии задания миграции на другие приложения. Рассмотрим динамический трафик, обслуживаемый другими проверяющими приложениями, чтобы обеспечить отсутствие регулирования на уровне клиента и нехватку ресурсов для вашего динамического приложения. Дополнительные сведения см. в руководстве по регулированию Microsoft Graph.
- Используйте пример нагрузочного теста для имитации регистрации и входа.
- Дополнительные сведения об ограничениях и ограничениях службы Azure AD B2C.

Время существования токена

Если служба проверки подлинности Azure AD B2C не может завершить новые регистрации и входы, укажите способы устранения рисков для пользователей, которые вошли в систему. При настройке пользователи, вошедшего в систему, могут использовать приложение без нарушений, пока они не выходят из приложения или время ожидания сеанса от неактивности.

Бизнес-требования и взаимодействие с конечным пользователем определяют частоту обновления маркеров для веб-приложений и одностраничных приложений (SPAs).

Расширение времени существования маркера

Веб-приложения: для веб-приложений, где маркер проверки подлинности проверяется при входе, приложение зависит от файла cookie сеанса, чтобы продолжить продление срока действия сеанса. Разрешить пользователям оставаться в системе, реализуя время последовательного сеанса, которое обновляется на основе действий пользователей. Если существует долгосрочный сбой выдачи маркеров, эти периоды сеанса можно увеличить как одноразовую конфигурацию приложения. Оставьте время существования сеанса максимально допустимым.
SPAs: SPA может зависеть от маркеров доступа для выполнения вызовов к API. Для spAs рекомендуется использовать поток кода авторизации с потоком проверки подлинности для обмена кодом (PKCE), чтобы разрешить пользователю продолжать использовать приложение. Если ваш SPA использует неявный поток, рассмотрите возможность миграции в поток кода авторизации с помощью PKCE. Перенос приложения из MSAL.js 1.x в MSAL.js 2.x для реализации устойчивости веб-приложений. Неявный поток не приводит к маркеру обновления. Spa может использовать скрытый iframe для выполнения новых запросов маркеров к конечной точке авторизации, если браузер имеет активный сеанс с Azure AD B2C. Для spAs существует несколько вариантов, позволяющих пользователю продолжать использовать приложение.
- Продлить срок действия маркера доступа.
- Создайте приложение для использования шлюза API в качестве прокси-сервера проверки подлинности. В этой конфигурации SPA загружается без проверки подлинности и вызовы API выполняются в шлюз API. Шлюз API отправляет пользователя через процесс входа с помощью предоставления кода авторизации на основе политики и проверяет подлинность пользователя. Сеанс проверки подлинности между шлюзом API и клиентом поддерживается с помощью файла cookie проверки подлинности. Шлюз API обслуживает API с помощью маркера, полученного шлюзом API, или другого прямого метода проверки подлинности, например сертификатов, учетных данных клиента или ключей API.
- Переключитесь на рекомендуемый параметр. Перенос SPA из неявного предоставления в поток предоставления кода авторизации с поддержкой проверки подлинности для Обмена кодом (PKCE) и поддержкой общего доступа к ресурсам между источниками (CORS).
- Для мобильных приложений расширьте время существования маркера обновления и доступа.
Внутренние или микрослужбы приложений: внутренние приложения (управляющая программа) являются неинтерактивными и не находятся в пользовательском контексте, поэтому перспектива кражи маркеров уменьшается. Наша рекомендация заключается в том, чтобы обеспечить баланс между безопасностью и временем существования и задать продолжительное время существования маркера.

Единый вход

С помощью единого входа пользователи войдите один раз с учетной записью и получите доступ к приложениям: веб-, мобильное или одностраничное приложение (SPA), независимо от платформы или доменного имени. Когда пользователь входит в приложение, Azure AD B2C сохраняет сеанс на основе файлов cookie.

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

Настройка единого входа

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

Защита от ботов

Защита приложений от известных уязвимостей, таких как атаки распределенного типа "отказ в обслуживании" (DDoS), внедрение SQL, межсайтовые скрипты, удаленное выполнение кода и другие, описанные в OWASP Top-10. Разверните Брандмауэр веб-приложений (WAF) для защиты от распространенных эксплойтов и уязвимостей.

Используйте Azure WAF, который обеспечивает централизованную защиту от атак.
Используйте WAF с защитой идентификаторов Microsoft Entra и условным доступом, чтобы обеспечить многоуровневую защиту при использовании Azure AD B2C.
Создайте устойчивость к регистрации на основе бота путем интеграции с системой CAPTCHA.

Секреты

Azure AD B2C использует секреты для приложений, API, политик и шифрования. Секреты обеспечивают безопасную проверку подлинности, внешние взаимодействия и хранилище. Национальный институт стандартов и технологий (NIST) относится к временному интервалу авторизации ключа, используемому законными сущностями, в качестве криптопериоды. Выберите необходимую длину криптопериодов. Задайте срок действия и смените секреты до истечения срока их действия.

Реализация смены секретов

Используйте управляемые удостоверения для поддерживаемых ресурсов для проверки подлинности в любой службе, поддерживающей проверку подлинности Microsoft Entra. При использовании управляемых удостоверений ресурсы можно управлять автоматически, включая смену учетных данных.
Выполните инвентаризацию ключей и сертификатов, настроенных в Azure AD B2C. Этот список может включать ключи, используемые в пользовательских политиках, API, маркере идентификатора подписи и сертификатах для языка разметки утверждений безопасности (SAML).
Используя CICD, смените секреты, срок действия которого истекает в течение двух месяцев от ожидаемого пикового сезона. Рекомендуемый максимальный криптопериод закрытых ключей, связанных с сертификатом, составляет один год.
Отслеживайте и смените учетные данные доступа к API, например пароли и сертификаты.

Тестирование REST API

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

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

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

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