Jak správně nasadit IdM do produkce a vyhnout se problémům?

Implementujete IDM. Prošli jste analýzou, vývojem a testováním vyvinutého řešení. Stojíte před nasazením do produkce, což je velmi riziková část.

Jak správně postupovat při přechodu s řešením Identity Managementu (IDM) do produktivního provozu? Na co si dát pozor? Kde jsou hlavní rizika? Pokazit se přeci může tolik věcí.

Článek je o praktických zkušenostech z mnoha nasazení, kterými jsme prošli. Je sepsán ve formě cheklistu, krok za krokem. Jedná se o nahlédnutí do naší kuchyně, roky sbíraného know-how.

Článek jsem se rozhodl psát co nejstručněji. Nepopisuji teorii. Od toho jsou jiné články odkazované níže. Pokud vám bude cokoliv nesrozumitelné, neváhejte se mne zeptat: lukas.cirkva@bcvsolutions.eu

Vše až na výjimky (odkazy do dokumentace) je napsáno nezávisle na implementovaný produkt IdM.

Existují dva základní typy projektů IDM dle velikosti:

  1.  Malé projekty:  IDM se pouze instaluje a konfiguruje. Admin připojí ke správě systémy. Není třeba nic programovat.
  2. Větší a velké integrační projekty IDM. Data se transformují z více systémů a přenáší do dalších. Jsou nutné zásahy vývojářů na úpravy procesů. 

Tento článek se věnuje druhému typu projektům, těm složitějším integračním projektům.

Jaké jsou nejčastější příčiny neúspěchu nasazení a jak jim předejít:

  1. Přílišná velikost projektů.  Větší projekty doporučuji rozdělit na menší. Hledejte MVP – minimum viable product. Ten nasazujte do produkce a rychle zlepšujte. Vím, bývá to těžké, co nezahrnout.
  2. Smiřte se s tím, že máte v systémech chybná data (duplicity, mrtvé duše atd). Bohužel často nejsou systémy ani zdokumentované. Zmapovat data může být extrémně náročné nebo složité. Jak na to? Opět jít po menších projektech a iteracích. Nasadit, identifikovat problémy průběhu, opravit a rychle nasadit zlepšení.
  3. Testing – na testování je vždy málo času. Testování je enormě drahé. Zástupci zákazníka mají svou standardní práci, projekt IDM mají často navíc. Testovací prostředí je odlišné od produkce apod. Toto je věčná bolest všech projektů. Testing si zaslouží vlastní článek. 
  4. Nedělejte změny oproti analýze a návrhu řešení na poslední chvíli. Pokud změny dovolíte, způsobíte si pravděpodobně velké problémy. Fixní zadání u SW projektů bez možností změn je již překonaným postupem. Postupujte agilně a iterativně.
  5. Máte neznámé aplikace v síti, využívající identity v AD speciální atributy.  Existují systémy běžící desítky let a jejich funkce již dávno nejsou ve firmě známé. Analýzou tedy často nelze identifikovat. Lze řešit testingem, ale ne vždy plně.

Obecné návyky na bezproblémová nasazení do produkce:

  1. Chyby v datech jsou vždy. Přijměte to. Řešte testingem a po nasazení pilotním provozem a rychlými nápravami. 
  2. I první řešení nasazujte do produkce postupně a řízeně – po procesech, po systémech, po identitě, po skupině identit. viz. cheklist
  3. Testovací prostředí musí být datově identické. Pokud není, budou při nasazení problémy. Postavit a provozovat testovací prostředí něco stojí. Ale v konečném důsledku se vyplatí.
  4. Proškolte klíčové uživatele IDM. Testovat musí také ti, kteří budou IDM ovládat. Musí skutečně projít své scénáře. Jedná se o kritickou část testování. 
  5. Definujte deploy proces a hlídejte jej. Vývojář nesmí zasahovat do produkce mimo tento proces. Tj. nasazuje se do produkce pouze to, co bylo otestováno na testovacím prostředí.  
  6. Řešení IdM nepokrývá všechny možné výjimky procesů. Často nemá finančně/časově smysl vše automatizovat systémem. Mějte čas na identifikaci výjimek v testu i v produkčním provozu.
  7. Sledujte co IdM dělá na koncových systémech, nejen v IDM. Osvědčilo se nám dělat diff například z AD ldap LDIFF. Dá se tak podchytit nejvíce změn.
  8. Nikomu nevěřte. :-) Pokud vám admin řekne, že koncový systéme zazálohoval, udělejte si zálohu sami. No kidding.
  9. Tvořte sestavy změn na účtech, které plánuje IDM udělat a předávejte je adminům k akceptaci. Teprve na základě těchto sestav se najde hromada chybných dat a výjimek. 

