Разграничение доступа на основе атрибутов

Первые механизмы контроля доступа были внедрены в Министерство обороны США в 1960-х — 1970-х годах и реализовали модели избирательного (англ. Discretionary Access Control, DAC) и мандатного (англ. Mandatory Access Control, MAC) управления доступом.

С развитием вычислительных сетей возникла задача ограничения доступа к особо защищённым объектам. При этом сформировалась модель контроля доступа на основе идентичности (англ. Identity-Based Access Control, IBAC), использующая ACL (англ. Access Control List). Для каждого субъекта создаётся собственный список, где указываются разрешённые действия. Доступ осуществляется только при подтверждении полномочий, а количество привилегий может отличаться для разных субъектов (чтение, запись, удаление и др.). Однако необходимость ручного управления списками и риска ошибок при отзыве прав приводит к возможному непреднамеренному расширению возможностей субъектов доступа, что не соответствует изначальной политике.

Одной из альтернатив стала ролевая модель (англ. Role-Based Access Control, RBAC), где права объединяются в роли, назначаемые субъектам. В компьютерных системах (СУБД, ОС) субъекту присваивается единичная роль, хотя в реальных процессах их может быть несколько. При обращении к ресурсу система определяет роль пользователя и, согласно ей, разрешает определённые операции. Роль в данном случае можно трактовать как атрибут субъекта. Wведение RBAC усилило централизацию управления и устранило необходимость в явных списках ACL.

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

Эволюционным развитием ABAC стал стандарт NGAC (англ. Next Generation Access Control), разработанный NIST. В отличие от классического ABAC, опирающегося на проверку статических атрибутов с помощью сложной условной логики, NGAC использует графовую модель данных. Политики доступа накладываются поверх графа, описывающего структуру организации, пользователей и ресурсы. Такой подход значительно упрощает управление, а также обеспечивает линейную масштабируемость и высокую производительность системы при усложнении правил доступа^[5][6].

Ключевым стандартом управления доступом на основе атрибутов считается XACML, разработанный консорциумом OASIS в 2001 году. XACML определяет общие концепции безопасности, а не занимается управлением самими атрибутами (назначением, удалением и прочими операциями).

Главные понятия в XACML — правило, политика, алгоритм комбинирования правил и политик, атрибуты субъектов, объектов, действий и среды, обязательства и рекомендации. Центральный элемент — правило, содержащее цель, эффект, условия, обязательства и рекомендации (последние два могут отсутствовать). Цель — это ожидаемое действие субъекта над объектом, а эффект после выполнения логического выражения определяется как «разрешить», «отказать», «не применимо» или «не определено». При ложном логическом условии система принимает решение о неприменимости; при ошибке — выдаёт «не определено».

Пример бизнес-правила:

Более общим элементом является политика, объединяющая несколько правил с помощью определённых алгоритмов — именно они формируют систему контроля компании. Самая общая единица — набор политик. Это реализует модульность инфраструктуры безопасности даже на верхних уровнях.

Политики могут задаваться на естественном языке (англ. Natural Language Policy, NLP), затем транслируемом в цифровые политики (англ. digital policies, DP), используемые уже на уровне машинного исполнения. Такая трансляция важна для обеспечения совместимости атрибутов между различными организациями. Кроме NLP и DP, существуют метаполитики (англ. metapolicy, MP), регулирующие иерархии, разрешающие конфликты и подтверждающие корректность цифровых политик.

Структура управления бизнес-моделью ABAC состоит из четырёх базовых компонентов:

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

Дополнительно может применяться обработчик контекста (англ. Context Handler), регулирующий последовательность применения политик и обработку поиска атрибутов, а также переводящий решения в исполняемый код.

Закономерной эволюцией ABAC, направленной на упрощение управления сложными правилами доступа, стали концепции «внешней авторизации» (англ. Externalized Authorization) и «политики как код» (англ. Policy-as-Code). В рамках этих подходов логика авторизации выносится из исходного кода приложения во внешний выделенный движок, а правила пишутся в виде декларативных политик, которые централизованно управляются и развёртываются программно^[7][8].

В современных облачных и микросервисных средах популярным инструментом для реализации ABAC является Open Policy Agent (OPA), использующий декларативный язык Rego^[9][10].

Для упрощения написания политик также применяются современные языки с более компактным и интуитивно понятным синтаксисом по сравнению с XML-форматом XACML. Среди них выделяется Cedar, имеющий открытый исходный код и масштабно используемый в экосистеме Amazon Web Services (AWS)^[11]. Другим примером является ALFA (англ. Abbreviated Language for Authorization) — язык с синтаксисом, похожим на Java и C#, который позволяет высокоуровнево описывать политики с их последующей компиляцией в стандарт XACML^[12].

Ниже приведён пример политики для компании Medi Corp (med.example.com):

Любой пользователь с электронной почтой в домене med.example.com имеет право выполнять любые действия над любыми ресурсами.

