שיטות מומלצות לשימוש במפתחות CMEK

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

המדריך הזה מיועד למי שכבר מכיר את Cloud Key Management Service ‏(Cloud KMS) ואת מפתחות הצפנה בניהול הלקוח.

בחירה איפה להשתמש ב-CMEK

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

אתם יכולים להשתמש במפתחות CMEK בשירותים תואמים כדי להשיג את המטרות הבאות:

• בעלות על מפתחות ההצפנה.

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

• ליצור חומר מפתח ב-Cloud KMS או לייבא חומר מפתח שמנוהל מחוץ ל- Cloud de Confiance.

• הגדרת מדיניות לגבי המקומות שבהם אפשר להשתמש במפתחות.

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

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

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

• עמידה בתקנות קיימות או עתידיות שמחייבות את השימוש באחד מהיעדים האלה.

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

כדי לקבל הנחיות לגבי האופן שבו שירותים יכולים לעזור לעמוד בדרישות של מסגרות שונות לתאימות, אפשר לעיין במקורות המידע הבאים: Cloud de Confiance

• הגנה על נתונים רפואיים ב-Cloud de Confiance
• מרכז משאבים בנושא תאימות

בחירת המקור של חומר המפתח

כשיוצרים מפתח, צריך לאפשר ל-Cloud KMS ליצור את חומר המפתח בשבילכם או לייבא חומר מפתח שנוצר מחוץ ל- Cloud de Confiance. במקרים שבהם הדבר אפשרי, מומלץ ליצור חומר מפתח ב-Cloud KMS. האפשרות הזו לא חושפת את חומר המפתח הגולמי מחוץ ל-Cloud KMS, ויוצרת באופן אוטומטי גרסאות חדשות של מפתחות על סמך תקופת רוטציית המפתחות שאתם בוחרים. אם אתם חייבים לייבא חומר מפתח משלכם, מומלץ להעריך את השיקולים התפעוליים הבאים ואת הסיכונים בשימוש בגישת Bring-Your-Own-Key‏ (BYOK):

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

• איך בכוונתך לאחסן באופן מאובטח את חומר המפתח המקורי או להפקיד אותו בנאמנות?

• איך אפשר לצמצם את הסיכון שבתהליך ייבוא המפתחות ייחשף חומר המפתח הגולמי?

• מה תהיה ההשפעה של ייבוא מחדש של מפתח שהושמד בעבר כי חומר המפתח הגולמי נשמר מחוץ ל- Cloud de Confiance?

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

בחירת מודלים מרכזיים לניהול ולשמירת מפתחות

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

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

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

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

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

אחסון מפתחות

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

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

• אחסון מפתחות באותו פרויקט: המפתחות מאוחסנים באותוCloud de Confiance פרויקט כמו המשאבים שהם מגנים עליהם. הגישה הזו נקראת לפעמים "המפתח עוקב אחרי הנתונים". אפשר להשתמש ב-Autokey עם אחסון מפתחות באותו פרויקט. מידע נוסף על מודל אחסון מפתחות באותו פרויקט זמין במאמר אחסון מפתחות באותו פרויקט.

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

התאמה בין משילות לאחסון

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

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

שימוש בארכיטקטורה עקבית בכל הסביבות

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

אחסון מפתחות בפרויקט ייעודי

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

תרחיש שימוש

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

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

לתשומת ליבכם

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

דוגמה

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

• התיקייה Prod מכילה תיקיות ופרויקטים נפרדים לאפליקציות שונות, וגם תיקייה משותפת.
• פרויקטים של אפליקציות מכילים מגוון משאבים שונים, כמו מכונות ב-Compute Engine וקטגוריות של Cloud Storage, אבל הם לא מכילים מפתחות Cloud KMS.
• התיקייה Shared מכילה משאבים שמשותפים בין האפליקציות השונות.
• בתיקייה המשותפת יש פרויקט מפתחות ייעודי שבו מופעל Cloud KMS API. הפרויקט הזה מכיל את כל המפתחות שמשמשים להגנה על משאבים בתיקייה Prod.
• אמצעי בקרה ברמת הארגון וברמת התיקייה, כמו הגבלות של מדיניות הארגון ומדיניות IAM, אוכפים הפרדה בין תחומי האחריות ושיטות עבודה מומלצות אחרות.
• למפתחים יכולות להיות הרשאות מורחבות, כמו התפקיד 'Project Owner', בתיקייה או בפרויקט של אפליקציה ספציפית, בלי לתת להם הרשאות בפרויקט המרכזי.

