מפתחות הצפנה באספקת הלקוח (CSEK)

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

מפתחות הצפנה באספקת הלקוח (CSEK) הם תכונה ב-Cloud Storage וב-Compute Engine. אם אתם מספקים מפתחות הצפנה משלכם, Google משתמשת במפתח שלכם כדי להגן על המפתחות שנוצרו על ידי Google, שמצפינים ומפענחים את הנתונים שלכם.

במסמך הזה מוסבר איך מפתחות CSEK פועלים ואיך הם מוגנים ב-Google Cloud.

איך מפתחות CSEK פועלים עם Cloud Storage

כשמשתמשים במפתחות CSEK ב-Cloud Storage, המפתחות הבאים הם חלק מתהליך העטיפה:

  • מפתח CSEK גולמי: אתם מספקים מפתח CSEK גולמי כחלק מקריאה ל-API. מפתח ה-CSEK הגולמי מועבר מממשק הקצה של Google‏ (GFE) לזיכרון של מערכת האחסון. המפתח הזה הוא המפתח להצפנת מפתחות הצפנה (KEK) ב-Cloud Storage עבור הנתונים שלכם.
  • מפתחות מוצפנים של חלקי נתונים: מפתחות מוצפנים של חלקי נתונים מוצפנים באמצעות מפתח ה-CSEK הגולמי.
  • מפתחות גולמיים של נתחי נתונים: מפתחות גולמיים של נתחי נתונים נארזים בזיכרון באמצעות מפתחות נארזים של נתחי נתונים. המפתחות הגולמיים של המקטעים משמשים להצפנת מקטעי הנתונים שמאוחסנים במערכות האחסון. המפתחות האלה משמשים כמפתחות להצפנת נתונים (DEK) ב-Cloud Storage עבור הנתונים שלכם.

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

Cloud Storage CSEK.

בטבלה הבאה מתוארים המפתחות.

מקשים מאוחסן ב מטרה הגישה זמינה עד

מפתח CSEK גולמי

זיכרון של מערכת האחסון

הגנה על מפתחות של נתחי נתונים מוצפנים.

הפעולה שהלקוח ביקש (לדוגמה, insertObject או getObject) הושלמה.

מפתחות של נתחים עטופים

התקני אחסון

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

אובייקט האחסון נמחק.

מפתחות של נתחים גולמיים

הזיכרון של התקני אחסון

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

הפעולה שהלקוח ביקש הושלמה

איך מפתחות CSEK פועלים עם Compute Engine

כשמשתמשים במפתחות CSEK ב-Compute Engine, המפתחות הבאים הם חלק מתהליך העטיפה:

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

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

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

המפתחות הגולמיים של הדיסק מועברים לזיכרון של מנהל האשכול (CM), מנהל המכונה ומכונת ה-VM. המפתחות האלה משמשים כמפתחות להצפנת נתונים (DEK) ב-Compute Engine עבור הנתונים שלכם.

הדיאגרמה הבאה מציגה כיצד פועלת עטיפת מפתח.

‫CSEK ב-Compute Engine.

מקשים בבעלות מטרה הגישה זמינה עד

מפתח CSEK גולמי

ממשק הקצה של מנהל האשכול

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

הפעולה שהלקוח ביקש (לדוגמה, instances.insert, instances.attachDisk) הושלמה.

מפתח CSEK שעבר הצפנה באמצעות מפתח ציבורי

(כשמשתמשים בעטיפת מפתח RSA)

ממשק הקצה של Cluster Manager

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

הפעולה שהלקוח ביקש הושלמה.

מפתח אסימטרי בבעלות Google

(כאשר נעשה שימוש בעטיפת מפתח RSA)

מאגר מפתחות

מבטלים את העטיפה של המפתח שעטוף ב-RSA.

ללא הגבלת זמן.

מפתח שנגזר מ-CSEK

ממשק הקצה של מנהל האשכול

מצפין את מפתחות הדיסק.

פעולת העטיפה או הפתיחה של מפתח הושלמה.

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

(כשמשתמשים בהפעלה מחדש אוטומטית)

ממשק הקצה של מנהל האשכול

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

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

המכונה הווירטואלית מושבתת או נמחקת.

מפתחות גולמיים של דיסקים

זיכרון של מכונה וירטואלית (VMM), זיכרון של מנהל אשכולות

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

המכונה הווירטואלית מושבתת או נמחקה

מפתח שנגזר ממפתח CSEK ועטוף על ידי Google

מסד נתונים של מנהל האשכול

הפעלה מחדש של הפעולה במקרה של כשל

הפעולה שהלקוח ביקש הושלמה

איך מוגנים מפתחות CSEK

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

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

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

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

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

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