Attribute-Based Access Control (ABAC ) je model řízení přístupu k objektu založený na analýze pravidel pro atributy objektu nebo subjektu, možné operace s nimi a prostředí odpovídající požadavku [1] . Systémy řízení přístupu založené na atributech poskytují povinné a selektivní řízení přístupu . Uvažovaný typ řízení přístupu umožňuje vytvářet obrovské množství kombinací podmínek pro vyjádření různých politik.[ co? ] [1] .
Hlavními součástmi jakéhokoli mechanismu řízení přístupu jsou autentizace a autorizace uživatele . Přístup do firemní sítě nebo jejího majetku obvykle závisí na pozici zaměstnance. Účetní má například možnost zjistit jak všeobecnou účetní závěrku, tak konkrétní tržby, zatímco vedoucí prodeje má přístup pouze k těm druhým. Pokud zaměstnanec změní pozici nebo odejde, administrátor musí manuálně změnit jeho roli, aby mohl změnit přístupová práva, případně i napříč více systémy. Pro zjednodušení procesu změny práv v takových a složitějších případech potřebuje společnost flexibilnější přístup k řízení přístupu [2] .
Politika založená na atributech zefektivňuje řízení přístupu tím, že snižuje složitost regulačních požadavků. Stejné zásady založené na atributech lze použít na různých systémech. To pomáhá řídit konzistenci přístupu ke zdrojům v rámci stejné společnosti nebo mezi více partnery. Takové centralizované řízení přístupu předpokládá jediný autoritativní zdroj pro přístupová pravidla, takže není nutné kontrolovat soulad s požadavky každého konkrétního systému s jeho vlastní politikou [3] .
Vývojem modelu ABAC jsou modely založené na autentizaci ( angl. autheNtication-Based Access Control, NBAC ) a autorizaci ( angl. authoriZation-Based Access Control, ZBAC ), kde je zohledněn problém shody hodnot atributů účet a počet dohod mezi doménami je snížen, ale to vyžaduje určité změny ve zdrojových systémech [4] .
Poprvé byla kontrola přístupu aplikována na ministerstvu obrany USA v 60. a 70. letech 20. století a zahrnovala modely dobrovolného ( anglicky Discretionary Access Control, DAC ) a povinného přístupu ( anglicky Mandatory Access Control, MAC ) [5] .
S růstem sítí bylo nutné omezit přístup ke zvláště chráněným objektům. Takto se objevilo řízení přístupu založené na identitě (IBAC ) pomocí seznamů řízení přístupu . Každý předmět má svůj vlastní seznam. Pouze poskytnutím důkazu o svém oprávnění získá osoba přístup k objektu. Může mít různá oprávnění (pro čtení, zápis, úpravy, mazání a další). Vlastník objektu určuje dostupné operace pro každý subjekt. Subjekty tak mohou kvůli nutnosti ručního ovládání a případným neúspěšným revokacím přístupových práv neúmyslně získat více privilegií, než z nich vyplývá politika [5] .
Řešením mnoha problémů spojených s předchozími typy řízení přístupu je model RBAC ( Role-Based Access Control ) . V něm mají všechny role své vlastní sady oprávnění. Každému subjektu počítačového systému (například DBMS nebo operačnímu systému) je přiřazena jedna role, na rozdíl od případných reálných organizací, kde jich může mít uživatel několik. V době požadavku mechanismus řízení přístupu určuje roli a je povoleno provádět sadu operací, které jsou mu přiřazeny. Roli lze chápat jako atribut subjektu. S rozšířením modelu RBAC se řízení přístupu stalo centralizovanějším a není potřeba ACL [5] .
ACL a RBAC jsou speciální případy mechanismu ABAC, jehož hlavní myšlenkou je definovat řízení pomocí atributů entit zapojených do systému. U implementací ACL v rámci ABAC je atributem identita, u RBAC role. Hlavním rozdílem od těchto dvou modelů v ABAC je koncept politik vyjádřený prostřednictvím určitého souboru logických pravidel, která berou v úvahu nejrozmanitější vlastnosti objektu, subjektu a prostředí. Organizací systému pravidel se snižují mzdové náklady na zavedení nezbytných omezení přístupu. Navíc při úpravách stávajících politik v přístupových seznamech a vzoru je obtížnější zohlednit všechna místa, která vyžadují změny [6] .
Jedním z hlavních standardů pro řízení přístupu na základě atributů je XACML ( eXtensible Access Control Markup Language ) [5] [7] , původně vyvinutý v roce 2001 globálním konsorciem OASIS . Tato norma se zabývá regulací obecných bezpečnostních konceptů v systému, nikoli správou atributů, včetně přiřazení, modifikace, odstranění atd.
Hlavními pojmy v XACML jsou pravidla ( anglická pravidla ), zásady ( anglicky policy ), algoritmy pro kombinování pravidel a politik ( anglicky rule-combining-algorithms ), atributy ( anglické atributy ) (předmět, objekt, akce a podmínky prostředí), povinnosti ( anglické povinnosti ) a doporučení ( anglické rady ) [5] . Ústředním prvkem je pravidlo, které obsahuje cíl, účinek, podmínky, povinnosti a doporučení (poslední dvě nemusí být) [8] . Cílem je, jak subjekt očekává, že bude na objekt působit (číst, upravovat, mazat atd.). Účinek, který je určen systémem kontroly přístupu na základě výpočtu logického výrazu, může být buď povolení ( anglicky permit ), nebo odmítnutí ( anglicky deny ), nebo „nepoužije se“ ( anglicky neuplatňuje se ), popř. „nedefinováno“ ( anglicky ).indeterminate Rozhodnutí systému o nepoužitelnosti je učiněno v případě, kdy se logická podmínka ukáže jako „nepravdivá“. Pokud při vyhodnocování výrazu dojde k chybě, systém vrátí "undefined".
Příklad obchodního pravidla:
Obchodní pravidlo | |
---|---|
cílová | Zjistěte krevní skupinu ze zdravotní dokumentace pacienta |
Akce | dovolit |
Stav | Předmět. Pozice=doktor a středa. Čas >= 8:00 a středa. Čas <= 18:00 |
Závazek | Zobrazte datum revize (středa. Datum) chorobopisu v registru registru |
Obecnějším prvkem rámce řízení přístupu je politika. Kombinuje několik pravidel do jednoho systému propojeného určitými algoritmy. Tento systém společnost dodržuje. Nejglobálnější součástí modelu je soubor zásad. Existence této komponenty zachovává modularitu infrastruktury i na vyšších úrovních. Sada bezpečnostních politik je také spojena na základě několika algoritmů.
Zásady mohou být vyjádřeny v přirozeném jazyce ( NLP ), který je následně přeložen do strojově srozumitelné podoby . Ve velkých systémech z jedné organizace do druhé vyžaduje takový popis modelu zachování kompatibility existujících atributů. NLP je poté převedeno do digitálních politik ( angl. digital policies, DP ), které jsou sestaveny do strojového kódu pro provedení. Pro optimalizaci procesu sestavování může existovat několik digitálních zásad, které vyhovují různým modulům infrastruktury. Kromě těchto dvou typů reprezentace politik existují ještě tzv. metapolitika ( anglicky metapolicy, MP ), zodpovědné za regulaci, zpracování hierarchií, řešení konfliktů a validaci při sestavování digitálních politik [5] .
Samotná struktura řízení obchodního modelu ABAC se skládá ze 4 základních mechanismů, které jsou klíčovými uzly při implementaci politik [5] :
Další součástí správy politik může být Context Handler , který reguluje možné pořadí bezpečnostní politiky a hledání atributů. Může to být užitečné, když je důležitý čas zpracování nebo je možné, že dojde k selhání pro splnění požadavku v budoucnu. Handler také převádí rozhodnutí o autorizaci do strojového kódu [5] .
Tento příklad ilustruje zásady společnosti Medi Corp (název domény: med.example.com) [8] :
Любой пользователь с электронной почтой в пространстве имён med.example.com имеет право совершать любое действие на любом ресурсе.
XACML politika obsahuje hlavičkové informace ( angl. header ) (jmenné prostory, identifikátor, algoritmy pro jeho zpracování, popis), cíl ( angl. target ), pravidlo (obvykle několik) a je možný blok povinností.
<?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" Verze= "1.0" RuleCombiningAlgId= "identifier:rule-combining- algorithm:deny-overrides" > <Popis> Zásady řízení přístupu Medicorp </Description> <Target/> <Rule RuleId= "urn:oasis:names:tc:xacml:3.0:example:SimpleRule1" Effect= "Permit" > <Description> Jakýkoli předmět s názvem e-mailu v doméně med.example.com může provádět jakoukoli akci na libovolném zdroji. </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>Popis standardu XACML od verze 1.0 po současnou verzi 3.0 Plus s poznámkami ze dne 12. července 2017 a podrobnější příklady vytváření pravidel, zásad a zásad naleznete v bílých knihách OASIS na adrese www.oasis-open.org. množiny, kontextové požadavky a odpovědi [8] .
Vzhledem k tomu, že model RBAC ( Role-Based Access Control, RBAC ) se stále používá v mnoha počítačových systémech, je pak jako vylepšení a zobecnění použitelný také model řízení přístupu atributů ( anglicky Attribute -Based Access Control, ABAC ) . v mnoha oblastech IT oboru a podnikových systémů [7] [9] .
Produkt Cisco Enterprise Policy Manager podporuje výše popsané mechanismy PDP ( Policy Decision Point ) , PAP ( Policy Administration Point ) a PEP ( Policy Enforcement Point ) . Program zjednodušuje proces nasazení politik na celou infrastrukturu společnosti, integruje správu aplikačních politik, databází, konfiguračních informací a dalších komponent chráněných systémů [10] .
Uvažovaný model se používá také při návrhu architektury bezpečnostních systémů pro společnosti, ve kterých se počet uživatelů měří v tisících, respektive počet oprávnění je několikanásobně větší, existuje mnoho dynamicky řešených požadavků na systém a silné integrace částí společné infrastruktury. Mohou to být různé komerční organizace, banky, finanční trhy a další firmy a vládní podniky, které vyžadují provozní podporu při řízení přístupu a mají velkou základnu zaměstnanců, partnerů a zákazníků, kteří sdílejí přístup k datům. Implementaci řešení na bázi ABAC a hybridních bezpečnostních systémů ve velkých organizacích provádí ruská společnost Custis . Přestože zpřesňování vzoru v atributu obnáší hodně práce, zvyšuje se flexibilita řízení přístupu v případě přechodu a v budoucnu při dobrém návrhu není nutné zapojovat vývojáře do změn politik [11 ] .
Mnoho cloud computingu IaaS používá model založený na atributech. Zabezpečuje úložiště, sítě, výpočetní techniku a další součásti schématu IaaS. Příklady známých poskytovatelů zahrnují Amazon Web Service, OpenStack a další [12] .
Řízení přístupu typu atributu se také používá k ochraně velkých dat , například v produktu SmartGuard pro framework Hadoop od Axiomatics, který implementuje dynamickou autorizaci pro ochranu cenných dat [13] .