הגבלת השימוש בחשבונות שירות של IAM

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

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

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

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

אילוצים מנוהלים

ההגבלות הבאות הן סוגים של הגבלות מנוהלות, שמוגדרות כ-true או כ-false. אילוצים מנוהלים מבוססים על פלטפורמת מדיניות הארגון בהתאמה אישית.

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

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

חלק מהשירותים יוצרים באופן אוטומטי חשבונות שירות שמוגדרים כברירת מחדל. Cloud de Confiance by S3NS כשיוצרים חשבון שירות שמוגדר כברירת מחדל, הוא מקבל אוטומטית את התפקיד 'עריכה' (roles/editor) בפרויקט. יכול להיות שמישהו יבחר להעניק לחשבון שירות שמוגדר כברירת מחדל תפקיד עם הרשאות גבוהות, כמו התפקיד 'עורך' או 'בעלים' (roles/owner), בשלב מאוחר יותר.

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

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

השבתת יצירה של חשבונות שירות

אפשר להשתמש באילוץ המנוהל iam.managed.disableServiceAccountCreation כדי להשבית את היצירה של חשבונות שירות חדשים. כך תוכלו לרכז את ניהול חשבונות השירות בלי להגביל את ההרשאות האחרות שיש למפתחים שלכם בפרויקטים.

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

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

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

אתם יכולים להשתמש באילוץ המנוהל iam.managed.disableServiceAccountApiKeyCreation כדי להגביל את יצירת מפתחות ההרשאה לשירותים ספציפיים. כשמשתמשים יוצרים מפתח הרשאה, הם צריכים להוסיף הגבלת API שתואמת לשירות שמותר על ידי האילוץ.

האילוץ הזה נאכף ומאפשר את Gemini API (generativelanguage.googleapis.com) כברירת מחדל.

השבתת יצירת מפתחות לחשבון שירות

אתם יכולים להשתמש באילוץ המנוהל iam.managed.disableServiceAccountKeyCreation כדי להשבית את היצירה של מפתחות חיצוניים חדשים של חשבונות שירות ושל מפתחות HMAC של Cloud Storage. כך תוכלו לשלוט בשימוש בפרטי כניסה לא מנוהלים לטווח ארוך לחשבונות שירות. כשהאילוץ הזה מוגדר, אי אפשר ליצור פרטי כניסה בניהול המשתמשים לחשבונות שירות בפרויקטים שמושפעים מהאילוץ.

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

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

אילוצים מנוהלים (גרסה קודמת) עם כללים בוליאניים

האילוצים הבאים הם סוגים של אילוצים מנוהלים מדור קודם עם כללים בוליאניים, שמוגדרים כ-true או כ-false.

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

חלק מהשירותים יוצרים באופן אוטומטי חשבונות שירות שמוגדרים כברירת מחדל. Cloud de Confiance כשיוצרים חשבון שירות שמוגדר כברירת מחדל, הוא מקבל אוטומטית את התפקיד 'עריכה' (roles/editor) בפרויקט.

כדי לשפר את האבטחה, אנחנו ממליצים מאוד להשבית את ההקצאה האוטומטית של תפקידים. כדי להשבית את ההקצאה האוטומטית של תפקידים, משתמשים באילוץ iam.automaticIamGrantsForDefaultServiceAccounts legacy managed.

השבתת יצירה של חשבונות שירות

אפשר להשתמש באילוץ המנוהל iam.disableServiceAccountCreation מדור קודם כדי להשבית את היצירה של חשבונות שירות חדשים. כך תוכלו לרכז את ניהול חשבונות השירות בלי להגביל את ההרשאות האחרות שיש למפתחים שלכם בפרויקטים.

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

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

השבתת יצירת מפתחות לחשבון שירות

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

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

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

השבתה של צירוף חשבונות שירות למשאבים בפרויקטים אחרים

