SSO jako rámec řízeného přístupu
Organizace, která provozuje více informačních systémů, nepotřebuje pouze pohodlnější přihlašování. Potřebuje jednotný způsob, jak ověřovat identity, uplatňovat bezpečnostní pravidla, řídit přístupy a bez zbytečného odkladu reagovat na změnu role nebo ukončení spolupráce.
Single Sign-On umožňuje uživateli ověřit se u důvěryhodného poskytovatele identity a následně vstupovat do navazujících aplikací bez opakovaného zadávání samostatných přihlašovacích údajů. Cílová aplikace místo hesla přijímá ověřitelné tvrzení nebo token vydaný poskytovatelem identity. [1] [2]
SSO není pouze společná přihlašovací obrazovka. Jde o vztah důvěry mezi poskytovatelem identity a aplikacemi, které musí správně ověřit vydavatele, příjemce, integritu a platnost přijatého tvrzení.
SSO sjednocuje způsob ověření identity. Samo o sobě však neurčuje, jaké operace smí ověřený uživatel v cílové aplikaci provádět.
Centralizace autentizace může omezit množství samostatných hesel a vytvořit jednotné místo pro vícefaktorové ověření, pravidla podmíněného přístupu, kontrolu zařízení a vyhodnocování rizikových přihlášení. Současně zvyšuje význam zabezpečení a dostupnosti samotného poskytovatele identity.
Co přesně SSO řeší
V typickém federovaném modelu vystupují uživatel, poskytovatel identity a cílová aplikace. Každá strana má odlišnou odpovědnost.
Poskytovatel identity spravuje uživatelský účet a provádí nebo zprostředkovává autentizaci. Může vyžadovat vícefaktorové ověření, kontrolovat stav zařízení, zohlednit lokalitu nebo uplatnit další pravidla vycházející z bezpečnostní politiky organizace.
Cílová aplikace uživatelovo heslo přímo neposuzuje. Ověřuje digitálně podepsané tvrzení nebo token, kontroluje jeho původ, integritu, časovou platnost a skutečnost, že byl vydán právě pro tuto aplikaci.
Po úspěšném přihlášení si aplikace zpravidla vytváří vlastní relaci. Její délka může být odlišná od centrální relace u poskytovatele identity. Návrh proto musí řešit nejen přihlášení, ale také obnovování relace, opětovné ověření, odhlášení a předčasné zneplatnění přístupu.
Federace nepřenáší pouze informaci, že je uživatel přihlášen. Přenáší strukturovaná tvrzení s definovaným vydavatelem, příjemcem, dobou platnosti a dalšími bezpečnostními parametry.
SAML a OpenID Connect
SSO není jeden konkrétní protokol. V podnikových prostředích se nejčastěji používá SAML 2.0 nebo OpenID Connect.
SAML 2.0 používá XML assertions a je rozšířený zejména při propojování podnikových webových aplikací s centrálními adresářovými a identitními službami. Specifikace definuje strukturu tvrzení, autentizační informace, atributy a pravidla jejich zpracování. [2]
OpenID Connect je identitní vrstva nad autorizačním rámcem OAuth 2.0. Cílové aplikaci umožňuje ověřit identitu uživatele na základě autentizace provedené autorizačním serverem a získat standardizované informace ve formě claims. [1] [3]
Volba protokolu závisí na existující infrastruktuře, typu aplikace, podporovaných scénářích a požadavcích na správu relací. Moderní webové a mobilní aplikace často využívají OpenID Connect, zatímco řada podnikových systémů nadále pracuje se SAML.
Bez ohledu na zvolený protokol musí být jasně určeno, které strany si důvěřují, jak se spravují podpisové klíče, jaké atributy se předávají a jak se řeší změna konfigurace nebo kompromitace důvěryhodného vztahu.
Autentizace není autorizace
Bezpečně ověřená identita nemá automaticky získat přístup ke všem datům a funkcím cílového systému.
SSO odpovídá především na otázku, kdo se přihlašuje a jakým způsobem byla jeho identita ověřena. O tom, co smí uživatel po přihlášení provádět, rozhoduje autorizační model aplikace nebo navazující autorizační služba.
Skupiny a atributy z poskytovatele identity mohou autorizaci podpořit, ale jejich mapování na aplikační role musí být řízené, přezkoumatelné a pravidelně aktualizované.
Role, skupiny a životní cyklus identity
Přístupový model musí pokrývat nástup pracovníka, změnu jeho role, dočasné pověření i ukončení spolupráce.
Poskytovatel identity může předávat jméno, e-mailovou adresu, organizační jednotku, pracovní roli nebo členství ve skupinách. Každý atribut však vytváří požadavky na správnost, aktuálnost, ochranu a jednoznačné použití v cílové aplikaci.
Mapování centrální skupiny přímo na privilegovanou aplikační roli musí být řízeno stejně důsledně jako jiné přidělování administrátorských oprávnění. Chybná změna skupiny může jinak vytvořit přístup do více propojených aplikací současně.
Při změně pracovní pozice je nutné odebrat oprávnění spojená s původní rolí a přidělit pouze ta, která odpovídají nové odpovědnosti. Při odchodu musí být identita deaktivována a související přístupy zrušeny bez zbytečného odkladu.
Pro propojení účtů je obvykle vhodnější stabilní interní identifikátor než atribut, který se může měnit, například e-mailová adresa nebo zobrazované jméno.
Vícefaktorové a phishing-resistant ověření
SSO umožňuje soustředit autentizační požadavky do jednoho kontrolního bodu. Organizace může vícefaktorové ověření vyžadovat při každém přihlášení, pouze u citlivých aplikací nebo při zjištění zvýšeného rizika.
Centralizace současně zvyšuje dopad kompromitace hlavního účtu. Pokud útočník ovládne relaci u poskytovatele identity, může získat přístup k více propojeným službám. Síla autentizace proto musí odpovídat hodnotě chráněných dat a rozsahu navazujících oprávnění.
SSO snižuje počet samostatných přihlášení. Automaticky však nezaručuje odolnost proti phishingu, krádeži relace ani zneužití již ověřeného zařízení.
NIST rozlišuje běžné vícefaktorové metody od autentizačních protokolů odolných proti phishingu. Heslo doplněné jednorázovým kódem může bezpečnost zvýšit, ale nemusí zabránit útoku, při kterém falešná stránka přenáší přihlášení v reálném čase. [7]
WebAuthn používá kryptografické přihlašovací údaje vázané na konkrétní relying party. Soukromý klíč neopouští autentizátor a cílová služba ověřuje kryptografický důkaz vytvořený pro její doménu. [8]
Auditní stopa a dohledatelnost přihlášení
Centralizované přihlášení může vytvořit jednotnější zdroj informací o autentizačních událostech, použité metodě ověření a výsledku bezpečnostních pravidel.
Pro vyšetření incidentu je však nutné propojit záznamy poskytovatele identity s auditními záznamy cílové aplikace. Přihlášení samo neukazuje, jaká data uživatel následně zobrazil, změnil, schválil nebo exportoval.
Záznamy mají používat konzistentní identifikátory a synchronizovaný čas. Musí být chráněny před neoprávněnou změnou, uchovávány po definovanou dobu a dostupné pouze oprávněným pracovníkům.
Poskytovatel identity dokládá, jak byla identita ověřena. Aplikace dokládá, co tato identita po přihlášení provedla.
Relace, odhlášení a zneplatnění přístupu
Po federovaném přihlášení obvykle existuje centrální relace u poskytovatele identity a samostatná relace v každé navazující aplikaci. Odhlášení z jedné služby proto nemusí automaticky ukončit všechny ostatní relace.
Pro citlivé systémy je nutné stanovit maximální délku relace, dobu nečinnosti, podmínky opětovného ověření a reakci na změnu rizika. Zvláštní pravidla mohou platit pro administrátorské operace, export dat nebo změnu bezpečnostních nastavení. [6]
Provisioning není totéž co SSO
Federované přihlášení řeší ověření identity při vstupu do aplikace. Samo o sobě nemusí vytvářet, aktualizovat ani odstraňovat uživatelský účet v cílové službě.
Některé aplikace používají Just-in-Time provisioning, kdy je účet vytvořen při prvním úspěšném přihlášení. Tento přístup může zrychlit nasazení, ale nemusí dostatečně řešit změny atributů, správu skupin ani odstranění účtu bez dalšího přihlášení uživatele.
Pro automatizovanou správu životního cyklu identit lze použít SCIM. Ten definuje HTTP rozhraní pro vytváření, úpravu, vyhledávání a správu uživatelů a skupin napříč organizačními a cloudovými prostředími. [5]
Při ukončení spolupráce nestačí pouze zablokovat možnost nového přihlášení. Je nutné řešit existující relace, API tokeny, lokální účty, servisní přístupy a další oprávnění, která mohou fungovat nezávisle na interaktivním SSO.
Bezpečnost assertions a tokenů
Cílová aplikace musí ověřit podpis assertion nebo tokenu, důvěryhodnost vydavatele, určeného příjemce, časovou platnost a další parametry stanovené použitým protokolem.
Přijetí tokenu určeného jiné aplikaci může vést k záměně příjemce. Opětovné použití zachyceného tvrzení může způsobit replay útok. Důvěryhodný vztah proto musí zahrnovat omezení příjemce, ochranu proti opakovanému použití a správné ověřování všech relevantních podmínek. [4]
Kryptograficky podepsaný token je bezpečný pouze tehdy, když aplikace správně ověří nejen podpis, ale také jeho účel, vydavatele, příjemce a dobu platnosti.
Klíče používané k podepisování musí mít řízený životní cyklus. Aplikace musí bezpečně pracovat s jejich rotací a nesmí nekontrolovaně přijímat klíče nebo metadata z nedůvěryhodného zdroje.
Poskytovatel identity jako kritická závislost
Nedostupnost identity provideru může omezit přístup do více navazujících systémů současně.
Návrh proto musí zohlednit redundanci, obnovu, monitoring, správu konfigurace a postup při bezpečnostním incidentu. U kritických služeb je nutné předem určit, jak bude organizace postupovat při výpadku centrální identity nebo při podezření na kompromitaci podpisových klíčů.
Nouzové účty mají být omezené, důsledně chráněné a pravidelně testované. Nemají se stát běžnou cestou, která obchází centralizovaná bezpečnostní pravidla a oslabuje auditní dohledatelnost.
Součástí provozní připravenosti je také znalost závislostí. Organizace musí vědět, které aplikace používají konkrétního poskytovatele identity, jaké protokoly podporují a jak rychle lze změnit konfiguraci nebo zneplatnit důvěryhodný vztah.
Ochrana soukromí a minimalizace atributů
Federovaný přístup může mezi organizačními systémy přenášet osobní údaje a pracovní atributy. Organizace musí určit, které informace jsou pro konkrétní aplikaci nezbytné, za jakým účelem jsou používány a jak dlouho mají být uchovávány.
Cílová aplikace nemá automaticky získávat celý profil uživatele. Rozsah claims nebo SAML atributů má odpovídat skutečné potřebě. Je nutné rozlišovat údaje potřebné k autentizaci, údaje používané pro autorizaci a údaje sloužící pouze k uživatelskému komfortu.
SSO v prostředí Atodatu
Při integraci Atodatu do organizačního identitního prostředí je cílem navázat přístup na existující identity a bezpečnostní pravidla, nikoliv vytvářet další izolovaný svět uživatelských účtů.
Konkrétní integrační model závisí na poskytovateli identity, podporovaném protokolu, požadovaných atributech, životním cyklu účtů a způsobu, jakým se mají centrální skupiny promítnout do rolí v jednotlivých systémech.
Přihlášení představuje pouze první vrstvu. Atodat musí nadále řídit, jaké projekty, datové oblasti, operace a schvalovací kroky jsou konkrétní identitě dostupné. Federovaná identita proto vstupuje do lokálního modelu oprávnění, ale nenahrazuje jej.
Dobrá integrace SSO sjednocuje identitu. Dobrá autorizace zachovává přesnou kontrolu nad tím, co tato identita smí dělat.
Auditní stopa může spojovat centrální identifikátor uživatele s konkrétními změnami, přístupy a rozhodnutími uvnitř systému. To usnadňuje interní kontrolu, řešení incidentů a ověřování odpovědnosti.
Vztah k Zero Trust, GDPR a NIS2
SSO není náhradou architektury Zero Trust. Může však tvořit důležitou součást identity-centric přístupu, ve kterém se přístup neposuzuje pouze podle umístění v síti, ale také podle identity, stavu zařízení, kontextu a citlivosti požadované operace.
SSO stejně tak samo o sobě nezajišťuje soulad s GDPR nebo NIS2. Může však podpořit řízení přístupů, vícefaktorové ověření, dohledatelnost autentizačních událostí a rychlejší odebrání oprávnění při změně nebo ukončení pracovního vztahu.
Soulad závisí na celém souboru technických a organizačních opatření. Jednotné přihlášení je jednou vrstvou kontrolního prostředí, nikoliv jeho úplnou náhradou.
Co to znamená pro zákazníka Atodatu
Pro uživatele znamená SSO méně samostatných přihlašovacích údajů. Pro správce představuje jednotnější místo pro řízení autentizace a přehlednější životní cyklus přístupů.
Výsledná bezpečnost závisí na kvalitě poskytovatele identity, používaných autentizačních metodách, správném ověřování tokenů, lokálním modelu oprávnění a rychlosti, s jakou se změny identity projeví v navazujících systémech.
Přístup Atodatu je založený na tom, že identita, role a auditní stopa musí být propojeny s reálným fungováním systému. Přihlášení nemá být izolovaný technický krok, ale součást řízeného přístupu k datům, operacím a rozhodnutím.
Jeden bod přihlášení může práci výrazně zjednodušit. Musí se ale stát také jedním z nejlépe chráněných a nejlépe kontrolovaných bodů celé infrastruktury.
Chcete projít federované přihlášení, mapování rolí nebo životní cyklus identit pro svůj projekt?
Zdroje a další informace
[1] OpenID Foundation — OpenID Connect Core 1.0
[2] OASIS — Assertions and Protocols for SAML 2.0
[3] Internet Engineering Task Force — RFC 6749 — The OAuth 2.0 Authorization Framework
[4] National Institute of Standards and Technology — SP 800-63C — Federation and Assertions
[5] Internet Engineering Task Force — RFC 7644 — System for Cross-domain Identity Management
[6] OpenID Foundation — OpenID Connect Session Management 1.0
[7] National Institute of Standards and Technology — SP 800-63B — Authentication and Authenticator Management
[8] World Wide Web Consortium — Web Authentication: An API for accessing Public Key Credentials