אבטחת שכבת התעבורה של אפליקציה (ALTS)

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

סיכום ברמת מנהל מערכות המידע

  • אבטחת שכבת התעבורה של אפליקציה (ALTS) של Google היא מערכת להצפנת תעבורה ולאימות הדדי שפותחה על ידי Google, ובדרך כלל משמשת לאבטחת תקשורת של קריאה לשירות מרוחק (RPC) בתשתית של Google. הקונספט של ALTS דומה לזה של TLS עם אימות הדדי, אבל הוא תוכנן ועבר אופטימיזציה כדי לענות על הצרכים של סביבות מרכזי הנתונים של Google.
  • מודל האמון של ALTS מותאם לאפליקציות מבוססות-קונטיינרים שדומות לאפליקציות בענן. זהויות קשורות לישויות ולא למארח או לשם של שרת ספציפי. כך מתאפשר לבצע בצורה חלקה שכפול של מיקרו-שירותים, איזון עומסים ותזמון מחדש בין מארחים.
  • פרוטוקול ALTS מסתמך על שני פרוטוקולים: פרוטוקול לחיצת היד (עם חידוש סשן) ופרוטוקול הרישום. הפרוטוקולים האלה קובעים איך מתבצעות הפעולות הבאות: יצירת סשנים, אימות, הצפנה וחידוש.
  • ‫ALTS הוא פתרון מותאם אישית לאבטחת שכבת התעבורה שבו אנחנו משתמשים ב-Google. התאמנו את ALTS לסביבת הייצור שלנו, ולכן יש כמה הבדלים בין ALTS לבין תקן התעשייה, TLS. פרטים נוספים זמינים בקטע שיקולים.

מבוא

מערכות Production ב-Google מורכבות ממקבץ של מיקרו-שירותים1 שביחד מנפיקים O(1010) קריאות לשירות מרוחק (RPC) בכל שנייה. כשמהנדס של Google מתזמן עומס עבודה של ייצור2, כל קריאות ה-RPC שמונפקות או מתקבלות על ידי עומס העבודה הזה מוגנות באמצעות ALTS כברירת מחדל. ההגנה האוטומטית הזו, שלא דורשת הגדרה, מסופקת על ידי אבטחת שכבת התעבורה של אפליקציה (ALTS) של Google. בנוסף להגנות האוטומטיות שמוענקות ל-RPC,‏ ALTS גם מאפשר שכפול קל של שירותים, איזון עומסים ותזמון מחדש בין מכונות ייצור. במאמר הזה מתואר פרוטוקול ALTS ומוסבר על הפריסה שלו בתשתית הייצור של Google.

למי מיועד המסמך: לאנשי מקצוע בתחום אבטחת התשתית שרוצים לדעת איך מתבצע אימות ואבטחת תעבורה בקנה מידה גדול ב-Google.

דרישות מוקדמות: בנוסף למבוא הזה, צריכה להיות לכם הבנה בסיסית בניהול אשכולות ב-Google.

אבטחה ברמת האפליקציה ו-ALTS

אפליקציות רבות, מדפדפני אינטרנט ועד רשתות VPN, מסתמכות על פרוטוקולי תקשורת מאובטחים, כמו TLS ‏ (Transport Layer Security) ו-IPSec, כדי להגן על נתונים בזמן ההעברה3. ב-Google אנחנו משתמשים ב-ALTS, מערכת להצפנת תעבורה ולאימות הדדי שפועלת בשכבת האפליקציה, כדי להגן על תקשורת RPC. שימוש באבטחה ברמת האפליקציה מאפשר לאפליקציות לקבל זהות מאומתת של עמית מרוחק, שאפשר להשתמש בה כדי להטמיע מדיניות הרשאות מפורטת.

