Перехід до іншого джерела безпеки Cognos

Коли вам потрібно переналаштувати існуюче середовище Cognos на використання іншого зовнішнього джерела безпеки (наприклад, Active Directory, LDAP тощо), можна скористатися кількома підходами. Мені подобається називати їх "хороші, погані і потворні". Перш ніж ми розглянемо ці хороші, погані та потворні підходи, давайте розглянемо деякі поширені сценарії, які мають тенденцію викликати зміни простору імен автентифікації в середовищі Cognos.

Загальні драйвери бізнесу:

Оновлення обладнання або ОС - Модернізація обладнання/інфраструктури BI може бути частим драйвером. В той час, як решта Cognos може працювати, як переможець на вашому елегантному новому обладнанні та сучасній 64-розрядній ОС, удачі вам буде перенесено вашу версію Access Manager 2005 року на цю нову платформу. Access Manager (вперше випущений разом із серією 7) - це пошана з багатьох минулих днів для багатьох клієнтів Cognos. Це єдина причина того, що багато клієнтів тримаються навколо цієї старої версії Windows Server 2003. Написання вже деякий час стоїть на стіні для Access Manager. Це застаріле програмне забезпечення. Чим швидше ви зможете від нього відійти, тим краще.

Стандартизація застосування- Організації, які хочуть об'єднати автентифікацію всіх своїх програм на одному централізованому корпоративному сервері каталогів (наприклад, LDAP, AD).

Злиття та поглинання- Компанія А купує Компанію В і потребує середовища Cognos Компанії В, щоб вказати на сервер каталогів Компанії А, не викликаючи проблем із наявним вмістом чи конфігурацією BI.

Корпоративні поглинання- Це протилежність сценарію злиття, частина компанії виділяється у власну організацію і тепер має вказати своє існуюче середовище BI на нове джерело безпеки.

Чому міграції простору імен можуть бути брудними

Вказати середовище Cognos на нове джерело безпеки не так просто, як додати новий namesace з тими самими користувачами, групами та ролями, від’єднати старий простір імен та VOILA!- усі ваші користувачі Cognos у новому просторі імен зіставляються з їх зміст. Насправді, ви часто можете закінчитись кривавим безладом на руках, і ось чому ...

Усі принципи безпеки Cognos (користувачі, групи, ролі) посилаються на унікальний ідентифікатор під назвою CAMID. Навіть якщо всі інші атрибути рівні, CAMID для користувача в існуючий простір імен аутентифікації не буде таким самим, як CAMID для цього користувача в new простору імен. Це може зруйнувати існуюче середовище Cognos. Навіть якщо у вас є лише кілька користувачів Cognos, вам слід усвідомити, що посилання на CAMID існують у МНОГО різних місцях у вашому сховищі вмісту (і навіть можуть існувати поза межами вашого магазину вмісту в моделях Framework, моделях трансформаторів, програмах TM1, кубах, програмах планування тощо) ).

Багато клієнтів Cognos помилково вважають, що CAMID насправді має значення лише для вмісту Моєї папки, уподобань користувачів тощо. Це не може бути далі від правди. Справа не лише у кількості користувачів, а у кількості об’єктів Cognos, які вам потрібні. У магазині вмісту існує понад 140 різних типів об’єктів Cognos, багато з яких можуть мати кілька посилань на CAMID.

Наприклад:

1. Нерідкі випадки, коли один розклад у вашому магазині вмісту має декілька посилань CAMID (CAMID власника розкладу, CAMID користувача, за яким має працювати розклад, CAMID кожного користувача або список розповсюдження, який він повинен надсилати генерованим звітом електронною поштою тощо).
2. Кожен об’єкт у Cognos має політику безпеки, яка визначає, які користувачі можуть отримати доступ до об’єкта (подумайте «Вкладка дозволів»). Єдина політика безпеки, що висить з цієї папки в Cognos Connection, має посилання CAMID для кожного користувача, групи та ролі, яка зазначена в цій політиці.
3. Сподіваюся, ви зрозуміли суть - цей список можна продовжувати і продовжувати!

Нерідкі випадки, коли великий магазин вмісту містить десятки тисяч посилань на CAMID (і ми бачили деякі великі з сотнями тисяч).