כל חשבון שירות ממוקם בתוך פרויקט. אפשר להשתמש באילוץ iam.disableCrossProjectServiceAccountUsage legacy managed כדי למנוע צירוף של חשבונות שירות בפרויקט למשאבים בפרויקטים אחרים.

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

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

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

אם אוכפים את האילוץ המנוהל iam.restrictCrossProjectServiceAccountLienRemoval מדור קודם, חשבונות משתמשים יכולים למחוק את המנעול למניעת מחיקה רק אם יש להם הרשאת resourcemanager.projects.updateLiens בארגון.

מומלץ לאכוף את המגבלה הזו אם באחד מהפרויקטים שלכם מותרת התחזות לחשבון שירות בין פרויקטים.

השבתה של יצירת אשכולות עם Workload Identity

אפשר להשתמש באילוץ iam.disableWorkloadIdentityClusterCreation legacy managed כדי לדרוש שבתהליך היצירה של כל אשכול חדש של Google Kubernetes Engine, התכונה Workload Identity תהיה מושבתת. אם רוצים לשלוט באופן הדוק בגישה לחשבונות שירות בארגון, כדאי להשבית את Workload Identity בנוסף להשבתה של יצירת חשבונות שירות ויצירת מפתחות לחשבונות שירות.

אשכולות GKE קיימים שמופעל בהם איחוד זהויות של עומסי עבודה ל-GKE לא יושפעו וימשיכו לפעול כרגיל.

הגדרת אילוץ מנוהל (גרסה קודמת) עם כללים בוליאניים

gcloud resource-manager org-policies enable-enforce \
    --organization 'ORGANIZATION_ID' \
    CONSTRAINT_NAME

disable-enforce

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

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

בקטע הקוד הבא מוצגת מדיניות ארגון שמחילה את האילוץ iam.disableServiceAccountCreation legacy managed, שמונע יצירה של חשבונות שירות:

name: organizations/012345678901/policies/iam.disableServiceAccountCreation
spec:
  rules:
  - enforce: true

ניהול מגבלות (גרסה קודמת) באמצעות כללים לרשימות

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

הארכת משך החיים של אסימוני גישה מסוג OAuth 2.0

אפשר ליצור אסימון גישה מסוג OAuth 2.0 שמספק פרטי כניסה לטווח קצר לחשבון שירות. כברירת מחדל, משך החיים המקסימלי של אסימון גישה הוא שעה אחת (3,600 שניות). עם זאת, אפשר להאריך את משך החיים המקסימלי ל-12 שעות (43,200 שניות).

כדי לעשות את זה, צריך לזהות את חשבונות השירות שבהם צריך שמשך החיים של האסימונים יהיה ארוך יותר, ואז להוסיף את חשבונות השירות האלו למדיניות הארגון שכוללת את האילוץ constraints/iam.allowServiceAccountCredentialLifetimeExtension. לאחר מכן, במהלך יצירה של אסימון לחשבונות השירות האלה באמצעות API בארכיטקטורת REST, ניתן לציין משך חיים של עד 43,200 שניות (12 שעות). ב-Google Cloud CLI אין תמיכה בהגדרה של תוחלת חיים לאסימון.

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

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

כדי להגדיר מועד תפוגה, משתמשים באילוץ constraints/iam.serviceAccountKeyExpiryHourslegacy managed כדי לציין את מספר השעות שבהן מפתח חדש שנוצר יהיה בתוקף. אחרי פרק הזמן הזה, מפתח חשבון השירות יפוג ולא תוכלו להשתמש בו יותר.

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

• ‫1h: שעה אחת
• ‫8h: 8 שעות
• ‫24h: 24 שעות (יום אחד)
• ‫168h: 168 שעות (7 ימים)
• ‫336h: 336 שעות (14 ימים)
• ‫720h: 720 שעות (30 ימים)
• ‫1440h: 1,440 שעות (60 ימים)
• ‫2160h: 2,160 שעות (90 ימים)

אי אפשר למזג את האילוץ constraints/iam.serviceAccountKeyExpiryHours עם מדיניות של משאב ראשי. כדי לאכוף את ההגבלה הזו, צריך להחליף את מדיניות ההורה או להעביר אותה בירושה.

