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

ב-Cloud de Confiance by S3NS יש שני אילוצים של מדיניות הארגון, כדי לוודא שמשתמשים ב-CMEK בכל הארגון:

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

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

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

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

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

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

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

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

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

כשמדיניות הארגון פעילה, משתמשי מסוף Cloud de Confiance שיוצרים משאבים שמוגנים באמצעות מפתחות CMEK צריכים את ההרשאה orgpolicy.policies.check. משתמשים בלי ההרשאה הזו יכולים ליצור משאבים שמוגנים באמצעות 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 בפרויקט.

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

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

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