XACML-политика включает заголовок (пространства имён, идентификатор политики, алгоритмы, описание), цель (англ. target), правила (обычно несколько) и возможный блок обязательств.

 <?xml version="1.0" encoding="UTF-8"?>
 <Policy
   xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17
   http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd"
   PolicyId="urn:oasis:names:tc:xacml:3.0:example:SimplePolicy1"
   Version="1.0"
   RuleCombiningAlgId="identifier:rule-combining-algorithm:deny-overrides">
   <Description>
     Medi Corp access control policy
   </Description>
   <Target/>
   <Rule
     RuleId= "urn:oasis:names:tc:xacml:3.0:example:SimpleRule1"
     Effect="Permit">
     <Description>
       Any subject with an e-mail name in the med.example.com domain
       can perform any action on any resource.
     </Description>
     <Target>
       <AnyOf>
         <AllOf>
           <Match
             MatchId="urn:oasis:names:tc:xacml:1.0:function:rfc822Name-match">
           <AttributeValue
             DataType="http://www.w3.org/2001/XMLSchema#string"
               >med.example.com</AttributeValue>
           <AttributeDesignator
             MustBePresent="false"
             Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
             AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
             DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name"/>
           </Match>
         </AllOf>
       </AnyOf>
     </Target>
   </Rule>
 </Policy>

Документация OASIS на сайте www.oasis-open.org предоставляет подробные описания XACML со всеми версиями стандарта, а также примеры политик, наборов политик, запросов и ответов.

Модель RBAC (англ. Role-Based Access Control, RBAC) по-прежнему широко используется, но атрибутивная модель (англ. Attribute-Based Access Control, ABAC) как её обобщение применима во многих IT- и бизнес-системах.

В продукте Cisco Enterprise Policy Manager реализованы механизмы PDP (англ. Policy Decision Point), PAP (англ. Policy Administration Point) и PEP (англ. Policy Enforcement Point), что упрощает развёртывание и сопровождение политик в инфраструктуре компании и централизует управление безопасностью приложений, баз данных, конфигурацией и др.

Модель ABAC применяют и при проектировании систем безопасности в крупных организациях, где тысячи пользователей, множество привилегий, многочисленные динамические запросы и требуется интеграция с разными модулями. Среди внедряющих гибридные решения — российская компания Custis. Несмотря на начальные трудозатраты, дальнейшее изменение политик становится более простым и не требует участия разработчиков.

В инфраструктуре как услуга (IaaS) многие облачные провайдеры (например, Amazon Web Services, OpenStack) используют ABAC для защиты сетей, хранилищ, вычислительных ресурсов и других компонентов.

В 2024 году облачные решения для контроля доступа на основе атрибутов впервые превзошли локальные (on-premise) по доле выручки на рынке, а в 2025 году на них пришлось 54,4 % рыночной выручки и более 54 % новых внедрений^[13].

Для централизованного управления детализированными разрешениями в пользовательских приложениях AWS предоставляет сервис Amazon Verified Permissions (AVP), который использует язык политик Cedar с поддержкой ABAC.

Атрибутивное управление доступом применяется и для защиты больших данных. Примером является продукт SmartGuard для Hadoop от компании Axiomatics, обеспечивающий динамическую авторизацию для защиты ценных данных.

Модель ABAC играет важную роль в обеспечении соответствия европейским регламентам. В рамках GDPR она позволяет реализовать принципы минимизации данных и ограничения цели, предоставляя доступ строго в зависимости от контекста, а также обеспечивает гранулярный аудит доступа к чувствительной информации. Кроме того, ABAC помогает предприятиям выполнять расширенные требования к кибербезопасности директивы NIS2, заменяя устаревшие модели доступа более надёжными механизмами защиты^[13].

Интеграция модели управления доступом на основе атрибутов (ABAC) в системы искусственного интеллекта обеспечивает безопасную автоматизацию рабочих процессов и управление автономными ИИ-агентами^[14].^[15]

Основные методы интеграции включают:

• Использование многоуровневых точек контроля, при которых проверки доступа встраиваются на всех этапах работы ИИ (обработка промптов, поиск данных, вызов инструментов и генерация вывода)^[14].^[16]
• Централизованное управление с применением центральных движков принятия решений и кэшированием результатов для сохранения высокой производительности^[14].^[16]

Применение ABAC позволяет решать следующие задачи в области безопасности ИИ:

• Предотвращение избыточного раскрытия данных путём автоматической блокировки или маскирования конфиденциальной информации в ответах ИИ^[14].^[16]
• Защита от prompt-инъекций за счёт ограничения доступа ИИ к несанкционированным данным даже при успешной манипуляции запросом^[14].
• Контекстная фильтрация поиска, исключающая запрещённые документы из контекстного окна ИИ на основе меток и списков контроля доступа^[14].^[16]

Среди примеров использования ABAC выделяются управление доступом для ИИ-агентов (например, разрешение агенту поддержки читать записи CRM при запрете на изменение платёжных данных) и защита корпоративных данных (медицинских карт, финансовых документов и ERP-систем), с которыми взаимодействуют ИИ-инструменты^[15].

Внедрение модели управления доступом на основе атрибутов (ABAC) на крупных предприятиях сопряжено с рядом технологических и ресурсных барьеров:

• Сложность управления политиками: крупным предприятиям необходимо создавать, тестировать и поддерживать большое количество правил. При множестве атрибутов политики становятся громоздкими, а возможные конфликты правил могут привести к избыточному доступу или ошибочной блокировке пользователей^[17].^[18].
• Требования к качеству и синхронизации данных: эффективность модели критически зависит от точности, полноты и актуальности атрибутов. Необходима постоянная синхронизация и нормализация данных из множества источников (HR-системы, службы каталогов, CRM)^[19][20].
• Технологическая сложность интеграции: внедрение требует использования специализированных решений и их интеграции с существующей ИТ-инфраструктурой, включая унаследованные системы^[21][22].
• Снижение производительности: обработка сложных логических выражений и оценка множества атрибутов в режиме реального времени могут создавать задержки при аутентификации и увеличивать общую латентность системы^[19][20].