למה חשבונות ה-'svc-' שלכם הם פצצת זמן מתקתקת

By Mirko Peters · 2026-08-11

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

Titelbild: Why Your 'svc-' Accounts Are a Ticking Time Bomb

ברוכים השבים לפודקאסט ולהעמקה המתמשכת שלנו בארכיטקטורת האבטחה הארגונית. אם הארגון שלכם דומה לרוב הארגונים, מבט מהיר ב-Active Directory או ב-Microsoft Entra ID שלכם יחשוף בית קברות גדול של חשבונות שמתחילים ב-"svc-", ‏"app-" או ‏"admin-bot". החשבונות האלה מחזיקים את המערכות פועלות, את הנתונים זורמים ואת האוטומציות רצות. אבל הם גם נקודת העיוורון הגדולה ביותר במצב האבטחה המודרני שלכם. בפוסט הזה אנחנו ממשיכים את השיחה האחרונה שלנו ומפרקים מדוע חשבונות שירות מסורתיים מערערים לחלוטין את ארכיטקטורת Zero Trust שלכם, ומדוע המעבר ל-Microsoft Entra Workload Identities הוא הדרך היחידה קדימה.

לסקירה קולית מלאה של הנושא, כדאי להאזין לפרק הפודקאסט המשלים שלנו, Replace Service Accounts with Entra Workload Identities. עכשיו בואו נצלול אל מנגנוני הסיכון של ישויות שאינן אנושיות, ואיך אפשר לחסל אותו לחלוטין.

TL;DR

לחשבונות שירות עם סודות סטטיים והרשאות רחבות יש את פער הזהויות הגדול ביותר שלכם. Workload Identities (ב-Microsoft Entra ID) מעניקים לכל ישות לא-אנושית זהות מנוהלת עם הרשאות מינימליות, מחזור חיים, מדיניות CA, רוטציה ונתיבי ביקורת מלאים – בלי לשבור את האוטומציות שלכם.

מדוע חשבונות שירות נכשלים (ומערערים את Zero Trust)

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

סודות סטטיים ואין MFA -> קלים לגניבה, וקשים לרוטציה בבטחה
הרשאות מוגזמות כברירת מחדל -> הרשאות "רק שזה יעבוד" הופכות לקבועות
אין מחזור חיים -> חשבונות יתומים או נשכחים שורדים מיגרציות ושינויים ארגוניים
ביקורתיות דלה -> "מי השתמש בזה ולמה?" = ניחושים וצילומי מסך
תרבות של חריגים -> החרגות מ-CA/MFA עבור בוטים מרחיבות בשקט את משטח התקיפה שלכם

Managed Identities: צעד טוב – אבל קשור ל-Azure

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

✅ גישה ללא סודות למשאבים מקוריים ל-Azure (Functions, VMs, Logic Apps)
❌ פערים ביעדים היברידיים/של צד שלישי, מיפוי בעלות חלש, ותצוגות ממשל מוגבלות
❌ הכיסוי של CA/הרשאות אינו אחיד על פני משטחים שאינם ב-Azure

Workload Identities: מה באמת מקבלים

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

זהויות לא-אנושיות מדרגה ראשונה (אפליקציות, סקריפטים, מחברים, RPA, אינטגרציות)
הרשאות ממוקדות (תפקידי Graph/משאבים, אימות app-only) עם הרשאות מינימליות
מחזור חיים (בעלים, תדירות סקירה, תהליך פירוק) המקושר לתהליך העסקי
Conditional Access לעומסי עבודה (שערים מודעי סיכון והקשר, בקרות סשן היכן שנתמך)
היגיינת אישורים (סודות קצרי-מועד, תעודות, מדיניות רוטציה של מפתחות)
נראות מאוחדת (כניסות, טוקנים, גישה למשאבים, היסטוריית שינויים) -> מוכנות לביקורת

מטריצת השוואה (במבט מהיר)

יכולת	חשבון שירות	Managed Identity	Workload Identity
סודות	סיסמאות סטטיות	ללא סודות (Azure)	ללא סודות/קצרי-מועד + רוטציה
היקף	רחב / דמוי משתמש	ממוקד Azure	כל עומס עבודה (אפליקציות/סקריפטים/מחברים)
CA / סיכון	כמעט לא מיושם	מוגבל	מונחה מדיניות היכן שנתמך
מחזור חיים	אד-הוק	בסיסי	בעלים + סקירות + פירוק
ביקורת	דלילה	יומני Azure	יומן כניסות והרשאות מרכזי

דפוסי ארכיטקטורה (מקרי שימוש נפוצים)

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

מחברים של Power Platform / Cloud Flows -> הקצו workload identity לכל אינטגרציה; העניקו רק את ההיקפים הנדרשים של Graph/Dataverse.
אפליקציות ליבה עסקית (Web APIs, daemons) -> רישום אפליקציה + אישור; השתמשו ב-app roles ובגישת Graph מבוססת app-only; אכפו CA היכן שרלוונטי.
סקריפטים אוטומטיים (Azure Automation, GitHub Actions, DevOps) -> השתמשו בfederated credentials (OIDC), ללא סודות שמורים.
משימות Cross-tenant / B2B -> workload identity ייעודי לכל גבול דייר; בודדו את ההרשאות והרישום.

ספר מהלכים להגירה (90 יום, ללא הפתעות)

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

שלב 1 — גילוי ומיון (שבועות 0–3)

