Transisi ke Sumber Keamanan Cognos yang Berbeda

Ketika Anda perlu mengkonfigurasi ulang lingkungan Cognos yang ada untuk menggunakan sumber keamanan eksternal yang berbeda (misalnya Active Directory, LDAP, dll), ada beberapa pendekatan yang dapat Anda ambil. Saya suka memanggil mereka, "Yang Baik, Yang Buruk, dan Yang Jelek." Sebelum kita menjelajahi pendekatan Baik, Buruk, dan Jelek ini, mari kita lihat beberapa skenario umum yang cenderung mendorong perubahan namespace otentikasi di lingkungan Cognos.

Penggerak Bisnis Umum:

Memperbarui Perangkat Keras atau OS – Modernisasi perangkat keras/infrastruktur BI dapat menjadi pendorong yang sering. Sementara Cognos lainnya dapat berjalan seperti jagoan pada perangkat keras baru Anda yang ramping dan OS 64-bit modern, semoga berhasil memigrasikan Access Manager versi sekitar 2005 Anda ke platform baru itu. Access Manager (pertama dirilis dengan Seri 7) adalah peninggalan terhormat dari masa lalu bagi banyak pelanggan Cognos. Ini adalah satu-satunya alasan mengapa banyak pelanggan tetap menggunakan Windows Server 2003 versi lama yang kejam itu. Penulisan Access Manager telah lama tidak ada di dinding. Ini adalah perangkat lunak warisan. Semakin cepat Anda dapat beralih darinya, semakin baik.

Standarisasi Aplikasi– Organisasi yang ingin menggabungkan otentikasi semua aplikasi mereka terhadap satu server direktori perusahaan yang dikelola secara terpusat (misalnya LDAP, AD).

Merger & Akuisisi– Perusahaan A membeli Perusahaan B dan membutuhkan lingkungan Cognos Perusahaan B untuk menunjuk ke server direktori Perusahaan A, tanpa menyebabkan masalah pada konten atau konfigurasi BI yang ada.

Divestasi Perusahaan– Ini adalah kebalikan dari skenario merger, sebagian perusahaan dipisahkan menjadi entitasnya sendiri dan sekarang perlu mengarahkan lingkungan BI yang ada ke sumber keamanan baru.

Mengapa Migrasi Namespace Bisa Berantakan

Mengarahkan lingkungan Cognos ke sumber keamanan baru tidak sesederhana menambahkan nameapce baru dengan pengguna, grup, dan peran yang sama, memutuskan namespace lama, dan VOILA!- semua pengguna Cognos Anda di namespace baru dicocokkan dengan konten mereka. Faktanya, Anda sering berakhir dengan kekacauan berdarah di tangan Anda, dan inilah alasannya ...

Semua prinsip keamanan Cognos (pengguna, grup, peran) direferensikan oleh pengidentifikasi unik yang disebut CAMID. Bahkan jika semua atribut lainnya sama, CAMID untuk pengguna di ada namespace otentikasi tidak akan sama dengan CAMID untuk pengguna itu di yang baru ruang nama. Ini dapat merusak malapetaka pada lingkungan Cognos yang ada. Bahkan jika Anda hanya memiliki beberapa pengguna Cognos, Anda perlu menyadari bahwa referensi CAMID ada di BANYAK tempat berbeda di Toko Konten Anda (dan bahkan dapat ada di luar Toko Konten Anda dalam model Kerangka, Model Transformer, Aplikasi TM1, Kubus, Aplikasi Perencanaan, dll. ).

Banyak pelanggan Cognos secara keliru percaya bahwa CAMID benar-benar hanya penting untuk konten Folder Saya, preferensi pengguna, dll. Ini tidak bisa jauh dari kebenaran. Ini bukan hanya soal jumlah pengguna yang Anda miliki, tetapi jumlah objek Cognos yang perlu Anda perhatikan. Ada lebih dari 140 jenis objek Cognos yang berbeda hanya di Toko Konten, banyak di antaranya mungkin memiliki beberapa referensi CAMID.

Sebagai contoh:

1. Tidak jarang satu Jadwal di Toko Konten Anda memiliki beberapa referensi CAMID (CAMID dari pemilik jadwal, CAMID pengguna jadwal yang harus dijalankan, CAMID dari setiap pengguna atau daftar distribusi yang harus dikirim melalui email hasil laporan yang dihasilkan ke , dll.).
2. Setiap objek di Cognos memiliki kebijakan keamanan yang mengatur pengguna mana yang dapat mengakses objek tersebut (pikirkan "Tab Izin"). Kebijakan keamanan tunggal yang menggantung folder itu di Cognos Connection memiliki referensi CAMID untuk setiap pengguna, grup & peran yang ditentukan dalam kebijakan itu.
3. Semoga Anda mengerti maksudnya – daftar ini terus berlanjut!