Cheklist nasazení

Mějme příklad IDM, kdy napojujeme HR – SQL databázi a Active Directory.

  1. Udělejte si přípravu – harmonogram, checklist, rizika. Promyslete krok za krokem. Co se může stát špatného a jak to řešit.
  2. IDM jsme nainstalovali. Na to máme extra checklist. 
  3. Zkontrolujte, že na testu i produkci máme identickou verzi IDM. Ověřte shodnost workflow i pravidel. 
  4. Zazálohujte data identit napojovaných systémů. U AD LDIF všech stromů a u SQL tabulky. Mějte vy zálohu, nevěřte žádnému systému nebo jinému týmu.
  5. Zálohujte IDM.
  6. Přepněte systémy v IDM do read-only (RO)  režimu. V našem případě AD a HR.
  7. Vypněte staré synchronizační skripty (pokud existují) mezi systémy, které IDM bude nahrazovat.
  8. Vypněte v IDM automatické procesy, notifikace apod.
  9. Rekoncilujte organizační strukturu z HR.
  10. Rekoncilujte identity z HR a AD do IdM.
  11. Vytvořte sestavu nespárovaných identit.  Často se jedná o mrtvé duše nebo systémové účty adminů nebo aplikací. Které identity se automaticky nespárovali a proč?
  12. Vyřešte problematické identity. Může trvat delší čas.
  13. Vyberte uživatele a toho z AD LDIFem zazálohujte. Viz. příklad striptu níže.
  14. Aktivujte v IDM správu AD do R/W.
  15. Aktivujte brzdu provisioningu – kolik povolit změn za jednotku času?  za  viz: Návod na wiki k brzdě.
  16. Propište jednoho uživatele do AD.
    1. Stáhněte LDIF uživatele z AD a porovnejte DIFFem změny. Jsou ok? Jsou správné?
    2. Postupujte shodně u všech typů uživatelů napříč firmou. Logicky nejde zkontrolovat všechny, alespoň typy napříč firmou ano.
  17. Propište všechny účty a zkontrolujte namátkou rozdíly diffem koncového systému.
  18. Aktivujte v IDM správu AD do RO.
  19. Personální procesy z HR: spustit nástup, odchod změnu
    1. nejdříve v RO, zkontrolovat frontu v CzechIdM k jakým změnám dochází. Podívat se do logu provisioningu. Viz návod logu provisioningu ve wiki
    2. Aktivujte v IDM správu AD do R/W.
    3. Spusťte personální proces na jednom uživateli.
    4. Ověřte diffem v koncovém systému správnost změny.
    5. Spusťte proces na jednotkách uživatelů. Zkontrolujte změny diffem.
    6. Spustit na všech uživatelích a LDIF namátkově zkontrolovat.
  20. Následně synchronizovat skupiny v AD do IDM dle předchozího postupu.
  21. Zkontrolujte aktivaci všech procesů, notifikací atd.
  22. Dejte pozor na notifikace. Aby nedošlo k neočekávané notifikace uživatelů maily, které nechcete poslat.
  23. Změňte brzdu provisioningu do produkčního nastavení.
  24. Zkontrolujte systémové prostředky IDM, logování, využití diskového prostoru, vytížení atd.
  25. Projděte klíčové scénáře s pracovníky, kteří budou IDM využívat. Znovu proškolte.
  26. Zaevidujte změny na produkčním prostředí do servisního systému a dokumentace.
  27. Zazálohujte IDM, AD LDIFF.
  28. Aktivujte monitoring IDM. (nagios apod.)
  29. 14 dní věnujte řešení zvýšenou pozornost. Aktivně sledujte logy a synchronizace, zejména na chybná data a nepokryté procesy. Dále dozorujte uživatele, zda řešení využívají dle plánu.
