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

Разграничение доступа на основе атрибутов ( англ. Attribute-Based Access Control, ABAC ) — модель контроля доступа к объектам, основанная на анализе правил для атрибутов объектов или субъектов, возможных операций с ними и окружения, соответствующего запросу . Системы управления доступом на основе атрибутов обеспечивают мандатное и избирательное управление доступом . Рассматриваемый вид разграничения доступа даёт возможность создать огромное количество комбинаций условий для выражения различных политик ^{[

чего?

]} .

Главными компонентами любого механизма контроля доступа являются аутентификация и авторизация пользователя. Доступ к сети компании или её активам обычно зависит от должности сотрудника. Например, бухгалтер имеет возможность узнать как общую финансовую отчетность, так и конкретно по продажам, в то время как менеджер по продажам имеет доступ только к последней. Если сотрудник меняет должность или увольняется, администратор должен вручную поменять его роль, чтобы изменить права доступа, возможно даже в нескольких системах. Чтобы в таком и более сложных случаях упростить процесс изменения прав, фирме нужен более гибкий подход к контролю доступа .

Политика на основе атрибутов делает управление доступом более эффективным, уменьшая сложность нормативных требований. Одна и та же политика, основанная на атрибутах, может использоваться в разных системах. Это помогает управлять согласованностью доступа к ресурсам в пределах одной компании или между несколькими партнёрскими. Такое централизованное управление доступом предполагает единственный авторитетный источник для правил доступа, что делает необязательными проверки на соответствие требованиям каждой конкретной системы со своей политикой .

Развитием модели ABAC являются модели на основе аутентификации ( англ. autheNtication-Based Access Control, NBAC ) и авторизации ( англ. authoriZation-Based Access Control, ZBAC ), где учитывается проблема согласования значений атрибутов и уменьшается количество междоменных соглашений, но при этом требуются некоторые изменения в исходных системах .

Развитие механизмов контроля доступа

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

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

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

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

Стандарт XACML

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

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

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

Бизнес-правило
Цель	Узнать группу крови из медицинской карты пациента
Действие	Разрешить
Условие	Субъект. Должность=Врач & Среда. Время >= 8:00 & Среда. Время <= 18:00
Обязательство	Отобразить в журнале регистратуры дату просмотра (Среда. Дата) медицинской карты

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

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

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

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

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

Пример политики, реализованной в рамках стандарта XACML

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

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

Применение модели ABAC

Из-за того, что модель 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 и гибридных систем безопасности в крупные организации занимается российская компания . Хотя доработка ролевой модели в атрибутивную предполагает большие трудозатраты, гибкость управления доступом в случае перехода повышается, и в дальнейшем при хорошем проектировании для изменения политик не приходится привлекать разработчиков .

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

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

См. также

Примечания

↑ , p. 7.
, p. 1.
, p. 2.
, p. 11.
↑ .
, p. 4—5.
↑ .
↑ .
.
. Cisco Sistems (23 января 2014). Дата обращения: 27 февраля 2018. 10 декабря 2017 года.
. Банковское обозрение (25 июля 2016). Дата обращения: 27 февраля 2018. 10 декабря 2017 года.
.
. Cision PRWeb . Vocus PRW Holdings, LLC (18 октября 2016). Дата обращения: 27 февраля 2018. 12 марта 2018 года.

Литература

Daniel Servos, Sylvia L. Osborn. (англ.) . — University of Western Ontario.
Vincent C. Hu, etc. (англ.) . — National Institute of Standards and Technology, 2014. — P. 45. — doi : . 5 марта 2016 года.
William Fisher. (англ.) . — National Institute of Standards and Technology, 2015. — P. 22.
Alan H. Karp, etc. (англ.) . — HP Laboratories, 2009. — P. 21.
Bill Parducci, Hal Lockhart. (англ.) . — OASIS, 2017. — P. 154.
Xin Jin. (англ.) . — THE UNIVERSITY OF TEXAS AT SAN ANTONIO, 2014. — P. 144.