Bukan hal yang aneh jika Toko Konten yang cukup besar berisi puluhan ribu referensi CAMID (dan kami telah melihat beberapa referensi besar dengan ratusan ribu).

Sekarang, lakukan matematika pada apa yang ada di Tujuan lingkungan Cognos dan Anda dapat melihat bahwa Anda berpotensi berurusan dengan gerombolan referensi CAMID. Ini bisa menjadi mimpi buruk! Mengalihkan (atau mengonfigurasi ulang) ruang nama autentikasi Anda dapat membuat semua referensi CAMID ini dalam keadaan tidak dapat diselesaikan. Ini pasti mengarah ke masalah konten & konfigurasi Cognos (misalnya jadwal yang tidak lagi berjalan, konten yang tidak lagi diamankan seperti yang Anda pikirkan, paket atau kubus yang tidak lagi menerapkan keamanan tingkat data dengan benar, hilangnya konten Folder Saya dan pengguna preferensi, dll).

Metode Transisi Ruang Nama Cognos

Sekarang, mengetahui bahwa lingkungan Cognos dapat memiliki puluhan ribu referensi CAMID yang memerlukan pencarian, pemetaan, dan pembaruan ke nilai CAMID baru yang sesuai di namespace otentikasi baru, mari kita bahas pendekatan Baik, Buruk & Jelek untuk memecahkan masalah ini.

Baik: Penggantian Namespace dengan Persona

Metode pertama (Penggantian Namespace) menggunakan Motioini IQ Persona produk. Mengambil pendekatan ini, namespace Anda yang ada "diganti" dengan namespace Persona khusus yang memungkinkan Anda memvirtualisasikan semua prinsip keamanan yang terpapar ke Cognos. Prinsip keamanan yang sudah ada sebelumnya akan diekspos ke Cognos dengan CAMID yang sama persis seperti sebelumnya, meskipun mereka mungkin didukung oleh sejumlah sumber keamanan eksternal (misalnya Direktori Aktif, LDAP atau bahkan database Persona).

Bagian yang indah tentang pendekatan ini adalah bahwa hal itu memerlukan perubahan NOL pada konten Cognos Anda. Ini karena Persona dapat mempertahankan CAMID dari prinsipal yang sudah ada sebelumnya, bahkan ketika mereka didukung oleh sumber baru. Jadi… puluhan ribu referensi CAMID di Toko Konten Anda, model eksternal, dan kubus historis? Mereka bisa tetap seperti apa adanya. Tidak ada pekerjaan yang diperlukan.

Sejauh ini, ini adalah pendekatan yang paling tidak berisiko dan berdampak paling rendah yang dapat Anda gunakan untuk mentransisikan lingkungan Cognos yang ada dari satu sumber keamanan eksternal ke sumber keamanan eksternal lainnya. Ini dapat dilakukan dalam waktu kurang dari satu jam dengan sekitar 5 menit waktu henti Cognos (satu-satunya waktu henti Cognos adalah memulai ulang Cognos setelah Anda mengonfigurasi namespace Persona).

The Bad: Migrasi Namespace menggunakan Persona

Jika pendekatan yang mudah dan berisiko rendah bukanlah secangkir teh Anda, maka ada is pilihan lain.

Persona juga dapat digunakan untuk melakukan Migrasi Namespace.

Ini melibatkan pemasangan namespace otentikasi kedua di lingkungan Cognos Anda, memetakan (semoga) semua prinsip keamanan yang ada (dari namespace lama) ke prinsip yang sesuai di namespace baru, lalu (inilah bagian yang menyenangkan), menemukan, memetakan, dan memperbarui setiap referensi CAMID tunggal yang ada di lingkungan Cognos Anda: Toko Konten Anda, Model Kerangka, Model Transformer, Kubus Historis, Aplikasi TM1, Aplikasi Perencanaan, dll.

Pendekatan ini cenderung membuat stres dan proses intensif, tetapi jika Anda adalah jenis administrator Cognos yang membutuhkan sedikit adrenalin untuk merasa hidup (dan tidak keberatan panggilan telepon larut malam / pagi), maka mungkin… ini adalah opsi yang Anda cari?

