יישום IdM. הכנה ליישום על ידי הלקוח

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

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

בהתחשב בכך שתהליך האוטומציה של גישה משפיע על שני היבטים עיקריים - נתוני כוח אדם ונתונים ממערכות מידע שאיתן יש לבצע אינטגרציה, נשקול את הצעדים הדרושים כדי להבטיח שהטמעת IdM תעבור בצורה חלקה ולא תגרום לדחייה:

1. ניתוח תהליכי כוח אדם ואופטימיזציה של תמיכת מסדי נתונים עובדים במערכות כוח אדם.
2. ניתוח נתוני משתמש וזכויות וכן עדכון שיטות בקרת גישה במערכות יעד המתוכננות להיות מחוברות ל-IDM.
3. פעילות ארגונית ומעורבות כוח אדם בתהליך ההיערכות ליישום IdM.

נתוני כוח אדם

יכול להיות שיש מקור אחד של נתוני כוח אדם בארגון, או שיכול להיות כמה. לדוגמה, לארגון עשויה להיות רשת סניפים רחבה למדי, וכל סניף עשוי להשתמש בבסיס כוח אדם משלו.

קודם כל, יש להבין אילו נתונים בסיסיים על עובדים מאוחסנים במערכת רישומי כוח אדם, אילו אירועים נרשמים ולהעריך את שלמותם ומבנהם.

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

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

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

• מנהל בכיר
• מנהל בכיר
• מנהל בכיר
• אומנות. מנהל…

לעתים קרובות אתה צריך להתמודד עם הבדלים באיות שמך:

• שמלבה נטליה גנאדייבנה,
• שמלבה נטליה גנאדייבנה...

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

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

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

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

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

מערכות יעד

בשלב הבא עלינו להבין כמה מערכות מידע נרצה לשלב במבנה ה-IDM, אילו נתונים על משתמשים וזכויותיהם מאוחסנים במערכות אלו וכיצד לנהל אותם.

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

מודל לחיקוי

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

לבקרת גישה מבוססת תפקידים יש מספר יתרונות שאין להכחישה:

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

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

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

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

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

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

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

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

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

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

אירועים ארגוניים

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

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

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

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

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

צ'ק ליסט

לסיכום, אנו מסכמים את הצעדים העיקריים שעל ארגון המתכנן ליישם IdM לנקוט:

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

תהליך ההכנה יכול להיות קשה, אז אם אפשר, שלב יועצים.

הטמעת פתרון IdM היא צעד קשה ואחראי, ולהטמעתו המוצלחת חשובים הן המאמצים של כל צד בנפרד – עובדי מחלקות עסקיות, שירותי IT ואבטחת מידע והאינטראקציה של הצוות כולו. אבל המאמצים שווים את זה: לאחר הטמעת IdM בחברה יורד מספר התקריות הקשורות לסמכויות מופרזות וזכויות בלתי מורשות במערכות מידע; נעלמת זמן השבתה של עובד עקב חוסר/המתנה ארוכה לזכויות הכרחיות; עקב אוטומציה, עלויות העבודה מופחתות ותפוקת העבודה של שירותי IT ואבטחת מידע גדלה.

מקור: www.habr.com