מדריך

תחילת טרנספורמציית Zero Trust ממודל היקפי מסורתי.

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

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

מקור↗

תכנון הגנה מקיפה נגד שרשרת התקפת כופר המלאה.

→שלב תחנות עבודה עם גישה מיוחסת (PAWs) למניעת גניבת אישורים ותנועה רוחבית, עם ארכיטקטורת גיבוי בלתי ניתנת לשינוי (Azure Backup immutable vaults, MUA) לשחזור עמיד.

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

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

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

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

יישום Zero Trust בגישה מדורגת להשגת תוצאות מהירות.

→פעל לפי תעדוף תוכנית המודרניזציה המהירה של Zero Trust (RaMP): 1. ניהול זהויות וגישה, 2. נקודות קצה והתקנים, 3. יישומים, 4. רשת ותשתית.

למה: אבטחת זהות מספקת את ההפחתה המשמעותית ביותר של הסיכון המיידי ומהווה את מישור הבקרה עבור כל שאר עמודי התווך של Zero Trust.

תעדוף תיקון פגיעויות בהתבסס על השפעה עסקית, לא רק על ציוני CVSS.

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

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

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

→יישם יוזמות Azure Policy מיושרות עם MCSB בקבוצת ניהול השורש. השתמש ב-Microsoft Defender for Cloud לניטור תאימות רציף על פני כל המנויים היורשים.

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

תכנון מרכז פעולות אבטחה (SOC) עבור חברה גלובלית עם דרישות אחסון נתונים אזוריות.

→פרוס ארכיטקטורת Microsoft Sentinel מרובת סביבות עבודה. שמור נתונים בסביבות עבודה אזוריות של Log Analytics כדי לעמוד בדרישות האחסון. השתמש ב-Azure Lighthouse לניהול מרכזי ובשאילתות חוצות סביבות עבודה לציד איומים מאוחד.

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

מקור↗

אופטימיזציה של פעולות SOC באמצעות Microsoft Defender XDR ו-Microsoft Sentinel כאחד.

→אפשר את מחבר Microsoft Defender XDR ב-Sentinel לסנכרון אירועים דו-כיווני. השתמש ב-Defender XDR לחקירה עמוקה ואוטומטית של אירועי M365/נקודות קצה. השתמש ב-Sentinel לקורלציה חוצת-תחומים עם מקורות צד שלישי וציד מתקדם.

למה: גישת "טוב יותר יחד" זו ממנפת את החוזקות של שתי הפלטפורמות: XDR לתגובה משולבת ואוטומטית בתוך המערכת האקולוגית של Microsoft, ו-SIEM לנראות וקורלציה רחבה וחוצת-פלטפורמות.

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

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

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

הקמת מישור ניטור אבטחה מאוחד על פני סביבות מקומיות, Azure, AWS ו-GCP.

→השתמש ב-Microsoft Sentinel כ-SIEM המרכזי. צרף שרתים מקומיים/מרובי עננים באמצעות Azure Arc. השתמש במחברי נתונים מקוריים של Sentinel עבור שירותי AWS ו-GCP. אפשר את Microsoft Defender for Cloud בכל הסביבות.

למה: Azure Arc מרחיב את מישור הבקרה של Azure לכל תשתית, ומספק לוח מחוונים יחיד לניהול אבטחה (Defender for Cloud) ולניטור (Sentinel) על פני נכסים היברידיים ומרובי עננים.

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

→הגדר הגדרות אבחון לייצוא יומני פעילות של Azure לסביבת עבודה ייעודית של Log Analytics ולחשבון אחסון בלתי ניתן לשינוי של Azure. מקם משאבים אלה במנוי אבטחה/ניהול נפרד ונעול.

למה: אחסון בלתי ניתן לשינוי (WORM) מונע שינוי יומנים. מנוי ניהול נפרד מבודד יומנים ממנהלי עומסי עבודה, ומונע ממנהל מערכת שנפרץ לטשטש את עקבותיו.

תעדוף השקעות בקרות אבטחה בהתבסס על דפוסי התקפה סבירים.

→מפה בקרות אבטחה קיימות למסגרת MITRE ATT&CK. נתח מידע איומים רלוונטי לתעשייה כדי לזהות TTPs נפוצים המשמשים יריבים סבירים. תעדף סגירת פערי זיהוי/מניעה עבור TTPs ספציפיים אלה.

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

ניהול הרשאות מופרזות (ריבוי הרשאות) עבור זהויות על פני Azure, AWS ו-GCP.

→פרוס את Microsoft Entra Permissions Management (CIEM). השתמש בו לגילוי מתמשך של הרשאות, הערכת סיכונים (מדד זחילת הרשאות), ויצירת המלצות להתאמת גודל הרשאות לאכיפת הרשאה מינימלית.

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

