Webov é služby a bezpečnosť 2

1. Webové služby a bezpečnosť 2 Doc. Ing. Ladislav Hudec, CSc. 1

2. Manažment identity • 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. • Identita entity formuje v SOA základ pre autorizáciu a dôveru. • Systém manažmentu identity (IDMS - Identity Management System) ako taký 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). • 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

3. Manažment identity Manažment dokladov Entita doklady identifikátor doklady Manažment identity atribúty Autentizácia Validácia atribútov z dokladov a iných zdrojov Manažment atribútov atribúty identifikátor Atribútová schéma atribúty Atribútová schéma Autorizácia Rozhodnutie o prístupe na základe atribútov a politík Manažment privilégií politiky Prehľad manažmentu identity 3

4. Manažment identity • Po autentizácii identity entity bod rozhodnutia politiky (PDP – Policy Decision Point) systému alebo zdroja, ku ktorému entita žiada prístup, musí stanoviť či novo-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í. • 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 – je to architektúra používaná väčšinou webových aplikácií na Internete. • 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

5. Manažment identity • 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 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 poskytovateľmi. • 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. • 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

6. 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í. 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ú službu. • 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 jednoduchú množinu webových služieb zabezpečujúcich manažment identity naprieč hraníc inštitúcií. • 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 – tieto služby sú poskytované lokálnymi poskytovateľmi identity, udeľujú tokeny autentizovaným používateľom a validujú tokeny predložené službou dôvery. 6

7. Manažment identity a webové služby • 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. • Autorizač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

8. Zriadenie dôvery medzi službami • 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

9. Zriadenie dôvery medzi službami • 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. • 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 (napríklad Kerberos token). Tradične 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 proxy, ktoré prekleňovalo hranice, alebo pomocou krížových certifikátov. 9

10. Zriadenie dôvery medzi službami • 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. WS-Federation dovoľuje federalizovať rôzne bezpečnostné oblasti (realms) definovaním sprostredkovateľov dôvery, ktorí validujú použitím WS-Trust bezpečnostné tokeny používané medzi webovými službami. • 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

11. Zriadenie dôvery medzi službami • 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. 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, aby WS-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 dôvery. 11

12. Opis politík webových služieb (WS-Policy) • 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 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 množinami tvrdení. • 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/) 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 tvrdenia: • 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

13. Opis politík webových služieb (WS-Policy) • 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 – š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é šifrovanie. 13

14. 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 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 potvrdenie. 14

15. 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

16. Opis politík webových služieb (WS-Policy) • 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ávySOAP 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é. • 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 špecifikácia definuje ako referencovať politiku z definícií WSDL, ako združiť politiky z rozmiestnených koncových bodov a ako združiť politiky s položkami UDDI. 16

17. Distribuovaný manažment autorizácie a prístupu • Vzhľadom na distribuovanú podstatu architektúry webových služieb je správaautorizá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) • RAdAC (Risk Adaptive Access Control) • 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 XACML pre hlavný a hierarchický RBAC profil umožňujúci podporovať RBAC v inštitúciach pomocou flexibilnej a platformovo nezávislej špecifikácie XACML. 17

18. Distribuovaný manažment autorizácie a prístupu • 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 (R) - sú zviazané so zdrojom ako je webová služba, systémová funkcia alebo údaje • 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

19. Distribuovaný manažment autorizácie a prístupu • 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 politiky (PDP – Policy Decision Point) použije atribútové tvrdenia, autentizačné 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: • Žiadateľ sa pokúša pristúpiť k zdroju a predloží autentizačné tvrdenie. • Bod presadzovania politiky (PEP – Policy Enforcement Point) posiela bodu PDP SAML žiadosť na rozhodnutie o autorizácii. • 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

20. Distribuovaný manažment autorizácie a prístupu Použitie SAML a XACML pri implementácii ABAC AA -Atribútová autorita 7 5 6 4 3 2 1 8 Tvrdenie o atribútoch žiadateľa Žiadateľ Vrátenie atribútového tvrdenia Tvrdenie o autentizácii žiadateľa Úložisko politík Žiadosť o prístup k zdroju Žiadosť o atribútové tvrdenie Žiadosť o politiku riadenia prístupu Vrátenie politiky riadenia prístupu Tvrdenie o autentizácii žiadateľa PEP - Bod presadzovania politiky Žiadosť o autorizačné rozhodnutie PDP – Bod rozhodnutia politiky Zdroj Vrátenie tvrdenia o aut. rozhod. Prístup k zdroju Tvrdenie o autorizač-nom rozhodnutí 20

21. Distribuovaný manažment autorizácie a prístupu • 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). • 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

22. Distribuovaný manažment autorizácie a prístupu Rozhodovací strom RAdAC Žiadosť Stanov úroveň rizika Stanov prevádzkové potreby Zodpovedá úroveň rizika politike? Áno Nie Existujú prevádzkové potreby? Sú potreby vyššie ako riziko? Áno Áno Nie Nie Prístup zamietnutý Prístup povolený 22

23. ĎAKUJEM ZA POZORNOSŤ 23