התוכן הזה עודכן לאחרונה בינואר 2025, והוא מציג את המצב הקיים במועד כתיבתו. מדיניות האבטחה ומערכות האבטחה של Google עשויות להשתנות בעתיד, מכיוון שאנחנו כל הזמן פועלים לשיפור ההגנה על הלקוחות שלנו.
במאמר הזה מתואר איך Cloud Key Management Service (Cloud KMS) מספק שירותי ניהול מפתחות ב Google Cloud להצפנת נתונים במנוחה.Google Cloud העיקרון הבסיסי של Cloud KMS הוא ש Google Cloud הנתונים של הלקוחות נמצאים בבעלותם, והם אלו שצריכים לקבוע את אופן השימוש בהם.
כשמאחסנים נתונים באמצעות Google Cloud, הנתונים נמצאים במצב הצפנה במנוחה כברירת מחדל. כשמשתמשים בפלטפורמת Cloud KMS, מקבלים שליטה רבה יותר על אופן ההצפנה במנוחה של הנתונים ועל אופן הניהול של מפתחות ההצפנה.
המאמר הזה מתמקד בתפעול הפנימי של פלטפורמת Cloud KMS. האפשרויות האלה עוזרות להגן על המפתחות ועל מידע סודי נוסף שאתם שומרים ב- Google Cloud. המאמר מיועד למקבלי החלטות טכניות שזקוקים למידע על הארכיטקטורה, התשתית והמאפיינים של Cloud KMS. ההנחה במאמר הזה היא שיש לכם הבנה בסיסית במושגי הצפנה ובארכיטקטורות ענן.
מפתחות ב Google Cloud
בטבלה הבאה מתוארים הסוגים השונים של מפתחות ב- Google Cloud.
| סוג המפתח | Cloud KMS Autokey | Cloud KMS בניהול הלקוח (ידני) | Google-owned and Google-managed encryption key (ברירת המחדל של Google להצפנה) |
|---|---|---|---|
הרשאה לצפייה במטא-נתונים חשובים |
כן |
כן |
לא |
בעלות על מפתחות1 |
לקוח/ה |
לקוח/ה |
|
יצירה והקצאה של מפתחות מתבצעות באופן אוטומטי. יש תמיכה מלאה בשליטה ידנית של הלקוח. |
לקוח, שליטה ידנית בלבד |
||
תמיכה בדרישות רגולטוריות לגבי מפתחות בניהול הלקוח |
כן |
כן |
לא |
שיתוף מפתחות |
ייחודיים ללקוח |
ייחודיים ללקוח |
בדרך כלל, נתונים מכמה לקוחות מוגנים באמצעות מפתחות הצפנה משותפים (KEK). |
שליטה ברוטציית מפתחות |
כן |
כן |
|
כן |
כן |
לא | |
כן |
כן |
לא |
|
הפרדה לוגית של נתונים באמצעות הצפנה |
כן |
כן |
|
תמחור |
משתנה | חינם |
1 הבעלים של המפתח מציין למי יש זכויות על המפתח. הגישה של Google למפתחות שבבעלותכם מוגבלת מאוד או לא קיימת.
2 ניהול המפתחות כולל את המשימות הבאות:
- יוצרים מפתחות.
- בוחרים את רמת ההגנה של המפתחות.
- הקצאת סמכות לניהול המפתחות.
- שליטה בגישה למפתחות.
- שליטה בשימוש במפתחות.
- הגדרה ושינוי של תקופת הרוטציה של המפתחות, או הפעלה של רוטציה של מפתחות.
- משנים את הסטטוס של המפתח.
- השמדת גרסאות של מפתחות.
3 שליטה במקשים פירושה הגדרת אמצעי בקרה על סוג המקשים ועל אופן השימוש בהם, זיהוי שונות ותכנון פעולות מתקנות אם יש צורך בכך. אתם יכולים לשלוט במפתחות, אבל להעביר את ניהול המפתחות לצד שלישי.
עקרונות 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 מספקת הפרדה לוגית של נתונים באמצעות הצפנה. הפרדה לוגית של נתונים פירושה שבעלי הנתונים לא משתפים מפתחות הצפנה (KEK ו-DEK).
מקורות ואפשרויות ניהול של מפתחות קריפטוגרפיים
פלטפורמת Cloud KMS מאפשרת לכם לנהל מפתחות קריפטוגרפיים בשירות ענן מרכזי לשימוש ישיר או לשימוש של אפליקציות ומשאבים אחרים בענן.
התיק Google Cloud כולל את המפתחות הבאים:
ברירת מחדל להצפנה: כל הנתונים שמאוחסנים ב-Google מוצפנים בשכבת האחסון באמצעות אלגוריתם תקן ההצפנה המתקדם (AES) AES-256. אנחנו יוצרים ומנהלים את המפתחות להצפנה שמוגדרים כברירת המחדל, וללקוחות אין גישה למפתחות או אפשרות לשלוט בניהול וברוטציה שלהם. יכול להיות שמפתחות ההצפנה שמוגדרים כברירת מחדל ישותפו עם לקוחות. אפשר לקרוא מידע נוסף במאמר ברירת המחדל להצפנה במנוחה.
Cloud KMS עם מפתחות שמוגנים על ידי תוכנה: אתם יכולים לשלוט במפתחות שנוצרו ב-Cloud KMS. הקצה העורפי של תוכנת Cloud KMS מספק גמישות להצפנת הנתונים או לחתימה עליהם באמצעות מפתח סימטרי או אסימטרי שנמצא בשליטתכם.
Cloud KMS עם מפתחות שמוגנים על ידי חומרה (Cloud HSM): באמצעות Cloud KMS עם הקצה העורפי Cloud HSM תוכלו להיות הבעלים של המפתחות שנוצרו ונשמרו במודולים של אבטחת חומרה בבעלות ובהפעלה של Google (HSMs). אם אתם צריכים מפתח שמוגן באמצעות חומרה, תוכלו להשתמש בקצה העורפי Cloud HSM כדי לוודא שהמפתחות שלכם בשימוש רק ב-HSMs שאושרו באישור FIPS 140-2 ברמה 3. אפשר להקצות מפתחות שמוגנים על ידי חומרה בשיטה ידנית שדורשת מנהל Cloud KMS, או באופן אוטומטי באמצעות Cloud KMS Autokey. Autokey מאפשרת להפוך לאוטומטיים את תהליכי הקצאת המפתחות וההקצאה של מפתחות הצפנה בניהול הלקוח (CMEK). כדי להשתמש במפתחות HSM רגילים, אדמין KMS צריך ליצור את המפתחות לפי בקשה.
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, להשתמש בהם, לבצע רוטציה שלהם ולהשמיד אותם. כשמשתמשים ב-CMEK עם Google Cloud שירותים, הגישה למפתחות והמעקב אחריהם מנוהלים בשבילכם.
הצפנה וניהול מפתחות ב-Google
בקטע הזה מוגדרים כמה מהמונחים של ניהול מפתחות בהקשר של התשתית הרב-שכבתית של Google לניהול מפתחות.
מפתחות, גרסאות של מפתחות ואוספי מפתחות
בתרשים שכאן מוצגים קיבוצים של מפתחות, אוספי מפתחות ומפתחות שיש להם גרסה ראשית אחת וכמה גרסאות קודמות.
המושגים שמוצגים בתרשים שלמעלה:
מפתח: אובייקט בעל שם שמייצג מפתח קריפטוגרפי שנמצא בשימוש למטרה ספציפית. הביטים שמשמשים בפועל לביצוע פעולות קריפטוגרפיות נקראים חומר המפתח, והם יכולים להשתנות עם הזמן כשיוצרים גרסאות חדשות של המפתח. אפשר להקצות מדיניות הרשאות ב-IAM ברמת המפתח בהיררכיית המשאבים.
המטרה של המפתח ושל מאפיינים אחרים שלו מחוברים ומנוהלים באמצעות המפתח, לכן הוא האובייקט החשוב ביותר להבנת השימוש ב-KMS.
Cloud KMS תומך גם במפתחות אסימטריים וגם במפתחות סימטריים. מפתח סימטרי משמש ליצירה או לתיקוף של חתימות MAC או להצפנה סימטרית כדי להגן על אוסף נתונים. לדוגמה, שימוש ב-AES-256 במצב GCM כדי להצפין בלוק של טקסטים ללא הצפנה. אפשר להשתמש במפתח אסימטרי להצפנה אסימטרית או ליצירת חתימות אסימטריות. תוכלו לקרוא מידע נוסף במאמר מטרות ואלגוריתמים נתמכים.
אוסף מפתחות: קיבוץ של מפתחות למטרות ארגוניות. אוסף מפתחות שייך ל Google Cloud פרויקט ונמצא במיקום ספציפי. המפתחות יורשים את מדיניות ההרשאות מאוסף המפתחות שהם שייכים לו. הקיבוץ של מפתחות עם ההרשאות הרלוונטיות באוסף מפתחות מאפשר להעניק, לבטל או לשנות הרשאות למפתחות האלה ברמת אוסף המפתחות, בלי שיהיה צורך לבצע פעולה לכל מפתח בנפרד. אוספי המפתחות נוחים וקלים לסיווג, אבל אם הקיבוץ של אוספי המפתחות לא שימושי לכם, תוכלו לנהל את ההרשאות ישירות במפתחות. תגים מאפשרים להגדיר תנאי לאישור או לדחייה של כללי מדיניות אם תג ספציפי מצורף או לא מצורף למשאב. אפשר להוסיף תגים ברמת אוסף המפתחות, בהיררכיית המשאבים.
כדי למנוע התנגשויות בין שמות של משאבים, אי אפשר למחוק אוסף מפתחות או מפתח. למפתחות ולאוספי המפתחות אין עלויות שניתנות לחיוב וגם לא מגבלות מכסה, ולכן אין להם השפעה על העלויות ועל מגבלות הייצור.
מטא-נתונים של מפתח: שמות משאבים, מאפיינים של משאבי KMS כמו מדיניות הרשאות, סוג מפתח, גודל מפתח, מצב מפתח וכל הנתונים שנובעים ממפתחות ומאוספי מפתחות.
גרסת מפתח: חומר המפתח שמשויך למפתח בשלב כלשהו. גרסת המפתח היא המשאב שמכיל בפועל את חומר המפתח. הגרסאות ממוספרות ברצף, החל מגרסה 1. כשמבצעים רוטציה למפתח, נוצרת גרסת מפתח חדשה עם חומר מפתח חדש. לאותו מפתח לוגי יכולות להיות כמה גרסאות לאורך זמן, וכתוצאה מכך הנתונים שלכם מוצפנים באמצעות גרסאות מפתח שונות. למפתחות סימטריים יש גרסה ראשית. כברירת מחדל, הגרסה הראשית משמשת להצפנה. כשמבצעים פענוח ב-Cloud KMS באמצעות מפתחות סימטריים, גרסת המפתח שנחוצה לביצוע הפענוח מזוהה באופן אוטומטי.
היררכיית מפתחות
הדיאגרמה הבאה ממחישה את היררכיית המפתחות המרכזית ואת הצפנת המעטפות עבור Cloud KMS ומאגר המפתחות הפנימי של Google. הצפנת מעטפה היא תהליך ההצפנה של מפתח אחד באמצעות מפתח אחר כדי לשמור אותו באופן מאובטח או לשדר אותו בערוץ לא מהימן. כל המפתחות בתרשים הזה הם מפתחות סימטריים.
בהיררכיית המפתחות, מפתח להצפנת נתונים (DEK) מצפין את מקטעי הנתונים. מפתח להצפנת מפתחות הצפנה (KEK) משמש להצפנה או לאריזה של ה-DEK. כל האפשרויות בפלטפורמת Cloud KMS (תוכנה, חומרה ונקודות קצה עורפי חיצוניות) מאפשרות לכם לשלוט ב-KEK. ה-KEK מאוחסנים ב-Cloud KMS. חומר המפתח אף פעם לא יוצא מגבולות המערכת של Cloud KMS.
במפתחות שמוגנים באמצעות תוכנה, מפתח מאסטר של KMS ספציפי למיקום מצפין את ה-KEK. מפתח המאסטר של KMS מאוחסן במאגר המפתחות. לכל מיקום ב-Cloud KMS יש ב-Keystore מפתח מאסטר של KMS. כל שרת Cloud KMS מאחזר עותק של מפתח המאסטר של KMS במהלך ההפעלה כתוצאה מיחסי תלות חזקים, ועותק חדש של מפתח המאסטר של KMS מאוחזר מדי יום. מפתח המאסטר של KMS מוצפן מחדש באופן שוטף באמצעות מפתח המאסטר של מאגר המפתחות ב-Keystore. מפתח המאסטר של מאגר המפתחות מוגן באמצעות מפתח המאסטר ברמה הבסיסית של מאגר המפתחות.
במפתחות שמוגנים על ידי חומרה, מפתח אריזה של HSM ספציפי למיקום מצפין את ה-KEK, ואז מפתח האריזה של HSM מוצפן באמצעות מפתח המאסטר של KMS. מידע נוסף זמין במאמר בנושא יצירת מפתחות. למפתחות חיצוניים, מפתח אריזה של EKM מצפין את ה-DEK הארוז, ואז מפתח האריזה של EKM מוצפן באמצעות מפתח המאסטר של KMS.
Cloud KMS משתמש ב-Keystore – שירות ניהול המפתחות (KMS) הפנימי של Google – כדי לארוז מפתחות בהצפנת Cloud KMS. Cloud KMS משתמש באותו Root of Trust של Keystore. תוכלו לקרוא מידע נוסף על Keystore בקטע ניהול מפתחות במאמר בנושא הצפנה במנוחה.
מגבלות תפעוליות
Cloud KMS פועל במסגרת המגבלות הבאות:
- פרויקט: משאבי Cloud KMS שייכים לפרויקטGoogle Cloud, בדומה לכל המשאבים האחרים ב- Google Cloud. מפתחות Cloud KMS יכולים להיות בפרויקט שונה מהפרויקט שבו נמצאים הנתונים שהמפתחות מגנים עליהם. אם שומרים את המפתחות באותו פרויקט שבו נמצאים הנתונים שהמשאבים מגנים עליהם, אפשר להסיר את תפקיד הבעלים מהפרויקט כדי לאפשר פעולה בהתאם לשיטות המומלצות להפרדת סמכויות בין אדמינים של מפתחות לבין אדמינים של נתונים.
- מיקומים: בתוך הפרויקט, משאבי Cloud KMS נוצרים במיקום. למידע נוסף על מיקומים תוכלו לעיין במאמר מיקום גיאוגרפי ואזורים.
- עקביות: ב-Cloud KMS מועברות הפעולות במפתחות, באוספי מפתחות ובגרסאות של מפתחות באמצעות מודל עקביות חזק או מודל עקביות הדרגתי. תוכלו לקרוא מידע נוסף במאמר עקביות של משאבי Cloud KMS.
מפתחות הצפנה בניהול הלקוח
כל נתוני הלקוחות שמאוחסנים במצב מנוחה מוצפנים ב- Google Cloud כברירת מחדל, והמפתחות שמשמשים להצפנה מנוהלים על ידי Google. במוצרים תואמים Google Cloud שבהם תוכן הלקוח נשמר באופן קבוע (לדוגמה, Cloud Storage), אפשר להשתמש במקום זאת ב-Cloud KMS כדי לנהל מפתחות הצפנה בניהול הלקוח (CMEK). מפתחות CMEK הם מפתחות הצפנה שנמצאים בבעלותכם ואפשר להשתמש בהם עם מפתחות חיצוניים, מפתחות שמוגנים על ידי תוכנה ומפתחות שמוגנים על ידי חומרה.
מפתחות CMEK מאפשרים לכם לקבל שליטה רבה יותר על המפתחות שמשמשים להצפנת נתונים במנוחה בשירותים תואמים Google Cloud , ומספקים גבול קריפטוגרפי מסביב לנתונים שלכם. אתם יכולים לנהל את CMEK ישירות ב-Cloud KMS, או להשתמש ב-Autokey כדי להקצות ולספק אותם באופן אוטומטי. כששירות משתמש ב-CMEK, עומסי העבודה יכולים לגשת למשאבים באותו אופן כמו כשמשתמשים רק בהצפנה שמוגדרת כברירת מחדל.
Cloud KMS מאפשר לכם לשלוט בהיבטים רבים של המפתחות (כמו יצירה, הפעלה, השבתה, ביצוע רוטציה והשמדה של מפתחות) ולנהל את ההרשאות המתאימות ב-IAM. כדי לאכוף את הפרדת הסמכויות הרצויה, שירות Cloud KMS כולל כמה תפקידי IAM מוגדרים-מראש עם הרשאות והגבלות ספציפיות, שאפשר להעניק למשתמשים ולחשבונות שירות ספציפיים.
מכיוון ש-Cloud KMS משתמש בהצפנת מעטפת, מפתח CMEK הוא מפתח KEK שמצפין את מפתחות ה-DEK. מידע נוסף זמין במאמר בנושא היררכיית מפתחות.
רוטציית מפתחות CMEK פועלת באופן שונה בהתאם לסוג המשאב שהמפתח מגן עליו. מומלץ להביא בחשבון את הדוגמאות הבאות:
- ב-Spanner, גרסה חדשה של מפתח מצפינה מחדש את ה-DEK.
- בסוגי משאבים אחרים, כמו קטגוריות של Cloud Storage, רק משאבים חדשים שנוצרו מוצפנים באמצעות גרסת המפתח החדשה, כלומר גרסאות שונות של המפתח מגינות על קבוצות נתונים שונות.
- בתרחישים מסוימים, צריך ליצור מחדש את משאב הענן עם גרסת המפתח החדשה. לדוגמה, כברירת מחדל, BigQuery לא מבצע רוטציה אוטומטית למפתח הצפנה של טבלה כשמתבצעת רוטציה של מפתח Cloud KMS שמשויך לטבלה. בטבלאות BigQuery הקיימות ממשיכים להשתמש בגרסת המפתח שבאמצעותה הן נוצרו.
מידע נוסף על רוטציית מפתחות זמין במסמכי התיעוד של כל מוצר.
מדיניות הארגון ל-CMEK מאפשרת לכם לשלוט בצורה טובה יותר על האופן שבו אתם משתמשים ב-CMEK בפרויקטים שלכם. בעזרת כללי המדיניות האלה תוכלו לשלוט בשירותים ובפרויקטים שכוללים מפתחות שמותרים לשימוש ב-CMEK, וברמת ההגנה של המפתחות.
Google Cloud תומך ב-CMEK לשירותים רבים, כולל Cloud Storage, BigQuery ו-Compute Engine. במסמך הזה מפורטת הרשימה המלאה של שירותים עם שילובי CMEK ושירותים שתואמים ל-CMEK. Google ממשיכה להשקיע בשילוב של CMEK במוצרים אחרים של Google Cloud Google.
Cloud KMS Autokey
Autokey מאפשר לייעל את תהליך הקצאת ההרשאות ל-CMEK. במהלך תהליך הקצאת CMEK ידני, אדמין של Cloud KMS צריך לתכנן את סוגי מחזיקי המפתחות, המפתחות וחשבונות השירות לפני שהם נדרשים, ולתאם עם המפתחים את הקצאת המפתחות. ב-Autokey, האדמין של Cloud KMS מאציל את הסמכות שלו לסוכן השירות של Cloud KMS בפרויקט. כשמפעילים את Autokey, מפתח יכול לבקש מפתח מ-Cloud KMS, וסוכן השירות מספק את המפתח המתאים למטרה של המפתח. עם Autokey, המפתחות זמינים על פי דרישה, הם עקביים ועומדים בסטנדרטים המקובלים בתעשייה.
Autokey מספקת ומקצה מחזיקי מפתחות, מפתחות וחשבונות שירות לפי דרישה, כשמפתחים יוצרים את משאבי הענן האלה, תוך שמירה על הפרדה בין תפקידים. הקצאה והקצאת הרשאות למפתחות מתבצעות בהתאם לשיטות המומלצות בתחום ולאבטחת נתונים, כולל:
- רמת ההגנה של HSM: המפתחות שנוצרו באמצעות Autokey הם תמיד מפתחות HSM, ולכן הם מאוחסנים בקצה העורפי של Cloud HSM. מדובר במפתחות הצפנה מסוג AES-256 GCM.
- הפרדת תפקידים: כדי לשמור על הפרדת תפקידים, הזהויות שיכולות להשתמש במפתח כדי להצפין ולפענח שונות מהזהויות שמנהלות את המפתח (כולל הרוטציה, ההשמדה או שינוי המצב שלו).
- רוטציית מפתחות: המפתחות עוברים רוטציה מדי שנה.
- מיקום משותף של המפתח עם המשאבים: המפתח נמצא באותו מיקום כמו המשאב שהמפתח מגן עליו.
- ספציפיות של המפתח: הספציפיות של המפתח מתאימה לסוג המשאב שהמפתח מגן עליו, על בסיס כל סוג משאב. המשמעות של ספציפיות היא שלא צריך לבדוק באופן ידני את סוגי המשאבים של כל שירות ולהחליט כמה מכל סוג משאב מפתח יחיד צריך להגן עליו.
מפתחות שמבוקשים באמצעות Autokey פועלים באופן זהה למפתחות אחרים של Cloud HSM עם אותן הגדרות. Autokey מפשט את השימוש ב-Terraform כי הוא מבטל את הצורך בהרצת תשתית כקוד עם הרשאות מורחבות ליצירת מפתחות. Autokey זמין בכלGoogle Cloud המיקומים שבהם Cloud HSM זמין.
התכונה Autokey זמינה רק למשאבים ספציפיים Google Cloud . מידע נוסף מופיע במאמר סקירה כללית על Autokey.
הארכיטקטורה והרכיבים של פלטפורמת Cloud KMS
פלטפורמת Cloud KMS תומכת באלגוריתמים קריפטוגרפיים רבים, ומספקת שיטות להצפנה ולחתימה דיגיטלית באמצעות מפתחות חיצוניים, מפתחות שמוגנים בחומרה ומפתחות שמוגנים בתוכנה. פלטפורמת Cloud KMS משולבת עם ניהול זהויות והרשאות גישה (IAM) ועם יומני ביקורת של Cloud, כדי שתוכלו לנהל את ההרשאות במפתחות נפרדים ולבדוק את אופן השימוש בהם.
בתרשים הקודם מוצגים הרכיבים העיקריים בפלטפורמת 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 מאפשר להשתמש במפתחות תוכנה, במפתחות חומרה או במפתחות חיצוניים. אתם יכולים ליצור ולנהל מפתחות שמוגנים על ידי תוכנה ומפתחות שמוגנים על ידי חומרה באמצעות נקודת הקצה של שירות Cloud KMS. מפתחות מבוססי תוכנה ומפתחות מבוססי חומרה נעזרים באמצעי ההגנה היתירים לגיבוי של 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.
אבטחה של חומרי מפתחות
ב-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 מבצע את הטרנזקציה שיוצרת את המפתח, ואחרי ששכבת האחסון מאשרת את יצירת המפתח.
מערכות עורפיות (backend) של מפתחות ורמות הגנה
כשיוצרים מפתח באמצעות 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 למפתחות תוכנה, במסגרת הטמעת BoringSSL של Google בכל העבודות הקריפטוגרפיות הקשורות. למודול BoringCrypto יש אישור 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 HSM באמצעות אותן ספריות לקוח ואותו ממשק API שמשמשים גם את Cloud KMS. אפשר לקרוא מידע נוסף על שירות Cloud HSM במאמר ארכיטקטורת Cloud HSM.
Cloud EKM: רמת הגנה EXTERNAL
שירות Cloud EKM מאפשר להצפין נתונים באמצעות מפתחות הצפנה מחוץ לענן שנשארים בשליטתכם.
מפתחות עם רמות ההגנה EXTERNAL ו-EXTERNAL_VPC מאוחסנים ומנוהלים במערכת חיצונית לניהול מפתחות. מידע נוסף זמין במאמר תרשימי עזר לארכיטקטורות של Cloud EKM.
תהליך יצירת המפתח
בתרשים הבא מוצג תהליך יצירת המפתחות עבור סוגי ה-backend השונים של המפתחות ורמות ההגנה השונות.
תהליך יצירת המפתחות כולל את השלבים הבאים:
- משתמש שולח בקשה ל-Cloud KMS ליצור מפתח באמצעות Cloud KMS API. הבקשה הזו כוללת את רמת ההגנה (אם המפתח מוגן על ידי תוכנה, חומרה או גורם חיצוני).
- Cloud KMS מאמת את זהות המשתמש ואם יש לו הרשאה ליצור את המפתח.
- המפתח נוצר באופן הבא:
- למפתחות שמוגנים על ידי תוכנה, Cloud KMS יוצר את מפתח הלקוח.
- לגבי מפתחות שמוגנים באמצעות חומרה, Cloud KMS שולח בקשה ל-Cloud HSM. Cloud HSM שולח את הבקשה ל-HSM כדי ליצור מפתח חדש. מודול ה-HSM יוצר מפתח לקוח ומצפין (אורז) את המפתח הזה באמצעות מפתח האריזה האזורי של ה-HSM. Cloud HSM שולח את המפתח הארוז בחזרה ל-Cloud KMS.
- לגבי מפתחות חיצוניים, Cloud KMS שולח בקשה ל-Cloud EKM. Cloud EKM שולח את הבקשה למנהל המפתחות החיצוני כדי ליצור מפתח חדש. EKM יוצר מפתח חדש ומצפין אותו באמצעות מפתח האריזה של EKM. Cloud EKM שולח את המפתח הארוז בחזרה ל-Cloud KMS.
- Cloud KMS מצפין את המפתח הארוז של הלקוח באמצעות מפתח המאסטר של KMS ושולח אותו לאחסון במאגר הנתונים של KMS.
- Cloud KMS שולח למשתמש תגובת הצלחה עם מזהה ה-URI המלא של גרסת המפתח.
ייבוא מפתחות
תוכלו לייבא לסביבת הענן מפתחות משלכם שיצרתם בארגון או ב-EKM. לדוגמה, יכול להיות שאתם כפופים לדרישה רגולטורית ליצירת מפתחות שמשמשים להצפנה של נתוני הענן, בסביבה מסוימת או באופן מסוים. ייבוא מפתחות מאפשר לייבא את המפתחות האלה ולעמוד בדרישות הרגולטוריות. תוכלו גם לייבא מפתחות אסימטריים כדי להרחיב את יכולות החתימה שלכם בענן.
כחלק מייבוא המפתחות, Cloud KMS יוצר מפתח אריזה ציבורי, שהוא זוג מפתחות ציבורי/פרטי, באמצעות אחת משיטות הייבוא הנתמכות. הצפנת חומר המפתח באמצעות מפתח האריזה מספקת הגנה על חומר המפתח במעבר.
כדי להצפין את המפתח לטובת ייבוא אצל הלקוח, משתמשים במפתח האריזה הציבורי. המפתח הפרטי שתואם למפתח הציבורי הזה נשמר ב- Google Cloud ומשמש לפתיחת האריזה של המפתח אחרי שהוא מגיע לפרויקטGoogle Cloud . שיטת הייבוא שתבחרו קובעת את האלגוריתם שישמש ליצירת מפתח האריזה. אחרי שמסתיימת האריזה של חומר המפתח, תוכלו לייבא אותו למפתח חדש או לגרסת מפתח חדשה ב-Cloud KMS.
אתם יכולים להשתמש במפתחות מיובאים בעזרת רמת ההגנה HSM או SOFTWARE. ב-Cloud HSM, החלק של המפתח הפרטי בתוך מפתח האריזה זמין רק ב-Cloud HSM. הגבלת החלק של המפתח הפרטי רק ל-Cloud HSM מונעת מ-Google לפתוח את האריזה של חומר המפתח מחוץ ל-Cloud HSM.
מחזור החיים של בקשה ב-Cloud KMS
בקטע הזה מתואר מחזור החיים של בקשה ב-Cloud KMS, כולל דיון בנושא השמדה של חומר מפתח. בתרשים שכאן מוצג לקוח שמבקש גישה למכונות של שירות Cloud KMS ב-us-east1 וב-us-west1, והאופן שבו מתבצע ניתוב של הבקשות באמצעות ממשק הקצה של Google (GFE).
השלבים במחזור החיים כוללים את אלה:
- עובדים בארגון או משימה שפועלת בשם הארגון יוצרים בקשה לשירות Cloud KMS – https://cloudkms.googleapis.com. ב-DNS מתבצעת התאמת נתונים (resolve) של הכתובת הזו לכתובת IP של ה-GFE שמנותבת בשיטת anycast.
- שירות GFE מספק אירוח IP ציבורי של שם ה-DNS הציבורי שלו, הגנה מפני התקפת מניעת שירות (DoS) וסיום TLS. כשאתם שולחים בקשה, בדרך כלל היא מנותבת ל-GFE בקרבתכם בלי קשר למיקום היעד שלה. שירות GFE מטפל במשא ומתן ב-TLS (אבטחת שכבת התעבורה), ובעזרת כתובת ה-URL והפרמטרים של הבקשה, ה-GFE קובע איזה מאזן עומסי תוכנה גלובלי (Global Software Load Balancer – GSLB) ישמש לניתוב הבקשה.
- לכל אזור ב-Cloud KMS יש יעד GSLB נפרד. אם הבקשה מגיעה ל-GFE באזור
us-east1והבקשה שייכת ליעדus-west1, היא מנותבת בין מרכזי הנתוניםus-east1ו-us-west1. כל התקשורת בין מרכזי הנתונים מוצפנת במעבר באמצעות ALTS, שמאמת באופן הדדי את המשימות ב-GFE וב-Cloud KMS. - כשהבקשה מגיעה למשימה ב-Cloud KMS, בהתחלה היא מעובדת על ידי framework שמטפל בחלק גדול מהעבודה המשותפת לכלGoogle Cloud השירותים. ה-framework מאמת את החשבון ומבצע מספר בדיקות כדי לוודא את הפרטים הבאים:
- לחשבון יש פרטי כניסה תקפים ואפשר לאמת אותו.
- לפרויקט יש ממשק Cloud KMS API פעיל וחשבון תקף לחיוב.
- המכסה מספיקה כדי להריץ את הבקשה.
- החשבון נמצא ברשימת ההיתרים לשימוש באזור הרלוונטי שלGoogle Cloud .
- הבקשה לא נדחית על ידי VPC-Service Controls.
- לאחר שהבדיקות האלה עוברות בהצלחה, ה-framework מעביר את הבקשה ואת פרטי הכניסה ל-Cloud KMS. Cloud KMS מנתח את הבקשה כדי לקבוע לאילו משאבים צריך לגשת, ואז בודק דרך IAM אם המתקשר מורשה לבצע את הבקשה. IAM גם מציין אם לכתוב את אירוע הבקשה ביומני הביקורת. אם האפשרות הצדקות לגישה למפתחות מופעלת, תישלח לכם הודעה עם הצדקה, ותצטרכו לאשר אותה.
- אחרי שהבקשה מאומתת ומקבלת הרשאה, Cloud KMS קורא לקצוות העורפיים של מאגר הנתונים בתוך האזור כדי לאחזר את המשאב המבוקש. אחרי אחזור המשאב, חומר המפתח מפוענח ומוכן לשימוש.
- בעזרת חומר המפתח, Cloud KMS מבצע את הפעולה הקריפטוגרפית ומעביר את הגרסה הארוזה של המפתח לקצה העורפי של תוכנת Cloud KMS, לקצה העורפי של Cloud HSM או לקצה העורפי של Cloud EKM, בהתאם לרמת ההגנה על המפתח.
- כשהפעולה הקריפטוגרפית מסתיימת, התגובה מוחזרת לכם בערוץ מסוג GFE-to-KMS בדומה לשליחת הבקשה.
- כשהתגובה מוחזרת, 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 נמצאים 30 יום במצב של התקופה Scheduled for destruction (מחיקה עם יכולת שחזור) לפני שחומר המפתחות נמחק באופן לוגי מהמערכת. אפשר לשנות את משך הזמן הזה. תוכלו לקרוא מידע נוסף בקטע משך זמן משתנה של מצב Scheduled for destruction.
אמנם חומר המפתח מושמד, אבל אי אפשר למחוק מפתחות ואוספי מפתחות. אי אפשר למחוק גם גרסאות של מפתחות, אבל אפשר להשמיד חומר של גרסאות המפתחות כך שלא תהיה יותר אפשרות להשתמש במשאבים. למפתחות ולאוספי המפתחות אין עלויות שניתנות לחיוב ואין מגבלות מכסה, ולכן אין להם השפעה על העלויות ועל מגבלות הייצור.
אחרי שגרסת מפתח תוזמנה להשמדה, היא כבר לא זמינה לפעולות קריפטוגרפיות. במהלך תקופת ההמתנה למחיקה תוכלו לשחזר את גרסת המפתח כדי שהיא לא תושמד.
אם מחקתם בטעות מפתח מיובא, אפשר לייבא אותו מחדש. תוכלו לקרוא מידע נוסף בקטע ייבוא מחדש של מפתח שהושמד.
כדי להימנע ממחיקה של מפתח בטעות, מומלץ להשתמש בשיטות המומלצות הבאות:
- מגדירים את האילוץ משך הזמן המינימלי המתוזמן להשמדה לכל מפתח למשך זמן ארוך יותר. המגבלה הזו מגדירה את משך הזמן המינימלי של התקופה המתוזמנת להשמדה עבור מפתחות חדשים.
- אוכפים את האילוץ הגבלת השמדת מפתחות למפתחות מושבתים כדי שאפשר יהיה להשמיד רק מפתחות מושבתים. מידע נוסף מופיע במאמר בנושא דרישה להשבתת מפתחות לפני השמדה.
- ליצור תפקיד מותאם אישית ב-KMS שלא כולל את ההרשאה
cloudkms.cryptoKeyVersions.destroy. - להאריך את פרק הזמן שמצוין בשדה
destroy_scheduled_duration. לעקוב אחרי אירועי השמדה של מפתחות ולהגדיר התראות לגביהם, לדוגמה, יוצרים ב-Cloud Logging את המסנן:
resource.type="cloudkms_cryptokeyversion" protoPayload.methodName="DestroyCryptoKeyVersion"ליצור תהליכים להשבתה של המפתח לכמה ימים לפני שהוא נמחק.
יחסי תלות עם התשתית של 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 כוללת מדיניות לאבטחה ולאחסון נתונים, הגבלות גישה ואסטרטגיות לצמצום סיכונים שנועדו לשפר את האמינות, העמידות והזמינות תוך הגנה על חומר המפתח. בקטע הזה מתוארים מבנה התפעול של השירות, תחומי האחריות של חברי צוות התפעול, מנגנוני אימות ופרוטוקולים לביקורת ולרישום ביומן. הקטע הזה רלוונטי גם ליכולות של מפתחות שמוגנים בתוכנה ובחומרה.
מהנדסי תוכנה, site reliability engineers ואופרטורים של מערכות
מהנדסי התוכנה אחראים לשיתוף הפעולה עם בעלי עניין אחרים, למשל מנהלי מוצרים ומהנדסי 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 Google Cloud שתומכים ב-CMEK:
- לאזור יחיד ספציפי: מכיוון שהאזור של מפתח KMS שמנוהל על ידי הלקוח חייב תמיד להיות תואם לאזור של המשאב שעליו הוא מגן בשירות Google Cloud נתון, מובטחות תאימות ואכיפה של הגבלות המיקום על המפתחות והמשאבים באזור יחיד.
- במיקומים בשני אזורים או במספר אזורים: המשתמשים יכולים לבחור מיקום במספר אזורים שמוגדר על ידי Google למפתחות שלהם ולמשאבי Google CloudGoogle Cloud, כדי להבטיח תאימות של המיקום. כדי לוודא את המיקום הגיאוגרפי, צריך להקפיד שהאזורים במוצרים אחרים תואמים למיקום האזורי שנבחר ב-Cloud KMS.
המיקום של חומר מפתח ב-Cloud KMS מתומצת בטבלה הבאה:
| סוג האזור | במצב מנוחה, בשימוש |
|---|---|
| אזור יחיד | תושבים |
| בשני אזורים או במספר אזורים | תושבים באזורים שמרכיבים את המיקום בשני אזורים או במספר אזורים. |
מעקב אחרי מיקוד לפי אזורים
השירותים הפנימיים של Google למעקב אחרי נתונים עוקבים אחרי המיקום של מפתחות. Cloud KMS שולח התראות לחברי הצוות של SRE כשיש זיהוי של הגדרות שגויות שבוצעו בטעות, או כשחומר המפתח חוצה את גבולות האזור שהוגדר עבורו, מאוחסן באזור לא נכון או שהגישה אליו התבצעה מאזור שגוי.
זמינות גבוהה
שירות Cloud KMS יכול לעזור לכם לפשט את דרישות הזמינות בהתאם לאזורים שבחרתם. ככל שהמיקום יותר מפורט תצטרכו ליצור יותר יתירות. באפליקציות עם רמות זמינות גבוהות, כדאי להשתמש במיקומים במספר אזורים במקום לנסות ליצור מערכת רפליקציה למפתחות. צריך לאזן בין יכולות היתירות המובנות לבין צורכי חלוקת הנתונים שלכם לאזורים.
אימות והרשאה
ב-Cloud KMS אפשר להשתמש במגוון של מנגנוני אימות, למשל OAuth2, 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.
המאמרים הבאים
- למידע נוסף על Cloud KMS כדאי לעיין במשאבים הבאים:
- למידע על שימוש במפתחות הצפנה משלכם ב-Google Cloud, קראו את המאמר מפתחות הצפנה בניהול הלקוח (CMEK).
- למידע נוסף על אבטחת התשתית של Google, ראו סקירה כללית על תכנון האבטחה בתשתית של Google.