בדף הזה מפורטות שיטות מומלצות להגדרת הצפנה במצב מנוחה באמצעות מפתחות הצפנה בניהול הלקוח (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-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 בדף הזה.
- אם כן, ממשיכים לשאלה הבאה.
- אם לא, מומלץ להשתמש בהצפנה שמוגדרת כברירת מחדל.
האם אתם צריכים שחומר המפתח יישאר בתוך הגבול הפיזי של מודול אבטחה לחומרה (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, שמשתמש במפתחות של תקן הצפנה מתקדם (AES-256) ב-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 שעות בלבד, וזה לא מספיק זמן כדי לזהות בעיה ולשחזר את המפתח. אפשר להגדיר את משך הזמן של ההשמדה המתוזמנת רק במהלך יצירת המפתח.
בזמן שמפתח מתוזמן להשמדה, אי אפשר להשתמש בו לפעולות קריפטוגרפיות, וכל בקשה להשתמש במפתח נכשלת. במהלך הזמן הזה, כדאי לעקוב אחרי יומני הביקורת כדי לוודא שהמפתח לא נמצא בשימוש. אם רוצים להשתמש שוב במפתח, צריך לשחזר אותו לפני סוף התקופה שנקבעה להשמדה.
כדי לוודא שכל המפתחות שנוצרו עומדים בדרישות של משך הזמן המינימלי שנקבע להשמדה, מומלץ להגדיר את האילוץ של מדיניות הארגון constraints/cloudkms.minimumDestroyScheduledDuration עם משך זמן מינימלי של 30 יום, או משך הזמן המועדף עליכם. מדיניות הארגון הזו מונעת ממשתמשים ליצור מפתחות עם משך זמן שנקבע להשמדה שקטן מהערך שצוין במדיניות.
אכיפה של רמות ההגנה המותרות עבור CMEK
מומלץ לאכוף את הדרישות שלכם לגבי רמות ההגנה על המפתחות באופן עקבי בכל הסביבה באמצעות אילוצים של מדיניות הארגון.
משתמשים ב-constraints/cloudkms.allowedProtectionLevels כדי לוודא שמפתחות חדשים, גרסאות מפתח ועבודות ייבוא ישתמשו ברמות ההגנה שאתם מאשרים.
הגדרת אמצעי בקרה לזיהוי בעיות במפתחות CMEK
Google Cloud CMEK מספק אמצעי בקרה שונים לזיהוי. בקטעים הבאים מוסבר איך להפעיל את אמצעי הבקרה האלה ואיך להשתמש בהם בהקשר של Cloud KMS.
הפעלה וצבירה של רישום ביומן ביקורת
מומלץ לצבור את יומני הביקורת של פעילות האדמין ב-Cloud KMS (יחד עם יומני פעילות האדמין של כל השירותים) במיקום מרכזי לכל המשאבים בארגון. כך צוות אבטחה או מבקר יכולים לבדוק את כל הפעילות שקשורה ליצירה או לשינוי של משאבי Cloud KMS בבת אחת. הוראות להגדרת אובייקטים מסוג sink של יומנים מצטברים זמינות במאמר איך מצטברים ומאחסנים את היומנים של הארגון.
אפשר גם להפעיל יומני גישה לנתונים כדי לרשום ביומן פעולות שנעשה בהן שימוש במפתחות, כולל פעולות הצפנה ופענוח. כשמשתמשים במפתחות CMEK, יכול להיווצר נפח גדול של יומנים, והדבר יכול להשפיע על העלויות, כי כל פעולה מכל שירות שמשתמש במפתחות CMEK תיצור יומני גישה לנתונים. לפני שמפעילים את היומנים של גישה לנתונים, מומלץ להגדיר תרחיש שימוש ברור ליומנים הנוספים ולבדוק איך עלויות הרישום ביומן יגדלו.
מעקב אחר השימוש במפתחות
אפשר לראות את השימוש במפתחות באמצעות Cloud KMS inventory API כדי לזהות Google Cloud משאבים בארגון שתלויים במפתחות Cloud KMS ומוגנים על ידם. אפשר להשתמש בלוח הבקרה הזה כדי לעקוב אחרי המצב, השימוש והזמינות של גרסאות המפתח והמשאבים התואמים שהן מגנות עליהם. לוח הבקרה מזהה גם נתונים שלא ניתן לגשת אליהם בגלל מפתח מושבת או מושמד, כדי שתוכלו לבצע פעולות כמו מחיקת הנתונים שלא ניתן לגשת אליהם או הפעלה מחדש של המפתח. אפשר להשתמש ב-Cloud Monitoring עם Cloud KMS כדי להגדיר התראות על אירועים קריטיים, כמו תזמון של השמדת מפתח. Cloud Monitoring מאפשר לכם להבין למה הפעולה הזו בוצעה ולהפעיל תהליך אופציונלי במורד הזרם כדי לשחזר את המפתח אם צריך.מומלץ ליצור תוכנית תפעולית לזיהוי אוטומטי של אירועים שחשובים לכם, ולבדוק מעת לעת את לוח הבקרה של מדדי השימוש העיקריים.
הפעלת Security Command Center לזיהוי נקודות חולשה ב-Cloud KMS
Security Command Center יוצר ממצאים של נקודות חולשה שמדגישים הגדרות שגויות שמשויכות ל-Cloud KMS ולמשאבים אחרים. מומלץ להפעיל את Security Command Center ולשלב את הממצאים האלה בפעולות האבטחה הקיימות. הממצאים האלה כוללים בעיות כמו מפתחות Cloud KMS שנגישים לציבור, פרויקטים של Cloud KMS עם התפקיד owner שכולל הרשאות רחבות מדי, או תפקידי IAM שמפירים את הפרדת התפקידים.
הערכת דרישות התאימות
למסגרות שונות של תאימות יש דרישות שונות לגבי הצפנה וניהול מפתחות. בדרך כלל, מסגרת תאימות מפרטת את העקרונות והיעדים ברמה גבוהה של ניהול מפתחות הצפנה, אבל היא לא קובעת את המוצר או ההגדרה הספציפיים שמאפשרים תאימות. באחריותכם להבין את הדרישות של מסגרת התאימות שלכם ואת האופן שבו אמצעי הבקרה שלכם, כולל ניהול מפתחות, יכולים לעמוד בדרישות האלה.
כדי לקבל הנחיות לגבי האופן שבו שירותים Google Cloud יכולים לעזור לעמוד בדרישות של מסגרות תאימות שונות, אפשר לעיין במקורות המידע הבאים:- הגנה על נתונים רפואיים ב- Google Cloud
- מקורות מידע בנושא תאימות ותקנות בענן
- Google Cloud מדריך להטמעה של FedRAMP
- תאימות לתקן אבטחת הנתונים של PCI
סיכום השיטות המומלצות
בטבלה הבאה מפורטות השיטות המומלצות שמופיעות במסמך הזה:
| נושא | משימה |
|---|---|
| החלטה אם להשתמש בהצפנה באמצעות מפתח שמוגדר על ידי הלקוח (CMEK) | כדאי להשתמש ב-CMEK אם אתם צריכים את אחת היכולות שמופעלות על ידי CMEK. |
| בחירה ביצירה ידנית או אוטומטית של מפתחות | אם המאפיינים של המפתחות שנוצרו על ידי Autokey מתאימים לצרכים שלכם, כדאי להשתמש ב-Cloud KMS Autokey. |
| פרויקטים של מפתחות Cloud KMS | משתמשים בפרויקט מפתח מרכזי אחד לכל סביבה. אל תיצרו משאבי Cloud KMS באותו פרויקט שבו נמצאים משאבי Google Cloud שהמפתחות מגנים עליהם. |
| אוספי מפתחות ב-Cloud KMS | יוצרים אוספי מפתחות של Cloud KMS לכל מיקום שבו רוצים להגן על משאבי Google Cloud. |
| רמת הפירוט של המפתחות | בוחרים דפוס של רמת פירוט של מפתחות שמתאים לצרכים שלכם, או משתמשים ב-Autokey כדי להקצות מפתחות באופן אוטומטי ברמת הפירוט המומלצת לכל שירות. |
| רמת הגנה | אם חומר המפתח שלכם חייב להיות מאוחסן מחוץ ל- Google Cloud, אתם צריכים לבחור ב-Cloud EKM. בוחרים באפשרות Single-tenant Cloud HSM אם חומר המפתח צריך להיות מאוחסן במחיצות ייעודיות במודולי אבטחה לחומרה (HSM) בבעלות Google Cloud. בוחרים באפשרות Multi-tenant Cloud HSM אם אפשר לארח את חומר המפתח באשכולות של מודול אבטחה לחומרה (HSM) בבעלות Google Cloudשמשותפים עם לקוחות אחרים של Google Cloud . אם אתם לא צריכים את Cloud HSM או Cloud EKM, אתם יכולים לבחור במפתחות תוכנה. מומלץ לעיין בהנחיות לבחירת רמת הגנה. |
| חומר הליבה | אם חומר המפתח מאוחסן ב- Google Cloud, מומלץ להשתמש בחומר מפתח שנוצר על ידי Google Cloud. אם אתם משתמשים בחומר מפתח מיובא, כדאי להטמיע אוטומציה ונהלים כדי לצמצם את הסיכונים. |
| המטרה העיקרית והאלגוריתם | כל מפתחות ה-CMEK צריכים להשתמש במטרה הסימטרית ENCRYPT_DECRYPT של המפתח ובאלגוריתם GOOGLE_SYMMETRIC_ENCRYPTION. |
| תקופת הרוטציה | השתמשו ברוטציית מפתחות אוטומטית כדי לוודא שהמפתחות שלכם עוברים רוטציה לפי לוח זמנים. בוחרים ומחילים תקופת סבב שמתאימה לצרכים שלכם, רצוי לפחות פעם בשנה. מומלץ להשתמש ברוטציית מפתחות תכופה יותר לעומסי עבודה רגישים. |
| הרשאות מינימליות | צריך להקצות את התפקידים המוגדרים מראש שמוגבלים ביותר, שמאפשרים לחשבונות הראשיים להשלים את המשימות שלהם. אל תשתמשו בתפקידים בסיסיים. |
| הפרדת תפקידים | שמירה על הרשאות נפרדות לאדמינים ולגורמים מרכזיים שמשתמשים במפתחות. |
| שעבודים של פרויקטים | כדאי להשתמש במנעולים של פרויקטים כדי למנוע מחיקה בטעות של פרויקטים חשובים. |
| דרישה לשימוש במפתחות CMEK | משתמשים באילוץ constraints/gcp.restrictNonCmekServices. |
| נדרש משך מינימלי של השמדה מתוזמנת | משתמשים באילוץ constraints/cloudkms.minimumDestroyScheduledDuration. |
| אכיפה של רמות ההגנה המותרות עבור CMEK | משתמשים באילוץ constraints/cloudkms.allowedProtectionLevels. |
| הפעלה וצבירה של רישום ביומן ביקורת | יומני ביקורת של פעילות אדמין מצטברת לכל המשאבים בארגון. כדאי לשקול אם רוצים להפעיל רישום ביומן של פעולות באמצעות מפתחות. |
| מעקב אחר השימוש במפתחות | כדי להבין את השימוש במפתחות, אפשר להשתמש ב-Cloud KMS Inventory API או במסוף Google Cloud . אפשר להשתמש ב-Cloud Monitoring כדי להגדיר התראות לפעולות רגישות כמו תזמון של מחיקת מפתח. |
| הפעלת Security Command Center ל-Cloud KMS | בדיקת הממצאים של נקודות החולשה ושילוב של בדיקת הממצאים של נקודות החולשה בפעולות האבטחה. |
| הערכת דרישות התאימות | בודקים את הארכיטקטורה של Cloud KMS ומשווים אותה לדרישות התאימות שאתם צריכים לעמוד בהן. |
המאמרים הבאים
- Cloud KMS Autokey מפחית את המאמץ שנדרש כדי להשתמש ב-CMEK באופן עקבי.