התשובה הקצרה
Identity architecture ב-Salesforce אינה פרויקט טכני חד-פעמי אלא שכבת בקרה שרצה כל יום: מי נכנס, באיזו זהות, עם אילו הרשאות, ומה קורה ברגע שהוא כבר לא אמור להיכנס. הבחירה בין SAML ל-OIDC, בין JIT ל-SCIM ובין מדיניות MFA ברמת ה-IdP לבין אכיפה פנימית ב-Salesforce - כל אלה נראים כפרטי הגדרה, אך בפועל הם קובעים כמה זמן לוקח לחסום גישה של עובד שפוטר, ואיזה חלק מהתקריות האלה יתגלה רק בביקורת.
הגישה הנכונה מתחילה לא בפרוטוקול אלא בשתי שאלות: מי מקור האמת לזהות המשתמש, ומהו הזמן המרבי המותר בין אירוע Offboarding לבין חסימת גישה בפועל. משם נגזרות כל שאר ההחלטות - סוג ה-Federation, שיטת ה-Provisioning, מדיניות ה-Session ותהליך ה-Break Glass.
ארגונים שמתלבטים גם בשאלת ההרשאות עצמן ולא רק באימות, ימצאו הרחבה במודל ההרשאות של Salesforce.
מפת ההחלטות: ארבע שכבות של Identity ב-Salesforce
| שכבה | השאלה שצריך להכריע | האפשרויות המרכזיות | מה נשבר אם מחליטים לא נכון |
|---|---|---|---|
| Federation ואימות | מי ה-Identity Provider ואיך Salesforce סומך עליו | SAML 2.0, OIDC, Delegated Authentication | כניסה כפולה, אי-תאימות Attributes, פרצת אמון |
| Provisioning ומחזור חיים | איך משתמש נוצר, מתעדכן ומבוטל | JIT Provisioning, SCIM, יצירה ידנית | חשבונות יתומים, גישה שנשארת אחרי עזיבה |
| Session ו-MFA | איפה נאכפת רמת האימות ומשך ה-Session | MFA ב-IdP, MFA פנימי ב-Salesforce, Session Policies | עקיפת MFA דרך נתיב חלופי, Session שלא פג לעולם |
| Break Glass ו-Audit | מה קורה כש-SSO נופל ומי בודק חריגות | משתמש חירום מבוקר, Login History, Event Monitoring | תלות מוחלטת ב-IdP, חוסר יכולת חקירה בדיעבד |
SAML מול OIDC: לא שאלה של "מה חדש יותר"
הבחירה בין שני הפרוטוקולים לא אמורה להיגזר מטרנד אלא מהתשתית הקיימת. SAML פועל מול XML ו-Assertions חתומות, ונפוץ בארגונים עם Active Directory Federation Services או IdP ותיק שכבר משמש עשרות מערכות אחרות. OIDC בנוי מעל OAuth 2.0, קליל יותר לתחזוקה, ונוח במיוחד כשאותו IdP צריך לשרת גם צרכני API מודרניים לצד כניסת המשתמשים.
הטעות הנפוצה היא לבחור לפי מה שנראה "מתקדם" בלי לבדוק אילו Attributes ה-IdP הקיים כבר שולח, ואיך הם ממופים ל-Salesforce (Username, Federation ID, Profile, Permission Set Group). מיפוי Attribute שגוי בשלב ההקמה גורר לרוב תיקון ידני של עשרות משתמשים בפרודקשן, ולא רק שינוי הגדרה.
נקודה שנשכחת: גם כשבוחרים OIDC או SAML, כדאי לתכנן IdP-Initiated מול SP-Initiated Login בנפרד - חלק מהתקריות האבטחה הנפוצות נובעות מכך ש-SP-Initiated נשאר פתוח למרות שכל תהליך הכניסה התוכנן דרך פורטל ה-IdP בלבד.
JIT Provisioning מול SCIM: מתי "ברגע הכניסה" לא מספיק
JIT (Just-In-Time) Provisioning יוצר או מעדכן את המשתמש ב-Salesforce בזמן ההתחברות הראשונה, לפי הנתונים שמגיעים מה-IdP ב-SAML Assertion או ב-OIDC Token. זה נוח, זול ליישום, ומספיק לרוב הארגונים שבהם המשתמשים מתחברים באופן שוטף.
הבעיה: JIT לא פותר Deprovisioning. אם עובד מוסר מה-IdP אבל לא מתחבר יותר, המשתמש שלו נשאר פעיל ב-Salesforce ללא הגבלת זמן, כי אין אירוע שמפעיל עדכון. זהו בדיוק המקום שבו SCIM (System for Cross-domain Identity Management) נכנס - הוא מאפשר סנכרון יזום מה-IdP ל-Salesforce, כולל דה-אקטיבציה מיידית כשמשתמש מוסר במקור.
הכלל המעשי: אם לארגון יש דרישת Offboarding תוך שעות ולא ימים - קבלני משנה, עובדים זמניים, גישה לנתונים רגישים - SCIM הוא לא Nice-to-have אלא דרישת Compliance. אם מחזור העובדים איטי וה-Governance כבר כולל סבב רבעוני של סקירת גישות, JIT לבדו יכול להספיק בתנאי שהוא מלווה בתהליך ידני מתועד לחסימה מיידית.
תכנון הפרוביז'ן צריך תמיד להיבחן גם מול המורכבות של האוטומציה סביבו - למשל כשמעורבים Flow שמריצים לוגיקת הקצאת הרשאות בזמן יצירת המשתמש, שם רלוונטית ההשוואה בFlow מול Apex לגבי היכן שווה קוד מותאם.
MFA ו-Session Policy: שתי שכבות, לא אחת
טעות נפוצה היא להסתפק ב-MFA שנאכף ב-Identity Provider ולהניח שהוא מכסה את כל נתיבי הכניסה ל-Salesforce. בפועל, כל עוד קיים משתמש שיכול להתחבר ישירות דרך login.salesforce.com - למשל אינטגרציה, API User, או Admin שמחזיק גישת גיבוי - נדרשת מדיניות MFA נפרדת שמוגדרת בתוך Salesforce עצמה (Identity Verification, Session Security Levels).
לצד זה, מדיניות ה-Session קובעת דברים שקל לפספס: Session Timeout, "Force logout on session timeout", Login IP Ranges, ו-High Assurance Session חובה לפעולות רגישות (למשל שינוי הרשאות או ייצוא נתונים המוני). ארגון שמגדיר MFA חזק אך משאיר Session Timeout על ברירת המחדל של שעתיים, פותח חלון שבו מחשב שנגנב שומר גישה פעילה הרבה מעבר לזמן הסביר.
Break Glass ו-Audit: כשה-SSO נופל, מי נכנס
תלות מלאה ב-IdP חיצוני יוצרת נקודת כשל יחידה: אם ה-IdP נופל או אם קיים באג בקונפיגורציית ה-Federation, אף אחד לא יכול להתחבר, כולל מי שצריך לתקן את התקלה. הפתרון המקובל הוא משתמש Break Glass - חשבון מנהל-על עם אימות עצמאי (לא תלוי ב-SSO), סיסמה שמנוהלת בכספת (Vault) ולא בזיכרון של אדם, ו-MFA נפרד.
חשוב להבחין: Break Glass אינו "פתח אחורי נוח" - הוא מנגנון חירום מבוקר. שימוש בו חייב להפעיל התראה אוטומטית, ולהיבדק תוך יום עסקים על ידי גורם שאינו מי שהשתמש בו. ארגונים רבים מקימים את המשתמש נכון אך שוכחים את הבקרה השוטפת - הסיסמה לא מסתובבת, וההרשאות שלו רחבות מדי כברירת מחדל.
תרחיש ארגוני: כשל Offboarding בחברת ביטוח בינונית
נניח חברת ביטוח עם כשש מאות עובדים, המשתמשת ב-Okta כ-Identity Provider ובהגדרת SAML מול Salesforce שהוקמה לפני כשלוש שנים. ה-Provisioning מבוסס כולו על JIT: כשעובד חדש מתחבר בפעם הראשונה, נוצר לו משתמש עם Profile ו-Permission Set Group לפי קבוצת ה-Okta שהוא משתייך אליה.
באחד המקרים, נציג שירות פוטר ביום שישי אחר הצהריים. צוות ה-IT השבית אותו ב-Okta מיד. בפועל, מכיוון שלא היה מנגנון SCIM או Webhook שמסנכרן דה-אקטיבציה ל-Salesforce, המשתמש שלו נשאר במצב Active שם - ומכיוון שה-Session שלו כבר היה פעיל מהבוקר ולא הוגדר "Force logout on session timeout", הוא המשיך לגשת למערכת גם אחרי הפיטורים, עד שמישהו שם לב בסקירת גישות שבועית ביום שני.
הפתרון שהוטמע לא היה מעבר מלא ל-SCIM (שהיה דורש פרויקט נפרד ותקציב אינטגרציה), אלא שילוב מיידי של שלוש פעולות: הפעלת "Force logout on session timeout" עבור כל הפרופילים הרגישים, קיצור Session Timeout מ-120 דקות ל-30 דקות לתפקידים מול לקוחות, והוספת שלב אוטומטי בתהליך ה-Offboarding הארגוני שמריץ דה-אקטיבציה ישירה ב-Salesforce כפעולה עצמאית ולא רק כתוצאה עקיפה של השבתה ב-Okta. SCIM נשאר ביעד לרבעון הבא, כבר עם תקציב ואישור, אבל הפער המסוכן ביותר נסגר תוך שבוע.
סיכונים נפוצים ופעולות מניעה
| סיכון | איך הוא נראה בפועל | פעולת מניעה |
|---|---|---|
| תלות מלאה ב-JIT בלי דה-פרוביז'ן | משתמשים שעזבו נשארים Active ללא הגבלת זמן | הוספת שלב Offboarding עצמאי ב-Salesforce, לא תלוי סנכרון |
| MFA רק ב-IdP | משתמשי אינטגרציה ו-Admin עוקפים MFA דרך כניסה ישירה | מדיניות MFA פנימית ב-Salesforce לכל סוגי המשתמשים |
| Session Timeout ארוך מדי | מחשב גנוב או Session שנשכח פתוח שומר גישה שעות | קיצור Timeout ו-Force Logout לפרופילים רגישים |
| Break Glass ללא בקרה | שימוש בחשבון חירום לא מתגלה בזמן | התראה אוטומטית וסקירה תוך יום עסקים לכל שימוש |
| מיפוי Attributes שגוי מה-IdP | משתמש מקבל Profile או Role לא נכונים בכניסה הראשונה | בדיקת מיפוי מלאה בסביבת Sandbox לפני שינוי בפרודקשן |
Checklist להקמה או לביקורת של Identity Architecture
- ☐ הוגדר Identity Provider יחיד כמקור אמת, וידוע מה קורה כשהוא נופל
- ☐ נבחר פרוטוקול (SAML או OIDC) לפי תשתית קיימת ולא לפי מגמה
- ☐ מיפוי Attributes בין ה-IdP ל-Profile/Permission Set Group נבדק ב-Sandbox
- ☐ הוגדרה מדיניות ברורה: JIT בלבד, או JIT בשילוב SCIM לפי דרישת Offboarding
- ☐ MFA נאכף גם בתוך Salesforce, לא רק ב-IdP
- ☐ Session Timeout ו-Force Logout מוגדרים לפי רגישות הפרופיל
- ☐ קיים משתמש Break Glass מבוקר, עם MFA נפרד וסיסמה בכספת
- ☐ תהליך Offboarding כולל צעד עצמאי לדה-אקטיבציה ב-Salesforce
- ☐ Login History ו-Event Monitoring נבדקים לפי לוח זמנים קבוע
- ☐ קיימת תוכנית בדיקה תקופתית (Access Review) שאינה תלויה רק בזיכרון של IT
איך מודדים שהארכיטקטורה עובדת
המדד המרכזי אינו "האם SSO פעיל" אלא זמן התגובה בין אירוע במקור האמת לבין שינוי מקביל ב-Salesforce: כמה זמן עובר בין הסרת משתמש ב-IdP לבין דה-אקטיבציה בפועל. מדד משלים הוא שיעור הכניסות שמבוצעות דרך נתיב לא צפוי (Direct Login במקום דרך ה-IdP), שאמור לשאוף לאפס מלבד Break Glass מתועד. מדד שלישי הוא תדירות סקירת ההרשאות מול המצב בפועל - לא כל שינוי ארגוני מגיע דרך ה-IdP, ולכן סקירה רבעונית נשארת הכרחית גם עם Provisioning אוטומטי מלא.
ליישום או לביקורת של ארכיטקטורת Identity בסביבת Salesforce קיימת, אפשר להתקדם דרך שירות ארכיטקטורת CRM. ארגונים שבודקים גם את החיבור ל-ERP ולמערכות שכר כחלק מתמונת הזהות הכוללת ימצאו רקע משלים בחיבור Salesforce ל-ERP, ותמונת ארכיטקטורה רחבה יותר במדריך ארכיטקטורת CRM.
סיכום
Identity architecture ב-Salesforce נבנית פעם אחת אבל נבחנת כל יום מחדש דרך התקרית הבודדת - עובד שעוזב, Session ששוכח להיסגר, אינטגרציה שעוקפת MFA. הבחירות המרכזיות (SAML מול OIDC, JIT מול SCIM, MFA כפול, Break Glass מבוקר) לא צריכות להיגזר מברירת מחדל של ה-IdP אלא מזמן התגובה הנדרש לחסימת גישה ומרמת הרגישות של המידע שנחשף. ארגון שמתכנן את השכבה הזו מראש, במקום לגלות את הפערים בביקורת או אחרי אירוע אבטחה, חוסך גם עלות תיקון וגם סיכון תדמיתי ורגולטורי.