למה לא TLS?

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

  • יש הבדל משמעותי בין מודלי האמון4 של TLS עם סמנטיקה של HTTPS לבין ALTS. במקרה הראשון, זהויות השרת קשורות לשם ספציפי ולסכימת שמות תואמת. ב-ALTS, אפשר להשתמש באותה זהות עם כמה סכימות של שמות. רמת ההפניה העקיפה הזו מספקת גמישות רבה יותר ומפשטת מאוד את תהליך השכפול של מיקרו-שירותים, איזון העומסים והתזמון מחדש בין מארחים.
  • בהשוואה ל-TLS, ‏ ALTS פשוט יותר בעיצוב וביישום שלו. כתוצאה מכך, קל יותר לעקוב אחרי באגים ופרצות אבטחה באמצעות בדיקה ידנית של קוד המקור או באמצעות fuzzing נרחב.
  • ב-ALTS נעשה שימוש ב-Protocol Buffer כדי לבצע סריאליזציה של האישורים והודעות הפרוטוקול, וב-TLS נעשה שימוש באישור X.509 שמקודד באמצעות ASN.1. ברוב שירותי הייצור שלנו נעשה שימוש ב-protocol buffers לתקשורת (ולפעמים לאחסון), ולכן ALTS מתאים יותר לסביבה של Google.

עיצוב ALTS

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

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

מודל האמון של ALTS

האימות ב-ALTS מתבצע בעיקר לפי זהות ולא לפי מארח. ב-Google, לכל ישות ברשת (למשל, משתמש ארגוני, מכונה פיזית או שירות ייצור) יש זהות משויכת. הזהויות האלה מוטמעות באישורי ALTS ומשמשות לאימות עמיתים במהלך יצירת חיבור מאובטח. המודל שאנחנו פועלים לפיו הוא שהשירותים שלנו בסביבת הייצור פועלים כיישויות ייצור שאפשר לנהל באמצעות Site Reliability Engineers ‏(SREs)5. גרסאות הפיתוח של שירותי הייצור האלה פועלות כישויות בדיקה שאפשר לנהל אותן גם באמצעות SRE וגם באמצעות מפתחים.

לדוגמה, נניח שיש לנו מוצר עם שני שירותים: service-frontend ו-service-backend. מהנדסי SRE יכולים להפעיל את גרסת הייצור של השירותים האלה: service-frontend-prod ו-service-backend-prod. מפתחים יכולים ליצור ולהפעיל גרסאות פיתוח של השירותים האלה, service-frontend-dev ו-service-backend-dev, למטרות בדיקה. הגדרות ההרשאה בשירותי הייצור יוגדרו כך שלא יתבססו על גרסאות הפיתוח של השירותים.

פרטי כניסה ל-ALTS

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

  • אישור מאסטר: נחתם על ידי שירות חתימה מרחוק ומשמש לאימות אישורים של לחיצת יד. אישור המאסטר מכיל מפתח ציבורי שמשויך למפתח פרטי של מאסטר, למשל: זוג מפתחות RSA. המפתח הפרטי הזה משמש לחתימה על אישורים של לחיצת יד. האישורים האלה, כשהם משמשים בשילוב עם מדיניות ALTS שמפורטת בהמשך, הם למעשה אישורי רשות אישורים (CA) ביניים מוגבלים. בדרך כלל מונפקים אישורים ראשיים למכונות ולמתזמנים של עומסי עבודה בקונטיינרים, כמו Borgmaster6.
  • אישור ללחיצת יד: נוצר ונחתם באופן מקומי על ידי המפתח הפרטי הראשי. האישור הזה מכיל את הפרמטרים שמשמשים במהלך לחיצת היד של ALTS (ביסוס חיבור מאובטח), לדוגמה, פרמטרים סטטיים של Diffie-Hellman ‏ (DH) וצפנים של לחיצת היד. בנוסף, אישור הלחיצת היד מכיל את אישור האב שממנו הוא נגזר, כלומר, האישור שמשויך למפתח הפרטי הראשי שחותם על אישור הלחיצת היד.
  • מפתח המשך: סוד שמשמש להצפנת כרטיסי המשך. המפתח הזה מזוהה על ידי מזהה המשך (Resumption Identifier)R שהוא ייחודי לעומסי עבודה של סביבת ייצור שפועלים עם אותה זהות ובאותה תא של מרכז נתונים, ומשותף ביניהם. פרטים נוספים על חידוש סשן ב-ALTS זמינים במאמר בנושא חידוש סשן.

איור 1 מציג את שרשרת האישורים של ALTS, שכוללת מפתח אימות של שירות חתימה, אישור ראשי ואישור ללחיצת יד. מפתחות האימות של שירות החתימה הם שורש האמון ב-ALTS, והם מותקנים בכל המכונות של Google ברשתות הייצור והרשתות הארגוניות שלנו.

