ביטול הפיצול של כניסות חוצות-דומיינים

Eiji Kitamura

ארכיטקטורות עסקיות מודרניות כוללות לעיתים קרובות כמה דומיינים נפרדים. ארגונים מתחזקים סביבות ייעודיות לתכונות שונות – למשל, brand.example לשיווק, service-app.example למוצר הליבה ו-support-portal.example לשירות לקוחות. מומלץ לספק חוויית כניסה מאוחדת ופשוטה למשתמשים שמנווטים בין הנכסים האלה. עם זאת, צוותי הנדסה משלבים את הדומיינים האלה בדרך כלל באמצעות טכניקות אד-הוק שגורמות לפיצול. הדבר משבש את ניהול פרטי הכניסה המובנה בדפדפן, כי הוא מונע את תהליכי המילוי האוטומטי של מנהל הסיסמאות ומעכב את השימוש במפתחות גישה.

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

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

פתרונות עקיפים נפוצים

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

בקשות אחזור של CORS

כשדומיינים פועלים באופן עצמאי, ממשקי קצה מסתמכים לעיתים קרובות על בקשות fetch() ממקורות שונים שמכוונות אל API מרכזי לאימות, שאפשר לאשר באופן מאובטח באמצעות שיתוף משאבים בין מקורות (CORS). מכיוון שדפדפנים חוסמים או מגבילים לעיתים קרובות קובצי Cookie חוצי-אתרים, יכול להיות שמפתחים יתכננו את ממשקי ה-API האלה במפורש כך שיחזירו אסימוני אימות, כמו אסימוני אינטרנט מסוג JSON‏ (JWT), במטען ייעודי (payload) של JSON, במקום להסתמך על כותרות Set-Cookie.

שיתוף מסד נתונים של חשבון

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

בעיות בכניסות לחשבון שלא מחוברות

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

פיצול של מנהלי סיסמאות

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

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

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

שער פישינג

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

חסימה בגלל מפתח גישה

החיכוך גדל כשמשתמשים במפתחות גישה. ארכיטקטורת האבטחה הבסיסית של WebAuthn קושרת את מפתחות הגישה באופן קריפטוגרפי למזהה צד נסמך (RP ID) ספציפי.

הפעולה הזו יוצרת 'מלכודת מזהה RP'. אי אפשר להשתמש במפתח גישה שנרשם ב-brand.example ב-service-app.example כי הדפדפן חוסם גישה בין דומיינים. כדי שהמשתמשים לא יתבקשו לרשום מפתחות גישה שונים לכל אתר, צריך לאחד את הנכסים האלה למזהה RP יחיד.

גישות מומלצות

כדי ליצור רצף של זהויות, צריך להפסיק להשתמש בשילובים של כניסה אד-הוק ולאמץ סטנדרטים מוכרים של ארכיטקטורה:

• שימוש בקובצי הגדרות של מטא-נתונים: אירוח קובצי מטא-נתונים כמו Digital Asset Links ובקשות שקשורות למקור, כדי ליצור שרשרת של אמון קריפטוגרפי. כך אפשר לשתף בצורה חלקה פרטי כניסה ומפתחות גישה בין דומיינים שונים ואפליקציות לנייד. הגישה הזו היא פתרון זול ושקט לפיצול הזהויות, שלא דורש ארכיטקטורה מורכבת מחדש של תשתית האינטרנט הקיימת.
• שימוש ב-iFrame חוצה-דומיינים: הטמעה של מקור אימות מרכזי כ-iFrame בתוך צד נסמך כדי לגשר בין פרטי כניסה וסיסמאות ששמורים באתרים שונים. הגישה הזו משתמשת במדיניות הרשאות ובקובצי Cookie עם חלוקה למחיצות כדי לאפשר חוויית כניסה חלקה בהקשר, תוך שמירה על גבולות אבטחה קפדניים באמצעות CSP והעברת הודעות בין מסמכים.
• שימוש באיחוד זהויות סטנדרטי: שימוש בפרוטוקולים סטנדרטיים בתעשייה כמו OpenID Connect כדי לרכז את האימות בדומיין ייעודי של ספק זהויות (IdP). השינוי הזה הופך את תהליך הכניסה לרשמי באמצעות הפניות מאובטחות, ומחליף שילובים לא יציבים בפתרון מהימן וניתן להרחבה מאינטראקציה ישירה (First-Party).
• איחוד תתי-דומיינים: מעבר לתתי-דומיינים תחת שורש משותף. כך מתאפשר שיתוף חלק של סשנים באמצעות קובצי Cookie עם תווים כלליים והמשכיות של מפתחות גישה בכל הדומיין שניתן לרישום. הרבה מנהלי סיסמאות יכולים לזהות את דומיין הבסיס המשותף ולהציע באופן אוטומטי פרטי כניסה שמורים בדומיינים משניים קשורים.

שימוש בקובצי תצורה של מטא-נתונים

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

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