ציון ספקי זהויות חיצוניים מורשים

אם אתם משתמשים באיחוד של Workload Identity, שמאפשר לזהויות חיצוניות לגשת למשאבים Cloud de Confiance , אתם יכולים לציין אילו ספקי זהויות חיצוניים מורשים. כברירת מחדל, כל הספקים מורשים. כדי להגדיר מגבלה, משתמשים באילוץ המנוהל מדור קודם constraints/iam.workloadIdentityPoolProviders כדי לציין כתובות URI של הספקים המורשים, בפורמטים הבאים:

• ‫Amazon Web Services ‏ (AWS): https://sts.amazonaws.com

  כדי להגביל את החשבונות המורשים ב-AWS, צריך להשתמש בconstraints/iam.workloadIdentityPoolAwsAccounts מגבלת ניהול מדור קודם, כמו שמתואר בדף הזה.

• ‫Microsoft Azure: https://sts.windows.net/azure-tenant-id

• ספקי זהויות אחרים שתומכים ב-OpenID Connect‏ (OIDC): משתמשים ב-URI של המנפיק מספק הזהויות.

בחירת חשבונות AWS מותרים

אם אתם משתמשים באיחוד זהויות של עומסי עבודה, שמאפשר לזהויות חיצוניות לגשת למשאבים של Cloud de Confiance , אתם יכולים לציין לאילו חשבונות AWS מותר לגשת למשאבים שלכם. כברירת מחדל, עומסי עבודה (workloads) מכל חשבון AWS יכולים לגשת למשאבים שלכם ב- Cloud de Confiance . כדי להגביל את החשבונות המותרים ב-AWS, משתמשים באילוץ המנוהל מדור קודם constraints/iam.workloadIdentityPoolAwsAccounts כדי לציין רשימה של מזהי חשבונות מותרים.

השבתה אוטומטית של מפתחות חשופים לחשבונות שירות

‫Cloud de Confiance by S3NS מזהה מדי פעם שמפתח מסוים של חשבון שירות נחשף – לדוגמה, הוא עשוי לזהות מפתח במאגר ציבורי. כדי לציין מה Cloud de Confiance עושה עם המפתחות האלה, משתמשים במגבלה מדור קודם לניהול iam.serviceAccountKeyExposureResponse. המפתחות שנכללים במעקב הם מפתחות של חשבונות שירות עם תוקף ארוך ומפתחות API שמקושרים לחשבון שירות.

ההגבלה המנוהלת הזו מדור קודם מקבלת את הערכים הבאים של ALLOW, ולא מקבלת ערכים של DENY.

• ‫DISABLE_KEY: אם Cloud de Confiance מזהה מפתח חשוף, הוא משבית אותו באופן אוטומטי. בנוסף, המערכת יוצרת אירוע ביומני הביקורת של Cloud ושולחת הודעה על המפתח שנחשף לבעלי הפרויקט ולאנשי הקשר בנושאי אבטחה.

• ‫WAIT_FOR_ABUSE: Cloud de Confiance לא משבית באופן יזום מפתחות שנחשפו. עם זאת, Cloud de Confiance עדיין עשוי להשבית מפתחות חשופים אם הם משמשים בדרכים שמשפיעות לרעה על הפלטפורמה. גם אם המפתח שנחשף מושבת, Cloud de Confiance יוצר אירוע ביומני הביקורת של Cloud ושולח הודעה על המפתח שנחשף לבעלי הפרויקט ולאנשי הקשר בנושאי אבטחה.

כש- Cloud de Confiance מזהה מפתח שנחשף או משבית מפתח שנחשף, הוא גם מבצע את הפעולות הבאות:

