ניתוח מעמיק של Cloud Key Management Service

מחברים: Sonal Shah,‏ Il-Sung Lee,‏ Walter Poupore,‏ Hunter Freyer,‏ Honna Segel,‏ Dwight Worley

תודות: Adrian Sears,‏ John Randolph,‏ Tim Dierks,‏ Chris Rezek,‏ Stanley McKenzie,‏ Kevin Plybon,‏ David Hale,‏ Sergey Simakov,‏ David U. Lee,‎ Carrie McDaniel,‏ Anton Chuvakin,‏ Dave Tonisson

עדכון אחרון: אפריל 2020

1. מבוא

העיקרון הבסיסי של Google Cloud הוא שהנתונים של משתמשי Google Cloud נמצאים בבעלותם, והם אלו שצריכים לקבוע את אופן השימוש בהם.

כשמאחסנים נתונים באמצעות Google Cloud, הנתונים נמצאים במצב הצפנה במנוחה כברירת מחדל. כשמשתמשים ב-Cloud Key Management Service‏ (Cloud KMS), מקבלים שליטה רבה יותר על אופן ההצפנה במנוחה של הנתונים ואופן הניהול של מפתחות ההצפנה.

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

  • הקצה העורפי של תוכנת Cloud KMS מספק גמישות להצפנת הנתונים באמצעות מפתח סימטרי או אסימטרי שנמצא בשליטתכם (Cloud KMS).
  • אם יש צורך במפתח חומרה, תוכלו להשתמש ב-Cloud HSM כדי לוודא שהמפתחות הסימטריים והאסימטריים שלכם נמצאים בשימוש רק במודולי אבטחה לחומרה (Hardware Security Modules‏ – HSMs) עם הסמכת FIPS 140-2 ברמה 3.
  • ‏Cloud KMS מאפשר לייבא מפתחות קריפטוגרפיים משלכם למקרה שתצטרכו להשתמש במפתחות שאתם יוצרים בעצמכם.
  • תוכלו להשתמש במפתחות שנוצרו על ידי Cloud KMS בשירותי Google Cloud אחרים. מפתחות כאלה נקראים מפתחות הצפנה בניהול הלקוח (CMEK). בעזרת המאפיין CMEK תוכלו ליצור מפתחות הצפנה שעוזרים להגן על נתונים בשירותי Google Cloud אחרים, להשתמש בהם, לבצע רוטציה שלהם ולהשמיד אותם.
  • בעזרת Cloud External Key Manager‏ (Cloud EKM) אפשר ליצור ולנהל מפתחות במנהל מפתחות מחוץ ל-Google Cloud, ואז להגדיר את השימוש של פלטפורמת Cloud KMS במפתחות החיצוניים כדי להגן על הנתונים באחסון. תוכלו להשתמש במפתחות הצפנה בניהול הלקוח ביחד עם מפתח Cloud EKM. הסקירה המפורטת הזו לא מרחיבה כרגע בנושא Cloud EKM.

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

'תרשים פורטפוליו של KMS'

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

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

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

2. מושגי הצפנה וניהול מפתחות ב-Google

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

2.1. מפתחות, גרסאות של מפתחות ואוספי מפתחות

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

'תרשים קיבוצים של מפתחות'

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

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

    ‏Cloud KMS תומך גם במפתחות אסימטריים וגם במפתחות סימטריים. מפתח סימטרי משמש להצפנה סימטרית כדי להגן על אוסף נתונים מסוים, לדוגמה, השימוש ב-AES-256 במצב GCM כדי להצפין בלוק של טקסטים ללא הצפנה. ניתן להשתמש במפתח אסימטרי להצפנה אסימטרית או ליצירת חתימות דיגיטליות. המטרות והאלגוריתמים הנתמכים מתוארים במסמכי התיעוד של Cloud KMS.

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

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

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

  • גרסת מפתח: מייצגת את חומר המפתח המשויך למפתח בשלב כלשהו. גרסת המפתח היא המשאב שמכיל בפועל את חומר המפתח. הגרסאות ממוספרות ברצף, החל מגרסה 1. כשמבצעים רוטציה למפתח, נוצרת גרסת מפתח חדשה עם חומר מפתח חדש. לאותו מפתח לוגי יכולות להיות כמה גרסאות לאורך זמן, וכתוצאה מכך יש הגבלת שימוש בכל גרסה. מפתחות סימטריים תמיד יכללו גרסה ראשית. הגרסה הזו משמשת להצפנה כברירת מחדל. כאשר מבצעים פענוח ב-Cloud KMS באמצעות מפתחות סימטריים, מתרחש זיהוי אוטומטי של גרסת המפתח שנחוצה לביצוע הפענוח.

