סקירה מפורטת של Cloud Key Management Service

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

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

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

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

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

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

עמודי התווך בתכנון של Cloud KMS

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

  • שליטה של הלקוח: ‏Cloud KMS מאפשר לכם לנהל מפתחות להצפנה של תוכנות וחומרה ולהתחברות אליהן. עמוד התווך הזה כולל תמיכה ב-bring-your-own-keys ‏(BYOK) וב-hold-your-own-keys ‏(HYOK).
  • בקרת גישה ומעקב: באמצעות Cloud KMS תוכלו לנהל הרשאות במפתחות נפרדים ולעקוב אחרי השימוש בהם.
  • מיקוד לפי אזורים: ‏Cloud KMS מציע גישה ייחודית לחלוקה לאזורים. השירות מוגדר ליצירה, לאחסון ולעיבוד של מפתחות רק במיקום שבחרתם ב-Google Cloud.
  • גיבויים: כדי להגן מפני פגיעה בנתונים ולוודא שאפשר לפענח אותם, Cloud KMS סורק ומגבה מדי פעם את כל החומרים והמטא נתונים של המפתחות.
  • אבטחה:‏ Cloud KMS מציע אמצעי הגנה חזקים מפני גישה לא מורשית למפתחות, והוא משולב באופן מלא עם אמצעי הבקרה של ניהול זהויות והרשאות גישה (IAM) ושל יומני הביקורת של Cloud.

מקורות ואפשרויות ניהול של חומרי מפתחות

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

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

הפורטפוליו של Google Cloud למפתחות.

האפשרויות שמוצגות בתרשים שלמעלה הן:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

היררכיית מפתחות תוכנה

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

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

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

  1. מפתח להצפנת נתונים (DEK) מצפין את מקטעי הנתונים.
  2. מפתח להצפנת מפתחות הצפנה (KEK) משמש להצפנה או לאריזה של ה-DEK. כל האפשרויות בפלטפורמת Cloud KMS (תוכנה, חומרה ונקודות קצה עורפי חיצוניות) מאפשרות לכם לשלוט ב-KEK. ה-KEK מאוחסנים ב-Cloud KMS.
  3. מפתח מאסטר של KMS מצפין את ה-KEK. מפתח המאסטר של KMS מאוחסן ב-Keystore. לכל מיקום ב-Cloud KMS יש ב-Keystore מפתח מאסטר של KMS. מפתחות KEK של Cloud KMS מוגנים לפי המיקום של מפתח המאסטר של KMS. כל שרת Cloud KMS מאחזר עותק של מפתח המאסטר של KMS במהלך ההפעלה כתוצאה מיחסי תלות חזקים, ועותק חדש של מפתח המאסטר של KMS מאוחזר מדי יום. מפתח המאסטר של KMS מוצפן מחדש באופן שוטף.
  4. מפתח המאסטר של KMS מוגן באמצעות מפתח המאסטר של מאגר המפתחות ב-Keystore.
  5. מפתח המאסטר של מאגר המפתחות מוגן באמצעות מפתח המאסטר ברמה הבסיסית של מאגר המפתחות.

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

מגבלות תפעוליות של מפתחות

‏Cloud KMS פועל במסגרת המגבלות הבאות:

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

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

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

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

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

  • אדמינים יכולים לגשת לשירותי ניהול מפתחות באמצעות מסוף Cloud או Google Cloud CLI.
  • אפליקציות ניגשות לשירותי ניהול מפתחות באמצעות API ל-REST, ‏gRPC או ספריות לקוח. אפליקציות יכולות להשתמש בשירותי Google שמאפשרים להשתמש ב-CMEK. ה-CMEK משתמש ב-Cloud Key Management Service API. אם האפליקציה שלכם משתמשת ב-PKCS #11, אתם יכולים לשלב אותו עם Cloud KMS באמצעות הספרייה של PKCS #11.

  • ‏Cloud KMS API מאפשר להשתמש במפתחות תוכנה, במפתחות חומרה או במפתחות חיצוניים. מפתחות מבוססי תוכנה ומפתחות מבוססי חומרה נעזרים באמצעי ההגנה היתירים לגיבוי של Google.

  • אם משתמשים במפתחות חומרה, מפתחות HSM עם אישור FIPS 140-2 ברמה 3 ב-Google Cloud מאחסנים את המפתחות. אפשר לקרוא מידע נוסף על האישור הזה במאמר בנושא אישור #4399‎.

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

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

תיקוף של אישור FIPS 140-2

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

יחסי תלות עם התשתית של Google

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

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

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

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

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

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

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

‏Snapshotter של מפתח Cloud KMS

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

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

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

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

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

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

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

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

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

בקשות של לקוחות ב-Cloud KMS מוצפנות במעבר באמצעות TLS בין הלקוח לממשק הקצה של Google‏ (GFE).

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

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

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

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

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

