בדף הזה מפורטות שיטות מומלצות להגדרת הצפנה במנוחה באמצעות מפתחות הצפנה בניהול הלקוח (CMEK) במשאבי Google Cloud . המדריך הזה מיועד לאדריכלי ענן ולצוותי אבטחה, והוא כולל שיטות מומלצות והחלטות שצריך לקבל במהלך תכנון הארכיטקטורה של CMEK.
המדריך הזה מיועד למי שכבר מכיר את Cloud Key Management Service (Cloud KMS) ואת מפתחות הצפנה בניהול הלקוח, וקרא את הניתוח המעמיק של Cloud KMS.החלטות ראשוניות
ההמלצות בדף הזה מיועדות ללקוחות שמשתמשים במפתחות הצפנה בניהול הלקוח (CMEK) כדי להצפין את הנתונים שלהם. אם אתם לא בטוחים אם כדאי להשתמש במפתחות CMEK שנוצרו באופן ידני או אוטומטי כחלק מאסטרטגיית האבטחה שלכם, בחלק הזה מופיעות הנחיות שיעזרו לכם לקבל את ההחלטות הראשוניות האלה.
החלטה אם להשתמש בהצפנה באמצעות מפתח שמוגדר על ידי הלקוח (CMEK)
מומלץ להשתמש ב-CMEK כדי להצפין נתונים במנוחה בשירותי Google Cloudאם נדרשות לכם היכולות הבאות:
בעלות על מפתחות ההצפנה.
שליטה במפתחות ההצפנה וניהול שלהם, כולל בחירת מיקום, רמת הגנה, יצירה, בקרת גישה, רוטציה, שימוש והשמדה.
יוצרים חומר מפתח ב-Cloud KMS או מייבאים חומר מפתח שמנוהל מחוץ ל- Google Cloud.
הגדרת מדיניות לגבי המקומות שבהם אפשר להשתמש במפתחות.
מחיקה סלקטיבית של נתונים שמוגנים על ידי המפתחות שלכם במקרה של ביטול הרשאה או כדי לטפל באירועי אבטחה (מחיקה קריפטוגרפית).
יצירה ושימוש במפתחות ייחודיים ללקוח, כדי ליצור גבול קריפטוגרפי סביב הנתונים.
רישום ביומן של גישה אדמיניסטרטיבית וגישה לנתונים למפתחות הצפנה.
עמידה בתקנות קיימות או עתידיות שמחייבות את השימוש באחד מהיעדים האלה.
בחירה ביצירה ידנית או אוטומטית של מפתחות
במדריך הזה מפורטות שיטות מומלצות לקבלת החלטות שצריך לקבל כשמקצים מפתחות CMEK באופן עצמאי. Cloud KMS Autokey מקבל חלק מההחלטות האלה בשבילכם ומיישם באופן אוטומטי הרבה מההמלצות שבמדריך הזה. השימוש ב-Autokey פשוט יותר מאשר הקצאת מפתחות באופן עצמאי, והוא מומלץ אם המפתחות שנוצרו על ידי Autokey עומדים בכל הדרישות שלכם.
Autokey מקצה לכם מפתחות CMEK. למפתחות CMEK שמוקצים על ידי Autokey יש את המאפיינים הבאים:
- רמת הגנה: HSM.
- אלגוריתם: AES-256 GCM.
תקופת הרוטציה: שנה אחת.
אחרי שמפתח נוצר על ידי Autokey, אדמין של Cloud KMS יכול לערוך את תקופת הרוטציה מברירת המחדל.
- הפרדת תפקידים:
- לחשבון השירות של השירות מוענקות באופן אוטומטי הרשאות הצפנה ופענוח במפתח.
- הרשאות האדמין ב-Cloud KMS חלות כרגיל על מפתחות שנוצרו על ידי Autokey. אדמינים של Cloud KMS יכולים להציג, לעדכן, להפעיל או להשבית מפתחות שנוצרו על ידי Autokey, וגם להשמיד אותם. לאדמינים של Cloud KMS לא ניתנות הרשאות הצפנה ופענוח.
- מפתחי Autokey יכולים לבקש רק יצירה והקצאה של מפתחות. הם לא יכולים לראות את המפתחות או לנהל אותם.
- ספציפיות המפתח או גרנולריות: הגרנולריות של מפתחות שנוצרו על ידי Autokey משתנה בהתאם לסוג המשאב. פרטים ספציפיים לשירות על רמת הגרנולריות של המפתחות זמינים במאמר שירותים תואמים.
מיקום: Autokey יוצר מפתחות באותו מיקום שבו נמצא המשאב שרוצים להגן עליו.
אם אתם צריכים ליצור משאבים שמוגנים באמצעות CMEK במיקומים שבהם Cloud HSM לא זמין, אתם צריכים ליצור את ה-CMEK באופן ידני.
- מצב גרסת המפתח: מפתחות חדשים שנוצרו באמצעות Autokey נוצרים כגרסת המפתח הראשית במצב מופעל.
- שמות של אוספי מפתחות: כל המפתחות שנוצרים על ידי Autokey נוצרים באוסף מפתחות שנקרא
autokey. מחזיקי מפתחות בפרויקט Autokey נוצרים כשמפתח Autokey מבקש את המפתח הראשון במיקום נתון. מחזיק המפתחותautokeyנוצר בפרויקט המפתחות הייעודי אם משתמשים באחסון מפתחות בפרויקט ייעודי, או בפרויקט המשאבים אם משתמשים באחסון מפתחות באותו פרויקט. - מתן שמות למפתחות: מפתחות שנוצרו על ידי Autokey מקבלים שמות לפי המוסכמה הבאה:
PROJECT_NUMBER-SERVICE_SHORT_NAME-RESOURCE_TYPE_DESCRIPTOR_NAME-RANDOM_HEX - ייצוא מפתחות: כמו כל המפתחות ב-Cloud KMS, אי אפשר לייצא מפתחות שנוצרו על ידי Autokey.
- מעקב אחרי מפתחות: כמו כל המפתחות של Cloud KMS שמשמשים בשירותים משולבים של CMEK שתואמים למעקב אחרי מפתחות, המפתחות שנוצרו על ידי Autokey מתועדים בלוח הבקרה של Cloud KMS.
אם יש לכם דרישות שלא ניתן לעמוד בהן באמצעות מפתחות שנוצרו על ידי Autokey, כמו רמת הגנה שונה מ-HSM או שירותים שלא תואמים ל-Autokey, מומלץ להשתמש במפתחות CMEK שנוצרו באופן ידני ולא ב-Autokey.
עיצוב הארכיטקטורה של CMEK
כשמתכננים ארכיטקטורה של CMEK, צריך לקחת בחשבון את ההגדרה של המפתחות שבהם תשתמשו ואת האופן שבו המפתחות האלה מנוהלים. ההחלטות האלה משפיעות על העלות, על ההוצאות התפעוליות ועל הקלות שבה אפשר להטמיע יכולות כמו הצפנה מוחלטת.
בקטעים הבאים מפורטות המלצות לכל אחת מהאפשרויות.
שימוש בפרויקט מרכזי של מפתח CMEK לכל סביבה
מומלץ להשתמש בפרויקט מרכזי של מפתח CMEK לכל תיקיית סביבה. אל תיצרו משאבים שמוצפנים באמצעות CMEK באותו פרויקט שבו אתם מנהלים מפתחות Cloud KMS. הגישה הזו עוזרת למנוע שיתוף של מפתחות הצפנה בין סביבות שונות, ומאפשרת הפרדת תפקידים.
התרשים הבא ממחיש את המושגים האלה בעיצוב המומלץ:
- לכל תיקיית סביבה יש פרויקט מפתח Cloud KMS שמנוהל בנפרד מפרויקטים של אפליקציות.
- אוספי מפתחות ומפתחות של Cloud KMS מוקצים בפרויקט המפתחות של Cloud KMS, והמפתחות האלה משמשים להצפנת משאבים בפרויקטים של האפליקציה.
- כללי מדיניות של ניהול זהויות והרשאות גישה (IAM) מוחלים על פרויקטים או תיקיות כדי לאפשר הפרדת תפקידים. הגורם המרכזי שמנהל את מפתחות Cloud KMS בפרויקט המפתחות של Cloud KMS הוא לא אותו גורם מרכזי שמשתמש במפתחות ההצפנה בפרויקטים של האפליקציות.
יצירת אוספי מפתחות של Cloud KMS לכל מיקום
צריך ליצור אוספי מפתחות של Cloud KMS במיקומים שבהם אתם פורסים משאביGoogle Cloud מוצפנים באמצעות CMEK.
- משאבים אזוריים ומשאבים של תחום מוגדר חייבים להשתמש באוסף מפתחות וב-CMEK באותו אזור שבו נמצא המשאב או במיקום
global. במשאבים אזוריים ובמשאבים של תחום מוגדר אי אפשר להשתמש במחזיק מפתחות שכולל מספר אזורים, מלבדglobal. - במשאבים רב-אזוריים (כמו מערך נתונים ב-BigQuery באזור הגיאוגרפי הנרחב
us) צריך להשתמש במחזיק מפתחות וב-CMEK באותו אזור גיאוגרפי נרחב או באותו אזור כפול. במשאבים שמנוהלים במספר אזורים אי אפשר להשתמש במחזיק מפתחות אזורי. - במשאבים גלובליים צריך להשתמש באוסף מפתחות וב-CMEK במיקום
global.
אכיפה של מפתחות אזוריים היא חלק מאסטרטגיה של אחסון נתונים באזורים גיאוגרפיים. כשמחילים את השימוש באוספי מפתחות ובמפתחות באזור מוגדר, מחילים גם את הדרישה שהמשאבים יתאימו לאזור של אוסף המפתחות. להנחיות בנושא מיקום אחסון הנתונים, ראה שליטה במיקום הנתונים.
אם יש לכם עומסי עבודה שדורשים זמינות גבוהה או יכולות תוכנית התאוששות מאסון (DR) בכמה מיקומים, אתם צריכים להעריך אם עומס העבודה שלכם עמיד במקרה ש-Cloud KMS לא יהיה זמין באזור מסוים. לדוגמה, אי אפשר ליצור מחדש דיסק מתמשך של Compute Engine שהוצפן באמצעות מפתח Cloud KMS מאזור א' באזור ב' בתרחיש של התאוששות מאסון שבו אזור א' לא זמין. כדי לצמצם את הסיכון לתרחיש הזה, אפשר לתכנן הצפנה של משאב באמצעות מפתחות global.
מידע נוסף זמין במאמר בחירת סוג המיקום המתאים ביותר.
אם משתמשים ב-Cloud KMS Autokey, נוצרים אוספי מפתחות באותו מיקום של המשאבים שמוגנים.
בחירה של אסטרטגיה מרכזית לרמת הפירוט
גרנולריות מתייחסת להיקף ולטווח של השימוש המיועד בכל מפתח. לדוגמה, מפתח שמגן על כמה משאבים נחשב פחות גרנולרי ממפתח שמגן רק על משאב אחד.
מפתחות Cloud KMS שהוקצו באופן ידני ל-CMEK צריכים להיות מוקצים מראש לפני שיוצרים משאב שיוצפן באמצעות המפתח, כמו דיסק קשיח קבוע של Compute Engine. אתם יכולים ליצור מפתחות גרנולריים מאוד למשאבים ספציפיים, או ליצור מפתחות פחות גרנולריים לשימוש חוזר במשאבים באופן כללי יותר.
באופן כללי, מומלץ להשתמש באסטרטגיית הגרנולריות הבאה:
- כל מפתח מגן על משאבים במיקום אחד – לדוגמה,
us-central1. - כל מפתח מגן על משאבים בשירות או במוצר יחיד – לדוגמה, BigQuery.
- כל מפתח מגן על משאבים ב Google Cloud פרויקט אחד.
יכול להיות שההמלצה הזו לא תהיה אסטרטגיית הגרנולריות האידיאלית לארגון שלכם. ברוב הארגונים, האסטרטגיה הזו מספקת איזון טוב בין התקורה של תחזוקת מפתחות רבים עם רמת פירוט גבוהה לבין הסיכונים הפוטנציאליים של שימוש במפתחות עם רמת פירוט נמוכה יותר שמשותפים בין פרויקטים, שירותים או משאבים רבים.
מפתחות שנוצרו באמצעות Cloud KMS Autokey עומדים בהמלצה הזו.
אם אתם רוצים להשתמש באסטרטגיה אחרת של רמת פירוט, כדאי לשקול את היתרונות והחסרונות של דפוסים שונים:
מפתחות עם רמת פירוט גבוהה – לדוגמה, מפתח אחד לכל משאב בנפרד
- יותר שליטה בהשבתה בטוחה של גרסאות מפתח: להשבתה או להשמדה של גרסת מפתח שמשמשת להיקף מצומצם יש סיכון נמוך יותר להשפיע על משאבים אחרים מאשר להשבתה או להשמדה של מפתח משותף. זה גם אומר ששימוש במפתחות עם רמת פירוט גבוהה עוזר לצמצם את ההשפעה הפוטנציאלית של מפתח שנמצא בסיכון, בהשוואה לשימוש במפתחות עם רמת פירוט נמוכה.
- עלות: שימוש במפתחות גרנולריים מחייב שמירה על יותר גרסאות מפתחות פעילות בהשוואה לאסטרטגיה שמשתמשת במפתחות עם גרנולריות נמוכה יותר. התמחור של Cloud KMS מבוסס על מספר הגרסאות הפעילות של המפתחות, ולכן בחירה בגרסאות מפורטות יותר של מפתחות תוביל לעלויות גבוהות יותר.
- תקורה תפעולית: שימוש במפתחות עם רמת גרנולריות גבוהה עשוי לדרוש מאמץ ניהולי או כלים נוספים לאוטומציה כדי להקצות מספר גדול של משאבי Cloud KMS ולנהל את אמצעי בקרת הגישה לסוכני שירות, כך שהם יוכלו להשתמש רק במפתחות המתאימים. אם אתם צריכים מפתחות עם רמת פירוט גבוהה, יכול להיות ש-Autokey היא בחירה טובה לאוטומציה של הקצאת הרשאות. מידע נוסף על רמת הפירוט של מפתחות Autokey לכל שירות זמין במאמר שירותים תואמים.
מפתחות עם רמת פירוט נמוכה – לדוגמה, מפתח אחד לכל אפליקציה, לכל אזור ולכל סביבה:
- צריך להיזהר כשמשביתים גרסאות של מפתחות: השבתה או השמדה של גרסת מפתח שמשמשת להיקף רחב של פעולות דורשת יותר זהירות מאשר השבתה או השמדה של מפתח עם רמת גרנולריות גבוהה. לפני שמשביתים את גרסת המפתח הישנה, צריך לוודא שכל המשאבים שהוצפנו באמצעות גרסת המפתח הזו הוצפנו מחדש בצורה בטוחה באמצעות גרסת מפתח חדשה. בסוגים רבים של משאבים, אפשר לראות את השימוש במפתח כדי לזהות איפה נעשה שימוש במפתח. המשמעות היא גם ששימוש במפתחות עם רזולוציה נמוכה יכול להגדיל את ההשפעה הפוטנציאלית של פריצה למפתח, בהשוואה לשימוש במפתחות עם רזולוציה גבוהה.
- עלות: שימוש במפתחות עם רמת גרנולריות נמוכה יותר דורש יצירה של פחות גרסאות מפתח, והתמחור של Cloud KMS מבוסס על מספר גרסאות המפתח הפעילות.
- תקורה תפעולית: אתם יכולים להגדיר מראש מספר ידוע של מפתחות ולספק להם הרשאות, בלי להשקיע מאמץ רב כדי לוודא שמוגדרים אמצעי בקרת גישה מתאימים.
בחירת רמת ההגנה למפתחות
כשיוצרים מפתח, באחריותכם לבחור את רמת ההגנה שמתאימה לכל מפתח בהתאם לדרישות שלכם לגבי הנתונים ועומסי העבודה שמוצפנים באמצעות CMEK. השאלות הבאות יכולות לעזור לכם בתהליך ההערכה:
האם אתם צריכים את אחת מהיכולות של CMEK? אפשר לעיין ביכולות שמפורטות בקטע החלטה אם להשתמש ב-CMEK בדף הזה.
- אם כן, ממשיכים לשאלה הבאה.
- אם לא, מומלץ להשתמש ב Google הצפנה שמוגדרת כברירת מחדל.
האם אתם צריכים שחומר המפתח יישאר בתוך הגבול הפיזי של מודול אבטחה לחומרה (HSM)?
- אם כן, ממשיכים לשאלה הבאה.
- אם לא, מומלץ להשתמש ב-CMEK עם מפתחות שמגובים בתוכנה.
האם נדרש שחומר המפתח יאוחסן מחוץ ל- Google Cloud?
- אם כן, מומלץ להשתמש ב-CMEK עם Cloud External Key Manager.
- אם לא, ממשיכים לשאלה הבאה.
האם נדרשת לך שליטה אדמיניסטרטיבית באשכול ה-HSM ובידוד קריפטוגרפי מלקוחות אחרים? Google Cloud
- אם כן, מומלץ להשתמש ב-CMEK עם Single-tenant Cloud HSM (מפתחות שמגובים בחומרה עם דייר יחיד).
- אם לא, מומלץ להשתמש ב-CMEK עם Multi-tenant Cloud HSM (מפתחות שמגובים בחומרה עם ריבוי דיירים).
שימוש בחומר מפתח שנוצר על ידי Google Cloudכשזה אפשרי
החלק הזה לא רלוונטי למפתחות Cloud EKM.
כשיוצרים מפתח, צריך לאפשר ל-Cloud KMS ליצור את חומר המפתח בשבילכם או לייבא באופן ידני חומר מפתח שנוצר מחוץ ל- Google Cloud. אם אפשר, מומלץ לבחור באפשרות שנוצרה. האפשרות הזו לא חושפת את חומר המפתח הגולמי מחוץ ל-Cloud KMS, והיא יוצרת באופן אוטומטי גרסאות מפתח חדשות על סמך תקופת הרוטציה של המפתח שאתם בוחרים. אם אתם צריכים לייבא חומר מפתח משלכם, מומלץ לבדוק את השיקולים התפעוליים והסיכונים הבאים שקשורים לשימוש בגישת BYOK (הבאת מפתח משלכם):
- האם אפשר להטמיע אוטומציה כדי לייבא באופן עקבי גרסאות חדשות של מפתחות? זה כולל גם הגדרות של Cloud KMS להגבלת גרסאות מפתח לייבוא בלבד, וגם אוטומציה מחוץ ל-Cloud KMS כדי ליצור ולייבא חומר מפתח באופן עקבי. מה קורה אם האוטומציה לא מצליחה ליצור גרסה חדשה של המפתח בזמן הצפוי?
- איך בכוונתך לאחסן באופן מאובטח את חומר המפתח המקורי או להפקיד אותו בנאמנות?
- איך אפשר לצמצם את הסיכון להדלפה של חומר המפתח הגולמי בתהליך ייבוא המפתחות?
- מה תהיה ההשפעה של ייבוא מחדש של מפתח שהושמד בעבר כי חומר המפתח הגולמי נשמר מחוץ ל- Google Cloud?
- האם היתרון של ייבוא חומר המפתח בעצמכם מצדיק את התקורה התפעולית והסיכון המוגברים?
בחירת המטרה המרכזית והאלגוריתם המתאימים לצרכים שלכם
כשיוצרים מפתח, צריך לבחור את המטרה ואת האלגוריתם הבסיסי של המפתח. בתרחישי שימוש ב-CMEK, אפשר להשתמש רק במפתחות עם מטרה סימטרית ENCRYPT_DECRYPT. למפתח הזה תמיד מוקצה אלגוריתם GOOGLE_SYMMETRIC_ENCRYPTION, שמשתמש במפתחות של 256 ביט בתקן הצפנה מתקדם (AES-256) ב-Galois Counter Mode (GCM), עם מטא-נתונים פנימיים של Cloud KMS. כשמשתמשים ב-Autokey, ההגדרות האלה מופעלות באופן אוטומטי.
בתרחישי שימוש אחרים, כמו הצפנה מצד הלקוח, כדאי לעיין במטרות והאלגוריתמים הזמינים של המפתחות כדי לבחור את האפשרות שהכי מתאימה לתרחיש השימוש שלכם.
בחירת תקופה להצגת סבב מודעות
מומלץ להעריך את התקופה המתאימה לרוטציית מפתחות בהתאם לצרכים שלכם. התדירות של רוטציית מפתחות תלויה בדרישות של עומסי העבודה, בהתאם לרגישות או לתאימות. לדוגמה, יכול להיות שתידרשו לבצע רוטציית מפתחות לפחות פעם בשנה כדי לעמוד בתקני תאימות מסוימים, או שתבחרו בתקופת רוטציה תכופה יותר עבור עומסי עבודה רגישים במיוחד.
אחרי שמבצעים רוטציה למפתח סימטרי, הגרסה החדשה מסומנת כגרסת המפתח הראשית ומשמשת לכל הבקשות החדשות להגנה על מידע. הגרסאות הקודמות של המפתח נשארות זמינות לשימוש כדי לפענח נתונים שהוצפנו בעבר והוגנו באמצעות הגרסה הזו. כשמבצעים רוטציה למפתח, נתונים שהוצפנו באמצעות גרסאות קודמות של המפתח לא מוצפנים מחדש באופן אוטומטי.
רוטציית מפתחות תכופה עוזרת להגביל את מספר ההודעות שמוצפנות באמצעות אותה גרסת מפתח, וכך להפחית את הסיכון ואת ההשלכות של פריצה למפתח.
אם משתמשים ב-Autokey, מפתחות נוצרים עם תקופת רוטציית מפתחות של שנה כברירת מחדל. אפשר לשנות את תקופת הרוטציה של מפתחות אחרי שהם נוצרים.החלת אמצעי בקרה מתאימים לגישה
מומלץ להביא בחשבון את העיקרון של הרשאות מינימליות והפרדת תפקידים כשמתכננים את אמצעי בקרת הגישה. בקטעים הבאים מפורטות ההמלצות האלה.
החלת העיקרון של הרשאות מינימליות
כשמקצים הרשאה לניהול מפתחות CMEK, חשוב לפעול לפי העיקרון של הרשאות מינימליות ולהעניק רק את ההרשאות שנדרשות לביצוע המשימה. אנחנו ממליצים מאוד להימנע משימוש בתפקידים בסיסיים. במקום זאת, מומלץ להעניק תפקידים מוגדרים מראש ב-Cloud KMS כדי לצמצם את הסיכון לאירועי אבטחה שקשורים לגישה עם הרשאות מוגזמות.
Security Command Center vulnerability findings for IAM יכול לזהות באופן אוטומטי הפרות של העיקרון הזה ובעיות שקשורות אליו.תכנון הפרדת תפקידים
להקפיד על זהויות והרשאות נפרדות לאנשים שמנהלים את מפתחות ההצפנה ולאנשים שמשתמשים בהם. במסמך NIST SP 800-152 מוגדר הפרדה בין תפקידים: בין קצין ההצפנה שמפעיל ומנהל את השירותים של מערכת ניהול מפתחות קריפטוגרפיים, לבין משתמש שמשתמש במפתחות האלה כדי להצפין או לפענח משאבים.
כשמשתמשים ב-CMEK כדי לנהל הצפנה במנוחה בשירותי Google Cloud , תפקיד ה-IAM שמשמש להצפנת מפתחות מוקצה לסוכן השירות של שירות Google Cloud , ולא למשתמש ספציפי. לדוגמה, כדי ליצור אובייקטים בקטגוריה מוצפנת של Cloud Storage, משתמש צריך רק את תפקיד ה-IAM roles/storage.objectCreator, וסוכן השירות של Cloud Storage באותו פרויקט (לדוגמה, service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com) צריך את תפקיד ה-IAM roles/cloudkms.cryptoKeyEncrypterDecrypter.
בטבלה הבאה מפורטים תפקידי IAM שמשויכים בדרך כלל לפונקציות שונות:
| תפקיד IAM | תיאור | סיווג NIST SP 800-152 |
|---|---|---|
roles/cloudkms.admin |
ההרשאה מאפשרת גישה למשאבי Cloud KMS, למעט גישה לסוגי משאבים מוגבלים ולפעולות קריפטוגרפיות. | קצין קריפטוגרפיה |
roles/cloudkms.cryptoKeyEncrypterDecrypter |
מאפשר להשתמש במשאבי Cloud KMS רק בפעולות encrypt ו-decrypt. |
משתמש במערכת לניהול מפתחות קריפטוגרפיים |
roles/cloudkms.viewer |
מאפשרת פעולות ב-get וב-list. |
אדמין של ביקורת |
אכיפה עקבית של CMEK
בקטעים הבאים מתוארים אמצעי בקרה נוספים שיכולים לעזור בצמצום הסיכונים, כמו שימוש לא עקבי במפתחות או מחיקה או השמדה בשוגג.
אכיפה של שיעבודים בפרויקט
כדי למנוע מחיקה בטעות, מומלץ להגן על פרויקטים באמצעות מנעולים (גרסת Preview). כשמפעילים מנעול למניעת מחיקה של פרויקט, אי אפשר למחוק את הפרויקט של מפתח Cloud KMS עד שמסירים את המנעול.
דרישה לשימוש במפתחות CMEK
מומלץ לאכוף את השימוש ב-CMEK בסביבה שלכם באמצעות אילוצים של מדיניות הארגון.
אתם יכולים להשתמש בconstraints/gcp.restrictNonCmekServices כדי לחסום בקשות ליצירת סוגים מסוימים של משאבים בלי לציין מפתח CMEK.
נדרש משך זמן מינימלי שנקבע להשמדה
מומלץ להגדיר משך זמן מינימלי להשמדה מתוזמנת. השמדת מפתח היא פעולה בלתי הפיכה שעלולה לגרום לאובדן נתונים. כברירת מחדל, ב-Cloud KMS יש תקופה של 30 יום שנקראת scheduled for destruction (לפעמים soft delete period) לפני שחומר המפתחות נמחק באופן סופי. כך יש זמן לשחזר מפתח במקרה של השמדה בטעות. עם זאת, יכול להיות שמישהו עם תפקיד אדמין ב-Cloud KMS ייצור מפתח עם משך זמן של השמדה מתוזמנת של 24 שעות בלבד, וזה לא מספיק זמן כדי לזהות בעיה ולשחזר את המפתח. אפשר להגדיר את משך הזמן של ההשמדה המתוזמנת רק במהלך יצירת המפתח.