סקירה כללית על האבטחה של Confidential Space

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

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

הרכיבים במערכת Confidential Space

ב-Confidential Space נעשה שימוש בסביבת מחשוב אמינה (TEE) שמאפשרת לחשוף סודות רק לעומסי עבודה מורשים. תהליך אימות (attestation) ותמונת דיסק של מערכת הפעלה מוקשחת עוזרים להגן על עומס העבודה ועל הנתונים ממפעיל לא מהימן שעומס העבודה מעבד.

מערכת Confidential Space מורכבת משלושה רכיבי ליבה:

  • עומס עבודה (workload): תמונה בקונטיינרים עם מערכת הפעלה מוקשחת שפועלת בסביבת TEE מבוססת-ענן. Confidential Computing משמש אתכם כסביבת ה-TEE שמאפשרת בידוד של החומרה ויכולות של אימות מרחוק.
  • ‫Google Cloud Attestation: ספק אסימונים של OpenID Connect‏ (OIDC). השירות הזה משמש לטיפול בבקשות האימות בסביבת TEE ולהפצת אסימונים של אימות. האסימונים מכילים מאפייני זיהוי של עומס העבודה.
  • משאב מוגן: משאב מנוהל בענן, כמו מפתח של Cloud Key Management Service או קטגוריה של Cloud Storage. המשאב מוגן באמצעות מדיניות הרשאות שמאפשרת גישה לאסימוני זהות מאוחדים ומורשים. בשלב ביניים, באמצעות מאגרי Workload Identity אסימוני ה-OIDC נהפכים לאסימוני זהות מאוחדים שאפשר להשתמש בהם ב-IAM.

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

במערכת Confidential Space מעורבים שלושה גורמים:

  • המחבר של עומס העבודה, שיוצר תמונה בקונטיינרים שכוללת אפליקציה עם גישה למשאבים המוגנים. למחבר אין גישה לנתונים ולתוצאות. בנוסף, למחבר אין שליטה על הגישה לנתונים ולתוצאות.
  • המפעיל של עומס העבודה, שמפעיל אותו ב Google Cloud פרויקט. למפעיל יש בדרך כלל הרשאות אדמין מלאות בפרויקט. המפעיל יכול לנהל Google Cloud משאבים כמו כללי רשת, דיסקים ומכונות של Compute Engine, והמפעיל יכול להשתמש בכל Google Cloud API שפועל בהם. למפעיל אין גישה לנתונים ולתוצאות, והוא לא יכול להשפיע על הקוד וסביבת הביצוע או לשנות אותם. בנוסף, למפעיל אין שליטה על הגישה לנתונים ולתוצאות.
  • בעלי המשאב (או שותפי הנתונים), שהם הבעלים של המשאב המוגן. בעלי המשאב יכול לגשת לנתונים שלו, להגדיר להם הרשאות ולהציג את התוצאות. הוא לא יכול לגשת לנתונים של בעלי משאבים אחרים ולשנות את הקוד בעצמו.

ב-Confidential Space קיים מודל אמון שלפיו המחבר של עומס העבודה, המפעיל של עומס העבודה ובעלי המשאב הם צדדים נפרדים שלא מתקיים אמון הדדי ביניהם.

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

המערכת והרכיבים של Confidential Space.

דוגמאות לעיבוד נתונים מאובטח

בעזרת Confidential Space תוכלו לשמור על פרטיות המשתמשים בזמן שיתוף הנתונים. בטבלה הבאה מתוארים שלושה תרחישים לדוגמה:

