Přechod na jiný zdroj zabezpečení Cognos

Když potřebujete překonfigurovat stávající prostředí Cognos na použití jiného externího zdroje zabezpečení (např. Active Directory, LDAP atd.), Můžete použít několik přístupů. Rád jim říkám „Dobrý, zlý a ošklivý“. Než prozkoumáme tyto dobré, špatné a ošklivé přístupy, podívejme se na některé běžné scénáře, které mají tendenci řídit změny oboru názvů autentizace v prostředí Cognos.

Běžné obchodní ovladače:

Aktualizace hardwaru nebo operačního systému - Častým ovladačem může být modernizace hardwaru/infrastruktury BI. Zatímco zbytek Cognosu může běžet jako šampión na vašem elegantním novém hardwaru a moderním 64bitovém operačním systému, hodně štěstí při migraci vaší verze Access Manager z roku 2005 na tuto novou platformu. Access Manager (první vydání se sérií 7) je pro mnoho zákazníků Cognos úctyhodným pozůstatkem minulých dnů. Je to jediný důvod, proč mnoho zákazníků uchovává tuto špinavou starou verzi systému Windows Server 2003. Psaní je pro Access Manager již nějakou dobu na zdi. Jedná se o starší software. Čím dříve se z toho můžete dostat pryč, tím lépe.

Standardizace aplikací- Organizace, které chtějí konsolidovat autentizaci všech svých aplikací na jednom centrálně spravovaném firemním adresářovém serveru (např. LDAP, AD).

Fúze a akvizice- Společnost A kupuje společnost B a potřebuje prostředí Cognos společnosti B, aby ukazovalo na adresářový server společnosti A, aniž by to způsobilo problémy s jejich stávajícím obsahem nebo konfigurací BI.

Firemní odprodeje- Toto je opak scénáře sloučení, část společnosti se rozdělí na vlastní entitu a nyní musí zaměřit své stávající prostředí BI na nový zdroj zabezpečení.

Proč může být migrace jmenného prostoru chaotická

Nasměrování prostředí Cognos na nový zdroj zabezpečení není tak jednoduché jako přidání nového jmenného prostoru se stejnými uživateli, skupinami a rolemi, odpojení starého jmenného prostoru a VOILA!- všichni vaši uživatelé Cognos v novém jmenném prostoru jsou spárováni s jejich obsah. Ve skutečnosti můžete často skončit s krvavým nepořádkem na rukou, a tady je důvod, proč…

Na všechny principy zabezpečení Cognos (uživatelé, skupiny, role) odkazuje jedinečný identifikátor zvaný CAMID. I když jsou všechny ostatní atributy stejné, CAMID pro uživatele v souboru stávající obor názvů ověřování nebude stejný jako CAMID pro daného uživatele v souboru nový jmenný prostor. To může zničit stávající prostředí Cognos. I když máte jen několik uživatelů Cognos, musíte si uvědomit, že reference CAMID existují na MNOHA různých místech ve vašem Content Store (a mohou dokonce existovat mimo váš Content Store v modelech Framework, Transformer Models, TM1 Applications, Cubes, Planning Applications atd. ).

Mnoho zákazníků Cognos se mylně domnívá, že CAMID je ve skutečnosti důležitý pouze pro obsah My Folder, uživatelské preference atd. To nemůže být dále od pravdy. Nejde jen o počet uživatelů, které máte, ale o množství objektů Cognos, o které se musíte starat. Jen v obchodě Content Store je více než 140 různých typů objektů Cognos, z nichž mnohé mohou mít více odkazů na CAMID.

Například:

1. Není neobvyklé, že jeden plán ve vašem obchodě s obsahem má více referencí CAMID (CAMID vlastníka plánu, CAMID uživatele, který by měl plán spustit jako, CAMID každého uživatele nebo distribuční seznam, na který by měl odeslat výstup generované zprávy e -mailem , atd.).
2. Každý objekt v Cognos má zásady zabezpečení, které určují, k jakým uživatelům k objektu mají přístup (viz „Karta Oprávnění“). Jedna zásada zabezpečení visící mimo tuto složku v Cognos Connection má odkaz na CAMID pro každého uživatele, skupinu a roli, která je v této zásadě uvedena.
3. Snad pochopíte pointu - tento seznam pokračuje dál a dál!

