מקור אמת אחד לשאלה מי יכול לגשת למה.

ארכיטקטורת זהויות ובחירת פלטפורמה

רוב ההשוואות בין פלטפורמות נענות ברמה הלא נכונה. SSO הוא יכולת, לא קטגוריית מוצר שמתחרה ב-IdP. השאלה היא כמה ארכיטקטורת זהויות הארגון באמת צריך: יש סביבות שכניסה מרכזית ו-MFA אחיד עונים על הצורך שלהן במלואו, ויש כאלה שצריכות סביבו גם ניהול מחזור חיים ובקרה. תשלום על השנייה כשצריך את הראשונה הוא תשלום על יכולות שלא תגדירו בפועל.

לפעמים נכון להפעיל יותר מפלטפורמה אחת. לניהול מכשירים, לשירותי ספרייה ולניהול הרשאות יש דרישות שונות, והכלי הטוב ביותר לכל אחד מהם אינו תמיד אותו ספק. מה שלא ניתן לפצל הוא הסמכות: פלטפורמה אחת מחזיקה בסמכות על מצב הזהות וההרשאות במערכות היעד, גם כשסטטוס ההעסקה מגיע ממערכת ה-HR, והשאר צורכות ממנה.

לפעמים הפלטפורמה הנוכחית מתאימה, והבעיה היא באופן שבו היא מוגדרת. אילו בקרות ואילו אותות בכלל זמינים תלוי בפלטפורמה, ברמת הרישוי שלה, בארכיטקטורת תחנות הקצה ובמערכת שעליה מגנים, ולכן אנחנו מבררים את הדרישות האלה לפני שממליצים על פלטפורמה או על שדרוג.

אימות, MFA וגישה ללא סיסמה

האימות הוא הנקודה שבה השתלטות על חשבון נעצרת, או לא. אנחנו מתכננים את המודל סביבו: אילו אמצעי אימות מתקבלים ואיך תהליכי ההרשמה והשחזור עובדים בלי להפוך בעצמם לחוליה החלשה.

שיטות אימות עמידות בפני פישינג קושרות את המפתח למכשיר עצמו, כך שאין קוד שאפשר להעביר לתוקף שביקש אותו. המשתמש מאמת את עצמו מקומית מול המכשיר, בטביעת אצבע, בזיהוי פנים או בקוד מכשיר לפי החומרה, והמפתח הפרטי נשאר במכשיר. ‏Okta FastPass, ‏JumpCloud Go ו-Passkeys מבוססי תקנים הם דוגמאות לדרך שבה זה מיושם.

כשההתחברות היומיומית מפסיקה להישען על סיסמאות חוזרות, נעלם אחד מפרטי ההתחברות שהכי קל לגנוב באמצעות פישינג, לעשות בו שימוש חוזר ולהזין אותו לתקיפות אוטומטיות. זה מצמצם את משטח התקיפה ולא סוגר אותו, ולכן המסלולים שנשארים פתוחים, כמו תהליכי שחזור, פרוטוקולים ישנים וחשבונות שירות, מטופלים במפורש.

SSO ופדרציה של אפליקציות

חיבור SAML ו-OIDC לכל מערכות ה-SaaS, כולל המערכות הבעייתיות: Authorization Servers ייעודיים, תכנון הרשאות ל-API, מערכות שתומכות בתקן רק חלקית ופלטפורמות שדורשות מיפוי מותאם של claims.

התכנון קובע מה כל מערכת מקבלת ממערכת הזהויות ועל מה היא סומכת: אילו claims ואילו קבוצות מגיעות אליה, ואיך הן מתורגמות להרשאות בתוכה. מערכת שאינה תומכת בפדרציה מקבלת מסלול חלופי במקום להישאר מחוץ למודל.

אנחנו קובעים סדר עדיפויות לפי סיכון ולא לפי קלות, כך שהמערכות שמחזיקות את קוד המקור, את מידע הלקוחות ואת הכסף מחוברות ראשונות.

הקצאת משתמשים, מאפיינים ומחזור חיים

