מעבר למקור אבטחה אחר של קוגנוס

כאשר עליך להגדיר מחדש את סביבת הקוגנוס הקיימת לשימוש במקור אבטחה חיצוני אחר (למשל Active Directory, LDAP וכו '), ישנן מספר גישות שאתה יכול לנקוט. אני אוהב לקרוא להם "הטוב, הרע והמכוער". לפני שנחקור את הגישות הטובות, הרעות והמכוערות האלה, בואו נסתכל על כמה תרחישים נפוצים שנוטים להניע שינויים במרחב שמות האימות בסביבת קוגנוס.

נהגים עסקיים נפוצים:

עדכון חומרה או מערכת הפעלה - מודרניזציה של חומרה/תשתית BI יכולה להיות נהג תדיר. בעוד ששאר הקוגנוס עשויים לרוץ כמו אלוף על החומרה החדשה והמהודרת שלך ומערכת ההפעלה המודרנית של 64 סיביות, בהצלחה בהעברת גרסת ה- Access Manager שלך בסביבות 2005 לפלטפורמה החדשה הזו. Access Manager (שוחרר לראשונה עם סדרה 7) הוא שימור מכובד מימים עברו עבור לקוחות רבים של קוגנוס. זו הסיבה היחידה שלקוחות רבים שומרים על הגרסה הישנה והגרועה הזו של Windows Server 2003. הכתיבה מונחת על הקיר עבור Access Manager די הרבה זמן. זו תוכנה מדור קודם. ככל שתוכל להתרחק ממנו מוקדם יותר, כך ייטב.

סטנדרטיזציה של יישומים- ארגונים שרוצים לאחד את האימות של כל היישומים שלהם מול שרת מדריכים ארגוני אחד המנוהל באופן מרכזי (למשל LDAP, AD).

מיזוגים ורכישות- חברה א 'רוכשת את חברה ב' וצריכה את סביבת הקוגנוס של חברה ב 'כדי להצביע על שרת הספרייה של חברה א', מבלי לגרום לבעיות בתוכן BI או בתצורה הקיימת שלהן.

פירוק חברות- זה ההפך מתרחיש המיזוג, חלק מחברה מתפזר לישות משלה וכעת צריך להפנות את סביבת ה- BI הקיימת שלה למקור האבטחה החדש.

מדוע העברות מרחב שמות יכולות להיות מבולגנות

הצבעה של סביבת קוגנוס למקור אבטחה חדש אינה פשוטה כמו הוספת מפת השמות החדשה עם אותם משתמשים, קבוצות ותפקידים, ניתוק מרחב השמות הישן ו- VOILA!- כל משתמשי Cognos שלך במרחב השמות החדש תואמים התוכן שלהם. למעשה, לעתים קרובות אתה יכול להסתיים בבלגן מדמם על הידיים, והנה הסיבה ...

כל מנהלי האבטחה של קוגנוס (משתמשים, קבוצות, תפקידים) מופנים על ידי מזהה ייחודי הנקרא CAMID. גם אם כל התכונות האחרות שוות, ה- CAMID של משתמש ב- קיימים מרחב שמות האימות לא יהיה זהה ל- CAMID עבור אותו משתמש ב- חדש מרחב שמות. זה יכול להרוס הרס בסביבת הקוגנוס הקיימת. גם אם יש לך רק כמה משתמשי Cognos, עליך להבין כי הפניות ל- CAMID קיימות בהרבה מקומות שונים בחנות התוכן שלך (ואף יכולות להתקיים מחוץ לחנות התוכן שלך בדגמי Framework, דגמי שנאי, יישומי TM1, קוביות, יישומי תכנון וכו '. ).

לקוחות רבים של קוגנוס מאמינים בטעות ש- CAMID באמת חשוב רק לתוכן התיקיה שלי, העדפות משתמש וכו '. זה לא יכול להיות רחוק יותר מהאמת. זה לא רק עניין של מספר המשתמשים שיש לך, זה כמות האובייקטים של קוגנוס שאתה צריך לדאוג להם. ישנם יותר מ -140 סוגים שונים של אובייקטים של קוגנוס רק בחנות התוכן, שרבים מהם עשויים להכיל מספר הפניות ל- CAMID.

לדוגמה:

1. אין זה נדיר של לוח זמנים אחד בחנות התוכן שלך מכיל מספר הפניות ל- CAMID (ה- CAMID של בעל לוח הזמנים, CAMID של המשתמש שעל לוח הזמנים לפעול כמו, ה- CAMID של כל משתמש או רשימת תפוצה עליו לשלוח פלט דוח שנוצר בדוא"ל אל , וכו.).
2. לכל אובייקט בקוגנוס יש מדיניות אבטחה הקובעת אילו משתמשים יכולים לגשת לאובייקט (חשוב "כרטיסיית הרשאות"). למדיניות אבטחה אחת התלויה בתיקיה זו בחיבור Cognos יש הפניה ל- CAMID לכל משתמש, קבוצה ותפקיד המצוינים באותה מדיניות.
3. אני מקווה שאתה מבין את הנקודה - הרשימה הזו נמשכת ונמשכת!

אין זה נדיר שחנות תוכן גדולה מכילה עשרות אלפי הפניות של CAMID (וראינו כמה גדולות עם מאות אלפים).

עכשיו, עשה את החישוב על מה שיש שֶׁלְךָ סביבת קוגנוס ואתה יכול לראות שאתה עלול להתמודד עם המוני הפניות של CAMID. זה יכול להיות סיוט! החלפה (או הגדרה מחדש) של מרחב שמות האימות שלך יכולה להשאיר את כל הפניות אלה של CAMID במצב בלתי פתיר. זה מוביל בהכרח לבעיות תוכן ותצורה של קוגנוס (למשל לוחות זמנים שכבר אינם פועלים, תוכן שכבר אינו מאובטח כפי שאתה חושב, חבילות או קוביות שכבר אינן מיישמות נכון את אבטחת רמת הנתונים, אובדן תוכן התיקיה שלי והמשתמש העדפות וכו ').

שיטות מעבר של מרחב שמות של קוגנוס

כעת, בידיעה כי סביבת Cognos יכולה להכיל עשרות אלפי הפניות ל- CAMID שידרשו למצוא, למפות ולעדכן את הערך החדש המתאים שלה ב- CAMID במרחב השמות החדש של האימות, בואו נדון בגישות הטובות, הרעות והמכוערות לפתרון בעיה זו.

הטוב: החלפת מרחב שמות באדם

השיטה הראשונה (החלפת מרחב שמות) משתמשת Motio, מנת המשכל של פרסונה מוצר. בגישה זו, מרחב השמות הקיים שלך "מוחלף" במרחב שמות מיוחד של Persona המאפשר לך וירטואליזציה של כל מנהלי האבטחה שנחשפים לקוגנוס. מנהלי אבטחה קיימים ייחשפו לקוגנו עם אותו CAMID בדיוק כמו קודם, למרות שהם עשויים להיות מגובים בכל מספר מקורות אבטחה חיצוניים (למשל Active Directory, LDAP או אפילו מסד הנתונים של Persona).

החלק היפה בגישה זו הוא שהיא דורשת אפס שינויים בתוכן הקוגנוס שלך. הסיבה לכך היא ש- Persona יכולה לשמור על CAMID של מנהלים קיימים, גם כאשר הם מגובים על ידי מקור חדש. אז ... כל אותם עשרות אלפי הפניות של CAMID בחנות התוכן שלך, מודלים חיצוניים וקוביות היסטוריות? הם יכולים להישאר בדיוק כפי שהם. אין צורך בעבודה.

זוהי גישת ההשפעה הפחות מסוכנת והנמוכה ביותר בה תוכלו להשתמש כדי להעביר את סביבת הקוגנוס הקיימת ממקור אבטחה חיצוני אחד למשנהו. ניתן לעשות זאת תוך פחות משעה עם כ -5 דקות של השבתה של קוגנוס (השבתה היחידה של קוגנוס היא הפעלה מחדש של קוגנוס לאחר שתגדיר את מרחב השמות של פרסונה).

הרע: העברת מרחב שמות באמצעות פרסונה

אם הגישה הקלה, בסיכון נמוך, היא פשוט לא כוס התה שלך, אז הנה is אפשרות נוספת.

ניתן להשתמש בפרסונה גם לביצוע העברת מרחב שמות.

זה כולל התקנת מרחב שמות אימות שני בסביבת Cognos שלך, מיפוי (בתקווה) של כל מנהלי האבטחה הקיימים שלך (ממרחב השמות הישן) למנהלים המתאימים במרחב השמות החדש, ואז (הנה החלק המהנה), מציאת, מיפוי ועדכון כל הפניה אחת ל- CAMID הקיימת בסביבת הקוגנוס שלך: חנות התוכן שלך, דגמי מסגרת, דגמי שנאי, קוביות היסטוריות, יישומי TM1, יישומי תכנון וכו '.

גישה זו נוטה להיות מלחיצה ועתירת תהליכים, אך אם אתה סוג של מנהל קוגנוס הזקוק לעומס אדרנלין כדי להרגיש חי (ולא אכפת לו משיחות טלפון מאוחרות / בוקר מוקדמות), אז אולי ... זֶה האם האפשרות שאתה מחפש?

ניתן להשתמש בפרסונה בכדי לסייע לאוטומציה של חלקים מתהליך זה. זה יעזור לך ליצור מיפוי בין מנהלי האבטחה הישנים למנהלי האבטחה החדשים, להפוך את ההיגיון "למצוא, לנתח, לעדכן" של התוכן בחנות התוכן שלך וכו '. העבודה בגישה זו כוללת "אנשים ותהליכים" ולא טכנולוגיה בפועל.

לדוגמה - איסוף מידע על כל דגם Framework Manager, כל דגם Transformer, כל יישום תכנון / TM1, כל יישום SDK, מי הבעלים שלהם ותכנון איך הם יעודכנו ויפוצלו מחדש יכולים להיות הרבה עבודה. תיאום הפסקות כל אחת מסביבות הקוגנוס שבהן ברצונך לנסות זאת וחלונות תחזוקה שבמהלכן תוכל לנסות את ההעברה יכול לכלול תכנון ו"זמן השבתה "של קוגנוס. להמציא (ולבצע) תוכנית בדיקה אפקטיבית לאחרי ההגירה שלך יכולה להיות גם דוב.

זה גם די נורמלי שתרצה לבצע תהליך זה תחילה בסביבה שאינה מייצרת לפני מנסה את זה בייצור.

בעוד שהגירת שמות מרחב עם אנשים אכן עובדת (והרבה יותר טובה מהגישה "המכוערת" שלהלן), היא פולשנית יותר, מסוכנת יותר, כרוכה בהרבה יותר כוח אדם ולוקח הרבה יותר שעות עבודה מאשר החלפת חלל שמות. בדרך כלל ההגירות צריכות להתבצע במהלך "שעות הפגרה", בעוד סביבת קוגנוס עדיין מקוונת, אך השימוש בטופס מוגבל על ידי משתמשי הקצה.

המכוער: שירותי הגירה של מרחב שמות ידני

השיטה המכוערת כוללת את הגישה הבלתי מעוררת הקנאה של ניסיון באופן ידני לעבור ממרחב שמות אימות אחד למשנהו. הדבר כרוך בחיבור מרחב שמות אימות שני לסביבת 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:XNUMX ביום שישי בערב. שלא לדבר, היכולות המנטאליות שלכם כנראה לא נמצאות במיטב הלילות ובסופי השבוע על פרויקט זה עושה דורש ממך להיות חד!
• ציינתי הגירות במרחב שמות הן עתירות זמן ועבודה. הנה עוד קצת על זה:
  • תהליך מיפוי התוכן צריך להיעשות בדיוק וזה דורש שיתוף פעולה של צוות ושעות עבודה רבות.
  • נדרשות ריצות יבשות מרובות כדי לבדוק אם יש טעויות או בעיות בהעברה. הגירה אופיינית לא עובדת בצורה מושלמת בניסיון הראשון. תזדקק גם לגיבוי תקף של חנות התוכן שלך שניתן לשחזר במקרים כאלה. ראינו ארגונים רבים שאין להם גיבוי טוב זמין (או שיש להם גיבוי שהם לא מבינים שהוא לא שלם).
  • אתה צריך לזהות הכל בחוץ חנות התוכן שעלולה להיות מושפעת (דגמי מסגרת, דגמי שנאי וכו '). משימה זו עשויה לכלול תיאום בין מספר צוותים (במיוחד בסביבות BI משותפות גדולות).
  • אתה צריך תוכנית בדיקה טובה הכוללת אנשים מייצגים עם דרגות שונות של גישה לתוכן הקוגנוס שלך. המפתח כאן הוא לוודא זמן קצר לאחר השלמת ההעברה שהכל נודד במלואו ומתפקד כפי שאתה מצפה. בדרך כלל זה לא מעשי לאמת הכל, כך שבסופו של דבר תאמת מה שאתה מקווה שהם דוגמאות מייצגות.
• בטח יש לך בroad הכרת סביבת קוגנוס ודברים התלויים בה. לדוגמה, קוביות היסטוריות עם תצוגות מותאמות אישית צריכות להיבנות מחדש אם תלך בדרך NSM.
• מה אם אתה או החברה שהוצאת את ההעברה של מרחב השמות למיקור חוץ כדי לשכוח משהו כמו ... יישומי SDK? לאחר שהפעלת את המתג, הדברים האלה מפסיקים לפעול אם הם לא מעודכנים כראוי. האם יש לך את הבדיקות המתאימות כדי להבחין בכך באופן מיידי, או שיעברו מספר שבועות / חודשים עד שהסימפטומים יתחילו לצוץ?
• אם עברת שדרוגים רבים של Cognos, ייתכן שיהיו לך בחנות התוכן אובייקטים שנמצאים במצב לא עקבי. אם אינך עובד עם ה- SDK, לא תוכל לראות אילו אובייקטים נמצאים במצב זה.

מדוע החלפת מרחב שמות היא האפשרות הטובה ביותר

גורמי הסיכון העיקריים והצעדים הגוזלים זמן שציירתי זה עתה מבוטלים בעת שימוש בשיטת החלפת מרחב שמות של Persona. באמצעות גישת החלפת מרחב השמות, יש לך 5 דקות זמן השבתה של קוגנוס, ואף אחד מהתכנים שלך לא צריך להשתנות. שיטת ה"טוב "נראית לי כ"אין מושג" חתוך ויבש. ערבי שישי מיועדים למנוחה, לא להילחץ מהעובדה שמנהל התוכן שלך התרסק באמצע העברת מרחב שמות.