Není neobvyklé, že značný obchod s obsahem obsahuje desítky tisíc referencí CAMID (a viděli jsme některé velké se stovkami tisíc).

Nyní si spočítejte, o co jde váš Prostředí Cognos a vidíte, že se potenciálně potýkáte s hordami referencí CAMID. Může to být noční můra! Přepnutím (nebo opětovnou konfigurací) vašeho oboru názvů ověřování můžete ponechat všechny tyto odkazy CAMID v neřešitelném stavu. To nevyhnutelně vede k problémům s obsahem a konfigurací Cognos (např. Plány, které již neběží, obsah, který již není zabezpečen tak, jak si myslíte, balíčky nebo krychle, které již správně neimplementují zabezpečení na úrovni dat, ztráta obsahu a uživatele My Folder preference atd.).

Přechodové metody Cognos Namespace

Nyní s vědomím, že prostředí Cognos může mít desítky tisíc referencí CAMID, které budou vyžadovat nalezení, mapování a aktualizaci na jejich odpovídající novou hodnotu CAMID v novém oboru názvů autentizace, pojďme diskutovat o přístupech Good, Bad & Ugly pro řešení tohoto problému.

Dobrý: Výměna jmenného prostoru za Personu

První metoda (Namespace Replacement) využívá Motio's, IQ osobnosti produkt. Při použití tohoto přístupu bude váš stávající obor názvů „nahrazen“ speciálním oborem jmen Persona, který vám umožní virtualizovat všechny principy zabezpečení, které jsou vystaveny Cognos. Již existující principy zabezpečení budou vystaveny Cognos s přesně stejnou CAMID jako dříve, přestože mohou být zálohovány libovolným počtem externích zdrojů zabezpečení (např. Active Directory, LDAP nebo dokonce databáze Persona).

Krásná část tohoto přístupu je, že vyžaduje NULOVÉ změny vašeho obsahu Cognos. Důvodem je, že Persona může udržovat KAMIDY již existujících jistin, i když jsou zálohovány novým zdrojem. Takže ... všechny ty desítky tisíc referencí CAMID ve vašem Content Store, externích modelech a historických kostkách? Mohou zůstat přesně takoví, jací jsou. Není vyžadována žádná práce.

Toto je zdaleka nejméně rizikový přístup s nejnižším dopadem, který můžete použít k přechodu stávajícího prostředí Cognos z jednoho externího zdroje zabezpečení na jiný. Lze to provést za méně než hodinu s přibližně 5 minutami prostojů Cognos (jediným prostojem Cognos je restartování Cognosu, jakmile nakonfigurujete obor názvů Persona).

Bad: Migrace jmenného prostoru pomocí Persony

Pokud snadný přístup s nízkým rizikem prostě není váš šálek čaje, pak ano is jinou možnost.

Personu lze také použít k provedení migrace oboru názvů.

To zahrnuje instalaci druhého oboru názvů ověřování do vašeho prostředí Cognos, mapování (doufejme) všech vašich stávajících principů zabezpečení (ze starého oboru názvů) na odpovídající objekty v novém oboru názvů, poté (zde je ta zábavná část), hledání, mapování a aktualizace každého jediná reference CAMID, která existuje ve vašem prostředí Cognos: váš Content Store, Framework Models, Transformer Models, Historic cubes, TM1 Applications, Planning Applications atd.

Tento přístup bývá stresující a náročný na proces, ale pokud jste typ správce Cognos, který potřebuje trochu adrenalinu, aby se cítil naživu (a nevadí mu pozdní noční / ranní telefonáty), pak možná… tento je možnost, kterou hledáte?