אחסון מפתחות באותו פרויקט

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

תרחיש שימוש

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

לתשומת ליבכם

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

דוגמה

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

• התיקייה Prod מכילה תיקיות ופרויקטים נפרדים לאפליקציות שונות.
• פרויקטים של אפליקציות מכילים מגוון משאבים שונים, כמו מכונות ב-Compute Engine וקטגוריות של Cloud Storage, כולל מפתחות Cloud KMS שמגנים על המשאבים האלה.
• אמצעי בקרה ברמת הארגון וברמת התיקייה, כמו הגבלות של מדיניות הארגון וכללי מדיניות IAM, אוכפים הפרדה בין תפקידים ושיטות עבודה אחרות, אבל כדי לאכוף הפרדה בין תפקידים צריך להגדיר את ההגדרות בקפידה.
• מפתחים צריכים הרשאות מורחבות ב-Cloud KMS בפרויקט המשאב כדי ליצור ולנהל מפתחות.

אכיפת הפרדת תפקידים

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

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

אחריות	התפקיד המומלץ	סיכום הרשאות
ניהול מפתחות, למשל מחזורי חיים של מפתחות ומשילות הם יכולים לכלול מנהלים אנושיים וישויות מורשות של IaC שזקוקים להרשאות מורחבות.	אדמין של Cloud KMS‏ (roles/cloudkms.admin)	ליצור מפתחות ומשאבים קשורים, להשתמש בהם בסבב, להפעיל אותם, להשבית אותם ולהשמיד אותם. ניהול מדיניות IAM.
הקצאת משאבים, למשל יצירת משאבים שמוגנים באמצעות CMEK הם יכולים לכלול מפתחים אנושיים ומשתמשי IaC ללא הרשאות מורחבות.	תפקידי אדמין או עריכה ספציפיים לשירות, כמו התפקידים הבאים: משתמש BigQuery‏ (roles/bigquery.user) אדמין של Compute (roles/compute.admin)	בוחרים מפתחות במהלך יצירת המשאב.
שימוש במפתח, למשל הצפנה ופענוח הקצאת התפקיד הזה מתבצעת רק לסוכני שירות. במפתחות שמשמשים לאינטגרציות של CMEK, לישויות מורשות אנושיות לא נדרשות ההרשאות האלה.	Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter)	הצפנה ופענוח של נתונים באמצעות המפתח.

החלת הסלמת הרשאות מינימלית על צינורות IaC

הרבה ארגונים מבצעים אוטומציה של הקצאת משאבים באמצעות צינורות עיבוד נתונים של תשתית כקוד (IaC), כמו Terraform runners. האופן שבו אתם מתכננים את אחסון המפתחות משפיע ישירות על מצב האבטחה של צינורות עיבוד הנתונים האלה.

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

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

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

• צינורות (pipelines) עם הרשאות מוגבלות: צינור ה-IaC דורש רק את התפקיד Cloud KMS Autokey User (roles/cloudkms.autokeyUser) עם הרשאות מוגבלות כדי לבקש מפתח על ידי יצירת משאב KeyHandle.
• הקצאת הרשאות אוטומטית: יצירת המפתח בפועל ועדכוני מדיניות IAM מתבצעים מאחורי הקלעים על ידי סוכן שירות Cloud KMS שמנוהל על ידי Google.
• היקף מוגבל של סיכון: על ידי צמצום ההרשאות שניתנות לצינור עיבוד הנתונים, העיצוב הזה מונע מתן הרשאות מוגברות ליצירת מפתחות או הרשאות אדמין אבטחה לצינורות עיבוד הנתונים לפריסה, או את היכולת להקצות תפקידי עזר, מה שמפחית באופן משמעותי את הסיכון לפריצה לצינור עיבוד הנתונים.