איור 1: שרשרת אישורים של ALTS

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

הנפקת אישור

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

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

באיור 2 מוצג אופן השימוש בשירות החתימה ליצירת אישור ראשי. התהליך מורכב מהשלבים הבאים:

איור 2: הנפקת אישור

  1. מנפיק האישור שולח בקשת חתימה על אישור (CSR) לשירות החתימה. בבקשה הזו, שירות החתימה מתבקש ליצור אישור עבור זהות A. לדוגמה, הזהות הזו יכולה להיות משתמש ארגוני או הזהות של שירות ייצור של Google.
  2. שירות החתימה מגדיר את המוסד המנפיק של האישור (שכלול ב-CSR) כמגיש הבקשה (הרשות המנפיקה במקרה הזה) וחותם עליו. חשוב לזכור שהמפתח הציבורי (לאימות) של שירות החתימה המתאים מותקן בכל המכונות של Google.
  3. שירות החתימה שולח חזרה את האישור החתום.
  4. נוצר אישור ללחיצת היד עבור זהות א', והוא נחתם על ידי המפתח הפרטי שמשויך לאישור הראשי

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

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

אישורים של בני אדם

ב-Google, אנחנו משתמשים ב-ALTS כדי לאבטח קריאות RPC שמונפקות על ידי משתמשים אנושיים לשירותי ייצור. כדי להנפיק RPC, המשתמש צריך לספק אישור לחיצת יד תקף. לדוגמה, אם אליס רוצה להשתמש באפליקציה כדי להנפיק RPC מאובטח באמצעות ALTS, היא יכולה לבצע אימות ל-CA הפנימי שלנו. אליס מאמתת את עצמה מול הרשות שמנפיקה את האישורים (CA) באמצעות שם המשתמש, הסיסמה והאימות הדו-שלבי שלה. הפעולה הזו גורמת לכך ש-Alice מקבלת אישור לביצוע לחיצת יד שתקף ל-20 שעות.

אישורי מכונה

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

אישורים של עומסי עבודה

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

כל עומס עבודה ברשת הייצור שלנו פועל בתא Borg. כל תא מכיל בקר מרכזי לוגי שנקרא Borgmaster, וכמה תהליכי סוכן שנקראים Borglets ופועלים בכל מכונה בתא. עומסי העבודה מאותחלים עם אישורי לחיצת יד משויכים של עומסי עבודה שהונפקו על ידי Borgmaster. איור 3 מציג את תהליך האימות של עומס עבודה ב-ALTS עם Borg.

איור 3: יצירת אישור ללחיצת היד ברשת הייצור של Google

ה-Borgmaster מוכן עכשיו לתזמן עומסי עבודה שצריכים להשתמש ב-ALTS. השלבים הבאים מתרחשים כשלקוח מתזמן הרצת עומס עבודה ב-Borg בתור זהות נתונה.

  1. כל Borgmaster מגיע עם אישור ראשי של מכונה ומפתח פרטי משויך (לא מוצג בתרשים) שהותקנו מראש.
  2. השירות ALTSd11 יוצר אישור ללחיצת יד של Borgmaster וחותם עליו באמצעות המפתח הפרטי של המכונה הראשית. אישור לחיצת היד הזה מאפשר ל-Borgmaster להנפיק קריאות RPC מאובטחות ב-ALTS.
  3. ה-Borgmaster יוצר אישור בסיסי של עומס עבודה ומפתח פרטי תואם. ה-Borgmaster יוזם בקשה (RPC מאובטח ב-ALTS) כדי לקבל את אישור הבסיס של עומס העבודה חתום על ידי שירות החתימה. כתוצאה מכך, שירות החתימה מציג את Borgmaster כמנפיק באישור הזה.
  4. מערכת Borgmaster מאמתת שהלקוח מורשה להריץ עומסי עבודה בתור הזהות שצוינה בהגדרות של עומס העבודה. אם כן, Borgmaster מתזמן את עומס העבודה של Borg ב-Borglet, ומנפיק אישור ללחיצת יד של עומס העבודה ואת המפתח הפרטי התואם שלו. האישור הזה הוא חלק משרשרת שמתחילה באישור הראשי של עומס העבודה הבסיסי. לאחר מכן, אישור לחיצת היד של עומס העבודה והמפתח הפרטי שלו מועברים בצורה מאובטחת אל Borglet (דרך ערוץ מוגן ב-ALTS עם אימות הדדי בין Borgmaster לבין Borglet). ה-Borgmaster מבצע רוטציה של אישור המאסטר של עומס העבודה הבסיסי, ומנפיק מחדש אישורי לחיצת יד לכל עומסי העבודה הפעילים בערך כל יומיים. בנוסף, כל עומס עבודה שפועל כאותו משתמש באותה תא מקבל את אותו מזהה (IDR) ואותו מפתח להמשך הפעולה שהוקצו על ידי Borgmaster.
  5. כשהעומס צריך לבצע קריאה מאובטחת לשירות מרוחק (RPC) באמצעות ALTS, הוא משתמש בתעודת לחיצת היד של עומס העבודה בפרוטוקול לחיצת היד. המזהה R משמש גם כחלק מלחיצת היד כדי להפעיל את חידוש הסשן. מידע נוסף על חידוש סשנים ב-ALTS זמין במאמר חידוש סשנים.