מאגר הנתונים של 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 מוצפנים בלי גישה למפתחות ההצפנה של מאגר הנתונים, ששמורים ב-Keystore.

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

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

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

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

הקצה העורפי של מפתחות

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

  • SOFTWARE: חלה על מפתחות שמודול אבטחה של תוכנה עלול לפתוח את האריזה שלהם כדי לבצע פעולות קריפטוגרפיות.
  • HSM: חלה על מפתחות שאפשר לפתוח את האריזה שלהם רק באמצעות מודולי HSM שמבצעים את כל הפעולות הקריפטוגרפיות עם המפתחות.
  • EXTERNAL או EXTERNAL-VPC: חלות על מנהל מפתחות חיצוני (EKM). באמצעות EXTERNAL-VPC אפשר לחבר את ה-EKM ל-Google Cloud ברשת VPC.

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

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

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

‏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.

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

כשיוצרים מפתחות הצפנה, 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.

הקצה העורפי של Cloud HSM: רמת הגנה HARDWARE

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

‏Cloud EKM: רמת הגנה EXTERNAL

שירות Cloud EKM מאפשר להצפין נתונים באמצעות מפתחות הצפנה מחוץ לענן שנשארים בשליטתכם.

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

ייבוא מפתחות

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. לקוח, או משימה שפועלת בשמו, יוצרים בקשה לשירות Cloud KMS‏ – https://cloud kilometers.googleapis.com.‏ ב-DNS מתבצעת התאמת נתונים (resolve) של הכתובת הזו לכתובת IP של ה-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 מאמת את המשתמש ומבצע מספר בדיקות כדי לוודא את הפרטים הבאים:
    • ללקוח יש פרטי כניסה תקפים ואפשר לאמת אותו.
    • לפרויקט יש ממשק 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 או לקצה העורפי של Cloud EKM, בהתאם לרמת ההגנה על המפתח.
  8. כשהפעולה הקריפטוגרפית מסתיימת, התגובה מוחזרת ללקוח בערוץ מסוג GFE-to-KMS בדומה לשליחת הבקשה.
  9. כשהתגובה מוחזרת, Cloud KMS מפעיל גם אירועים מסוימים באופן אסינכרוני:
    • מילוי יומני הביקורת ויומני הבקשות והעברתם לתור לכתיבה.
    • שליחת דוחות למטרות חיוב וניהול המכסות.
    • אם הבקשה עדכנה את המטא-נתונים של משאב, השינוי נשלח למאגר משאבי ענן באמצעות עדכוני משימות באצווה.

תקינות הנתונים מקצה לקצה

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

תקינות הנתונים מקצה לקצה עוזרת להגן על הסביבה מפני איומים כמו:

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

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

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

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

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

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

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

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

כדי להימנע ממחיקה של מפתח בטעות, מומלץ להשתמש בשיטות המומלצות הבאות:

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

      resource.type="cloudkms_cryptokeyversion"
      protoPayload.methodName="DestroyCryptoKeyVersion"
    
  • ליצור תהליכים להשבתה של המפתח לכמה ימים לפני שהוא נמחק.

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

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

מהנדסי תוכנה, מהנדסי Site Reliability ואופרטורים של מערכות

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

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

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

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

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

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

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

מידע נוסף על המיקומים הזמינים ב-Cloud KMS מופיע במאמר מיקומים ב-Cloud KMS.

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

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

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

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

מיקום של מפתחות

בחלק מהתחומים יש צורך במפתחות קריפטוגרפיים שנמצאים במיקום ספציפי. ל-Cloud KMS יש תנאים למיקום נתונים שכוללים התחייבויות לגבי מיקום הנתונים. כמו שצוין בקטע מיקוד לפי אזורים של משאבי 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 מתומצת בטבלה הבאה:

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

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

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

זמינות גבוהה

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

אימות והרשאה

ב-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
  • בדיקה אם אתם נמצאים ברשימת ההיתרים של אזורים רלוונטיים בענן הפרטי

ניהול מכסות

ל-Cloud KMS יש מגבלות שימוש על בקשות שנשלחות לשירות, שנקראות מכסות. ב-Cloud KMS קיימות המכסות האלה:

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

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

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

מומלץ להביא בחשבון את הדוגמאות הבאות:

  • כדי להפעיל פענוח באמצעות מפתח תוכנה ב-asia-northeast1, נדרשת יחידה אחת (גלובלית) של מכסה של בקשות קריפטוגרפיות.
  • כדי ליצור מפתח HSM ב-us-central1, נדרשת יחידה אחת של מכסה של בקשות לכתיבה בלי מכסת HSM.
  • כדי להפעיל הצפנה באמצעות מפתח EKM ב-europe, נדרשת יחידה אחת (גלובלית) של מכסה של בקשות קריפטוגרפיות ויחידה אחת של מכסה של בקשות KMS חיצוניות ב-europe.

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

רישום ביומן

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

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

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

יומני Access Transparency

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

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

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

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

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

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

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

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

מעקב

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

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

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