תכנון תוכנית לזיהוי הוצאת נתונים (exfiltration) או חבלה על ידי עובדים פנימיים.

→יישם את Microsoft Purview Insider Risk Management. שלב עם מערכות משאבי אנוש כדי להפעיל מדיניות על בסיס אירועי תעסוקה (לדוגמה, התפטרות). הגדר מדיניות בהתבסס על מחווני סיכון והשתמש בפסאודונימיזציה להגנה על פרטיות במהלך ניתוח ראשוני.

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

תכנון אבטחת רשת עבור טופולוגיית Azure סטנדרטית של hub-and-spoke.

→פרוס Azure Firewall Premium ב-VNet המרכזי לבדיקת תעבורה מרכזית (כולל IDPS ובדיקת TLS). השתמש ב-User-Defined Routes (UDRs) כדי לאלץ ניתוב תעבורה מהחיבורים הצידיים. השתמש ב-NSGs למיקרו-סגמנטציה בתוך החיבורים הצידיים. אפשר Azure DDoS Protection במרכז.

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

מקור↗

תכנון למניעת תנועה של תוקף מתחנת עבודה שנפרצה לשרתים קריטיים (Tier 0).

→יישם את מודל הניהול המדורג. השתמש בחשבונות ייעודיים ונפרדים ובתחנות עבודה לגישה מיוחסת (PAWs) לרמות שונות של ניהול (Tier 0, 1, 2). אכוף שאישורי Tier 0 לעולם לא ישמשו במערכות ברמה נמוכה יותר.

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

אבטחת סביבת טכנולוגיה תפעולית (OT) עם התקני מדור קודם שאינם יכולים להריץ סוכני אבטחה.

→פרוס את Microsoft Defender for IoT באמצעות חיישני רשת פסיביים ונטולי סוכנים. יישם סגמנטציית רשת המבוססת על מודל פורדו ליצירת DMZ בין IT ל-OT. שלב התראות Defender for IoT לתוך Microsoft Sentinel.

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

תכנון אבטחה לעומק עבור עומסי עבודה של Azure Kubernetes Service (AKS).

→שלב את Microsoft Defender for Containers (סריקת רישום, זיהוי איומי זמן ריצה) עם Azure Policy עבור AKS (בקרת קבלה לאכיפת תקני אבטחה כמו איסור על קונטיינרים מיוחסים) ומדיניות רשת (למיקרו-סגמנטציה בין פודים).

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

מקור↗

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

→השתמש ב-ExpressRoute עם private peering כחיבור ראשי, ו-VPN אתר לאתר כגיבוי כשל. אפשר הצפנת MACsec או IPsec מעל ExpressRoute. השתמש ב-Private Endpoints לגישה לשירותי Azure PaaS.

למה: ExpressRoute מספק חיבור פרטי וייעודי, עוקף את האינטרנט הציבורי. Private Endpoints מבטיחים שתעבורת PaaS תישאר גם היא מחוץ לאינטרנט. הצפנה מעל ExpressRoute מספקת הגנה לעומק.

תכנון אבטחה מקסימלית עבור חשבון Azure Storage המכיל נתונים רגישים.

→השבת גישה ציבורית וגישה אנונימית. השתמש ב-Private Endpoints לגישת רשת. השתמש בזהויות מנוהלות (managed identities) לאימות יישומים. אכוף הצפנה עם מפתחות מנוהלי לקוח (CMK). אפשר את Microsoft Defender for Storage לזיהוי איומים.

למה: גישה שכבתית זו מטפלת בכל וקטורי האבטחה העיקריים: חשיפה לרשת (Private Endpoints), ניהול אישורים (managed identities), בקרת הצפנה (CMK), ואיומי זמן ריצה (Defender for Storage).

החלת ניהול אבטחה וניהול תאימות עקביים על שרתים מקומיים ורב-ענניים.

→צרף את השרתים ל-Azure Arc. זה מרחיב את מישור הבקרה של Azure, ומאפשר ניהול באמצעות Microsoft Defender for Cloud (CSPM/CWP), יישום Azure Policy (כולל תצורת אורח), ושימוש בשירותים כמו Update Management.

למה: Azure Arc היא הטכנולוגיה הבסיסית ליצירת מישור ניהול ואבטחה יחיד על פני נכסי שרתים היברידיים ורב-ענניים.

מקור↗

אבטחת גישת עובדים מרוחקים גם ליישומי אינטרנט/SaaS וגם ליישומים ארגוניים פרטיים.

