Když zaměstnanec odejde, je jasné, že jeho přístupy mají zaniknout. U aplikace, služby nebo automatizovaného procesu to tak zřejmé není.

Jejich účty mohou fungovat roky. Původní autor odejde, aplikace změní vlastníka a oprávnění se postupně rozšíří. Heslo nebo klíč zůstává v konfiguraci, protože není jasné, kdo za něj odpovídá a kdy se má změnit.  

Systém přitom dál funguje. Časem už ale nikdo přesně neví, kdo za přístup odpovídá, k čemu slouží a zda je ještě potřeba. 

Identita, účet a přihlašovací prostředek

Technická identita představuje aplikaci, službu, zařízení nebo automatizovaný proces, který potřebuje přistupovat k systémům a datům.

V jednotlivých systémech může používat různé účty nebo identitní objekty, například servisní účet, databázového uživatele, API klienta, OAuth aplikaci nebo cloudovou identitu.

Jedna technická identita tedy může mít více účtů. Ty se ověřují pomocí hesla, klíče, tokenu nebo certifikátu.

U každé technické identity musí být jasné:

• kterou aplikaci nebo proces představuje,
• kdo za ni odpovídá,
• jaké účty a oprávnění používá,
• ke kterým systémům přistupuje,
• jakým způsobem se ověřuje,
• kdy má být změněna nebo zrušena.

Pokud tyto informace nejsou dohledatelné, organizace nemá daný přístup plně pod kontrolou ani jistotu, že za něj odpovídá správný člověk nebo tým. 

Proč technické identity snadno uniknou kontrole

Technický účet často vznikne při implementaci, integraci systémů nebo řešení provozního problému. Nemusí proto projít stejným procesem jako účet zaměstnance.

Nejčastěji se objevují čtyři rizika.

Chybějící vlastník

Účet vytvořil vývojář, aplikaci provozuje IT a její výstupy používá jiné oddělení. Každý zná část řešení, ale nikdo neodpovídá za identitu jako celek.

Příliš široká oprávnění

Aplikace získá při nasazení více práv, než skutečně potřebuje. Dočasné nastavení se postupně stane trvalým.

Dlouhodobé přihlašovací prostředky

Heslo nebo API klíč může zůstat aktivní roky, i když už nikdo přesně neví, kdo ho používá a proč. Při úniku pak není snadné určit rozsah rizika ani rychle přístup zrušit.

Neukončený životní cyklus

Aplikace je nahrazena nebo projekt skončí, ale původní účty, tokeny a oprávnění zůstanou aktivní v dalších systémech.

Stejná pravidla jako u lidí

Také aplikace a automatizované procesy potřebují známého vlastníka, jasný účel a pouze nezbytná oprávnění. Po celou dobu, kdy technická identita existuje, musí být jasné, kdo za ni odpovídá. Pokud tento člověk změní roli nebo z organizace odejde, je potřeba odpovědnost předat dál. IGA pomáhá tuto odpovědnost udržovat aktuální a navázat na ni pravidelnou kontrolu přístupů.

Stejně tak musí být jasné, které účty a oprávnění patří ke které aplikaci. Pokud několik aplikací používá stejný účet, hůř se dohledává, která z nich konkrétní operaci provedla. Takový účet navíc potřebuje oprávnění pro všechny činnosti, které tyto aplikace vykonávají, a snadno tak získá více práv, než by jednotlivě potřebovaly.

Účty je proto vhodné oddělovat podle aplikace a účelu.

Stejně důležité je řídit životní cyklus hesel, klíčů a tokenů. Organizace musí vědět, jak jsou spravovány, a být schopná je v případě potřeby změnit nebo rychle zneplatnit.

Při vyřazení aplikace nestačí vypnout server. Je nutné deaktivovat také její účty, odebrat oprávnění a zrušit navázané klíče, tokeny a certifikáty.

Do IAM vstupují také AI agenti

Vedle tradičních aplikací se v organizacích objevují AI agenti. Mohou pracovat s podnikovými daty, využívat různé nástroje a samostatně provádět povolené operace.

Také agent proto potřebuje vlastní dohledatelnou identitu. Neměl by používat osobní účet svého autora ani obecné přihlašovací údaje jiné aplikace.

U každého agenta musí být jasné:

• kdo za něj odpovídá,
• zda jedná samostatně, nebo jménem uživatele,
• ke kterým datům a operacím má přístup,
• jak lze jeho činnost zpětně dohledat,
• kdy mají jeho přístupy zaniknout.

Specifické je, že agent může v rámci jednoho úkolu pracovat s více systémy a nástroji a samostatně mezi nimi provádět navazující kroky. S rozšiřováním funkcí agenta se mohou postupně přidávat i další přístupy, takže časem nemusí být snadné udržet přehled o tom, kam všude agent dosáhne a co tam může udělat. Důležité je také rozlišit, kdy agent jedná pod vlastní identitou a kdy jménem konkrétního uživatele. 

Z pohledu IAM nejde o zcela nový princip. Také zde platí známý vlastník, nejnižší potřebná oprávnění, kontrolovatelný životní cyklus a auditní stopa.

Začněte u nejrizikovějších přístupů

Pokud organizace technické a agentní identity ještě nemá systematicky podchycené, dává smysl začít u těch nejrizikovějších. Typicky jde o identity s administrátorskými oprávněními, přístupem k citlivým datům, vazbami na více systémů, dlouhodobými klíči nebo bez jasného vlastníka.

V rámci zavedení IGA, případně v už existujících procesech, je pak možné postupně doplnit jejich vlastníky, účty, oprávnění a pravidla životního cyklu a pravidelně ověřovat, zda stále odpovídají původnímu účelu.

Začněte technickými technickými identitami s nejvyššími oprávněními. U kolika z nich dnes dokážete určit jejich vlastníka a důvod další existence?