הגיע הזמן ל- Token Binding
שלום לכולם,
החודשים האחרונים היו תקופה מלהיבה במיוחד בתחום תקני הזהויות והאבטחה. הודות למאמצים של קבוצה נרחבת של מומחים בענף, השגנו התקדמות מדהימה בגיבוש ערכה מקיפה של תקנים חדשים ומשופרים שישפרו גם את האבטחה וגם את חוויית המשתמש בדור של שירותי ענן ומכשירי ענן.
אחד מהשיפורים החשובים ביותר הוא משפחת המפרטים Token Binding, אשר נמצאת בדרכה לאישור סופי על-ידי Internet Engineering Task Force (IETF) (אם אתם מעוניינים לקבל מידע נוסף על Token Binding, צפו במצגת הנהדרת של בריאן קמפבל).
ב- Microsoft, אנו סבורים שמשפחת המפרטים Token Binding יכולה לשפר באופן משמעותי את האבטחה של תרחישים ארגוניים וצרכניים, בכך שהיא הופכת את הבטחת האימות והזהויות ברמה גבוהה לנגישה באופן נרחב ופשוט למפתחים ברחבי העולם.
מכיוון שאנו סמוכים ובטוחים שההשפעה שלה תהיה חיובית ביותר, אנו מחויבים מאוד – בהווה ובעתיד – לעבוד עם הקהילה לצורך יצירה והטמעה של משפחת המפרטים Token Binding.
ועכשיו, כשהמפרטים קרובים לקבלת אישור, אני רוצה לקרוא לכם לבצע שתי פעולות:
- התחילו להתנסות ב- Token Binding ולתכנן את הפריסות שלכם.
- פנו לספקי הדפדפנים והתוכנות שלכם ובקשו מהם לספק יישומים של Token Binding בהקדם, אם הם עדיין לא עשו זאת.
ואני שמח להודיע לכם ש- Microsoft היא רק אחת מחברות רבות בענף שטוענות ש- Token Binding מהווה פתרון חשוב שהגיע זמנו.
לקבלת מידע נוסף על החשיבות הטמונה ב- Token Binding, אעביר את רשות הדיבור לפאמלה דינגל – אושיה מובילה בענף שרבים מכם כבר מכירים – אשר משמשת כיום כמנהלת תקני הזהויות של Microsoft בצוות Azure AD.
בברכה,
אלכס סימונס (Twitter: @Alex_A_Simons)
מנהל ניהול תוכניות
חטיבת הזהויות של Microsoft
—————————————————————————————————————————–
תודה לאלכס ושלום לכולם,
אני שמחה בדיוק כמו אלכס! שנים של זמן ומאמץ הושקעו במפרטים שבקרוב יוכרזו כתקני RFC חדשים. עבור ארכיטקטים, הגיע הזמן להתעמק ביתרונות הספציפיים של Token Binding בתחום הזהויות והאבטחה.
אז מה כל כך טוב ב- Token Binding? Token Binding הופך קבצי Cookie, אסימוני גישה ורענון של OAuth ואסימוני מזהים של OpenID Connect לבלתי שמישים מחוץ להקשר TLS הספציפי ללקוח שבו הם הונפקו. בדרך כלל, אסימונים אלו הם אסימונים "נושאים", כלומר שכל אחד שבבעלותו האסימון יכול להחליף את האסימון במשאבים, אך Token Binding משפר את התהליך בכך שהוא מוסיף שכבה של מנגנון אישור שבודק את החומר הקריפטוגרפי שנאסף בזמן הנפקת האסימון מול חומר קריפטוגרפי שנאסף בזמן השימוש באסימון. רק הלקוח הנכון, שמשתמש בערוץ TLS הנכון, יעבור את הבדיקה. תהליך זה, שמאלץ את הישות שמציגה את האסימון להוכיח את עצמה, נקרא "הוכחת בעלות".
מסתבר שניתן להשתמש בקבצי Cookie ובאסימונים מחוץ להקשר TLS המקורי במגוון דרכים זדוניות. לדוגמה, חטיפת קבצי Cookie של הפעלה או דליפת אסימוני גישה, או תקיפה מתוחכמת מסוג 'אדם באמצע' (MiTM). זו הסיבה לכך שמסמך הטיוטה של שיטות העבודה המומלצות בנושא האבטחה עבור OAuth 2 של IEFT ממליץ על Token Binding, וכן הסיבה לכך שהכפלנו לאחרונה את סכומי הפרסים בתוכנית Identity Bounty Program שלנו. בכך שאנו דורשים הוכחת בעלות, אנו הופכים את השימוש האופורטוניסטי או הזדוני בקבצי Cookie או באסימונים לפעולה מורכבת ויקרה עבור האקרים.
בדומה לכל מנגנון של הוכחת בעלות, Token Binding מספק לנו את היכולת ליצור הגנה מעמיקה. אנו יכולים להשתדל לא לאבד אף פעם אסימונים, אך אנו יכולים גם לבצע אימות ליתר ביטחון. בניגוד למנגנונים אחרים של הוכחת בעלות, כגון אישורי לקוח, Token Binding מוכל בתוך עצמו ואינו גלוי למשתמש, והעבודה הקשה מתבצעת על-ידי התשתית. אנו מקווים שכולם יוכלו בסופו של דבר לבחור לפעול ברמה גבוהה של הבטחת זהויות, אך אנו צופים לביקוש ראשוני גבוה מצד גופי ממשל והמגזר הפיננסי, מכיוון שהם כפופים לדרישות רגולטוריות מיידיות שמחייבות לבצע הוכחת בעלות. לדוגמה, כל מי שמשתמש בסיווג AAL3 של NIST 800-63C זקוק לטכנולוגיה מסוג זה.
Token Binding כרוך בתהליך ארוך. התחלנו לפני שלוש שנים, ולמרות שאישור המפרטים מהווה ציון דרך משמח, יש לנו עוד הרבה עבודה, והצלחת המפרט תלויה ביכולת שלו לפעול עבור מגוון ספקים ופלטפורמות. במהלך החודשים הקרובים, נתחיל לשתף באופן מעמיק את יתרונות האבטחה ואת שיטות העבודה המומלצות שנלמדו הודות לשימוש שלנו בפונקציונליות זו. אנו מקווים שתצטרפו אלינו כתומכים בטכנולוגיה זו בכל מקום שבו אתם זקוקים לה.
בברכה,
– פאם