שם התרחיש דוגמה לתרחיש
מודל הצפנה פונקציונלית במודל הצפנה פונקציונלית, עינת רוצה לשתף את התוצאה של הנתונים הסודיים שלה עם ירון, בלי לחשוף את כל מערך הנתונים. עינת מצפינה את מערך הנתונים שלה ומגינה על המפתח להצפנת הנתונים (DEK) ב-Cloud KMS בפרויקט שלה. עינת כותבת תוכנית שמטמיעה את עומס העבודה, ומשתפת את הקובץ הבינארי עם ירון. עינת מגדירה ל-KMS לתת ל-DEK גישה לתוכנית. עומס העבודה פועל ב-Confidential Space של ירון, מפענח ומעבד את מערך הנתונים של עינת, וכותב את התוצאה ב-Cloud Storage של ירון.
חישוב מרובה צדדים בחישוב מרובה צדדים, עינת וירון רוצים לשתף ביניהם את התוצאה, תוך שמירה על הסודיות של מערכי הנתונים של הקלט. בדומה למודל ההצפנה הפונקציונלית, עינת וירון מצפינים את מערכי הנתונים שלהם ומגינים על ה-DEKs במכונות של Cloud KMS בפרויקטים שלהם. הם כותבים יחד תוכנית שקובעת את התוצאות, ומריצים אותה ב-Confidential Space. עינת וירון מגדירים ל-KMS לתת ל-DEKs גישה לתוכנית. בתוכנית מתבצעים קריאה ועיבוד של שני מערכי הנתונים, והתוצאה נכתבת בקטגוריה משותפת של Cloud Storage.
שיתוף מפתחות הרעיון של שיתוף מפתחות עומד במרכזה של תוכנית מורכבת יותר. שיתוף מפתחות הוא מפתח פרטי שמפוצל בין עינת, ירון ובעלים אחרים, כך ששיתופים בודדים לא נותנים גישה למערך הנתונים המוצפן. לפי התוכנית הזו, האמון מתפצל בין מספר בעלים. המפתח הפרטי מורכב רק בסביבת TEE מוגבלת, על ידי עומס עבודה מורשה.

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

הגנה על השלמות והסודיות של עומס עבודה (workload)

כדי להגן על עומס העבודה מפני מפעיל לא מהימן, מתבצעת הטמעה של אמצעי האבטחה הבאים באמצעות Confidential Space:

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

תהליך האימות (Attestation)

תהליך האימות (attestation) מבוסס על אתחול מדוד של מכונה וירטואלית מוגנת ועל המדידות בסביבת זמן ריצה מורחבת. בתהליך הזה מתבצעות מדידות של רצף אתחול ברישום מוגן ורחב-היקף בלבד במכשיר virtual Trusted Platform Module ‏(vTPM).

המדידות מתייחסות לרכיבי אתחול מוקדם, לליבה הנטענת ולתמונת הקונטיינר. בנוסף, הם כוללים מאפייני סביבה (environment properties) כמו דגל שמעיד שהמכונה היא Confidential VM. המדידות האלה נחתמות (או מקודדות) ב-vTPM באמצעות מפתח אימות מהימן שאושר על ידי Google Cloud Attestation.

בתרשים הבא מוצגים הרכיבים של מערכת Confidential Space ואופן המעורבות של כל רכיב בתהליך האימות.

הגורמים המעורבים והרכיבים של המערכת בתהליך האימות.

תהליך האימות תלוי ברכיבים הבאים:

  • קושחה לאורחים: רכיב שלא ניתן לשינוי והוא חלק מהימן ב-Google Cloud.
  • תמונה מאומתת של Confidential Space: תמונה מוקשחת שמבוססת על מערכת הפעלה שמותאמת לקונטיינרים, שנקראת מדיסק האתחול המצורף.
  • רכיבי אתחול מוקדם: תוכנות אתחול וליבות שמקיימות אינטראקציה עם ה-vTPM כדי למדוד את רכיבי האתחול ל-Platform Configuration Register‏ (PCR).

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

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

  • Google Cloud Attestation: שירות שמוודא את הקידוד, מפעיל מחדש את יומן האירועים, מנפיק את אסימון ה-OIDC ומחזיר את האסימון עם המאפיינים של מדיניות הגישה לעומסי עבודה.

תמונה מוקשחת

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

  • מחיצות דיסק מוצפנות עם הגנה על השלמות: התמונה של Confidential Space כוללת את המחיצות הבאות:
    • מחיצת root-fs, ומחיצת OEM (יצרן ציוד מקורי) שכוללת את הקובץ הבינארי של מרכז האפליקציות. מחיצות אלה לא ניתנות לשינוי ומוגנות על ידי dm-verity.
    • מחיצה זמנית הניתנת לכתיבה, שמאחסנת את הקובץ הבינארי של עומס העבודה שהורדתם. המחיצה מוצפנת על ידי dm-crypt והשלמות שלה מוגנת.
    • מחיצת tmp-fs שממופה ל-RAM. בסביבת TEE של Confidential VM, הזיכרון של המכונה הווירטואלית מוצפן. בנוסף, מערכת swap-fs מושבתת, וכך מונעים ממערכת הפעלה שהוגדרה באופן שגוי לאחסן נתונים בדיסק.
  • חיבורים מוצפנים ומאומתים לרשת: במרכז האפליקציות נעשה שימוש ב-TLS (אבטחת שכבת התעבורה) כדי לאמת את Google Cloud Attestation ולהגן על קישורי התקשורת שלו.
  • מדידות אתחול שונות: מדידות אלה כוללות ארגומנטים של שורת הפקודה בליבה, הגדרות dm-verity עבור root-fs ואת הקובץ הבינארי של עומס העבודה.

  • השבתה של גישה מרחוק וכלים ספציפיים לענן: הכלים האלה כוללים את sshd ואת OS Login.

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

