Читаючи про 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 мова, де ви збираєте ці атрибути та виконує рішення, прийняті тоді, називається точкою примусового виконання політики (PEP), а рішення, що приймають рішення, називається пунктом рішення щодо політики (PDP). Місця, з яких отримуються значення атрибутів, називаються інформаційними пунктами s (PIP). PEP, PDP і PIP можуть бути частиною вашого застосування, оскільки вони можуть бути зовнішніми системами. Ви можете знайти схему того, як вони спілкуються один з одним у стандарті XACML.

Процес прийняття рішення

Процес прийняття рішень заснований на правилах . Правила можуть бути згруповані в політики, які можна додатково згрупувати в набори політик . Кожен із них має ціль . Ціль використовується для визначення того, чи застосовується якесь із правил до запиту авторизації. Подумайте про це як про фільтр. Ціль містить умови, побудовані з використанням імен атрибутів та значень. Наприклад, правила вашої програми можна згрупувати у щось на зразок:

Веб-додаток (набір політик)
| - target: application-name == "Веб-додаток"
`- Версія 1.0 (набір політики)
    | - target: application-version == "1,0"
    `- Перегляд менеджера цін (політика)
        | - target: web-page-name == "менеджер цін" && action-name == "переглянути"
        `- Леслі може переглянути менеджер цін (правило)
            | - target: subject-name == "Леслі"
            `- дозвіл: дозволяти

PDP відповідатиме всім у вищенаведеному наборі проти значень атрибутів у запиті на авторизацію. Що станеться, якщо немає правил, які відповідають цьому, залежить від реалізації Вашого PDP. Після того , як PDP прийнято рішення ( allow, denyабо not-applicable) він посилає його назад в PEP , який діє на нього шляхом надання або відмови в доступі до ресурсу. Поряд з відповіддю, PDP може надіслати перелік obligationsта, advicesякий PEP повинен або повинен виконати в процесі примусового виконання. Залежно від того, як зберігаються правила (текстові файли чи база даних), адміністратор може використовувати стандартний текстовий редактор або спеціальну програму для редагування, щоб змінити їх так, як він вважає за потрібне. Скасування доступу Леслі до менеджера цін поновлюється просто змінюючи дозвіл allowнаdeny, наданий PEP виконує свою роботу.

Виконання

Це сильно залежить від вашої технології стеку. Деякі веб-рамки мають природні точки примусового виконання (наприклад, ASP.NET MVC має фільтри атрибутів). Можливо, ваші бізнес-шари повинні визначати такі точки примусового виконання. Мені було легше застосувати правозастосування на кінцевих точках обслуговування (думаю, мікросервіси) або на рівні інтерфейсу користувача.

Інші переваги

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