Рекомендации по лучшим практикам разработки управления идентификацией и доступом в архитектуре нулевого доверия

Эта статья поможет вам, как разработчику, понять рекомендации по управлению удостоверениями и доступом для жизненного цикла разработки приложений. Вы начинаете разрабатывать безопасные приложения, соответствующие нулю доверия , с помощью управления удостоверениями и доступом (IAM).

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

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

  • Реализуйте политики гигиены учетных данных и смены для приложений и служб. Если злоумышленники компрометируют такие секреты, как сертификаты или пароли, они могут достичь глубины системного доступа для получения токенов под видом идентичности приложения. Затем они получают доступ к конфиденциальным данным, перемещаются латерально и устанавливают устойчивость.
  • Развертывание строгой проверки подлинности. ИТ-администраторы настраивают политики, требующие многофакторной проверки подлинности и устройств FIDO2 без пароля.
  • Ограничьте согласие пользователей на приложения с разрешениями с низким риском от проверенных издателей. Доступ к данным в API-интерфейсах, таких как Microsoft Graph, позволяет создавать расширенные приложения. Организации и клиенты оценивают запросы на разрешения и надежность приложения перед предоставлением согласия. ИТ-администраторы принимают принцип явной проверки, требуя проверки издателя. Они применяют принцип наименьшей привилегии, разрешая согласие пользователя только для разрешений с низким риском.
  • Блокировать устаревшие протоколы и API. ИТ-администраторы блокируют старые протоколы проверки подлинности, такие как "Обычная проверка подлинности" и требуют современных протоколов, таких как OpenID Connect и OAuth2.

Использование доверенных библиотек проверки подлинности на основе стандартов

Чтобы повысить переносимость и безопасность приложений, разработайте приложение с помощью известных и принятых стандартов и библиотек. Доверенные библиотеки проверки подлинности на основе стандартов остаются up-to-date, чтобы ваши приложения реагировали на новейшие технологии и угрозы. Методологии разработки на основе стандартов предоставляют общие сведения о поддерживаемых стандартах и их преимуществах.

Вместо использования протоколов с известными уязвимостями и обширной документацией для разработки приложения с помощью таких библиотек, как библиотека проверки подлинности Майкрософт (MSAL), библиотека веб-проверки подлинности Microsoft Identity Web и комплекты средств разработчиков программного обеспечения Azure (SDK). Пакеты программных средств разработки MSAL и SDK позволяют использовать эти функции без необходимости писать дополнительный код:

  • Условный доступ
  • Регистрация устройств и управление ими
  • Аутентификация без паролей и FIDO2

MSAL и Microsoft Graph — это лучший выбор для разработки приложений Microsoft Entra. Разработчики MSAL обеспечивают соответствие протоколам. Корпорация Майкрософт оптимизирует MSAL для повышения эффективности при работе непосредственно с идентификатором Microsoft Entra.

Регистрация приложений в идентификаторе Microsoft Entra

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

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

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

Разработайте своё приложение для использования токенов для явной проверки подлинности и контроля доступа, которые определяются и управляются вашими клиентами. Корпорация Майкрософт не рекомендует разрабатывать собственные системы управления именами пользователей и паролями.

Держите учетные данные вне кода, чтобы ИТ-администраторы могли менять их без остановки или повторного развертывания вашего приложения. Используйте такие службы, как Azure Key Vault или Azure Managed Identities, чтобы делегировать IAM.

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

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

Всегда предоставляйте минимальные привилегии, необходимые для выполнения определенных задач. Например, используйте детализированные области в Microsoft Graph.

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

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

Безопасное управление токенами

Когда приложение запрашивает маркеры из идентификатора Microsoft Entra, безопасно управляйте ими:

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

Поддержка непрерывной оценки доступа (CAE)

Непрерывная оценка доступа (CAE) позволяет Microsoft Graph быстро запретить доступ в ответ на события безопасности. Примеры включают следующие действия администратора клиента:

  • Удаление или отключение учетной записи пользователя.
  • Включите многофакторную проверку подлинности (MFA) для пользователя.
  • Явно аннулировать выданные пользователю токены.
  • Обнаружение пользователя, перемещающегося в состояние высокого риска.

При поддержке КЭЭ токены, которые выдаёт идентификатор Microsoft Entra для вызова Microsoft Graph, действуют в течение 24 часов вместо стандартных 60–90 минут. CAE добавляет устойчивость вашему приложению, позволяя MSAL заранее обновлять токен до его истечения.

Определение ролей приложений для ИТ-специалистов для назначения пользователям и группам

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

Получение статуса проверенного издателя

В качестве проверенного издателя подтвердите свою личность с помощью учетной записи Microsoft Partner Network и выполните установленный процесс проверки. Для разработчиков мультитенантных приложений наличие статуса подтверждённого издателя помогает укреплять доверие IT-администраторов среди арендаторов клиентов.

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

  • Last updated on