Věk cloudových řešení a správa identit – jak na o365

Firmy a organizace chtějí omezovat rutinní operativu. To je jasné.

Automatizovat. Super.

Používat co nejmodernější vychytávky, řešení, aplikace a technologie. Už včera bylo pozdě.

Uvolňovat si ruce na kreativní a produktivní práci. Sen všech manažerů a majitelů firem.

“Clouduji, clouduješ, cloudujeme”

Současný trend je zřejmý. Data – a tedy i identity – se čím dál častěji přesouvají do prostředí cloudových služeb s cílem přiblížit je aplikacím, které se provozují v cloudovém prostředí. Jako jeden příklad za všechny stačí uvést hojně rozšířené cloudové služby Office365.

Na bedra administrátorů systémů tak dopadá nová kupa starostí, protože zároveň s tím rostou nároky na správu účtů a bezpečnostní rizika: logicky se tím rozšiřují možnosti přístupů do firemních systémů i počet přihlašujících se uživatelů (např. externistů).

Jak v takové situaci přehledně ukočírovat, kdo má jaká práva, kdy je dostane a kdy o ně přijde? Jak zajistit bezpečnost provozu systémů? Nemluvě o tom, že všechny tyto různorodé systémy spolu musejí umět efektivně komunikovat. Jinak můžete na automatizaci a efektivitu zapomenout.

Řízená identita nade vše – cloud necloud

Pro jasnější přiblížení problematiky si představme následující soukromou firmu:

• spravuje přes 30 různých informačních systémů (Office365 v cloudu, HR systémy, systém docházky, Helpdesk, správa přenosných zařízení s dálkovým přístupem, mailingový server, správa skupin v AD…)
• používá cloudové služby pro běh vlastního produktu, který nabízí jako službu
• navíc umožňuje svým partnerským organizacím či zaměstnancům model ‘bring your own identity’ neboli využívá identity, které si uživatelé služby přinášejí z domovské organizace, v níž se odehrává správa jejich životního cyklu (i tady se můžeme setkat s cloudovými řešeními)
• a novinkou je, že musí zahrnout do správy také totožnosti, které se nevážou k živým osobám (internet of things, IoT)

S každým nástupem nového zaměstnance, odchodem pracovníka, změnou pracovního zařazení se odehrají změny na identitách zakládaných v různých systémech, mění se její oprávnění, jsou jí odebírány přístupky k systémům a mimo to se mění i její vztahy k ostatním identitám. Stavy účtu v jednom systému však musí vždy spolehlivě odpovídat stavům účtu ve všech ostatních systémech.

Ať už jsou specifika koncového napojeného systému jakékoli, firma potřebuje, aby všechny běžné procesy probíhaly hladce. Například:

• Založení účtu (v kterémkoli systému, a tedy i v cloudu) a přenos informace o této operaci do jiných

• Distribuce hesla zaměstnanci, například pomocí SMS.

• Zrušení účtu (včetně účtu na cloudu) při konci úvazku, archivace účtu dle interní politiky firmy, smazání z archivu po uplynutí archivačního období.

• Schválení zřízení účtu/přidělení oprávnění (na cloudu i jinde). Moderní IdM systémy umožňují vícekolové schvalování přidělení oprávnění vlastníkem dat systému nebo nadřízeným.

• Příprava dat pro audit. Nemusíte ze změti logů různých systémů lovit auditní informace o přístupech zaměstnanců. S IdM máte přehled práv uživatelů na jednom místě. Audit bez Identity Managementu může zabrat celé dny.

Co mohou udělat jednotliví zaměstnanci, nedělejte vy sami

Navzdory složité síti systémů umožňuje moderní identity management také podstatně jemnější dělení pravomocí: řadu činností a kroků může s příslušným omezeným a bezpečnostně ošetřeným oprávněním zvládnout i samotný (řadový) zaměstnanec. I to je součást správy identit – na jedné straně možnost vyšší bezpečnost (např. nastavení neslučitelnosti rolí) a na druhé straně větší autonomie uživatelů:

• V případě resetu zapomenutého hesla nabízejí moderní IdM SW, jako je například CzechIdM, i samoobsluhu pro uživatele, kde si každý své zapomenuté heslo může sám resetovat.

• I o změnu práv (k nové AD skupině) si může uživatel zažádat sám, jeho žádost nadřízený (nebo garant systému) schválí.

• Můžete vyloučit souběh pravomocí: admin nebude sám rozhodovat o bezpečnostní politice a schvalovacích procesech.

CzechIdM a konkrétně správa Office 365 v Cloudu

Po obecném úvodu o cloudových řešeních v kontextu správy identit se teď zaměříme pouze na jeden možný koncový systém napojovaný k identity managementu – a tím je Office 365 v cloudu.

Způsobů, jak začlenit cloud Office365 pod širší centralizovanou správu identit napříč systémy organizace, je vícero. A je také mnoho různých technických záludností, s nimiž je nutno počítat:

• způsob, jak je o365 propojen s lokálním AD/Exchange
• odlišné platformy
• úprava konektorů pro jednotlivé databáze
• různý počet mapovaných atributů identit
• možné kolidující interní procesy – periodicky naplánované interní synchronizace, provisioning či rekonciliace dat
• prostředí, do kterého se zavádějí změny (produkce, testovací prostředí)