Personu lze použít k automatizaci částí tohoto procesu. Pomůže vám vytvořit mapování mezi starými principy zabezpečení a novými principy zabezpečení, zautomatizovat logiku hrubé síly „najít, analyzovat, aktualizovat“ pro obsah ve vašem úložišti obsahu atd. Jaké Persona zde může automatizovat některé úkoly práce v tomto přístupu zahrnuje spíše „lidi a procesy“ než skutečnou technologii.

Například - kompilovat informace o každém modelu Framework Manager, každém modelu Transformer, každé aplikaci Planning / TM1, každé aplikaci SDK, kdo je vlastní, a plánování, jak budou aktualizovány a znovu distribuovány, může být hodně práce. Koordinace výpadků pro každé prostředí Cognos, ve kterém se o to chcete pokusit, a okna údržby, během nichž se můžete pokusit o migraci, mohou zahrnovat plánování a „prostoje“ Cognos. Vymyslet (a spustit) efektivní testovací plán pro vaši migraci může být také docela medvědí.

Je také zcela normální, že budete chtít tento proces provést nejprve v neproduktivním prostředí před zkoušet to ve výrobě.

Přestože migrace Namespace s Personou funguje (a je mnohem lepší než níže uvedený „Ošklivý“ přístup), je invazivnější, riskantnější, zahrnuje mnohem více personálu a její provedení zabere mnohem více pracovních hodin než výměna jmenného prostoru. Migraci je obvykle nutné provádět „mimo pracovní dobu“, zatímco prostředí Cognos je stále online, ale omezené používání formulářů koncovými uživateli.

Ugly: Služby ruční migrace prostoru názvů

Ošklivá metoda zahrnuje nezáviděníhodný přístup k pokusu o ruční migrovat z jednoho oboru názvů ověřování do jiného. To zahrnuje připojení druhého oboru názvů ověřování k vašemu prostředí Cognos a následnému pokusu ručně přesunout nebo znovu vytvořit velkou část stávajícího obsahu a konfigurace Cognos.

Pomocí tohoto přístupu se například správce Cognos může pokusit:

1. Znovu vytvořte skupiny a role v novém oboru názvů
2. Znovu vytvořte členství těchto skupin a rolí v novém oboru názvů
3. Ručně zkopírujte obsah mých složek, uživatelské preference, karty portálu atd. Z každého zdrojového účtu do každého cílového účtu
4. Najděte všechny sady zásad v úložišti obsahu a aktualizujte je tak, aby odkazovaly na ekvivalentní objekty v novém oboru názvů přesně stejným způsobem, jakým odkazovaly na objekty ze starého oboru názvů.
5. Znovu vytvořte všechny plány a naplňte je odpovídajícími pověřeními, příjemci atd.
6. Resetujte všechny vlastnosti „vlastník“ a „kontakt“ všech objektů v obchodě Content Store
7. [Asi 40 dalších věcí v obchodě s obsahem, na které zapomenete]
8. Shromážděte všechny modely FM se zabezpečením na úrovni objektů nebo dat:
   1. Podle toho aktualizujte každý model
   2. Znovu publikujte každý model
   3. Redistribuujte upravený model zpět k původnímu autorovi
9. Podobná práce pro modely Transformer, TM1 Applications a Planning Applications, které jsou zabezpečeny proti původnímu oboru názvů
10. [a mnoho dalších]

Zatímco někteří masochisté Cognos se mohou tajně chichotat radostí nad myšlenkou kliknout 400,000 XNUMXkrát v Cognos Connection, pro většinu rozumných lidí bývá tento přístup extrémně únavný, časově náročný a náchylný k chybám. To však není největší problém tohoto přístupu.

Největší problém tohoto přístupu je, že téměř vždy vede k neúplné migraci.

Pomocí tohoto přístupu (bolestivě) najdete a pokusíte se zmapovat ty CAMID reference, o kterých víte ... ale většinou necháte všechny ty CAMID reference, které jste nevím o.

Jakmile myslet jste s tímto přístupem skončili, často ne opravdu hotovo.

Ve svém úložišti obsahu máte objekty, které již nejsou zabezpečeny tak, jak si myslíte to je, a dokonce můžete mít nevysvětlené chyby pro určité operace, které nemůžeš pořádně přiložit prst.

