Транзиција кон различен извор на безбедност Cognos

Кога треба да ја реконфигурирате постоечката средина на Cognos за да користите различен надворешен извор на безбедност (на пр. Active Directory, LDAP, итн.), Постојат неколку пристапи што можете да ги преземете. Сакам да ги нарекувам „Добрите, Лошите и Грдите“. Пред да ги истражиме овие добри, лоши и грди пристапи, ајде да погледнеме неколку вообичаени сценарија што имаат тенденција да ги поттикнат промените на именскиот простор на автентикација во средина на Коњос.

Заеднички деловни двигатели:

Ажурирање на хардвер или оперативен систем - Модернизирањето на хардверот/инфраструктурата на БИ може да биде чест двигател. Додека остатокот од Cognos може да работи како шампион на вашиот елегантен нов хардвер и модерен 64-битен оперативен систем, со среќа да ја мигрирате вашата верзија на Access Manager од 2005 година на новата платформа. Управувачот за пристап (првпат објавен со Серија 7) е почитуван приход од минатите денови за многу клиенти на Cognos. Тоа е единствената причина што многу клиенти ја чуваат околу онаа стара верзија на Windows Server 2003. Пишувањето е на wallидот за Access Manager веќе подолго време. Тоа е наследен софтвер. Колку побрзо можете да се оддалечите од него, толку подобро.

Стандардизација на апликацијата- Организации кои сакаат да ја консолидираат автентикацијата на сите нивни апликации против еден централно администриран сервер за корпоративни директориуми (на пр. LDAP, AD).

Спојувања и преземања- Компанијата А ја купува Компанијата Б и има потреба од опкружувањето Cognos на Компанијата Б за да укаже на серверот на директориуми на Компанијата А, без да предизвика проблеми со нивната постоечка BI содржина или конфигурација.

Корпоративни пренасочувања- Ова е спротивно од сценариото за спојување, дел од компанијата е префрлен во сопствен ентитет и сега треба да ја посочи постојната БИ -околина кон новиот извор на безбедност.

Зошто миграциите на именскиот простор можат да бидат неуредни

Посочувањето на околината на Cognos кон нов безбедносен извор не е едноставно како додавање на нова именска листа со исти корисници, групи и улоги, исклучување на стариот именски простор и VOILA!- сите ваши корисници на Cognos во новиот именски простор се совпаѓаат со нивната содржина. Всушност, честопати може да завршите со крвава збрка на вашите раце, и еве зошто…

Сите принципи за безбедност на Cognos (корисници, групи, улоги) се наведени со единствен идентификатор наречен CAMID. Дури и ако сите други атрибути се еднакви, CAMID за корисник во постоечките именскиот простор за автентикација нема да биде ист како CAMID за тој корисник во нови именски простор. Ова може да уништи хаос за постоечката средина Коњос. Дури и ако имате само неколку корисници на Cognos, треба да сфатите дека CAMID -референци постојат на МНОГУ различни места во вашата продавница за содржини (и може да постојат и надвор од вашата продавница за содржини во рамки модели, трансформаторски модели, апликации TM1, коцки, апликации за планирање итн. ).

Многу клиенти на Cognos погрешно веруваат дека CAMID е навистина важна само за содржината на Мојата папка, преференциите на корисниците итн. Ова не може да биде подалеку од вистината. Не е само прашање на бројот на корисници што ги имате, туку количината на Cognos објекти за кои треба да се грижите. Има над 140 различни типови на објекти Cognos само во продавницата за содржини, од кои многу може да имаат повеќе CAMID референци.

На пример:

1. Не е невообичаено еден Распоред во вашата продавница за содржини да има повеќе CAMID референци (CAMID на сопственикот на распоредот, CAMID на корисникот распоредот треба да работи како, CAMID на секој корисник или листа на дистрибуции на која треба да испрати генериран извештај за излез до , итн.).
2. Секој објект во Cognos има безбедносна политика што регулира кои корисници можат да пристапат до објектот (размислете „Табулаторот за дозволи“). Една единствена безбедносна политика што се исклучува од таа папка во Cognos Connection има CAMID референца за секој корисник, група и улога што е наведена во таа политика.
3. Се надеваме дека ја разбравте поентата - оваа листа продолжува и продолжува!

