בדף הזה מפורטות שיטות מומלצות להגדרת הצפנה במצב מנוחה באמצעות מפתחות הצפנה בניהול הלקוח (CMEK) במשאבי Cloud de Confiance . המדריך הזה מיועד לאדריכלי ענן ולצוותי אבטחה, והוא כולל שיטות מומלצות והחלטות שצריך לקבל במהלך תכנון הארכיטקטורה של CMEK.
המדריך הזה מיועד למי שכבר מכיר את Cloud Key Management Service (Cloud KMS) ואת מפתחות הצפנה בניהול הלקוח.החלטה אם להשתמש בהצפנה באמצעות מפתח שמוגדר על ידי הלקוח (CMEK)
מומלץ להשתמש ב-CMEK כדי להצפין נתונים במנוחה בשירותי Cloud de Confianceאם נדרשות לכם היכולות הבאות:
בעלות על מפתחות ההצפנה.
שליטה וניהול של מפתחות ההצפנה, כולל בחירת מיקום, רמת הגנה, יצירה, בקרת גישה, רוטציה, שימוש והשמדה.
יוצרים חומר מפתח ב-Cloud KMS או מייבאים חומר מפתח שמנוהל מחוץ ל- Cloud de Confiance.
הגדרת מדיניות לגבי המקומות שבהם אפשר להשתמש במפתחות.
מחיקה סלקטיבית של נתונים שמוגנים על ידי המפתחות במקרה של ביטול הרשאה או כדי לטפל באירועי אבטחה (מחיקה קריפטוגרפית).
יצירה ושימוש במפתחות ייחודיים ללקוח, כדי ליצור גבול קריפטוגרפי סביב הנתונים.
רישום ביומן של גישה אדמיניסטרטיבית וגישה לנתונים למפתחות הצפנה.
עמידה בתקנות קיימות או עתידיות שמחייבות את השימוש באחד מהיעדים האלה.
עיצוב הארכיטקטורה של CMEK
כשמתכננים ארכיטקטורה של CMEK, צריך לקחת בחשבון את ההגדרה של המפתחות שבהם תשתמשו ואת האופן שבו המפתחות האלה מנוהלים. ההחלטות האלה משפיעות על העלות, על התקורה התפעולית ועל הקלות שבה אפשר להטמיע יכולות כמו הצפנה גורסת.
בקטעים הבאים מפורטות המלצות לכל אחת מאפשרויות העיצוב.
שימוש בפרויקט מרכזי של מפתח CMEK לכל סביבה
מומלץ להשתמש בפרויקט מרכזי של מפתח CMEK לכל תיקיית סביבה. אל תיצרו משאבים שמוצפנים באמצעות CMEK באותו פרויקט שבו אתם מנהלים מפתחות Cloud KMS. הגישה הזו עוזרת למנוע שיתוף של מפתחות הצפנה בין סביבות שונות, ומאפשרת הפרדת תפקידים.
התרשים הבא ממחיש את המושגים האלה בעיצוב המומלץ:
- לכל תיקיית סביבה יש פרויקט מפתח Cloud KMS שמנוהל בנפרד מפרויקטים של אפליקציות.
- אוספי מפתחות ומפתחות של Cloud KMS מוקצים בפרויקט המפתחות של Cloud KMS, והמפתחות האלה משמשים להצפנת משאבים בפרויקטים של האפליקציה.
- כללי מדיניות של ניהול זהויות והרשאות גישה (IAM) מוחלים על פרויקטים או תיקיות כדי לאפשר הפרדת תפקידים. הגורם המרכזי שמנהל את מפתחות Cloud KMS בפרויקט המפתחות של Cloud KMS הוא לא אותו גורם מרכזי שמשתמש במפתחות ההצפנה בפרויקטים של האפליקציות.
יצירת אוספי מפתחות של Cloud KMS לכל מיקום
צריך ליצור אוספי מפתחות של Cloud KMS במיקומים שבהם אתם פורסים משאביCloud de Confiance מוצפנים באמצעות CMEK.
- משאבים אזוריים ומשאבים של תחום מוגדר חייבים להשתמש בשרשרת מפתחות וב-CMEK באותו אזור כמו המשאב או ב
globalהמיקום. - במשאבים גלובליים צריך להשתמש באוסף מפתחות וב-CMEK במיקום
global.
אכיפה של מפתחות אזוריים היא חלק מאסטרטגיה של אחסון נתונים באזורים גיאוגרפיים ספציפיים. כשמחילים את השימוש באוספי מפתחות ובמפתחות באזור מוגדר, מחילים גם את הדרישה שהמשאבים יתאימו לאזור של אוסף המפתחות.
אם יש לכם עומסי עבודה שדורשים זמינות גבוהה או יכולות תוכנית התאוששות מאסון (DR) בכמה מיקומים, אתם צריכים להעריך אם עומס העבודה שלכם עמיד במקרה ש-Cloud KMS לא יהיה זמין באזור מסוים. לדוגמה, אי אפשר ליצור מחדש דיסק אחסון מתמיד ב-Compute Engine שהוצפן באמצעות מפתח Cloud KMS מאזור א' באזור ב' בתרחיש של תוכנית התאוששות מאסון שבו אזור א' לא זמין. כדי לצמצם את הסיכון לתרחיש הזה, אפשר לתכנן הצפנה של משאב באמצעות מפתחות global.
בחירה של אסטרטגיה מרכזית לרמת הפירוט
גרנולריות מתייחסת להיקף ולשימוש המיועד של כל מפתח. לדוגמה, מפתח שמגן על כמה משאבים נחשב פחות גרנולרי ממפתח שמגן רק על משאב אחד.
צריך להקצות מראש מפתחות Cloud KMS שמשמשים ל-CMEK לפני שיוצרים משאב שיוצפן באמצעות המפתח, כמו דיסק קשיח מתמשך של Compute Engine. אתם יכולים ליצור מפתחות גרנולריים מאוד למשאבים ספציפיים, או ליצור מפתחות פחות גרנולריים לשימוש חוזר במשאבים באופן כללי יותר.
באופן כללי, מומלץ להשתמש באסטרטגיית הגרנולריות הבאה:
- כל מפתח מגן על משאבים במיקום אחד – לדוגמה,
us-central1. - כל מפתח מגן על משאבים בשירות או במוצר יחיד – לדוגמה, BigQuery.
- כל מפתח מגן על משאבים ב Cloud de Confiance פרויקט אחד.
יכול להיות שההמלצה הזו לא תהיה אסטרטגיית הגרנולריות האידיאלית לארגון שלכם. ברוב הארגונים, האסטרטגיה הזו מספקת איזון טוב בין התקורה של תחזוקת מפתחות רבים ברמת פירוט גבוהה לבין הסיכונים הפוטנציאליים של שימוש במפתחות ברמת פירוט נמוכה יותר שמשותפים בין פרויקטים, שירותים או משאבים רבים.
אם אתם רוצים להשתמש באסטרטגיה אחרת של רמת פירוט, כדאי לשקול את היתרונות והחסרונות של דפוסים שונים:
מפתחות עם רמת פירוט גבוהה – לדוגמה, מפתח אחד לכל משאב בנפרד
- יותר שליטה בהשבתה בטוחה של גרסאות מפתח: להשבתה או להשמדה של גרסת מפתח שמשמשת להיקף מצומצם יש סיכון נמוך יותר להשפיע על משאבים אחרים מאשר להשבתה או להשמדה של מפתח משותף. זה גם אומר ששימוש במפתחות עם רמת פירוט גבוהה עוזר לצמצם את ההשפעה הפוטנציאלית של מפתח שנמצא בסיכון, בהשוואה לשימוש במפתחות עם רמת פירוט נמוכה.
- עלות: שימוש במפתחות גרנולריים מחייב שמירה על יותר גרסאות מפתחות פעילות בהשוואה לשיטה שבה נעשה שימוש במפתחות עם גרנולריות נמוכה יותר. גרנולריות גבוהה יותר של מפתחות מחייבת מספר גדול יותר של גרסאות מפתח פעילות, מה שגורר עלויות נוספות.
- תקורה תפעולית: שימוש במפתחות עם רמת גרנולריות גבוהה עשוי לדרוש מאמץ ניהולי או כלים נוספים לאוטומציה כדי להקצות מספר גדול של משאבי Cloud KMS ולנהל את אמצעי בקרת הגישה לסוכני שירות, כך שהם יוכלו להשתמש רק במפתחות המתאימים.
מפתחות עם רמת פירוט נמוכה – לדוגמה, מפתח אחד לכל אפליקציה, לכל אזור ולכל סביבה:
- צריך להיזהר כשמשביתים גרסאות של מפתחות: השבתה או השמדה של גרסת מפתח שמשמשת להיקף רחב של פעולות דורשת יותר זהירות מאשר השבתה או השמדה של מפתח עם רמת גרנולריות גבוהה. לפני שמשביתים את גרסת המפתח הישנה, צריך לוודא שכל המשאבים שהוצפנו באמצעות גרסת המפתח הזו הוצפנו מחדש בצורה בטוחה באמצעות גרסת מפתח חדשה. המשמעות היא גם ששימוש במפתחות עם רמת פירוט נמוכה יכול להגדיל את ההשפעה הפוטנציאלית מפריצה למפתח, בהשוואה לשימוש במפתחות עם רמת פירוט גבוהה.
- עלות: שימוש במפתחות עם רמת פירוט נמוכה יותר דורש יצירה של פחות גרסאות מפתח, ולכן העלויות נמוכות יותר.
- תקורה תפעולית: אתם יכולים להגדיר מראש מספר ידוע של מפתחות, בלי להשקיע מאמץ רב כדי לוודא שיש אמצעי בקרה מתאימים לגישה.
בחירת רמת ההגנה למפתחות
כשיוצרים מפתח, האחריות לבחירת רמת ההגנה שמתאימה לכל מפתח מוטלת עליכם, בהתאם לדרישות שלכם לגבי הנתונים ועומסי העבודה שמוצפנים באמצעות CMEK. השאלות הבאות יכולות לעזור לכם בתהליך ההערכה:
האם אתם צריכים את אחת מהיכולות של CMEK? אפשר לעיין ביכולות שמפורטות בקטע החלטה אם להשתמש ב-CMEK בדף הזה.
- אם כן, ממשיכים לשאלה הבאה.S3NS
- אם לא, מומלץ להשתמש ב S3NS הצפנה שמוגדרת כברירת מחדל.
האם אתם צריכים אישור FIPS 140-2 ברמה 2 או ברמה 3, או שחומר המפתח יאוחסן מחוץ ל- Cloud de Confiance?
- אם כן, מומלץ להשתמש ב-CMEK עם Cloud External Key Manager.
- אם לא, מומלץ להשתמש ב-CMEK עם מפתחות שמגובים בתוכנה.
שימוש בחומר מפתח שנוצר על ידי Cloud de Confianceכשזה אפשרי
החלק הזה לא רלוונטי למפתחות Cloud EKM.
כשיוצרים מפתח, צריך לאפשר ל-Cloud KMS ליצור את חומר המפתח בשבילכם או לייבא באופן ידני חומר מפתח שנוצר מחוץ ל- Cloud de Confiance. אם אפשר, מומלץ לבחור באפשרות שנוצרה. האפשרות הזו לא חושפת את חומר המפתח הגולמי מחוץ ל-Cloud KMS, ויוצרת באופן אוטומטי גרסאות מפתח חדשות על סמך תקופת הרוטציה של המפתח שאתם בוחרים. אם אתם צריכים את האפשרות לייבא חומר מפתח משלכם, מומלץ להעריך את השיקולים התפעוליים והסיכונים הבאים שקשורים לשימוש בגישת BYOK (הבאת מפתח משלכם):
- האם אפשר להטמיע אוטומציה כדי לייבא באופן עקבי גרסאות חדשות של מפתחות? זה כולל גם הגדרות של Cloud KMS להגבלת גרסאות מפתח לייבוא בלבד, וגם אוטומציה מחוץ ל-Cloud KMS כדי ליצור ולייבא חומר מפתח באופן עקבי. מה קורה אם האוטומציה לא מצליחה ליצור גרסה חדשה של המפתח בזמן הצפוי?
- איך בכוונתך לאחסן או להפקיד באופן מאובטח את חומר המפתח המקורי?
- איך אפשר לצמצם את הסיכון שבתהליך ייבוא המפתחות ידלוף חומר מפתח גולמי?
- מה תהיה ההשפעה של ייבוא מחדש של מפתח שהושמד בעבר כי חומר המפתח הגולמי נשמר מחוץ ל- Cloud de Confiance?
- האם היתרון של ייבוא חומר מפתח בעצמכם מצדיק את התקורה התפעולית והסיכון המוגברים?
בחירת המטרה המרכזית והאלגוריתם המתאימים לצרכים שלכם
כשיוצרים מפתח, צריך לבחור את הייעוד ואת האלגוריתם הבסיסי של המפתח. בתרחישי שימוש ב-CMEK, אפשר להשתמש רק במפתחות עם מטרה סימטרית ENCRYPT_DECRYPT. למטרה הזו תמיד משתמשים באלגוריתם GOOGLE_SYMMETRIC_ENCRYPTION, שמשתמש במפתחות של תקן הצפנה מתקדם (AES-256) ב-256 ביט ב-Galois Counter Mode (GCM), עם מטא-נתונים פנימיים של Cloud KMS. כשמשתמשים ב-Autokey, ההגדרות האלה מוחלות באופן אוטומטי.
בתרחישי שימוש אחרים, כמו הצפנה מצד הלקוח, כדאי לעיין במטרות והאלגוריתמים הזמינים של המפתחות כדי לבחור את האפשרות שהכי מתאימה לתרחיש השימוש שלכם.
בחירת תקופה להצגת סבב מודעות
מומלץ להעריך מהו פרק הזמן המתאים לרוטציית מפתחות בהתאם לצרכים שלכם. תדירות רוטציית המפתחות תלויה בדרישות של עומסי העבודה, בהתאם לרגישות או לתאימות. לדוגמה, יכול להיות שתידרשו לבצע רוטציית מפתחות לפחות פעם בשנה כדי לעמוד בתקני תאימות מסוימים, או שתבחרו בתקופת רוטציה תכופה יותר עבור עומסי עבודה רגישים במיוחד.
אחרי שמבצעים רוטציה למפתח סימטרי, הגרסה החדשה מסומנת כגרסת המפתח הראשית ומשמשת לכל הבקשות החדשות להגנה על מידע. הגרסאות הקודמות של המפתח נשארות זמינות לשימוש כדי לפענח נתונים שהוצפנו בעבר והוגנו באמצעות הגרסה הזו. כשמבצעים רוטציה למפתח, נתונים שהוצפנו באמצעות גרסאות קודמות של המפתח לא מוצפנים מחדש באופן אוטומטי.
רוטציית מפתחות תכופה עוזרת להגביל את מספר ההודעות שמוצפנות באמצעות אותה גרסת מפתח, וכך להפחית את הסיכון ואת ההשלכות של פריצה למפתח.
החלת אמצעי בקרה מתאימים לגישה
מומלץ להביא בחשבון את העיקרון של הרשאות מינימליות והפרדת תפקידים כשמתכננים את אמצעי בקרת הגישה. בקטעים הבאים מפורטות ההמלצות האלה.
החלת העיקרון של הרשאות מינימליות
כשמקצים הרשאה לניהול מפתחות CMEK, חשוב לפעול לפי העיקרון של הרשאות מינימליות ולהעניק את ההרשאות המינימליות שנדרשות לביצוע משימה. אנחנו ממליצים מאוד להימנע משימוש בתפקידים בסיסיים. במקום זאת, כדאי להעניק תפקידים מוגדרים מראש ב-Cloud KMS כדי לצמצם את הסיכון לאירועי אבטחה שקשורים לגישה עם הרשאות מוגזמות.
תכנון הפרדת תפקידים
לשמור על זהויות והרשאות נפרדות לאנשים שמנהלים את מפתחות ההצפנה ולאנשים שמשתמשים בהם. במסמך NIST SP 800-152 מוגדר הפרדה בין תפקידים: בין קצין ההצפנה שמפעיל ומנהל את השירותים של מערכת ניהול מפתחות קריפטוגרפיים, לבין משתמש שמשתמש במפתחות האלה כדי להצפין או לפענח משאבים.
כשמשתמשים ב-CMEK כדי לנהל הצפנה במנוחה בשירותי Cloud de Confiance , תפקיד ה-IAM שמשמש להצפנת מפתחות מוקצה לסוכן השירות של שירות Cloud de Confiance , ולא למשתמש ספציפי. לדוגמה, כדי ליצור אובייקטים בקטגוריה מוצפנת של Cloud Storage, משתמש צריך רק את תפקיד ה-IAM roles/storage.objectCreator, וסוכן השירות של Cloud Storage באותו פרויקט (לדוגמה, service-PROJECT_NUMBER@gs-project-accounts.s3ns-system.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 שעות בלבד, וזה לא מספיק זמן כדי לזהות בעיה ולשחזר את המפתח. אפשר להגדיר את משך הזמן של ההשמדה המתוזמנת רק במהלך יצירת המפתח.
בזמן שמפתח מתוזמן להשמדה, אי אפשר להשתמש בו לפעולות קריפטוגרפיות, וכל בקשה להשתמש במפתח נכשלת. במהלך הזמן הזה, כדאי לעקוב אחרי יומני הביקורת כדי לוודא שהמפתח לא נמצא בשימוש. אם רוצים להשתמש שוב במפתח, צריך לשחזר אותו לפני סוף התקופה שנקבעה להשמדה.
כדי לוודא שכל המפתחות שנוצרו עומדים בדרישות של משך הזמן המינימלי שנקבע להשמדה, מומלץ להגדיר את האילוץ של מדיניות הארגון constraints/cloudkms.minimumDestroyScheduledDuration עם משך זמן מינימלי של 30 יום, או משך הזמן המועדף עליכם. מדיניות הארגון הזו מונעת ממשתמשים ליצור מפתחות עם משך זמן שנקבע להשמדה שקטן מהערך שצוין במדיניות.
אכיפה של רמות ההגנה המותרות עבור CMEK
מומלץ לאכוף את הדרישות שלכם לגבי רמות ההגנה על המפתחות באופן עקבי בכל הסביבה באמצעות אילוצים של מדיניות הארגון.
משתמשים ב-constraints/cloudkms.allowedProtectionLevels כדי לוודא שמפתחות חדשים, גרסאות מפתח ועבודות ייבוא ישתמשו ברמות ההגנה שאתם מאשרים.
הגדרת אמצעי בקרה לזיהוי בעיות במפתחות CMEK
Cloud de Confiance CMEK מספק אמצעי בקרה שונים לזיהוי. בקטעים הבאים מוסבר איך להפעיל את אמצעי הבקרה האלה ואיך להשתמש בהם בהקשר של Cloud KMS.
הפעלה וצבירה של רישום ביומן ביקורת
מומלץ לצבור את יומני הביקורת של פעילות האדמין ב-Cloud KMS (יחד עם יומני פעילות האדמין של כל השירותים) במיקום מרכזי לכל המשאבים בארגון. כך צוות אבטחה או מבקר יכולים לבדוק את כל הפעילות שקשורה ליצירה או לשינוי של משאבי Cloud KMS בבת אחת. הוראות להגדרת אובייקטים מסוג sink של יומנים מצטברים זמינות במאמר איך מצטברים ומאחסנים את היומנים של הארגון.
אפשר גם להפעיל יומני גישה לנתונים כדי לרשום ביומן פעולות שנעשה בהן שימוש במפתחות, כולל פעולות הצפנה ופענוח. כשמשתמשים במפתחות CMEK, יכול להיווצר נפח גדול של יומנים, והדבר יכול להשפיע על העלויות, כי כל פעולה מכל שירות שמשתמש במפתחות CMEK תיצור יומני גישה לנתונים. לפני שמפעילים את היומנים של גישה לנתונים, מומלץ להגדיר תרחיש שימוש ברור ליומנים הנוספים ולבדוק איך עלויות הרישום ביומן יגדלו.
הערכת דרישות התאימות
למסגרות שונות של תאימות יש דרישות שונות לגבי הצפנה וניהול מפתחות. בדרך כלל, מסגרת תאימות מפרטת את העקרונות והיעדים ברמה גבוהה של ניהול מפתחות הצפנה, אבל היא לא קובעת את המוצר או ההגדרה הספציפיים שמאפשרים תאימות. באחריותכם להבין את הדרישות של מסגרת התאימות שלכם ואת האופן שבו אמצעי הבקרה שלכם, כולל ניהול מפתחות, יכולים לעמוד בדרישות האלה.
כדי לקבל הנחיות לגבי האופן שבו שירותים Cloud de Confiance יכולים לעזור לעמוד בדרישות של מסגרות תאימות שונות, אפשר לעיין במקור המידע הבא:סיכום השיטות המומלצות
בטבלה הבאה מפורטות השיטות המומלצות שמופיעות במסמך הזה:
| נושא | משימה |
|---|---|
| החלטה אם להשתמש בהצפנה באמצעות מפתח שמוגדר על ידי הלקוח (CMEK) | כדאי להשתמש ב-CMEK אם אתם צריכים את אחת היכולות שמופעלות על ידי CMEK. |
| פרויקטים של מפתחות Cloud KMS | משתמשים בפרויקט מפתח מרכזי אחד לכל סביבה. אל תיצרו משאבי Cloud KMS באותו פרויקט שבו נמצאים משאבי Cloud de Confiance שהמפתחות מגנים עליהם. |
| אוספי מפתחות ב-Cloud KMS | יוצרים אוספי מפתחות של Cloud KMS לכל מיקום שבו רוצים להגן על משאבי Cloud de Confiance. |
| רמת הפירוט של המפתחות | בוחרים דפוס של רמת פירוט של מפתח שמתאים לצרכים שלכם מבחינת סובלנות לסיכון, עלות ותקורה תפעולית. |
| רמת הגנה | אם חומר המפתח שלכם צריך להיות מאוחסן מחוץ ל- Cloud de Confiance , או אם אתם צריכים אישור FIPS 140-2 ברמה 2 או ברמה 3, כדאי לבחור ב-Cloud EKM. אחרת, בוחרים במפתחות תוכנה. מומלץ לעיין בהנחיות לבחירת רמת הגנה. |
| חומר הליבה | אם חומר המפתח מאוחסן ב- Cloud de Confiance, מומלץ להשתמש בחומר מפתח שנוצר על ידי Cloud de Confiance. אם אתם משתמשים בחומר מפתח מיובא, כדאי להטמיע אוטומציה ונהלים כדי לצמצם את הסיכונים. |
| המטרה העיקרית והאלגוריתם | כל מפתחות ה-CMEK צריכים להשתמש במטרה הסימטרית ENCRYPT_DECRYPT של המפתח ובאלגוריתם GOOGLE_SYMMETRIC_ENCRYPTION. |
| תקופת הרוטציה | השתמשו ברוטציית מפתחות אוטומטית כדי לוודא שהמפתחות שלכם עוברים רוטציה לפי לוח זמנים. בוחרים ומחילים תקופת סבב שמתאימה לצרכים שלכם, רצוי לפחות פעם בשנה. מומלץ להשתמש ברוטציית מפתחות תכופה יותר לעומסי עבודה רגישים. |
| הרשאות מינימליות | צריך להקצות את התפקידים המוגדרים מראש שמוגבלים ביותר, שמאפשרים לחשבונות הראשיים להשלים את המשימות שלהם. אל תשתמשו בתפקידים בסיסיים. |
| הפרדת תפקידים | שמירה על הרשאות נפרדות לאדמינים ולגורמים מרכזיים שמשתמשים במפתחות. |
| שעבודים של פרויקטים | כדאי להשתמש במנעולים של פרויקטים כדי למנוע מחיקה בטעות של פרויקטים חשובים. |
| דרישה לשימוש במפתחות CMEK | משתמשים באילוץ constraints/gcp.restrictNonCmekServices. |
| נדרש משך מינימלי של השמדה מתוזמנת | משתמשים באילוץ constraints/cloudkms.minimumDestroyScheduledDuration. |
| אכיפה של רמות ההגנה המותרות עבור CMEK | משתמשים באילוץ constraints/cloudkms.allowedProtectionLevels. |
| הפעלה וצבירה של רישום ביומן ביקורת | יומני ביקורת של פעילות אדמין מצטברת לכל המשאבים בארגון. כדאי לשקול אם רוצים להפעיל רישום ביומן של פעולות באמצעות מפתחות. |
| הערכת דרישות התאימות | בודקים את הארכיטקטורה של Cloud KMS ומשווים אותה לדרישות התאימות שאתם צריכים לעמוד בהן. |