2.2. היררכיית מפתחות

בתרשים הבא מוצגת היררכיית המפתחות של שירות ניהול המפתחות (KMS) הפנימי של Google. ‏Cloud KMS משתמש ב-KMS הפנימי של Google כדי ש-Google KMS יארוז את המפתחות שמוצפנים ב-Cloud KMS. ‏Cloud KMS משתמש באותו Root of Trust של Google KMS. ההגדרות הרלוונטיות מופיעות אחרי התרשים.

'תרשים של היררכיית מפתחות פנימית'

  • מפתח להצפנת נתונים (DEK): מפתח המשמש להצפנת נתונים.
  • מפתח להצפנת מפתחות הצפנה (KEK): מפתח המשמש להצפנה או לאריזה של מפתח להצפנת נתונים. כל האפשרויות בפלטפורמת Cloud KMS (תוכנה, חומרה ונקודות קצה עורפי חיצוניות) מאפשרות לכם לשלוט במפתח להצפנת מפתחות הצפנה.
  • מפתח המאסטר של KMS: מפתח המשמש להצפנה של המפתחות להצפנת מפתחות הצפנה. המפתח הזה מופץ בזיכרון. הגיבוי של מפתח המאסטר של KMS נמצא בהתקני חומרה. המפתח הזה אחראי להצפנת המפתחות שלכם.
  • Root KMS: השירות הפנימי לניהול מפתחות של Google.

2.3. תפעול

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

3. סקירה כללית על פלטפורמת Cloud KMS

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

'תרשים ארכיטקטורה של Cloud KMS'

התרשים הקודם מציג את הרכיבים העיקריים בפלטפורמת Cloud KMS. אדמינים יכולים לגשת לשירותי ניהול מפתחות באמצעות מסוף Google Cloud או Google Cloud CLI, או לחלופין דרך אפליקציות שמטמיעות את ממשקי ה-API ל-REST או ל-gRPC. אפליקציות ניגשות לשירותי ניהול מפתחות באמצעות API ל-REST או gRPC. אפליקציות יכולות להשתמש בשירותי Google שמאפשרים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK). ‏ה-CMEK משתמש בממשק Cloud KMS API. ‏Cloud KMS API מאפשר להשתמש במפתחות תוכנה (Cloud KMS) או במפתחות חומרה (Cloud HSM). מפתחות מבוססי תוכנה ומפתחות מבוססי חומרה נעזרים באמצעי ההגנה היתירים לגיבוי של Google.

באמצעות פלטפורמת Cloud KMS, אפשר לבחור רמת הגנה כשיוצרים מפתח, כדי לקבוע איזה קצה עורפי של המפתח יוצר את המפתח ומבצע את כל הפעולות הקריפטוגרפיות במפתח הזה בעתיד. פלטפורמת Cloud KMS מספקת שני קצוות עורפיים (לא כולל Cloud EKM) שנחשפים בממשק Cloud KMS API בתור רמות ההגנה SOFTWARE ו-HSM. רמת ההגנה SOFTWARE חלה על מפתחות שמודול אבטחה של תוכנה עלול לפתוח את האריזה שלהם כדי לבצע פעולות קריפטוגרפיות. רמת ההגנה HSM חלה על מפתחות שאפשר לפתוח את האריזה שלהם רק באמצעות מודולי אבטחה לחומרה (Hardware Security Modules) שמבצעים את כל הפעולות הקריפטוגרפיות עם המפתחות.