Důvody, proč mohou být špatné a ošklivé přístupy hrozné:

• Automatizované migrace prostoru názvů kladou velký důraz na správce obsahu. Kontrola a potenciální aktualizace každého jednotlivého objektu ve vašem Content Store může často vést k desítkám tisíc volání SDK do Cognosu (prakticky všechna proudí přes Content Manager). Tento abnormální dotaz obvykle zvyšuje využití / zatížení paměti a vystavuje správce obsahu riziku, že během migrace dojde k selhání. Pokud již máte ve svém prostředí Cognos jakoukoli nestabilitu, měli byste se tohoto přístupu velmi obávat.
• Migrace oboru názvů vyžadují rozsáhlé okno údržby. Cognos musí být spuštěn, ale nechcete, aby lidé během procesu migrace prováděli změny. To bude obvykle vyžadovat spuštění migrace oboru názvů, když nikdo jiný nepracuje, řekněme v pátek večer ve 10 hodin. Nikdo nechce v pátek večer ve 10 hodin zahájit stresující projekt. Nemluvě o tom, že vaše mentální schopnosti pravděpodobně nemají nejlepší pracovní noci a víkendy na projektu, který dělá vyžadujte, abyste byli ostří!
• Zmínil jsem se, že jmenný prostor Migrace jsou časově i pracovně náročné. Tady je k tomu trochu více:
  • Proces mapování obsahu by měl být prováděn přesně a vyžaduje týmovou spolupráci a mnoho hodin práce.
  • Ke kontrole chyb nebo problémů s migrací je zapotřebí více běhů naprázdno. Typická migrace neprobíhá dokonale na první pokus. Budete také potřebovat platnou zálohu vašeho obchodu s obsahem, kterou lze v takových případech obnovit. Viděli jsme mnoho organizací, které nemají k dispozici dobrou zálohu (nebo mají zálohu, o které si neuvědomují, že je neúplná).
  • Musíte všechno identifikovat venku úložiště obsahu, které může být potenciálně ovlivněno (rámcové modely, transformátorové modely atd.). Tento úkol může zahrnovat koordinaci mezi více týmy (zejména ve velkých sdílených prostředích BI).
  • Potřebujete dobrý testovací plán, který zahrnuje reprezentativní lidi s různým stupněm přístupu k vašemu obsahu Cognos. Klíčem zde je ověřit krátce po dokončení migrace, zda je vše plně migrováno a funguje tak, jak očekáváte. Obvykle je nepraktické vše ověřit, takže nakonec ověříte, co doufáte, jsou reprezentativní vzorky.
• Musíte mít broad znalost prostředí Cognos a věcí, které na něm závisí. Například historické kostky s vlastními pohledy MUSÍ být přestavěny, pokud se vydáte cestou NSM.
• Co když vy nebo společnost, které jste outsourcovali migraci oboru názvů, na něco zapomene, například ... aplikace SDK? Jakmile přepnete přepínač, tyto věci přestanou fungovat, pokud nejsou správně aktualizovány. Máte zavedené řádné kontroly, abyste si toho okamžitě všimli, nebo bude trvat několik týdnů / měsíců, než se příznaky začnou objevovat?
• Pokud jste podstoupili četné upgrady Cognos, můžete mít potenciálně ve svém Content Store objekty, které jsou v nekonzistentním stavu. Pokud nepracujete se sadou SDK, nebudete moci zobrazit, které objekty jsou v tomto stavu.

Proč je náhrada jmenného prostoru nejlepší volbou

Klíčové rizikové faktory a časově náročné kroky, které jsem právě nastínil, jsou odstraněny, když je použita metoda nahrazení Persona Namespace. Pomocí přístupu Namespace Replacement máte 5 minut Cognos prostoje a žádný z vašeho obsahu se nemusí měnit. Metoda „Good“ mi připadá jako uřezaná a suchá „neomylnost“. Páteční večery jsou pro odpočinek, bez zdůraznění skutečnosti, že váš Správce obsahu právě havaroval uprostřed migrace Namespace.