אכיפת המדיניות של ALTS

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

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

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

איור 4: הנפקת אישורים ושימוש בהם

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

ביטול אישור

ב-Google, אישור נפסל כשהתוקף שלו פג או כשהוא נכלל ב רשימת האישורים שבוטלו (CRL) שלנו. בקטע הזה מתואר העיצוב של מנגנוני ביטול האישורים הפנימיים של Google.

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

איור 5: יצירת אישור ראשי עם RevocationID

  1. כשמאתחלים מופע של רשות האישורים שלנו12, הוא יוצר קשר עם שירות ה-CRL ומבקש טווח של מזהי ביטול. מזהה ביטול הוא מזהה באורך 64 ביט עם שני רכיבים: קטגוריית אישור באורך 8 ביט (למשל אישור של אדם או של מכונה) ומזהה אישור באורך 56 ביט. שירות ה-CRL בוחר טווח של מזהים כאלה ומחזיר אותו לרשות האישורים.
  2. כש-CA מקבל בקשה לאישור ראשי, הוא יוצר את האישור ומשבץ בו מזהה ביטול שהוא בוחר מתוך הטווח.
  3. במקביל, הרשות שמנפיקה את האישורים (CA) ממפה את האישור החדש למזהה הביטול ושולחת את המידע הזה לשירות CRL.
  4. רשות האישורים מנפיקה את אישור המאסטר.

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

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

פרוטוקולי ALTS

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

פרוטוקול לחיצת יד

פרוטוקול לחיצת היד של ALTS הוא פרוטוקול מאומת להחלפת מפתחות שמבוסס על Diffie-Hellman. הוא תומך גם ב-Perfect Forward Secrecy‏ (PFS) וגם בחידוש סשן. תשתית ALTS מוודאת שלכל לקוח ולכל שרת יש אישור עם הזהויות שלהם ומפתח Elliptic Curve Diffie-Hellman ‏ (ECDH) שמשורשר למפתח אימות של שירות חתימה מהימן. ב-ALTS,‏ PFS לא מופעל כברירת מחדל כי המפתחות הסטטיים של ECDH מתעדכנים לעיתים קרובות כדי לחדש את סודיות ההעברה, גם אם לא נעשה שימוש ב-PFS בהעברת לחיצת היד. במהלך לחיצת היד, הלקוח והשרת מנהלים משא ומתן מאובטח על מפתח הצפנה משותף למעבר, ופרוטוקול הרשומה שבו מפתח ההצפנה ישמש להגנה. לדוגמה, הלקוח והשרת יכולים להסכים על מפתח של 128 ביט שישמש להגנה על סשן RPC באמצעות AES-GCM. הלחיצת יד מורכבת מארבע הודעות של Protocol Buffer, שמוצגות באיור 6.