Persona dapat digunakan untuk membantu mengotomatiskan bagian dari proses ini. Ini akan membantu Anda membuat pemetaan antara prinsip keamanan lama dan prinsip keamanan baru, mengotomatiskan logika "temukan, analisis, perbarui" brute force untuk konten di toko konten Anda, dll. Persona apa yang dapat mengotomatiskan beberapa tugas di sini, banyak pekerjaan dalam pendekatan ini melibatkan "orang dan proses" daripada teknologi yang sebenarnya.

Misalnya – mengumpulkan informasi pada setiap model Framework Manager, setiap model Transformer, setiap aplikasi Perencanaan / TM1, setiap aplikasi SDK, siapa yang memilikinya, dan merencanakan bagaimana mereka akan diperbarui dan didistribusikan ulang dapat menjadi banyak pekerjaan. Mengkoordinasikan pemadaman untuk setiap lingkungan Cognos yang ingin Anda coba dan jendela pemeliharaan di mana Anda dapat mencoba migrasi dapat melibatkan perencanaan dan "waktu henti" Cognos. Membuat (dan menjalankan) rencana pengujian yang efektif setelah migrasi Anda juga bisa sangat melelahkan.

Ini juga cukup normal bahwa Anda ingin melakukan proses ini terlebih dahulu di lingkungan non-produksi sebelum mencobanya di produksi.

Sementara Migrasi Namespace dengan Persona berhasil (dan jauh lebih baik daripada pendekatan "Jelek" di bawah), ini lebih invasif, lebih berisiko, melibatkan lebih banyak personel, dan membutuhkan lebih banyak jam kerja daripada Penggantian Namespace. Biasanya migrasi perlu dilakukan selama “jam libur”, saat lingkungan Cognos masih online, tetapi penggunaan formulir dibatasi oleh pengguna akhir.

The Ugly: Layanan Migrasi Namespace Manual

Metode Jelek melibatkan pendekatan yang tidak menyenangkan untuk mencoba manual bermigrasi dari satu namespace otentikasi ke yang lain. Ini melibatkan menghubungkan ruang nama otentikasi kedua ke lingkungan Cognos Anda, kemudian mencoba untuk memindahkan atau membuat ulang banyak konten dan konfigurasi Cognos yang ada secara manual.

Misalnya, menggunakan pendekatan ini, administrator Cognos mungkin mencoba untuk:

1. Buat ulang grup dan peran di namespace baru
2. Buat ulang keanggotaan grup dan peran tersebut di namespace baru
3. Salin konten folder saya secara manual, preferensi pengguna, tab portal, dll. dari setiap akun sumber ke setiap akun target
4. Temukan setiap Kumpulan Kebijakan di Toko Konten dan perbarui untuk mereferensikan prinsipal yang setara di namespace baru dengan cara yang sama persis dengan yang mereferensikan prinsipal dari namespace lama
5. Buat ulang semua jadwal dan isi dengan kredensial, penerima, dll.
6. Setel ulang semua properti "pemilik" dan "kontak" dari semua objek di Toko Konten
7. [Tentang 40 hal lain di Toko Konten yang akan Anda lupakan]
8. Kumpulkan semua model FM dengan keamanan tingkat objek atau data:
   1. Perbarui setiap model sesuai
   2. Publikasikan ulang setiap model
   3. Distribusikan kembali model yang dimodifikasi kembali ke penulis asli
9. Pekerjaan serupa untuk model Transformer, Aplikasi TM1 dan Aplikasi Perencanaan yang diamankan dari namespace asli
10. [dan masih banyak lagi]

Sementara beberapa masokis Cognos mungkin diam-diam tertawa terbahak-bahak dengan gagasan mengklik 400,000 kali di Cognos Connection, bagi kebanyakan orang yang masuk akal, pendekatan ini cenderung sangat membosankan, memakan waktu dan rawan kesalahan. Itu bukan masalah terbesar dengan pendekatan ini, namun.

Masalah terbesar dengan pendekatan ini adalah hampir selalu menyebabkan migrasi tidak lengkap.

Dengan menggunakan pendekatan ini, Anda (dengan susah payah) menemukan, dan mencoba memetakan referensi CAMID yang Anda ketahui…tetapi cenderung meninggalkan semua referensi CAMID yang Anda tidak tahu tentang.

Setelah Anda berpikir Anda sudah selesai dengan pendekatan ini, Anda sering tidak benar-benar dilakukan.

Anda memiliki objek di toko konten Anda yang tidak lagi diamankan seperti yang Anda pikirkan… Anda memiliki jadwal yang tidak berjalan seperti biasanya, Anda memiliki data yang tidak lagi diamankan seperti yang Anda pikirkan itu, dan Anda bahkan mungkin memiliki kesalahan yang tidak dapat dijelaskan untuk operasi tertentu yang Anda tidak bisa benar-benar meletakkan jari Anda.

