שיטות מומלצות לשימוש ב-Cloud HSM ל-Google Workspace

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

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

צמצום הסיכון לאובדן של חומר מפתחות

סיכוני אבטחה עלולים להתעורר כשחשבון משתמש מחזיק בתפקיד שמעניק הרשאה להשלמת פעולות הרסניות, במיוחד כאלה שנמצאות מחוץ לתחום העבודה הרגיל של חשבון המשתמש. לדוגמה, משתמש עם תפקיד רחב מדי של בעלים של פרויקט (roles/owner) יכול להרוס את חומר המפתח שמשמש להצפנה מצד הלקוח (CSE) ב-Google Workspace, וכך לגרום לכך שלא תהיה יותר גישה לנתונים המוצפנים.

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

אכיפה של כללי מדיניות דחייה של IAM ברמת התיקייה

מדיניות דחייה ב-IAM מאפשרת לדחות הרשאות לחשבונות משתמשים, גם אם ההרשאה ניתנת בדרך אחרת על ידי תפקיד שמוקצה לחשבון המשתמש. לדוגמה, גם אם למשתמש יש את התפקיד 'בעלים של פרויקט' (roles/owner), מדיניות דחייה ב-IAM ברמת התיקייה יכולה למנוע ממנו להשמיד או למחוק מפתחות. אם תמקמו את פרויקט Cloud HSM בתוך תיקייה ותחיל מדיניות דחייה ברמת התיקייה, תיצרו אמצעי הגנה שימנע השמדה ומחיקה של מפתחות בזמן שהמדיניות נאכפת. אי אפשר לבטל מדיניות דחייה שנאכפת בלי תפקיד כמו אדמין של מדיניות דחייה (roles/iam.denyAdmin) בתיקייה.

חשוב לוודא שתפקידי ניהול תיקיות כמו Folder Admin‏ (roles/resourcemanager.folderAdmin) ו-Deny Admin‏ (roles/iam.denyAdmin) ניתנים רק למשתמשים שאין להם גם את התפקיד Cloud KMS Admin‏ (roles/cloudkms.admin) בפרויקט שבו נמצאים המפתחות של Cloud HSM. הפרדת תפקידים זו מבטיחה שאף ישות מורשית לא תוכל גם לנהל וגם להשמיד מפתחות.

מגדירים מדיניות דחייה על סמך הגדרות הדוגמה הבאה:

displayName: Deny KMS key destruction and deletion
rules:
- description: "Denies destroy and delete permissions on Cloud KMS keys for all principals."
  denyRule:
    deniedPrincipals:
    - "principalSet://goog/public:all"
    deniedPermissions:
    - "cloudkms.googleapis.com/cryptoKeyVersions.destroy"
    - "cloudkms.googleapis.com/cryptoKeys.delete"

מידע נוסף על מדיניות דחייה ב-IAM זמין במאמר סקירה כללית על מדיניות דחייה ב-IAM.

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

בנוסף ל-IAM, אפשר לאכוף אמצעי הגנה ברמת הארגון או התיקייה באמצעות אילוצים של מדיניות הארגון. המגבלות האלה פועלות כדרישות מחייבות שמגבילות את סוגי המשאבים שאפשר ליצור ואת אופן ההגדרה שלהם. אי אפשר לעקוף את האילוצים של מדיניות הארגון שנאכפת, גם לא על ידי ישויות מורשות שיש להן את ההרשאות הנדרשות להשלמת הפעולה האסורה. אי אפשר לבטל אילוצים של מדיניות ארגונית שנאכפת בלי תפקיד כמו אדמין של מדיניות הארגון (roles/orgpolicy.policyAdmin) בארגון.

  • משך זמן מינימלי להשמדה (constraints/cloudkms.minimumDestroyScheduledDuration): קובע משך זמן מינימלי להשמדה מתוזמנת (לדוגמה, 90 או 120 ימים) לכל המפתחות בארגון או במשאב שבו המדיניות מופעלת. המגבלה הזו מונעת מכל משתמש לקצר את חלון השחזור מתחת לערך המינימלי שהוגדר.
  • השבתה לפני השמדה (constraints/cloudkms.disableBeforeDestroy): כדי לתזמן השמדה של גרסת מפתח, היא צריכה להיות במצב DISABLED. ההגבלה הזו מוסיפה שלב חובה לתהליך העבודה של ההשמדה, וכך מגדילה את החשיפה של הפעולה ביומני הביקורת.

מידע נוסף מופיע במאמר בנושא שליטה בהשמדת גרסאות של מפתחות.

הגדלת חלון השמדת המפתחות

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

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

הפקודה הבאה ב-CLI של gcloud יוצרת מפתח שמגובה ב-HSM עם משך זמן מתוזמן להשמדה של 120 ימים:

gcloud kms keys create KEY_NAME \
    --location LOCATION \
    --keyring KEY_RING \
    --purpose encryption \
    --protection-level hsm \
    --destroy-scheduled-duration 120d