O365 je primárně spravován přes adresářovou službu Active Directory (AD) zákazníka. Takže cílem je pod centrální správu identit v naší aplikaci CzechIdM začlenit AD tak, že vy jako náš zákazník budete moct využívat přínosů koordinovaného řízení životního cyklu identit centrálně spravovat přístupy do jednotlivých systémů a harmonizovat bezpečnostní politiky.

Za dva týdny čistého času a přímo v produkci

Alespoň pro určitou představu si ve zkratce projdeme několik zajímavých úskalí na jednom konkrétním – poměrně složitém – příkladu jednoho naše klienta ze soukromého sektoru.

V popisovaném případě náš zákazník potřeboval poměrně rychle zajistit v prostředí, kde jsou celkem 4 vzájemně si důvěřující AD domény(s vlastními rolemi přidělenými k identitám v každé skupině), propojení té největší AD domény s cloudovým řešením Office 365 včetně spárování identit.

Cílem bylo umožnit firmě pomocí IDM zakládat, spravovat a mazat mailboxy v cloudu O365, aby pak firma mohla pokračovat v migraci, kterou jim zajišťovala jiná externí firma. Schránky byly vytvářené v samotném závěru migrace dat, a to na základě vyhodnocení vlastností migrovaných účtů posílaných ze systémů. Přitom zákazník používá jak lokální systém Exchange, kde spravuje schránky, tak cloud O365.

Největším oříškem bylo, že jsme neměli k dispozici samostatné testovací prostředí pro cloud, jehož vytvoření by se do termínu nestihlo, a proto jsme řešení po dohodě nasazovali rovnou do produkčního prostředí. To je pochopitelně velmi náročné na pečlivou přípravu. Není to ani žádoucí dobrá praxe. Rizika jsou bohužel veliká.

Rozšířený AD konektor a vzdálený konektor server

Tím nejjednodušším krokem z celého procesu bylo vytvořit zálohu dat v Active Directory (AD). Všechno ostatní už vyžadovalo úpravy na míru.

V IdM v napojení AD pro správu uživatelů jsme rozšířili výpočet atributu RecipientType, který si hlídal, jaká měl uživatel oprávnění, pokud jde o mailovou schránku. Podle typu přidělené role se zvláštní externí atribut plnil konkrétní hodnotou – a v závislosti na tom se uživatelům buď zakládaly či nezakládaly nové cloudové mailové schránky.

Komplikací bylo, že při zakládání účtu v AD a jeho řazení do skupiny, která zajišťuje synchronizaci účtu do cloudu, jsme museli počkat až 30 minut na doběhnutí synchronizace dat. Do té doby nebylo žádoucí remoteMailbox zakládat. Právě proto jsme naimplementovali proces, který bude pravidelně kontrolovat identity s danou rolí (skupinou) a nastaví jim zvláštní příznak (o365Created=true). Pouze při načtení této hodnoty konektor volal příkaz pro vytvoření remoteMailbox. Tím bylo jednoznačně stanoveno, kdo získá jakou roli neboli oprávnění ke schránce. Samozřejmě proces musel umět vypočítat správnou hodnotu i pro případ, že identita už účet v Cloudu má. A vše bylo nutné sladit s personálními procesy.

K volání potřebných příkazů přímo z .NET konektoru našeho zákazníka a potažmo k vytvoření vzdálené schránky v cloudu jsme využili námi rozšířený (a otestovaný) AD konektor a Exchange konektor (což je nástavba nad AD konektorem). AD konektor je implementovaný v .NET a byl nasazený v našem Remote Connector Serveru, rovněž implementovaném v .NETu.

Exchange konektor spouští zvláštní příkazy, tzv. PowerShell příkazy, a využívá i .NET API AD-čka pro běžnou správu lokálních uživatelů. Před vlastní migrací jsme ho museli upravit tak, aby nově podporoval spuštění dvou nových PowerShell příkazů:

1) aktivace vzdálené emailové schránky (Enable-RemoteMailbox) a

2) její nastavení (Set-RemoteMailbox).

Error číhá v každém detailu – hodí se mít plán B

Načasování takové operace muselo být pečlivě odladěné, aby nekolidovalo s dalšími pravidelnými procesy aktualizace dat napříč systémy.

A samozřejmě bylo třeba počítat i s variantou, že z nějakých důvodů migrace neproběhne – a promyslet kroky, jak akci dovést do zdárného konce.

Protože se jelo přímo na ostré produkci, měli jsme připravený funkční plán B (tzv. roll back). Nasazení probíhalo během víkendu, na dva restarty a nemělo žádný dopad na dostupnost služby IDM pro uživatele.

Dodání trvalo všehovšudy 2 týdny čistého času.

Popsané takto v několika odstavcích to vypadá vlastně docela přímočaře.

Seriál o Identity Managementu:

1. Co je to Identity Management?
2. Jak vybrat IDM?
3. Jak migrovat Identity Management?
4. Modely spolupráce s dodavatelem IDM.
5. Jak zabrátit vendor lock-in?
6. Jak z personalistiky identifikovat vedoucího pro IDM?
7. Jak se zbavit rutinních úkolů při správě IT systému automatizací Identity Managementu?
8. Jak správně nasadit IDM do produktivního provozu?
9. Co je to SCIM?
10. JIP/KAAS – jak předávat data.

 

Další témata