Alasan Mengapa Pendekatan Buruk dan Jelek bisa Mengerikan:

• Migrasi Namespace Otomatis memberi banyak tekanan pada Pengelola Konten. Pemeriksaan dan potensi pembaruan setiap objek di Toko Konten Anda, sering kali dapat menghasilkan puluhan ribu panggilan SDK ke Cognos (hampir semuanya mengalir melalui Pengelola Konten). Kueri abnormal ini biasanya meningkatkan penggunaan/pemuatan memori dan membuat Pengelola Konten berisiko mogok selama migrasi. Jika Anda sudah memiliki sejumlah ketidakstabilan di lingkungan Cognos Anda, Anda harus sangat takut dengan pendekatan ini.
• Migrasi Namespace memerlukan jendela pemeliharaan yang cukup besar. Cognos harus aktif, tetapi Anda tidak ingin orang membuat perubahan selama proses migrasi. Ini biasanya memerlukan migrasi namespace untuk memulai ketika tidak ada orang lain yang bekerja, katakanlah pada jam 10 malam pada Jumat malam. Tidak ada yang ingin memulai proyek yang membuat stres pada jam 10 malam pada Jumat malam. Belum lagi, kemampuan mental Anda mungkin tidak bekerja dengan baik di malam hari dan akhir pekan pada proyek yang tidak mengharuskan Anda untuk menjadi tajam!
• Saya telah menyebutkan bahwa Migrasi Namespace membutuhkan waktu dan tenaga. Berikut ini sedikit lebih banyak tentang itu:
  • Proses pemetaan konten harus dilakukan dengan presisi dan membutuhkan kolaborasi tim dan banyak jam kerja.
  • Beberapa proses kering diperlukan untuk memeriksa kesalahan atau masalah dengan migrasi. Migrasi tipikal tidak berjalan sempurna pada percobaan pertama. Anda juga memerlukan cadangan yang valid dari Toko Konten Anda yang dapat dipulihkan dalam kasus seperti itu. Kami telah melihat banyak organisasi yang tidak memiliki cadangan yang baik (atau memiliki cadangan yang tidak mereka sadari tidak lengkap).
  • Anda perlu mengidentifikasi semuanya di luar Toko Konten yang mungkin terkena dampak (model kerangka, model transformator, dll). Tugas ini mungkin melibatkan koordinasi di beberapa tim (terutama di lingkungan BI bersama yang besar).
  • Anda memerlukan rencana pengujian yang baik yang melibatkan orang-orang yang representatif dengan berbagai tingkat akses ke konten Cognos Anda. Kuncinya di sini adalah untuk memverifikasi segera setelah migrasi selesai bahwa semuanya sepenuhnya dimigrasikan dan berfungsi seperti yang Anda harapkan. Biasanya tidak praktis untuk memverifikasi semuanya, jadi Anda akhirnya memverifikasi apa yang Anda harapkan adalah sampel yang representatif.
• Anda harus memiliki broad pengetahuan tentang lingkungan Cognos dan hal-hal yang bergantung padanya. Misalnya, kubus historis dengan tampilan khusus HARUS dibangun kembali jika Anda menggunakan rute NSM.
• Bagaimana jika Anda atau perusahaan Anda telah mengalihdayakan migrasi namespace untuk melupakan sesuatu, seperti…aplikasi SDK? Setelah Anda membalik sakelar, hal-hal ini berhenti berfungsi jika tidak diperbarui dengan benar. Apakah Anda memiliki pemeriksaan yang tepat untuk segera menyadarinya, atau akankah beberapa minggu / bulan sebelum gejala mulai muncul?
• Jika Anda telah mengalami banyak peningkatan Cognos, Anda berpotensi memiliki objek di Toko Konten Anda yang berada dalam keadaan tidak konsisten. Jika Anda tidak bekerja dengan SDK, Anda tidak akan dapat melihat objek mana yang berada dalam status ini.

Mengapa Penggantian Namespace adalah Pilihan Terbaik

Faktor risiko utama dan langkah-langkah yang memakan waktu yang baru saja saya uraikan dihilangkan ketika metode Penggantian Ruang Nama Persona digunakan. Menggunakan pendekatan Penggantian Namespace, Anda memiliki waktu henti Cognos selama 5 menit, dan tidak ada konten Anda yang harus diubah. Metode "Bagus" tampaknya seperti "tanpa otak" yang dipotong dan kering bagi saya. Jumat malam adalah untuk bersantai, tidak stres karena Pengelola Konten Anda baru saja mogok di tengah-tengah Migrasi Namespace.