תהליכי קליטה, שינוי ועזיבה אוטומטיים שמתחילים במערכת משאבי האנוש, עוברים דרך מערכת הזהויות וממשיכים למערכות היעד. הרשאות ניתנות לפי תפקיד ביום הראשון. בסיום ההעסקה הן נשללות אוטומטית בכל מערכת שתומכת בכך. בקרות הזהות ובקרות המערכת עצמה משמשות לביטול sessions פעילים במקום שבו יש תמיכה בכך, ומה שלא ניתן להפוך לאוטומטי מתועד ונכנס לסקירה במקום להישכח.

הרשאות שנגזרות מתפקיד עובדות רק אם מודל הנתונים שמתחתיהן בנוי נכון. אנחנו מגדירים אילו מאפיינים הם מקור הסמכות, איך הם ממופים בין המערכות, את כללי הקבוצות שקוראים אותם ואת שיוך האפליקציות והרישיונות שנגזר מהן. שינוי במערכת משאבי האנוש מתפשט משם הלאה בעצמו, לכל הרשאה יש כלל כתוב ולא זיכרון של מי שהוסיף אותה, והדיווח מראה שהתהליך אכן רץ.

גישה מותנית ומדיניות אימות

לא כל בקשת גישה זהה. מדיניות הגישה קוראת את ההקשר שסביב ההתחברות: מי המשתמש ובאיזה תפקיד, לאיזו מערכת הוא ניגש וכמה היא רגישה, האם המכשיר מוכר ומנוהל, באיזו רמת אימות הוא התחבר ומאיפה הגיעה הבקשה.

במקום שבו הפלטפורמה תומכת בכך, מערכת רגישה יכולה לדרוש מכשיר מנוהל ואימות חזק יותר, ובקשה ממכשיר לא מוכר או מהקשר חריג נחסמת או נדרשת לאימות נוסף. מיקום הוא אינדיקציה, לא הוכחה למיקום פיזי: איתור לפי כתובת IP הוא משוער, ולכן אפשר להגביל גישה ממדינות שבהן החברה לא פועלת, וגיאוגרפיה חריגה מעלה את רף הבדיקה במקום להכריע לבדה.

המטרה היא שגישה רגילה תהיה קלה יותר וגישה חריגה תהיה קשה יותר.

סקירת הרשאות וניהול גישה בהרשאות גבוהות

סקירה נקודתית של מי מחזיק במה, כולל הרשאות שמעולם לא עברו תהליך מסודר. אנחנו ממפים את ההרשאות, מזהים הרשאות אדמין והרשאות רגישות שנשארות פעילות באופן קבוע, מתכננים מודל קבוצות שמחליף הקצאה פרטנית, וקובעים תדירות סקירה שההנהלה יכולה לקחת עליה אחריות. אותו תכנון צריך גם לשמור על גישת חירום מבוקרת היטב, כדי שתקלה במדיניות או בפלטפורמה לא תנעל את הארגון מחוץ לסביבה של עצמו.

התוצר מובנה לצורכי ביקורת: מלאי הרשאות, יומן תיקונים ותהליך מתועד.

סקירת ספקים וניהול ספקים

פלטפורמה חדשה לא אמורה לקבל גישה למידע של החברה רק מפני שמישהו צריך את המוצר. אנחנו בודקים לאילו מערכות ולאילו נתונים הפלטפורמה צריכה גישה, דרך אילו אינטגרציות או הרשאות API, איך היא מבצעת אימות, איזה מידע היא מחזיקה, אילו משתמשים או קבוצות באמת צריכים אותה, והאם רמת האבטחה והתאימות שלה מתאימה לשימוש המבוקש.

האישור הוא רק ההתחלה. אנחנו מגדירים איזו גישה מותרת, אילו מגבלות חלות, מי הבעלים של הפלטפורמה, מי מחזיק בהרשאות הניהול ואיך מנוהלים חשבונות השירות, איך משתמשים מקבלים גישה אליה ואיך הגישה מוסרת, ומתי צריך לבחון את זה מחדש. שינויים באינטגרציות, בהרשאות, ברישוי או באופן השימוש העסקי נבדקים מחדש ולא יורשים את האישור המקורי לתמיד.