כדאי להשתמש בשני קובצי תצורה שונים כדי לוודא שאתם מכסים פלטפורמות ומערכות אקולוגיות שונות:

• מנהל הסיסמאות של Google ב-Android וב-Chrome: מארחים קובץ JSON של Digital Asset Links‏ (DAL) בכתובת /.well-known/assetlinks.json כדי ליצור יחסי אמון שניתנים לאימות בין האפליקציות והאתרים המשויכים של הארגון. המהימנות הזו מאפשרת קישורים עמוקים באפליקציות ושיתוף חלק של פרטי הכניסה, שבו סיסמאות שנשמרו באינטרנט ממולאות אוטומטית באתרים משויכים (אבל שיתוף מפתחות גישה בכמה דומיינים באינטרנט עדיין מחייב בקשות ממקורות קשורים). מידע נוסף זמין במדריך בנושא שיתוף מאובטח של פרטי כניסה.

• סיסמאות של אפל ב-iOS וב-Safari: צריך לארח קובץ Apple App Site Association ‏ (AASA) בכתובת /.well-known/apple-app-site-association כדי ליצור את שרשרת האמון הקריפטוגרפית שנדרשת לגישור בין מצבי הסיסמאות של אפל באפליקציות ל-iOS וב-Safari. כדי לתמוך במערכות אקולוגיות של צד שלישי, אפשר להצהיר על הדומיינים המשויכים האלה באופן מרכזי באמצעות מאגר מידע שמבוסס על מיקור המונים. כך אפשר לוודא שגם כלים עצמאיים (כמו 1Password, שמשתמש במאגר הזה באופן מפורש) יזהו את הקשר של הזהות המשותפת. מידע נוסף על Apple App Site Association זמין במאמר תמיכה בדומיינים משויכים.

כדי להפעיל מפתחות גישה בדומיינים שונים באינטרנט ולפתור את הבעיה שמונעת שימוש במפתחות גישה, מפתחים יכולים לארח קובץ בקשות ממקור קשור (ROR) בכתובת /.well-known/webauthn. רשומת ה-ROR מצהירה במפורש על דומיינים מורשים שמותר להם לשתף בצורה מאובטחת את אותו מזהה RP של מפתח הגישה. מידע נוסף על בקשות שקשורות למקור זמין במאמר איך מאפשרים שימוש חוזר במפתחות גישה באתרים באמצעות בקשות שקשורות למקור.

• יתרונות:
  • תיקון ברקע למשתמשי קצה: התיקון פועל לגמרי ברקע, ומטפל אוטומטית בפיצול של מילוי אוטומטי. הוא גם יוצר המשכיות של מפתחות גישה ברמת מערכת ההפעלה או הדפדפן, בלי שיהיו שינויים גלויים בחוויית המשתמש.
  • יישום פשוט: זהו פתרון בעלות נמוכה, שנדרש בו רק אירוח של קובצי JSON סטטיים. לא נדרשת ארכיטקטורה מחדש של ה-Backend או לוגיקה מורכבת של החלפת טוקנים.
  • שמירה על התשתית הקיימת: אפשר לשפר באופן משמעותי את המסלול של המשתמשים בין הדומיינים בלי לשנות את המותג או לאחד את הדומיינים.
• חסרונות:
  • מגבלות בפלטפורמה: בדרך כלל יש בפלטפורמות מגבלות מחמירות על החזר הוצאות הפרסום. לדוגמה, ב-Chrome יש הגבלה של עד 5 תוויות eTLD+1 שמשויכות למזהה RP יחיד. לדוגמה, ל-example.co.uk ול-example.de יש אותה תווית example eTLD+1, אבל ל-example-rewards.com יש תווית example-rewards נפרדת. אם אתם מנהלים תיק דומיינים גדול או מגוון, יכול להיות שהמגבלות האלה לא יספיקו לכם.
  • הגדלת זמן האחזור התפעולי: כדי לפתור בעיות בקובצי מטא-נתונים, צריך לבצע עוד הלוך ושוב ברשת, מה שמוסיף זמן אחזור כשדפדפן מעבד אימות.

שימוש ב-iframes ממקורות שונים

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

אם מטמיעים מקור אימות מרכזי (לדוגמה, auth.brand.example) כ-iframe בתוך צד נסמך (לדוגמה, brand.example), אפשר ליצור אינטראקציה עם שדות טופס רגילים ועם ממשקי API מודרניים. במקרה של סיסמאות, מנהל פרטי הכניסה של הדפדפן משייך פעולות של מילוי אוטומטי למקור של ה-iframe ‏ (auth.example). כך המשתמשים יכולים לגשת לפרטי הכניסה המרכזיים שלהם בצורה חלקה באתרים שונים.

