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

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

  • Статья

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

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

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

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

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

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

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

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

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

  • Приложения 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. Сделайте код устойчивым для обработки поворотов секретов при возникновении компромисса. ИТ-администраторы могут удалять и менять секреты и сертификаты, не затрагивая приложение или влияя на законных пользователей.

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

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

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