הסכנה הנסתרת של חשבונות צל באוטומציה של Microsoft 365

By Mirko Peters · 2026-08-26

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

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

ברוכים השבים לעוד העמקה באדריכלות, באבטחה ובמציאות הניהולית של מערכת Microsoft 365. אם אתם מנהלים תשתית ענן, בונים תהליכי עבודה או אחראים על ה-IT הארגוני, עלינו לדבר על פצצת זמן מתקתקת שמסתתרת לעין כולם. בפרק האחרון שלנו, Service Principal Security: Stop Using Personal Accounts, חשפנו פרקטיקה כל כך נפוצה שכמעט כל ארגון נופל בה: קישור אוטומציה ארגונית קריטית ישירות לחשבונות משתמשים אנושיים. זה מתחיל כקיצור דרך תמים. מהנדס צריך להקים זרימת Power Automate, לחבר Logic App, לסנכרן נתונים דרך API או להגדיר רענון נתונים ב-Power BI. כדי לחסוך זמן, הוא מאמת את החיבור בעזרת פרטי ההרשאה האישיים שלו. זה עובד מיד, הפרויקט עולה לאוויר בלי תקלות, וכולם ממשיכים הלאה. אבל מה קורה כשאותו מהנדס מחליף צוותים, מאפס את הסיסמה שלו, מפעיל מדיניות גישה מותנית חדשה או עוזב את החברה לחלוטין? האוטומציה נשברת, הייצור נדום, והארגון מגלה שהוא הריץ לוגיקה עסקית מרכזית על זהות שאולה. פוסט זה מרחיב את הרעיונות האלה, ומפרט מדוע חשבונות צל הורסים את עמידות התשתית שלכם וכיצד תוכלו לעדכן את הגישה לפני ששינויי הפלטפורמה ייכפו עליכם את ההחלטה.

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

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

מלכודת חשבון הצל באוטומציה של Microsoft 365

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

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

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

ריקבון זהות והעלות הנסתרת של תלויות אנושיות

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

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

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

למה מיקרוסופט דוחפת למעבר מתהליכי עבודה מבוססי משתמש

אם הסיכונים התפעוליים של חשבונות צל לא הספיקו כדי לשכנע ארגונים לשנות את דרכם, מפת הדרכים של הפלטפורמה בוודאי תעשה זאת. מיקרוסופט סוגרת בנחישות את הדלת בפני דפוסי אימות מדור קודם ואוטומציה מבוססת משתמש. בדרכנו אל מודל הזהויות של 2026, עידן האוטומציה ללא Service Principal מגיע לקיצו. תהליכי העבודה הישנים של SharePoint 2013 מוצאים משימוש, Azure AD Graph עובר הוצאה משימוש מלאה, והאימות המודרני לאפליקציות בלבד (app-only) הופך לדרישה מחייבת בכל המערכת האקולוגית.

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

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

התייחסות לזהות כתשתית באמצעות Service Principals

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

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

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

Managed Identities וכוחו של אימות ללא סודות

בעוד ש-Service Principals פותרים את בעיית התלות באדם, הם הציגו בעבר אתגר חדש: ניהול סודות. אחסון של client secrets, אישורים או סיסמאות בתוך קובצי תצורה, משתני סביבה או Key Vaults עדיין חשף ארגונים לתופעת פיזור הסודות ולדליפת אישורי גישה. למרבה המזל, ארכיטקטורת הענן התפתחה מעבר לאישורים סטטיים, בזכות הכניסה של Managed Identities.

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

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

ביטול סודות סטטיים באמצעות Federated Credentials

בעוד ש-Managed Identities אידיאליות לעומסי עבודה הפועלים באופן מקורי ב-Azure, צינורות אוטומציה ארגוניים רבים מסתמכים על מערכות CI/CD חיצוניות, סביבות מרובות ענן או כלי פיתוח כמו GitHub Actions. בתרחישים כאלה, תהליכי עבודה מסורתיים נוטים לייצר client secrets בעלי תוקף ארוך ולאחסן אותם במאגרים חיצוניים, פרקטיקה שיוצרת פגיעויות אבטחה עצומות.

כאן נכנסים לתמונה Federated Credentials ו-OpenID Connect (OIDC). זהות מאוחדת מאפשרת לעומסי עבודה חיצוניים ליצור קשר אמון זמני עם Microsoft Entra ID, ללא צורך באישורים מאוחסנים. במקום להשתמש בסיסמה קבועה, צינור העבודה החיצוני מבקש אסימון ישירות מהספק המקורי שלו, מציג לפני Entra ID את האסימון החתום קריפטוגרפית, ומקבל בתמורה אסימון גישה קצר מועד.

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

התמודדות עם משבר Permission Creep בארכיטקטורת הענן המודרנית

ככל שארגונים עוברים בהצלחה ל-Service Principals, ל-Managed Identities ול-Federated Credentials, מתעורר סיכון ארכיטקטוני חדש: Permission Creep. זהות עמידה ומתפקדת היטב, שמצוידת בהרשאות מוגזמות, הופכת לנשק מסוכן אם היא נפרצת. לעיתים קרובות מדי מהנדסים מקצים היקפי Graph API רחבים מדי, כגון `Application.ReadWrite.All` או `Directory.ReadWrite.All`, רק כדי להימנע מחיכוך בפריסה ולחסוך פתרון של שגיאות הרשאה במהלך ההגדרה הראשונית.

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

הפתרון למשבר הזה דורש יישום קפדני של עיקרון ההרשאה המינימלית (Principle of Least Privilege). יש להעניק ל-Service Principals רק את הרשאות היישום הספציפיות והמפורטות הנדרשות לביצוע המשימות שהוקצו להם. יש לבקר אותם באופן קבוע, לנטר התנהגות חריגה, ולהתייחס אליהם באותה זהירות בדיוק שמעניקים לגישת root בתשתית ייצור פיזית. בשילוב של ארכיטקטורת זהות נכונה לעומסי עבודה עם משילות הרשאות דיסציפלינרית, ניתן לבנות אוטומציה שהיא גם עמידה במיוחד וגם מאובטחת במיוחד.

סיכום

עידן בניית אוטומציה ארגונית על בסיס חשבונות משתמש אישיים מסתיים רשמית. כפי שבחנו לאורך המאמר, קישור תהליכים קריטיים ב-Microsoft 365 לאישורי גישה אנושיים יוצר תשתית שברירית, פערי אבטחה חמורים, ובעיית זהויות מתפוררת שבלתי נמנע להתמודד איתה. בין ההחלטה האגרסיבית של Microsoft להוציא משימוש מודלי אימות ישנים, לבין האיום המתמיד של השבתות תפעוליות שנגרמות מעובדים שעזבו את הארגון, המשך המצב הקיים כבר אינו אפשרות. באמצעות שימוש ב-Service Principals, הסתמכות על Managed Identities לאימות ללא סודות, שימוש בפרטי הזדהות פדרטיביים וניהול הרשאות מחמיר, ארגונים יכולים להפוך את צינורות האוטומציה שלהם לנכסים מאובטחים, עמידים וברמה ארגונית.

אם תרצו להעמיק בנושאים אלה ולשמוע אסטרטגיות מהעולם האמיתי לאבטחת סביבות האוטומציה שלכם, הקשיבו בבקשה לפרק הייעודי שלנו בנושא Service Principal Security: Stop Using Personal Accounts. הפרק מלא בתובנות מעשיות שיעזרו לכם לבצע ביקורת על הארכיטקטורה הנוכחית, לחסל חשבונות צל ולהכין את הדייר שלכם ב-Microsoft 365 למשבר הזהויות שמתקרב.