Google Cloud תומך ב-CMEK עבור מספר שירותים, כולל Cloud Storage,‏ BigQuery ו-Compute Engine. ב-CMEK אפשר להשתמש בפלטפורמת Cloud KMS כדי לנהל את מפתחות ההצפנה שבעזרתם השירותים האלה מגינים על הנתונים שלכם.

פעולות קריפטוגרפיות ב-Cloud KMS מתבצעות על ידי מודולים עם הסמכת FIPS 140-2. מפתחות עם רמת הגנה SOFTWARE, והפעולות הקריפטוגרפיות שניתן לבצע בעזרתם, תואמים ל-FIPS 140-2 ברמה 1. מפתחות עם רמת הגנה HSM, והפעולות הקריפטוגרפיות שניתן לבצע בעזרתם, תואמים ל-FIPS 140-2 ברמה 3.

3.1. סביבה ויחסי תלות

בקטע הזה מופיעים פרטים על התשתית של Google שבה פועלת פלטפורמת Cloud KMS, ועל פרוטוקולי התקשורת שבהם משתמשת התשתית.

3.1.1. משימות Cloud KMS Borg

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

3.1.1.1. משימות למילוי בקשות בממשק Cloud KMS API

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

3.1.1.2. משימות באצווה ב-Cloud KMS

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

  • ספירת מפתחות פעילים לחיוב הלקוחות.
  • צבירת משאבים מממשק API למאגר אחסון לפרוטוקולים ציבוריים של Cloud KMS, והעברת המטא-נתונים אל מאגר משאבי ענן. משאבים בהקשר הזה הם כל המשאבים שמנוהלים על ידי Cloud KMS, לדוגמה מפתחות ואוספי מפתחות.
  • צבירה של כל המשאבים ודיווח על מידע לניתוח נתונים עסקיים.
  • ביצוע snapshot של הנתונים כדי ליצור זמינות גבוהה.
  • אימות שכל הנתונים המאוחסנים במאגר הנתונים הבסיסי לא פגומים.
  • הצפנה מחדש של חומר מפתח של הלקוח כאשר מתבצעת רוטציה של מפתח המאסטר של KMS.
3.1.1.3. ‏Snapshotter של מפתח Cloud KMS

כדי לשמור על זמינות גבוהה, פלטפורמת Cloud KMS שומרת מאגר נתונים יתיר בכל מכונה בשירות משותף שמארח את משימות השרת של Cloud KMS API. כל שירות פורס מכונה משלו של שירות Snapshotter. היתירות הזו הופכת את השירותים לעצמאיים מאוד, וכתוצאה מכך לכשל באזור אחד יש השפעה מוגבלת על אזורים אחרים. כשמשימה ב-Cloud KMS API צריכה לבצע פעולה קריפטוגרפית, היא שולחת שאילתה למאגר הנתונים הראשי במקביל למשימות המקומיות של snapshotter. ‏Cloud KMS API משתמש במשימה שהשלימה ראשונה את המשימה בהצלחה. כדי למנוע עיכוב בצינור עיבוד הנתונים המבצע snapshot שעלול לגרום להצגת נתונים לא פעילים, שרת ה-API לא משתמש בתוצאות ממשימות של snapshotter אם הנתונים קיימים למשך יותר משעתיים. Snapshots נוצרים כפלט של משימה באצווה שפועלת באופן רציף לכל אזור. ה-Snapshots נמצאים באזור הענן שמשויך לחומר המפתח.

3.1.2. תקשורת בין שרתים ללקוחות

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

  • פרוטוקול אימות מקצה לקצה (P2P) לאפליקציות
  • פרוטוקול לרישום הצפנה
  • ממשק API שחושף את המשתמש המאומת למטרת הרשאה

הפרוטוקולים של ALTS ללחיצת יד ולרישום הצפנה דומים לפרוטוקולים של Transport Layer Security‏ (TLS) ללחיצת יד ולרישום. ב-ALTS מתבצעות פעולות שונות כדי לבצע אופטימיזציה של סביבת הייצור של Google, ויש שילוב מלא של ALTS בתוך כל סטאק החומרה והתוכנה של הייצור. פרטים נוספים מופיעים בקטע סביבת התפעול של פלטפורמת Cloud KMS בהמשך המאמר.

