Получение авторизации для доступа к ресурсам
В этой статье вы узнаете, как лучше всего обеспечить нулевое доверие при получении разрешений доступа к ресурсам для приложения. Чтобы получить доступ к защищенным ресурсам, таким как данные электронной почты или календаря, приложению требуется авторизация владельца ресурса. Владелец ресурса может предоставить согласие или отклонить запрос вашего приложения. Приложение получает маркер доступа, когда владелец ресурса предоставляет согласие; приложение не получает маркер доступа, когда владелец ресурса запрещает доступ.
Концептуальный обзор
Вы можете использовать платформа удостоверений Майкрософт для проверки подлинности и авторизации приложений и управления разрешениями и согласия. Начнем с некоторых понятий:
Проверка подлинности (иногда сокращена до AuthN) — это процесс подтверждения точности утверждения удостоверения. Для обработки операций проверки подлинности в платформе удостоверений Майкрософт применяется протокол OpenID Connect. Авторизация (иногда сокращена до AuthZ) предоставляет удостоверенному участнику разрешение на выполнение чего-либо. Он указывает, к каким данным может получить доступ участник, прошедший проверку подлинности. Платформа удостоверений Майкрософт использует протокол OAuth2.0 для обработки авторизации. Параметры авторизации включают списки управления доступом (ACL), управление доступом на основе ролей и управление доступом атрибутов (ABAC). Проверка подлинности часто является фактором авторизации.
Делегированный доступ (действующий от имени пользователя, вошедшего в систему) или прямой доступ (действующий только в качестве собственного удостоверения приложения) позволяет приложению получать доступ к данным. Делегированный доступ требует делегированных разрешений (также известных как область); клиент и пользователь должны быть отдельно авторизованы для выполнения запроса. Для прямого доступа могут потребоваться разрешения приложения (также известные как роли приложений); если роли приложений предоставляются приложениям, они могут вызываться разрешениями приложений.
Делегированные разрешения, используемые с делегированным доступом, позволяют приложению действовать от имени пользователя, доступ к доступу только к тому, к чему может получить доступ пользователь. Разрешение приложения, используемое с прямым доступом, позволяет приложению получать доступ к любым данным, с которым связано разрешение. Только администраторы и владельцы субъектов-служб могут согласиться на разрешения приложения.
Согласие — это способ получения приложений разрешений. Пользователи или администраторы разрешают приложению доступ к защищенному ресурсу. В запросе на согласие перечислены разрешения, необходимые приложению, а также сведения о издателе.
Предварительная проверка подлинности — это способ предоставления владельцам приложений ресурсов доступа к клиентским приложениям. Они могут сделать это в портал Azure или с помощью PowerShell и API, таких как Microsoft Graph. Они могут предоставлять разрешения на ресурсы, не требуя, чтобы пользователи могли просматривать запрос согласия на набор предварительно несанкционированных разрешений.
Разница между делегированным и разрешением приложения
Приложения работают в двух режимах: когда пользователь присутствует (делегированное разрешение) и когда нет пользователя (разрешение приложения). Когда перед приложением есть пользователь, вы вынуждены действовать от имени этого пользователя; Вы не должны действовать от имени самого приложения. Когда пользователь направляет приложение, вы выступаете в качестве делегата для этого пользователя. Вы получаете разрешение на действия от имени пользователя, идентифицирующее маркер.
Приложения типа службы (фоновые задачи, daemons, серверные процессы) не имеют пользователей, которые могут идентифицировать себя или ввести пароль. Им требуется разрешение приложения на действия от самого себя (от имени приложения-службы).
Рекомендации по авторизации приложений нулевого доверия
Подход авторизации имеет проверку подлинности в качестве компонента при подключении к пользователю, представляющего приложение, и к вызываемму ресурсу. Когда приложение действует от имени пользователя, мы не доверяем вызывающему приложению, чтобы сообщить нам, кто является пользователем или позволить приложению решить, кто является пользователем. Идентификатор Microsoft Entra проверяет и напрямую предоставляет сведения о пользователе в маркере.
Если необходимо разрешить приложению вызывать API или авторизовать приложение для доступа к ресурсу, современные схемы авторизации могут требовать авторизации через платформу разрешений и согласия. Рекомендации по безопасности ссылок на свойства приложения, включающие URI перенаправления, маркеры доступа (используемые для неявных потоков), сертификаты и секреты, URI идентификатора приложения и владение приложениями.
Следующие шаги
- Настройка маркеров описывает сведения, которые можно получить в токенах Microsoft Entra. В нем объясняется, как настроить маркеры для повышения гибкости и контроля при увеличении безопасности нулевого доверия приложений с минимальными привилегиями.
- Настройка утверждений групп и ролей приложений в маркерах показывает, как настроить приложения с определениями ролей приложения и назначить группы безопасности ролям приложений. Эти методы помогают повысить гибкость и контроль при увеличении безопасности нулевого доверия приложений с минимальными привилегиями.
- Разработка стратегии делегированных разрешений помогает реализовать оптимальный подход к управлению разрешениями в приложении и разработке с помощью принципов нулевого доверия.
- Разработка стратегии разрешений приложений помогает решить вопрос о подходе приложений к управлению учетными данными.
- Предоставьте учетные данные удостоверения приложения, если пользователь не объясняет, почему управляемые удостоверения для ресурсов Azure являются лучшей практикой учетных данных клиента для служб (неиспользуемых приложений) в Azure.
- Рекомендации по авторизации помогут реализовать лучшие модели авторизации, разрешения и согласия для приложений.
- Используйте рекомендации по разработке удостоверений и управления доступом в жизненном цикле разработки приложений для создания безопасных приложений.
- Создание приложений с использованием подхода "Нулевое доверие к идентификации" продолжается с руководства по разработке удостоверений и управления доступом, чтобы помочь вам использовать подход "Нулевое доверие" к идентификации в жизненном цикле разработки программного обеспечения (SDLC).