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

Статья
06/27/2024

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

Схема компонентов интерфейса разработчика

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

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

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

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

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

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

Избегайте записи функций в каталог при входе. Избегайте выполнения записи при входе без предварительных условий (если) в пользовательских политиках. Один вариант использования, для которого требуется запись при входе — это оперативная миграция паролей пользователей. Не требуется запись для каждого входа. Предварительные условия в пути пользователя:
```
<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 Active Directory 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 и выдает маркер доступа, не запрашивая вход пользователя. Если единый вход настроен с ограниченной областью в политике или приложении, более поздний доступ к другим политикам и приложениям требует новой проверки подлинности.

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

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

Методики безопасного развертывания

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

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

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

Используйте WAF Azure, который обеспечивает централизованную защиту от атак.
Используйте 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) в среде разработчика, а не в рабочей среде.

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