4. פרטי ארכיטקטורה של פלטפורמת Cloud KMS

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

מתוארות כאן גם האפשרויות למפתחות הצפנה בניהול הלקוח (CMEK).

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

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

ב-Cloud KMS, חומרי המפתחות תמיד מוצפנים במנוחה ובמעבר. פענוח של חומר מפתח מתבצע רק במקרים הבאים:

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

בקשות של לקוחות ב-Cloud KMS מוצפנות במעבר באמצעות TLS (אבטחת שכבת התעבורה) בין הלקוח לממשק הקצה של Google‏ (GFE). אבטחת שכבת התעבורה של אפליקציה (ALTS), שתוארה קודם לכן בקטע תקשורת בין שרתים ללקוחות, משמשת להצפנה בין משימות ב-Cloud KMS ונקודות הקצה העורפי שלהן במרכזי נתונים שונים. פירוט בנושא ALTS והצפנה במעבר מופיע בקטע מחזור החיים של בקשה ב-Cloud KMS בהמשך המאמר.

אימות מתרחש בין כל המשימות ב-KMS, בין מרכזי הנתונים של Google ובתוכם.

המדיניות של Google היא לוודא שמשימות משתמשות רק בקוד מקור שנוצר, נבחן ונבדק בצורה מאומתת. המדיניות הזו נאכפת ברמת התפעול באמצעות Binary Authorization for Borg‏ (BAB), כפי שמפורט במסמכי התיעוד בנושא אבטחה.

משימות ב-Cloud KMS API יכולות לגשת למטא-נתונים של מפתח (לדוגמה, מדיניות IAM או מחזורי הרוטציה). גוגלר שיש לו הצדקה עסקית תקפה ומתועדת (למשל, באג או בעיה של לקוח) גם יכול לגשת למטא נתונים של מפתח. הגישות נרשמות באופן פנימי, ויומנים הקשורים לנתונים שמאובטחים על ידי Access Transparency זמינים גם ללקוחות שעומדים בדרישות.

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

4.2. הגנה על מאגר הנתונים

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

4.2.1. מפתחות מאסטר

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

4.2.2. מדיניות רוטציה

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

4.2.3. המיקום של נתונים

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

4.3. זמינות מפתחות לאחר היצירה

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

4.4. הקצה העורפי של תוכנת Cloud KMS: רמת הגנה SOFTWARE

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

4.4.1. הטמעות אלגוריתמיות

Cloud KMS משתמש במודול BoringCrypto ‏(BCM) למפתחות תוכנה, במסגרת הטמעת BoringSSL של Google בכל העבודות הקריפטוגרפיות הקשורות. ל-BCM יש הסמכת FIPS 140-2. הבינארי ב-Cloud KMS נוצר בעקבות קריפטוגרפיה קדומה (Cryptographic Primitives) בהסמכת FIPS 140-2 ברמה 1 של המודול הזה. האלגוריתמים העדכניים ביותר הכלולים במודול הזה מופיעים בדף התיעוד שלנו, וכוללים פעולות של הצפנה, פענוח וחתימה באמצעות מפתחות קריפטוגרפיים סימטריים מסוג AES256-GCM ואסימטריים מסוג RSA 2048,‏ RSA 3072,‏ RSA 4096,‏ EC P256 ו-EC P384.

4.4.2. יצירה ואנטרופיה של מספרים אקראיים

