авторизация

Авторизация — это процесс определения того, какие действия разрешено выполнять конкретному пользователю, программе, устройству или другому субъекту в информационной системе. Если простыми словами, авторизация отвечает на вопрос: «Что вам разрешено делать?»

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

NIST определяет authorization как предоставленные субъекту права доступа либо сам процесс предоставления таких прав. В контексте access control авторизация также связана с решением разрешить или запретить субъекту доступ к определенному объекту системы.

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

Термины «идентификация», «аутентификация» и «авторизация» часто встречаются вместе, однако обозначают разные этапы работы системы.

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

Аутентификация проверяет, действительно ли пользователь контролирует эту учетную запись. Для этого могут применяться пароль, одноразовый код, аппаратный ключ, сертификат или другой аутентификатор. NIST описывает аутентификацию как проверку личности пользователя, процесса или устройства.

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

Упрощенная последовательность выглядит так:

1. Идентификация — «Кто вы?»
2. Аутентификация — «Можете ли вы доказать, что это действительно вы?»
3. Авторизация — «Что вам разрешено делать?»

Пример авторизации на сайте

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

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

После входа сервер определяет роль или набор разрешений пользователя. Когда пользователь открывает определенный раздел или отправляет запрос к API, система проверяет, соответствует ли запрошенная операция его правам.

Если разрешение есть, операция выполняется. Если разрешение отсутствует, сервер может вернуть ошибку доступа, например HTTP 403 Forbidden.

Что именно проверяет система при авторизации

Решение об авторизации может основываться не только на имени пользователя. Современные системы способны учитывать множество параметров.

• идентификатор пользователя;
• роль пользователя;
• группу или подразделение;
• конкретный ресурс;
• тип выполняемой операции;
• атрибуты пользователя;
• время и место запроса;
• состояние устройства;
• контекст текущей сессии;
• дополнительные правила безопасности.

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

Поэтому авторизация в современных системах — это не обязательно простая проверка вида «администратор или не администратор». Она может представлять собой достаточно сложную систему политик.

Что такое права доступа

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

Например, файловая система может разрешить пользователю читать файл, но запретить его изменение. В базе данных приложение может иметь право выполнять SELECT, но не иметь разрешения на DELETE.

Чем точнее определены права, тем проще реализовать принцип минимальных привилегий: субъект получает только те полномочия, которые действительно необходимы для выполнения его задач.

Авторизация на основе ролей — RBAC

Одним из наиболее распространенных подходов является Role-Based Access Control (RBAC). В этой модели права связываются прежде всего с ролями, а пользователям назначаются соответствующие роли.

Например, в CRM могут существовать роли:

• Менеджер — работа со своими клиентами;
• Руководитель — просмотр клиентов отдела и отчетов;
• Администратор — управление пользователями и настройками.

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

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

Авторизация на основе атрибутов — ABAC

Attribute-Based Access Control (ABAC) использует для принятия решения различные атрибуты субъекта, ресурса, действия и контекста.

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

ABAC позволяет создавать более гибкие правила, чем простая ролевая модель. NIST описывает ABAC как подход, при котором решения о доступе принимаются на основе атрибутов субъектов, объектов и условий политики.

Дискреционная и мандатная авторизация

В информационной безопасности используются разные модели управления доступом. В DAC (Discretionary Access Control) владелец ресурса может управлять тем, кому предоставляется доступ. Типичным примером является файловая система, где владелец файла устанавливает разрешения.

В MAC (Mandatory Access Control) доступ определяется централизованной политикой и установленными уровнями безопасности. Пользователь не может самостоятельно изменить обязательные правила доступа.

Выбор модели зависит от назначения системы, требований безопасности и характера обрабатываемой информации.

Авторизация в API

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

Например, токен может предоставлять приложению право читать профиль пользователя, но не разрешать изменение платежных реквизитов. Сервер API проверяет переданные учетные данные и соответствующие разрешения перед выполнением операции.

В OAuth 2.0 эта концепция реализуется через access token. Согласно RFC 6749, OAuth позволяет стороннему приложению получить ограниченный доступ к HTTP-сервису, а access token может определять область действия и срок предоставленного доступа.

Авторизация и OAuth

Название OAuth содержит слово «authorization» не случайно. OAuth предназначен для делегирования доступа к защищенным ресурсам без передачи стороннему приложению пароля пользователя.

Например, пользователь может разрешить приложению работать с определенными файлами облачного сервиса. Authorization Server выдает клиенту токен, после чего Resource Server проверяет этот токен при обращении к защищенному API.

При этом OAuth не следует полностью отождествлять с обычной авторизацией пользователя в локальном приложении. Это специализированная архитектура делегированного доступа, рассчитанная прежде всего на взаимодействие приложений и защищенных HTTP-ресурсов.

Сессии и авторизация

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

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

Например, менеджер и администратор могут одновременно иметь активные сессии, но сервер будет принимать разные решения при обращении к административному API.

Почему нельзя полагаться только на скрытие интерфейса

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

Такой подход не является полноценной авторизацией. Злоумышленник может напрямую отправить HTTP-запрос к API, минуя веб-интерфейс.

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

Принцип минимальных привилегий

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

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

Ограничение привилегий уменьшает потенциальные последствия компрометации учетной записи или программного компонента.

Что происходит при отказе в авторизации

Если субъект успешно аутентифицирован, но не имеет необходимых полномочий, система должна отклонить операцию. Для веб-приложений и API часто используется HTTP-код 403 Forbidden, когда сервер понимает запрос, но отказывает в его выполнении.

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

Аудит авторизации

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

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

При этом журналирование должно учитывать требования безопасности и приватности: чрезмерное сохранение чувствительных данных само по себе может создавать дополнительные риски.

Выводы

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

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

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

FAQ

Что такое авторизация простыми словами?

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

Чем авторизация отличается от аутентификации?

Аутентификация проверяет, кто именно находится по другую сторону системы, а авторизация определяет, какие ресурсы и операции доступны этому субъекту.

Что такое идентификация, аутентификация и авторизация?

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

Что такое права доступа?

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

Что такое RBAC?

RBAC — модель управления доступом на основе ролей. Пользователю назначается одна или несколько ролей, а каждая роль содержит определенный набор разрешений.

Что такое ABAC?

ABAC — модель авторизации на основе атрибутов. Решение о доступе принимается с учетом характеристик пользователя, ресурса, операции и контекста.

Можно ли считать скрытие кнопки авторизацией?

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

Что означает HTTP 403?

HTTP 403 Forbidden обычно означает, что сервер понял запрос, но отказывается выполнять его из-за отсутствия необходимых прав.

Что такое минимальные привилегии?

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

Связана ли авторизация с OAuth?

Да. OAuth 2.0 является архитектурой делегированного доступа, позволяющей приложению получить ограниченный доступ к защищенным ресурсам с использованием access token вместо передачи пароля пользователя.

Дополнительная информация:

• NIST — определение авторизации и управления доступом: NIST CSRC: Authorization
• NIST — определение управления доступом: NIST CSRC: Access Control
• NIST — руководство по Attribute-Based Access Control: NIST SP 800-162
• IETF — OAuth 2.0 Authorization Framework: RFC 6749
• NIST — глоссарий терминов информационной безопасности: NIST CSRC Glossary