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

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

Концептуальный обзор

Платформу удостоверений Майкрософт можно использовать для проверки подлинности и авторизации приложений и управления разрешениями и согласием. Начнем с некоторых понятий:

• Проверка подлинности (иногда сокращается до AuthN) — это процесс подтверждения вашей заявленной личности. Платформа удостоверений Майкрософт использует протокол OpenID Connect для обработки проверки подлинности. Авторизация (иногда сокращена до AuthZ) предоставляет удостоверенному участнику разрешение на выполнение чего-либо. Он указывает, к каким данным может получить доступ участник, прошедший проверку подлинности. Платформа удостоверений Майкрософт использует протокол OAuth2.0 для обработки авторизации. Параметры авторизации включают списки управления доступом (ACL), управление доступом на основе ролей и управление доступом атрибутов (ABAC). Проверка подлинности часто является фактором авторизации.

• Делегированный доступ (действующий от имени пользователя, вошедшего в систему) или прямой доступ (действующий только в качестве собственного удостоверения приложения) позволяет приложению получать доступ к данным. Для делегированного доступа требуются делегированные разрешения (также известные как области). Клиент и пользователь должны быть отдельно авторизованы для выполнения запроса. Для прямого доступа могут потребоваться разрешения приложения (также известные как роли приложения). Когда приложения получают роли приложений, это может называться разрешениями приложений.

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

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

• Предварительная проверка подлинности — это способ предоставления владельцам приложений ресурсов доступа к клиентским приложениям. Они могут сделать это на портале Azure или с помощью PowerShell и API, таких как Microsoft Graph. Они могут предоставлять разрешения на ресурсы, не требуя, чтобы пользователи могли просматривать запрос согласия на набор предварительно несанкционированных разрешений.

Разница между делегированным и разрешением приложения

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

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

Рекомендации по авторизации приложений нулевого доверия

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

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

Дальнейшие шаги

• Настройка токенов описывает информацию, которую можно получить в Microsoft Entra токенах. В нем объясняется, как настроить маркеры для повышения гибкости и контроля при увеличении безопасности приложений Zero Trust с минимальными привилегиями.
• Настройка утверждений о принадлежности к группам и ролей приложений в токенах объясняет, как настроить ваши приложения с использованием определений ролей и назначить группы безопасности ролям приложений. Эти методы помогают повысить гибкость и контроль при увеличении безопасности приложений Zero Trust с минимальными привилегиями.
• Разработка стратегии делегированных разрешений помогает реализовать оптимальный подход к управлению разрешениями в приложении и разработке с использованием принципов нулевого доверия.
• Стратегия разрешений приложений помогает вам определиться с подходом к управлению учетными данными ваших приложений.
• Предоставьте учетные данные удостоверения приложения, если пользователь отсутствует объясняет, почему управляемые удостоверения Azure для ресурсов являются лучшей практикой для предоставления учетных данных клиентам для служб (непользовательских приложений) в Azure.
• Рекомендации по авторизации помогут реализовать лучшие модели авторизации, разрешения и согласия для приложений.
• Используйте лучшие практики разработки удостоверений и управления доступом в модели Zero Trust в жизненном цикле разработки приложений для создания безопасных приложений.
• Создание приложений с использованием подхода "Нулевое доверие" к управлению удостоверениями продолжается в статье управление удостоверениями и доступом в рамках "Нулевого доверия": лучшие практики разработки, чтобы помочь вам использовать подход "Нулевое доверие" к управлению удостоверениями в жизненном цикле разработки программного обеспечения (SDLC).