Share via

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

  • Статья

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

Изображение, на котором показаны составляющие деятельности разработчика

Использование библиотеки проверки подлинности Майкрософт (MSAL)

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

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

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

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

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

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

    <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>

  • Общие сведения о регулировании количества запросов: в каталоге реализованы правила ограничения количества запросов — как на уровне приложения, так и на уровне клиента. Также предусмотрены дополнительные ограничения количества запросов для операций Read/GET, Write/POST, Update/PUT и Delete/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 будет неспособна выполнять новые регистрации и входы в систему, можно смягчить последствия для тех пользователей, которые уже выполнили вход. Посредством конфигурации можно разрешить тем пользователям, которые уже выполнили вход, продолжать использовать приложение без каких-либо заметных нарушений работы, пока такой пользователь не выйдет из приложения или пока не произойдет истечение времени ожидания сеанса вследствие неактивности.

Частота обновления маркеров проверки подлинности как для веб-приложений, так и для одностраничных приложений (SPA) будет определяться вашими бизнес-требованиями и требованиями к процессу взаимодействия с конечным пользователем.

Как продлить время существования маркеров проверки подлинности

  • Веб-приложения: для веб-приложений, в которых маркер проверки подлинности проверяется в начале входа, приложение полагается на файлы cookie сеансов для продления действительности сеансов. Разрешите пользователям оставаться вошедшими в систему, реализовав скользящую продолжительность сеансов, при которой сеансы продолжают возобновляться при условии активности пользователя. Если существует долгосрочный сбой выдачи маркеров, эти периоды сеанса можно увеличить как одноразовую конфигурацию приложения. Устанавливайте максимальное допустимое время существования сеансов.
  • SPA: одностраничное приложение (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 с неявного предоставления кода на поток предоставлениякода авторизации с поддержкой проверки подлинности для Exchange (PKCE) и поддержкой общего доступа к ресурсам между источниками (CORS).
    • Для мобильных приложений рекомендуется продлить и промежуток между обновлениями, и время существования маркера доступа.
  • Серверные приложения или приложения микрослужб: поскольку серверные приложения (управляющие программы) не являются интерактивными и не выполняются в пользовательском контексте, вероятность кражи маркера значительно снижается. Рекомендуется выбрать баланс между безопасностью и временем существования, задав для маркера безопасности длительное время существования.

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

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

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

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

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

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

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

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

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

Смена секретов

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

Как реализовать смену секретов

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

Проверка интерфейсов REST API

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

Тестирование API-интерфейсов

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

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