במקרה של מפתחות גישה, חלון האב צריך להעניק לאיפראם גישה באמצעות מסגרת מדיניות ההרשאות, כדי לאפשר לאיפראם להפעיל את WebAuthn לצורך אימות מול מזהה RP של המקור שלו. בשני התהליכים, CSP (Content Security Policy) שימושי להגנה על משתמשים מפני מתקפות כמו clickjacking ו-cross-site scripting. אחרי שהאימות מצליח, הסשן נוצר עם קובץ Cookie מחולק, והאסימון מועבר באופן מאובטח חזרה לחלון הראשי באמצעות postMessage().

• יתרונות:
  • פרטי כניסה מרכזיים: מאפשרים לעקוף את הבעיה של פיצול פרטי הכניסה. מקור מרכזי יחיד מנהל גם סיסמאות שמורות וגם מזהה RP מאוחד של מפתח גישה, ומאפשר לדומיינים שונים לשתף את פרטי הכניסה האלה בלי צורך לאחד את הדומיינים.
  • אימות הקשרי: כל תהליך הכניסה – בין אם מדובר במילוי אוטומטי של סיסמה או באימות באמצעות מפתח גישה – מתבצע בצורה חלקה בהקשר של דף ההורה, וכך נמנעות הפניות אוטומטיות משבשות של איחוד זהויות.
  • עמידות בפני אמצעי הגנה מפני מעקב: הגישה הזו פועלת בצורה תקינה גם כשמופעלים אמצעי הגנה מחמירים מפני מעקב באתרים שונים באמצעות קובצי Cookie מחולקים.
• חסרונות:
  • אילוצים בהטמעה: הארכיטקטורה הזו דורשת הנדסה מיוחדת. היא דורשת מדיניות CSP מחמירה (frame-ancestors) כדי להגביל את ההטמעה לדומיינים מהימנים של הורה ולמנוע הונאת קליקים, הגדרה של מדיניות הרשאות HTTP כדי להפעיל את WebAuthn API, והודעות מאובטחות ומאומתות בין מסמכים (postMessage()) כדי לצמצם את הסיכון לזיוף מקורות ולמתקפות CSRF. שיטות מומלצות לשימוש במפתחות גישה בתוך iframe

שימוש באיחוד שירותי אימות הזהות הסטנדרטי

שימוש באיחוד זהויות סטנדרטי כמו OpenID Connect הוא גישה חזקה ובת קיימא לשמירה על מערכת החשבונות שלכם. הגישה הזו ממסדת את תהליך העבודה של האימות על ידי איחוד שלו לדומיין ייעודי יחיד של ספק זהויות (IdP), כמו auth.brand.example. באמצעות פרוטוקול מבוסס, האפליקציות מפנות את המשתמשים למרכז הזה לצורך אימות, לפני שהן מקבלות העברת אסימון מאובטחת כדי להשלים את הכניסה בדומיין היעד. למרות שהפדרציה הסטנדרטית משויכת לרוב לכניסות של צד שלישי (כמו כניסה באמצעות חשבון Google), היא פתרון תקף לחלוטין ונמצא בשימוש נרחב כפתרון מאינטראקציה ישירה (First-Party) להחלפת פתרונות עקיפים לא יציבים.

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

איחוד תתי-דומיינים

גישה מבנית נוספת היא לאחד את כל הדומיינים על ידי העברת נכסים דיגיטליים שונים מתחת לדומיין בסיסי משותף שאפשר לרשום (eTLD+1). המשמעות היא מעבר מדומיינים נפרדים כמו brand.example ו-service-app.example לתת-דומיינים כמו www.brand.example ו-service.brand.example.

• יתרונות:
  • ניהול מאוחד של פרטי הכניסה: מנהלי סיסמאות יכולים לזהות את דומיין הבסיס ולטפל בכל תתי-הדומיין כרשומה אחת, וכך למנוע הנחיות כפולות והזנה ידנית של סיסמאות.
  • המשכיות של מפתחות גישה: מפתחים יכולים להגדיר באופן מקורי את מזהה RP של מפתח גישה לדומיין שניתן לרישום, וכך להרחיב באופן מיידי את התמיכה במפתחות גישה לכל תתי הדומיינים המשויכים. במקרה הזה, מזהה RP של brand.example יפעל גם ב-www.brand.example וגם ב-service.brand.example.
  • שיתוף סשנים ללא מאמץ: איחוד מבנה הדומיין מאפשר שיתוף של סשן יחיד באמצעות קובצי Cookie עם תווים כלליים (לדוגמה, הגדרת היקף של קובץ Cookie ל-Domain=brand.example).
• חסרונות:
  • הגבלות על מיתוג והעברה: הגישה הזו עלולה להגביל את המיתוג אם הארגון שלכם מחייב שימוש בדומיינים נפרדים ברמה העליונה. המיגרציה מורכבת ודורשת ניהול קפדני של הפניות אוטומטיות של HTTP וטיפול נרחב בהגדרות מיושנות של בקשות חוצות מקורות.

סיכום

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

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