פייפליין של IaC שמאפשר Autokey דורש תפקיד עם הרשאות רחבות יותר, כמו Cloud KMS Autokey Admin ‏ (roles/cloudkms.autokeyAdmin). לכן, אם אתם משתמשים בפייפליינים של IaC כדי לנהל את ההפעלה של Autokey, אתם צריכים להחיל הפרדת תפקידים גם על ישויות מורשות נפרדות של IaC.

התאמה לשיטות מומלצות לניהול מפתחות

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

מיקום המפתח

‫ צריך ליצור אוספי מפתחות של Cloud KMS במיקומים שבהם אתם מתכננים לפרוס Cloud de Confiance משאבים שמוצפנים באמצעות CMEK. צריך לבצע את הפעולה הזו לפני שיוצרים את המפתחות.

• משאבים אזוריים ומשאבים של תחום מוגדר חייבים להשתמש באוסף מפתחות ובמפתח באותו אזור שבו נמצא המשאב או במיקום global.
• משאבים גלובליים חייבים להשתמש באוסף מפתחות ובמפתח במיקום global.

ברוב המקרים, ההגבלות האלה נאכפות על ידי Cloud de Confiance השירות.

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

‫

בחירה של אסטרטגיה מרכזית לרמת הפירוט

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

באופן כללי, מומלץ להשתמש בכל מפתח באופן הבא:

• משמש לפרויקט אחד Cloud de Confiance .
• בשימוש במיקום יחיד – לדוגמה, us-central1.
• השימוש הוא בשירות או במוצר יחיד – למשל, BigQuery.
• בכל מקום שאפשר, משתמשים בהן למשאב יחיד – לדוגמה, קטגוריה אחת של Cloud Storage.

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

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

בחירת רמת ההגנה למפתחות

כשיוצרים מפתח, אתם אחראים לבחור את רמת ההגנה שמתאימה לכל מפתח על סמך הדרישות שלכם לגבי הנתונים ועומסי העבודה שמוצפנים באמצעות CMEK. * אם אתם רוצים שחומר המפתח שלכם יאוחסן מחוץ ל- Cloud de Confiance, אתם יכולים להשתמש במפתחות Cloud EKM. מומלץ להשתמש ברמת ההגנה EXTERNAL_VPC כדי לשפר את הזמינות. ‫* אם אתם לא נדרשים לאחסן את חומר המפתח מחוץ ל- Cloud de Confiance, מומלץ להשתמש במפתחות שמגובים על ידי תוכנה.

בחירת תקופה להצגת סבב מודעות

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

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

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

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

כשמעניקים תפקידי IAM, חשוב לפעול לפי העיקרון של הרשאות מינימליות. מומלץ מאוד להימנע משימוש בתפקידים בסיסיים כמו בעלים, עורך וצופה. במקום זאת, כדאי להעניק תפקידים מוגדרים מראש ב-Cloud KMS כדי לצמצם את הסיכון לאירועי אבטחה שקשורים לגישה עם הרשאות יתר. לדוגמה, אם חשבון משתמש צריך רק לייבא חומר מפתח, כדאי להקצות לו את התפקיד Cloud KMS Importer (ייבואן ב-Cloud KMS) ‏(roles/cloudkms.importer) במקום את התפקיד Cloud KMS Admin (אדמין ב-Cloud KMS) ‏(roles/cloudkms.admin) שכולל יותר הרשאות.

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

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

אכיפה של שיעבודים בפרויקט

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

דרישה למפתחות CMEK

מומלץ לאכוף את השימוש ב-CMEK בסביבה שלכם באמצעות אילוצים של מדיניות הארגון.

אתם יכולים להשתמש בconstraints/gcp.restrictNonCmekServices כדי לחסום בקשות ליצירת סוגים מסוימים של משאבים בלי לציין מפתח CMEK.

נדרש משך זמן מינימלי שנקבע להשמדה

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