Ve třetím díle jsme se seznámili v rámci role managementu s možnostmi, jak lze uživateli přidělovat oprávnění, a ukázali si, jak zkrotit nekontrolované kumulování oprávnění. V druhé části jsme se pak věnovali pokročilým funkcím identity managementu. Prošli jsme řízení licencí, časově omezené role, delegaci privilegovaných úloh, eskalaci v řízení oprávnění a vazbu na helpdeskový systém.

V tomto díle na tyto oblasti navážeme dvěma kapitolami, které s řízením identit souvisí: access management jako aktivní prvek vyhodnocování žádostí o přístup k systémům, a řízení správy SSH klíčů pro lepší management uživatelů linuxových systémů.

Access Management

Access management zajišťuje bezpečný přístup uživatele k informačnímu systému. Věnovat se zde budeme těmto kapitolám:

• AM v kontextu IdM – jak zapadá do již vyřčeného?
• Autentizace a autorizace – co to je a k čemu to je.
• Single Sign-On (a Off) – pro uživatelský komfort a bezpečnost.
• Federace – když si servery rozumějí.
• BYOID – aneb když si uživatel přinese digitální identitu s sebou.
• Bezpečnostní hledisko – jaké jsou hrozby.
• RAdAC – a jak jim čelit.

Access Management v kontextu IdM

Jak zapadá access management do celého kolečka identity managementu? Na začátku nám řízení identit založilo identitu, následně řízení rolí umožnilo, aby si uživatel mohl o přístup zažádat, poté řízení oprávnění zajistilo schválení žádosti a řízení přihlášení doplnilo potřebné autentizační a autorizační údaje. Na access managementu nyní je, aby tato data byla porovnána s aktuální žádostí uživatele o přístup k informačnímu systému. Děje se tak pomocí nástroje Access Manager, přes který požadavky na přístup typicky procházejí a zde také dochází k jejich vyhodnocování v reálném čase. Přehledně je toto znázorněno na následujícím obrázku.

Obrázek 1 – Access Management, princip

Oblast access managementu a identity managementu se souhrnně označuje jako Identity & Access Management (IAM).

Autentizace a autorizace

Autentizace představuje ověření uživatelské entity na základě předložených přihlašovacích údajů. Toto ověření může probíhat na základě více údajů, pak hovoříme o vícefaktorové autentizaci – MFA (Multi-Factor Authentication). Nejčastěji se takto setkáváme s dvoufaktorovou autentizací (TFA, Two-Factor Authentication), která v praxi nabývá formy hesla + nějakým způsobem předaný nezávislý kód (SMS, hardwarový token, kód z mobilní aplikace).

Příklad vícefaktorové autentizace: uživatel zadá do aplikace přihlašovací jméno a heslo a odešle formulář. Následně je mu doručeno na mobilní telefon jednorázové heslo (OTP, One-Time Password), které zadá na další stránce formuláře. Tím je uživatel ověřen z více pohledů a je zvýšena pravděpodobnost, že je skutečně tím, za koho se vydává.

Autorizace navazuje na autentizaci a zkoumá, zda má uživatel nárok na stránku/službu/operaci, kterou žádá. Obecně zda má přístupové právo ke zdroji. Pokud ano, je mu operace povolena, pokud ne, je o tomto nějakým způsobem informován – v případě webových stránek je to informace typu „Server vrátil chybu 401 – Neautorizovaný přístup“ [1].

Poznámka na závěr: mluvíme zde pro přiblížení o uživatelích, stejný princip ale platí i při automatizované komunikaci mezi systémy a službami.

Single Sign-On (a Off)

Mít více uživatelských účtů na různých systémech je dnes, zdá se, již nezbytnost. Avšak co nový účet, to nové heslo/PIN/kód. A proto byl pro zvýšení uživatelského komfortu v této oblasti navržen koncept jednotného přihlášení – Single Sign-On (SSO). Základní představa je taková, že uživatel se přihlásí proti jednomu zdroji (systému, službě) a na základě tohoto přihlášení je následně automaticky přihlašován do dalších zdrojů. Zdroj autentizace zde slouží jako garant správné autentizace uživatele

