Знакомство с XACML — стандартом для Attribute-Based Access Control

Евгений Мяченков, наш ведущий разработчик, опубликовал в корпоративном блоге на «Хабрахабре» статью, посвященную подходу Attribute-Based Access Control и стандарту XACML. Как бизнес-правила выражаются в виде политик? Из каких компонентов состоят системы безопасности? Какие интересные детали не вошли в стандарт? Ответы на эти вопросы — в материале «Знакомство с XACML — стандартом для Attribute-Based Access Control» на сайте.

Введение

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

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

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

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

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

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

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

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

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

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

Правило (rule)

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

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

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

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

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

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

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

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

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

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

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

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

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

Политика (policy)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Политика создания документа

   

2. Политика изменения документа

   

3. Политика удаления документа

   

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

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

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

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

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

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

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

Policy Administration Point

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

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

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

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

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

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

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

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

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

Policy Information Point

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

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

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

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

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

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

Policy Decision Point

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

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

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

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

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

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

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

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

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

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

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

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

Policy Enforcement Point

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

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

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

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

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

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

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

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

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

Пример

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

1. В каждом приложении существует своя уникальная бизнес-модель. Эта модель наполнена объектами, их атрибутами и т. п. Именно эти атрибуты являются источником данных для атрибутной модели системы контроля доступа.
2. На основе этой модели в PAP создаются политики и группы политик, использующих эти атрибуты.
3. Созданные в PAP политики и группы политик сохраняются в каком-нибудь хранилище, к которому будет обращаться PDP.
4. Когда пользователь (субъект) хочет выполнить какое-то действие, он выполняет соответствующие манипуляции с интерфейсом и тем самым посылает запрос на сервер приложений. На сервере приложений этот запрос попадает в логику приложения и, перед тем как попасть в бизнес-логику, проходит проверку на возможность выполнения.
5. Для этого встроенный в логику приложения PEP формирует запрос, помещает туда значения всех атрибутов из текущего контекста (пользователь, действие, объект и т. п.) и передает его в PDP.
6. PDP в первую очередь получает все политики и группы политик из хранилища.
7. Затем PDP отправляет запросы ко всем своим PIP с целью получения значений всех необходимых атрибутов, указанных в политиках и группах политик.
8. Каждый PIP, руководствуясь своей логикой, ищет значения указанного атрибута, используя для этого текущий контекст, который был передан PEP. Логика работы PIP может подразумевать получения значений из каких-либо хранилищ, используя для этого значения из контекста (как правило, в качестве ключевых значений искомых сущностей).
9. После этого PIP формирует ответ и передает его в PDP.
10. Основываясь на полученных данных, PDP вычисляет политики и группы политик, получает решение о предоставлении доступа и добавляет его в формирующийся ответ. Кроме того, PDP вычисляет связанные с политиками или группами политик обязательства и рекомендации и добавляет их к ответу.
11. Полученный ответ передается в PEP на исполнение.
12. PEP анализирует полученный ответ, исполняет обязательства и рекомендации и в случае принятия положительного решения передает вызов в бизнес-логику.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<?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>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Послесловие

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