איור 6: הודעות פרוטוקול ללחיצת יד ב-ALTS

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

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

    • מפתח סודי M של פרוטוקול רשומות שמשמש להצפנה ולאימות של הודעות מטען ייעודי.
    • סוד לחידוש R לשימוש בכרטיס לחידוש הפעלה בסשנים עתידיים.
    • סוד האימות א'.

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

  3. השרת שולח הודעה מסוג ServerFinished שמכילה מאמת של לחיצת יד14. הערך של אמצעי האימות הזה מחושב באמצעות קוד אימות הודעות (HMAC) מבוסס-גיבוב (hash), שמחושב על מחרוזת ביטים מוגדרת מראש ועל הסוד A של אמצעי האימות.

  4. אחרי שהלקוח מקבל את ServerInit, הוא מאמת את אישור השרת, מחשב את תוצאת ההחלפה של DH באופן דומה לשרת, וגוזר את אותם סודות M,‏ R ו-A. הלקוח משתמש ב-A שהתקבל כדי לאמת את ערך אמצעי האימות בהודעה ServerFinished שהתקבלה. בשלב הזה בתהליך הלחיצה, הלקוח יכול להתחיל להשתמש ב-M כדי להצפין הודעות. מכיוון שהלקוח יכול עכשיו לשלוח הודעות מוצפנות, אפשר לומר של-ALTS יש פרוטוקול לחיצת יד של RTT אחד.

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

פרוטוקול רישום

בקטע פרוטוקול לחיצת היד מתואר איך אנחנו משתמשים בפרוטוקול לחיצת היד כדי לנהל משא ומתן על סוד של פרוטוקול רשומה. הסוד של הפרוטוקול הזה משמש להצפנה ולאימות של תעבורת הרשת. השכבה של המערך שמבצעת את הפעולות האלה נקראת ALTS Record Protocol‏ (ALTSRP).

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

מסגור

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

  • אורך: ערך לא חתום בן 32 ביט שמציין את אורך המסגרת, בבייטים. שדה האורך הזה (4 בייטים) לא נכלל באורך הכולל של המסגרת.
  • ‫Type: ערך של 32 ביט שמציין את סוג המסגרת, למשל מסגרת נתונים.
  • מטען ייעודי (payload): הנתונים המאומתים שנשלחים, שאפשר גם להצפין אותם.

האורך המקסימלי של פריים הוא 1MB בתוספת 4 בייטים של אורך. בפרוטוקולי RPC הנוכחיים, אנחנו מגבילים עוד יותר את אורך הפריימים, כי פריימים קצרים יותר דורשים פחות זיכרון לשמירה במאגר נתונים זמני. תוקף פוטנציאלי יכול גם לנצל פריימים גדולים יותר במהלך התקפת מניעת שירות (DoS) בניסיון להפיל שרת. בנוסף להגבלת אורך הפריימים, אנחנו גם מגבילים את מספר הפריימים שאפשר להצפין באמצעות אותו סוד M של פרוטוקול הרשומה. המגבלה משתנה בהתאם לתוכנית ההצפנה שמשמשת להצפנה ולפענוח של מטען הייעודי של הפריים. כשמגיעים למגבלה הזו, צריך לסגור את החיבור.

Payload

ב-ALTS, כל פריים מכיל מטען ייעודי (payload) שמוגן מפני שינויים לא מורשים, ואפשר גם להצפין אותו15. נכון למועד הפרסום של המאמר הזה, ב-ALTS יש תמיכה במצבים הבאים:

  • ‫AES-128-GCM, ‏ AES-128-VCM: מצבי AES-GCM ו-AES-VCM, בהתאמה, עם מפתחות של 128 ביט. המצבים האלה מגנים על הסודיות והשלמות של מטען הייעודי (payload) באמצעות סכימות GCM ו-VCM16, בהתאמה.
  • ‫AES-128-GMAC, ‏ AES-128-VMAC: המצבים האלה תומכים בהגנה רק על השלמות באמצעות GMAC ו-VMAC, בהתאמה, לחישוב התג. המטען הייעודי (Payload) מועבר בטקסט לא מוצפן עם תג קריפטוגרפי שמגן על התקינות שלו.

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

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

המשך הסשן

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

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

‫ALTS תומך בשני סוגים של חידוש סשן:

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

    המזההR משויך לזהות ולא לחיבורים ספציפיים. ב-ALTS, כמה לקוחות יכולים להשתמש באותה זהות באותו מרכז נתונים. התכונה הזו מאפשרת ללקוחות להמשיך סשנים עם שרתים שאולי לא תקשרו איתם בעבר, למשל אם מאזן עומסים שולח את הלקוח לשרת אחר שמריץ את אותה אפליקציה.

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

