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

Впервые контроль доступа был применён в Министерстве обороны США в 1960х-1970х годах и включал модели дискреционного (англ. Discretionary Access Control, DAC) и мандатного доступов (англ. Mandatory Access Control, MAC)[5].

С ростом сетей появилась необходимость в ограничении доступа к особо защищённым объектам. Так появился механизм контроля доступа на основе идентичности (англ. Identity-Based Access Control, IBAC), использующий списки контроля доступа (англ. Access Control List). Каждый субъект имеет свой список. Только предоставив доказательство своего полномочия, лицо получает доступ к объекту. Оно может иметь различные привилегии (на чтение, запись, редактирование, удаление и другие). Владелец объекта определяет доступные операции для каждого субъекта. Таким образом, из-за необходимости ручного контроля и возможных неудачных аннулирований прав доступа субъекты могут непроизвольно получать больше привилегий, чем того подразумевала политика[5].

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

ACL и RBAC являются частными случаями механизма ABAC, главной идеей которого является определение контроля по атрибутам сущностей, вовлечённых в систему. Для реализации ACL в рамках ABAC атрибутом является идентичность, для RBAC — роль. Главным отличием от этих двух моделей в ABAC является понятие политик, выраженных через определённый набор логических правил, учитывающих самые разные свойства объекта, субъекта и среды. С помощью организации системы правил уменьшаются трудозатраты на реализацию нужных ограничений в доступе. Кроме того, при модифицировании уже существующих политик в списках контроля доступа и ролевой модели сложнее учесть все места, требующие изменений[6].

Одним из основных стандартов для управления доступом на основе атрибутов является XACML (англ. eXtensible Access Control Markup Language)[5][7], разработанный изначально в 2001 г. глобальным консорциумом OASIS. Этот стандарт занимается регулированием общих концепций безопасности в системе, а не менеджментом атрибутов, включающим назначение, модификацию, удаление и т. д.

Главными понятиями в XACML являются правила (англ. rules), политики (англ. policies), алгоритмы комбинации правил и политик (англ. rule-combining-algorithms), атрибуты (англ. attributes) (субъекта, объекта, действий и условий среды), обязательства (англ. obligations) и рекомендации (англ. advices)[5]. Центральным элементом является правило, которые содержит в себе цель, эффект, условия, обязательства и рекомендации (двух последних может не быть) [8]. Цель — это то, как субъект ожидает подействовать на объект (читать, редактировать, удалять и т. д.). Эффект, который на основе вычислений логического выражения определяется системой контроля доступа, может быть или разрешением (англ. permit), или отказом (англ. deny), или «не применимо» (англ. not applicable), или «не определено» (англ. indeterminate). Решение системы о неприменимости принимается в случае, когда логическое условие оказывается «ложью». При возникновении ошибки во время вычисления выражения система выдаёт «не определено».

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

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

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

Сама структура управления бизнес-моделью ABAC состоит из 4 базовых механизмов, которые являются ключевыми узлами в реализации политик[5]:

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

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

Этот пример иллюстрирует политику компании Medi Corp (доменное имя: med.example.com)[8]:

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

XACML политика содержит заголовочную информацию (англ. header) (пространства имен, идентификатор, алгоритмы её отработки, описание), цель (англ. 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, начиная с Version 1.0 и до нынешней версии Version 3.0 Plus с примечаниями от 12 июля 2017 г., а также более детализированными примерами создания правил, политик, наборов политик, запросов и ответов контекста[8].

Из-за того, что модель RBAC (англ. Role-Based Access Control, RBAC) используется до сих пор во многих компьютерных системах, то, будучи улучшением и обобщением, атрибутная модель управления доступом (англ. Attribute-Based Access Control, ABAC) также применима во многих сферах IT-области и бизнес-системах[7][9].

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

Рассматриваемая модель также применяется при проектировании архитектуры систем безопасности для компаний, в которых численность пользователей измеряется тысячами, соответственно количество привилегий в несколько раз больше, много динамически разрешаемых запросов к системе и мощная интеграция частей общей инфраструктуры. Это могут быть различные коммерческие организации, банки, финансовые рынки и другие фирмы и государственные предприятия, требующие оперативную поддержку в контроле доступа и имеющие многочисленную базу сотрудников, партнёров и клиентов, разделяющих доступ к данным. Внедрением решений на основе ABAC и гибридных систем безопасности в крупные организации занимается российская компания Custis. Хотя доработка ролевой модели в атрибутивную предполагает большие трудозатраты, гибкость управления доступом в случае перехода повышается, и в дальнейшем при хорошем проектировании для изменения политик не приходится привлекать разработчиков[11].

Во многих облачных вычислениях на уровне инфраструктуры как услуги используется модель на основе атрибутов. Она обеспечивает безопасность хранилищ данных, сетей, вычислительных средств и других компонент схемы IaaS. Примерами известных провайдеров могут быть Amazon Web Service, OpenStack и другие[12].

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

• Управление доступом на основе ролей
• Избирательное управление доступом
• Мандатное управление доступом

• Daniel Servos, Sylvia L. Osborn. Current Research and Open Problems in Attribute-Based Access Control (англ.). — University of Western Ontario.
• Vincent C. Hu, etc. Guide to Attribute Based Access Control (ABAC) Definition and Considerations (англ.). — National Institute of Standards and Technology, 2014. — P. 45. — doi:10.6028/NIST.SP.800-162. Архивировано 5 марта 2016 года.
• William Fisher. Attribute Based Access Control (англ.). — National Institute of Standards and Technology, 2015. — P. 22.
• Alan H. Karp, etc. From ABAC to ZBAC: The Evolution of Access Control Models (англ.). — HP Laboratories, 2009. — P. 21.
• Bill Parducci, Hal Lockhart. eXtensible Access Control Markup Language (XACML) Version 3.0 Plus Errata 01 (англ.). — OASIS, 2017. — P. 154.
• Xin Jin. ATTRIBUTE-BASED ACCESS CONTROL MODELS AND IMPLEMENTATION IN CLOUD INFRASTRUCTURE AS A SERVICE (англ.). — THE UNIVERSITY OF TEXAS AT SAN ANTONIO, 2014. — P. 144.

• - Cisco Enterprise Policy Manager
• - Интервью Петра Марголиса, Custis
• - SmartGuard for Big Data
• - Axiomatics
• - Подходы к контролю доступа: RBAC vs. ABAC
• - Знакомство с XACML — стандартом для Attribute-Based Access Control