Разработка стратегии разрешений приложения

  • Статья

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

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

  • Приложение подтверждает, что это приложение, запрашивающее разрешение. Приложение докажет свое удостоверение с помощью одного из следующих методов:

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

  • Приложению всегда требуется предварительное согласие администратора. Приложение запрашивает это разрешение с .default помощью область. Он запрашивает разрешения, назначенные администратору приложению. Независимо от именования для любого конкретного область, эти разрешения применяются ко всем пользователям по умолчанию.

  • Функции транс-пользователей. По умолчанию приложение позволяет приложению User.ReadWrite.All обновлять профиль каждого пользователя даже Calendar.Read. В качестве разрешения приложения приложение позволяет приложению читать календарь каждого пользователя в клиенте.

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

Ограничение разрешений приложения

Существует три способа ограничения приложения меньше глобального доступа.

  • Приложения Microsoft Teams имеют согласие на использование определенных ресурсов (RSC), которое позволяет приложению получать доступ к определенной команде, а не получать доступ ко всем командам в организации. RSC — это интеграция API Microsoft Teams и Microsoft Graph, которая позволяет приложению использовать конечные точки API и управлять определенными ресурсами. Ее модель разрешений позволяет владельцам Teams и чата предоставлять согласие для вашего приложения на доступ к данным Teams и чата и изменять их.

  • Администраторы Microsoft Exchange могут создавать политики приложений Exchange, чтобы ограничить доступ приложений к определенным почтовым ящикам с помощью скрипта PowerShell. Они могут ограничить конкретное приложение определенными почтовыми ящиками Calendar.Read или Mail.Read получить доступ. Это позволяет, например, создавать автоматизацию, которая может читать только один почтовый ящик или отправлять только почту из одного почтового ящика, а не от всех пользователей в организации.

  • SharePoint имеет Sites.Selected в качестве определенного область, чтобы разрешить детализированные разрешения для доступа к SharePoint с приложением. Выбор Sites.Selected приложения вместо одного из других разрешений по умолчанию приведет к тому, что приложение не имеет доступа к семействам веб-сайтов SharePoint. Администратор использует конечную точку разрешений сайта для предоставления разрешений на чтение, запись или запись в приложение.

Управление учетными данными приложений

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

  • Удалите все секреты из кода и конфигурации. При использовании платформы Azure поместите секреты в хранилище ключей и получите доступ к ним с помощью управляемых удостоверений для ресурсов Azure. Сделайте код устойчивым для обработки поворотов секретов при возникновении компромисса. ИТ-администраторы могут удалять и менять секреты и сертификаты, не затрагивая приложение или влияя на законных пользователей.

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

  • Регулярно переключение сертификатов и секретов для создания устойчивости в приложении и избегает сбоя из-за аварийного отката.

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