התוכן הזה עודכן לאחרונה במאי 2024, והוא מציג את המצב הקיים במועד כתיבתו. מדיניות האבטחה ומערכות האבטחה של Google עשויות להשתנות בעתיד, מכיוון שאנחנו כל הזמן פועלים לשיפור ההגנה על הלקוחות שלנו.
כאן מתוארת הגישה של Google לאימות (attestation) מכונות במרכזי נתונים. הארכיטקטורה המתוארת במסמך הזה מיועדת לשילוב עם תקנים פתוחים, כמו Trusted Platform Module (TPM), Security Protocol and Data Model (SPDM)ו-Redfish. למידע על הטמעה של הפניות ותקנים חדשים שהוצעו על ידי Google וקשורים לאימות המכונות במרכז הנתונים, תוכלו לעיין בפרויקט Platform Integrity (PINT) ב-GitHub. המסמך מיועד למנהלי אבטחה, לאדריכלי אבטחה ולמבקרים.
סקירה כללית
Google מתכננת ופורסת יותר ויותר מכונות מופרדות של מרכזי נתונים. במקום Root of Trust (RoT) יחיד, מכונות רבות מכילות RoT נפרדים, כולל למדידה (RTM), לאחסון, לעדכון ולשחזור. כל RTM מופעל עבור קטע משנה במכונה כולה. לדוגמה, למכונה יכולים להיות RTM אחד שבאמצעותו נמדד ומאומת מה שהופעל במעבד (CPU) הראשי, ו-RTM אחר שבאמצעותו נמדד ומאומת מה שהופעל ב-SmartNIC שמחובר ליחידת קיבולת (Slot) מסוג PCIe. בתרשים הבא מוצגת מכונה לדוגמה.
המורכבות של מכונה שמכילה הרבה RTM מתווספת לקנה המידה העצום ולציפיות הגדולות גם ככה בקשר למכונות במרכז הנתונים, ולסיבוכים הרבים שעלולים להתרחש בעקבות טעויות אנוש ותקלות בחומרה או בתוכנה. בקיצור, לא פשוט לשמור על תקינות הקושחה של ה-Fleet.
המערכת המתוארת במסמך הזה נועדה לייעל את האימות מרחוק של מכונות מופרדות. אפשר להרחיב את תשתית האימות הזו כדי שתתרגל לפעול עבור מכונות מורכבות ביותר שמופיעות במרכז הנתונים.
אנחנו משתפים זאת כדי להציג את נקודת המבט שלנו לגבי ביצוע של אימות מכונות מופרדות בקנה המידה הנדרש. דרך שיתוף פעולה עם שותפים מהענף ותרומות לגופים כמו Distributed Management Task Force (DMTF), Trusted Computing Group (TCG) ו-Open Compute Project (OCP), אנחנו מתכוונים להמשיך לתמוך בחדשנות בנושאי אבטחה בתחום הזה.
מאפיינים מומלצים של RTM
בקטע הזה מתוארים כמה מאפיינים שמומלצים ל-RTM.
אינטגרציה של חומרת RTM
כשמעבד מותאם ל-RTM, ה-RTM אמור לתעד מדידות בקוד הראשון שניתן לשינוי ומריצים באותו מעבד. המדידות של הקודים הבאים שניתנים לשינוי אמורים להיות מתועדים ומדווחים ל-Root of Trust לפני הרצת הקוד. הסידור הזה יוצר רשת של אתחול מדוד שמאפשרת אימות חזק במצב האבטחה הקריטי של המעבד.
אימות הזהות של החומרה והקושחה של RTM
לכל RTM צריך להיות זוג מפתחות לחתימה כדי להנפיק אימותים לתיקוף חיצוני. רשת האישורים של זוג המפתחות אמורה לכלול ראיות קריפטוגרפיות לזהות החומרה ולזהות הקושחה הייחודיות של ה-RTM עבור כל קוד שניתן לשינוי ומופעל בתוך ה-RTM. רשת האישורים צריכה לעבור תהליך רוט (Root) אצל יצרן ה-RTM. כך המכונות יכולות להתאושש מנקודות חולשה קריטיות של קושחת RTM.
המפרט של Device Identifier Composition Engine (DICE) הוא למעשה מיסוד התבנית שמשמשת אותנו בפתרון לאימות. יצרן ה-RTM מאשר זוג מפתחות ייחודי למכשיר, שמאשר זוג מפתחות חלופי שנועד ספציפית לתמונת הקושחה ולזהות החומרה של ה-RTM. רשת האישורים של המפתח החלופי מכילה מדידה של קושחת ה-RTM ואת המספר הסידורי של ה-RTM. המאמתים יכולים להיות סמוכים ובטוחים שהנתונים שנחתמו על ידי מפתח חלופי מסוים הונפקו מ-RTM, המתואר על ידי המדידות של החומרה הקריפטוגרפית וזהות הקושחה. המדידות האלה מוטמעות בתוך רשת האישורים של המפתח החלופי.
פעולות אימות מרחוק
סכימת האימות נועדה לוודא שמשימות ונתוני משתמשים מונפקים רק למכונות שמפעילות את סטאק ההפעלה הייעודי, ועדיין מאפשרות לאוטומציה של תחזוקת ה-Fleet להתרחש בקנה המידה שנדרש לתיקון בעיות. השירות של מתזמן המשימות, שמתארח בענן הפנימי שלנו, יכול לאתגר את אוסף ה-RTM בתוך המכונה ולהשוות בין המדידות המאומתות שהונפקו לבין מדיניות שייחודית לאותה מכונה. המתזמן מנפיק משימות ונתוני משתמשים למכונות רק אם המדידות המאומתות עומדות בדרישות המדיניות של המכונה.
אימות מרחוק כולל את שתי הפעולות הבאות:
יצירת מדיניות אימות שמתרחשת כשחל שינוי בתוכנה או בקושחה הייעודיות של המכונה.
וידוא האימות בנקודות ספציפיות בתהליכי הניהול של המכונות. אחת מהנקודות נמצאת ממש לפני תזמון העבודה במכונה. המכונה מקבלת גישה למשימות ולנתוני המשתמשים רק אחרי שמוודאים את האימות.
מדיניות האימות
Google משתמשת במסמך חתום שמתאים לקריאה למחשבים, שנקראמדיניות, כדי לתאר את החומרה והתוכנה שצפויות לפעול בתוך מכונה. אפשר לאמת את המדיניות הזו באמצעות אוסף ה-RTM של המכונה. הפרטים הבאים של כל RTM מופיעים במדיניות:
- אישור בסיס לזהות: אישור מהימן שיכול לתקף את האימותים שהונפקו על ידי ה-RTM.
- זהות החומרה: זהות ייחודית וגלובלית ל-RTM.
- זהות הקושחה: זהות שמתארת את הגרסה הצפויה שה-RTM אמור להפעיל.
- הציפיות למדידה לכל שלב הפעלה שמדווח על ידי ה-RTM.
- מזהה של ה-RTM שדומה לשם של משאב Redfish.
- מזהה שמקשר את ה-RTM למיקום הפיזי שלו בתוך מכונה. המזהה הזה דומה לשם של משאב Redfish, ומערכות אוטומטיות לתיקון מכונות משתמשות בו.
בנוסף, המדיניות מכילה גם מספר סידורי ייחודי וגלובלי לביטול, שעוזר למנוע החזרה לא מאושרת של המדיניות למצב קודם. בתרשים הבא מוצגת דוגמה למדיניות.
בתרשים מוצגים הפריטים הבאים מהמדיניות:
- החתימה שמספקת אימות למדיניות.
- המספר הסידורי של הביטול, שעוזר לרענן את המדיניות כדי למנוע החזרה למצב הקודם.
- הציפיות של ה-RTM שבעזרתן אפשר להכין רשימה של כל RTM במכונה.
הפריטים האלה מוסברים בהרחבה בקטעים הבאים.
הרכבת המדיניות
כשמרכיבים את החומרה של המכונה או מתקנים אותה, נוצר מודל של חומרה שמגדיר את ה-RTM הצפויים באותה מכונה. מישור הבקרה שלנו עוזר לוודא שהמידע הזה יישאר עדכני לגבי כל האירועים, כמו תיקונים שכוללים החלפת חלקים או שדרוגי חומרה.
בנוסף, מישור הבקרה שומר על ציפיות לגבי התוכנה שתותקן במחשב, יחד עם ציפיות לגבי מדידת תוכנות באמצעות RTM מסוימים. מישור הבקרה משתמש בציפיות האלה יחד עם מודל החומרה, כדי ליצור מדיניות אימות חתומה וניתנת לביטול שמתארת את המצב הצפוי של המכונה.
לאחר מכן, המדיניות החתומה נכתבת באחסון המתמיד של המכונה שמופיעה במדיניות. הגישה הזו עוזרת לצמצם את מספר יחסי התלות של רשתות ושירותים שנדרשים לאימות המכונה מרחוק. במקום להריץ שאילתה במסד נתונים לגבי המדיניות, המאמתים יכולים לאחזר את המדיניות מהמכונה עצמה. זהו מאפיין חשוב של התכנון, כי מתזמני המשימות צריכים לעמוד ברמות שירות קפדניות ומוכרחים להיות עם זמינות גבוהה. כדי לצמצם את הסיכון להפסקות זמניות בשירות, רצוי למזער את התלות של רשתות המכונות בשירותים אחרים. בתרשים הבא מוצג רצף האירועים.
בתרשים מתוארים השלבים שמישור הבקרה משלים בתהליך הרכבת המדיניות:
- הפקת מדיניות האימות מההקצאה של חבילת התוכנה וממודל החומרה של המכונה.
- חתימת המדיניות.
- שמירת המדיניות במכונה של מרכז הנתונים.
ביטול המדיניות
הכוונה (intent) של החומרה והתוכנה של מכונה מסוימת משתנה לאורך זמן. כשמשנים את הכוונה, צריך לבטל את המדיניות הישנה. כל מדיניות אימות חתומה כוללת מספר סידורי ייחודי לביטול. המאמתים מקבלים את המפתח הציבורי שמתאים לאימות המדיניות החתומה ואת רשימת האישורים שבוטלו כדי לוודא שהמדיניות עדיין תקפה.
שליחת שאילתות באופן אינטראקטיבי לשרת מפתחות או למסד נתונים לצורך ביטול משפיעה על הזמינות של מתזמן המשימות. במקום זאת, Google משתמשת במודל אסינכרוני. קבוצת המפתחות הציבוריים שמשמשים לאימות מדיניות האימות החתומה נשלחת כחלק מתמונת מערכת ההפעלה הבסיסית של כל מכונה. רשימת האישורים שבוטלו נשלחת באופן אסינכרוני באמצעות אותה מערכת מרכזית לפריסת ביטול שבה משתמשת Google לסוגים אחרים של פרטי כניסה. המערכת הזו מיועדת לביצוע פעולות מהימנות בתנאים רגילים, עם יכולת לבצע שליחות חירום מהירות בתנאים של תגובה לאירועים.
באמצעות אימות מפתחות ציבוריים וקבצים עם רשימות האישורים שבוטלו שמאוחסנים באופן מקומי במחשב של המאמת, המאמתים יכולים לבצע תיקוף להצהרות אימות ממכונות מרוחקות בלי להיעזר בשירותים חיצוניים בנתיב הקריטי.
אחזור של מדיניות האימות ותיקוף המדידות
התהליך של אימות מכונה מרחוק כולל את השלבים הבאים:
- אחזור ותיקוף של מדיניות האימות.
- קבלת מדידות מאומתות מה-RTM של המכונה.
- בדיקת המדידות המאומתות והשוואתן למדיניות.
בתרשימים ובקטעים הבאים השלבים האלה מוסברים בהרחבה.
אחזור ותיקוף של מדיניות האימות
המאמת מרחוק מאחזר את מדיניות האימות החתומה של המכונה. כפי שצוין בחלק של הרכבת המדיניות, מטעמי זמינות, המדיניות מאוחסנת כמסמך חתום במכונת היעד.
כדי לוודא שהמדיניות שהוחזרה היא אותנטית, המאמת מרחוק נעזר בעותק המקומי של רשימת האישורים שבוטלו. כך אפשר לוודא שהמדיניות שאוחזרה חתומה באופן קריפטוגרפי על ידי ישות מהימנה, ושהמדיניות לא בוטלה.
קבלת מדידות מאומתות
המאמת מרחוק מאתגר את המכונה ומבקש מדידות מכל RTM. המאמת מוודא שהכל מעודכן באמצעות הכנסת צפנים קריפטוגרפיים חד-פעמיים (nonces) לבקשות. ישות במכונה, כמו baseboard management controller (BMC), מנתבת כל בקשה ל-RTM המתאים, אוספת את התשובות החתומות ושולחת אותן בחזרה למאמת מרחוק. מנקודת מבט של אימות, לישות במכונה אין הרשאה, כי היא משמשת רק לתעבורת המדידות החתומות של ה-RTM.
כדי לאמת את המדידות, Google משתמשת בממשקי API פנימיים. כמו כן, אנחנו מספקים שיפורים ל-Redfish כדי לאפשר למאמתים שלא במכונה לאתגר BMC במדידות של RTM באמצעות SPDM. ניתוב פנימי של מכונה מתבצע באמצעות פרוטוקולים וערוצים ספציפיים להטמעה, למשל:
- Redfish over subnet
- Intelligent Platform Management Interface (IPMI)
- Management Component Transport Protocol (MCTP) על גבי i2c/i3c
- PCIe
- Serial Peripheral Interface (SPI)
- USB
בדיקת המדידות המאומתות
המאמת מרחוק של Google מבצע תיקוף לחתימות שמונפקות באמצעות כל RTM, כדי לוודא שהן עוברות תהליך רוט (Root) בחזרה לזהות ה-RTM שכלולה במדיניות האימות של המכונה. לכל זהויות החומרה והקושחה שנמצאות ברשת האישורים של ה-RTM מתבצע תיקוף בהתאם למדיניות, וכך מוודאים שכל RTM הוא הנכון ומפעיל את הקושחה הנכונה. כדי לשמור על עדכניות, בודקים את הצופן הקריפטוגרפי החתום והחד-פעמי (nonce). לבסוף, המדידות המאומתות נבדקות כדי לוודא שהן תואמות לציפיות של מדיניות המכשיר.
תגובה לתוצאות האימות מרחוק
אחרי שהאימות הושלם, משתמשים בתוצאות כדי לקבוע מה לעשות עם המכונה המאומתת. כפי שמוצג בתרשים, יש שתי תוצאות אפשריות: האימות מצליח ומנפיקים למכונה נתוני משתמש ופרטי כניסה של המשימה, או שהאימות נכשל ונשלחות התראות לתשתית התיקונים.
בקטעים הבאים מוסבר בהרחבה על התהליכים האלה.
האימות נכשל
אם האימות של המכונה נכשל, Google לא משתמשת בה כדי לבצע משימות של לקוחות. במקום זאת, נשלחת התראה לתשתית התיקונים בניסיון להחליף תמונת דיסק במכונה באופן אוטומטי. למרות שכשלים באימות (attestation) עשויים לקרות בגלל כוונה זדונית, רוב הכשלים באימות נובעים מבאגים בהשקות של התוכנות. לכן, כשיש השקות שגורמות לעלייה בכשלים באימות (attestation), הן מופסקות באופן אוטומטי כדי למנוע כשלים נוספים במכונות. במקרה כזה, נשלחת התראה למהנדסי SRE. אם החלפת תמונת הדיסק האוטומטית לא פותרת את הבעיה במכונה, מחזירים את ההשקה למצב הקודם או משיקים תוכנה מתוקנת. המכונה תחזור לשמש למשימות של הלקוחות רק אחרי שתעבור שוב אימות (attestation) מרחוק.
האימות הצליח
אם האימות מרחוק של המכונה הצליח, Google משתמשת בה כדי לבצע משימות ייצור, כמו מכונות וירטואליות ללקוחות Google Cloud או עיבוד תמונות ב-Google Photos. Google דורשת שכל הפעולות המשמעותיות של המשימות שכוללות שירותי רשת יהיו כפופות לפרטי הכניסה של משימות LOAS לטווח קצר. פרטי הכניסה האלה מוענקים באמצעות חיבור מאובטח אחרי הצלחה באתגר האימות, והם נותנים את ההרשאות הנדרשות למשימה. מידע נוסף על פרטי הכניסה האלה זמין במאמר אבטחת שכבת התעבורה של אפליקציה (ALTS).
אימות התוכנה יעיל רק אם התשתית שממנה נוצרה התוכנה יעילה. כדי לוודא שהארטיפקטים שנוצרים בתהליך משקפים במדויק את כוונתנו, השקענו רבות בתקינות של צינור עיבוד נתוני ה-build. במאמר תקינות שרשרת האספקה של תוכנות תוכלו לקרוא בהרחבה על התקן שהוצע על ידי Google לטיפול בתקינות ובאותנטיות של שרשרת האספקה של תוכנות.
המאמרים הבאים
איך אפשר להיעזר ב-BeyondProd כדי ליצור חיבורים מאובטחים למכונות במרכז הנתונים של Google.