هنگامی که نیاز به پیکربندی مجدد محیط Cognos موجود برای استفاده از منبع امنیتی خارجی متفاوت (به عنوان مثال Active Directory ، LDAP ، و غیره) دارید ، تعداد انگشت شماری از روش ها وجود دارد. من دوست دارم آنها را "خوب ، بد و زشت" صدا کنم. قبل از بررسی این رویکردهای خوب ، بد و زشت ، بیایید نگاهی به برخی از سناریوهای رایج بیندازیم که باعث ایجاد تغییرات در فضای نام احراز هویت در محیط Cognos می شوند.
محرک های تجاری مشترک:
به روز رسانی سخت افزار یا سیستم عامل - مدرن سازی سخت افزار/زیرساخت BI می تواند یک محرک مکرر باشد. در حالی که بقیه Cognos ممکن است مانند سخت افزاری جدید و سیستم عامل 64 بیتی مدرن شما عمل کنند ، موفق باشید نسخه حدود 2005 مدیریت دسترسی خود را به آن پلتفرم جدید منتقل کنید. Access Manager (که برای اولین بار با سری 7 منتشر شد) برای بسیاری از مشتریان Cognos از گذشته گذشته محترم است. این تنها دلیلی است که بسیاری از مشتریان آن نسخه قدیمی ویندوز سرور 2003 را نگه می دارند. این نوشته مدتی است که برای Access Manager روی دیوار است. این نرم افزار قدیمی است. هرچه زودتر بتوانید از آن دور شوید ، بهتر است.
استانداردسازی برنامه- سازمان هایی که می خواهند احراز هویت همه برنامه های خود را در برابر یک سرور فهرست راهنمای شرکتها (به عنوان مثال LDAP ، AD) ادغام کنند.
ادغام و ادغام- شرکت A شرکت B را خریداری می کند و به محیط Cognos شرکت B نیاز دارد تا به سرور فهرست شرکت A اشاره کند ، بدون اینکه مشکلی در محتوای BI موجود یا پیکربندی آنها ایجاد شود.
Divestitures شرکت- این برعکس سناریوی ادغام است ، بخشی از یک شرکت به نهاد خود منتقل می شود و اکنون باید محیط BI موجود خود را به منبع امنیتی جدید نشان دهد.
چرا مهاجرت های Namespace می تواند نامرتب باشد
اشاره به محیط Cognos به منبع امنیتی جدید به سادگی افزودن نام جدید با همان کاربران ، گروه ها و نقش ها ، قطع فضای نام قدیمی و VOILA نیست- همه کاربران Cognos شما در فضای نام جدید با محتوای آنها در حقیقت ، شما اغلب می توانید با یک آشفته خونین بر روی دستان خود مواجه شوید ، و در اینجا دلیل آن…
همه اصول امنیتی Cognos (کاربران ، گروه ها ، نقش ها) توسط یک شناسه منحصر به فرد به نام CAMID ارجاع داده می شوند. حتی اگر همه ویژگی های دیگر برابر باشند ، CAMID برای یک کاربر در an موجود فضای نام احراز هویت مشابه CAMID برای آن کاربر در جدید فضای نام این می تواند محیط Cognos موجود را خراب کند. حتی اگر چند کاربر Cognos دارید ، باید بدانید که مراجع CAMID در بسیاری از نقاط مختلف فروشگاه محتوا (و حتی در خارج از فروشگاه محتوا در مدلهای چارچوب ، مدلهای ترانسفورماتور ، برنامه های TM1 ، مکعب ها ، برنامه های کاربردی و غیره) وجود دارد. )
بسیاری از مشتریان Cognos به اشتباه معتقدند که CAMID واقعاً فقط برای محتوای پوشه من ، ترجیحات کاربر و غیره اهمیت دارد. این نمی تواند از حقیقت دورتر باشد. این فقط به تعداد کاربران شما مربوط نمی شود ، بلکه به تعداد اشیاء Cognos مربوط می شود که باید به آنها توجه داشته باشید. بیش از 140 نوع مختلف شیء Cognos فقط در فروشگاه محتوا وجود دارد که بسیاری از آنها ممکن است دارای چندین منبع CAMID باشند.
مثلا:
- غیر معمول نیست که یک برنامه واحد در فروشگاه محتوای شما چندین مرجع CAMID داشته باشد (CAMID مالک برنامه ، CAMID کاربر برنامه زمانبندی شده به عنوان ، CAMID هر کاربر یا لیست توزیع باید خروجی گزارش تولید شده را به آن ایمیل کند ، و غیره.).
- هر شی در Cognos دارای یک خط مشی امنیتی است که بر اساس آن کاربران می توانند به این شی دسترسی داشته باشند (به "برگه مجوزها" فکر کنید). یک خط مشی امنیتی واحد در پوشه Cognos Connection دارای یک مرجع CAMID برای هر کاربر ، گروه و نقشی است که در آن خط مشی مشخص شده است.
- امیدوارم متوجه منظور شده باشید - این لیست همچنان ادامه دارد!
این غیر معمول نیست که یک فروشگاه محتوای بزرگ حاوی ده ها هزار مرجع CAMID باشد (و ما برخی از آنها را با صدها هزار مورد مشاهده کرده ایم).
حالا ، محاسبه کنید که چه چیزی در آن وجود دارد خود را محیط Cognos و می توانید ببینید که شما به طور بالقوه با انبوهی از منابع CAMID سر و کار دارید. می تواند یک کابوس باشد! تعویض (یا پیکربندی مجدد) فضای نام احراز هویت شما می تواند همه این منابع CAMID را در وضعیتی غیرقابل حل قرار دهد. این به ناچار منجر به مشکلات محتوا و پیکربندی Cognos می شود (به عنوان مثال برنامه هایی که دیگر اجرا نمی شوند ، محتوایی که دیگر آنطور که فکر می کنید ایمن نیست ، بسته ها یا مکعب هایی که دیگر امنیت سطح داده ها را به درستی اجرا نمی کنند ، از بین رفتن محتوای پوشه من و کاربر ترجیحات و غیره).
روش های انتقال Cognos Namespace
اکنون ، با دانستن اینکه یک محیط Cognos می تواند ده ها هزار مرجع CAMID داشته باشد که نیاز به یافتن ، نقشه برداری و به روز رسانی مقدار CAMID جدید مربوطه در فضای نام جدید احراز هویت دارد ، بیایید در مورد راه حل های خوب ، بد و زشت برای حل این مشکل بحث کنیم.
خوب: جایگزینی فضای نام با پرسونا
روش اول (جایگزینی فضای نام) استفاده می کند Motio'S، ضریب هوشی پرسونا تولید - محصول. با استفاده از این رویکرد ، فضای نام فعلی شما با یک فضای نام شخصی شخصی "جایگزین" می شود که به شما امکان می دهد تمام اصول امنیتی را که در معرض Cognos قرار دارند مجازی سازی کنید. اصول امنیتی موجود از قبل با CAMID کاملاً مشابه در معرض دید Cognos قرار می گیرند ، هر چند که ممکن است توسط تعدادی از منابع امنیتی خارجی (مانند Active Directory ، LDAP یا حتی پایگاه داده Persona) پشتیبانی شوند.
قسمت زیبای این رویکرد این است که نیاز به تغییرات صفر در محتوای Cognos شما دارد. این به این دلیل است که Persona می تواند CAMID مدیران قبلی را حفظ کند ، حتی اگر از منبع جدیدی پشتیبانی شوند. بنابراین ... همه آن ده ها هزار مرجع CAMID در فروشگاه محتوا ، مدلهای خارجی و مکعب های تاریخی شما؟ آنها می توانند دقیقاً همانطور که هستند بمانند. نیازی به کار نیست
این روش کم خطرترین و کمترین رویکرد تأثیر است که می توانید برای انتقال محیط کنونی Cognos از یک منبع امنیتی خارجی به منبع دیگر استفاده کنید. این کار را می توان در کمتر از یک ساعت با حدود 5 دقیقه خرابی Cognos انجام داد (تنها زمان خرابی Cognos راه اندازی مجدد Cognos پس از پیکربندی فضای نام Persona است).
بد: مهاجرت Namespace با استفاده از Persona
اگر روش آسان و کم خطر فقط فنجان چای شما نیست ، پس آنجاست is گزینه ای دیگر.
از Persona همچنین می توان برای انجام Namespace Migration استفاده کرد.
این شامل نصب یک فضای نام دوم احراز هویت در محیط Cognos شما ، نقشه برداری (امیدوارم) تمام اصول امنیتی موجود شما (از فضای نام قدیمی) به اصول مربوطه در فضای نام جدید ، سپس (در اینجا بخش سرگرم کننده است) ، پیدا کردن ، نقشه برداری و به روز رسانی هر مرجع واحد CAMID که در محیط Cognos شما وجود دارد: فروشگاه محتوا ، مدلهای چارچوب ، مدلهای ترانسفورماتور ، مکعب های تاریخی ، برنامه های TM1 ، برنامه های کاربردی و غیره.
این رویکرد استرس زا و فرایندی است ، اما اگر شما از آن دسته مدیران Cognos هستید که برای احساس زنده بودن به کمی هورمون آدرنالین احتیاج دارید (و برای تلفن های شبانه دیر وقت و صبح زود مشکلی ندارد) ، شاید… این گزینه ای است که شما به دنبال آن هستید؟
از Persona می توان برای کمک به خودکار بخشی از این فرایند استفاده کرد. این به شما کمک می کند تا نقشه ای بین اصول امنیتی قدیمی و مدیران جدید امنیتی ایجاد کنید ، منطق محتوا را در محتویات خود پیدا کنید ، تجزیه و تحلیل کنید ، و غیره را خودکار کنید. کارهایی که در این رویکرد انجام می شود به جای فناوری واقعی ، شامل "افراد و فرایند" است.
به عنوان مثال - جمع آوری اطلاعات در مورد هر مدل Framework Manager ، هر مدل Transformer ، هر برنامه Planning / TM1 ، هر برنامه SDK ، صاحب آنها و برنامه ریزی نحوه به روز رسانی و توزیع مجدد آنها می تواند کار زیادی باشد. هماهنگی خاموشی ها برای هر یک از محیط های Cognos که می خواهید این کار را انجام دهید و در پنجره های تعمیر و نگهداری که طی آن می توانید مهاجرت را انجام دهید ، می تواند شامل برنامه ریزی و Cognos "زمان پایین" باشد. ارائه (و اجرای) یک برنامه آزمایشی م forثر برای بعد از مهاجرت شما نیز می تواند یک خرس باشد.
همچنین کاملاً طبیعی است که بخواهید ابتدا این فرآیند را در محیطی غیر تولیدی انجام دهید قبل از آن را در تولید آزمایش می کند
در حالی که مهاجرت Namespace with Persona کار می کند (و به مراتب بهتر از رویکرد "زشت" زیر است) ، مهاجم تر ، پر مخاطره تر ، پرسنل بسیار بیشتری را شامل می شود ، و انجام ساعت های انسانی آن بسیار بیشتر از جایگزینی Namespace است. به طور معمول مهاجرت ها باید در "ساعات خاموش" انجام شوند ، در حالی که محیط Cognos هنوز آنلاین است ، اما استفاده کاربران نهایی از فرم محدود شده است.
زشت: خدمات مهاجرت به نام فضایی نام
روش زشت شامل رویکرد غیرقابل شگفتی برای تلاش است دستی انتقال از یک فضای نام احراز هویت به مکان دیگر. این شامل اتصال یک فضای نام دوم احراز هویت به محیط Cognos شما و سپس تلاش برای جابجایی یا بازسازی بیشتر محتوا و پیکربندی موجود Cognos است.
به عنوان مثال ، با استفاده از این رویکرد ، یک مدیر Cognos ممکن است تلاش کند:
- گروه ها و نقش ها را در فضای نام جدید بازسازی کنید
- عضویت آن گروه ها و نقش ها را در فضای نام جدید ایجاد کنید
- محتوای پوشه های من ، ترجیحات کاربر ، برگه های پورتال و غیره را به صورت دستی از هر حساب منبع در هر حساب مورد نظر کپی کنید
- هر مجموعه خط مشی را در فروشگاه محتوا بیابید و آن را به همان اصول مرجع در فضای نام جدید به همان روشی که در فضای نام قدیمی به مراجع اصلی ارجاع داده است ، به روز کنید.
- همه برنامه ها را بازسازی کنید و آنها را با اعتبار مربوطه ، گیرندگان و غیره پر کنید.
- همه ویژگیهای "مالک" و "تماس" همه اشیاء در فروشگاه محتوا را بازنشانی کنید
- [حدود 40 مورد دیگر در فروشگاه محتوا که فراموش خواهید کرد]
- همه مدل های FM را با امنیت سطح شی یا داده جمع آوری کنید:
- بر این اساس هر مدل را به روز کنید
- هر مدل را بازنشر دهید
- توزیع مجدد مدل اصلاح شده به نویسنده اصلی
- کارهای مشابه برای مدلهای ترانسفورماتور ، برنامه های TM1 و برنامه های کاربردی که در برابر فضای نام اصلی ایمن شده اند
- [و خیلی بیشتر]
در حالی که برخی از مازوخیست های Cognos ممکن است به طور مخفیانه از ایده 400,000 بار کلیک روی Cognos Connection از خوشحالی خنده کنند ، اما برای اکثر افراد منطقی ، این روش بسیار خسته کننده ، وقت گیر و مستعد خطا است. اما این بزرگترین مشکل این رویکرد نیست.
بزرگترین مشکل این روش تقریباً همین است همیشه منجر به مهاجرت ناقص می شود.
با استفاده از این رویکرد ، شما (به طرز دردناکی) آن منابع CAMID را که می شناسید ، پیدا کرده و سعی می کنید نقشه برداری کنید ... اما تمایل دارید همه آن مراجع CAMID را که ترک می کنید ترک کنید. نمی دانم در مورد.
هنگامی که شما در فکر می کنم شما با این روش کار خود را تمام کرده اید ، اغلب اینطور نیست واقعا انجام شده.
شما اشیایی را در فروشگاه محتوای خود دارید که دیگر آنطور که فکر می کنید ایمن نیستند ... شما برنامه هایی دارید که مانند گذشته اجرا نمی شوند ، شما داده هایی دارید که دیگر آنطور که شما فکر می کنید امن نیست. چنین است ، و حتی ممکن است برای عملیات خاصی خطاهای غیر قابل توضیح داشته باشید شما واقعاً نمی توانید انگشت خود را روی دست بگذارید.
دلایلی که رویکردهای بد و زشت می تواند وحشتناک باشد:
- مهاجرت های خودکار فضای نام بر مدیر محتوا فشار زیادی وارد می کند. بازرسی و به روز رسانی احتمالی تک تک اجزای موجود در فروشگاه محتوا ، اغلب می تواند منجر به ده ها هزار تماس SDK به Cognos شود (تقریباً همه آنها از طریق مدیر محتوا جریان می یابند). این پرس و جو غیرعادی معمولاً استفاده از حافظه / بار را افزایش می دهد و مدیر محتوا را در معرض خرابی در حین مهاجرت قرار می دهد. اگر قبلاً در محیط Cognos خود بی ثباتی دارید ، باید از این روش بسیار بترسید.
- مهاجرت به فضای نام نیاز به یک پنجره نگهداری قابل توجه دارد. Cognos باید بالا باشد ، اما شما نمی خواهید که افراد در طول روند مهاجرت تغییراتی ایجاد کنند. به طور معمول لازم است مهاجرت فضای نام زمانی شروع شود که هیچ کس دیگری کار نمی کند ، فرض کنید ساعت 10 شب جمعه شب. هیچ کس نمی خواهد یک پروژه استرس زا را ساعت 10 شب جمعه شب آغاز کند. ناگفته نماند ، قوای ذهنی شما احتمالاً در بهترین شبها و تعطیلات آخر هفته خود در پروژه ای نیستند میکند از شما می خواهد تیزبین باشید!
- من اشاره کردم مهاجرت های Namespace زمان و کار زیادی می طلبد. در اینجا کمی بیشتر در مورد آن آمده است:
- فرآیند نگاشت محتوا باید با دقت انجام شود و مستلزم همکاری تیمی و ساعات کار زیاد است.
- برای بررسی خطاها یا مشکلات مربوط به مهاجرت ، چندین اجرای خشک لازم است. مهاجرت معمولی در اولین تلاش کاملاً انجام نمی شود. همچنین به یک نسخه پشتیبان معتبر از فروشگاه محتوا نیاز دارید که در چنین مواردی قابل بازیابی است. ما بسیاری از سازمان ها را دیده ایم که پشتیبان خوبی در دسترس ندارند (یا پشتیبان دارند که نمی دانند ناقص است).
- شما باید همه چیز را شناسایی کنید خارج از فروشگاه محتوا که ممکن است به طور بالقوه تحت تأثیر قرار گیرد (مدلهای چارچوب ، مدلهای ترانسفورماتور و غیره). این کار ممکن است شامل هماهنگی بین چندین تیم (به ویژه در محیط های مشترک مشترک BI) باشد.
- شما به یک برنامه آزمایشی خوب نیاز دارید که شامل افراد نماینده با درجات مختلف دسترسی به محتوای Cognos شما باشد. نکته اصلی این است که مدت کوتاهی پس از اتمام مهاجرت تأیید کنید که همه چیز به طور کامل منتقل شده و همانطور که انتظار دارید کار می کند. معمولاً تأیید همه چیز غیر عملی است ، بنابراین در نهایت آنچه را که امیدوارید نمونه های نماینده باشند تأیید کنید.
- شما باید b داشته باشیدroad آگاهی از محیط Cognos و موارد وابسته به آن. به عنوان مثال ، اگر از مسیر NSM بروید ، مکعب های تاریخی با نمای سفارشی باید بازسازی شوند.
- اگر شما یا شرکتی که مهاجرت فضای نام تجاری را برون سپاری کرده اید ، چیزی را فراموش کنید ، مانند برنامه های SDK؟ هنگامی که سوئیچ را زیر و رو کردید ، اگر این موارد به درستی به روز نشوند ، کار نمی کنند. آیا بررسی های مناسبی را برای مشاهده فوراً انجام داده اید یا چند هفته / ماه طول می کشد تا علائم ظاهر شوند؟
- اگر چندین ارتقاء Cognos را پشت سر گذاشته اید ، به طور بالقوه می توانید اشیایی را در فروشگاه محتوای خود داشته باشید که در وضعیت ناسازگار قرار دارند. اگر با SDK کار نمی کنید ، نمی توانید ببینید کدام اجسام در این حالت هستند.
چرا جایگزینی فضای نامی بهترین گزینه است
وقتی از روش جایگزینی فضای نام شخصی استفاده می شود ، عوامل خطرساز اصلی و مراحل زمان بری که من به آنها اشاره کردم حذف می شوند. با استفاده از رویکرد Namespace Replacement ، 5 دقیقه زمان خرابی Cognos دارید و هیچ یک از محتوای شما نباید تغییر کند. روش "خوب" به نظر من "بیهوده" بریده و خشک است. شبهای جمعه برای استراحت است ، نه اینکه بر این واقعیت تأکید داشته باشید که مدیر محتوا شما در وسط مهاجرت Namespace خراب شده است.