Не е невообичаено големата продавница за содржини да содржи десетици илјади референци за CAMID (и видовме некои големи со стотици илјади).

Сега, направете математика за она што е внатре вашиот Cognos средина и можете да видите дека потенцијално се занимавате со орди од референци за CAMID. Може да биде кошмар! Префрлањето (или повторното конфигурирање) на именскиот простор за автентикација може да ги остави сите овие CAMID референци во нерешлива состојба. Ова неизбежно води до проблеми со содржината и конфигурацијата на Cognos (на пр. Распореди што повеќе не се извршуваат, содржини што повеќе не се обезбедени како што мислите, пакети или коцки што повеќе не ја имплементираат безбедноста на нивото на податоци, губење на содржината и корисникот на Мојата папка) параметри, итн.).

Методи на транзиција на Cognos Namespace

Сега, знаејќи дека Cognos средината може да има десетици илјади CAMID референци кои ќе бараат пронаоѓање, мапирање и ажурирање на нивната соодветна нова CAMID вредност во новиот именски простор за автентикација, да разговараме за Добрите, Лошите и Грдите пристапи за решавање на овој проблем.

Добриот: Замена на именскиот простор со Persona

Првиот метод (Замена на именски простор) користи Motio's, Персона IQ производ. Имајќи го овој пристап, вашиот постоечки именски простор се „заменува“ со специјален именски простор Persona кој ви овозможува да ги виртуелизирате сите безбедносни принципи што се изложени на Cognos. Претходно постоечките безбедносни принципи ќе бидат изложени на Cognos со иста CAMID како и досега, иако тие можат да бидат поддржани од било кој број надворешни безбедносни извори (на пр. Active Directory, LDAP или дури и базата на податоци Persona).

Убавиот дел за овој пристап е тоа што бара НУЛА промени во вашата содржина на Cognos. Ова се случува затоа што Persona може да ги одржува CAMID-овите на веќе постоечките директори, дури и кога тие се поддржани од нов извор. Значи ... сите тие десетици илјади CAMID референци во вашата продавница за содржини, надворешни модели и историски коцки? Можат да останат точно такви какви што се. Не е потребна работа.

Ова е далеку најмалку ризичниот, пристапот со најниско влијание што можете да го користите за транзиција на постојната средина Cognos од еден надворешен извор на безбедност во друг. Може да се направи за помалку од еден час со околу 5 минути застој во Cognos (единствениот прекин во Cognos е рестартирање на Cognos откако ќе го конфигурирате именскиот простор Persona).

Лошиот: Миграција на именски простор користејќи ја Persona

Ако лесниот пристап со низок ризик едноставно не е чаша, тогаш таму is друга опција.

Persona исто така може да се користи за извршување миграција на именски простор.

Ова вклучува инсталирање на втор именски простор за автентикација во вашата средина Cognos, мапирање (се надеваме) на сите ваши постоечки безбедносни принципи (од стариот именски простор) до соодветните принципи во новиот именски простор, потоа (тука е забавниот дел), пронаоѓање, мапирање и ажурирање на секој единечна референца за CAMID што постои во вашата средина Cognos: вашата продавница за содржина, модели на рамки, модели на трансформатори, историски коцки, апликации TM1, апликации за планирање итн.

Овој пристап има тенденција да биде стресен и интензивен за процеси, но ако сте таков администратор на Cognos на кој му е потребен малку адреналин за да се чувствува жив (и не му пречи доцна навечер / телефонски повици рано наутро), тогаш можеби… оваа дали е опцијата што ја барате?

