שליטה בשימוש ב-Autokey

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

התרחישים הבאים נתמכים:

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

IAM לעומת מדיניות הארגון

גם IAM וגם מדיניות הארגון מאפשרים לכם להגדיר שכבות הגנה כדי לשלוט באופן השימוש ב-Cloud KMS Autokey בארגון שלכם.

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

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

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

לפני שמתחילים

כדי לקבל את ההרשאות שדרושות לכם כדי לשלוט בשימוש ב-Autokey, אתם צריכים לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בארגון:

• הגדרת מדיניות ארגונית: אדמין של מדיניות ארגונית (roles/orgpolicy.policyAdmin)
• הגדרת כללי מדיניות דחייה ב-IAM: אדמין דחייה (roles/iam.denyAdmin)

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

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

שימוש בכללי מדיניות דחייה ב-IAM כדי לשלוט ב-Autokey

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

במאמר דחיית הגישה למשאבים מוסבר איך ליצור כללי מדיניות דחייה ב-IAM.

בטבלה הבאה מפורטים כמה תרחישי שימוש לדוגמה במדיניות דחייה ב-IAM, כולל הרשאות שאפשר לדחות כדי לשלוט ב-Autokey בארגון, וההשפעה של דחיית כל הרשאה.

שימוש באילוצים מותאמים אישית של מדיניות הארגון כדי לשלוט ב-Autokey

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

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

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

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

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

    name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictAutokeyKeyStorage
    resourceTypes:
    - cloudkms.googleapis.com/AutokeyConfig
    methodTypes:
    - CREATE
    - UPDATE
    condition: "resource.keyProjectResolutionMode == 'KEY_PROJECT_RESOLUTION_MODE')"
    actionType: DENY
    displayName: Restrict Autokey key storage mode
    description: >
      Prevent creation or update of AutokeyConfig resources with
      `KEY_PROJECT_RESOLUTION_MODE` key resolution mode.

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

איסור יצירת הגדרות של Autokey בתיקייה

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

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

    name: organizations/ORGANIZATION_ID/customConstraints/custom.noNewAutokeyConfigFolder
    resourceTypes:
    - cloudkms.googleapis.com/AutokeyConfig
    methodTypes:
    - CREATE
    condition: "resource.name == 'folders/FOLDER_ID/autokeyConfig'"
    actionType: DENY
    displayName: Prohibit Autokey within FOLDER_ID
    description: >
      Prevent creation of new AutokeyConfig resources within
      folders/FOLDER_ID.

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

• ‫ORGANIZATION_ID: המזהה של הארגון.
• ‫FOLDER_ID עם המזהה של התיקייה שבה רוצים לחסום את Autokey.

איסור יצירת הגדרת Autokey בארגון

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

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

    name: organizations/ORGANIZATION_ID/customConstraints/custom.noNewAutokeyConfigOrg
    resourceTypes:
    - cloudkms.googleapis.com/AutokeyConfig
    methodTypes:
    - CREATE
    condition: "resource.name.endsWith('/autokeyConfig')"
    actionType: DENY
    displayName: Prohibit Autokey within ORGANIZATION_ID
    description: >
      Prevent creation of new AutokeyConfig resources within organization
      ORGANIZATION_ID.

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

איסור שינוי ההגדרה של Autokey בתיקייה

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

ההגדרה הבאה של מגבלה לדוגמה אוסרת על יצירה או עדכון של משאבי AutokeyConfig בתיקייה עם שם.

    name: organizations/ORGANIZATION_ID/customConstraints/custom.noChangeAutokeyConfigFolder
    resourceTypes:
    - cloudkms.googleapis.com/AutokeyConfig
    methodTypes:
    - CREATE
    - UPDATE
    condition: "resource.name == 'folders/FOLDER_ID/autokeyConfig'"
    actionType: DENY
    displayName: Prohibit Autokey within FOLDER_ID
    description: >
      Prevent creation or update of AutokeyConfig resources within
      folders/FOLDER_ID.

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

