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

Основы авторизации

  • Статья

Авторизация (иногда называется AuthZ) используется для того, чтобы задать разрешения, используемые для оценки наличия доступа к ресурсам или функциональным возможностям. В отличие от нее, аутентификация (иногда называется AuthN) предназначена для того, чтобы доказать, что сущность (например, пользователь или служба) является тем, за кого себя выдает.

Авторизация может включать указание на то, к каким функциям, ресурсам или данным разрешен доступ. Авторизация также указывает, что можно сделать с данными. Это действие авторизации часто называется управлением доступом.

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

Подходы к авторизации

Существует несколько распространенных подходов к обработке авторизации. Управление доступом на основе ролей в настоящее время является наиболее распространенным способом использования платформы удостоверений Майкрософт.

Аутентификация в роли авторизации

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

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

Авторизация с помощью списков управления доступом (ACL) включает в себя поддержание явных списков конкретных сущностей, у которых есть доступ или нет доступа к ресурсу или функциональным возможностям. Списки управления доступом обеспечивают более точное управление аутентификацией в роли авторизации, но усложняют управление по мере увеличения числа сущностей.

Управление доступом на основе ролей

Управление доступом на основе ролей (RBAC), возможно, является наиболее распространенным подходом к принудительной авторизации в приложениях. При использовании RBAC определяются роли, чтобы описать типы действий, которые может выполнять сущность. Разработчик приложения предоставляет доступ ролям, а не отдельным сущностям. Затем администратор может назначить роли разным сущностям, чтобы контролировать, у каких из них есть доступ к ресурсам и функциональным возможностям.

В расширенных реализациях RBAC роли могут сопоставляться с коллекциями разрешений, где разрешение описывает детализированное действие или действие, которое можно выполнить. Затем роли настраиваются в качестве сочетаний разрешений. Вычислить общий набор разрешений для сущности путем объединения разрешений, предоставленных различным ролям, которым назначена сущность. Хорошим примером такого подхода является реализация RBAC, которая управляет доступом к ресурсам в подписках Azure.

Примечание.

Приложение RBAC отличается от Azure RBAC и Microsoft Entra RBAC. Пользовательские роли и встроенные роли Azure являются частью Azure RBAC, что помогает управлять ресурсами Azure. Microsoft Entra RBAC позволяет управлять ресурсами Microsoft Entra.

Управление доступом на основе атрибутов

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

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

Одним из способов достижения ABAC с помощью идентификатора Microsoft Entra является использование динамических групп членства. Динамические группы позволяют администраторам динамически назначать пользователей группам на основе определенных атрибутов пользователей с нужными значениями. Например, можно создать группу авторов, в которой все пользователи с должностью "Автор" динамически назначаются группе "Авторы". Динамические группы можно использовать в сочетании с RBAC для авторизации, при которой роли сопоставлены с группами, а пользователи динамически назначаются в группы.

Azure ABAC — это пример решения ABAC, доступного в настоящее время. Azure ABAC основывается на Azure RBAC путем добавления условий назначения ролей на основе атрибутов в контексте определенных действий.

Реализация авторизации

Логика авторизации часто реализуется в приложениях или решениях, где требуется управление доступом. Во многих случаях платформы разработки приложений предлагают ПО промежуточного слоя или другие решения API, которые упрощают реализацию авторизации. Среди примеров можно назвать использование AuthorizeAttribute в ASP.NET и Route Guards в Angular.

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

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

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