מודל של איומים ומיטיגציות

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

ההתקפות הבאות לא מופיעות במסמך זה:

  • התקפות על שרשרת האספקה של תוכנות, כולל הקושחה Unified Extensible Firmware Interface‏ (UEFI) של אורחים, תוכנת אתחול התמונות והליבה של Confidential Space, סביבת זמן הריצה של הקונטיינר ויחסי תלות של צד שלישי בעומס העבודה. ההנחה של שותפי הנתונים היא שבעלי המשאבים סקרו ובדקו את תמונת הקונטיינר לפני שיתוף המשאבים עם מדיניות הרשאות.
  • התקפות על Google Cloud, למשל בריחות ממכונות וירטואליות.

התקפות פוטנציאליות

מטרת Confidential Space היא להגן מפני שלוש התקפות אפשריות:

  • מפעיל עומס עבודה זדוני: מפעיל שעלול לשנות את תוכן הדיסק, ליירט חיבורים לרשת ולנסות לפגוע בסביבת TEE בזמן הריצה. מפעיל זדוני עלול להרחיב את שטח ההתקפה ולהגביל את סביבת זמן הריצה. לדוגמה, מפעיל זדוני עלול להוסיף מסוף טורי כדי להחדיר וקטורי תקיפה חדשים. הוא גם עלול להציב אילוצים על משאבים, כמו הגבלת גודל הזיכרון של האורח, שינוי המקום בכונן ושינוי כללי חומת האש. האילוצים האלה עלולים לגרום לשגיאות קלט/פלט (I/O), וכתוצאה מכך לתרחישי שגיאות שלא נבדקו כהלכה.
  • לקוח אימות (attestation) זדוני: תוקף שמתחבר ל-Google Cloud Attestation ושולח הודעות ביומן האירועים שהן שגויות אך חתומות.
  • בעל משאבים זדוני: לבעל משאבים זדוני יש שליטה מלאה על מערך הנתונים המוצפן שנצרך בעומס העבודה. תוקף כזה עלול להציג קלט בצורה שגויה או נתונים מסולפים, ולנסות להפעיל נקודות חולשה בניתוח עומסי העבודה או לנסות לעקוף את אמצעי הבקרה על הפרטיות.

שטחי התקפה

בטבלה הבאה מתוארים שטחי ההתקפה שזמינים לתוקפים.

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

כל מה שנקרא מהדיסק נמצא בשליטת התוקף.

בשירותים כמו דיסקים לאחסון מתמיד (persistent disks) עם מספר בעלי הרשאות כתיבה וצירופי דיסקים דינמיים, התוקפים עלולים לשנות את תוכן הדיסק באופן דינמי ולפי רצונם.
מפעיל של עומס עבודה סביבת TEE, עומס עבודה כתיבה בדיסק כל מה שנכתב בדיסק גלוי לתוקפים. למידע נוסף על קובצי snapshot של דיסקים ועל יכולות ייבוא.
מפעיל של עומס עבודה סביבת TEE, עומס עבודה שרת מטא-נתונים מאפייני המכונות שנקראו משרת המטא-נתונים נמצאים בשליטת התוקפים, כולל סקריפט לטעינה בזמן ההפעלה ומשתני סביבה.
מפעיל של עומס עבודה סביבת TEE, עומס עבודה רשת אפשר ליירט חיבורי רשת חיצוניים למאגר התמונות או לשירות האימות של Google Cloud. ההתקפה הזו מתבצעת באמצעות VPC פרטי עם מכונה של Cloud Router הפונה לציבור.
לקוח אימות (attestation) Google Cloud Attestation יומן אירועים והודעות אימות לשירות Google Cloud Attestation יש לוגיקה מורכבת ומרובת הצפנות, שקשה לכתוב באופן הגנתי.
הבעלים של מקור המידע עומס עבודה מערך נתונים מוצפן

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