כשממשיכים סשן, הסוד להמשכת הסשן R משמש להפקת סודות חדשים לסשן M′, R′ ו-A′. ‫M′ משמש להצפנה ולאימות של הודעות מטען ייעודי (payload),‏ A′ משמש לאימות של הודעות ServerFinished ו-ClientFinished, ו-R′ מוכל בכרטיס חידוש חדש. חשוב לזכור שאותו סוד לחידוש החיבור R לא משמש יותר מפעם אחת.

השפעות

התקפות התחזות שנובעות מסיכון המפתח

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

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

פרטיות בהודעות ב-Handshake

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

סודיות העברה מושלמת

ב-ALTS יש תמיכה ב-Perfect Forward Secrecy ‏ (PFS), אבל היא לא מופעלת כברירת מחדל. במקום זאת, אנחנו משתמשים ברוטציה תכופה של אישורים כדי ליצור סודיות קדימה ברוב האפליקציות. ב-TLS 1.2 (ובגרסאות קודמות), חידוש הסשן לא מוגן באמצעות PFS. כשמפעילים PFS עם ALTS, ‏ PFS מופעל גם עבור הפעלות שהופסקו והוחזרו.

חידוש ללא הלוך ושוב

‫TLS 1.3 מספק חידוש של סשן שלא דורש זמן אחזור (0-RTT), אבל יש לו מאפייני אבטחה חלשים יותר19. החלטנו לא לכלול אפשרות של 0-RTT ב-ALTS כי ב-Google, חיבורי RPC הם בדרך כלל לטווח ארוך. לכן, קיצור זמן האחזור של הגדרת הערוץ לא היה שווה את המורכבות הנוספת או את האבטחה המופחתת שנדרשות ללחיצות ידיים מסוג 0-RTT.

מקורות מידע נוספים

הערות שוליים

‫1 מיקרו-שירות הוא סגנון ארכיטקטוני שמבנה אפליקציה כאוסף של שירותים בצימוד חלש שמיישמים יכולות עסקיות.
‫2 עומס עבודה של ייצור הוא אפליקציה שמהנדסי Google מתזמנים להפעלה במרכזי הנתונים של Google.
‫3 מידע נוסף על האופן שבו Google מגנה על נתונים במעבר זמין במסמך המידע שלנו בנושא הצפנה במעבר ב-Google Cloud.
‫4 מודל אמון הוא המנגנון שבאמצעותו פרוטוקול אבטחה מזהה, מפיץ ומחליף פרטי כניסה וזהויות.
‫5 יש שירותים שמנוהלים ישירות על ידי מפתחים.
‫6 ‫Borgmaster אחראי לתזמון ולאתחול של עומסי עבודה בייצור של Google. מידע נוסף זמין במאמר ניהול אשכולות בקנה מידה גדול ב-Google באמצעות Borg.
‫7 מידע נוסף על תדירות רוטציית האישורים זמין במאמר בנושא הצפנה במעבר ב-Google Cloud.
8 אם מפתח נפרץ, התוקף יוכל לגלות רק את התנועה שנוצרה במהלך חיי צמד המפתחות הזה.
‫11 ALTSd: דמון שאחראי, בין היתר, על פעולות ALTS ועל יצירת אישורי לחיצת יד.
12 בפועל, לרשות ה-CA יש גישה למפתחות הפרטיים של שירות החתימה, ולכן שתי הישויות הלוגיות הן ישות פיזית אחת.
‫13 Specifically, HKDF-Extract and HKDF-Expand as defined in RFC-5869.
‫14 ההטמעה של פרוטוקול לחיצת היד של ALTS משלבת את ההודעות ServerInit ו-ServerFinished למטען ייעודי (payload) יחיד.
‫15 ההצפנה של המטען הייעודי (payload) מוגדרת כחלק מפרוטוקול הרשומה בתהליך הלחיצת יד.
16 הסכימה של AES-GCM‏ (128 ביט) מבוססת על NIST 800-38D, ו-AES-VCM מוסבר בפירוט במאמר AES-VCM, An AES-GCM Construction Using an Integer-Based Universal Hash Function.
‫17 חידוש הסשן כולל פעולות סימטריות קלות רק אם לא מעורבים פרמטרים זמניים.