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

то есть это изображение дает мне четкое представление о ACL и RBAC (как я могу продолжать и создавать таблицы базы данных на основе выше): (Изображение предоставлено пресс-книгами )

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

Начальный пример

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

Например, я хочу, чтобы человек Leslieимел доступ к веб-странице с именем Price Managerи разрешал ей управлять только ценами для Travelгруппы цен на этой странице, но не мог управлять ценами для Productгруппы на той же странице. Как бы я реализовать это с помощью ABAC?

Пока что, я думаю, я мог бы назначить Leslieнекоторые атрибуты (но какие из них и что это за атрибуты?) И затем создать таблицу базы данных, в которой они хранятся. Затем я могу разработать механизм, который смотрит на эти атрибуты (но не выглядит Leslieкак «Роль», как это делается в RBAC), и решает оттуда, предоставлять ли доступ к странице. Как будет выглядеть этот двигатель? Это простой блок if / else? Что-то другое?

Что произойдет, если Лесли позже изменит свою позицию, и кто-то должен изменить ее доступ? Как это будет выглядеть, если ей нужно Productотозвать доступ и отозвать его Travel? Как это будет закодировано, если ей нужно полностью отозвать доступ к Price Managerстранице и, следовательно, больше не иметь доступа ни к одному Travel, или Product?

Актив в моем случае, просто для повторения, есть Price Manager, и пользователь может получить доступ к различным ценовым группам на этой странице, таким как Travelценообразование, Productценообразование и т. Д.

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

Бонус: Является ли ABAC подходящим способом для относительно небольших потребностей в разрешениях, например, для управления 70-200 людьми и доступа к 150 - 450 активам? Будет ли лучше придерживаться ACL / RBAC вместо этого?

Реализация 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 имеет фильтры атрибутов). Ваши бизнес-уровни, возможно, должны определить такие точки принуждения. Я обнаружил, что проще применять принудительное применение на конечных точках обслуживания (например, на микросервисах) или на уровне пользовательского интерфейса.

Другие преимущества

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