כשיוצרים מפתחות הצפנה, Cloud KMS משתמש ב-BoringSSL. בשביל הסמכת FIPS 140-2, צריך להשתמש ב-PRNGs עצמיים (שנקראים גם DRBGs). ב-BoringCrypto,‏ Cloud KMS משתמש אך ורק ב-CTR-DRBG עם AES-256. כך מתקבל פלט של RAND_bytes, הממשק הראשי שבאמצעותו מתקבלים בשאר חלקי המערכת נתונים אקראיים. המקור של ה-PRNG הוא מ-RNG של ליבת Linux, שנובעת בעצמה ממספר מקורות אנטרופיה עצמאיים. תהליך היצירה מהמקור כולל אירועים אנטרופיים מסביבת מרכז הנתונים, למשל מדידות מדוקדקות של סרגלי דיסקים (disk seeks) וזמני הגעה בין חבילות, וכן הוראות ה-RDRAND של Intel כאשר זה אפשרי. למידע נוסף על ההתנהגות של מחולל המספרים האקראיים ל-BoringSSL (במצב שתואם ל-FIPS), כדאי לעיין בתכנון RNG.

4.5. הקצה העורפי של HSM ב-Cloud KMS: רמת הגנה HARDWARE

שירות Cloud HSM מספק מפתחות ל-Cloud KMS שמגובים בחומרה. הוא מאפשר ללקוחות להשתמש במפתחות קריפטוגרפיים שמוגנים על ידי מודולים מנוהלים של אבטחה לחומרה (HSMs) עם הסמכת FIPS 140-2 ברמה 3 במרכזי הנתונים של Google. זהו שירות עם זמינות גבוהה והתאמה גמישה לעומס (scaling), בדיוק כמו Cloud KMS. לקוחות קיימים של Cloud KMS לא נדרשים לבצע שינויים באפליקציות, כי הם יכולים לגשת לשירות Cloud HSM באמצעות אותן ספריות לקוח ואותו ממשק API שמשמשים גם את Cloud KMS. מידע נוסף על שירות Cloud HSM זמין במאמר ארכיטקטורת Cloud HSM.

4.6. ‏Cloud KMS: ייבוא מפתחות

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

כחלק מייבוא המפתחות, Cloud KMS יוצר מפתח אריזה, שהוא זוג מפתחות ציבורי/פרטי, באמצעות אחת משיטות הייבוא הנתמכות. הצפנת חומר המפתח באמצעות מפתח האריזה מספקת הגנה על חומר המפתח במעבר.

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

ניתן להשתמש במפתחות מיובאים בעזרת רמת ההגנה HSM או SOFTWARE.

ב-Cloud HSM, החלק של המפתח הפרטי בתוך מפתח האריזה זמין רק ב-Cloud HSM. הגבלת החלק של המפתח הפרטי רק ל-Cloud HSM מונעת מ-Google לפתוח את האריזה של חומר המפתח מחוץ ל-Cloud HSM.

4.7. מפתחות הצפנה בניהול הלקוח (CMEK)

כל נתוני הלקוחות המאוחסנים במצב מנוחה מוצפנים ב-Google Cloud כברירת מחדל, בעוד שהמפתחות המשמשים להצפנה מנוהלים על ידי Google. במוצרים מסוימים של Google Cloud, לקוחות יכולים להשתמש במקום זאת ב-Cloud KMS כדי לנהל את המפתחות המשמשים להצפנה. אפשר להשתמש ב-CMEK למפתחות שמגובים בחומרה ובתוכנה. Cloud KMS מאפשר ללקוח לשלוט בהיבטים רבים של המפתחות (כמו יצירה, הפעלה/השבתה, ביצוע רוטציה והשמדה של מפתחות) ולנהל את ההרשאות המתאימות ב-IAM. ‏Cloud KMS כולל מספר תפקידי IAM מוגדרים-מראש עם הרשאות והגבלות ספציפיות, שאפשר להעניק למשתמשים ולחשבונות שירות מסוימים כדי לאכוף את הפרדת הסמכויות הרצויה.

הנושאים הבאים מפרטים על מוצרים שמשולבים בפלטפורמת Cloud KMS, שתומכים ב-CMEK:

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

במסמך זה מפורטת הרשימה המלאה של שירותים עם שילובי CMEK ושירותים שתואמים ל-CMEK. ‏Google ממשיכה להשקיע בשילוב של CMEK במוצרים אחרים של Google Cloud.

4.8. מחזור החיים של בקשה ב-Cloud KMS

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

