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

Управление доступом на основе атрибутов (англ. Attribute-Based Access Control, ABAC) — это модель контроля доступа, в которой решения о предоставлении доступа к ресурсам принимаются на основе набора атрибутов, связанных с субъектом (пользователем), объектом (ресурсом), действием и окружением (средой). В отличие от ролевых моделей (RBAC), где доступ определяется исключительно ролью пользователя, ABAC позволяет формировать более гибкие и динамичные политики, учитывающие множество факторов.

Основные принципы

ABAC базируется на логическом выводе, где каждое правило доступа формулируется как булево выражение, состоящее из атрибутов. Если выражение истинно, доступ разрешается; если ложно — запрещается. Ключевыми элементами модели являются:

• Субъект — пользователь, процесс или устройство, запрашивающее доступ. Его атрибуты могут включать: идентификатор, должность, отдел, уровень допуска, местонахождение, время последней аутентификации.
• Объект — ресурс, к которому запрашивается доступ (файл, база данных, сервер, API-метод). Атрибуты объекта: тип, владелец, классификация (например, «секретно», «для служебного пользования»), дата создания, чувствительность.
• Действие — операция, которую субъект намерен выполнить над объектом (чтение, запись, удаление, выполнение, копирование).
• Окружение — контекст, в котором происходит запрос доступа. Атрибуты окружения: текущее время, IP-адрес, используемое устройство, уровень угрозы, географическое положение.

Политика доступа в ABAC представляет собой набор правил, каждое из которых связывает эти четыре типа атрибутов. Например: «Разрешить чтение документа, если его классификация равна "открытый" ИЛИ (должность субъекта = "руководитель отдела" И отдел субъекта = отдел, создавший документ) И время запроса находится в пределах рабочего дня (с 9:00 до 18:00)».

История и развитие

Концепция атрибутного управления доступом начала формироваться в конце 1990-х — начале 2000-х годов как развитие идей мандатного (MAC) и дискреционного (DAC) управления доступом. В 2000-х годах Национальный институт стандартов и технологий США (NIST) опубликовал серию документов, формализующих модель ABAC. В 2013 году был принят стандарт XACML (eXtensible Access Control Markup Language) версии 3.0, разработанный организацией OASIS, который стал основным языком описания политик ABAC.

В России развитие ABAC связано с внедрением систем защиты информации в государственных и корпоративных информационных системах, особенно в контексте требований Федерального закона № 152-ФЗ «О персональных данных» и нормативных документов ФСТЭК России. Ряд российских вендоров (например, «Код Безопасности», «Лаборатория Касперского», «ИнфоТеКС») предлагают продукты, поддерживающие ABAC-моделирование.

Архитектура и компоненты

Система ABAC обычно включает следующие компоненты:

• Policy Enforcement Point (PEP) — точка принудительного применения политики. Перехватывает запросы доступа, формирует запрос к PDP и исполняет принятое решение (разрешить/запретить).
• Policy Decision Point (PDP) — точка принятия решений. Оценивает запрос на основе политик, хранящихся в Policy Administration Point (PAP), и атрибутов, полученных от Policy Information Point (PIP). Возвращает PEP решение.
• Policy Administration Point (PAP) — точка администрирования политик. Интерфейс для создания, редактирования и управления правилами доступа.
• Policy Information Point (PIP) — точка получения информации. Служит источником атрибутов субъектов, объектов и окружения. Может обращаться к LDAP-каталогам, базам данных, системам управления идентификацией (IdM), системам мониторинга.
• Policy Retrieval Point (PRP) — точка хранения политик. База данных или репозиторий, где хранятся правила и политики.

Преимущества и недостатки

Преимущества

• Гибкость и детализация. Позволяет создавать политики, учитывающие множество параметров, что невозможно в RBAC или DAC.
• Динамичность. Правила могут изменяться в реальном времени без перезагрузки системы (например, доступ к документу может быть временно ограничен при повышении уровня угрозы).
• Масштабируемость. Легко добавлять новые атрибуты и правила без изменения архитектуры системы.
• Контекстная осведомлённость. Учитывает окружение (время, местоположение, устройство), что важно для мобильных и облачных сред.
• Поддержка сложных сценариев. Например, доступ к данным может быть разрешён только для сотрудников, находящихся в командировке в определённом регионе, и только в рабочие часы.

Недостатки

• Сложность администрирования. Требует квалифицированного персонала для разработки и поддержки политик. Большое количество атрибутов может привести к запутанным правилам.
• Производительность. Оценка сложных булевых выражений может быть ресурсоёмкой, особенно при большом количестве запросов. Требуется оптимизация PDP.
• Управление атрибутами. Необходимо поддерживать актуальность и целостность атрибутов (например, при переводе сотрудника в другой отдел). Ошибки в атрибутах могут привести к утечкам данных или блокировкам.
• Сложность аудита. Трудно отследить, почему конкретный запрос был разрешён или запрещён, если политика содержит много условий.

Применение

ABAC широко используется в:

• Корпоративных информационных системах (ERP, CRM, HRM) — для разграничения доступа к данным в зависимости от должности, отдела, географического расположения, времени.
• Облачных сервисах (AWS, Azure, Google Cloud) — встроенные сервисы управления доступом, такие как AWS IAM, поддерживают атрибутные политики.
• Системах управления базами данных — для тонкой настройки доступа к строкам и столбцам таблиц (Row-Level Security, Column-Level Security).
• Медицинских информационных системах — доступ к электронным медицинским картам может быть разрешён только врачам определённой специальности, работающим в той же клинике, и только в рабочее время.
• Государственных информационных системах — например, в единой системе межведомственного электронного взаимодействия (СМЭВ) в России.
• Системах управления цифровыми правами (DRM) — для контроля доступа к контенту на основе атрибутов пользователя (подписка, регион, возраст).

Отличие от других моделей

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

Интересные факты

• В 2020 году NIST опубликовал специальную публикацию SP 800-162, посвящённую руководству по внедрению ABAC.
• В России требования к системам управления доступом, включая ABAC, регулируются приказами ФСТЭК России (например, Приказ № 17 от 11 февраля 2013 года «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»).
• ABAC активно используется в архитектуре Zero Trust (нулевого доверия), где ни один запрос не считается доверенным по умолчанию, а решение о доступе принимается на основе множества атрибутов в реальном времени.

Источники

• NIST Special Publication 800-162. «Guide to Attribute Based Access Control (ABAC) Definition and Considerations». 2014.
• OASIS Standard. «eXtensible Access Control Markup Language (XACML) Version 3.0». 2013.
• ФСТЭК России. «Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах». Приказ № 17 от 11.02.2013.
• Hu, V. C., et al. «Attribute-Based Access Control». IEEE Computer, 2015.
• Sandhu, R. «The Future of Access Control: Attributes, Not Roles». Proceedings of the 21st Annual Computer Security Applications Conference, 2005.