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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• הגנה על נתונים רפואיים ב-Google Cloud
• מרכז משאבים בנושא תאימות
• הדרכה בנושא הטמעה של FedRAMP ב-Google Cloud
• תאימות לתקן אבטחת הנתונים של PCI

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

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

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

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

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

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

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

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

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

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

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

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

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

אחסון מפתחות

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

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

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

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

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

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

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

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

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

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

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

תרחיש שימוש

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

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

לתשומת ליבכם

הגישה הזו עלולה ליצור מורכבויות ב-IAM בין פרויקטים וצווארי בקבוק פוטנציאליים לצוותי פיתוח. כדי לצמצם את הסיכון הזה, אפשר להטמיע הקצאת הרשאות אוטומטית לפרויקטים – לפעמים קוראים לזה 'מפעל פרויקטים' – כדי להפוך את יצירת המפתחות והקצאת ההרשאות לאוטומטיות, או להשתמש ב-Cloud KMS Autokey כדי להפעיל הקצאת הרשאות לפי דרישה שתומכת בהפרדת תפקידים, גם בצינורות עיבוד נתונים של תשתית כקוד (IaC).

דוגמה

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

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

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

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

תרחיש שימוש

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

לתשומת ליבכם

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

דוגמה

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

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

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

נקודה חשובה: לא מומלץ להקצות לאותו סובייקט תפקידים אדמיניסטרטיביים כמו Cloud KMS Admin ותפקידים שקשורים לשימוש קריפטוגרפי כמו Cloud KMS CryptoKey Encrypter/Decrypter באותו משאב.

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

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

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

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

החלת הסלמת הרשאות מינימלית על צינורות 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.

האם להשתמש ב-Autokey

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

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

השיטות המומלצות הבאות מבוצעות באופן אוטומטי כשמשתמשים ב-Autokey:

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

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

תאימות ו-Autokey

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

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

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

במקום להחליש את השליטה, האצלת ההקצאות ל-Autokey מחזקת את התאימות. הכלי מחליף שלבים ידניים בהגדרות שעלולים להוביל לשגיאות, ומאפשר לאכוף באופן פרוגרמטי הפרדת תפקידים ואבטחת צינורות. כך הוא עונה על דרישות הבקרה המחמירות של תוכניות תאימות כמו NIST SP 800-152 ו-PCI DSS.

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

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

מיקום המפתח

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

• משאבים אזוריים ומשאבים של תחום מוגדר חייבים להשתמש באוסף מפתחות ובמפתח באותו אזור שבו נמצא המשאב או במיקום global. במשאבים אזוריים ובמשאבים של תחום מוגדר אי אפשר להשתמש במחזיק מפתחות של אזור גיאוגרפי נרחב יותר, מלבד global.
• במשאבים רב-אזוריים (כמו מערך נתונים ב-BigQuery בusמספר אזורים) צריך להשתמש במחזיק מפתחות ובמפתח באותו אזור רב-אזורי. במשאבים שמנוהלים במספר אזורים אי אפשר להשתמש במפתח אזורי.
• משאבים גלובליים חייבים להשתמש באוסף מפתחות ובמפתח במיקום global.

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

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

‫אם משתמשים ב-Cloud KMS Autokey, נוצרים אוספי מפתחות באותו מיקום של המשאבים שמוגנים.

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

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

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

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

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

מפתחות שנוצרו באמצעות Cloud KMS Autokey עומדים בהמלצה הזו.

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

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

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

1. האם יש לכם דרישות מיוחדות לגבי בידוד, מיקום או תקנות? כדאי לבדוק אם עומס העבודה שלכם דורש אחת מהתכונות הבאות של אבטחה גבוהה:

   • אחסון חיצוני: שימוש ב-CMEK ידני עם Cloud EKM. מומלץ להשתמש ברמת ההגנה EXTERNAL_VPC כדי לשפר את הזמינות.
   • חומרה ייעודית: שימוש ב-CMEK ידני עם Cloud HSM בדייר יחיד.

   אם לא, ממשיכים לשאלה הבאה.

2. האם אתם רוצים הקצאת מפתחות אוטומטית וניהול מחזור חיים?

   • אם כן, כדאי להשתמש ב-Cloud KMS Autokey. ‫Autokey יוצר מפתחות באופן אוטומטי באמצעות רמת ההגנה Multi-tenant Cloud HSM. גם אם מפתחות שמגובים בתוכנה מקובלים עליכם, מומלץ להשתמש בבסיס האבטחה הגבוה יותר של Cloud HSM כדי ליהנות מהאוטומציה שמספק Autokey.

   • אם לא, ממשיכים לשאלה הבאה.

3. האם אתם צריכים שחומר המפתח יישאר בתוך הגבול הפיזי של מודול אבטחה לחומרה (HSM)?

   • אם כן, צריך להשתמש ב-Cloud HSM מרובה דיירים.
   • אם לא, משתמשים במפתחות שמגובים על ידי תוכנה.

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

‫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 Autokey

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

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

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

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

כדי לוודא שכל המפתחות שנוצרו עומדים בדרישות של משך זמן מינימלי שנקבע להשמדה, מומלץ להגדיר את האילוץ של מדיניות הארגון constraints/cloudkms.minimumDestroyScheduledDuration עם משך זמן מינימלי של 30 ימים, או משך הזמן המועדף עליכם. מדיניות הארגון הזו מונעת ממשתמשים ליצור מפתחות עם משך זמן שנקבע להשמדה שקטן מהערך שצוין במדיניות.

אכיפה של רמות ההגנה המותרות עבור מפתחות CMEK

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

משתמשים בהרשאה constraints/cloudkms.allowedProtectionLevels כדי לוודא שמפתחות חדשים, גרסאות מפתח ועבודות ייבוא ישתמשו ברמות ההגנה שאתם מאשרים.

אם אוכף שימוש ב-Autokey, כל המפתחות מגובים בחומרה.

הגדרת אמצעי בקרה לזיהוי בעיות במפתחות CMEK

Google Cloud מספקת אמצעי בקרה שונים לזיהוי בעיות ב-CMEK. בקטעים הבאים מוסבר איך להפעיל את אמצעי הבקרה שרלוונטיים ל-Cloud KMS ואיך להשתמש בהם.

הפעלה וצבירה של יומני ביקורת

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

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

הפעלת Security Command Center לזיהוי נקודות חולשה ב-Cloud KMS

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

מעקב ותיקון

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

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

• לוח הבקרה Key usage (שימוש במפתחות): אפשר לראות את השימוש במפתחות כדי לזהות Google Cloud משאבים בארגון שתלויים במפתחות Cloud KMS ומוגנים על ידם. לוח הבקרה הזה מאפשר לעקוב אחרי המצב, השימוש והזמינות של גרסאות המפתח והמשאבים שהן מגנות עליהם. לוח הבקרה גם מזהה נתונים שלא ניתן לגשת אליהם בגלל מפתח שהושבת או הושמד, כדי שתוכלו לבצע פעולות כמו מחיקת הנתונים שלא ניתן לגשת אליהם או הפעלה מחדש של המפתח. המידע בלוח הבקרה Key usage זמין גם באמצעות Cloud KMS Inventory API.

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

סיכום של השיטות המומלצות

בטבלה הבאה מפורטות השיטות המומלצות שמופיעות במאמר הזה:

נושא	משימה
בחירה ביצירה ידנית או אוטומטית של מפתחות	אם המאפיינים של המפתחות שנוצרו על ידי 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 באופן עקבי.