שליטה ב-Conditional Access ב-Microsoft Entra ID: בניית היקף אבטחה מבוסס Zero Trust

By Mirko Peters · 2026-08-27

ברוכים השבים לפודקאסט! היום נרחיב על נושא שמהווה את היסוד המוצק ביותר של אבטחת ענן מודרנית: Conditional Access ב-Microsoft Entra ID. מי שהאזין לפרק האחרון שלנו יודע שביליתי שעה טובה בהסבר מדוע היקף הרשת המסורתי כבר לא רלוונטי. נגמרו הימים שבהם יכולנו פשוט לתת אמון בכל מה שנמצא מאחורי חומת האש הארגונית. בעידן העבודה מרחוק, הסביבות ההיברידיות ואפליקציות הענן בכל מקום, ההיקף שלכם אינו עוד מיקום פיזי

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

ברוכים השבים לפודקאסט! היום אנחנו מרחיבים על נושא שמהווה את היסוד המוצק ביותר של אבטחת ענן מודרנית: Conditional Access ב-Microsoft Entra ID. מי שהאזין לפרק האחרון שלנו יודע שביליתי שעה טובה בהסבר מדוע היקף הרשת המסורתי כבר לא רלוונטי. נגמרו הימים שבהם יכולנו פשוט לתת אמון בכל מה שנמצא מאחורי חומת האש הארגונית. בעידן העבודה מרחוק, הסביבות ההיברידיות ואפליקציות הענן בכל מקום, ההיקף שלכם אינו עוד מיקום פיזי – הוא הזהות.

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

מבוא ל-Conditional Access ולעקרונות Zero Trust

כדי באמת לשלוט ב-Conditional Access, קודם צריך ליישר קו עם עקרונות Zero Trust. הרעיון המרכזי של Zero Trust אפשר לסכם בשלוש מילים פשוטות: לעולם אל תסמכו, תמיד אמתו. בעבר ארגונים הסתמכו על אסטרטגיית טירה וחפיר. ברגע שמשתמש הצליח לפרוץ את חומות הטירה – בין אם חיבר את עצמו לרשת האתרנט במשרד ובין אם אימת את עצמו בהצלחה דרך VPN ארגוני – הניחו לו לנוע באופן חופשי ברשת. כפי שראינו במתקפות סייבר רבות לאורך השנים, הגישה הזו פגומה ביסודה.

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

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

אנטומיה של מדיניות: השמות ותנאים

בניית מדיניות Conditional Access אפקטיבית דורשת הבנה מעמיקה של הארכיטקטורה שלה. כל מדיניות ב-Microsoft Entra ID מחולקת בעיקרה לשני שלבים מרכזיים: Assignments ו-Access Controls. בשלב ה-Assignments מגדירים על מי המדיניות חלה ולאילו משאבים הם מנסים לגשת. בואו נפרק את היסודות האלה.

ראשית, יש לנו Users and Groups. כאן מגדירים את היקף המדיניות. האם רוצים שהמדיניות תחול על כל המשתמשים בארגון כולו, או שמוטב למקד מחלקות מסוימות, כמו Finance או מנהלי IT? לפי נהלי העבודה המומלצים, בדרך כלל כדאי להתחיל עם קבוצות פיילוט לפני פריסה רחבה, אך בסופו של דבר, קווי הבסיס הקריטיים לאבטחה צריכים לכסות את כולם.

לאחר מכן, נבחן את Cloud Apps or Actions. כאן מגדירים את המשאבים שהמדיניות מגינה עליהם. ניתן למקד אפליקציות ספציפיות כמו Microsoft Exchange Online, SharePoint או אפליקציות ארגוניות מותאמות אישית המשולבות עם Entra ID. אפשר גם להחיל מדיניות על כל אפליקציות הענן, וזו דרך עוצמתית לאכוף עמדת אבטחה בסיסית על כל אפליקציית SaaS שהארגון משתמש בה.

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

סיכון משתמש וסיכון כניסה

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

פלטפורמות מכשיר

ניתן למקד מדיניות לפי מערכת ההפעלה של המכשיר בשימוש, בין אם מדובר ב-Windows, macOS, iOS, Android או Linux. כך ניתן להחיל דרישות אבטחה שונות בהתאם לסוג המכשיר.

