Novinky

ABAC, neboli Attribute-Based Access Control, představuje způsob řízení přístupu založený na vlastnostech subjektu, objektu a charakteristikách prostředí. Zjednodušeně řešeno, zkoumá kdo, kam a za jakých podmínek chce přistoupit nebo přistupuje.

Proč je vlastně tak zdánlivě složitý způsob řízení přístupu potřeba? Vezměme to popořádku.

Pokud si představíme historickou škálu způsobů řízení přístupu, najdeme zhruba níže uvedenou posloupnost vývoje. V nich jsme jako příklad použili naše „barové téma“, ve kterém potřebujeme kontrolovat věk návštěvníků.

• Programové řízení v aplikaci (MAC)
  • Přímo v aplikaci je nastaveno, kdo  smí co dělat
  • „Majitel baru zná všechny své hosty osobně a hlídá si vše sám“
• Základní řízení výčtem (ACL):
  • Ve zvláštním seznamu je uvedeno, kdo smí co dělat v jaké aplikaci
  • „Barman má seznam hostů, spolu s jejich věkem“
• Pokročilé řízení rolemi (RBAC):
  • Do aplikace smí jen ten, kdo má v nějakém důvěryhodném úložišti přidělenou roli
  • „Vyhazovač u vstupu kontroluje věk podle občanského průkazu“
• Komplexní řízení atributy (ABAC)
  • Vstup do aplikace je podmíněn správnou kombinací atributů
  • „Stroj u vstupu zkontroluje podle občanského průkazu věk a vydá jednorázový papírový náramek“

Každé z těchto řízení přístupů má zcela logicky i své nevýhody:

• U MAC a ACL je to nutnost manuální aktualizace informací
• RBAC se zde naopak jeví zdánlivě bezproblémový. Riziko RBACu je však ukryto jinde: cílová aplikace má spolu s informací o roli typicky přístup i k dalším datům uživatele, které už nepotřebuje.
  • V naší paralele tak může vyhazovač podle občanky zjistit adresu dotyčné blondýnky, a počkat si na ni po práci (jistě proto, aby ji vysvětlil výhody použití ABACu 🙂

A jak je to u ABACu?

ABAC uvedené nevýhody svých předchůdců překonává takto:

• Informace si bere přímo z autoritativního zdroje
• Pravidla se vyhodnotí v centrální rozhodovací části, ne v cílové aplikaci

Jak vidno, ABAC bere v potaz široké spektrum informací, z nichž některé – například prostředí – dnes běžně součástí řízení přístupu nejsou. Dobře se proto hodí i na RAdAC – řízení, které si všímá míry rizika aktuálního pokusu o přístup. Příkladem může být:

• Zaměstnanec se v práci přihlašuje pouze heslem
• Pokud však přistupuje vzdáleně nebo v noci, musí se přihlásit ještě certifikátem

Daleko lépe a přehledněji také implementuje bezpečnostní politiky přístupu, které jsou popsané pochopitelněji pro toho, kdo politiky tvoří.

Z popsaného však pramení i největší slabina tohoto řešení:

• Nejlépe funguje ve vyzrálé infrastruktuře.
  • Počítá se s tím, že potřebné atributy a procesy jsou funkční a k dispozici
• Příklad: Vzpomeňme na stroj zpracovávající občanky
  • Občanky musí být strojově čitelné
  • A informace v nich programově zpracovatelné

Teorie, nebo praxe?

Koncept ABACu vznikl v roce 2009 na půdě NIST (National Institute of Standards and Technology) jako doporučení jak zlepšit řízení přístupu napříč systémy federálních organizací (v USA). Aktuální snahy tvůrců vedou k šíření povědomí a formalizaci tohoto modelu přístupu. Velké změny v této souvislosti jsou očekávány v horizontu 2017-2019.

Jaký je současný stav používání řízení přístupu na základě atributů?

• Technicky je nejdál implementace ABACu v protokolu XACML (podpora v produktech od ForgeRock, WSO2, Oracle, IBM, Axiomatics)
• Současné implementace řízení přístupu (povětšinou RBAC) si již atributů v jisté míře z praktických důvodů všímají
  • Používá se navázání role na organizační strukturu, na další roli, na pozici vedoucího
• Budoucnost se proto zdá být v kombinaci těchto přístupů.
  • ABAC vhodně naváže tam, kde stávající způsob řízení končí
  • Například: RBAC rozděluje uživatele do rolí, informaci o roli následně využije ABAC pro řízení přístupu.
• Ve vzdálenější budoucnosti se pak můžeme těžit na evoluční rozvinutí v PBAC (Policy-based access control) a RAdAC (Risk-Adaptable Access Control)

Shrnutí

ABAC nabízí možnost detailního řízení přístupu na základě pravidel, aplikovaných na atributy entit, které se účastní přístupu, spolu s požadovanými akcemi a prostředím, ve kterém k přístupu dochází.

Výhody

• Komplexní politiky popsané jednoduchými pravidly
• Menší práce s implementací bezpečnostních politik
• Menší množství výjimek v pravidlech a z toho pramenících bezpečnostních incidentů (zapomenuté duše, neaktuální pravidla)
• Možnost posuzovat míru rizika přístupu

Nevýhody

• Implementace ABAC není moc rozšíření, přestože se situace pozvolna zlepšuje
• Spoléhá na dostatečně vyzrálou infrastrukturu – správné informace na správných místech –
• Neexistuje formální model (popis pravidel a vztahů a jejich hierarchií)

Bonus pro pozorné čtenáře

A jak že to bylo s tou blondýnou v úvodu článku? Inu, barman už od pohledu věděl, jaký vtip mu chce vyprávět. A tak by to v ABACu mělo být.

Autor: Petr Gašparík