Single Sign-On ve firemním prostředí.
Jak se informační systémy dostupné přes webové rozhraní stávají ve firemním prostředí standardem, roste poptávka po jednotném přihlašování do celé firemní infrastruktury – jedno, jednou zadané jméno a heslo ke všem firemním systémům. K zajištění této funkcionality slouží technologie Single Sign-On (SSO), tedy jednotný poskytovatel oprávnění ke všem firemním systémům. Mimo firemní prostředí se s tímto přístupem běžně setkáte, když vám webová stránka nabídne možnost přihlásit se prostřednictvím vašeho Google či Facebook účtu. Je ale tento způsob přihlašování pro firmy vždy vhodný?
Rizika sdílení účtů třetích stran
V první řadě je třeba zvážit, zda je přihlašování přes účty třetích stran z firemního hlediska bezpečné. Velcí poskytovatelé, jako například Google, budou mít své zabezpečení na špičkové úrovni. Za svou existenci jistě zaznamenali mnoho bezpečnostních zranitelností, ale obvykle jsou rychle řešeny a následné úpravy bezpečnostních politik obvykle zajistí ochranu před několika dalšími souvisejícími zranitelnostmi.
Existuje však i druhá strana, a to strana uživatele. Uživatel svůj Google účet využívá ke stovkám různých přístupů, má jej v každém Android zařízení, hlásí se přes něj do e-shopů a na mnoha zařízeních pracuje i s poštou či kalendářem. Lze za těchto okolností vůbec očekávat, že když nějaká aktivita na počítači či v mobilním zařízení požádá o přihlášení ke Google účtu, bude uživatel náležitě orientován, komu a proč dává svůj souhlas?
Tyto situace vznikají zcela neúmyslně, velmi často a velmi snadno. Máme svůj Android telefon, kde máme svůj Google účet, a synchronizujeme ho se svým firemním počítačem. Vše funguje skvěle. A když pak pořídíme rodinný tablet pro děti na hraní, přece nebudeme vytvářet další účet. Kdo by si to pamatoval. To stejné se stane se dvěma rodinnými Android TV a dalším novým tabletem pro starší, ale ještě ne dost staré dítě.
Není otázka „jestli“, ale „kdy“ zazní „Něco tam instaluju a chce to po mně přihlášení k Tvému Google účtu.“ a opět je jen otázka času, kdy odpověď bude „Něco dělám, tady ho máš a tady máš telefon, potvrď si to a neotravuj mě s tím“. Více faktorové přihlášení jistě ledacos řeší, ale obtěžuje. A lidé se obtěžovat nenechají.
Přihlašování do vlastní infrastruktury
Naproti tomu přihlašování přes vlastní firemní infrastrukturu těmito problémy netrpí. Váš firemní účet se k jiné, než firemní činnosti využít nedá. Rovněž pravděpodobnost, že útočník cíleně vytvoří rozhraní napodobující vaši firemní infrastrukturu, aby přiměl uživatele se přihlásit, je výrazně menší. Má ale použití čistě firemní infrastruktury jen samé výhody? Určitě ne. Ať už bude tím přihlašovacím serverem cokoli, vždy bude platit, že jeho selhání povede k odepření všech ověřovaných služeb.
Vzniká tak nový single point of failure (SPOF). Autentizační server může být redundantní, může běžet na naprosto spolehlivém hardware/software, ale možnost jeho selhání, třeba vlivem chyby v konfiguraci, vždy existuje.
Jelikož se nejedná o systém, který by se upravoval denně, jsou chyby administrátorů opravdu nejčastější příčinou fatálních selhání.
Navzdory tomu nejčastější příčina problémů bývá jiná. Autentizační servery jsou často navrhovány mezi prvními prvky firemní infrastruktury a v průběhu času „se zapomene“, jak mnoho nových služeb, které je využívají, přibylo. A výkon autentizace přestane dostačovat. Tato situace má nepříjemné důsledky. Dochází k poklesu odezvy zdánlivě nesouvisejících systémů, kdy při hledání příčiny se často zdlouhavě prověřuje něco „bližšího“, než autentizační server, který přeci vždy perfektně fungoval.
I banalita může přerůst v problém
Existují případy, kdy OAuth2 server, vytvořený v PHP, běžící bez problémů roky, najednou nestačil. U klienta již nebyl nikdo, kdo by jej uměl jakkoli upravit. Přenos na výkonnější hardware neměl výrazný efekt a z banální situace se stával rozsáhlý problém, protože přes SSO se uživatelé přihlašovali prakticky ke všemu.
Jelikož se i Flexideo pomocí tohoto SSO přihlašovalo a automaticky si pro svou potřebu vytvářelo kopii informací o uživatelských účtech, dala se nakonec situace řešit tím, že se flexideo převedlo do režimu nikoli OAuth2 klienta, ale OAuth2 serveru a stalo se tím, kdo udržuje informace o uživatelských účtech a jejich oprávněních.
Ukázalo se, že data v původním PHP OAuth2 serveru jsou relativně „čitelně“ uložena v databázi, takže jejich přenos byl spíše otázkou hodin než dnů. Uživatelé si sice museli znovu vytvořit hesla, ale s tím už se dá žít. A OAuth2 server napsaný v C/C++ již netrpěl problémy s nedostatkem výkonu, takže problémy s latencí navázaných služeb odezněly.
Flexideo vždy najde řešení
Flexideo celkově podporuje více SSO rolí. V rámci OAuth2 se umí chovat jako čistá klientská strana, tedy jednat svým jménem (na účet služby); jako třetí strana do níž se uživatel přes SSO hlásí a jedná vůči ní svým jménem (na cizí účet); jako zprostředkovatel, kdy jedná vůči třetí straně jménem uživatele (na svůj účet); jako pasivní třetí strana, do které se uživatel hlásí prostřednictvím oprávnění vystaveném pro někoho jiného (cizím jménem, na svůj účet – jen z druhé strany); a v neposlední řadě jako čistokrevný OAuth2 server, tedy autentizační server pro SSO celé firmy.
Kromě OAuth2 umožňuje užívat další obdobné SSO protokoly, například OpenID. Použití OAuth2 bylo testováno proti řadě předních poskytovatelů těchto služeb, jako je Google (jako OpenID) nebo Microsoft.
Flexideo tedy splní vaše požadavky, ať již ji budete chtít začlenit do své stávající infrastruktury, nebo na ní svou bezpečnostní infrastrukturu postavit.