→יישם את Global Secure Access של מיקרוסופט. השתמש ב-Microsoft Entra Internet Access כ-Secure Web Gateway (SWG) לתעבורת SaaS/אינטרנט. השתמש ב-Microsoft Entra Private Access כפתרון Zero Trust Network Access (ZTNA) להחלפת VPNs מסורתיים.

למה: זה מספק פתרון SSE מאוחד וממוקד זהות, המיישם מדיניות אבטחה עקבית ללא קשר למיקום המשתמש או סוג המשאב, ומתיישר עם עקרונות Zero Trust המודרניים.

תכנון הגנה מקיפה עבור מכונות וירטואליות של Azure.

→אפשר את Microsoft Defender for Servers Plan 2, הכולל Defender for Endpoint (EDR). השתמש בגישת Just-in-Time (JIT) ל-VM כדי לסגור יציאות ניהול כברירת מחדל. השתמש ב-Azure Bastion לגישה ניהולית מאובטחת מבוססת מתווך ללא כתובות IP ציבוריות.

למה: זה מספק הגנה שכבתית: JIT ו-Bastion מצמצמים את משטח התקיפה, בעוד Defender for Servers מספק זיהוי איומים ותגובה מתקדמים (EDR) לעומס העבודה עצמו.

הגנה על נתונים רגישים ביותר בזמן שהם מעובדים (data-in-use) מפני גישה מיוחסת, כולל מנהלי ענן.

→השתמש במכונות וירטואליות של Azure Confidential Computing (לדוגמה, מבוססות AMD SEV-SNP) או בקונטיינרים סודיים ב-AKS. זה יוצר סביבת ביצוע מהימנה (TEE) מבוססת חומרה שבה נתונים וקוד מוצפנים ומבודדים במהלך הביצוע.

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

חיזוק סביבת Active Directory מקומית מורכבת מפני התקפות ממוקדות.

→תעדף יישום מודל הניהול המדורג למניעת תנועה רוחבית. פרוס את קבוצת האבטחה Protected Users ואת תאי מדיניות האימות כדי להגן על חשבונות מיוחסים מפני התקפות גניבת אישורים (לדוגמה, Pass-the-Hash).

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

יישום גישת Zero Trust מיוחסת למנהלי Azure ו-Microsoft Entra ID.

→פרוס את Microsoft Entra Privileged Identity Management (PIM). המר את כל ההקצאות המיוחסות הקיימות ל-"זכאי". הגדר הפעלה מוגבלת בזמן, תהליכי אישור לתפקידים קריטיים, וסקירות גישה חובה.

למה: PIM הוא שירות הליבה של מיקרוסופט ליישום גישת Just-in-Time (JIT) והרשאה מינימלית עבור תפקידי Azure/Entra, ומבטל את הסיכון המשמעותי של גישה מיוחסת קבועה.

מקור↗

תכנון מבנה מדיניות גישה מותנית הניתן להרחבה ולניהול.

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

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

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

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

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

ניהול גישה מאובטחת לסוגים שונים של משתמשים חיצוניים (שותפים, לקוחות).

→השתמש בשיתוף פעולה Microsoft Entra B2B עבור שותפים וקבלני משנה, המנוהל על ידי מדיניות גישה חוצת דיירים. השתמש ב-Microsoft Entra B2C עבור יישומים הפונים ללקוחות, המספק ספרייה נפרדת וניתנת להרחבה עם מסעות משתמש הניתנים להתאמה אישית.

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

הגנה עקבית על נתונים רגישים על פני Microsoft 365 ו-Azure.

→פרוס את Microsoft Purview Information Protection. השתמש בסיווג אוטומטי (סוגי מידע רגישים, מסווגים ניתנים לאימון) כדי להחיל תוויות רגישות. הגדר תוויות לאכיפת הגנה (הצפנה, הגבלות גישה) על נתונים בכל מקום שבו הם נמצאים.

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

אבטחת ממשקי API פנימיים וחיצוניים מפני איומים נפוצים.

→פרוס את Azure API Management כשער מאוחד. אכוף אימות חזק עם OAuth 2.0. הגדר מדיניות להגבלת קצב ואימות בקשות. אפשר את Microsoft Defender for APIs לזיהוי איומי זמן ריצה.

למה: אבטחת API דורשת שער שישמש כנקודת אכיפת מדיניות. שילוב בקרות מונעות (מדיניות APIM) עם בקרות גילוי (Defender for APIs) מספק הגנה לעומק מפני התקפות ספציפיות ל-API.

שילוב אבטחה לתוך צינור CI/CD כדי למצוא פגיעויות מוקדם ("shift-left").

→יישם את GitHub Advanced Security (או Defender for DevOps). שלב סריקת קוד אוטומטית (SAST), סריקת תלויות (SCA) וסריקת סודות ישירות לתוך צינור ה-CI ותהליך בקשת המשיכה. השתמש בשערי אבטחה לחסימת בנייה עם פגיעויות קריטיות.

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

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