• ‫ORGANIZATION_ID: המזהה של הארגון.
• ‫FOLDER_ID עם המזהה של התיקייה שבה רוצים לחסום את Autokey.

איסור שינוי ההגדרה של Autokey בארגון

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

ההגדרה הבאה של אילוץ לדוגמה אוסרת על יצירה או עדכון של משאבי AutokeyConfig בכל הארגון.

    name: organizations/ORGANIZATION_ID/customConstraints/custom.noChangeAutokeyConfigOrg
    resourceTypes:
    - cloudkms.googleapis.com/AutokeyConfig
    methodTypes:
    - CREATE
    - UPDATE
    condition: condition: "resource.name.endsWith('/autokeyConfig')"
    actionType: DENY
    displayName: Prohibit Autokey within ORGANIZATION_ID
    description: >
      Prevent creation or update of AutokeyConfig resources within
      ORGANIZATION_ID.

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

אפשר להגדיר רק את DISABLED Autokey

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

    name: organizations/ORGANIZATION_ID/customConstraints/custom.onlyDisabledAutokeyConfig
    resourceTypes:
    - cloudkms.googleapis.com/AutokeyConfig
    methodTypes:
    - CREATE
    - UPDATE
    condition: "resource.keyProjectResolutionMode=='DISABLED'"
    actionType: ALLOW
    displayName: Prohibit Autokey within the organization
    description: >
      Prevent creation or update of `AutokeyConfig` resources within
      organization ORGANIZATION_ID unless the `keyProjectResolutionMode`
      is `DISABLED`.

איסור הגדרת Autokey ברמת הפרויקט

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

    name: organizations/ORGANIZATION_ID/customConstraints/custom.noAutokeyConfigProject
    resourceTypes:
    - cloudkms.googleapis.com/AutokeyConfig
    methodTypes:
    - CREATE
    - UPDATE
    condition: "resource.name.startsWith('projects/')"
    actionType: DENY
    displayName: Block project-level Autokey within the organization
    description: >
      Prevent creation or update of `AutokeyConfig` resources on projects within
      organization ORGANIZATION_ID. Existing project-level AutokeyConfig
      resources remain in effect, but all other projects must inherit the
      AutokeyConfig from their parent folder.

תרחישים לדוגמה

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

דרישה ליצירת מפתחות על ידי Autokey

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

כדי לאכוף את השימוש ב-Autokey בתיקייה, פועלים לפי השלבים הבאים:

1. חסימה של יצירת מפתחות באופן ידני בפרויקט המפתחות על ידי אכיפה של מדיניות דחייה ב-IAM. במדיניות הדחייה, דוחים את ההרשאה cloudkms.cryptoKeys.create לכל הגורמים המורשים, למעט סוכן השירות של Cloud KMS. אם התיקייה משתמשת באחסון מפתחות בפרויקט ייעודי, צריך להחיל את מדיניות הדחייה על פרויקט המפתחות הייעודי. אם התיקייה משתמשת באחסון מפתחות באותו פרויקט, צריך להחיל את מדיניות הדחייה על פרויקטי המשאבים.

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

2. דרישה להגנה על משאבים חדשים שנוצרו בתיקייה באמצעות CMEK על ידי אכיפת האילוץ constraints/gcp.restrictNonCmekServices.

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

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

מניעת שימוש ב-Autokey באופן מלא

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

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

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

2. אפשר לחסום משתמשים מהגדרת Autokey על ידי אכיפה של מדיניות דחייה ב-IAM. במדיניות הדחייה, דוחים את ההרשאה cloudkms.autokeyConfigs.update לכל החשבונות הראשיים. אם Autokey מושבת בכל מקום ואף גורם לא יכול לשנות משאבי AutokeyConfig, ‏ Autokey יישאר מושבת לחלוטין.

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

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

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

• מידע נוסף על מדיניות הארגון לגבי CMEK
• מידע נוסף על כללי מדיניות של IAM לסירוב גישה
• מידע נוסף על השירות של מדיניות הארגון
• מידע נוסף על אילוצים מותאמים אישית של מדיניות הארגון