Тепер подумайте про те, що є ваш Cognos, і ви можете побачити, що потенційно маєте справу з ордами посилань CAMID. Це може бути кошмар! Переключення (або повторна настройка) вашого простору імен автентифікації може залишити всі ці посилання на CAMID у нерозв’язному стані. Це неминуче призводить до проблем із вмістом та конфігурацією Cognos (наприклад, розклади, які більше не виконуються, вміст, який більше не захищений таким, яким ви вважаєте, пакети або куби, які більше не реалізують належним чином рівень безпеки даних, втрату вмісту Моєї папки та користувача уподобання тощо).

Методи переходу простору імен Cognos

Тепер, знаючи, що середовище 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 може бути використана для автоматизації частин цього процесу. Це допоможе вам створити зіставлення між старими принципалами безпеки та новими принципами безпеки, автоматизувати грубу силу логіки "знаходити, аналізувати, оновлювати" вміст у вашому магазині вмісту тощо. Що Персона може значно автоматизувати деякі завдання тут робота у цьому підході включає “людей та процес”, а не фактичну технологію.

Наприклад - складання інформації про кожну модель Framework Manager, кожну модель Transformer, кожну програму Planning / TM1, кожну програму SDK, хто є їх власником, і планування того, як вони будуть оновлюватися та розповсюджуватися, може бути великою роботою. Координація відключень для кожного з середовищ Cognos, у яких ви хочете це спробувати, та вікна технічного обслуговування, під час яких ви можете спробувати міграцію, можуть включати планування та “час простою” Cognos. Створення (та виконання) ефективного плану тестування після вашої міграції також може бути досить неприємним.

Також цілком нормально, що ви спочатку захочете виконати цей процес у невиробничому середовищі перед тим пробуючи це у виробництві.

Хоча міграція простору імен за допомогою Persona працює (і це набагато краще, ніж підхід "Потворний" нижче), він є більш інвазивним, ризикованим, включає набагато більше персоналу і потребує набагато більше робочих годин, ніж заміна простору імен. Як правило, міграції потрібно виконувати в “неробочі години”, поки середовище Cognos все ще перебуває в мережі, але обмежене використання форм кінцевими користувачами.

Потворний: Служби міграції простору імен вручну

Потворний метод передбачає незавидний підхід до спроб вручну мігрувати з одного простору імен автентифікації в інший. Це передбачає підключення другого простору імен автентифікації до вашого середовища Cognos, а потім спробу вручну перемістити або відтворити більшу частину наявного вмісту та конфігурації Cognos.

Наприклад, використовуючи цей підхід, адміністратор Cognos може спробувати:

1. Відтворіть групи та ролі в новому просторі імен
2. Відновіть членство цих груп та ролі у новому просторі імен
3. Копіюйте вручну вміст моїх папок, налаштування користувачів, вкладки порталу тощо з кожного вихідного облікового запису до кожного цільового облікового запису
4. Знайдіть усі набори політик у Сховищі вмісту та оновіть їх до посилань на еквівалентних принципалів у новому просторі імен так само, як це стосується принципалів зі старого простору імен
5. Відтворіть усі розклади та заповніть їх відповідними обліковими даними, одержувачами тощо.
6. Скиньте всі властивості "власника" та "контакту" всіх об'єктів у сховищі вмісту
7. [Ще близько 40 речей у магазині вмісту, про які ви забудете]
8. Зберіть усі моделі FM із захистом об’єктів або рівнів даних:
   1. Відповідно оновіть кожну модель
   2. Повторно опублікуйте кожну модель
   3. Поширюйте змінену модель назад до оригінального автора
9. Подібна робота для моделей Transformer, додатків TM1 та програм для планування, які захищені від вихідного простору імен
10. [та багато іншого]

Хоча деякі мазохісти Cognos можуть таємно хихикати від радості від ідеї натиснути 400,000 XNUMX разів у програмі Cognos Connection, для більшості розумних людей цей підхід, як правило, є надзвичайно нудним, трудомістким та схильним до помилок. Однак це не найбільша проблема такого підходу.

Найбільша проблема такого підходу в тому, що він майже такий завжди призводить до неповної міграції.

Використовуючи цей підхід, ви (болісно) знаходите та намагаєтесь зіставити ті посилання на CAMID, які вам відомі… але, як правило, залишаєте всі ці посилання на CAMID, які ви не знаю про.