→השתמש ב-Azure Key Vault. בודד כספות לפי יישום או גבול אבטחה. השתמש בזהויות מנוהלות (managed identities) עבור משאבי Azure כדי לגשת לכספת (ללא אישורים מאוחסנים). אפשר מחיקה רכה והגנה מפני טיהור. נטר באמצעות Defender for Key Vault.

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

יישום אבטחה שכבתית עבור מסד נתונים רגיש של Azure SQL.

→שלב הצפנת נתונים שקופה (TDE) עם מפתחות מנוהלי לקוח (CMK), Always Encrypted עבור עמודות רגישות ספציפיות, מיסוך נתונים דינמי למשתמשים לא מיוחסים, Microsoft Defender for SQL לזיהוי איומים, ואימות מבוסס Azure AD בלבד.

למה: אין בקרה אחת מספיקה. גישה שכבתית זו מגנה על נתונים במנוחה (TDE), בשימוש (Always Encrypted), מפני צפייה לא מורשית (מיסוך), מפני איומים (Defender), ומבטיחה אימות חזק (Azure AD).

מניעת אובדן נתונים על פני דוא"ל, Teams, SharePoint, והתקני קצה.

→פרוס את Microsoft Purview DLP. צור מדיניות מאוחדת החלה על שירותי M365 ונקודות קצה. ישר כללי DLP עם תוויות רגישות. השתמש ב-Endpoint DLP כדי לשלוט בפעולות בהתקנים מנוהלים (לדוגמה, חסימת העתקה ל-USB).

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

הכנת סביבת הנתונים של ארגון לפריסה מאובטחת של Copilot עבור Microsoft 365.

→לפני הפריסה, התמקד בניהול מידע (information governance). השתמש בכלים כמו SharePoint Advanced Management כדי למצוא ולתקן אתרים וקבצים ששותפו יתר על המידה. ודא שאסטרטגיה חזקה של סיווג נתונים ותיוג רגישות קיימת ומיושמת.

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

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

→השתמש ב-Azure Application Gateway עם Web Application Firewall (WAF) במצב מניעה. שלב סריקת SAST/DAST לתוך צינור ה-CI/CD. אפשר את Microsoft Defender for App Service לניטור זמן ריצה. מקם את App Service על Private Endpoint.

למה: זה מספק הגנה במספר שכבות: בקצה (WAF), בקוד (SAST/DAST), בפלטפורמה (Defender), וברשת (Private Endpoint), ומתמודד עם מגוון רחב של איומי יישומי אינטרנט.

תכנון אימות עבור מיקרו-שירותים ב-AKS כדי לגשת זה לזה ולשירותי Azure PaaS ללא אישורים מאוחסנים.

→יישם את Azure AD Workload Identity כדי לאפשר לפודי Kubernetes לרכוש אסימוני Azure AD. השתמש ב-service mesh (לדוגמה, Istio, Linkerd) לאכיפת mTLS (mutual TLS) לכל תקשורת שירות-לשירות בתוך האשכול.

למה: דפוס זה מבטל לחלוטין סודות ארוכי טווח (סיסמאות, מפתחות) מסביבת היישום, ומשפר באופן משמעותי את מצב האבטחה. Workload Identity מטפל באימות צפון-דרום ל-Azure, בעוד mTLS מטפל באימות מזרח-מערב בתוך האשכול.

עמידה בדרישות תאימות מחמירות (לדוגמה, FIPS 140-2 Level 3) לאחסון מפתחות קריפטוגרפיים.

→השתמש ב-Azure Key Vault Managed HSM. זה מספק HSM ייעודי, יחיד-דייר, בעל אימות FIPS 140-2 Level 3, המנוהל במלואו על ידי מיקרוסופט אך מעניק ללקוח שליטה מלאה על תחום האבטחה.

למה: עבור רמת התאימות ובקרת המפתחות הגבוהה ביותר, נדרש Managed HSM על פני שכבות Key Vault הסטנדרטיות/פרימיום, המשתמשות ב-HSMs משותפים, מרובי-דיירים (FIPS 140-2 Level 2).

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

→תכנן צינור מאובטח באמצעות רישומי חבילות פרטיים (לדוגמה, Azure Artifacts), סריקת תלויות (SCA), יצירת Software Bill of Materials (SBOM), חתימת חפצים (artifact signing), ואימות מקוריות (provenance verification).

למה: זה מטפל במספר שלבים של שרשרת האספקה: שליטה על קלטים (רישום פרטי), אימות רכיבים (SCA, SBOM), והבטחת שלמות הפלטים (חתימה, מקוריות).