Kdo má přístup a k čemu? Problém s IAM, o kterém se nemluví
Většina firem si myslí, že má správu přístupů pod kontrolou. Nemá. A audity tuto iluzi často potvrzují.
Vzor, který se opakuje
V podnikovém prostředí se překvapivě často opakuje jeden scénář. Starší aplikace, která je v provozu již desítky let, a role vytvářené postupně bez jakékoli dokumentace. Výsledek? Systémy se stovkami rolí, u nichž ani tým spravující aplikaci nedokáže popsat, co jednotlivé role vlastně umožňují.
Při přidělování přístupových práv se pak postupuje cestou nejmenšího odporu: přijde nový zaměstnanec a jeho manažer řekne: „Dejte mu stejné role jako jeho kolegovi.“ Ten kolega odešel před třemi lety a nikdo nikdy jeho přístupová práva neprověřil. Nový zaměstnanec tak zdědí oprávnění, o která nikdo nepožádal, která nikdo nepotřebuje a která nikdo nedokáže vysvětlit.
Princip nejmenších oprávnění existuje v dokumentaci. V praxi ho však nikdo nevynucuje, protože nikdo nemá nástroje ani čas na to, aby zjistil, co každá role vlastně dělá.
Iluze každoroční recertifikace
Jednou za rok nastává období recertifikací. Manažeři dostávají seznam se stovkami či tisíci oprávnění, která mají schválit. A jak to dopadne? Schválí všechno. Ne z nedbalosti, ale proto, že nemají jak zjistit, co je správné. Audit dopadne čistě, ale nikdo se neptá, jak recertifikace vlastně proběhla. Systém formálně splňuje předpisy, ale v praxi nic neřídí.
Možná si říkáte: jsme malý tým, to se nás netýká
Týká. Tento problém nevzniká při velkých číslech. Začíná v okamžiku, kdy první vývojář získá práva správce „protože je potřebuje pro jeden projekt“. Projekt skončí, ale přístup zůstane. Přidá se další vývojář a dostane stejné role. O dva roky později už nikdo přesně neví, kdo k čemu má přístup, a nikoho nenapadlo se na to zeptat.
Jak to vypadá z pohledu útočníka
Z pohledu útočníka se jedná o ideální prostředí. V rámci jednoho projektu jsem narazil na roli, která umožňovala vytvoření administrátorského uživatele. Nikdo o tom nevěděl. Role byla vytvořena před lety a prostě tam zůstala. Tento vzorec se opakuje znovu a znovu, obvykle ve dvou podobách:
Zvýšení oprávnění prostřednictvím špatně navržených rolí: uživatel se standardním přístupem má oprávnění vytvořit nového uživatele s vyššími oprávněními, než má sám.
Oprávnění vynucovaná pouze na frontendu: aplikace zobrazuje pouze to, co uživatel „smí vidět“, ale volání API neprovádějí žádné autorizační kontroly. Stačí jeden přímý požadavek a vše se zhroutí.
Tři věci, které platí bez ohledu na velikost firmy
Neobhajuji zavádění komplexních frameworků pro správu identit a přístupů (IAM) ve firmě s dvaceti zaměstnanci. Existují však tři zásady, které platí obecně:
Každá role musí mít svého správce a popis. Nejen v něčí hlavě, ale písemně. Když správce odejde, role se přezkoumá nebo zruší.
Přístupy se řídí na backendu, ne jen na frontendu. Frontend slouží pro uživatelský zážitek. Backend slouží pro bezpečnost. Nikdy ne naopak.
Princip nejnižších oprávnění musí být aktivně udržován. Nestačí jej pouze deklarovat při nástupu nového zaměstnance. Pravidelně se ptejte: potřebuje tato osoba stále tento přístup?
Chaos v oblasti řízení přístupu nevzniká ze zlých úmyslů. Vzniká z dobrých úmyslů bez řádného postupu. A útočníci mezi nimi nerozlišují.
Ví vaše společnost, kdo má k čemu přístup?
Pokud je upřímná odpověď „ani ne“, právě v tom vám může pomoci služba IAM Consulting. Provedu audit vašeho stávajícího systému řízení přístupů, odhalím jeho slabá místa a pomohu vám vytvořit model, který bude v praxi skutečně fungovat.
Doporučené příspěvky