V prostředí webu se tento pojem označuje za Web SSO, a známe jej například z produktů firem Facebook či Google. Opakem Single Sign-On je jednotné odhlášení, Single Sign-Off. Tím je míněno automatické odhlášení ze všech spolupracujících aplikací po odhlášení od hlavního zdroje autentizace. Toto je důležitý bezpečnostní bod v řešeních, který ošetřuje situace, kdy například uživatel použije SSO do firemního webu v kavárně, kde je třeba se bezpečně odhlásit po skončení práce.

Federace

Na oblast SSO navazuje další pojem, který se objevuje v souvislosti s řízením přístupů – federace. Mějme případ, kdy existují dva na sobě nezávislé informační systémy, které autentizují uživatele (například web prodejce letenek a web rezervace hotelů). Nyní si představme, že chceme uživatele webu pro prodej letenek automaticky přihlásit do webu pro registraci v hotelech. Zmíněné SSO nám zde nestačí, oba weby jsou na stejné úrovni. Pomůže nám ale vytvoření důvěry mezi těmito dvěma servery (rezervace hotelů důvěřuje obchodu s letenkami v oblasti autentizace uživatele) a použití některého ze standardů, například SAML (standard pro výměnu informací o uživateli se zaměřením na autentizaci, autorizaci a uživatelské atributy). Nyní, když přijde uživatel na rezervaci hotelů, aplikace si vyžádá informaci, zda již není založen na prodeji letenek, a pokud ano, vytvoří uživateli automaticky účet. Zároveň mu již předvyplní rezervační formulář na datum příletu, protože mezi servery putují i informace o uživateli.

Tento koncept řešení se označuje jako federace domén, a nemusí nutně končit u dvou serverů. Ve zmíněném příkladu je tak možné do kruhu důvěry v rámci federace přidat web půjčovny automobilů, web turistických okružních jízd a další tematické weby, pro vyšší uživatelský komfort při cestování.

Obrázek 2 – Federace

BYOID

V překladu „Přines si svou vlastní identitu“ (Bring Your Own IDentity), tento termín označuje situaci, kdy se uživatel k informačnímu systému nebo službě hlásí identitou, kterou má založenou u jiného poskytovatele identit. Pojem tedy spadá jak pod federaci, tak pod Single Sign-On. V praxi se tento termín používá například při náboru nových zaměstnanců, kdy se kandidáti hlásí do Personálního portálu například Facebookem, nebo při zvyšování komfortu pro zákazníky na zákaznickém portálu firmy, kde se zákazníci vyhnou nutnosti registrace, pokud použijí například Google či Microsoft účet.

Bezpečnostní hledisko

Jako poslední kapitolku řízení přístupu si projdeme bezpečnostní hledisko. Ukázali jsme si, že máme možnost různé služby propojit jednotným přihlášením, což poskytuje uživatelský komfort, ale na druhou stranu zvyšuje riziko zneužití. Co když někdo ukradne identitu uživatele na poskytovateli identit? Má pak kvůli SSO náhle přístup k mnoha dalším službám. Jak jsme uvedli u vícefaktorové autentizace, můžeme se tomu bránit tím, že uživatele necháme zadávat další autentizační údaje – heslo, otisk prstu, kód z hardwarového tokenu, PIN, jednorázové heslo z generátoru, a navíc uživateli ještě omezíme platnost přihlášení na například 3 hodiny. To vše bezpečnost zvyšuje. Pokud však necháme například privilegovaného uživatele každé tři hodiny zadávat tři přihlašovací faktory stále dokola, získáme bezpečně přihlášeného, avšak nerudného administrátora.

Tomu se snaží zabránit relativně nový standard RAdAC.

RAdAC

Risk-Adaptable Access Control, neboli RAdAC, je pokročilý model řízení přístupu. Rozhodnutí o autorizaci (poskytnutí nebo zamítnutí požadavku na přístup k systému nebo službě) zde závisí na dynamickém posouzení rizik. Toto posouzení rizik nejenže rozhodne, zda uživatele pustit do systému, ale i za jakých podmínek se tak stane – jak se bude autentizovat, jaké parametry jako časové omezení bude přístup ke zdroji mít, a podobně. RAdAC lze takto použít na efektivní a bezpečné řízení privilegií. Technicky jej doplňuje implementace pomocí XACML protokolu.

Příklad použití RAdACu: v prostředí lokální sítě je administrátorovi umožněno hlásit se k informačnímu systému pomocí jména a hesla. Pokud však přistupuje z vnějšího prostředí, nebo mimo pracovní dobu, je vyžadována dvoufaktorová autentizace. Při přístupu mimo místní síť je navíc platnost jeho autentizace omezena na 3 hodiny.

