מדיניות הארגון ל-CMEK

‫Cloud de Confiance by S3NS ‏Google Cloud מציעה שני אילוצים של מדיניות הארגון כדי להבטיח שימוש ב-CMEK בכל הארגון:

• ‫constraints/gcp.restrictNonCmekServices משמש לדרישה של הגנה באמצעות CMEK.
• ‫constraints/gcp.restrictCmekCryptoKeyProjects משמש להגבלת המפתחות ב-Cloud KMS שמשמשים להגנה באמצעות CMEK.

מדיניות הארגון ל-CMEK חלה רק על משאבים חדשים שנוצרו בשירותים Cloud de Confiance נתמכים.

התפקידים הנדרשים

כדי לוודא שלכל משתמש יש את ההרשאות הנדרשות לבדיקת מדיניות הארגון בזמן יצירת משאבים, צריך לבקש מהאדמין להקצות לכל משתמש בארגון את תפקיד ה-IAM‏ Organization Policy Viewer (roles/orgpolicy.policyViewer). כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

ההרשאות הנדרשות

כדי לבדוק את מדיניות הארגון כשיוצרים משאבים, נדרשות ההרשאות הבאות:

• כדי לראות את הפרטים המלאים של מדיניות הארגון: orgpolicy.policy.get
• כדי לבדוק את מדיניות הארגון כשיוצרים משאבים: orgpolicy.policies.check

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

כשמדיניות הארגון פעילה, נדרשת ההרשאה orgpolicy.policies.check ממשתמשי המסוף של Cloud de Confiance שיוצרים משאבים שמוגנים על ידי מפתחות CMEK. משתמשים שאין להם את ההרשאה הזו יכולים ליצור משאבים שמוגנים באמצעות CMEK באמצעות מסוף Cloud de Confiance , אבל הם יכולים לבחור מפתח CMEK שלא מותר על ידי האילוץ restrictCmekCryptoKeyProjects. אם בוחרים מפתח שלא עומד באילוץ הזה, בסופו של דבר יצירת המשאב תיכשל.

דרישה להגנה באמצעות CMEK

כדי לדרוש הגנה באמצעות CMEK בארגון, צריך להגדיר את constraints/gcp.restrictNonCmekServices מדיניות הארגון.

כאילוץ מסוג רשימה, הערכים המקובלים לאילוץ הזה הם Cloud de Confiance by S3NSשמות של שירותים (לדוגמה, bigquery.googleapis.com). כדי להשתמש באילוץ הזה, צריך לספק רשימה של Cloud de Confiance by S3NS שמות של שירותים ולהגדיר את האילוץ ל-Deny (דחייה). ההגדרה הזו חוסמת את יצירת המשאבים בשירותים האלה אם המשאב לא מוגן על ידי CMEK. במילים אחרות, בקשות ליצירת משאב בשירות לא יצליחו בלי לציין מפתח Cloud KMS. בנוסף, האילוץ הזה חוסם את ההסרה של הגנת CMEK ממשאבים בשירותים האלה. המגבלה הזו יכולה לחול רק על שירותים נתמכים.

הגבלת השימוש במפתחות Cloud KMS ל-CMEK

כדי להגביל את מפתחות Cloud KMS שמשמשים להגנה באמצעות CMEK, צריך להגדיר את האילוץ constraints/gcp.restrictCmekCryptoKeyProjects.

כאילוץ של רשימה, הערכים המקובלים הם מחווני היררכיית משאבים (לדוגמה, projects/PROJECT_ID,‏ under:folders/FOLDER_ID ו-under:organizations/ORGANIZATION_ID). כדי להשתמש באילוץ הזה, צריך להגדיר רשימה של מחווני היררכיית משאבים ולהגדיר את האילוץ ל-Allow (אישור). ההגדרה הזו מגבילה את השירותים הנתמכים כך שאפשר לבחור מפתחות CMEK רק מתוך הפרויקטים, התיקיות והארגונים שמופיעים ברשימה. בקשות ליצירת משאבים שמוגנים באמצעות CMEK בשירותים מוגדרים לא יצליחו ללא מפתח Cloud KMS מאחד המשאבים המותרים. ההגבלה הזו חלה על כל השירותים הנתמכים, אם היא מוגדרת.

שירותים נתמכים

חריגים לאכיפה לפי סוג המשאב

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

תצורות לדוגמה

בדוגמאות להגדרות, נניח שהיררכיית המשאבים בארגון לדוגמה היא כזו:

דרישה לשימוש ב-CMEK והגבלת מפתחות לפרויקט

נניח שאתם רוצים לדרוש הגנה באמצעות CMEK לכל המשאבים של Cloud Storage ב-projects/5 ולוודא שאפשר להשתמש רק במפתחות שמגיעים מ-projects/4.

כדי לדרוש הגנה באמצעות CMEK לכל המשאבים החדשים ב-Cloud Storage, משתמשים בהגדרת מדיניות הארגון הבאה:

• מדיניות הארגון: constraints/gcp.restrictNonCmekServices
• הקישור בוצע בתאריך: projects/5
• סוג המדיניות: דחייה
• ערך המדיניות: storage.googleapis.com

כדי לוודא שנעשה שימוש רק במפתחות מ-projects/4, משתמשים בהגדרה הבאה:

• מדיניות הארגון: constraints/gcp.restrictCmekCryptoKeyProjects
• הקישור בוצע בתאריך: projects/5
• סוג המדיניות: הרשאה
• ערך המדיניות: projects/4

דרישה לשימוש ב-CMEK והגבלת המפתחות לתיקייה

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

כדי לדרוש הגנה נוספת באמצעות CMEK למשאבי Cloud SQL ו-Cloud Storage חדשים בכל מקום מתחת ל-folders/3:

• מדיניות הארגון: constraints/gcp.restrictNonCmekServices
• הקישור בוצע בתאריך: folders/3
• סוג המדיניות: דחייה
• ערכי מדיניות: sqladmin.googleapis.com, ‏ storage.googleapis.com

כדי לוודא שנעשה שימוש רק במפתחות מפרויקטים של Cloud KMS שנמצאים תחת folders/2:

• מדיניות הארגון: constraints/gcp.restrictCmekCryptoKeyProjects
• הקישור בוצע בתאריך: folders/3
• סוג המדיניות: הרשאה
• ערך המדיניות: under:folders/2

דרישה ל-CMEK בארגון

כדי לדרוש שימוש ב-CMEK בכל מקום בארגון (בשירותים נתמכים), מגדירים את האילוץ constraints/gcp.restrictNonCmekServices עם ההגדרה הבאה:

• מדיניות הארגון: constraints/gcp.restrictNonCmekServices
• הקישור בוצע בתאריך: organizations/1
• סוג המדיניות: דחייה
• ערכי מדיניות: (כל השירותים הנתמכים)

מגבלות

אם משתמשים במסוף Cloud de Confiance כדי ליצור משאב, יכול להיות שלא תהיה אפשרות להשתמש באפשרויות הצפנה אחרות מלבד CMEK כש-constraints/gcp.restrictNonCmekServices מוגדר לפרויקט ולשירות. ההגבלה של מדיניות הארגון בנושא CMEK גלויה רק אם לחשבון הלקוח הוקצתה הרשאת IAM‏ orgpolicy.policy.get בפרויקט.

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

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

דוגמאות נוספות ליצירת מדיניות ארגון עם אילוצים מסוימים מופיעות במאמר בנושא שימוש באילוצים.