KYBEZ

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.

Autor: Petr Gašparík pracuje posledních 5 let jako solution architect pro oblast řízení identit. Ve společnosti
AMI Praha působí 18. rokem a má za sebou řadu významných IT projektů pro zákazníky z komerční i veřejné
správy např. ČEZ ICT Services, Česká pošta, či Unicredit Bank Czech Republic and Slovakia.