Руслан Рахметов, Security Vision
Технология авторизации — это важная часть информационной безопасности, которая определяет, что именно пользователь может делать в системе после того, как он прошёл аутентификацию (т.е. доказал свою личность). Авторизоваться – значит запустить и пройти проверку прав доступа, когда система решает, можешь ли ты просматривать личные данные, редактировать их, или только читать. В текущей статье мы разберём каждый вид авторизации — что он из себя представляет, как работает, где используется, его плюсы и минусы. Это поможет вам как выбрать для своих задач подходящую методику, так и разобраться в отличиях.
Все модели авторизации можно описать несколькими группами, на основе ролей, атрибутов, списков доступа и политик безопасности.
RBAC (Role-Based Access Control) — это один из самых популярных и широко используемых методов авторизации. Он прост в реализации и понятен для большинства систем. Контроль доступа на основе ролей — это модель, при которой доступ к ресурсам предоставляется не напрямую пользователям, а через роли (наборы прав, которые определяют, какие действия можно выполнять).
Такую модель можно представить в виде трёх уровней:
1) пользователь получает одну или несколько ролей;
2) каждая роль содержит набор разрешений;
3) разрешения определяют, что можно делать (например: читать, писать, удалять).
Можно представить дом с разными ключами для множества замков, когда у каждого жильца свой уровень доступа: ребёнок открывает только входную дверь, родители — ещё и подвал, гараж. Четкое разделение по ролям можно заметить, например, в супермаркете, когда покупатель берёт товар и собирает продуктовую корзину, кассир пробивает и помогает провести оплату, менеджер пересчитывает кассу в указанные регламентами сроки, а директор магазина имеет доступ ко всем системам.
В модели авторизации RBAC легко назначать и изменять доступ, просто меняя роли, благодаря прозрачности уровней сразу становится понятно, кто за что отвечает. Подходит она для систем с сотнями пользователей, а с точки зрения безопасности позволяет легко внедрить принцип наименьших привилегий. Несмотря на простоту и прозрачность, модель эта не самая гибкая: если нужно задать уникальные права пользователю, нужно создавать новые роли или делать исключения, а при большом количестве комбинаций прав может появиться множество ролей, и ими сложно управлять.
RBAC широко применяется в корпоративных системах (например, в компании у сотрудников есть роли: бухгалтер, менеджер, директор, и у каждого свои права в системе), сайтах и веб-приложениях (админ может всё, редактор — публиковать, пользователь — только читать), базах данных (например, в PostgreSQL и Oracle у каждой роли своя видимость таблиц, процедур и данных), операционных системах (в Linux или Windows: у обычных пользователей ограниченные права, у администратора — полный доступ) и облачных решениях (например, в AWS создаются роли с доступом только к нужным сервисам). Сравнить такую модель можно с работой доступов в библиотеке, когда посетители могут читать книги, библиотекари — выдавать и принимать, а заведующая — заказывать новые экземпляры по потребности. Или с работой с данными в поликлинике, когда пациент видит свою карту, медсестра может вносить назначения, врач ставит диагнозы, а главный врач управляет всем сразу и имеет самый полный доступ.
ABAC (Attribute-Based Access Control) – гораздо более гибкий и «умный» способ управления доступом. Контроль доступа на основе атрибутов – это модель авторизации, в которой решения о доступе принимаются на основе набора атрибутов: пользователя (кто он), ресурса (что это), действия (что он хочет сделать), контекста (в каком окружении). А доступ выдается в том случае, если все условия совпали.
Вместо простых ролей, как в RBAC, здесь применяется логика «если Х - то Y», например: ЕСЛИ пользователь работает в отделе HR, ресурс – файл типа резюме, текущее время – рабочие часы и доступ запрашивается с корпоративного устройства, ТОГДА разрешить доступ к чтению файла. Также модель применима для постаматов в пунктах выдачи товаров: если покупатель пришел на место и предоставил код доступа к ячейке в пределах сроков хранения посылки – дверь откроется и клиент сможет получить товар.
Вся авторизация строится на политиках доступа (rules/policies), состоящих из логических выражений.
Таким образом, например, работают доступы в школу (если это учитель, и у него карта доступа, и сейчас будний день — разрешить вход) или выдается социальная скидка в супермаркетах (если покупателю > 60 лет, у него есть подтверждение возраста или статуса и покупки совершаются в будние дни до 17:00, тогда предоставляется дополнительная скидка 10%).
ABAC обеспечивает большую гибкость, можно задавать доступ в зависимости от множества факторов. Сам доступ настраивается гранулярно, к конкретным объектам в определённых условиях, а система авторизации отлично масштабируется: не нужно создавать тысячи ролей, как в RBAC. Поскольку для реализации модели нужно спроектировать и внедрить систему правил, а со временем логика может стать слишком запутанной, у текущего варианта достаточно высокий порог входа – нужно хорошо понимать логику политик.
ABAC применяется для корпоративных порталов с множеством переменных (отдел, регион, стаж, устройство), облачных платформ (AWS, Azure), где администраторы гибко управляют доступом по ресурсам, тегам, условиям, в финансовых и медицинских системах, где нужно учитывать множество факторов безопасности, а также в военных и государственных учреждениях.
ACL (Access Control List) – это список правил, который прикреплён к каждому ресурсу (например, файлу, записи в БД, API-эндпоинту) и определяет, кто и что может делать с этим объектом. Доступ через список контроля определяет разрешения на объекте, а не на пользователе: у каждого ресурса есть список, где указано кто может получить доступ и что сможет сделать по правилам компании.
Так, например, устроены многие системы доступа в офис (у каждой двери есть свой список, кто может входить, например, в серверную — только админы) или игры на приставке (у каждой игры может быть доступ по профилю: «детский», «взрослый», «гость», которые определяют кто сможет запустить игру, сохранить прогресс или удалить сохранения).
Модель ACL очень гибкая на уровне каждого ресурса, можно очень точно настроить, кто к чему имеет доступ, она используется десятилетиями (например, в UNIX -системах вроде MacOS), реализовать её достаточно просто. Несмотря на это, ACL масштабируется достаточно сложно (если объектов много, становится сложно управлять списками), а понять, кто к чему имеет доступ, сложнее, чем в первой модели нашего списка (RBAC).
Применяется она в файловых системах (Linux, Windows, NTFS, ext4), веб-сервисах (Apache.htaccess), базах данных (например, MongoDB, Redis), сетевых устройствах и облачных хранилищах (Яндекс.Диск, Google Drive, Dropbox).
MAC (Mandatory Access Control) – это самая жёсткая и строгая модель авторизации из всех, о которых мы говорили выше. Модель принудительного контроля доступа, при которой правила задаются централизованно, и пользователи не могут изменить права доступа самостоятельно – как армейский устав: всё строго по регламенту.
Каждому: объекту (документ, файл, база, ресурс) и субъекту (пользователь, процесс) присваиваются метки безопасности (например, «Секретно», «Конфиденциально», «Открыто» для разных объектов-документов, а доступ разрешается только если метка субъекта соответствует метке объекта (или выше).
Это похоже на доступ в зону запуска на космодроме (только у инженеров с «допуском» есть возможности пройти на территорию и выполнять там свою работу) или доступ к экзаменационным материалам (только комиссия имеет доступ, а студенты получают ограниченные права на ознакомление ближе к сессии).
MAC работает по принципу «не доверяй никому» (Zero-Trust): пользователь не может сам поменять права доступа, которые проверяются по политике безопасности, установленной администратором. Используется иерархия уровней доступа (как в армии или правительстве). Таким образом обеспечивается максимальная безопасность, единообразие политик и максимальное исключение человеческого фактора. Однако системы типа MAC показывают минимальную гибкость и сложность в настройках.
Такие четыре метода авторизации описывают подавляющее большинство процессов:
RBAC — это как система пропусков, где каждому назначается роль, и на основе этой роли определяется, что он может делать;
ABAC работает, как умный швейцар, который проверяет кучу условий, прежде чем впустить тебя: «ты сотрудник… но ты не из того отдела… да ещё и выходной… извини, доступ запрещён!»;
ACL отлично подходит там, где важен контроль на уровне объекта (это как списки гостей у каждого помещения), а не роли или контекста. Но при большом масштабе может стать неудобным;
А MAC, как военная дисциплина для файлов и данных, никакой демократии: всё решает метка и политика безопасности («Ты не в списке – ты не заходишь, даже если ты начальник отдела»).
Основная цель авторизации — защита данных и ресурсов: авторизация обеспечивает безопасность, позволяя только авторизованным пользователям получать доступ к определённым системам, функциям или данным. Без авторизации информация может быть уязвима для несанкционированного доступа.