Příklady skriptů zálohování AD LDAP protokolem

Skript pro export z Active Directory LDAPem do LDIFu několika vyjmenovaných uživatelů:

#!/bin/bash

LOC="/opt/czechidm/ADbackup"
NOW=$(date +"%Y-%m-%d-%H%M%S")
OUTPUT="users.ldif$NOW"

cd "$LOC"

FILTER="(|(sAMAccountName=USER0)(sAMAccountName=USER1)(sAMAccountName=USER2))"
CONTAINER="DC=DC_NAME,DC=local"

ldapsearch -h “IP-ADD” -p 389 -D "CN=IDM CZ,CN=Users,DC=DC_NAME,DC=local" -E "pr=999999/noprompt" -w ‘PASSWORD’ -s sub -z none -b "$CONTAINER" -o ldif-wrap=no "$FILTER" > "${OUTPUT}_full"

ldapsearch -h "IP-ADD" -p 389 -D "CN=IDM CZ,CN=Users,DC=DC_NAME,DC=local" -E "pr=999999/noprompt" -w 'PASSWORD' -s sub -z none -b "$CONTAINER" -o ldif-wrap=no "$FILTER" displayName userAccountControl givenName member memberOf mail distinguishedName dn sAMAccountName sn userPrincipalName  > "$OUTPUT"
cat "$OUTPUT" |  perl -MMIME::Base64 -MEncode=decode -n -00 -e 's/(?<=:: )(\S+)/decode("UTF-8",decode_base64($1))/eg;print' > "${OUTPUT}_decoded"

Export z Active Directory LDAPem do LDIFu všech dat:

#!/bin/bash

LOC="/opt/czechidm/ADbackup"
NOW=$(date +"%Y-%m-%d-%H%M%S")
OUTPUT="users.ldif$NOW"

cd "$LOC"

ldapsearch -h "IP-ADD" -p 389 -D "CN=IDM CZ,CN=Users,DC=DC_NAME,DC=local" -E "pr=999999/noprompt" -w 'PASSWORD' -s sub -z none -b "DC=DC_NAME,DC=local" -o ldif-wrap=no  > "${OUTPUT}_full"

ldapsearch -h "IP-ADD" -p 389 -D "CN=IDM CZ,CN=Users,DC=DC_NAME,DC=local" -E "pr=999999/noprompt" -w 'PASSWORD' -s sub -z none -b "DC=DC_NAME,DC=local" -o ldif-wrap=no displayName userAccountControl givenName member memberOf mail distinguishedName dn sAMAccountName sn userPrincipalName  > "$OUTPUT"
cat "$OUTPUT" |  perl -MMIME::Base64 -MEncode=decode -n -00 -e 's/(?<=:: )(\S+)/decode("UTF-8",decode_base64($1))/eg;print' > "${OUTPUT}_decoded"

Závěr

Nasazení Identity Managementu může zabrat poměrně dost času a práce. Pro úspěch je zásadní příprava. Ročně nasazujeme desítky řešení IDM. Každé je v něčem zajímavé, jiné. Postupně si tvoříme takovéto cheklisty, které velmi pomáhají.

Článek neřeší časovou náročnost. Každý napojovaný systém má jinou složitost – množství uživatelů, hloubku integrace s IDM.  IDM dle složitosti integrace napojujeme do produkčního provozu v rámci hodin, ale i dní.

Přeji Vám úspěšné nasazení.

Děkuji kolegyni Aleně Peterové za inspiraci a skripty.

 

Mohlo by vás také zajímat:

  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. Co je to SCIM?

About Lukáš Cirkva

CEO, Identity Management consultant with 10+ years of experience. I have also played a leadership role in the development of our company's own SW tool - CzechIdM. We also service our delivered solutions. Please see www.CzechIdM.com and linkedin for more info: www.linkedin.com/in/lukascirkva/

Leave a Reply