Google Cloud תשתית

Google Cloud כולל את hypervisor של Compute Engine, את vTPM ל-Confidential VM, את קושחת UEFI של אורחים ואת מופע Google Cloud Attestation המתארח. חומרי מפתח רגישים, כמו מפתחות חתימה של OIDC ו-vTPM, תוכננו להיות מוגנים באופן מאובטח.

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

איומים ומיטיגציות

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

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

בטבלאות הבאות מתוארים האיומים והמיטיגציות:

התקפות על תהליך האתחול המדוד

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

איום מיטיגציה הטמעת המיטיגציה

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

אם הפעולה מצליחה, תוקף עלול להפעיל מדידות שרירותיות ולעקוף את האימות מרחוק.

אפשר לצמצם את האיום באמצעות מישור הבקרה של Google Cloud .

ב-Confidential Space נוספים מכשיר vTPM וקושחת UEFI מעודכנת. כמו כן, Confidential Space מפעיל אתחול מדוד, שלא ניתן להשבתה.

 בתוך Google Cloud התשתית

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

אם הפעולה מצליחה, תוקף עלול להפעיל מדידות שרירותיות ולעקוף את האימות מרחוק.

 אפשר לצמצם את האיום באמצעות hypervisor. בהפעלה מחדש של האורח, באמצעות hypervisor נטען עותק נקי של קושחת ה-UEFI בזיכרון של האורח. השינויים הקודמים בזיכרון האורח מתבטלים. בנוסף, הפעלה מחדש של האורח היא האירוע היחיד שמאפס את ה-vTPM. ב- Google Cloud ועל ידי הפעלת Confidential Computing
תוקף משנה קובצי תצורה לא מדודים, וזה משפיע לרעה על הביצוע של תוכניות.

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

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

בבדיקת האבטחה נמצא שלא חסרות מדידות בתהליך האימות.

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

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

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

עם זאת, במערכת Confidential Space, ההתקפה הזו לא מצליחה לעבור אימות כי המדידות של grub.cfg לא תואמות לתצורה הצפויה.

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

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

בתמונה של Confidential Space
תוקף משנה את הקבצים הבינאריים של האתחול המוקדם בדיסק אחרי הקריאה והמדידה, ולפני הקריאה והביצוע (דיסק TOCTOU).

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

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

בדיקת האבטחה של התמונה של Confidential Space לא זיהתה בעיות מסוג TOCTOU ברכיבי האתחול המוקדם, כמו UEFI,‏ Shim ו-GNU GRUB.

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

אפשר לצמצם את האיום באמצעות מערכת קבצים ברמה הבסיסית (root) עם הגנה על השלמות.

הערך Root-fs בתמונה של Confidential Space מוגן על ידי dm-verity. התצורה (root-hash) מועברת בארגומנט של פקודה בליבה, ולאחר מכן נמדדת ומאומתת על ידי Google Cloud Attestation.

 בתמונה של Confidential Space

התקפות על מפעיל הקונטיינרים

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

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

החיבור למאגר התמונות מוגן באמצעות חיבור TLS מוצפן ומאומת.

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

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

 בתמונה של Confidential Space
תוקף משנה את התמונה של עומס העבודה בדיסק אחרי הורדה ומדידה שלה.

אפשר לצמצם את האיום באמצעות מחיצה מוצפנת ניתנת לכתיבה שהשלמות שלה מוגנת.

התמונה של עומס העבודה והנתונים הזמניים שלה מוגנים על ידי dm-crypt באמצעות מפתחות זמניים לכל הפעלה.

תהליך הצפנת הדיסק של dm-crypt מאפשר התקפות רולבק, שבהן תוקף מחליף את תוכן הדיסק במידע מוצפן (ciphertext) ובתגים שהוצגו בעבר. ההתקפות האלה מורכבות מאוד בהגדרות של Confidential Space.

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

התקפות על Google Cloud Attestation

בטבלה הבאה מתוארים איומים פוטנציאליים ואסטרטגיות מיטיגציה שקשורות ל-Google Cloud Attestation.

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

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

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

תוקף לא יכול להתחזות ללקוח חוקי כי זהות הלקוח מובטחת על ידי פרוטוקול האימות.

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