בצעו מלאי של כניסות וישויות שאינן אנושיות: svc-*, app-*, תיבות דואר משותפות, רישומי אפליקציות, סודות שפגים בתוך פחות מ-90 יום.
מפו כל אחד לבעלים, מטרה עסקית, יעדים, הרשאות, תלות בחשבון break glass.
דרגו סיכון: סיסמאות סטטיות, תפקידים גלובליים, היעדר בעלים, היעדר החלפה לאחרונה.

שלב 2 — המרת הסיכונים הגבוהים תחילה (שבועות 4–8)

הקימו workload identity לכל אינטגרציה (אין לעשות שימוש חוזר).
החליפו אימות בסיסמה ב-אישורים או ב-federated credentials; הגדירו מדיניות החלפה.
עברו להרשאות app-only; הסירו הרשאות מואצלות למשתמש במקום שאינן נדרשות.
החילו מדיניות Conditional Access על כניסות של workloads (במקום שנתמך).
הטמיעו סקירות גישה (אחת לרבעון) וכן בעלות ב-CMDB/ITSM.

שלב 3 — ביטול שירות וממשל (שבועות 9–12)

השביתו חשבונות שירות ישנים; עקבו אחריהם למשך 14 יום; ולאחר מכן מחקו.
אכפו תקני יצירה: שמות, בעלים, סיווג נתונים, מחזור סקירה.
הוסיפו התראות: כניסות חריגות, זהויות לא פעילות מעל 30/60/90 יום, וסודות שפגים.
הטמיעו בדיקות זהות ב-CI/CD (policy-as-code).

Conditional Access והרשאות (מעקות בטיחות מעשיים)

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

מדיניות נפרדת למשתמשים אנושיים מול workload identities; חסמו כניסה אינטראקטיבית ל-workloads.
מיקומים בשם / הגבלות רשת לגישת app-only, במקום שניתן.
הרשאות מוגבלות בזמן (PIM עבור app roles במקום שזמין; סקירות גישה מתוזמנות).
היקפים: עדיפות ל-app roles או לתפקידים ספציפיים למשאב, על פני הרשאות רחבות ברמת הדיירקטוריון.

רישום וביקורת (מה להציג למבקר)

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

בעלים של האפליקציה/ה-workload, המטרה ורגישות הנתונים
יומני כניסה (כניסות service principal), קהל היעד של הטוקן, כתובת IP, אפליקציית הלקוח
הקצאות תפקידים (מי אישר, מתי אושר באישור)
היסטוריית אישורים (סוג, החלפה אחרונה, תפוגה)
מחזור חיים: נוצר/שונה/הושבת/נמחק עם שם המבצע

לוח מחוונים של KPI (להוכחת השיפור)

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

% ישויות שאינן אנושיות עם בעלים ומחזור סקירה (יעד ≥ 95%)
חשבונות שירות יתומים (יעד -> 0)
סודות בני יותר מ-90 יום (יעד -> 0; עדיפות לאישור/federated)
רוחב הרשאות app-only (ספירת “Directory.ReadWrite.All” -> מגמת ירידה)
ממצאי ביקורת לגישה שאינה אנושית (ירידה רבעון מול רבעון)

דפוסים אנטי-מומלצים שיש לחסל

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

שימוש חוזר בחשבון שירות גנרי יחיד על פני מערכות רבות
שמירת סיסמאות בסקריפטים, ב-web.config או ב-Key Vault ללא מדיניות רוטציה
הענקת Global Admin / Owner “ליתר ביטחון” כדי שהעבודות ימשיכו לרוץ
חריגות “זמניות” ל-CA שאף פעם לא פגות תוקף

צעדים מהירים (השבוע)

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

סמנו כל זהות שאינה אנושית עם Owner, System ו-Data Class.
עברו עבודה אחת בסיכון גבוה ל-federated credentials (GitHub OIDC -> Entra).
החליפו חשבון שירות משותף ב-Power Automate ב-workload identity.
צרו דוח של service principals עם סודות שפגים או שפגו תוקף, והגדירו התראות מתוזמנות.

שאלות נפוצות (תשובות מהירות)

האם workload identities שוברים עבודות מקומיות (on-prem) ישנות?
לא. אפשר לגשר באמצעות אימות app-only, אישורים או שירותי מתווך; פשוט הסירו סיסמאות בהדרגה.

האם אפשר לאכוף Conditional Access על כניסות שאינן אנושיות?
כן, עבור תהליכים הנתמכים (כניסות של service principal). השתמשו באותות רשת, מיקום ומכשיר במידת הצורך, וחסמו כניסות אינטראקטיביות.

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

מה לגבי Power Platform?
השתמשו ב-Service Principals / Workload Identities עבור קונקטורים ו-Dataverse; הפסיקו להשתמש בחשבונות משתמש משותפים.

סיכום

אי אפשר לפתור את סיכון חשבונות השירות רק ברוטציה של סיסמאות. Entra Workload Identities מכניסים גישה לא-אנושית לאותו מודל Zero Trust, מחזור חיים וביקורת שכבר דורשים מאנשים, ועושים זאת בלי השבתות ובלי גיבורות-על. התחילו מחשבונות ה-“svc-” המסוכנים ביותר, המירו אותם ל-workload identities מנוהלות, והחזירו את החריגות להיות החריגים.

אם נהניתם מהכתבה, כדאי מאוד לצפות בדיון המלא בפרק הפודקאסט שלנו, Replace Service Accounts with Entra Workload Identities. הירשמו לתוכנית למעמקים נוספים באסטרטגיות אבטחה של Microsoft 365 ו-Azure לארגונים.