Просмотр исходного текста страницы Знакомство с XACML — стандартом для Attribute-Based Access Control

<blockquote>''[[:Категория:Евгений Мяченков (Статьи)|Евгений Мяченков]], наш ведущий разработчик, опубликовал в&nbsp;корпоративном блоге на&nbsp;[http://habrahabr.ru/ «Хабрахабре»] статью, посвященную подходу Attribute-Based Access Control и&nbsp;стандарту XACML. Как бизнес-правила выражаются в&nbsp;виде политик? Из&nbsp;каких компонентов состоят системы безопасности? Какие интересные детали не&nbsp;вошли в&nbsp;стандарт? Ответы на&nbsp;эти вопросы&nbsp;— в&nbsp;материале [http://habrahabr.ru/company/custis/blog/258861/ «Знакомство с&nbsp;XACML&nbsp;— стандартом для&nbsp;Attribute-Based Access Control»] на&nbsp;сайте.''</blockquote>
==== Введение ====

В&nbsp;предыдущей статье мы рассказывали о&nbsp;том, что такое Attribute-Based Access Control и&nbsp;в&nbsp;чем его преимущества по&nbsp;сравнению с&nbsp;наиболее распространенным на&nbsp;сегодняшний день Role-Based Access Control. Пришло время рассмотреть ABAC более детально, через существующий стандарт под&nbsp;названием XACML.

Стандарт переживает уже третью и,&nbsp;скорее всего, не&nbsp;последнюю редакцию, история его ведет свой отсчет с&nbsp;2003 года. Курирует и&nbsp;поддерживает стандарт организация OASIS. Этот стандарт описывает необходимые компоненты системы, их&nbsp;назначение, способ их&nbsp;взаимодействия и&nbsp;использования. По&nbsp;сути, он охватывает все, что нужно, до&nbsp;мелочей.

В&nbsp;данной статье будут рассматриваться способ выражения бизнес-правил в&nbsp;виде политик, основные компоненты системы безопасности, ее интеграция и&nbsp;другие моменты, стандартом не&nbsp;затрагиваемые, но&nbsp;не&nbsp;менее важные и&nbsp;интересные. Приглашаю всех читателей познакомиться с&nbsp;этими вопросами подробнее. Также приветствуются любые замечания, комментарии, вопросы и&nbsp;критика.

Мы начнем разбор стандарта с&nbsp;обзора изменений бизнес-правил и&nbsp;продолжим обзором инструментов и&nbsp;способов обработки этих бизнес-правил.

==== Политики безопасности ====

Любое бизнес-правило, отвечающее за&nbsp;возможность совершения какого-либо действия или доступа к&nbsp;какому-либо объекту, отвечает на&nbsp;вопрос «Есть ли доступ?» и&nbsp;дает один из&nbsp;двух вариантов ответа: «Да» либо «Нет». А&nbsp;условие такого бизнес-правила сводится к&nbsp;набору логических выражений, вычисление которых и&nbsp;дает один из&nbsp;двух вариантов ответа.

Поэтому политики безопасности представляют собой логическое выражение, оперирующее атрибутами и&nbsp;константными значениями.

Начнем с&nbsp;пристального взгляда на&nbsp;сами политики безопасности и&nbsp;то, как их&nbsp;описывает стандарт.

[[Image:ABAC_1.jpg|thumb|550px|center]]

Хотя эта схема из&nbsp;стандарта может выглядеть немного устрашающе на&nbsp;первый взгляд, в&nbsp;ней все довольно просто. На&nbsp;картинке изображена иерархия основных объектов&nbsp;XACML, используемых для&nbsp;выражения бизнес-правил.

Самой элементарной частицей иерархии является правило (rule). Правила объединяются в&nbsp;политики (policy), которые, в&nbsp;свою очередь, объединяются в&nbsp;наборы политик (policy set).

===== Правило (rule) =====

Как описано в&nbsp;стандарте, правило не&nbsp;может жить само по&nbsp;себе, оно обязательно должно быть включено в&nbsp;политику. Это означает, что механизм вычисления прав доступа оперирует правилами только в&nbsp;составе политик и&nbsp;никак иначе. Тем не&nbsp;менее правило является наиболее насыщенным с&nbsp;точки зрения бизнес-смысла элементом.

Само правило состоит из&nbsp;нескольких частей:

* цель (target);
* эффект (effect);
* условие (condition);
* обязательства (obligation);
* рекомендации (advice).

Цель является одинаковой частью как для&nbsp;правил, так и&nbsp;для политик и&nbsp;групп политик. Поэтому описанное здесь верно и&nbsp;для них. Цель представляет собой логическое выражение, которое должно состоять только из&nbsp;атрибутов и&nbsp;констант. В&nbsp;цель обычно выносится та&nbsp;часть бизнес-правила, которая соответствует этому требованию. Основной смысл разделения бизнес-правила на&nbsp;части&nbsp;— более быстрое отсеивание неподходящих правил, политик или&nbsp;групп политик. Для чего это нужно&nbsp;— будет подробнее разобрано в&nbsp;описании&nbsp;PDP.

Оставшаяся часть бизнес-правила (если такая есть), содержащая более сложное, динамически вычисляемое логическое выражение, должна помещаться в&nbsp;другую часть правила&nbsp;— условие (condition). Те&nbsp;элементы, которые могут быть указаны в&nbsp;условии, их&nbsp;формат и&nbsp;все, что с&nbsp;ними связано, также детально расписаны в&nbsp;стандарте, но&nbsp;их&nbsp;разбор выходит за&nbsp;рамки данной статьи.

Бизнес-правила могут быть как разрешающими, так и&nbsp;запрещающими. Для указания этого в&nbsp;правиле существует еще одна часть&nbsp;— эффект (effect). Он&nbsp;может принимать значения «разрешить» (permit) или&nbsp;«запретить» (deny). Самое главное, что нужно знать: эффект правила срабатывает только в&nbsp;случае положительного вычисления (evaluate) этого правила. То&nbsp;есть эффект применяется только в&nbsp;случае, когда результатом вычисления логического условия в&nbsp;цели и&nbsp;в условии будет «истина» (true).

В&nbsp;случае, когда результатом вычисления логического выражения цели или условия является «ложь» (false), результатом оценки правила будет «не&nbsp;применимо» (not applicable). Если же в&nbsp;процессе вычисления логического условия цели или&nbsp;условия произошла ошибка, то&nbsp;результат оценки правила будет «не&nbsp;определен» (indeterminate). Таким образом, результатом вычисления правила может быть одно из&nbsp;четырех значений: «разрешить», «запретить», «не&nbsp;применимо», «не&nbsp;определено».

Рассмотрим пример формирования достаточно простого правила.

[[Image:ABAC_2.jpg|thumb|450px|center]]

Первое логическое условие представляет собой сравнение атрибута с&nbsp;константой, и&nbsp;его лучше поместить в&nbsp;цель правила (хотя возможно поместить и&nbsp;в&nbsp;условие). Второе логическое условие представляет собой сравнение двух атрибутов. Оно может быть помещено только в&nbsp;условие правила. Так как бизнес-правило разрешающее, эффект будет определен как «разрешить». В&nbsp;результате у&nbsp;нас получится такое правило:

[[Image:ABAC_3.jpg|thumb|450px|center]]

Помимо функции принятия решения о&nbsp;предоставлении прав доступа к&nbsp;системе безопасности могут предъявляться дополнительные функциональные требования. Примером такой функции может быть аудит безопасности. Именно для решения подобного рода проблем в&nbsp;стандарте существуют обязательства и&nbsp;рекомендации. По&nbsp;большому счету, разница между ними заключается только в&nbsp;том, что обязательства непременно нужно выполнять, а&nbsp;рекомендации можно проигнорировать.

И&nbsp;обязательства, и&nbsp;рекомендации описывают эффект правила, к&nbsp;которому они применимы, действие, которое необходимо выполнить, и&nbsp;выражения для&nbsp;получения параметров этого действия на&nbsp;основе текущего контекста.

Рассмотрим пример простого обязательства. Если существует требование к&nbsp;системе безопасности отправлять письмо владельцу объекта, когда кто-то взаимодействует с&nbsp;ним, то&nbsp;для&nbsp;этого можно сделать обязательство, которое будет выглядеть так:

[[Image:ABAC_4.jpg|thumb|450px|center]]

В&nbsp;качестве рекомендации, например, может быть указано описание действия логирования некоторой информации в&nbsp;целях отладки.

===== Политика (policy) =====

Политика используется для&nbsp;объединения набора правил. Обычно набор таких правил представляет собой одно бизнес-правило. Таким образом решается сразу несколько задач. Во-первых, небольшие части логических условий, выраженные в&nbsp;правилах, можно легко использовать повторно, без&nbsp;дублирования этих условий. Во-вторых, такое разделение на&nbsp;части облегчает понимание всего бизнес-правила и&nbsp;упрощает его сопровождение.

Политика состоит из:

* цели (target);
* правил (rules);
* алгоритма комбинации правил (rule-combine algorithm);
* обязательств (obligation);
* рекомендаций (advice).

Как уже было сказано ранее, цель нужна для быстрого отсеивания неподходящих политик. Для чего это нужно&nbsp;— будет рассмотрено далее, в&nbsp;рамках обзора&nbsp;PDP.

Набор правил просто перечисляет все входящие в&nbsp;данную политику правила.

Результатом вычисления политики является какое-то одно конкретное значение, как и&nbsp;в&nbsp;случае с&nbsp;правилами. Это значит, что&nbsp;из&nbsp;результатов оценки всех входящих в&nbsp;политику правил нужно получить всего лишь одно из&nbsp;четырех доступных значений. Чтобы получить такое значение из&nbsp;результатов вычисления всех правил, применяется заданный для&nbsp;политики алгоритм комбинации правил. Стандарт определяет несколько различных алгоритмов, которые могут пригодиться в&nbsp;различных ситуациях. Например, «запрещено, если не&nbsp;разрешено» (deny-unless-permit). Данный алгоритм вернет значение «разрешить» только в&nbsp;том случае, если результатом вычисления хотя&nbsp;бы одного правила является «разрешить». Если результатами оценки всех правил стал набор других значений («запретить», «не&nbsp;применимо», «не&nbsp;определено»), этот алгоритм комбинирования вернет «запретить».

В&nbsp;стандарте перечислены и&nbsp;куда более сложные алгоритмы комбинации, которые вводят дополнительные понятия результатов оценки правил. Таким примером может быть результат, звучащий как «не&nbsp;определено, но&nbsp;могло бы быть разрешено» (indeterminate{D}), который относится к&nbsp;тем правилам, во&nbsp;время оценки которых произошла ошибка, а&nbsp;их&nbsp;эффект в&nbsp;случае успешной оценки был бы «запретить».

Рассмотрим пример политики на&nbsp;основе простого бизнес-правила.

[[Image:ABAC_5.jpg|thumb|450px|center]]

Это бизнес-правило можно разбить на&nbsp;части и&nbsp;сформировать из&nbsp;него два простых правила, которые можно объединить в&nbsp;политику.

[[Image:ABAC_6.jpg|thumb|450px|center]]

Обязательства и&nbsp;рекомендации рассмотрены чуть выше, в&nbsp;описании правила.

===== Набор политик (policy set) =====

Набор политик нужен для&nbsp;объединения группы политик с&nbsp;целью их&nbsp;более быстрой фильтрации на&nbsp;основе общего назначения, задаваемого в&nbsp;цели группы политик. Он также может применяться при&nbsp;наличии крайне сложных бизнес-правил для дополнительного разделения на&nbsp;составные части. Набор политик по&nbsp;своим составным частям очень похож на&nbsp;обычную политику. Различия состоят только в&nbsp;том, что в&nbsp;случае с&nbsp;набором политик объединяются политики, а&nbsp;не&nbsp;правила, и&nbsp;в&nbsp;том, что стандарт предлагает несколько иной набор алгоритмов комбинации для&nbsp;политик, чем&nbsp;для&nbsp;правил.

Набор политик состоит&nbsp;из:

* цели (target);
* политик (policies);
* алгоритма комбинации политик (policy-combine algorithm);
* обязательств (obligation);
* рекомендаций (advice).

Единственное, что следует отметить,&nbsp;— в&nbsp;стандарте описаны как одинаковые, так&nbsp;и&nbsp;различные алгоритмы комбинации для&nbsp;политик и&nbsp;групп политик.

Давайте рассмотрим пример набора политик, используя для&nbsp;этого набор бизнес-правил.

[[Image:ABAC_7.jpg|thumb|450px|center]]

Из&nbsp;этих трех бизнес-правил будут сформированы три аналогичных политики.

# Политика создания документа
#: [[Image:ABAC_8.jpg|thumb|450px|center]]
# Политика изменения документа
#:[[Image:ABAC_9.jpg|thumb|450px|center]]
# Политика удаления документа
#:[[Image:ABAC_10.jpg|thumb|450px|center]]

У&nbsp;всех этих правил есть кое-что общее: они описывают доступность действий над&nbsp;одним и&nbsp;тем же типом объекта и&nbsp;к&nbsp;тому&nbsp;же&nbsp;— в&nbsp;определенное время. Поэтому мы можем с&nbsp;полной уверенностью объединить&nbsp;их в&nbsp;набор политик.

[[Image:ABAC_11.jpg|thumb|450px|center]]

Обязательства и&nbsp;рекомендации рассмотрены чуть выше, в&nbsp;описании правила.

Итак, мы выяснили, как&nbsp;стандарт предлагает превращать бизнес-правила в&nbsp;элементы, понятные системе безопасности. Теперь рассмотрим, из&nbsp;каких компонентов состоит сама система безопасности и&nbsp;как в&nbsp;ней обрабатываются эти бизнес-правила.

==== Основные компоненты системы ====

[[Image:ABAC_12.jpg|thumb|550px|center]]

Механизм вычисления политик является центральным компонентом системы и&nbsp;в&nbsp;стандарте именуется Policy Decision Point (PDP).

Для того, чтобы вычислять политики безопасности, их&nbsp;нужно где-то создать. За это отвечает другой компонент системы&nbsp;— механизм администрирования политик, в&nbsp;стандарте названный Policy Administration Point (PAP). Еще одним источником данных, необходимых PDP для&nbsp;вычислений, является источник значений атрибутов, называемый Policy Information Point (PIP).

Последним по&nbsp;списку&nbsp;— но не&nbsp;по&nbsp;значению&nbsp;— компонентом является механизм, отвечающий за&nbsp;вызов PDP и&nbsp;правильную обработку его ответа, который именуется Policy Enforcement Point (PEP).

===== Policy Administration Point =====

[[Image:ABAC_13.jpg|thumb|550px|center]]

Это компонент, в&nbsp;котором происходит управление политиками безопасности. Как правило, он&nbsp;представляет собой некий интерфейс, который позволяет администратору системы превращать бизнес-правила в&nbsp;политики безопасности и&nbsp;делать их&nbsp;доступными для&nbsp;PDP.

Для того, чтобы с&nbsp;помощью PAP можно было управлять политиками, ему нужно знать следующие вещи:

* структуру политик, чтобы уметь контролировать корректность ввода;
* список функций, которые можно указывать в&nbsp;логических условиях;
* список атрибутов, которые можно указывать в&nbsp;качестве аргументов функций в&nbsp;логических условиях.

Про структуру политик уже говорилось выше. Более детальное их описание приведено в&nbsp;стандарте.

Что касается функций, то&nbsp;некоторый их&nbsp;перечень уже описан в&nbsp;стандарте, как описана и&nbsp;логика их&nbsp;поведения. Кроме того, стандарт подразумевает возможность добавления своих произвольных функций. Поэтому при&nbsp;необходимости сформировать итоговый список функций, доступных для&nbsp;использования, часть этого списка, возможно, придется откуда-то получать.

Относительно атрибутов в&nbsp;стандарте тоже сказано немало. В&nbsp;основном затрагивается вопрос типизации и&nbsp;именования атрибутов. Сами же атрибуты, как правило, представляют собой что-то специфическое для&nbsp;бизнеса, поэтому для&nbsp;каждой системы этот список будет своим. Это означает, что система должна так или иначе уметь предоставлять нужную информацию. Неплохо также предоставлять информацию о&nbsp;том, какие значения могут быть доступны тем или&nbsp;иным атрибутам, чтобы иметь возможность проверять указанные в&nbsp;правилах константы.

Стоит помнить, что названиям атрибутов может потребоваться локализация. Это означает, что кроме названия атрибута и&nbsp;его типа нужно предоставлять еще и&nbsp;отображаемое название, которое можно локализовать. Это позволит отображать политики на&nbsp;разных языках без модификации самих политик.

С&nbsp;точки зрения системы безопасности PAP не&nbsp;играет какую-то ключевую роль. Но&nbsp;с&nbsp;точки зрения управления системой безопасности это одно из&nbsp;наиболее важных ее&nbsp;мест.

Сейчас мы затронули только назначение этого компонента. Его потенциальные возможности для&nbsp;управления системой безопасности мы рассмотрим позже.

===== Policy Information Point =====

[[Image:ABAC_14.jpg|thumb|550px|center]]

Как уже было сказано выше, для&nbsp;работы PDP необходимы две вещи: источник политик и&nbsp;источник значений атрибутов. О&nbsp;первом мы поговорили только что, а&nbsp;теперь поговорим о&nbsp;втором.

Принцип работы PIP, на&nbsp;первый взгляд, достаточно прост. На&nbsp;входе он&nbsp;получает название атрибута, а&nbsp;на&nbsp;выходе отдает все значения, которые может для&nbsp;него найти в&nbsp;текущем контексте выполнения. Вся сложность PIP заключается в&nbsp;его внутреннем устройстве, в&nbsp;том, как и&nbsp;где он умеет искать значения атрибутов.

Если система контроля доступа встроена в&nbsp;само приложение, и&nbsp;PIP умеет искать значения атрибутов среди текущих объектов приложения, то он может, например, транслировать название атрибута в&nbsp;путь до&nbsp;свойства объекта и&nbsp;извлекать значение этого свойства.

Если система контроля доступа расположена как отдельный сервис и&nbsp;принимает внешние вызовы, то&nbsp;PIP может уметь извлекать значения атрибутов из&nbsp;этого вызова.

Или же PIP может уметь извлекать такие текущие параметры среды, как время, дата, ip-адреса и&nbsp;т.&nbsp;п. Также PIP может уметь «ходить» в&nbsp;какое-либо хранилище и&nbsp;искать значения атрибутов там.

В&nbsp;целом, тут все ограничено только фантазией разработчиков системы контроля доступа.

===== Policy Decision Point =====

[[Image:ABAC_15.jpg|thumb|550px|center]]

Для системы контроля доступа это, пожалуй, центральный компонент.

Именно здесь происходит вычисление политик на&nbsp;основе текущего контекста вызова.

Очень важно понять, что PDP оперирует только атрибутами. Атрибут с&nbsp;точки зрения&nbsp;PDP&nbsp;— обычный ключ, по&nbsp;которому надо найти значение и&nbsp;подставить его в&nbsp;вычисляемое выражение. Он ничего не&nbsp;знает и&nbsp;не&nbsp;должен знать про&nbsp;то, что существуют действия, пользователи, среда, объекты. Понимание этого позволит правильно и&nbsp;с&nbsp;максимальной эффективностью использовать всю мощь системы контроля доступа.

Скорее всего, сразу может возникнуть вопрос: а&nbsp;как&nbsp;PDP понимает, какую политику безопасности ему надо вычислять в&nbsp;контексте текущего действия, если он&nbsp;не&nbsp;делает никакого различения? Ответ достаточно прост: никак. Он&nbsp;просто вычисляет все доступные ему политики безопасности и&nbsp;на&nbsp;основании этого формирует свое решение. Это может показаться безумной идеей хотя бы с&nbsp;точки зрения производительности, но&nbsp;если разобраться подробнее, все встает на&nbsp;свои места.

В&nbsp;первую очередь представляется ужасным процесс вычисления тысячи правил каждый раз при&nbsp;любой проверке прав доступа. Мыслить категориями тысяч заставляет тот факт, что в&nbsp;крупных системах число ролей обычно исчисляется такими порядками. Но&nbsp;политики&nbsp;— это не&nbsp;роли. Десятки хорошо продуманных политик способны заменить тысячи ролей. Так что мыслить тут&nbsp;нужно другими порядками. Кроме того, как уже упоминалось при&nbsp;рассмотрении структуры политик, предусмотренная в&nbsp;их&nbsp;структуре цель как раз предназначена для&nbsp;быстрой фильтрации не&nbsp;подходящих под&nbsp;текущий контекст политик. По&nbsp;факту вычисляться будут только единицы политик.

Вообще здесь могут быть применены различные способы оптимизации, что тоже зависит от&nbsp;обширности фантазии и&nbsp;ресурсов.

Для того, чтобы понять, какие политики применимы в&nbsp;данный момент, PDP&nbsp;должен вычислить цель каждой из&nbsp;них, подставив туда текущие значения указанных атрибутов. Для их&nbsp;поиска&nbsp;PDP использует PIP. Так как логика поиска в&nbsp;PIP может быть различной, одновременно может использоваться целая коллекция&nbsp;PIP, где каждый&nbsp;PIP будет искать значения указанного атрибута, руководствуясь своей логикой. PDP&nbsp;одновременно опрашивает все свои PIP для&nbsp;нахождения искомого атрибута, а&nbsp;из&nbsp;ответов формирует массив полученных значений. В&nbsp;стандарте все ориентировано на&nbsp;то, что для каждого атрибута может вернуться массив значений заранее не&nbsp;известного размера.

В&nbsp;случае, когда в&nbsp;текущем контексте вычислилось несколько политик или&nbsp;групп политик, результат их&nbsp;вычислений также комбинируется заранее заданным для&nbsp;PDP алгоритмом комбинации.

Наряду с&nbsp;другими элементами, у&nbsp;правил, политик или&nbsp;групп политик могут быть заданы обязательства или&nbsp;рекомендации. Они состоят из&nbsp;выражений, вычисляющих значения некоторых атрибутов, которые будут переданы PEP в&nbsp;составе ответа. И&nbsp;их&nbsp;вычисление может повлиять на&nbsp;результат вычисления самого правила, политики или&nbsp;группы политик.

Вычисляются только те&nbsp;обязательства и&nbsp;рекомендации, назначение которых совпадает с&nbsp;эффектом, полученным от&nbsp;вычисления их&nbsp;правила, политики или&nbsp;группы политик. Если вычисление значения атрибута обязательства или&nbsp;рекомендации закончилось неопределенным результатом, результат вычисления соответствующего правила, политики или&nbsp;группы политик также станет неопределенным.

Результатом всех вычислений должен стать ответ, содержащий в&nbsp;себе решение о&nbsp;предоставлении доступа, которое может принимать одно из&nbsp;четырех уже описанных выше значений: «разрешить», «запретить», «не&nbsp;применимо», «не&nbsp;определено».

Помимо этого, в&nbsp;ответе может содержаться список обязательств или&nbsp;рекомендаций. Следует отметить, что в&nbsp;стандарте описаны все условия, по&nbsp;которым должен формироваться итоговый список обязательств или&nbsp;рекомендаций.

===== Policy Enforcement Point =====

[[Image:ABAC_16.jpg|thumb|650px|center]]

PEP является и&nbsp;местом начала, и&nbsp;местом окончания всех действий по&nbsp;проверке прав доступа.

Обязанности PEP в&nbsp;качестве отправной точки включают в&nbsp;себя подготовку запроса и&nbsp;вызов&nbsp;PDP. По&nbsp;сути, PEP отвечает за&nbsp;передачу текущего контекста выполнения в&nbsp;PDP. Текущий контекст может включать в&nbsp;себя атрибуты, относящиеся к&nbsp;субъекту, выполняющему действие (имя, должность, отдел, филиал), к&nbsp;действию (название действия), к&nbsp;объекту действия (тип, номер, владелец), к&nbsp;среде (день недели, дата, ip-адрес). Все эти атрибуты собираются вместе и&nbsp;передаются в&nbsp;PDP.

В&nbsp;качестве финальной точки PEP отвечает за&nbsp;получение ответа от&nbsp;PDP, его трактовку и&nbsp;верное исполнение. Так как решение о&nbsp;предоставлении доступа может принимать одно из&nbsp;четырех значений, PEP должен уметь превращать их&nbsp;в&nbsp;два («разрешить» или&nbsp;«запретить»). В&nbsp;зависимости от&nbsp;алгоритма трактовки значений, PEP делится на&nbsp;два типа.

Разрешающий (Permit based) PEP действует по&nbsp;принципу «Разрешено все, что явно не&nbsp;запрещено». Это означает, что только в&nbsp;случае отрицательного решения будет запрещен доступ. В&nbsp;остальных трех случая доступ будет разрешен.

Запрещающий (Deny based) PEP действует по&nbsp;принципу «Запрещено все, что явно не&nbsp;разрешено». Это означает, что только в&nbsp;случае положительного решения доступ будет разрешен. В&nbsp;остальных трех случаях доступ будет запрещен.

Помимо решения о&nbsp;предоставлении доступа ответ от&nbsp;PDP может содержать список обязательств и&nbsp;рекомендаций, которые PEP должен исполнить.

Как уже было сказано выше, обязательства на&nbsp;то&nbsp;и&nbsp;обязательства, что применение их необходимо. И&nbsp;это накладывает отпечаток на&nbsp;исполнение решения, полученного от&nbsp;PDP.

Если PEP не&nbsp;понимает, как ему надо исполнить обязательство, то, в&nbsp;зависимости от&nbsp;типа&nbsp;PEP, это или отменит запрет, или отменит разрешение. Если PEP разрешающий, от&nbsp;PDP пришло решение «запретить», а&nbsp;выполнить обязательство невозможно, то&nbsp;PEP разрешит выполнение. Сработает так, как сработал бы в&nbsp;случае получения решения «не&nbsp;определено». И&nbsp;наоборот, если PEP запрещающий, значение решения, пришедшего от&nbsp;PDP,&nbsp;— «разрешить», а&nbsp;выполнить обязательство невозможно, PEP запретит выполнение. Сработает так, как будто решение от&nbsp;PDP было «не&nbsp;определено».

Рекомендации, в&nbsp;свою очередь, могут быть не&nbsp;выполнены, и&nbsp;это никак не&nbsp;повлияет на&nbsp;решение о&nbsp;предоставлении доступа.

===== Пример =====

Рассмотрим пример системы контроля доступа в&nbsp;случае с&nbsp;приложением, состоящим из&nbsp;клиента, сервера приложений и&nbsp;основных компонентов системы контроля доступа.

[[Image:ABAC_17.jpg|thumb|1050px|center]]

# В каждом приложении существует своя уникальная бизнес-модель. Эта модель наполнена объектами, их&nbsp;атрибутами и&nbsp;т.&nbsp;п. Именно эти атрибуты являются источником данных для&nbsp;атрибутной модели системы контроля доступа.
# На основе этой модели в&nbsp;PAP создаются политики и&nbsp;группы политик, использующих эти атрибуты.
# Созданные в&nbsp;PAP политики и&nbsp;группы политик сохраняются в&nbsp;каком-нибудь хранилище, к&nbsp;которому будет обращаться PDP.
# Когда пользователь (субъект) хочет выполнить какое-то действие, он выполняет соответствующие манипуляции с&nbsp;интерфейсом и&nbsp;тем&nbsp;самым посылает запрос на&nbsp;сервер приложений. На&nbsp;сервере приложений этот запрос попадает в&nbsp;логику приложения и, перед тем как попасть в&nbsp;бизнес-логику, проходит проверку на&nbsp;возможность выполнения.
# Для этого встроенный в&nbsp;логику приложения&nbsp;PEP формирует запрос, помещает туда значения всех атрибутов из&nbsp;текущего контекста (пользователь, действие, объект и т. п.) и&nbsp;передает его в&nbsp;PDP.
# PDP в&nbsp;первую очередь получает все политики и&nbsp;группы политик из&nbsp;хранилища.
# Затем PDP отправляет запросы ко&nbsp;всем своим PIP с&nbsp;целью получения значений всех необходимых атрибутов, указанных в&nbsp;политиках и&nbsp;группах политик.
# Каждый PIP, руководствуясь своей логикой, ищет значения указанного атрибута, используя для&nbsp;этого текущий контекст, который был передан PEP. Логика работы PIP может подразумевать получения значений из&nbsp;каких-либо хранилищ, используя для&nbsp;этого значения из&nbsp;контекста (как правило, в&nbsp;качестве ключевых значений искомых сущностей).
# После этого PIP формирует ответ и&nbsp;передает его в&nbsp;PDP.
# Основываясь на&nbsp;полученных данных, PDP вычисляет политики и&nbsp;группы политик, получает решение о&nbsp;предоставлении доступа и&nbsp;добавляет его в&nbsp;формирующийся ответ. Кроме того, PDP вычисляет связанные с&nbsp;политиками или группами политик обязательства и&nbsp;рекомендации и&nbsp;добавляет их&nbsp;к&nbsp;ответу.
# Полученный ответ передается в&nbsp;PEP на&nbsp;исполнение.
# PEP анализирует полученный ответ, исполняет обязательства и&nbsp;рекомендации и&nbsp;в&nbsp;случае принятия положительного решения передает вызов в&nbsp;бизнес-логику.

==== Что осталось за кадром ====

Так как стандарт покрывает все до&nbsp;мелочей, в&nbsp;этой статье были пропущены мелкие детали. В&nbsp;стандарте много внимания уделено описанию тех выражений, которые можно задавать в&nbsp;качестве условия правила. Какие функции должны быть? Какие типы данных могут быть? Как эти функции должны вычисляться? Какие бывают категории атрибутов? Какие бывают алгоритмы комбинации? Все это&nbsp;— детали, которые не&nbsp;должны влиять на&nbsp;понимание общей картины. Да и&nbsp;подробный их&nbsp;разбор уже мало относится к&nbsp;самому ABAC, скорее,&nbsp;— к&nbsp;техническим деталям реализации.

==== За пределами стандарта ====

Стандарт описывает многое, вплоть до&nbsp;мелких деталей, но&nbsp;некоторые моменты все равно остаются неосвещенными. Дальше хотелось бы затронуть эти интересные моменты и&nbsp;поговорить о&nbsp;них поподробнее.

==== Атрибут может быть любым ====

Хочется еще раз отметить, что атрибут может быть любым. Все разделения атрибутов на&nbsp;различные категории сделаны для&nbsp;более удобного восприятия людьми. PDP не&nbsp;отличает атрибут субъекта от&nbsp;атрибута объекта или&nbsp;атрибута действия. Название атрибута, его категория, владелец и&nbsp;т.&nbsp;п. для&nbsp;PDP являются всего лишь ключом, по&nbsp;которому нужно найти значения для&nbsp;неизвестной переменной в&nbsp;некотором логическом выражении.

Так что возможность использования в&nbsp;системе каких-либо атрибутов, по&nbsp;сути, ограничена лишь фантазией разработчиков и,&nbsp;вероятно, техническими ресурсами. Главное, чтобы какой-либо PIP умел возвращать значения для таких атрибутов.

Например, нередко могут встречаться бизнес-правила, в&nbsp;которых накладываются ограничения как на&nbsp;текущие значения атрибутов какой-либо сущности, так и&nbsp;на&nbsp;новые одновременно. Иными словами, при попытке внесения изменений в&nbsp;сущность нужно проверить значения изменяемых атрибутов до&nbsp;и&nbsp;после предполагаемого изменения. Такая проверка может быть встроена в&nbsp;логику приложения там, где мы знаем, какую сущность и&nbsp;какие ее атрибуты мы хотим изменить, на&nbsp;какие новые значения они будут меняться. Останется только создать специальный PIP, который будет уметь доставать старое или новое значение атрибута, основываясь, например, на&nbsp;префиксе в&nbsp;названии атрибута (old или&nbsp;new). Если старые значения сущности отсутствуют в&nbsp;текущем контексте, такой PIP может уметь доставать их&nbsp;из&nbsp;хранилища, основываясь на&nbsp;значениях ключевых атрибутов. Благо вся необходимая метаинформация в&nbsp;системе должна быть.

==== Интерфейс и проверка прав доступа ====

[[Image:ABAC_18.jpg|thumb|550px|center]]

Для удобства пользователя гораздо лучше не&nbsp;дать ему возможность выполнить какое-либо действие на&nbsp;интерфейсе, чем постфактум уведомить его о&nbsp;невозможности такого выполнения.

Если пользователь не&nbsp;может выполнить какое-либо действие, то&nbsp;неплохо бы дезактивировать на&nbsp;интерфейсе «запрещенные» элементы управления или вообще скрыть&nbsp;их.

Для этого можно также задействовать систему контроля доступа. Нужно будет передать в&nbsp;нее текущий контекст и, основываясь на&nbsp;полученном решении, понять, что стоит сделать с&nbsp;элементами управления.

==== Фильтрация данных ====

[[Image:ABAC_19.jpg|thumb|550px|center]]

Стандарт хорошо описывает возможность ограничения выполнения действия, используя для этого правила любой сложности. Но ничего не&nbsp;сказано по&nbsp;поводу решения задач, в&nbsp;которых нужно ограничивать доступ к&nbsp;просмотру части данных, то&nbsp;есть, по&nbsp;сути, фильтровать эти данные.

Решение этой задачи ложится на&nbsp;плечи разработчиков системы безопасности.

Если посмотреть на&nbsp;пример таких бизнес-правил, то&nbsp;видно, что они представляют собой такое же логическое выражение, как и&nbsp;бизнес-правила для&nbsp;доступа к&nbsp;объектам. Ну а&nbsp;раз&nbsp;это логическое выражение, то его можно использовать в&nbsp;качестве предиката для&nbsp;запроса данных.

Первое, что приходит на&nbsp;ум: обучение PDP формированию предиката из бизнес-правил для передачи его, например, в&nbsp;ORM, которая сможет использовать это для получения нужного списка данных.

Отличие от&nbsp;обычных политик будет в&nbsp;том, что политики, описывающие возможность совершения действия, вычисляются при наличии значения всех нужных атрибутов. В&nbsp;то&nbsp;время как значения всех атрибутов для политик, описывающих фильтрацию данных, будут известны только во&nbsp;время самой фильтрации и&nbsp;применения предиката к&nbsp;каждому конкретному объекту.

Конечно, делать из&nbsp;всех бизнес-правил предикат&nbsp;— чрезмерно и, в&nbsp;принципе, не&nbsp;обязательно, т.&nbsp;к. часть атрибутов все-таки известна перед формированием предиката. Значит, можно, как&nbsp;и&nbsp;в&nbsp;стандартном случае, отфильтровать часть бизнес-правил, оставив только необходимые.

Однако даже одна отобранная политика может быть достаточно большой. А&nbsp;учитывая&nbsp;то, что результат вычисления политики может принимать не&nbsp;два, а&nbsp;четыре значения, то, что PEP бывают как разрешающими, так&nbsp;и&nbsp;запрещающими, и&nbsp;то, что существуют различные алгоритмы комбинации, нужно понимать: из&nbsp;всего этого может сформироваться гигантский предикат. Такой предикат будет состоять из&nbsp;множества выражений, объединенных условными И&nbsp;и&nbsp;ИЛИ.

Эту проблему также можно попробовать решить в&nbsp;несколько этапов.

На&nbsp;первом этапе можно подставить в&nbsp;полученный предикат значения всех известных атрибутов и&nbsp;вычислить то, что получилось. Это может значительно сократить предикат, т.&nbsp;к.&nbsp;должны быть известны значения всех атрибутов, кроме атрибутов самого объекта.

На втором этапе можно попробовать упростить оставшийся предикат, используя минимизацию булевых функций, например, с помощью метода Куайна–Мак-Класки.

После этого предикат станет компактным настолько, насколько это возможно. А&nbsp;дальше все будет зависеть, к&nbsp;примеру, от&nbsp;возможности&nbsp;ORM сформировать запрос и&nbsp;возможности&nbsp;БД этот запрос обработать.

Так, например, бизнес-правило:

[[Image:ABAC_20.jpg|thumb|450px|center]]

Образует предикат:

[[Image:ABAC_21.jpg|thumb|450px|center]]

Этот предикат, после подстановки значений из&nbsp;контекста примет вид:

[[Image:ABAC_22.jpg|thumb|450px|center]]

После упрощения которого останется только:

[[Image:ABAC_23.jpg|thumb|450px|center]]

==== Концепция панели администратора ====

Как уже отмечалось выше, для&nbsp;системы контроля доступа панель администратора является наиболее важным компонентом. И&nbsp;это неудивительно. Помимо задачи создания и&nbsp;редактирования политик она может решать и&nbsp;ряд других, не&nbsp;менее важных проблем.

Начнем с&nbsp;редактирования политик. Если посмотреть на&nbsp;стандарт и&nbsp;на&nbsp;примеры политик, то&nbsp;становится видно, что даже достаточно простые бизнес-правила, написанные на&nbsp;XACML, сложны для понимания и&nbsp;модификации, особенно без подготовки. Даже имея определенную подготовку, изменять какое-либо более-менее сложное бизнес-правило в&nbsp;таком виде достаточно проблематично.

Пример очень простого правила в&nbsp;виде XACML:

<code-xml><?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></code-xml>

Поэтому, панель администратора может значительно облегчить жизнь пользователя в&nbsp;плане редактирования политик, если будет позволять задавать бизнес-правила в&nbsp;более простом виде. Который впоследствии сама будет превращать в&nbsp;XACML.

Также панель администратора может решать и&nbsp;ряд других не&nbsp;менее важных задач.

==== Редактирование политик ====

Удобный и&nbsp;продуманный интерфейс для&nbsp;редактирования политик играет важную роль в&nbsp;системе контроля доступа. Чем ближе к&nbsp;человеческому языку будут задаваться правила, тем лучше они будут управляться и&nbsp;поддерживаться. Интерфейс должен быть максимально прост, понятен и&nbsp;в&nbsp;то&nbsp;же время функционален.

Это может означать максимально возможный отказ от&nbsp;конструкций типа И,&nbsp;ИЛИ, а&nbsp;также выражений в&nbsp;скобках, явного указания типа атрибутов и&nbsp;т.&nbsp;п. Все, что можно вычислить или&nbsp;определить на&nbsp;основе метаинформации об&nbsp;атрибутах или&nbsp;структуры политики, можно и&nbsp;нужно убирать из&nbsp;интерфейса, оставляя лишь необходимый минимум для&nbsp;ввода бизнес-правил, который должен быть максимально приближен к&nbsp;человеческому языку.

Для&nbsp;удобства ввода можно применять технологии наподобие IntelliSense, удобные выпадающие списки, различные подсказки. Главная цель&nbsp;— создать интуитивно понятный и&nbsp;удобный интерфейс.

На&nbsp;концептуальном рисунке ниже изображено редактирование политики «Создание заказа». В&nbsp;верхней части окна указана цель&nbsp;— то, к&nbsp;чему будет применена данная политика. Дальше указан алгоритм комбинирования правил&nbsp;— «запрещено, если не&nbsp;разрешено». Ниже заданы три правила, состоящие из&nbsp;условий, которые будут проверяться, и&nbsp;эффекта, который будет результатом выполнения каждого правила.

[[Image:ABAC_24.jpg|thumb|550px|center]]

===== Редактирование набора политик =====

Как уже было сказано выше, наборы политик нужны для&nbsp;более удобного управления и&nbsp;фильтрации. В&nbsp;этом окне нет ничего особо примечательного, но&nbsp;забывать про&nbsp;его существование не&nbsp;стоит.

На&nbsp;концептуальном рисунке ниже, в&nbsp;левой части окна, изображен список уже созданных политик и&nbsp;наборов политик. Наборы политик могут быть вложенными. В&nbsp;правой части окна происходит само редактирование. Для&nbsp;набора политик можно также задавать цель&nbsp;— то, к&nbsp;чему будет применен весь набор. Ниже указан список того, что входит в&nbsp;набор. Еще ниже виден пример указания обязательства&nbsp;— действия по&nbsp;отправке e-mail-сообщения администратору в&nbsp;случае положительного решения о&nbsp;предоставлении прав доступа к&nbsp;объекту. Как видно из&nbsp;макета, для&nbsp;обязательств можно использовать существующие атрибуты, будь то имя пользователя или&nbsp;тип объекта. Это дает широкие возможности по&nbsp;использованию обязательств.

[[Image:ABAC_25.jpg|thumb|550px|center]]

===== Поиск политик =====

Одной из&nbsp;возникающих проблем может быть потребность в&nbsp;поиске политик или&nbsp;атрибутов, задействованных в&nbsp;них.

Можно сделать универсальное окно поиска, которое будет искать сразу в&nbsp;нескольких категориях, таких как цель, правила и&nbsp;политики.

Соответственно, без&nbsp;дополнительных указаний поиск будет происходить по&nbsp;всем категориям и&nbsp;предоставлять результат в&nbsp;виде, показанном на&nbsp;концептуальном рисунке ниже. В&nbsp;выведенных результатах будут подсвечены искомые слова и&nbsp;отображена та&nbsp;часть правила (цели), в&nbsp;которой встретился искомый текст.

[[Image:ABAC_26.jpg|thumb|550px|center]]

===== Действия, доступные в заданном контексте =====

Одной из&nbsp;важных задач системы контроля доступа является поиск доступных пользователю действий. Такой функционал может быть востребован сотрудниками службы безопасности или&nbsp;администраторами. Так как проверка прав доступа происходит динамически и&nbsp;заранее точно не&nbsp;известно, какие политики вычислятся положительно, отображение такой информации может показаться затруднительным. Но&nbsp;это&nbsp;не&nbsp;такая серьезная проблема, как кажется на&nbsp;первый взгляд. Ведь значения атрибутов пользователя у&nbsp;нас уже есть, и&nbsp;можно, как минимум, отобрать те&nbsp;политики, которые соответствуют этим значениям. Помимо этого, для&nbsp;более четкого понимания или&nbsp;более точного поиска можно задавать значения любых других интересующих атрибутов: указывать необходимый контекст или&nbsp;часть контекста и&nbsp;смотреть, что доступно для&nbsp;таких значений атрибутов. Более того, можно отобразить и&nbsp;те&nbsp;политики, которые подошли частично. Для них можно показать оставшиеся условия, необходимые для&nbsp;их&nbsp;выполнения.

[[Image:ABAC_27.jpg|thumb|550px|center]]

===== Тестирование выполнения политик =====

Еще одной немаловажной проблемой может быть непонимание, почему та&nbsp;или&nbsp;иная политика вычисляется именно так, а&nbsp;не&nbsp;иначе, несмотря на&nbsp;то&nbsp;что, по&nbsp;мнению администратора, все должно было выполниться по-другому.

Ситуация, когда политика задана, все атрибуты указаны правильно, а&nbsp;доступа все равно нет, может быть очень неприятной. Учитывая то, что политики или&nbsp;группы политик могут состоять из&nbsp;множества логических условий, ручной разбор этой проблемы может быть утомительным и&nbsp;чреват ошибками. Так как политики состоят из&nbsp;множества условий, которые вычисляются постепенно, процесс этого вычисления можно визуализировать. Администратор может указать нужный контекст, выбрать политики и&nbsp;пошагово изучить процесс вычисления, используя для&nbsp;этого удобный интерфейс.

[[Image:ABAC_28.jpg|thumb|550px|center]]

===== Интеграция с приложениями =====

Интеграция может выполняться как с&nbsp;существующими, так&nbsp;и&nbsp;с&nbsp;новыми приложениями.

Интеграция с&nbsp;новыми приложениями должна осуществляться довольно просто. Так как разработчики будут изначально знать про&nbsp;атрибутную модель, мыслить в&nbsp;ее&nbsp;понятиях, они смогут сразу разрабатывать все так, как нужно. Для того, чтобы все работало хорошо, необходимо реализовать две основные вещи. Во-первых, нужно, чтобы в&nbsp;системе существовала вся необходима метаинформация об&nbsp;атрибутах. Эта метаинформация может включать в&nbsp;себя название, тип, доступные значения, локализацию. Во-вторых, нужно, чтобы в&nbsp;приложении были правильно встроены PEP. Обычно PEP встраивается в&nbsp;логику приложения, где-либо перед вызовом бизнес-логики. Если хорошо наполнить систему метаинформацией и&nbsp;правильно разместить PEP, то&nbsp;при&nbsp;изменении бизнес-правил и,&nbsp;соответственно, политик никакое привлечение программистов не&nbsp;потребуется. Даже для&nbsp;заранее не&nbsp;известных и&nbsp;не&nbsp;запланированных бизнес-правил.

Интеграция с&nbsp;существующими приложениями может происходить по-разному. Большинство приложений сейчас используют ролевую, одномерную модель доступа и&nbsp;перейти на&nbsp;атрибутную, многомерную модель может быть непросто. Переход напрямую от&nbsp;ролевой модели к&nbsp;атрибутной может быть очень сложен, дорог или&nbsp;даже невозможен в&nbsp;силу ряда причин. Если такой переход все же возможен, то&nbsp;принцип действий будет таким же, как и&nbsp;для&nbsp;интеграции с&nbsp;нуля. Придется наполнять атрибутную модель метаинформацией и встраивать PEP во все необходимые места.

Если же такой переход невозможен, можно попробовать действовать в&nbsp;несколько этапов. На&nbsp;первом этапе нужно надстроить над&nbsp;ролевой моделью модель атрибутную. Смысл в&nbsp;том, что надстройка трансформирует ролевую модель в&nbsp;атрибутную, позволяя задавать бизнес-правила в&nbsp;атрибутном стиле и&nbsp;превращать ее обратно в&nbsp;ролевую модель. Да, поначалу это может показаться странным. Но&nbsp;такой подход может привнести ряд плюсов атрибутной модели и&nbsp;снять ряд минусов модели ролевой. А&nbsp;на&nbsp;втором этапе можно будет потихоньку, местами, отказываться от&nbsp;излишней прослойки в&nbsp;виде ролевой модели и&nbsp;полностью переходить на&nbsp;атрибутную модель.

Детальный разбор обоих случаев достаточно обширен и&nbsp;выходит за&nbsp;рамки текущей статьи.

==== Послесловие====

Надеюсь, введение в&nbsp;проблематику и&nbsp;знакомство со&nbsp;стандартом XACML поможет читателям повнимательнее присмотреться к&nbsp;ABAC и&nbsp;лучше понять принцип его работы, а&nbsp;моменты, затронутые вне&nbsp;стандарта, позволят учесть различные аспекты этой области, что сможет оказать поддержку при&nbsp;переходе на&nbsp;ABAC.

[[Категория:Евгений Мяченков (Статьи)]]
[[Категория:Хабрахабр (Публикации)]]
[[Категория:2015 год (Статьи)]]
[[Категория:CustisWikiToLib]]