Tímto jsme si v kostce probrali některé důležité body řízení přístupu, neboli access managementu. Přidruženou oblastí je i řízení přístupů na Linuxové či Unixové servery pomocí SSH klíčů, neboli key distribution management.

Key distribution management

Jak takové přihlášení pomocí SSH klíče vypadá, ilustruje následující obrázek. Protože se takto často přihlašují do serverové konzole uživatelé s administrátorskými právy, mluvíme zde o oblasti privilegovaných účtů.

Obrázek 3 – Princip přihlášení pomocí SSH klíče

Privilegovanému uživateli byl předem vygenerován pár klíčů – privátní a veřejná část. Kdokoli může veřejnou část použít, aby zašifroval zprávu, kterou pak lze přečíst (rozšifrovat) pouze pomocí privátní části. Tohoto principu se používá při přihlašování na zmíněné servery, kdy server šifruje data spojení pomocí veřejné části uživatele. Ten tak již nemusí znát své heslo, stačí mu vlastnit privátní klíč (ten je však většinou také chráněn heslem, kterému se říká passphrase, takže se jeho zadávání úplně nevyhne).

Aby toho bylo možno dosáhnout, je třeba distribuovat veřejné části klíče na ty servery, kam má mít uživatel přístup. A následně je opět smazat, pokud již uživateli přístup chceme odmítnout. A toto je úkolem správce distribuce klíčů, neboli Key distribution managera.

Jak může takový nástroj fungovat a podstatně zvýšit bezpečnost práce privilegovaných uživatelů, si ukážeme na příkladu reálného produktu [2]. Jeho srdcem je KDM server, který slouží k samotnému rozesílání SSH klíčů a prvotnímu ověřování uživatelů. Řešení používá třífaktorovou autentizaci (věnovali jsme se jí v tomto článku):

• něco, co uživatel zná (heslo k privátnímu klíči, čili passphrase a heslo k účtu na KDM serveru),
• něco, co má svého (privátní část SSH klíče)
• a něco, co znát nemůže (privátní část druhého SSH klíče, kterou obdrží od KDM serveru).

Uživatel zde k úspěšnému přihlášení potřebuje znát své přístupové údaje (jméno, heslo) – krok 1. Privátní část svého SSH klíče má uživatel u sebe, veřejnou již dříve nahrál na KDM server, aby mohla být distribuována na cílové servery.

Obrázek 4 – Key Distribution Manager, princip

KDM server vygeneruje nový pár SSH autentizačního klíče – privátní a veřejnou část. Privátní část zašle uživateli (krok 2), a obě veřejné části (uživatelovu i nově vygenerovanou) nahraje na cílový server (krok 3). Privátní části jsou tedy uloženy u uživatele, bezpečně v autentizačním agentovi, ze kterého si SSH klient tyto informace bere. Nyní pokaždé, když uživatel chce přistoupit na cílový server, proběhne autentizace pomocí obou privátních částí SSH autentizačního klíče (krok 4).

Napojení na Identity manager je nasnadě – stačí, když rozhodnutí o tom, zda KDM server pro (privilegovaného) uživatele nový pár SSH klíčů vydá či nikoli vyjde z informace, zda má uživatel přidělenou odpovídající roli v Identity manageru.

Závěrem

V dnešním, čtvrtém díle série jsme prošli dvě oblasti: Access management, který s řízením identit úzce souvisí, a řízení distribuce SSH klíčů pro uživatele linuxových systémů. Dozvěděli jsme se tak o autentizaci a autorizaci uživatelů, jednotném přihlašování a odhlašování – SSO, řešení pro sdílení identit mezi partnerskými systémy – federaci a s tím související BYOID, a bezpečnostních rizicích access managementu spolu s řešením v podobě standardu RAdAC.

V příštím díle celou sérii zakončíme. Nejprve se seznámíme s vybranými požadavky Kybernetického zákonu, které je možno realizovat pomocí nástrojů identity a access managementu, a ISO 27001. Následně se budeme věnovat technickým řešením pro Identity manager – jaké možnosti pro realizaci trh nabízí a jak se v nich zorientovat

Odkazy:

• [1] http://cs.wikipedia.org/wiki/Stavové_kódy_HTTP
• [2] http://www.ami-kdm.cz/

Autor: Petr Gašparík