כמעט בכל שיחה על אבטחת זהויות עולה אותו בלבול סביב Conditional Access ב-Microsoft 365 ושכבות ההגנה השונות על זהויות.
אנשים מניחים לא פעם שהפעלת MFA מספיקה, או ש-passkeys מגנים אוטומטית מפני גניבת טוקנים. אחרים מאמינים שתאימות התקן (device compliance) מכסה חטיפת סשנים, או שמדיניות Conditional Access לבדה יכולה לאכוף Zero Trust. המציאות מורכבת יותר.
הבעיה היא לא חוסר ביכולות: Microsoft שחררה יכולות עוצמתיות בשנתיים האחרונות. הבעיה היא שכל בקרה נועדה לפתור בעיה מאוד ספציפית, והבקרות לא מחליפות זו את זו במלואן. אם פורסים אותן בלי להבין מה הן עושות (ומה הן לא עושות), מגיעים לביטחון שווא ולפערים חשופים.
המאמר הזה מפרק את הכול:
- מה כל בקרה מגינה עליו (ומה לא)
- איפה יש חפיפה בין הבקרות, ואיפה ברור שאין
- הפשרות בפריסה, במורכבות ובהשפעה על המשתמשים
- והכי חשוב: מאיפה להתחיל, לפי סוג הסביבה שבה אתם עובדים
המטרה היא לא להפעיל הכול. המטרה היא לבנות מודל הגנה שמתאים באמת לאופן שבו המשתמשים שלכם עובדים, לאן הסיכונים שלכם מכוונים, ולמה שאפשר באמת לתחזק.
ארבע הבקרות שכדאי להכיר
Microsoft מספקת ארבע בקרות מתקדמות על זהויות וסשנים, שמכוונות לחלקים שונים בשרשרת התקיפה:
- Passkeys: מונעות פישינג באמצעות אימות ללא סיסמה, הקשור להתקן.
- Compliant Device: מוודאת שמשתמשים ניגשים לנתונים רק מהתקנים מאובטחים.
- Token Protection: מונעת מתוקפים לעשות שימוש חוזר בטוקני סשן גנובים.
- CAE Strict (preview): מנטרת ומבטלת סשנים לפי חריגות במיקום או ב-IP.
הבקרות האלה עובדות הכי טוב כשמשלבים ביניהן, אבל לכל אחת יש חוזקות, פערים ושיקולי פריסה משלה.
1Passkeys (MFA עמיד בפני פישינג)
מבטלות סיסמאות באמצעות מפתח פרטי שמאוחסן בהתקן (למשל TPM או מפתח אבטחה).
- חזקות מול: פישינג של פרטי התחברות, push fatigue, MFA fatigue ופורטלים מזויפים.
- חלשות מול: גניבת טוקנים אחרי ההתחברות, חטיפת סשנים, איומים ברמת ההתקן.
- שיקולים: דורשות התקנים תואמים; צריך שיטת גיבוי (למשל Temporary Access Pass); עקומת למידה קלה למשתמשים.
2Compliant Devices
חוסמת גישה מהתקנים לא מהימנים או לא תואמים, באמצעות MDM (למשל Intune).
- חזקה מול: התקנים שנדבקו בנוזקה או עברו jailbreak, מחשבים ניידים לא מוצפנים, אכיפת הגבלות BYOD.
- חלשה מול: גניבת פרטי התחברות, token replay, סשנים שנפרצו מהתקנים שהם תואמים בכל השאר.
- שיקולים: מאמץ גבוה בסביבות BYOD; דורשת רישום התקנים והגדרת מדיניות; חששות פרטיות בשימוש מעורב (אישי ועבודה).
3Token Protection
מונעת שימוש בטוקנים גנובים בהתקנים אחרים, באמצעות קשירה קריפטוגרפית של הטוקנים להתקן.
- חזקה מול: token replay, חטיפת סשנים, התבססות לאחר פריצה.
- חלשה מול: פישינג של פרטי התחברות, היגיינת התקנים ירודה; מוגבלת לאפליקציות native של Microsoft 365 (Windows, ו-macOS ו-iOS במכשירים מנוהלים ב-MDM).
- שיקולים: שקופה למשתמשים; עובדת באפליקציות native ב-Windows, וב-macOS וב-iOS רק במכשירים מנוהלים ב-MDM; מגינה על Exchange, SharePoint ו-Teams; בדפדפן יש רק preview לכמה פורטלי ניהול של Azure.
4CAE Strict Location Enforcement
מאמתת באופן רציף את ה-IP והמיקום, ומבטלת סשנים כשהם משתנים באופן לא צפוי.
- חזקה מול: בקרת גישה מבוססת VPN, זיהוי proxy או מיקום מזויף, זיהוי חטיפה באמצע סשן.
- חלשה מול: גניבת פרטי התחברות בעת ההתחברות, גניבת טוקנים בתוך טווח IP מותר, איומים ברמת ההתקן.
- שיקולים: לא יעילה עם split-tunnel VPN; דורשת כתובות IP יציאה ידועות וסטטיות; מתאימה ביותר לפריסות עם מיקום קבוע או בסגנון VDI.
איך הן עובדות יחד
אף בקרה בודדת לא מכסה הכול. כל אחת מטפלת בחלק אחר ב-stack של הזהויות:
| בקרה | פישינג | התקנים לא תקינים | Token replay | חטיפת מיקום/IP |
|---|---|---|---|---|
| Passkeys | כן | לא | לא | לא |
| Compliant Device | לא | כן | לא | לא |
| Token Protection | לא | לא | כן | לא |
| CAE Strict | לא | לא | כן | כן |
הפשרות בפריסה
| בקרה | ערך אבטחתי | השפעה על משתמשים | מאמץ פריסה |
|---|---|---|---|
| Passkeys | גבוה | בינונית | בינוני |
| Compliant Device | גבוה | בינונית | גבוה |
| Token Protection | בינוני | נמוכה | נמוך |
| CAE Strict | בינוני | נמוכה | גבוה |
כל בקרה מוסיפה ערך. העיקר לשלב ביניהן בדרך שמתאימה למשתמשים, לתשתית ולמשטח התקיפה שלכם.
סיכום ביניים
ארבע הבקרות האלה, Passkeys, Compliant Devices, Token Protection ו-CAE Strict, לא מיותרות. הן נועדו לפתור בעיות שונות, בשכבות שונות של ההגנה על זהויות:
- אחת מטפלת בפישינג.
- אחרת אוכפת אמון בהתקן.
- האחרות מגינות על סשנים אחרי ההתחברות.
אם אתם נשענים על MFA בלבד, או משתמשים ב-Conditional Access בלי להבין את התפקיד של כל שכבה, יש סיכוי טוב שאתם משאירים פערים אמיתיים, במיוחד סביב token replay, התקנים לא מנוהלים וחטיפת סשנים.
מה שבאמת חשוב הוא בהירות
- להבין מה כל בקרה נועדה להגן עליו.
- להחליט מאיפה להתחיל לפי המשתמשים, ההתקנים ומודל הסיכון שלכם.
- להיות חכמים לגבי חוויית משתמש, מאמץ פריסה ומגבלות רישוי.
לא צריך להפעיל הכול בבת אחת. אבל כן צריך תוכנית שבנויה על יסודות נכונים, ולא על הנחות.
איך Griffin31 עוזר
ב-Griffin31 מיפינו את כל ארבע הבקרות לפלטפורמה. אנחנו מראים בדיוק אילו מהן כבר פועלות בטננט שלכם, איפה הפערים, ומה הצעד הבא הנכון, לפי השימוש בפועל, סוגי התפקידים והסביבה שלכם.
רוצים לדעת אילו מארבע הבקרות כבר פועלות אצלכם ואיפה הפערים? Griffin31 בודק את הטננט שלכם באופן רציף ומראה מה לתקן קודם.