הנה רעיון מעניין: מה אם אפשר להשאיר את Okta כמרכז ה-SSO למאות אפליקציות SaaS, ועדיין לנצל את חבילת האבטחה העוצמתית של Microsoft, כמו Conditional Access, Identity Protection, PIM ותאימות התקנים ב-Intune? לא צריך להעביר הכול ל-Microsoft Entra כדי לקבל הגנה ברמה ארגונית.
למה זה חשוב
ארגונים רבים שמשתמשים ב-Okta לזהויות ול-SSO מתעלמים מכך שאפשר לנצל את מנוע האבטחה של Entra ID בלי להוציא את האפליקציות מ-Okta. עם הגדרה חכמה, באמצעות Microsoft כ-External Identity Provider, אפשר:
- לאכוף תאימות התקנים דרך Intune
- להחיל Conditional Access לפי סיכון והקשר הסשן
- להגן על חשבונות בעלי הרשאות מורחבות עם PIM
- לקבל נראות ושליטה דרך Identity Governance ו-Protection
והכול תוך שמירה על מערך אפליקציות ה-SaaS שמבוסס על Okta. זה שיפור אבטחה עוצמתי ובעל השפעה נמוכה.
✅ איך זה עובד: Microsoft כ-External IdP של Okta
Microsoft הכריזה לאחרונה על תמיכה ב-OpenID Connect עבור external identity providers (כרגע בתצוגה מקדימה ציבורית). גם Okta מספקת הנחיות מובנות להגדרה מול Entra ID באמצעות OIDC.
הנה הסקירה:
- Entra ID = רשות הזהות
- משתמשים מתחברים דרך Azure AD.
- האימות נבדק על ידי Conditional Access + Identity Protection.
- Intune בודק את תאימות ההתקן במהלך ההתחברות.
- Okta = מאגד SSO
- Okta סומכת על Entra לצורך אימות דרך OIDC.
- המשתמש מזין פרטים פעם אחת בהתחברות ל-Azure, ואז עובר ב-SSO לאפליקציות SaaS דרך Okta.
- מדיניות האבטחה נמצאת ב-Entra
- MFA, אותות סיכון, בדיקות התקן, מדיניות סשן ו-PIM מטופלים על ידי Microsoft.
- בינתיים, חוויית ה-SaaS נשארת ללא שינוי דרך הדשבורדים של Okta.
🔐 מה אבטחת Microsoft מביאה לסביבת ה-Okta שלכם
הנה מה שנפתח כשמכניסים את Entra לשרשרת האימות:
- Conditional Access: אכיפת MFA, חסימת התחברויות legacy, דרישת התקנים תואמים, הערכת התנהגות מסוכנת.
- תאימות התקנים ב-Intune: בדיקה אוטומטית אם התקני ההתחברות עומדים בתקני התאימות שלכם.
- Identity Protection: זיהוי דפוסי התחברות חשודים; חסימת התחברויות או דרישת תיקון לפי רמות סיכון.
- Privileged Identity Management: אבטחת תפקידי אדמין ברמת Azure ואפליקציות SaaS; אישור בקשות העלאת הרשאות "just-in-time".
- Identity Governance: סקירות גישה, ניהול זכאויות, attestation, הכול מובנה.
אין צורך לשכפל את זה ב-Okta, תנו ל-Microsoft לעשות את העבודה הכבדה.
🚀 צעדים מעשיים: הגדרה בשלושה מהלכים
1. הפעילו OpenID Connect External IdP ב-Entra
השתמשו בתצוגה המקדימה הציבורית של Microsoft כדי לרשום את Okta כאפליקציה ב-Entra, והגדירו את נקודות הקצה של OIDC ואת אמון התעודה של Okta.
2. הגדירו את Okta לשימוש ב-Azure כ-IdP
פעלו לפי התיעוד של Okta כדי להגדיר את Azure AD כ-OIDC identity provider. החליפו client IDs ונקודות קצה, והגדירו מיפוי claims (למשל email, name).
3. אבטחו את הסביבה
עכשיו, התחברו דרך Okta ← המשתמש מופנה ל-Azure AD ← המשתמש נבדק עם CA + Intune ← מופנה חזרה ל-Okta ← SSO חלק לאפליקציות. בדקו התחברויות עם MFA ועם אכיפת התקנים.
📌 סיכום היתרונות העיקריים
| יתרון | תיאור |
|---|---|
| חוויית משתמש חלקה | נקודת התחברות אחת, המשתמשים רואים את פורטל Okta המוכר, בלי התחברות חדשה. |
| אבטחה עדיפה | ניצול מדיניות מתקדמת של Microsoft בלי להעביר אפליקציות. |
| השפעה נמוכה, ערך גבוה | בלי שינוי במאות אפליקציות SaaS; שינוי ארכיטקטוני מינימלי. |
| הטמעה הדרגתית | פיילוט עם קבוצות משתמשים או אפליקציות נבחרות לפני הפריסה הרחבה. |
| תמיכה בזהות היברידית | שימושי בתרחישים שממוקדים ב-Microsoft (Intune, M365, Teams וכו'). |
🛠️ שיטות עבודה מומלצות להטמעה חלקה
- פיילוט קטן: התחילו עם צוות פנימי או קבוצה לא קריטית. אמתו את התהליכים מקצה לקצה.
- סנכרנו מאפייני משתמש: ודאו שב-Azure AD וב-Okta יש UPN/מייל תואמים, כדי להבטיח אמון ב-claims.
- סקרו את Conditional Access בקפידה: התחילו במצב "monitor" לפני אכיפה קפדנית של MFA או תאימות. תעדו והבינו את ההשפעה.
- תקשרו בבהירות: הסבירו למשתמשים: "עדיין תתחברו ל-Okta, אבל ייתכן שתתבקשו לבצע Microsoft MFA או בדיקות התקן."
- נטרו ומדדו: השתמשו בלוגי ההתחברות של Azure AD ובדוחות האדמין של Intune כדי לאשר כיסוי ותאימות.
- הרחיבו בחוכמה: כשאתם בטוחים, החילו PIM על תפקידים בעלי הרשאות מורחבות, Identity Protection לזיהוי סיכונים ו-Identity Governance לבקרות מחזור חיים.
🧠 למי זה מתאים?
- לקוחות Okta עם מערכת SaaS מבוססת שרוצים אבטחה נוספת בלי הגירה המונית.
- משתמשי SaaS של Microsoft (חבילת Office 365, Teams, התקנים בניהול Intune) שכבר נהנים מ-AuthN/AuthZ במערכת של Microsoft.
- ארגונים שאבטחה היא בראש סדר העדיפויות שלהם ומחפשים לגשר בין פלטפורמות זהות ולאכוף בקרות תאימות בסביבות היברידיות.
✅ שורה תחתונה
ניצול Microsoft Entra כ-external identity provider של Okta הוא דרך חכמה ופרגמטית לחזק את אבטחת הזהויות, בלי לפרק את מפת הדרכים של Okta. אתם ממשיכים להשתמש ב-Okta להתחברות היומיומית ל-SaaS, אבל עכשיו מנועי האימות, המדיניות והאכיפה רצים דרך המנוע החזק של Microsoft.
אם אתם משתמשים באפליקציות Microsoft 365, ב-Intune, או נוטים ל-Conditional Access או ל-PIM, הגישה ההיברידית הזו מאפשרת לכם לקבל גם מהירות וגם חוזק.
שוקלים לנסות את ההגדרה הזו?
התחילו בקטן: הכניסו קבוצת פיילוט לתהליך הזה, ובדקו מקצה לקצה עם MFA ומדיניות תאימות התקנים. אשמח לעזור אם אתם צריכים checklist או חומרים כדי להתחיל!
🔧 משאבים נוספים
- ההכרזה של Microsoft על תמיכה ב-OpenID Connect עבור external identity provider (תצוגה מקדימה ציבורית):
- התיעוד של Okta על הגדרת Okta עם Microsoft Entra ID כ-Identity Provider:
https://help.okta.com/oie/en-us/content/topics/apps/configure-okta-as-microsoft-entra-id-eam.htm
רוצים לדעת איפה הטננט שלכם עומד? Griffin31 בודק את הגדרות האבטחה של Microsoft 365 אצלכם באופן רציף ומראה מה לתקן קודם.