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

Первые механизмы контроля доступа были внедрены в Министерство обороны США в 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 требует большего внимания к корректности изменений.

Ключевым стандартом управления доступом на основе атрибутов считается 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), регулирующий последовательность применения политик и обработку поиска атрибутов, а также переводящий решения в исполняемый код.

Ниже приведён пример политики для компании 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 для защиты сетей, хранилищ, вычислительных ресурсов и других компонентов.

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