• יוצר אירועים ביומני ביקורת של Cloud.

  • כש- Cloud de Confiance מזהה שחשיפה של מפתח התרחשה, נוצר אירוע שימוש לרעה ביומני אירועי שימוש לרעה.

  • כש- Cloud de Confiance משבית מפתח, יומני הביקורת מכילים את פעולת ההשבתה שבוצעה על ידי חשבון המשתמש gcp-compromised-key-response@s3ns-system.system.gserviceaccount.com.

• הגדרת השדה extendedStatus.value של המפתח שנחשף או הושבת. שדה הסטטוס המורחב כולל את המיקום שבו זוהה הדליפה.

מומלץ מאוד להגדיר את המגבלה הזו לערך DISABLE_KEY. הגדרת האילוץ הזה לערך WAIT_FOR_ABUSE מגדילה את הסיכון לשימוש לרעה במפתחות שנחשפו.

אם מחליטים להגדיר את האילוץ לערך WAIT_FOR_ABUSE, מומלץ להירשם לאירועים ביומני הביקורת של Cloud, לבדוק את פרטי אנשי הקשר בנושא אבטחה באנשי קשר חיוניים ולוודא שאנשי הקשר בנושא אבטחה מגיבים להתראות בזמן.

אי אפשר למזג את האילוץ iam.serviceAccountKeyExposureResponse עם מדיניות אב. כדי לאכוף את ההגבלה הזו, צריך להחליף את מדיניות ההורה.

הגדרת הגבלה מנוהלת (גרסה קודמת) באמצעות כללי רשימה

gcloud resource-manager org-policies allow \
    CONSTRAINT_NAME \
    VALUE_1 [VALUE_N ...] \
    --organization=ORGANIZATION_ID \

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

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

בקטע הקוד הבא מוצגת מדיניות ארגון שמחילה את המגבלה iam.allowServiceAccountCredentialLifetimeExtension של ניהול מדור קודם, שמאריכה את משך החיים המקסימלי של אסימוני גישה מסוג OAuth 2.0 עבור חשבונות שירות שמופיעים ברשימה:

name: organizations/012345678901/policies/iam.allowServiceAccountCredentialLifetimeExtension
spec:
  rules:
  - values:
      allowedValues:
      - SERVICE_ACCOUNT_ADDRESS

החלת אילוצים באופן מותנה באמצעות תגים

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

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

הודעות שגיאה

השבתת יצירה של חשבונות שירות

אם iam.disableServiceAccountCreation נאכף, יצירת חשבון שירות תיכשל עם השגיאה:

FAILED_PRECONDITION: Service account creation is not allowed on this project.

השבתת יצירה של מפתחות API שמשויכים לחשבונות שירות

אם נאכף iam.managed.disableServiceAccountApiKeyCreation, יצירת מפתח API שמקושר לחשבון שירות תיכשל עם השגיאה:

FAILED_PRECONDITION: Operation denied by org policy:
["constraints/iam.managed.disableServiceAccountApiKeyCreation":
"When enforced, disables creation of API Keys bound to service accounts."]

השבתת יצירת מפתחות לחשבון שירות

אם iam.disableServiceAccountKeyCreation נאכף, יצירת חשבון שירות תיכשל עם השגיאה:

FAILED_PRECONDITION: Key creation is not allowed on this service account.

השבתה של יצירת אשכולות עם Workload Identity

אם iam.disableWorkloadIdentityClusterCreation נאכף, יצירת אשכול GKE עם Workload Identity מופעלת תיכשל עם השגיאה:

FAILED_PRECONDITION: Workload Identity is disabled by the organization
policy constraints/iam.disableWorkloadIdentityClusterCreation. Contact your
administrator to enable this feature.

פתרון בעיות מוכרות

חשבונות שירות שמוגדרים כברירת מחדל

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

• Compute Engine
• GKE
• App Engine
• Dataflow

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

כדי לפתור את הבעיה:

1. מסירים את המגבלה iam.disableServiceAccountCreation באופן זמני.
2. מפעילים את השירותים הרצויים.
3. יוצרים חשבונות שירות נוספים שרוצים.
4. ולבסוף, מחילים מחדש את המגבלה.