הכלי להצפנה עם פיצול הרשאות (STET) מאפשר העברה מאובטחת של נתוני מפתחות אל Google Cloud וממנו, באופן שניתן לאימות ומוגן קריפטוגרפית מפני משתמשים פנימיים ב- Google Cloud .
ההצפנה מתבצעת באמצעות שתי מערכות לניהול מפתחות (KMS), אחת פנימית ל-Google Cloudוהשנייה חיצונית. גם אם אחד משרתי ה-KMS ייפרץ, השרת השני ימשיך לפעול כדי לשמור על פרטיות הנתונים.
בהמשך מופיעות כמה דוגמאות שקשורות לנתונים שמועברים אל Cloud Storage ומחושבים באמצעות מכונות וירטואליות של Compute Engine. הדוגמאות מציגות שלבים להגברת רמות האבטחה כדי להסביר איך STET משתלב בתהליך האבטחה.
רמה 1: Cloud Storage
כשמבצעים המרת נתונים ל- Google Cloud, אפשר להשתמש ב-Cloud Storage כדי להפוך את הנתונים לזמינים לעומסי העבודה בענן. אתם יכולים להעלות את הנתונים מסביבות המחשוב המקומיות שלכם לקטגוריה של Cloud Storage, לתת לעומס העבודה גישה לקטגוריה הזו ולגרום לעומס העבודה (או לכמה עומסי עבודה) לצרוך את הנתונים האלה כשצריך. השיטה הזו מונעת את המורכבות של יצירת חיבור פעיל ישירות לעומס העבודה כדי לשלוח לו את הנתונים שהוא צריך.
ב-Cloud Storage הנתונים תמיד מוצפנים במצב מנוחה. עם זאת, אם אתם סומכים על Cloud Storage שיבצע את ההצפנה בשבילכם, תהיה לו גישה לנתונים הלא מוצפנים (טקסט רגיל) לפני ההצפנה, וגם למפתחות ההצפנה ששימשו ליצירת הנתונים המוצפנים (טקסט מוצפן). בהתאם למודל האיומים שלכם, יכול להיות שתרצו להצפין את הנתונים לפני שתשלחו אותם ל-Cloud Storage, כדי של-Cloud Storage לא תהיה גישה לטקסט לא מוצפן.
רמה 2: הצפנה מצד הלקוח
כשמשתמשים בהצפנה מצד הלקוח, מצפינים את הנתונים לפני שהם מועלים ל-Cloud Storage ומפענחים אותם רק אחרי שהם מורדים לעומס העבודה. כתוצאה מכך, ל-Cloud Storage יש גישה לטקסט המוצפן אבל לא לטקסט הגלוי. Cloud Storage מוסיף עוד שכבת הצפנה לפני האחסון, אבל ההגנה העיקרית על הנתונים היא ההצפנה שמתבצעת לפני ההעלאה.
בגישה הזו, צריך לתת לעומס העבודה גישה למפתח ההצפנה שנדרש כדי לפענח את הנתונים. המשימה הזו עלולה להיות קשה, כי מפתח ההצפנה מאפשר להסיר את שכבת ההצפנה המקורית שלכם ולקבל גישה לנתונים.
רמה 3: ניהול מפתחות חיצוני
גישה נפוצה לפתרון הבעיה הזו של ניהול מפתחות היא שימוש בשירות ייעודי לניהול מפתחות (KMS) שמחזיק את המפתחות ומנהל את הגישה אליהם. בכל ניסיון הצפנה או פענוח, צריך לשלוח בקשה ל-KMS. ל-KMS יש אפשרות להעניק גישה על סמך קריטריונים שונים, כדי להבטיח שרק גורמים מתאימים יוכלו לפענח את הנתונים.
מערכות KMS יכולות לדרוש מספר קריטריונים שונים לפני אישור הגישה למפתח ההצפנה, אבל בדרך כלל הן דורשות אישור שמתאים למדיניות שהוגדרה ב-KMS. לכן, כל גורם שמחזיק באמצעי האימות הזה יוכל לגשת למפתח ההצפנה ולפענח את הנתונים.
רמה 4: Confidential Computing
במקרים של Confidential VM, הזיכרון מוצפן, וכך מספק הגנה נוספת מפני גישה לא מכוונת לנתונים בזמן השימוש. במודלים רבים של איומים, מכונות Confidential VM נחשבות מהימנות יותר ממכונות רגילות, ולכן אפשר להשתמש בהן לעומסי עבודה רגישים.
אם מודל האיומים שלכם מסתמך על Confidential Computing, אחת הבעיות היא לוודא שעומס עבודה פועל במכונה וירטואלית מסוג Confidential VM. אימות (attestation) מרחוק הוא אמצעי שמאפשר לעומס העבודה להוכיח לצד שלישי מרוחק שהוא פועל במופע של Confidential VM, ולאשר מאפיינים רבים אחרים לגבי ההגדרה והסביבה של עומס העבודה. מכיוון שהאישורים נוצרים על ידי הפלטפורמה, עומס העבודה לא יכול ליצור אישורים כוזבים שלא משקפים את הסביבה בפועל.
מערכת KMS יכולה לדרוש ולאמת את האישורים האלה לפני שהיא מאפשרת גישה למפתחות. הדרישה הזו עוזרת לוודא שרק לעומס העבודה המיועד מותר לפענח את הנתונים, גם אם פרטי הכניסה הרגילים נפרצו.
רמה 5: אמון מפוצל
כשמשתמשים ב-KMS יחיד, ל-KMS הזה יש שליטה בלעדית במפתחות ההצפנה. אם מפעיל KMS ישיג את המידע המוצפן (ciphertext) של הנתונים המוצפנים שלכם, יהיה לו כל מה שצריך כדי לפענח אותו לטקסט לא מוצפן. יכול להיות שהסיכון הזה מקובל אם מערכת ה-KMS מופעלת על ידי גורם שאפשר לבטוח בו לחלוטין, אבל יש מודלים של איומים שבהם צריך להסיר את השליטה החד-צדדית ממערכת ה-KMS.
עם STET, יש לכם אפשרות לפצל את האמון הזה בין שתי מערכות KMS, כך שאף אחת מהן לא מכילה מספיק מידע כדי לפענח את הנתונים שלכם. כדי לפענח את הנתונים, נדרש שיתוף פעולה בין שני מפעילי KMS (וגישה לטקסט המוצפן).
אם אתם משתמשים ב-Confidential VM, STET גם מאפשרת הצפנה ופענוח של נתונים באמצעות מפתחות שמאוחסנים ב-KMS שדורש אישורים.
בסך הכול, STET עוזר לוודא שהישויות היחידות שיש להן גישה לנתונים בטקסט לא מוצפן הן יוצר הנתונים (לדוגמה, מערכת מקומית) וצרכן הנתונים (לדוגמה, עומס עבודה שפועל במכונה וירטואלית מסוג Confidential).
מידע נוסף על השימוש ב-STET זמין במאגר GitHub ובמדריך לתחילת העבודה.
Confidential Space עם STET
אם משתמשים ב-Confidential Space, STET יכול להשתמש בטוקן האימות מ-Confidential Space כהוכחת אימות כשניגשים למפתח להצפנת מפתחות הצפנה (KEK) שמאוחסן ב-Cloud KMS.
STET מטפל בגישה למפתחות Cloud KMS עבור עומס העבודה שלכם, ותומך בשימוש ב-Confidential Space כדי לבצע אימות לתהליך העבודה של ההצפנה, לתהליך העבודה של הפענוח או לשני תהליכי העבודה.
אפשר ליצור הגדרת STET שכוללת מידע כמו שם מאגר זהויות של עומסי עבודה (WIP), כתובות URI של Cloud KMS ופרטי פענוח. לאחר מכן, STET משתמש במידע הזה כדי להשתלב בהגדרות של Confidential Space.
מידע נוסף זמין במאגר GitHub ובמדריך לשילוב Confidential Space.