מחליפים את מה שכתוב בשדות הבאים:

  • ‫KEY_NAME: השם של המפתח.
  • ‫LOCATION: המיקום ב-Cloud KMS שבו נמצא אוסף המפתחות.
  • ‫KEY_RING: השם של אוסף המפתחות שמכיל את המפתח.

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

name: organizations/ORGANIZATION_ID/customConstraints/custom.limitScheduledDestruction
resourceTypes:
- cloudkms.googleapis.com/CryptoKey
methodTypes:
- CREATE
condition: "resource.destroyScheduledDuration >= duration('7776000s') && resource.destroyScheduledDuration <= duration('10368000s')"
actionType: ALLOW
displayName: Require scheduled destruction duration between 90 and 120 days
description: Allows key creation only if the destroyScheduledDuration is between 90 and 120 days.

מחליפים את ORGANIZATION_ID במזהה המספרי של הארגון.

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

הגנה על התשתית והפרויקט

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

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

מנעול למניעת מחיקה של פרויקט מונע את מחיקת הפרויקט. גם משתמש עם התפקיד 'Project Owner' בפרויקט (roles/owner) לא יכול להשבית את הפרויקט בזמן שמנעול למניעת מחיקה פעיל. זו הדרך הכי יעילה למנוע מחיקה לא מכוונת או לא מורשית של הפרויקט שבו נמצאים המפתחות של Google Workspace.

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

הסבר על חלון הזמן לשחזור פרויקט

אם פרויקט נמחק בהצלחה – למשל, אחרי שמסירים את המנעול למניעת מחיקה על הפרויקט (בשלב טרום-השקה) – הוא נכנס לחלון השחזור של 30 יום. במהלך התקופה הזו, משתמש עם התפקיד Project Owner (roles/owner) או אדמין בארגון (roles/resourcemanager.organizationAdmin) יכול לשחזר את הפרויקט. אחרי 30 ימים, הפרויקט וכל המפתחות שבו נמחקים באופן סופי.

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

מידע נוסף על שחזור פרויקט זמין במאמר שחזור פרויקט שנמחק.

שימוש ב-VPC Service Controls

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

שמירה על ריבונות חומר המפתח באמצעות מפתחות מיובאים (BYOK)

ברוב הארגונים, מומלץ לאפשר ל-Cloud HSM ליצור ולנהל את חומר המפתח בשבילכם.

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

ייבוא מחדש לאותה גרסה

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

מידע נוסף על ייבוא מחדש של גרסת מפתח שהושמדה זמין במאמר ייבוא מחדש של גרסת מפתח שהושמדה.

הגנה מתקדמת באמצעות Cloud HSM עם דייר יחיד

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

הפרדה בין התשתית והמפתחות בפרויקטים שונים

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

מידע נוסף על Cloud HSM עם דייר יחיד זמין במאמר סקירה כללית על Cloud HSM עם דייר יחיד.

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

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

נושא משימה
כללי מדיניות הדחייה ב-IAM אכיפת מדיניות של דחייה ברמת התיקייה כדי לחסום השמדה ומחיקה של מפתחות, גם למשתמשים עם הרשאות גבוהות במיוחד.
מגבלות שקשורות למדיניות הארגון אפשר לאכוף מגבלות כדי לחייב תקופת שחזור מינימלית ולדרוש השבתה של המפתחות לפני השמדה שלהם.
תקופת ההשמדה המתוזמנת
  • יוצרים את המפתח עם הערך scheduled for destruction (מתוזמן להשמדה) שמוגדר למקסימום של 120 ימים. אפשר גם לבחור משך זמן קצר יותר, אבל חשוב לוודא שהוא ארוך מספיק כדי לאפשר שחזור של מפתחות אם הם מתוזמנים להשמדה.
  • אתם יכולים להשתמש באילוץ של מדיניות הארגון בהתאמה אישית כדי לוודא שכל המפתחות נוצרים עם משך זמן מתאים לצרכים שלכם.
שעבודים על פרויקטים אוכפים מנעולים למניעת מחיקה של פרויקטים כדי למנוע את המחיקה של הפרויקט שבו מאוחסנים מפתחות ההצפנה.
היקף האבטחה של VPC Service Controls הגדירו אזור של VPC Service Controls כדי להגביל את הגישה ל-Cloud KMS API לרשתות ולזהויות מהימנות.
ייבוא מחדש של BYOK ליצור חומר מפתח במקום ולייבא מחדש כדי לשחזר גרסאות מפתח שהושמדו בלי לשנות את שמות המשאבים.
ארכיטקטורה חוצת-פרויקטים אם אתם משתמשים ב-Single-tenant Cloud HSM, כדאי להפריד את מופע ה-Single-tenant Cloud HSM והמפתחות בין פרויקטים שונים כדי לאכוף הפרדת תפקידים.

המאמרים הבאים