האיום הזה עלול להתרחש כי יומן האירועים של המדידות עובר תהליך סריאליזציה ונשלח ל-Google Cloud Attestation, שבו הוא מנותח ומעובד.

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

לדוגמה, אם בשדה cmdline יש רשימה של ארגומנטים המופרדים בפסיקים, ייתכן שמחרוזת כמו a=1, b=2 c='3,d=e' (שימו לב ל-,d במחרוזת המשנה של הערך) תנותח באופן שונה על ידי הליבה ועל ידי השירות.

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

 בתמונה של Confidential Space
תוקף משתמש בכל משאבי השירות, מה שגורם להפלת השירות בגלל התקפה מסוג מניעת שירות (DoS). השירות משתבש גם למשתמשים אחרים ב-Confidential Space.

אפשר לצמצם את סיכון המהימנות הזה באמצעות הפצת שירות גמיש, שניתן לבצע בקלות רפליקציה וסילומיות אופקית (scale out) שלו לפי הצורך.

הקוד מונע מיצוי משאבים על ידי לקוחות זדוניים.

 בעומס העבודה

התקפות על עומסי עבודה (workloads)

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

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

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

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

 בתמונה של Confidential Space
תוקף קורא סודות בסביבת זמן ריצה ממסוף טורי. אפשר לצמצם את האיום באמצעות התמונה של Confidential Space, כי פרטי הכניסה והאסימונים לעולם לא מודפסים במסוף הטורי. בנוסף, אפשרות הרישום ביומן בענן מושבתת. בתמונה של Confidential Space
תוקף מעדכן מפתחות SSH מורשים באמצעות חבילת OSLogin, ואז מתחבר למכונה שפועלת. אפשר לצמצם את האיום באמצעות התמונה של Confidential Space, כי בוצעה אנונימיזציה לשירותי ברירת המחדל של systemd, כולל sshd. בתמונה של Confidential Space
תוקף מעדכן סקריפטים לטעינה בזמן ההפעלה בשרת המטא-נתונים, שנטענים באופן אוטומטי על ידי הסוכן האורח. אפשר לצמצם את האיום באמצעות התמונה של Confidential Space, כי חבילת הסוכן האורח מושבתת. בתמונה של Confidential Space
תוקף דוחף חבילות לא רצויות למכונה הווירטואלית באמצעות סוכן ה-OS config. אפשר לצמצם את האיום באמצעות התמונה של Confidential Space, כי סוכן ה-OS config מושבת. בתמונה של Confidential Space
תוקף מעביר מערך נתונים מוצפן ולא תקין לעומס העבודה. אפשר לצמצם את האיום באמצעות קוד ניתוח הגנתי בעומס העבודה. בעומס העבודה
תוקף מעביר מערך נתונים מסולף או מושחת לעומס העבודה, ומנסה לחשוף מידע על מערכי הנתונים מגורמים אחרים. אפשר לצמצם את האיום באמצעות הטמעת אמצעי בקרה על פרטיות דיפרנציאלית בעומס העבודה. בעומס העבודה

בדיקות אבטחה

‏Google ביצעה בדיקת אבטחה מקיפה של Confidential Space. תהליך הבדיקה כלל את הבדיקות והביקורות הבאות:

  • בדיקות אינטגרציה מקצה לקצה של זרימה שלילית

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

  • בדיקה ידנית של תהליך האתחול המדוד

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

  • בדיקה ידנית של תהליך ה-build עבור התמונה של Confidential Space והלוגיקה של מרכז האפליקציות:

    בבדיקה הזו התמקדנו בהסרת חבילות ובצמצום שטחי התקפה.

  • בדיקה ידנית של Google Cloud Attestation

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

  • בדיקה של הקריפטוגרפיה על ידי מומחים לאבטחת סייבר

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

  • בדיקת הגדרות פרטיוּת על ידי מומחי פרטיות

    בבדיקה הזו התמקדנו באמצעי הבקרה על פרטיות דיפרנציאלית בעומסי העבודה ש-Google יצרה

  • בדיקות fuzz מתמשכות

    בבדיקות האלה עסקנו ברכיבי אבטחה קריטיים, כמו vTPM ו-Google Cloud Attestation.

בדיקות חדירה למערכת בוצעו באמצעות NCC Group – ארגון חיצוני שעוסק בבדיקות חדירה. ארגון NCC בדק את Confidential Space ומצא שזוהי פלטפורמת מחשוב מאובטחת.

המאמרים הבאים