פישינג, גניבת טוקנים ו-CAE: מה Passkeys לבדן לא פותרים ב-Microsoft 365
פורסם ב-30 ביולי 2025
היי חברים,
רציתי לשתף משהו שעולה כמעט בכל שיחה שלי על אבטחת זהויות: עדיין יש הרבה בלבול סביב Conditional Access ב-Microsoft 365 ושכבות ההגנה השונות על זהויות.
אנשים מניחים לא פעם שהפעלת MFA מספיקה, או ש-Passkeys מגנים אוטומטית מפני גניבת טוקנים. אחרים מאמינים שתאימות התקן (device compliance) מכסה חטיפת סשנים, או שמדיניות Conditional Access לבדה יכולה לאכוף Zero Trust. המציאות מורכבת יותר.
הבעיה היא לא חוסר ביכולות, Microsoft שחררה יכולות עוצמתיות בשנתיים האחרונות. הבעיה היא שכל בקרה נועדה לפתור בעיה מאוד ספציפית, והבקרות לא מחליפות זו את זו במלואן. אם פורסים אותן בלי להבין מה הן עושות (ומה הן לא עושות), מגיעים לביטחון שווא ולפערים חשופים.
הפוסט הזה מפרק את הכול:
- מה כל בקרה מגינה עליו (ומה לא)
- איפה יש חפיפה בין הבקרות, ואיפה ברור שאין
- הפשרות בפריסה, במורכבות ובהשפעה על המשתמשים
- והכי חשוב: מאיפה להתחיל, לפי סוג הסביבה שבה אתם עובדים
המטרה היא לא להפעיל הכול. המטרה היא לבנות מודל הגנה שמתאים באמת לאופן שבו המשתמשים שלכם עובדים, לאן הסיכונים שלכם מכוונים, ולמה שאפשר באמת לתחזק.
ארבע הבקרות שכדאי להכיר
Microsoft מספקת ארבע בקרות מתקדמות על זהויות וסשנים, שמכוונות לחלקים שונים בשרשרת התקיפה:
- Passkeys: מונעות פישינג באמצעות אימות ללא סיסמה, הקשור להתקן
- Compliant Device: מוודאות שמשתמשים ניגשים לנתונים רק מהתקנים מאובטחים
- Token Protection: מונעת מתוקפים לעשות שימוש חוזר בטוקני סשן גנובים
- CAE Strict: מנטרת ומבטלת סשנים לפי חריגות במיקום או ב-IP
הבקרות האלה עובדות הכי טוב כשמשלבים ביניהן, אבל לכל אחת יש חוזקות, פערים ושיקולי פריסה משלה.
1. Passkeys (MFA עמיד בפני פישינג)
מבטלות סיסמאות באמצעות מפתח פרטי שמאוחסן בהתקן (למשל TPM או מפתח אבטחה).
| חזקות מול | פישינג של פרטי התחברות, push fatigue, MFA fatigue ופורטלים מזויפים |
| חלשות מול | גניבת טוקנים אחרי ההתחברות, חטיפת סשנים, איומים ברמת ההתקן |
| שיקולים | דורשות התקנים תואמים; צריך שיטת גיבוי (למשל Temporary Access Pass); עקומת למידה קלה למשתמשים |
2. Compliant Devices
חוסמות גישה מהתקנים לא מהימנים או לא תואמים, באמצעות MDM (למשל Intune).
| חזקות מול | התקנים שנדבקו בנוזקה או עברו jailbreak, מחשבים ניידים לא מוצפנים, אכיפת הגבלות BYOD |
| חלשות מול | גניבת פרטי התחברות, token replay, סשנים שנפרצו מהתקנים שבאופן אחר תואמים |
| שיקולים | מאמץ גבוה בסביבות BYOD; דורשות רישום התקנים והגדרת מדיניות; חששות פרטיות בהגדרות שימוש מעורב (אישי/עבודה) |
3. Token Protection
מונעת שימוש בטוקנים גנובים בהתקנים אחרים, באמצעות קשירה קריפטוגרפית של הטוקנים.
| חזקה מול | token replay, חטיפת סשנים, התבססות לאחר פריצה |
| חלשה מול | פישינג של פרטי התחברות, היגיינת התקנים ירודה, מוגבלת לאפליקציות Microsoft 365 מקוריות ב-Windows |
| שיקולים | שקופה למשתמשים; קלה לפריסה בסביבות Windows המצורפות ל-Entra; לא נתמכת בדפדפנים, בנייד או ב-macOS |
4. CAE 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, התקנים לא מנוהלים וחטיפת סשנים.
מקרה שימוש אמיתי: CAE Strict + Always-On VPN
באחת הפריסות האחרונות אצל לקוחות הפעלנו CAE Strict Location Enforcement בסביבה שמשתמשת ב-Always-On VPN עם ניתוב full-tunnel (כך שגם האימות וגם שירותי Microsoft 365 מנותבים דרך אותן כתובות IP יציאה ארגוניות).
המטרה: לחסום כל ניסיון לעשות replay לטוקנים גנובים, גם אחרי התחברויות תקינות ומוצלחות, באפליקציות שמחוברות ל-Microsoft Graph.
מכיוון שכל התעבורה יוצאת דרך כתובות IP ידועות וסטטיות, CAE יכול היה לאמת באופן רציף את מיקום הסשן. אם טוקן שימש מחדש מ-IP לא צפוי, גם עם refresh token תקף, הגישה בוטלה מיד, בלי להמתין להתחברות האינטראקטיבית הבאה.
בלי CAE Strict, Conditional Access בודק מיקום רק בעת ההתחברות. אחרי זה, אפשר עדיין לעשות replay לטוקן גנוב עד שעה, או עד 28 שעות במקרים מסוימים שבהם האפליקציה מודעת ל-CAE אבל לא משתמשת באכיפה strict. בזמן הזה התוקף יכול להשתמש ב-Microsoft Graph, ב-SharePoint, ב-Teams או בשירותים אחרים עם SSO, מאזור גיאוגרפי או מכתובת IP שבדרך כלל המדיניות הייתה חוסמת.
עם CAE Strict הפער הזה נסגר. הגישה נאכפת באופן רציף ברמת המשאב, וכל חריגת IP מובילה לביטול מיידי של הסשן.
ללקוחות עם full-tunnel VPN ונקודות יציאה קבועות, CAE Strict מספק ערך אמיתי, במיוחד בסביבות שחוששות משימוש לרעה ב-API, מגניבת טוקנים ומתנועה רוחבית דרך replay של סשנים.
מה שבאמת חשוב הוא בהירות:
- להבין מה כל בקרה נועדה להגן עליו
- להחליט מאיפה להתחיל לפי המשתמשים, ההתקנים ומודל הסיכון שלכם
- להיות חכמים לגבי חוויית משתמש, מאמץ פריסה ומגבלות רישוי
לא צריך להפעיל הכול בבת אחת. אבל כן צריך תוכנית שבנויה על יסודות נכונים, ולא על הנחות.
ב-Griffin31 מיפינו את כל ארבע הבקרות לפלטפורמה. אנחנו יכולים להראות בדיוק אילו מהן כבר פועלות ב-tenant שלכם, איפה הפערים, ומה הצעד הבא הנכון, על סמך השימוש בפועל, סוגי התפקידים והסביבה שלכם.