Persona може да се користи за да помогне во автоматизирање на делови од овој процес. Тоа ќе ви помогне да креирате мапирање помеѓу старите начела за безбедност и новите директори за безбедност, да ја автоматизирате грубата логика „пронајдете, анализирајте, ажурирајте“ за содржина во вашата продавница со содржина, итн. Она што Persona може да ги автоматизира некои од задачите овде, многу работата во овој пристап вклучува „луѓе и процес“, а не вистинска технологија.

На пример - составувањето информации за секој модел на Framework Manager, секој модел на Transformer, секоја апликација Planning / TM1, секоја апликација SDK, кој ги поседува и планирањето како тие ќе се ажурираат и прераспределуваат може да биде многу работа. Координирање на прекините за секоја од средините на Коњос во која сакате да се обидете и прозорци за одржување, за време на кои можете да се обидете, миграцијата може да вклучува планирање и „ненадејно време“ на Коњос. Излегувањето (и извршувањето) на ефективен тест план за после вашата миграција, исто така, може да биде доста мечка.

Исто така, сосема е нормално дека ќе сакате да го направите овој процес прво во непродуктивна средина пред обидувајќи се во производството.

Додека миграцијата на именски простор со Персона функционира (и е далеку подобра од „грдиот“ пристап подолу), таа е поинвазивна, поризична, вклучува многу повеќе персонал и потребни се многу повеќе часови од човекот отколку замена на именски простор. Обично миграциите треба да се направат за време на „слободни часови“, додека околината на Коњос е с online уште онлајн, но ограничена употреба од страна на крајните корисници.

Грдата: Рачни услуги за миграција на именски простор

Грдиот метод вклучува незавиден пристап за обид за рачно мигрирајте од еден именски простор за автентикација во друг. Ова вклучува поврзување на втор именски простор за автентикација со вашата околина Cognos, потоа обид рачно да преместите или рекреирате голем дел од постојната содржина и конфигурација на Cognos.

На пример, користејќи го овој пристап, администраторот на Cognos може да се обиде да:

1. Рекреирајте ги групите и улогите во новиот именски простор
2. Рекреирајте ги членствата на тие групи и улоги во новиот именски простор
3. Рачно копирајте ја содржината на моите папки, кориснички параметри, картички на портали, итн. Од секоја изворна сметка до секоја целна сметка
4. Најдете ги сите Поставки за Политика во Продавницата за содржини и ажурирајте ги на референтни еквивалентни принципи во новиот именски простор на ист начин како што се повикуваше на принципите од стариот именски простор
5. Рекреирајте ги сите распореди и пополнете ги со соодветни ингеренции, примачи, итн.
6. Ресетирајте ги сите својства „сопственик“ и „контакт“ на сите објекти во Продавницата за содржини
7. [Околу 40 други работи во Продавницата за содржини што ќе ги заборавите]
8. Соберете ги сите FM модели со безбедност на објекти или ниво на податоци:
   1. Ажурирајте го секој модел соодветно
   2. Објавете го секој модел
   3. Прераспределете го изменетиот модел назад до оригиналниот автор
9. Слична работа за модели на трансформатори, апликации TM1 и апликации за планирање кои се обезбедени од оригиналниот простор за имиња
10. [и многу повеќе]

Додека некои мазохисти на Коњос би можеле тајно да се кикотат од радост при идејата да кликнат 400,000 пати во Cognos Connection, за повеќето разумни луѓе, овој пристап има тенденција да биде крајно досаден, одзема време и е склон кон грешки. Сепак, тоа не е најголемиот проблем со овој пристап.

Најголемиот проблем со овој пристап е тоа што речиси секогаш доведува до нецелосна миграција.

Користејќи го овој пристап, вие (болно) ги наоѓате и се обидувате да ги мапирате оние CAMID референци за кои знаете ... но имате тенденција да ги оставите сите оние CAMID референци што не знам за.

Откако ќе мислам завршивте со овој пристап, често не сте навистина завршено.

