הגדרת Azure Active Directory לניהול גישה

הגדרת Azure Active Directory: היכן ניהול הגישה נשבר

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

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

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

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

מה נותן ניהול גישה מרוכז

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

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

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

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

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

השוואת גישות: ספריית ענן, היברידי ופדרציה

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

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

שלבי העבודה: מביקורת הספרייה ועד מסירת נהלים

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

1. ביקורת הגישות הנוכחיות: מייצאים משתמשים, קבוצות, יישומים וחשבונות שירות, משווים הרשאות בפועל לתפקידים, מסמנים כפילויות, חשבונות «יתומים» והרשאות שניתנו ישירות.
2. סכימת תפקידים וקבוצות: מתכננים מבנה לפי חטיבות ותפקידים, גישה ניתנת רק דרך קבוצות, תפקידים ניהוליים עוברים למצב העלאה לפי בקשה עם אישור.
3. קבוצת פיילוט של משתמשים: 10–15 עובדים ממחלקה אחת עוברים מחזור מלא — כניסה ראשונה, מעבר לחטיבה אחרת, חופשה, פיטורים. הפיילוט מראה היכן המודל נשבר בתרחישים חיים.
4. הפעלת מדיניות גישה: כניסה אחודה, אימות רב-גורמי חובה, הגבלות לפי מכשיר ומיקום, כללים נפרדים לסשנים ניהוליים.
5. בדיקה אחרי ההטמעה: מנתחים יומני כניסות ודוח תפקידים, מנסים להיכנס ממכשיר לא מהימן, מתעדים דחיות שווא ומתקנים כללים לפני מסירה לתמיכה.
6. מסירת נהלים: מטריצת «משרה → תפקיד», סדר הענקה ושלילה, הוראות לקו תמיכה ראשון ובדיקות תקופתיות בידי בעלי קבוצות.

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

חבילת מסירה: קונפיגורציות, סכימות ומדיניות גישה

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

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

את הערכה בודקים יחד עם מנהל המערכת שלך: עוברים שניים-שלושה תרחישים על ספרייה חיה — חיבור שירות ושלילה מלאה של הרשאות. תארו את המשימה — נחזור עם הערכה ותוכנית.

ניתוח הטמעה: הענקת גישות ושלילה בעת פיטורים

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

לעובד חדש זה לקח בין יומיים לחמישה ימים ו-6–9 פעולות ידניות, ופניות מסוג «הכניסה לא עובדת» תפסו עד שליש מעומס קו התמיכה הראשון.

עשינו נקודת הענקה אחודה לגישות על בסיס Azure Active Directory: ספריית חשבונות, קבוצות ותפקידים הפכה משותפת לכל השירותים. הרשאות כבר לא מוקצות לאנשים ישירות — עובד נכנס לקבוצה לפי משרה וחטיבה, והגישות יורשות ממנה.

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

מספרים לפני ואחרי. הענקת סט הגישות המלא לעובד חדש: היה 2–5 ימים ו-6–9 פעולות ידניות, הפך לכמה דקות ובקשה אחת. סגירת גישות של מפוטר: היה מכמה שעות עד שלושה ימים, הפך ללא יותר מ-10 דקות מרגע האירוע במערכת משאבי האנוש.

פניות לתמיכה בנושא גישות ירדו בכ-70% — תרחישים טיפוסיים נסגרים באוטומציה, ופעולות ידניות נשארו רק לחריגים נדירים.

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

מה לעשות אם העובדים כבר רשומים בספרייה אחרת

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

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

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

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

שאלות טכניות נפוצות על אינטגרציה של ספרייה

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

האם כל השירותים הפנימיים תואמים לספרייה?

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

איך בודקים מדיניות גישה לפני הפעלה?

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

אילו הרשאות נשארות למנהלי מערכת?

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

נדון בסכימת הגישה שלך ונחזור עם תוכנית עבודה

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

כדאי לשלוח:

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

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

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