תרשים מחזור החיים של בקשה ב-KMS

השלבים במחזור החיים כוללים את אלה:

  1. לקוח, או משימה שפועלת בשמו, יוצרים בקשה לשירות Cloud KMS‏ – https://cloud kilometers.googleapis.com.‏ ב-DNS מתבצעת התאמת נתונים (resolve) של הכתובת הזו לכתובת IP של ממשק הקצה של Google‏ (GFE) המנותבת בשיטת anycast.
  2. ‏GFE מספק אירוח IP ציבורי של שם ה-DNS הציבורי שלו, הגנה מפני התקפת מניעת שירות (DoS) וסיום TLS. כשלקוח שולח בקשה, בדר"כ היא מנותבת ל-GFE בקרבת הלקוח בלי קשר למיקום היעד שלה. GFE מטפל במשא ומתן ב-TLS (אבטחת שכבת התעבורה), ובעזרת כתובת ה-URL והפרמטרים של הבקשה, ה-GFE קובע איזה מאזן עומסי תוכנה גלובלי (Global Software Load Balancer‏ – GSLB) ישמש לניתוב הבקשה.
  3. לכל אזור ב-Cloud KMS יש יעד GSLB נפרד. אם הבקשה מגיעה ל-Google באזור us-east1 והבקשה שייכת ליעד us-west1, היא מנותבת בין מרכזי הנתונים us-east1 ו-us-west1. כל התקשורת בין מרכזי הנתונים מוצפנת במעבר באמצעות ALTS, שמאמת באופן הדדי את המשימות ב-GFE וב-Cloud KMS.
  4. כשהבקשה מגיעה למשימה ב-Cloud KMS, בהתחלה היא מעובדת על ידי framework שמטפל בחלק גדול מהעבודה המשותפת לכל שירותי Google Cloud. ה-framework מאמת את המשתמש ומבצע מספר בדיקות כדי לוודא את הפרטים הבאים:
    • ללקוח יש פרטי כניסה תקפים ואפשר לאמת אותו.
    • לפרויקט ב-Google Cloud יש ממשק Cloud KMS API פעיל וחשבון תקף לחיוב.
    • המכסה מספיקה כדי להריץ את הבקשה.
    • הלקוח נמצא ברשימת ההיתרים לשימוש באזור Google Cloud הרלוונטי.
    • הבקשה לא תידחה על ידי VPC-Service Controls.
  5. לאחר שהבדיקות האלה עוברות בהצלחה, ה-framework מעביר את הבקשה ואת פרטי הכניסה ל-Cloud KMS. ‏Cloud KMS מנתח את הבקשה כדי לקבוע לאילו משאבים צריך לגשת, ואז בודק דרך IAM אם המתקשר מורשה לבצע את הבקשה. IAM גם מנחה את Cloud KMS אם לכתוב את אירוע הבקשה ביומני הביקורת.
  6. לאחר שהבקשה מאומתת ומקבלת הרשאה, Cloud KMS קורא לקצוות העורפיים של מאגר הנתונים בתוך האזור כדי לאחזר את המשאב המבוקש. אחרי האחזור, חומר המפתח של הלקוח מפוענח ומוכן לשימוש.
  7. בעזרת חומר המפתח, Cloud KMS מבצע את הפעולה הקריפטוגרפית ומעביר את הגרסה הארוזה של המפתח לקצה העורפי של תוכנת Cloud KMS או ל-Cloud HSM, בהתאם לרמת ההגנה על המפתח.
  8. בסיום הפעולה הקריפטוגרפית, התגובה מוחזרת ללקוח בערוץ מסוג GFE-to-KMS בדומה לשליחת הבקשה.
  9. כשהתגובה מוחזרת, Cloud KMS מפעיל גם אירועים מסוימים באופן אסינכרוני:
    • מילוי יומני הביקורת ויומני הבקשות והעברתם לתור לכתיבה.
    • שליחת דוחות למטרות חיוב וניהול המכסות.
    • אם הבקשה עדכנה את המטא-נתונים של משאב, השינוי נשלח אל מאגר משאבי ענן באמצעות עדכוני משימות באצווה.

