הטמעת SSO בארגון: שלבים, עלויות ורשימת בדיקה
הכנה להטמעת SSO: מיפוי יישומים ואחריות, בדיקת רישוי ועלויות, חיבור כלי העבודה, פיילוט, גישת חירום ותחזוקה.
הטמעת SSO בארגון מסייעת לרכז את הכניסה לכלי העבודה כשחשבונות נפרדים מקשים על ניהול הגישה. מפו את היישומים, בעלי האחריות והחשבונות לפני בחירת החיבורים ורכישת הרישוי. המדריך מתמקד בהכנה, בחיבור דרך Microsoft Entra ID או Google Workspace, בבדיקת עלויות, בפיילוט ובתחזוקה.
1. חלוקת האחריות לאימות, להרשאות ולניהול חשבונות
תעדו לכל יישום מי אחראי לאימות המשתמשים, מי מאשר הרשאות ומי פותח וסוגר חשבונות. בעל התהליך העסקי יאשר את התפקידים הנדרשים לעבודה; IT ומנהל היישום יבדקו שההגדרות בשני הצדדים מממשות את ההחלטה.
בדקו ותעדו לכל יישום אם קיימת דרך נתמכת ליצירה, לעדכון ולהשבתת חשבונות, ומה דורש טיפול ידני. הגדירו אחראי לכל פעולה ואופן אימות להשלמתה, כדי שחיבור הכניסה לא ישאיר חשבונות ללא טיפול.
2. הכנת הארגון להטמעת SSO
לפני הטמעת SSO בוחרים ספר משתמשים מרכזי ומוודאים שלכל יישום יש חיבור נתמך ורישוי מתאים. אם אתם כבר משתמשים ב-Entra ID או ב-Google Workspace, בדקו תחילה את הסביבה הקיימת. מנהל התפעול ימפה מערכות, בעלים עסקיים ותהליכים קריטיים; IT יבדוק הרשאות ניהול, בעלות ואימות דומיינים, כתובות משתמשים וחשבונות אורחים. התוצר הוא טבלת מוכנות מאושרת הכוללת גם חשבונות שירות וכניסות מקומיות שעלולות להישאר מחוץ לבקרה הארגונית.
בחרו חיבור שהיישום וספק הזהויות תומכים בו בפועל, לפי הוראות האינטגרציה שלהם. ספק התוכנה יאשר את דרך החיבור, המסלול המסחרי ותהליך התמיכה; העסק יאשר קבוצות ותפקידים, וספק המחשוב יתעד את ההגדרות והבדיקות בשני הצדדים.
סביבת עבודה או יישום | דרך החיבור לבדיקה | רישוי ותלויות |
|---|---|---|
Microsoft Entra ID | חיבור מהקטלוג או אינטגרציה נתמכת | שיוך קבוצות ליישום דורש Microsoft Entra ID P1 או P2 ואינו כולל קבוצות מקוננות, לפי <a href="https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/assign-user-or-group-access-portal">תיעוד Microsoft</a>. בדקו בנפרד את זכאות החיבור ואת דרישות הרישוי ל-Conditional Access. |
Google Workspace כספק זהויות | אפליקציית SAML מוכנה או מותאמת | בדקו את הזכאות בסביבה שלכם ואת תמיכת היישום. הגדרת יישום SAML מותאם דורשת Super administrator, לפי <a href="https://knowledge.workspace.google.com/admin/apps/set-up-your-own-custom-saml-app?hl=en">הוראות Google</a>. |
SUMIT Books | חיבור SAML לפי הוראות הספק | לפי <a href="https://help.sumit.co.il/books/he/articles/13940158-הפעלת-אימות-משתמשים-באמצעות-sso-saml">תיעוד SUMIT Books מ-1 ביוני 2026</a>, השירות זמין במסלול יהלום ומעלה. הוראות החיבור ל-Microsoft Entra ID כוללות פנייה לתמיכה עם פרטי ההגדרה. |
מערכת ותיקה | בדיקת חיבור ארגוני נתמך | אם אין חיבור נתמך, בדקו שדרוג, שער גישה נתמך או החלפה. עד להשלמת הפתרון, נהלו חשבונות אישיים וביטול גישה בתהליך מתועד. |
3. חיבור כלי העבודה ובדיקת חוויית העובדים
בחיבור SAML, קבלו מספק היישום את Entity ID ואת ACS URL והגדירו אותם בהתאם להוראות החיבור. העבירו ליישום את פרטי ספק הזהויות ואת תעודת החתימה או קובץ המטא-דאטה הנדרשים, לפי הוראות Google להגדרת יישום SAML. בחיבורים אחרים, פעלו לפי הוראות היישום וספק הזהויות ותעדו את ההגדרות המאושרות.
לעובדים צריכה להיות כניסה מוכרת שמחזירה אותם לחשבון הנכון, ללא יצירת חשבון כפול. כשמתקבלת שגיאה, IT ישווה את כתובת הדוא״ל ומזהה המשתמש שנשלחו, הדומיין, שיוך המשתמש והחשבון הקיים ביישום. כינוי דואר אינו בהכרח מזהה ההתחברות שהמערכת מצפה לו. תרחיש המחשה, שאינו מקרה לקוח: עובדת נכנסת בהצלחה ל-Google, אך כלי השירות מזהה אותה בכתובת מדומיין קודם. הפתרון הוא מיפוי מאושר ושמירת החשבון הקיים, לאחר בדיקת בעלות על המידע וההרשאות.
4. בדיקת עלויות ותנאים להפעלת אכיפה
עלות הפרויקט מורכבת מרישוי הזהויות, שדרוגי יישומים, עבודת ההטמעה והתחזוקה לאחר ההשקה. השתמשו בטבלת הרישוי והתלויות להכנת הבדיקה, ובדקו בתיעוד Microsoft העדכני ל-Conditional Access את הזכאות ליכולת ולמדיניות מבוססת סיכון. ודאו שהרישוי מכסה את המשתמשים ואת היכולות המתוכננות. בקשו הצעה בשקלים המפרידה תשלום חוזר, עבודה חד-פעמית, מע״מ והתחייבות למסלולי SaaS.
משך הפרויקט נקבע לפי מוכנות המערכות והספקים, ומועד האכיפה נקבע לפי תוצאות הפיילוט. לצורך הצעה מוגדרת, הניחו ספר משתמשים קיים, דומיין מאומת, חיבורים נתמכים וללא פיתוח ייעודי; ציינו בנפרד חריגים ומערכות ותיקות. מנהל הפרויקט יקבל מכל ספק מועד להשלמת הגדרה ותיקון תקלות. לפני השקה, בעל התהליך העסקי יאשר שפעולות העבודה הנדרשות הצליחו, שמשתמש לא מורשה נחסם ושנבדקה חזרה לאחור. כך אפשר לקבל החלטה על סמך ראיות, בלי להפוך תאריך יעד לתחליף לבדיקה.
רשימת בדיקה לאישור הפיילוט
- בעל היישום: אשרו כניסה לחשבון הנכון, תפקיד מתאים וביצוע פעולה עסקית מייצגת.
- IT: בדקו חסימת משתמש שאינו מורשה לגשת ליישום.
- IT: בדקו טיפול בכתובת משתמש שאינה תואמת לחשבון הקיים.
- IT: ודאו שהדרישה ל-MFA נאכפת בהתאם למדיניות שהוגדרה.
- IT וההנהלה: תעדו הגדרות קודמות, תנאי עצירה ומי מוסמך לאשר חזרה לאחור.
- מנהל המערכת: בדקו גישת חירום מוגנת ומנוטרת בהתאם להנחיות הספק.
- מנהל התפעול: הכינו הודעת מעבר לעובדים וכתובת לפניות תמיכה.
- בעל התהליך העסקי: תעדו אישור לסיום הפיילוט לפני הפעלת אכיפה.
5. צמצום הסיכון לנעילה ותחזוקת הגישה לאחר ההשקה
צמצמו את הסיכון לנעילה באמצעות גישת חירום שנבדקה מראש, מדיניות גישה מדורגת ואחריות קבועה לתחזוקה. רכזו כניסות עם MFA ובחנו אמצעים עמידים לפישינג כאשר נתמכים, משום שריכוז הזהות מגדיל את חשיבות ההגנה על החשבון. חשבון חירום לניהול אינו מבטיח כניסה ל-SaaS בזמן השבתת ספק הזהויות; לכל יישום דרוש מסלול התאוששות מאושר משלו. קבעו אחראי לחידוש תעודות וסודות, התראות תפוגה, בדיקת יומנים והסלמת תקלות. לתכנון ההיבט האנושי אפשר להיעזר גם במדריך העברת Microsoft Authenticator לטלפון חדש.
בדיקת עזיבת עובד צריכה לכלול גם חיבור שכבר פתוח ביישום, מפני שחסימת החשבון בספק הזהויות אינה בהכרח מבטלת אותו. תיעוד Microsoft לביטול גישה מבהיר שהיישום שולט בחיבור שהוא עצמו יצר, ושביטול הגישה עשוי להימשך זמן בהתאם לסביבה. מנהל המערכת ישבית את הזהות, יפעיל ביטול חיבורים לפי הוראות הספק ויבדוק את התוצאה בכל כלי, לרבות השבתת חשבון היישום בדרך הנתמכת בו. תעדו תוצאות, העברת בעלות על מידע וגישת המחליפים בחשבונותיהם האישיים. לאחר שינוי תפקיד, הסירו הרשאות קודמות ובדקו מחדש את הנחוצות. הגדירו את האחריות הזאת כחלק מתהליך קליטה ועזיבת עובדים.
בדקו עם גורם משפטי מתאים את דרישות אבטחת המידע החלות על העסק ועל המערכות שתחברו. תרגמו את ההנחיות למשימות עם בעלי אחריות, תיעוד ובדיקת השלמה. שמרו את אישורי ההרשאות ואת תוצאות הבדיקות במקום נגיש לגורמים המורשים.