Авторизация

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

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

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

1. Идентификация: Субъект сообщает системе свой идентификатор (например, логин, номер карты, IP-адрес).
2. Аутентификация: Система проверяет, что субъект действительно является тем, за кого себя выдаёт (с помощью пароля, биометрических данных, сертификата).
3. Авторизация: После успешной аутентификации система обращается к правилам доступа (политикам) и определяет, разрешено ли данному субъекту выполнять запрошенное действие (например, чтение файла, запись в базу данных, запуск программы).
4. Аудит: Система фиксирует факт предоставления или отказа в доступе в журнале событий.

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

Модели управления доступом

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

Дискреционное управление доступом (DAC — Discretionary Access Control)

В этой модели владелец ресурса (объекта) сам решает, кому и какие права предоставить. Каждый объект имеет список управления доступом (ACL — Access Control List), в котором перечислены субъекты и их разрешения (чтение, запись, выполнение). Классический пример — файловые системы Windows (NTFS) и Linux (права на файлы). Модель проста и гибка, но порождает риски: владелец может случайно или намеренно предоставить доступ постороннему.

Мандатное управление доступом (MAC — Mandatory Access Control)

Доступ контролируется централизованно на основе меток безопасности, присвоенных субъектам (например, «секретно», «совершенно секретно») и объектам (уровень секретности данных). Субъект может читать объект, только если его уровень допуска не ниже уровня секретности объекта, а записывать — только если не выше (правила Белла — ЛаПадулы). Эта модель жёсткая и негибкая, но обеспечивает высокий уровень защиты, поэтому применяется в государственных и военных системах. В гражданских ОС (например, SELinux для Linux) реализованы элементы MAC.

Ролевое управление доступом (RBAC — Role-Based Access Control)

Наиболее распространённая модель в корпоративных и веб-системах. Права доступа назначаются не отдельным пользователям, а ролям (например, «администратор», «менеджер», «бухгалтер», «гость»). Пользователь получает одну или несколько ролей, и через них — соответствующие полномочия. RBAC упрощает администрирование: при смене должности сотрудника достаточно изменить его роль, а не переназначать права вручную для каждого ресурса.

Управление доступом на основе атрибутов (ABAC — Attribute-Based Access Control)

Более гибкая и современная модель, где решение о доступе принимается на основе множества атрибутов: атрибутов субъекта (возраст, должность, отдел), атрибутов объекта (тип документа, уровень секретности), атрибутов среды (время суток, местоположение, тип устройства) и типа действия. Политика доступа формулируется в виде логических правил (например: «Разрешить доступ к документу, если пользователь является сотрудником отдела кадров И время — рабочее И устройство — корпоративный ноутбук»). ABAC широко используется в облачных сервисах и системах с большим количеством разнородных пользователей.

Механизмы реализации

Авторизация может быть реализована на различных уровнях информационной системы:

• На уровне операционной системы: Права доступа к файлам, процессам, устройствам (например, через ACL в Windows или права rwx в Linux).
• На уровне приложения: Внутренняя логика программы, проверяющая, может ли текущий пользователь выполнить определённое действие (например, редактировать статью в CMS или просматривать отчёт в ERP-системе).
• На уровне базы данных: Разграничение прав на выполнение SQL-команд (SELECT, INSERT, UPDATE, DELETE) для различных пользователей или ролей базы данных.
• На уровне сети: Фильтрация трафика на основе IP-адресов, портов и протоколов (межсетевые экраны), а также протоколы AAA (Authentication, Authorization, Accounting), такие как RADIUS и TACACS+.

Авторизация в веб-приложениях и API

В современных веб-системах и API (REST, GraphQL) авторизация часто реализуется с помощью токенов и протоколов OAuth 2.0 и OpenID Connect.

• OAuth 2.0: Протокол делегированного доступа, который позволяет приложению (клиенту) получить ограниченный доступ к ресурсам пользователя на стороннем сервере без передачи пароля. Пользователь авторизует приложение, и оно получает токен доступа (access token), который предъявляет при каждом запросе к API.
• OpenID Connect (OIDC): Надстройка над OAuth 2.0, которая, помимо авторизации, добавляет аутентификацию — позволяет клиенту удостовериться в личности пользователя и получить его базовые данные (профиль).

Внутри приложений широко применяются JSON Web Tokens (JWT) — компактные, URL-безопасные токены, содержащие утверждения (claims) о пользователе и его правах. Сервер проверяет подпись JWT и, не обращаясь к базе данных, извлекает из него информацию для принятия решения об авторизации.

Проблемы и уязвимости

Ошибки в реализации авторизации являются одними из самых критичных уязвимостей веб-приложений (согласно OWASP Top 10). Наиболее распространённые проблемы включают:

• Недостаточная проверка на уровне функции: Пользователь может вызвать функцию или API-эндпоинт, предназначенный для администратора, просто изменив URL или параметр запроса.
• Обход авторизации через идентификаторы: Уязвимость IDOR (Insecure Direct Object References), когда пользователь, изменив идентификатор записи (например, ?user_id=123 на ?user_id=124), получает доступ к чужим данным.
• Отсутствие проверки на уровне объекта: Система проверяет, что пользователь аутентифицирован, но не проверяет, имеет ли он право на доступ к конкретному объекту.
• Некорректная настройка ACL: Слишком широкие права для ролей или неправильное наследование разрешений.

Для защиты от этих уязвимостей необходимо применять принцип наименьших привилегий (субъекту выдаётся только минимум прав, необходимых для выполнения его работы), централизованную проверку авторизации и тщательное тестирование.

Источники

1. Фергюсон Н., Шнайер Б. «Практическая криптография». — М.: Вильямс, 2005.
2. Сандху Р. «Ролевое управление доступом». — М.: ДМК Пресс, 2003.
3. OWASP Foundation. «OWASP Top 10 — 2021: The Ten Most Critical Web Application Security Risks».
4. RFC 6749 — The OAuth 2.0 Authorization Framework.
5. RFC 7519 — JSON Web Token (JWT).