אבטחה והרשאות ב-Azure Lighthouse: ניהול בטוח של גישה לענן במספר דיירים

By Mirko Peters · 2026-10-21

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

Automatically translated with AI from the original post. Read the English original

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

עיקרי הדברים

• ללקוחות נותרת סמכות מלאה על הדיירים שלהם ב-Azure, באמצעות הגדרת היקפים מדויקים ותפקידים מובנים.
• הגדרות רישום והקצאות רישום פועלות כ"לחיצת יד" מתמשכת, ש-Azure בודק בכל פעולה.
• תפקיד Owner מלא וגישה לשכבת הנתונים אינם נתמכים כלל בהאצלות של Azure Lighthouse.
• ספקים פועלים באמצעות הקרנות לוגיות בפורטל שלהם, ללא שיתוף סיסמאות או פרטי אימות של משתמשים.
• יומני פעילות מתעדים כל שינוי בדייר של הלקוח, ומספקים מסלול ביקורת שקוף.

ארכיטקטורת האבטחה של Azure Lighthouse

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

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

לחיצת היד בשני חלקים

האבטחה ב-Azure Lighthouse אינה מבוססת על אמון עיוור; היא מעוגנת בשני קובצי תצורה בלתי ניתנים לשינוי מבוססי JSON, שהמנהל הראשי של הלקוח פורס ישירות.

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

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

יישום הרשאות מינימליות בסביבות מרובות דיירים

עיקרון ההרשאות המינימליות (least privilege) הוא אבן יסוד באבטחת ענן מודרנית: מעניקים למשתמשים ולמערכות רק את מינימום ההרשאות הנדרש לביצוע המשימות שלהם. Azure Lighthouse מקל על אכיפת העיקרון הזה, באמצעות מיפוי ההרשאות לקבוצות אבטחה, לחסויות שירות (service principals) וחשבונות אוטומציה, במקום למשתמשים אנושיים בודדים.

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

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

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

מגבלות תפקידים מובנים כמנגנוני הגנה באבטחה

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

בנוסף, תפקידים שמעניקים גישה לשכבות הנתונים (data planes), כגון קריאת קבצים בתוך מאגרי Azure Blob Storage או צפייה ברשומות במסד נתונים, אינם ניתנים להאצלה דרך Lighthouse. Lighthouse מנהל את שכבות הבקרה (control planes) של התשתית, ובכך מבטיח שהפיקוח הניהולי לעולם לא יחצה את הגבול אל פגיעה בפרטיות המידע.

מסלולי ביקורת ומעקב תאימות

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

כל פעולה שמבצע משתמש של הספק, בין אם הפעלה מחדש של מכונה וירטואלית, שינוי כלל בחומת אש או עדכון הגדרות רשת, נרשמת ישירות ביומן הפעילות של Azure (Azure Activity Log) של הלקוח. מאחר שהיומנים נמצאים בדייר של הלקוח, הספק החיצוני אינו יכול לשנות או למחוק אותם. מנהלי IT יכולים להריץ ביקורות סדירות שיענו על שאלות אבטחה קריטיות: מי נגע במשאב הזה? מתי הוא שונה? איזו פקודה מדויקת הורצה?

יתר על כן, ארגונים יכולים לשלב את Azure Lighthouse עם Privileged Identity Management (PIM) כדי לדרוש הרשאות העלאה בזמן אמת (just-in-time). במקום להחזיק הרשאות תורם קבועות, מהנדסי הספק יכולים לבקש גישה רק כאשר מתרחש אירוע, כשהאישורים נרשמים וההגבלות בזמן נאכפות אוטומטית.

סיכום

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

שאלות נפוצות

האם ספק של Azure Lighthouse יכול לצפות בסיסמאות הארגון שלי?

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

מה קורה לגישה של Azure Lighthouse אם ספק נפרץ?

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

האם Azure Lighthouse תומך בתפקידי RBAC מותאמים אישית?

לא. Azure Lighthouse תומך רק בתפקידי Azure מובנים שמספקת Microsoft. תפקידים מותאמים אישית שנוצרו בדייר הספק או בדייר הלקוח אינם ניתנים לשימוש בהגדרות רישום.

מי מוסמך להגדיר את Azure Lighthouse בדייר של לקוח?

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