Реализация ABAC является более сложной, чем ACL / RBAC. Некоторые фреймворки даже дают вам немного инфраструктуры, чтобы справиться с последним. Если люди и активы могут быть сгруппированы по относительно небольшому и фиксированному количеству ролей / категорий, то, вероятно, лучше придерживаться ACL / RBAC. Если разрешения сильно различаются от человека к человеку, ABAC может предоставить лучшее и более гибкое решение.
Если вы решите пойти по пути ABAC, первое, что вам нужно сделать, это потратить некоторое время на чтение и понимание стандарта XACML . В примерах, приведенных в документе, используется XACML-совместимый синтаксис, и поначалу их немного сложно пережить. Я предполагаю, что вы не хотите реализовывать стандартное совместимое решение, поэтому вам нужны только общие идеи из него.
Концепции
XACML вращается вокруг 4 понятий и их атрибутов: предметы , действия , ресурсы и окружение . Есть еще несколько, но это самые важные. Все остальное построено поверх них. Если бы я сделал предложение с этими понятиями, это могло бы быть чем-то вроде: субъекты выполняют действия с ресурсами в определенной среде . Применение этого к вашему сценарию привело бы к чему-то вроде:
- Лесли открывает веб-страницу менеджера цен.
- Лесли создает цену поездки, используя веб-страницу менеджера цен.
Коллекция атрибутов
Первое, что нам нужно сделать, это собрать соответствующие атрибуты концепций, изложенных выше. В идеале не следует назначать какие-либо конкретные атрибуты, поскольку XACML пытается быть ненавязчивым и полагаться только на то, что система предоставляет естественным образом. И так имеем:
Тема
Любой актер, будь то человек или служба, в вашей системе. Наша тема - Лесли. Какие атрибуты необходимы для однозначной идентификации Лесли? Вероятно , некоторые из следующих условий : first name
, last name
, e-mail
, ssn
, company id
, position(s)
.
действие
Любое действие, выполняемое субъектами. Может быть стандартными операциями CRUD или чем-то более сложным. Наши действия есть open/view
и create
. Атрибуты для этих действий могут отличаться в зависимости от используемой платформы веб-приложения. Мы поговорим об этом подробнее, когда перейдем к ресурсу.
Ресурс
Довольно понятно. Наши ресурсы price manager page
, travel prices
и the newly created price
. Там может быть больше, если вы действительно хотите. Вы можете скрыть действия, которые пользователи не могут выполнить. Например. Это create price button
может быть ресурс, который можно показать / скрыть в зависимости от того, есть ли у пользователя разрешения на создание цен. Поскольку единственный способ для пользователя увидеть список цен может быть через эту страницу, вероятно, будет хорошей идеей обеспечить авторизацию на этом уровне, а не дальше вниз по стеку.
Доступ к ресурсам является наиболее сложным для реализации, особенно для тех, которые поступают из базы данных. Более тонкий вариант - безопасность на уровне строк. Некоторые базы данных имеют определенную степень поддержки для этого. Некоторые реализации XACML зашли так далеко, что создали надмножество SQL. Это действительно зависит от ваших потребностей в авторизации, но единственное, что вы не хотите делать, это взять все из таблицы и затем решить, что показать. Вы можете группировать ресурсы по наборам разрешений, абстрагировать их за API и применять авторизацию на конечных точках API.
Окружающая обстановка
Я не могу правильно определить его (XACML также не имеет правильного определения), но допустим, что это «пузырь», в котором все это происходит. Это включает в себя: web application
, web server
, operating system
, browser
, office
. Можно извлечь атрибуты , как: ip address
, time of day
, user locale
, user agent
, operating system version
. Вы можете использовать их даже для блокировки доступа пользователей из сред, которые не поддерживаются вашим приложением (например, старые браузеры, старые операционные системы, компьютеры вне вашей сети, доступ в нерабочее время).
Запрос авторизации
После того, как мы собрали все необходимые атрибуты, мы собрали их в запросе на авторизацию и направили его объекту, который может принимать решения об авторизации на основе значений этих атрибутов. В XACML lingua место, где вы собираете эти атрибуты и применяете решения, принятые затем, называется точкой реализации политики (PEP), а точка принятия решений называется точкой принятия политики (PDP). Местоположения, из которых получены значения атрибутов, называются информационными точками политики (PIP). PEP, PDP и PIP могут быть частью вашего приложения, они могут быть внешними системами. Вы можете найти схему их взаимодействия друг с другом в стандарте XACML.
Процесс принятия решения
Процесс принятия решений основан на правилах . Правила могут быть сгруппированы в политики, которые могут быть далее сгруппированы в наборы политик . У каждого из них есть цель . Цель используется для определения, применимо ли какое-либо из правил к запросу на авторизацию. Думайте об этом как о фильтре. Цель содержит условия, созданные с использованием имен и значений атрибутов. Например, правила для вашего приложения могут быть сгруппированы в нечто вроде:
Веб-приложение (набор политик)
| - target: application-name == "Веб-приложение"
`- Версия 1.0 (набор политик)
| - target: application-version == "1.0"
`- Просмотреть цену менеджера (политики)
| - target: web-page-name == "менеджер цен" && action-name == "view"
`- Лесли может просматривать цены менеджера (правило)
| - target: subject-name == "Лесли"
`- разрешение: разрешить
PDP будет сопоставлять все в указанном выше наборе со значениями атрибута в запросе авторизации. Что произойдет, если нет соответствующих правил, зависит от реализации вашего PDP. После того , как PDP принято решение ( allow
, deny
или not-applicable
) он посылает его обратно в PEP , который действует на него путем предоставления или отказа в доступе к ресурсу. Наряду с ответом PDP может отправить список obligations
и advices
что PEP должен или должен выполнить в процессе обеспечения соблюдения. В зависимости от того, как хранятся правила (текстовые файлы или база данных), администратор может использовать стандартный текстовый редактор или специальное приложение для редактирования, чтобы изменить их по своему усмотрению. Доступ к отменив Лесли менеджеру цен возобновится просто изменяя разрешение allow
наdeny
Пипл выполняет свою работу.
правоприменение
Это сильно зависит от вашего технологического стека. Некоторые веб-фреймворки имеют естественные точки исполнения (например, ASP.NET MVC имеет фильтры атрибутов). Ваши бизнес-уровни, возможно, должны определить такие точки принуждения. Я обнаружил, что проще применять принудительное применение на конечных точках обслуживания (например, на микросервисах) или на уровне пользовательского интерфейса.
Другие преимущества
Приятным побочным эффектом от реализации этого является то, что вы получаете довольно богатый контрольный журнал, который можно использовать для других целей.