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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מבנה המודל לחיקוי הראשון המתואר בבירור הוצע על ידי המדענים האמריקאים דיוויד פראילו וריצ'רד קון מהמכון הלאומי האמריקאי לתקנים וטכנולוגיה ב-1992. ואז הופיע לראשונה המונח RBAC (בקרת גישה מבוססת תפקידים). מחקרים ותיאורים אלו של המרכיבים העיקריים, כמו גם הקשר ביניהם, היוו את הבסיס לתקן INCITS 359-2012, שעדיין בתוקף היום, שאושר על ידי הוועדה הבינלאומית לתקני טכנולוגיית מידע (INCITS).

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

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

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

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

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

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

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

שלב 1. צור מודל פונקציונלי

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

שלב 2. אנו מבקרים את מערכות ה-IT ומגבשים תכנית תעדוף

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

אז איך קובעים את הקריטיות של מערכת? ענה לעצמך על השאלות הבאות:

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

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

נ.ב. חברות גדולות בעלות תהליכי IT מפותחים בוודאי מכירים את נוהל ביקורת IT - IT General Controls (ITGC), המאפשר לזהות ליקויים בתהליכי IT ולבסס בקרה על מנת לשפר תהליכים בהתאם לשיטות העבודה הטובות ביותר (ITIL, COBIT, IT ממשל וכו') ביקורת כזו מאפשרת ל-IT ולעסק להבין טוב יותר זה את זה ולפתח אסטרטגיית פיתוח משותפת, לנתח סיכונים, לייעל עלויות ולפתח גישות יעילות יותר לעבודה.



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

שלב 3 צור מתודולוגיה

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

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

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

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

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

שלב 4. תקן את הפרמטרים של מודל בקרת הגישה הקיים

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

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

• אופן ניהול החשבונות (ישירות במסד הנתונים או באמצעות ממשקי תוכנה);
• כיצד משתמשים נכנסים למערכת (באמצעות חשבון נפרד או באמצעות חשבון AD, LDAP וכו');
• באילו רמות גישה למערכת נעשה שימוש (רמת אפליקציה, רמת מערכת, שימוש מערכת במשאבי קבצי רשת);
• תיאור ופרמטרים של השרתים עליהם פועלת המערכת;
• אילו פעולות ניהול חשבון נתמכות (חסימה, שינוי שם וכו');
• אילו אלגוריתמים או כללים משמשים ליצירת מזהה משתמש המערכת;
• באיזו תכונה ניתן להשתמש כדי ליצור קשר עם רישום של עובד במערכת כוח האדם (שם מלא, מספר כוח אדם וכו');
• כל תכונות החשבון והכללים האפשריים למילוים;
• אילו זכויות גישה קיימות במערכת (תפקידים, קבוצות, זכויות אטומיות וכו', האם קיימות זכויות מקוננות או היררכיות);
• מנגנונים לחלוקת זכויות גישה (לפי תפקיד, מחלקה, פונקציונליות וכו');
• האם יש למערכת כללים להפרדת זכויות (SOD – Segregation of Duties), וכיצד הם פועלים;
• כיצד מעובדים במערכת אירועי היעדרות, העברה, פיטורים, עדכון נתוני עובדים וכו'.

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

שלב 5. צור תיאור עסקי של הרשאות

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

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

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

שלב 6 אנו מורידים נתונים על משתמשים וזכויות מהמערכות ומשווים אותם למקור כוח האדם

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

אילו נתונים צריך להוריד:

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

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

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

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

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

מחבר: לודמילה סבסטיאנובה, מנהלת קידום מכירות Solar inRights

מקור: www.habr.com