Після того як ви думати Ви закінчили з цим підходом, часто це не так насправді зроблено.

У вашому магазині вмісту є об’єкти, які більше не захищені таким, яким ви їх вважаєте… у вас є розклади, які не працюють так, як раніше, у вас є дані, які більше не захищені так, як ви думаєте це так, і ви навіть можете мати незрозумілі помилки для певних операцій, які ти не можеш покласти пальцем.

Причини, чому поганий і потворний підхід може бути жахливим:

• Автоматизована міграція простору імен створює великий навантаження на Менеджер вмісту. Перевірка та потенційне оновлення кожного окремого об’єкта у вашому Сховищі вмісту часто може призвести до десятків тисяч викликів SDK до Cognos (практично всі вони проходять через Менеджер вмісту). Цей ненормальний запит зазвичай збільшує використання / завантаження пам’яті та наражає Менеджер вмісту на ризик збою під час міграції. Якщо у вашому середовищі Cognos вже є якась нестабільність, вам слід дуже боятися такого підходу.
• Міграція простору імен вимагає значного періоду обслуговування. Cognos потрібно активувати, але ви не хочете, щоб люди вносили зміни під час процесу міграції. Для цього зазвичай потрібно, щоб міграція простору імен розпочалася, коли ніхто інший не працює, скажімо о 10:10 у п’ятницю ввечері. Ніхто не хоче розпочинати стрес -проект о XNUMX:XNUMX у п’ятницю ввечері. Не кажучи вже про те, що ваші розумові здібності, ймовірно, не найкращі робочі ночі та вихідні на проекті робить вимагайте від вас гостроти!
• Я згадував, що міграція простору імен займає багато часу та праці. Ось трохи більше про це:
  • Процес картографування вмісту повинен виконуватися з точністю, що вимагає співпраці з командою та багато робочих годин.
  • Щоб перевірити наявність помилок або проблем із міграцією, потрібно кілька сухих запусків. Типова міграція не проходить ідеально з першої спроби. Вам також знадобиться дійсна резервна копія вашого магазину вмісту, яку можна відновити в таких випадках. Ми бачили багато організацій, які не мають хорошої резервної копії (або мають резервну копію, яку вони не усвідомлюють як неповну).
  • Потрібно все визначити поза сховище вмісту, на яке може бути потенційно вплинуто (моделі каркасів, моделі трансформаторів тощо). Це завдання може включати координацію між кількома командами (особливо у великих спільних середовищах BI).
  • Вам потрібен хороший план тестування, який передбачає представницьких людей з різним ступенем доступу до вашого вмісту Cognos. Ключовим моментом тут є перевірка незабаром після завершення міграції того, що все повністю перенесено та функціонує так, як ви очікуєте. Як правило, перевіряти все непрактично, тому ви в кінцевому підсумку перевіряєте те, що, як ви сподіваєтесь, є репрезентативними зразками.
• Ви повинні мати бroad знання про середовище Cognos та речі, які від нього залежать. Наприклад, історичні куби зі спеціальними представленнями ПОВИННІ бути відновлені, якщо ви пройдете маршрут NSM.
• Що робити, якщо ви або компанія, яку ви передали на аутсорсинг, перенесли простір імен, щоб забути про щось, наприклад ... програми SDK? Після того, як ви натиснули перемикач, ці речі перестають працювати, якщо вони не оновлені належним чином. Чи є у вас належні перевірки, щоб негайно помітити це, або пройде кілька тижнів / місяців, перш ніж симптоми почнуть проявлятися?
• Якщо ви пройшли численні оновлення Cognos, у вашому магазині вмісту потенційно можуть бути об’єкти, які перебувають у несумісному стані. Якщо ви не працюєте з SDK, ви не зможете побачити, які об’єкти знаходяться в цьому стані.

Чому заміна простору імен - найкращий варіант

Ключові фактори ризику та кроки, що забирають багато часу, які я щойно описав, усуваються, коли використовується метод заміни простору імен Persona. Використовуючи підхід до заміни простору імен, у вас є 5 хвилин простою Cognos, і жоден ваш вміст не повинен змінюватися. «Хороший» метод здається мені різаним і сухим «безглуздим». Вечори п’ятниці - це розслаблення, а не напруження через той факт, що ваш Менеджер вмісту просто розбився посеред міграції простору імен.