Transcript prezentácia
Webové služby a bezpečnosť 2
Doc. Ing. Ladislav Hudec, CSc.
1
Manažment identity
o o o
Manažment identity pre SOA
. Obsahuje celú škálu udalostí súvisiacich s identitou entity: Informácie a dokumenty, pomocou ktorých je verifikovaná identita entity.
Vydávanie dokumentov identity entity a osobných dokumentov.
Autentizácia identity entít v miestach vstupu do SOA.
o o o
Identita entity formuje v SOA základ pre autorizáciu a dôveru.
Systém manažmentu identity (IDMS - Identity Management System)
je zodpovedný za verifikáciu identity entity, registráciu entít a vydávanie digitálnych identifikátorov entitám (viď nasledujúci obrázok).
ako taký Musí byť splnených viacero podmienok, aby bol občan (ľudská entita) registrovaný v registri občanov SR (register fyzických osôb).
Podobne to je aj s právnickými osobami a môžu byť iné požiadavky napríklad pre neziskové inštitúcie a súkromné podnikateľské subjekty.
Pre hráčov stávkových hier stačí na preukázanie identity platná emailová adresa a číslo bankového účtu, pre elektronický obchod stačí platná emailová adresa a číslo kreditnej karty.
Akonáhle bol entite vydaný digitálny identifikátor, môže byť tento identifikátor použitý v rámci inštitúcie spolu s ďalším informáciami o entite ako napríklad jej rola a autorizačné atribúty. Identifikátor sa môže stať časťou digitálnych dokladov, ktoré autorizujú entitu na prístup k rôznym zdrojom SOA.
Pri registrácii musí entita poskytnúť časť svojich dokladov, ktoré postačujú na autentizáciu identity. Samozrejme rôzne inštitúcie môžu mať rôzne politiky pre to, čo predstavuje postačujúce autentizačné doklady. Veľa sídiel e-obchodu vyžadujú od entít zadať meno a heslo, iné inštitúcie môžu od entity požadovať zaslanie certifikátu verejného kľúča podľa X.509. 2
Manažment identity
Entita doklady Autentizácia Validácia atribútov z dokladov a iných zdrojov atribúty Autorizácia Rozhodnutie o prístupe na základe atribútov a politík doklady Manažment dokladov atribúty identifikátor Manažment identity atribúty politiky Manažment atribútov identifikátor Atribútová schéma Manažment privilégií Atribútová schéma
Prehľad manažmentu identity
3
Manažment identity
o o o Po autentizácii identity entity novo-
bod rozhodnutia politiky
(PDP – Policy Decision Point) systému alebo zdroja, ku ktorému entita žiada prístup, musí stanoviť či autentizovaná entita je tiež autorizovaná na prístup k zdroju.
Na vykonanie autorizácie sa PDP spolieha na manažment privilégií a manažment atribútov.
Rozhodnutie politiky umožniť alebo odmietnuť prístup môže vychádzať z jednoduchého atribútu entity (napríklad atribútu roly) alebo môže vyžadovať kombináciu atribútov jemnej granularity (napríklad fyzické umiestnenie entity, aktuálnej aktívnej roly entity v systéme a úrovni oprávnení entity).
Systém manažmentu atribútov využíva digitálny identifikátor (vydaný IDMS) na uloženie a výber týchto atribútov entity, ktoré sú vyžadované politikou manažmentu privilégií.
o
Existujú tri významné architektúry manažmentu identity
, ktoré sú dostupné na používanie pri webových službách:
Izolovaný manažment identity
aplikácií na Internete.
– je to architektúra používaná väčšinou webových Poskytovatelia webových služieb fungujú aj ako poskytovatelia dokladov a aj poskytovatelia identity.
Zjednodušuje to manažment pre jedinú službu a vylučuje potrebu TTP (Trusted Third Party), aby vykonávala funkciu poskytovateľov alebo dokumentov.
Nevýhodou tejto architektúry je to, že každá služba musí poznať doklady a identifikátory všetkých autorizovaných žiadateľov. V prípade rozsiahlej SAO sa môže stať administrácia každého poskytovateľa nezvládnuteľná. 4
Manažment identity
o
Existujú tri významné architektúry manažmentu identity
:
Federatívny manažment identity
– skupina poskytovateľov súhlasí s tým, že si bude navzájom uznávať identifikátory používateľov.
Každý poskytovateľ služby funguje ako poskytovateľ dokumentov a identít pre podmnožinu žiadateľov.
Vydaním tvrdenia (napríklad poskytovateľmi.
autentizačné a atribútové tvrdenia SAML
) môže poskytovateľ služby vybaviť ostatných poskytovateľov nevyhnutnými informáciami o žiadateľovi bez požadovania, aby sa žiadateľ autentifikoval druhý krát. Toto zjednodušuje manažment identít a dokumentov pre SOA ako celku, ale vyžaduje individuálne služby dôvery tvrdení medzi V jednej SOA v rámci inštitúcii nemusí byť obtiažne pre jednotlivých poskytovateľov dôverovať jeden druhému, ale asi bude menšia vôľa dôverovať tvrdeniam v prípade, keď SOA zahrňuje poskytovateľov z rôznych inštitúcií. Žiadateľ v SOA môže dať požiadavku poskytovateľovi a zadať lubovoľné tvrdenie na získanie prístupu. Je dôležité mať politiku inštitúcie pre takýto typ údajov, ktoré prekračujú hranice SOA v inštitúcii.
o
Centralizovaný manažment identity
– poskytovatelia sa spoliehajú na jednu TTP, ktorá vybaví žiadateľov dokumentami a identifikátormi.
Je podobný na federatívny manažment identity v tom, že poskytovatelia dokladov a identity vystavia tvrdenia priamo poskytovateľom služieb umožňujúc tak žiadateľom prístup bez druhej autentizácia.
Individu álni poskytovatelia služieb potrebujú poznať iba poskytovateľa identity.
V SOA medzi inštitúciami by mali byť inštitúcie ochotné dôverovať v prvom rade poskytovateľom identity partnerskej inštitúcii (viac než ich jednotlivým ponúkaným službám).
Hlavným nedostatkom tejto architektúry je to, že poskytovatelia identity môžu fungovať ako jediné miesto poruchy (single point of failure). Napríklad v prípade útoku DoS na poskytovateľa identity nebude možné, aby poskytovateľ akceptoval akúkoľvek požiadavku. Pri vývoji nových alebo aktualizácii existujúcich SOA je potrebné brať do úvahy
veľkosť SOA
a priority inštitúcií. Niektoré z uvedených architektúr nemusia byť vhodné pre SOA určitej veľkosti a môžu byť v rozpore s politikou inštitúcie.
5
Manažment identity a webové služby
Webové služby poskytujú
štandardizovaný mechanizmus
na komunikáciu a zdieľanie informácií naprieč hraníc inštitúcií. službu.
Bezpečnostne akceptovateľné
webové služby naprieč inštitúcií vyžadujú spôsob na to, aby poskytovatelia bezpečne identifikovali a poskytovali služby oprávneným žiadateľom a spôsob pre žiadateľov, aby pomocou nevyhnutných dokladov bezpečne vyvolali webovú o o Bez rámca manažmentu identity je pre webové služby obťažné bezpečne identifikovať jedna druhú alebo predložiť uznateľné dokumenty.
Napríklad, inštitúcia A môže používať na identifikáciu webových služieb a jednotlivých používateľov certifikáty X.509, zatial čo inštitúcia B môže používať na identifikáciu tikety Kerbera. Ak žiadateľ z inštitúcii B pošle poskytovateľovi z inštitúcii A správu SAOP s tiketom Kerbera,
poskytovateľ nebude schopný autorizovať žiadateľa a prístup odmietne
.
Rámec manažmentu identity webových služieb abstrahuje túto informáciu a umožní webovým serverom bezpečne identifikovať jeden druhého bez ohľadu na použitú identifikačnú technológiu. Na realizáciu tejto úlohy stačí, aby inštitúcie mali
inštitúcií.
jednoduchú množinu webových služieb zabezpečujúcich manažment identity naprieč hraníc
o o Množina webových služieb na manažment identity naprieč hraníc inštitúcií obsahuje:
Služby dôvery
– tieto služby vydávajú a validujú autentizačné tokeny na používanie naprieč inštitúcií. Služby dôvery si tiež môžu vymieňať tieto tokeny s lokálnym poskytovateľom identity.
Autentizačné a validačné služby
poskytovateľmi identity, udeľujú tokeny autentizovaným používateľom a validujú tokeny predložené službou dôvery.
– tieto služby sú poskytované lokálnymi 6
Manažment identity a webové služby
o o o Množina webových služieb na manažment identity naprieč hraníc inštitúcií obsahuje:
Služby mapovania identity a atribútov
– často sú obsiahnuté v službách dôvery. Tieto služby mapujú zadané identifikačné informácie alebo atribúty do lokálnych ekvivalentov.
Služby manažmentu životného cyklu používateľa
– umožňujú zriadiť alebo mapovať identifikačné informácie a atribúty pre používateľa z inej inštitúcie.
Aut orizačné služby
– často implementované lokálne pre individuálne služby. Autorizačné služby môžu spracovať doklady poskytnuté odosielateľom, dopýtať sa odpovedajúcej bezpečnostnej politiky a určiť či odosielateľovi je dovolené vykonať požadovanú akciu.
Systémy manažmentu identity môžu poskytnúť tieto abstraktné služby v rôznych konfiguráciach, niektoré môžu byť explicitné webové služby a iné môžu byť poskytnuté implicitne.
7
Zriadenie dôvery medzi službami
o o o o o Aby SAML alebo WS Security boli užitočné vo veľkom rozsahu je potrebné, aby vzťah dôvery bol zriadený medzi vzdialenými webovými službami. Podpísané tvrdenia SAML alebo správy WS-Security sú nepoužiteľné, ak príjemca tvrdenia nie je schopný garantovať, že informácia v tvrdení je dôveryhodná.
V pôvodnej špecifikácii SAML sú diskutované iba vzťahy priamej dôvery – sú referencované ako
párové kruhy dôvery
(pairwise circles of trust).
Na druhej strane SAML v2.0 ponúka ďalšie modely dôvery SAML: sprostredkovanú (brokered) dôveru a komunitárnu (community) dôveru
Kruhy párovej dôvery
sú najtesnejšia a najpriamejšia forma vzťahu dôvery. Každá entita, ktorá je autorizovaná komunikovať s ďalšou entitou musí zdielať jej informácie o kľúči. Ak tvrdenie SAML môže byť v kruhu párovej dôvery verifikované, potom je verifikované autorizovanou entitou. Jednou z hlavných nevýhod párovej dôvery je fakt, že každá entita musí mať kópiu verejného kľúča od každej ďalšej entity, s ktorou komunikuje. Tento fakt vytvára systém inherentne neškálovateľný.
Model
sprostredkovanej dôvery
je rozšírením modelu párovej dôvery. Keď dve služby môžu komunikovať a nepoznajú navzájom svoje kľúče, na výmenu kľúčov sa použije TTP. Tento koncept umožňuje lepšie škálovanie než pri kruhu párovej dôvery, pretože pridanie poskytovateľa novej služby spôsobí iba výmenu kľúča novej služby s TTP. Poskytovatelia webových služieb musia veriť, že TTP nebola kompromitovaná. Toto odlišuje od párového modelu, v ktorom každý poskytovateľ služby je nezávisle zodpovedný za dôveru.
Ďalšou ťažkosťou v modeli sprostredkovanej dôvery je situácia, v ktorej dve služby môžu komunikovať s TTP ale nemôžu komunikovať navzájom medzi sebou. V modeli párovej dôvery tieto dve služby by nemali potrebné kľúče na vzájomnú komunikáciu. V modeli sprostredkovanej dôvery môžu obe služby komunikovať s TTP a teda tiež s ostatnými entitami. To znamená, že alebo TTP alebo jednotlivé entity musia vedieť, kto môže a kto nemôže s kým komunikovať.
8
Zriadenie dôvery medzi službami
o o Model
komunitárnej dôvery
sa pri zriadení dôvery spolieha na externú PKI. Tento model dôvery predpokladá, že PKI interfejsy sú implementované korektne a že žiadna certifikačná autorita nebola kompromitovaná. Tento model ponúka dôveru podobnú aká je v párovom modeli a škálovateľnosť aká je v sprostredkovanom modeli. Kľúč vzdialenej intity je podpísaný dôveryhodnou autoritou a teda je bezpečné s jeho použitím komunikovať. Musí však ale existovať mechanizmus zabraňujúci dvom entitám komunikovať v prípade, že je to proti politike (aj keď si navzájom poznajú kľúče). Tento mechanizmus je implementovaný v PKI alebo v jednotlivých entitách. Pridanie novej služby je jednoduché pridaním kľúča do PKI. o o Podpísané tvrdenia SAML majú tie isté bezpečnostné nedostatky ako každá technológia využívajúca kryptografiu verejného kľúča: privátny kľúč nesmie byť kompromitovaný.
Rámec federácie dôvery
poskytuje podporu pre všetky skorej vymenované modely dôvery bez ohľadu na to či webové služby potrebujú dôverovať jedna druhej v rámci jednej inštitúcie alebo naprieč hraníc viacerých inštitúcií.
Federácia dôvery
D ôvera v distribuovanom výpočtovom prostredí je zvyčajne verifikovaná pomocou
PKI certifikátov
(podpísaných dôveryhodnou certifikačnou autoritou) alebo predložením
zákazníckeho tokenu, ktorý je generovaný TTP
tieto mechanizmy dôvery fungujú dobre v rámci jednej inštitúcii. Pokiaľ zdieľanie informácií prekračuje hranice inštitúcii, entity navzájom komunikujúce nemusia nevyhnutne mať ten istý zdroj dôvery. Pred príchodom webových služieb bolo zdieľanie informácií naprieč inštitúciami riešené pomocou alebo pomocou
krížových certifikátov
.
(napríklad Kerberos token). Tradične
proxy
, ktoré prekleňovalo hranice, 9
Zriadenie dôvery medzi službami
o
Federácia dôvery
V SOA by mali webové služby z viacerých inštitúcií dôverovať jedna druhej bez vyžadovania rozsiahlejšej reštrukturalizácii prostredia dôvery. Vychádzajúc z tejto požiadavky, rámec federatívnej dôvery by mal byť konfigurovaný s využitím už existujúcich autentizačných mechanizmov v inštitúciách. Liberty Alliance poskytuje pre webové aplikácie a aj pre federáciu webových služieb
využívanie SAML na realizáciu sprostredkovania dôvery Trust
.
WS-Federation
dovoľuje federalizovať rôzne bezpečnostné oblasti (realms) definovaním sprostredkovateľov dôvery, ktorí validujú použitím bezpečnostné tokeny používané medzi webovými službami.
WS-
o o
WS-Federation a WS-Trust
Boli vyvinuté viacerými firmami (IBM, Microsoft, RSA, BEA), aby vytvorili systém federácie identity založený na
rozšírení WS-Security
, ktorá používa protokoly hlavných webových služieb SOAP a WSDL. WS-SecurityPolicy je rozšírením rámca WS-Policy, ktorý dovoľuje webovej službe definovať množinu detailných požiadaviek ako musia byť správy zabezpečené a aké tokeny sú webovou službou vyžadované. To využíva WS Trust na určenie, ktoré tokeny sú potrebné na interakciu s určitou webovou službou.
WS-Trust
je využitá na výmenu tokenov dôvery medzi webovými službami: WS Trust je rozšírením WS-Security.
WS Trust poskytuje metódy na vydanie, obnovu a validáciu bezpečnostných tokenov a metód na zriadenie a sprostredkovanie vzťahov dôvery medzi webovými službami. Ak žiadateľ nezadá vhodnú žiadosť, môže použiť bezpečnostnú politiku deklarovanú vo WS SecurityPolicy stanovujúcu URI poskytovateľa so službou bezpečnostných tokenov (STS Security Token Service), kde je daná informácia a kde zistí aká žiadosť je vhodná.
Navyše, WS-Trust podporuje výmeny s viacerými správami, ktoré dovoľujú poskytovateľom použiť na autorizáciu mechanizmus výzvy a odpovede.
Pretože WS-Trust je vystavaná nad WS-Security, žiadosťou môže byť čokoľvek od digitálneho podpisu po certifikát X.509 alebo token na báze XML ako je SAML tvrdenie. 10
Zriadenie dôvery medzi službami
o
WS-Federation a WS-Trust
WS Federation rozširuje WS-Trust.
WS Federation je rozšírená rôznymi protokolmi, pomocou ktorých STS (zameniteľne nazývaná poskytovateľ identity vo WS-Federation), žiadatelia a poskytovatelia môžu medzi sebou navzájom interagovať a pomocou ktorých umožňujú webovým službám dôverovať jedna druhej naprieč hraníc inštitúcií.
Každá inštitúcia je separátna oblasť dôvery (trust realm). WS-Federation umožňuje webovým službám komunikovať medzi viacerými oblasťami dôvery.
WS Federation ponúka dva profily na to, ako žiadatelia interagujú s poskytovateľmi a STS: aktívny a pasívny profil žiadateľa. aby WS dôvery.
Pasívny profil žiadateľa
udáva detail ako musia byť posielané správy medzi webovým browserom žiadateľa (klient om webovej služby), poskytovateľom, poskytovateľmi identity (IP – Identity Provider) a STS obidvoch inštitúcií tak, Federation mohla byť použitá v rámci kontextu webových aplikácií, poskytujúcich používateľom prax SSO (Single Sign On).
Aktívny profil žiadateľa
udáva detaily ako musia žiadatelia interagovať s poskytovateľom a IP/STS na prístup k poskytovateľovi v ďalšej oblasti 11
Opis politík webových služieb (WS-Policy)
o o
WSDL opisuje ako komunikovať s webovou službou.
WSDL udáva detaily protokolu väzby a formáty správy, ktoré webová služba očakáva. V mnohých prípadoch protokol väzby a formáty správy nie sú postačujúce pre žiadateľov na dynamickú väzbu s poskytovateľom.
WSDL je obmedzený na opis, čo by malo byť uložené v samotnej správe. Nešpecifikuje aký typ metadát by mal byť zadaný, ako bude správa autentizovaná alebo ktorá časť správy by mala byť podpísaná. K tomuto účelu bol vytvorený rámec
politiky webovej služby
(WS Policy), ktorý dovoľuje poskytovateľom vyjadriť možnosti, požiadavky a charakteristiky webovej služby.
WS Policy požiadavky môžu byť v rozsahu od špecifických on-the-wire požiadaviek takých ako požiadavka WS-Security šifrovanie alebo podpisovanie až po abstraktnejšie požiadavky ako sú QoS alebo požiadavky na privátnosť.
Vyjadrenie politiky
množinami tvrdení.
WS Policy vybavuje odosielateľa základnými metadátami pre plnú automatizáciu dynamickej väzby. Vyjadrenie politiky obsahuje množinu alternatív politiky spolu s o o o Tvrdenia (assertions) politiky sú definované pre množstvo WS-* špecifikácií vrátane WS-SecurityPolicy, WS-ReliableMessaging Policy Assertions (WS-RM) a WS-Addressing WSDL Binding. WS Policy Primer (dostupné na http://www.w3.org/ tvrdenia: ) definuje ako môžu byť tieto špecifikácie použité v rámci výrazov politiky. Existujú tri primárne (2007) špecifikácie definujúce WS-Policy
WS-SecurityPolicy
– definuje tvrdenia na špecifikáciu integrity, dôvernosti a informácií o bezpečnostných tokenoch.
WS-RM Policy
– definuje tvrdenia, ktoré môžu byť použité na špecifikáciu ako webové služby používajú WS-ReliableMessaging.
WS-Addressing WSDL Binding
– definuje elementy, ktoré môžu byť použité v rámci WSDL deskriptora na špecifikáciu použitia WS-Addressing. 12
Opis politík webových služieb (WS-Policy)
o o Na obrázku je
príklad vyjadrenia WS-Policy
Koreňové vyjadrenie v príklade je
All príznak
(tag), ktorý je použitý na špecifikáciu, že všetky obsahujúce vyjadrenia musí žiadateľ splniť, aby bol v súlade s politikou poskytovateľa. All príznak obsahuje tieto vyjadrenia:
wsap:UsingAddressing
– špecifikuje, že žiadatelia by mali zahrnúť do hlavičky SOAP informáciu WS-Addressing.
sp:TransportBinding
– špecifikuje, že žiadatelia by mali použiť TLS na zabezpečenie správy SOAP a definuje požadované parametre.
Element sp:TransportBinding obsahuje All príznak obsahujúci dve vyjadrenia:
sp:TransportToken
– špecifikuje, aký typ tokenu musí zadať odosielateľ. V tomto príklade sp:HttpsToken indikuje, že odosielateľ musí zadať prostredníctvom TLS klientsky certifikát .
sp:AlgorithmSuite
šifrovanie.
– špecifikuje, aký algoritmus knižnice TLS odosielateľa musí byť podporovaný. V tomto príklade sp:Basic256Sha256Rsa15, definovaný WS-SecurityPolicy, indikuje, že by mal byť použitý AES algoritmus s dĺžkou kľúča 256 bitov pre symetrické šifrovanie, 256 bitový algoritmus SHA na hašovanie a RSA v1.5 algoritmus pre asymetrické 13
Opis politík webových služieb (WS-Policy)
WS Policy môže byť tiež použitá na opis nevyhnutných parametrov pri používaní
WS-ReliableMessaging
potvrdenie.
s cieľom zaistiť dodanie správy. Na obrázku je politika definujúca časovú závoru 2 sekundy pri neaktívnosti, základný interval 5 sekúnd retransmisie pri použití exponenciálneho algoritmu backoff a interval 5 sekúnd na 14
Opis politík webových služieb (WS-Policy)
Príjemcovia majú voľbu špecifikácie, či odosielatelia by mali použiť TLS alebo WS Security na zabezpečenie správ SOAP. Niektorí príjemcovia si môžu priať rozhodnúť sa, ktorú voľbu budú podporovať. V takomto prípade by bolo použité
vyjadrenie ExactlyOne
na indikáciu voľby spôsobom podobným na obrázku.
15
Opis politík webových služieb (WS-Policy)
o Vyjadrenie ExactlyOne na predchádzajúcom obrázku obsahuje dve vyjadrenia majúce vzťah na zabezpečenie správ webovej služby medzi žiadateľom a poskytovateľom.
Odosielateľ si musí pri posielaní správy SOAP do tejto služby vybrať práve jednu z uvedených volieb:
sp:TransportBinding
– indikuje žiadateľovi, že môže použiť SSL/TLS na zabezpečenie správy
All
– obsahuje dve vyjadrenia WS-SecurityPolicy, ktoré musia byť dodržané pri používaní WS Security namiesto SSL/TLS:
sp:signedParts
– indikuje, že aj telo a aj hlavička SOAP správy musí byť podpísaná,
sp:EncryptionParts
– indikuje, že telo správy SOAP musí byť šifrované.
o o o o o Každé vyjadrenie politiky môže obsahovať: Vyjadrenie All, ExactlyOne alebo element vyjadrenia z gramatiky WS Policy ako sú WS Security, WS-RM alebo WS-Addressing.
Každé z týchto vyjadrení môže obsahovať ďalšie vyjadrenia Policy.
Táto úroveň flexibility dovoľuje poskytovateľovi kompletne špecifikovať požiadavky, ktoré musia byť žiadateľom splnené nad rámec požiadaviek daných v opise WSDL poskytovateľa.
Vyjadrenia politiky sú externé k metadátam uložených v UDDI a WSDL. To znamená, že poskytovatelia sa musia spoliehať na separátny mechanizmus distribúcie informácií WS-Policy: WS-MetadataExchange alebo WS PolicyAttachment.
WS-MetadataExchnge
špecifikácia definuje zapúzdrenie formátu pre metadáta webovej služby, mechanizmus na výmenu správ riadenú metadátami a opiera sa na špecifikáciu WS-Transfer pri zabezpečení koncového bodu webovej služby, z ktorého si žiadatelia môžu vybrať metadáta.
WS-PolicyAttachment
ako združiť politiky z rozmiestnených koncových bodov a ako združiť politiky s položkami UDDI.
špecifikácia definuje ako referencovať politiku z definícií WSDL, 16
Distribuovaný manažment autorizácie a prístupu
o o o Vzhľadom na distribuovanú podstatu architektúry webových služieb je správa autorizácie a dokladov riadenia prístupu používateľov v prostredí SOA netriviálny problém. V tejto časti budú uvedené opisy tradičných a pokročilých modelov a praktík použiteľných na uchopenie, spravovanie a presadzovanie rozhodnutí o riadení prístupu autorizovaných používateľov.
Najdôležitejšie modely
v správe prístupu v SOA sú: RBAC (Role Based Access Control) ABAC (Attribute Based Access Control) PBAC (Policy Based Access Control) o RAdAC (Risk Adaptive Access Control) o o o o o Autorizačný model
RBAC
: Je autorizačný mechanizmus, ktorý zväzuje množinu prístupových privilégií s určitou rolou, často korešpondujúcou s pracovnou pozíciou. Všetky prístupy používateľa sú sprostredkované prostredníctvom roly.
Zjednodušuje spravovanie bezpečnosti pomocou štruktúry hierarchie rolí.
Má rozsiahle možnosti na obmedzenie prístupu používateľa na základe administrátorom definovaných vzťahov. Táto vlastnosť umožňuje implementovať komplexné opatrenia ako napríklad separácia povinností.
Väčšina komerčne dostupných systémov RBAC je konformná s niektorým štandardom RBAC (NIST RBAC webová stránka).
Skupina OASIS poskytuje špecifikácie XACML.
XACML pre hlavný a hierarchický RBAC profil
umožňujúci podporovať RBAC v inštitúciach pomocou flexibilnej a platformovo nezávislej 17
Distribuovaný manažment autorizácie a prístupu
o o o o o Autorizačný model
RBAC
: RBAC na platforme webových služieb by mal byť implementovaný minimálne pre administrátorov, vývojárov a ostatné privilegované kontá, ktoré sú potrebné na prevádzku webovej služby. Platforma webovej služby musí byť konfigurovaná na presadzovanie separácie rolí (nedovoliť používateľovi pridelenému do jednej roly, aby vykonával funkcie výlučne pridelené inej role).
Privilégiá priradené každej roli by mali byť pridelené tak, aby zabezpečovali
najmenšie potrebné privilégiá
(least privilege) – každej role by mali byť pridelené iba minimálne privilégiá potrebné na vykonanie funkcií požadovaných rolou.
Väčšina dodávateľov implementuje vo svojich produktoch hlavných webových služieb niektorú formu RBAC. Inou alternatívou je implementovať alebo rozširovať RBAC na úrovni webových služieb, ktoré sú podporované mnohými bránami XML a dodávateľmi webových služieb.
Autorizačný model
ABAC
: Poskytuje mechanizmus na reprezentáciu prístupového profilu subjektu (používateľa alebo aplikácie) prostredníctvom kombinácie týchto atribútov:
Atribúty subjektu
(S) – sú zviazané so subjektom a definujú identitu a charakteristiky subjektu
Atribúty zdroja
údaje (R) sú zviazané so zdrojom ako je webová služba, systémová funkcia alebo
Atribúty prostredia
(E) – opisujú prevádzkové, technické alebo situačné prostredie alebo kontext, v ktorom sa vykonáva prístup k informácii.
Pravidlá politiky ABAC sú vytvárané ako Boolovské funkcie atribútov S, R a E a stanovujú či subjekt S môže pristúpiť k zdroju R v určitom prostredí E. Túto skutočnosť možno formálne zapísať vzťahom:
Rule X: can_access(s,r,e) ← f(ATTR(s), ATTR(r), ATTR(e))
18
Distribuovaný manažment autorizácie a prístupu
o o Autorizačný model
ABAC
: Prostredie SOA môže byť vo svojej podstate extrémne dynamické. Z tohto pohľadu má model ABAC zjavnú výhodu oproti modelu RBAC. Pravidlá politiky ABAC môžu byť zákaznicky orientované s ohľadom na
sémantický obsah
a sú významne flexibilnejšie ako RBAC pre jemnozrnné úpravy alebo nastavenia vo vzťahu k prístupovému profilu subjektu. ABAC sa bezproblémovo integruje s XACML, ktoré sa pri vykonaní rozhodnutia o riadení prístupu spolieha na atribúty definované politikou.
Ďalším prínosom ABAC pri jeho implementácii do webových služieb spočíva v jeho
voľnej definícii subjektu
. Pretože ABAC poskytuje flexibilitu pri pridelení pravidiel prístupu ľubovolnému aktorovi (subjektu), môže byť ABAC rozšírený aj na softvérových agentov webových služieb. Na nasledujúcom obrázku je ilustrácia ako môže byť
atribútová autorita
(AA) ABAC integrovaná do rámca SAML. Na tomto obrázku AA generuje atribútové tvrdenia, ktoré obsahujú všetky atribúty potrebné rozhodnutie o riadení prístupu vychádzajúce z politiky ABAC napísanej v XACML.
Bod rozhodnutia
(PDP – Policy Decision Point) použije
atribútové tvrdenia, autentizačné politiky tvrdenia a politiku XACML
na generovanie tvrdenia o autorizačnom rozhodnutí. Na obrázku je autentizačné tvrdenie žiadateľa vydané poskytovateľom identity ešte pred prístupom k zdroju. Tieto kroky opisujú ako SAML a XACML použijú atribúty žiadateľa na určenie či bude udelený prístup: 1.
Žiadateľ sa pokúša pristúpiť k zdroju a predloží autentizačné tvrdenie.
2.
Bod presadzovania politiky (PEP – Policy Enforcement Point) posiela bodu PDP SAML žiadosť na rozhodnutie o autorizácii.
3.
4.
5.
6.
7.
8.
PDP žiada určité atribútové tvrdenia, ktoré sú zviazané so žiadateľom.
AA vracia prííslušné atribútové tvrdenia.
PDP žiada politiku XACML z úložiska politík.
PDP prijíma politiku XACML.
Po dopýtaní politiky XACML, PDP posiela PEP tvrdenie o autorizačnom rozhodnutí.
Na základe tvrdenia o autorizačnom rozhodnutí, PDP udeľuje žiadateľovi prístup k zdroju. 19
Distribuovaný manažment autorizácie a prístupu
Žiadateľ Žiadosť o prístup k zdroju 1 Zdroj Tvrdenie o autentizácii žiadateľa 8 Prístup k zdroju PEP - Bod presadzovania politiky 2 AA Atribútová autorita 3 Žiadosť o atribútové tvrdenie Tvrdenie o Tvrdenie o atribútoch žiadateľa 4 Vrátenie atribútového tvrdenia Žiadosť o politiku riadenia prístupu 5 autentizácii žiadateľa Žiadosť o autorizačné rozhodnutie Vrátenie tvrdenia o aut. rozhod.
Tvrdenie o autorizač nom rozhodnutí 7 PDP – Bod rozhodnutia politiky Úložisko politík 6 Vrátenie politiky riadenia prístupu Použitie SAML a XACML pri implementácii ABAC 20
Distribuovaný manažment autorizácie a prístupu
o o o Autorizačný model
PBAC
: Tento model je logickým a v niečom ohraničeným rozšírením modelu ABAC. Je užitočný pri presadzovaní striktných politík riadenia prístupu na úrovni prostredia.
PBAC zavádza pojem autority politiky, ktorá slúži ako bod rozhodovania o prístupe v predmetnom prostredí.
PBAC znižuje granulárne funkcie pravidiel politiky, ktoré sú charakteristické pre ABAC. PBAC sa sústreďuje viac na automatizované presadzovanie povinného riadenia prístupu MAC (Mandatory Access Control), ktoré je tradične omnoho viac ohraničené ako voliteľné riadenie prístupu DAC (Discretionary Access Control).
o o Autorizačný model
RAdAC
: Tento model je ďalším variantom tradičných metód riadenia prístupu. Na rozdiel od RBAC, ABAC a PBAC sa v modeli RAdAC vykonáva rozhodnutie o riadení prístupu na základe profilu relatívneho rizika pristupujúceho subjektu a nie nevyhnutne prísne na základe preddefinovaných pravidiel politiky. Na obrázku je logika procesu určujúca RAdAC, ktorá využíva kombináciu merateľnej úrovne rizika, ktorému je pristupujúci subjekt vystavený, a ohodnotenie prevádzkových potrieb ako primárnych atribútov, pomocou ktorých sú určené prístupové práva subjektu.
RAdAC ako politikou riadený mechanizmus je zdanlivo abstrakciou PBAC. Na rozdiel od PBAC rámec RAdAC vyžaduje väzbu na zdroje, ktoré sú schopné pri každej žiadosti o autentizáciu (a prístup) poskytnúť v reálnom čase informácie týkajúce sa situácie, na základe ktorých je možné ohodnotiť riziko.
21
Distribuovaný manažment autorizácie a prístupu
Žiadosť Stanov úroveň rizika Stanov prevádzkové potreby Nie Zodpovedá úroveň rizika politike?
Áno Existujú prevádzkové potreby?
Nie Prístup zamietnutý Áno Sú potreby vyššie ako riziko?
Nie Rozhodovací strom RAdAC Áno Prístup povolený 22
ĎAKUJEM ZA POZORNOSŤ
23