Имате предмети во вашата продавница за содржини што веќе не се обезбедени онака како што мислите дека се ... имате распоред што не функционира како што се работеше, имате податоци што веќе не се обезбедени како што мислите тоа е, па дури и може да имате необјасниви грешки за одредени операции кои навистина не можеш да ставиш прст.

Причини зошто лошите и грдите пристапи можат да бидат страшни:

• Автоматизираните миграции на именскиот простор ставаат голем стрес врз Управувачот со содржини. Проверката и потенцијалното ажурирање на секој објект во вашата продавница за содржини, честопати може да резултира со десетици илјади SDK повици до Cognos (практично сите течат низ Управувачот со содржини). Ова абнормално барање обично го зголемува користењето / оптоварувањето на меморијата и го става Менаџерот на содржини во опасност од пад за време на миграцијата. Ако веќе имате нестабилност во вашата околина Коњос, треба да се плашите од овој пристап.
• Миграциите на именскиот простор бараат голем прозорец за одржување. Коњос треба да се крене, но не сакате луѓето да прават промени за време на миграцискиот процес. Ова обично бара миграција на именски простор да започне кога никој друг не работи, да речеме во 10 часот во петок навечер. Никој не сака да започне стресен проект во петок навечер во 10 часот. Да не зборуваме, вашите ментални способности веројатно не се во најдобри работни ноќи и викенди на проект што не бараат да бидете остри!
• Споменав дека именските простории Миграциите се интензивни за време и труд. Еве уште малку за тоа:
  • Процесот на мапирање на содржината треба да се направи со прецизност и тоа бара тимска соработка и многу работни часови.
  • Потребни се повеќе суви работи за да се проверат дали има грешки или проблеми со миграција. Типична миграција не оди совршено при првиот обид. Исто така, ќе ви треба валидна резервна копија од вашата продавница за содржини што може да се врати во такви случаи. Видовме многу организации кои немаат добра резервна копија на располагање (или имаат резервна копија за која не сфаќаат дека е нецелосна).
  • Треба да идентификувате с надвор од продавницата за содржини што може да биде потенцијално засегната (модели на рамки, модели на трансформатори, итн.). Оваа задача може да вклучува координација помеѓу повеќе тимови (особено во големи заеднички опкружувања на БИ).
  • Потребен ви е добар тест план кој вклучува репрезентативни луѓе со различен степен на пристап до вашата содржина на Cognos. Клучот овде е да се потврди кратко време откако ќе заврши миграцијата дека с everything е целосно мигрирано и функционира како што очекувате. Типично е непрактично да се провери с everything, па на крајот ќе проверите што се надевате дека се репрезентативни примероци.
• Мора да имате бroad познавање на околината Коњос и нештата што зависат од неа. На пример, историските коцки со сопствени прикази МОРА да се обноват ако одите по трасата НСМ.
• Што ако вие или компанијата што ја аутсорсирате миграцијата на именскиот простор за да заборавите на нешто, како што се ... апликации за SDK? Откако ќе го превртите прекинувачот, овие работи престануваат да работат ако не се ажурираат правилно. Дали имате соодветни проверки за да го забележите ова веднаш, или ќе поминат неколку недели / месеци пред симптомите да почнат да се појавуваат?
• Ако сте претрпеле бројни надградби на Cognos, потенцијално може да имате објекти во продавницата за содржини што се во неконзистентна состојба. Ако не работите со SDK, нема да можете да видите кои објекти се во оваа состојба.

Зошто замена на именски простор е најдобрата опција

Клучните фактори на ризик и чекорите што одземаат многу време што ги наведов се елиминираат кога се користи методот за замена на именскиот простор Persona. Користејќи го пристапот за замена на именски простор, имате 5 минути застој во Cognos и ниту една од вашите содржини не мора да се промени. Методот „Добар“ ми изгледа како пресечен и сув „несоодветен“. Петочните вечери се наменети за релаксирање, а не за нагласување поради фактот што вашиот Менаџер на содржини штотуку се урна среде миграција на именски простор.