מיקומים

Conditional Access מאפשר להגדיר טווחי כתובות IP מהימנים (כמו רשתות משרד הארגון) או לשלב מיקומים מוגדרים לפי קודי מדינה. ניתן להשתמש באותות מיקום אלה כדי לחסום גישה ממדינות בסיכון גבוה, או לדרוש אימות רב-שלבי רק כאשר המשתמשים מתחברים מחוץ להיקף הארגוני המהימן.

הערכת אותות בזמן אמת: מיקום, סיכון ותאימות מכשיר

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

נבחן למשל את מצב המכשיר. באמצעות שילוב עם Microsoft Intune או עם פתרונות ניהול מכשירים ניידים (MDM) של צד שלישי הנתמכים, Conditional Access יכול לבדוק אם המכשיר עומד בתקני האבטחה הארגוניים. האם מערכת ההפעלה מעודכנת? האם הצפנת הדיסק מופעלת? האם המכשיר מנוהל על ידי הארגון, או שמדובר במכשיר אישי לא מנוהל (Bring Your Own Device, או BYOD)? על ידי הערכת מצב המכשיר בזמן אמת, ניתן לוודא שנתוני הארגון זורמים רק לנקודות קצה תקינות ומאובטחות.

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

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

אכיפת אבטחה: בקרות הענקה וחוזקות אימות

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

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

• דרישת אימות רב-שלבי (MFA)
• דרישה שהמכשיר יסומן כתואם
• דרישה למכשיר מצורף היברידית ל-Microsoft Entra
• דרישה ליישום לקוח מאושר
• דרישה למדיניות הגנת יישומים (ניהול יישומים ניידים)
• דרישה לשינוי סיסמה למשתמשים בסיכון גבוה

תכונה חזקה במיוחד שהציגה Microsoft היא Authentication Strengths. בעבר, MFA נתפס לעתים קרובות כבחירה בינארית: או מבצעים MFA או לא. אולם לא לכל שיטות האימות יש אותה רמת אבטחה. מתקפות phishing התפתחו כך שהן עוקפות SMS, שיחות קוליות ואפילו התראות push בסיסיות, באמצעות מתקפות adversary-in-the-middle מתוחכמות.

עם Authentication Strengths ניתן להגדיר בדיוק אילו שיטות אימות מותרות עבור נכסים בעלי ערך גבוה או בתרחישי סיכון גבוה. לדוגמה, ניתן ליצור מדיניות שמחייבת אימות רב-שלבי עמיד בפני הונאות פישינג, כגון מפתחות אבטחה מסוג FIDO2 או Windows Hello for Business, תוך חסימת שיטות פחות מאובטחות כמו SMS או שיחות טלפון רגילות. כך ניתן ליישם מודל אימות מדורג לפי רמת סיכון: באפליקציות היומיומיות אפשר לקבל אימות רב-שלבי רגיל, ואילו פורטלים מנהליים ומערכות פיננסיות רגישות ידרשו אישורי כניסה העמידים בפני פישינג.

שיטות עבודה מומלצות לתכנון ולבדיקה של המדיניות שלכם

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

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

שנית, יש לאמץ מתודולוגיית הטמעה בשלבים. אל תיצרו מדיניות מגבילה ותחילו להחיל אותה מיד על כל המשתמשים. במקום זאת, השתמשו במצב "Report-only". מצב זה מאפשר להעריך את השפעת המדיניות מבלי לאכוף אותה בפועל. Entra ID ירשום ביומני הכניסה אם המדיניות הייתה חוסמת או מאפשרת גישה, וכך תקבלו תמונה ברורה על חיכוך אפשרי למשתמשים או על תהליכי עבודה שייפגעו, עוד לפני שהמדיניות נכנסת לתוקף.

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

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

תודה שהאזנתם וקראתם! שליטה ב-Conditional Access היא מסע, אך ביצוע הצעדים האלה יקדם אתכם משמעותית לבניית היקף אבטחה עמיד מבוסס אפס אמון ב-Microsoft Entra ID. הקפידו להירשם לפודקאסט למעמקים נוספים באבטחת ענן, ונתראה בפרק הבא!