4.9. השמדת חומר מפתחות

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

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

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

5. סביבת התפעול בפלטפורמת Cloud KMS

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

5.1. מהנדסי תוכנה, site reliability engineers ואופרטורים של מערכות

מהנדסי התוכנה אחראים לשיתוף הפעולה עם בעלי עניין אחרים, למשל מנהלי מוצרים ו-site reliability engineers‏ (SRE), כדי לתכנן את המערכת ולבסוף לכתוב חלק גדול מהקוד והבדיקות של שירות Cloud KMS. הקוד כולל את המשימה הראשית שממלאת בקשות של לקוחות, וכן משימות משניות לפעילויות כמו יצירת רפליקה של נתונים וחיוב. מהנדסי SRE גם יכולים לכתוב קוד. עם זאת, הסמכויות של מהנדסי תוכנה ומהנדסי SRE נפרדות. מהנדסי ה-SRE אחראים בעיקר לתחזוקת סביבת הייצור למשימות ב-Cloud KMS. מהנדסי ה-SRE מודדים את האמינות ומשיגים אותה באמצעות פעולות הנדסה ותפעול.

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

5.2. מיקוד לפי אזורים של משאבי Cloud KMS

תוכלו ליצור משאבי Cloud KMS באחד מארבעת הסוגים הבאים של מיקומים ב-Google Cloud:

  • מיקומים אזוריים. מיקום אזורי כולל תחומים (zones) במקום גיאוגרפי ספציפי, למשל קליפורניה.
  • מיקומים בשני אזורים. מיקום בשני אזורים מורכב מתחומים (zones) בשני מיקומים גיאוגרפיים ספציפיים, למשל קליפורניה וטקסס.
  • מיקומים במספר אזורים. מיקום במספר אזורים מורכב מתחומים (zones) שמפוזרים על פני אזור גיאוגרפי כללי, למשל ארצות הברית.
  • המיקום הגלובלי. המיקום הגלובלי מורכב מתחומים (zones) שפזורים ברחבי העולם. כשיוצרים משאבי Cloud KMS במיקום הגלובלי, הם זמינים מתחומים בכל העולם.

מיקומים מייצגים את האזורים הגיאוגרפיים שבהם מטפלים בבקשות ל-Cloud KMS למשאב נתון, ושבהם מאוחסנים המפתחות הקריפטוגרפיים התואמים.

מידע נוסף על המיקומים הזמינים ב-Cloud KMS מופיע במסמכי התיעוד של Cloud KMS.

5.2.1. אזורים ומרכזי נתונים ב-Cloud

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

כל מרכז נתונים מכיל מדפים של מכונות למחשוב, לרשת או לאחסון נתונים. המכונות האלה פועלות בתשתית Borg של Google.

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

5.2.2. מיקוד לפי אזורים

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

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

באזור הגלובלי אין התחייבות למיקוד לפי אזורים.

Cloud KMS לא מבטיח מיקום למטא-נתונים של המפתח, ליומני שימוש ולחומר מפתח במעבר. מטא-נתונים של מפתח כוללים שמות משאבים, מאפיינים של משאבי Cloud KMS (למשל סוג, גודל ומצב המפתח), מדיניות IAM וכל הנתונים שנובעים מהמטא-נתונים.

במהלך השימוש ב-CMEK, ההגבלות הגיאוגרפיות הבאות של Cloud KMS חלות על המפתחות שלכם, ללא קשר לבחירת המיקומים באזור יחיד, בשני אזורים או במספר אזורים במוצרים אחרים של Google Cloud שאתם מעוניינים להשתמש בהם בעזרת CMEK:

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

המיקום של חומר מפתח ב-Cloud KMS מתומצת בטבלה הבאה:

מיקום של נתונים ב-Cloud KMS במצב מנוחה, בשימוש
(מיקום באזור יחיד)		 במצב מנוחה, בשימוש
(מיקום בשני אזורים או במספר אזורים)
חומר מפתח של תוכנה תושבים תושבים באזורים שמרכיבים את המיקום בשני אזורים או במספר אזורים.
חומר מפתח של חומרה (HSM) תושבים תושבים באזורים שמרכיבים את המיקום בשני אזורים או במספר אזורים.

5.2.3. מעקב אחרי מיקוד לפי אזורים

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

5.3. אימות והרשאה

ב-Cloud KMS אפשר להשתמש במגוון של מנגנוני אימות, למשל OAuth‏2, JWT ו-ALTS. לגבי כל מנגנון, Cloud KMS מבצע התאמת נתונים לפרטי הכניסה שסופקו כדי לזהות את חשבון המשתמש (הישות המאומתת שמאשרת את הבקשה), ומבצע קריאה ל-IAM כדי לבדוק אם לחשבון המשתמש יש הרשאה לבצע את הבקשה ואם נכתב יומן ביקורת.

Cloud KMS משתמש בגרסה פנימית של ממשק Service Control API הציבורי לצרכים שונים בניהול השירותים. לפני שמשימת Cloud KMS מטפלת בבקשה, תחילה היא שולחת בקשת בדיקה לממשק Service Control API שאוכף אמצעי בקרה רבים המשותפים לכל שירותי Google Cloud. לדוגמה:

  • בדיקה אם הלקוח הפעיל את ממשק Cloud KMS API ואם יש לו חשבון פעיל לחיוב.
  • בדיקה אם הלקוח לא חרג מהמכסה שלו, ודיווח על נפח השימוש במכסה.
  • אכיפה של VPC Service Controls.
  • בדיקה אם הלקוח נמצא ברשימת ההיתרים של אזורים רלוונטיים בענן הפרטי.

5.4. רישום ביומן

יש שלושה סוגי יומנים המשויכים ל-Cloud KMS: יומני Cloud Audit Logs, יומני Access Transparency ויומני בקשות פנימיים.

5.4.1. יומני ביקורת של Cloud

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

5.4.2. יומני Access Transparency

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

אפשר לשלב בין יומני Access Transparency לבין הכלים הקיימים לניהול אירועים ופרטי אבטחה (SIEM) כדי להפוך את הביקורות על הפעולות האלה לאוטומטיות. היומנים האלה זמינים במסוף Cloud יחד עם יומני Cloud Audit Logs.

הרשומות ביומן Access Transparency כוללות את סוגי הפרטים הבאים:

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

5.4.3. יומני בקשות פנימיים

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

הרשומות ביומן נמחקות באופן סופי בתום אורך החיים (TTL) שהוגדר.

למהנדסי SRE ב-Cloud KMS ולמהנדסים בסבב התורן יש גישה ליומני בקשות. גישה אנושית ליומנים וגישה לנתוני לקוחות מחייבות הצדקה עסקית מתועדת ותקפה. במקרים חריגים מסוימים, הגישה האנושית נרשמת ביומן ונגישה ללקוחות שיכולים לצפות ביומני Access Transparency.

5.5. קצה עורפי של מאגר נתונים

מאגר הנתונים של Cloud KMS עמיד, מוגן ועם זמינות גבוהה.

זמינות. Cloud KMS משתמש במאגר הנתונים הפנימי של Google, שהוא מאגר עם זמינות גבוהה התומך בכמה מהמערכות החיוניות של Google.

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

ב-Cloud KMS יש כמה סוגי גיבויים במאגר הנתונים:

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

לצוות Cloud KMS יש הליכים מתועדים לשחזור גיבויים במקרי חירום.

מיקום הגיבויים של מאגר הנתונים ב-Cloud KMS נמצאים באזור של Google Cloud המשויך אליהם. כל הגיבויים האלה מוצפנים במנוחה. הגישה לנתונים בגיבויים מוגבלת על סמך הנימוקים לגישה (למשל, מספר הפנייה שנשלחה לתמיכה של Google), וכל גישה אנושית מתועדת ביומני Access Transparency.

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

6. קריאה נוספת

מידע נוסף זמין במשאבים הבאים:

סקירות מפורטות:

מסמכי תיעוד אחרים: