‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הגדרת בקרת גישה מבוססת-הקשר לחשבונות שירות

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

מגבלות

ההגבלות הבאות חלות על כללי מדיניות לבקרת גישה מבוססת-הקשר בחשבונות שירות:

אי אפשר להשתמש במאפיינים שמבוססים על רשת או על כתובת IP לקישור חשבונות שירות, אם חשבון השירות ישמש להפעלת תהליכי עבודה ול-Cloud Scheduler.
אי אפשר לחסום חיבורים לאשכולות פרטיים של GKE באמצעות kubectl, ול-Cloud SQL באמצעות שרת proxy ל-Auth, באמצעות מדיניות של בקרת גישה מבוססת-הקשר.
אם רמת גישה שמקושרת לחשבון שירות מכילה מאפיינים שלא נתמכים, כמו מאפייני Device, הגישה ל-API נדחית.
חשבונות שירות לא תומכים ברמות גישה בהיקף מוגבל.

אם אתם משתמשים ב-Cloud Build וב-Cloud Run, מומלץ להשתמש בתכונות המובנות הבאות של VPC:

ב-Cloud Run, משתמשים בחיבור לרשת (VPC) מאפליקציית serverless.
ב-Cloud Build, משתמשים במאגרי משאבים פרטיים.

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

צריך לוודא שיש לכם Google Cloud ארגון ולפחות Google Cloud פרויקט אחד.

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

התקינו את ה-CLI של Google Cloud.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

יוצרים או בוחרים Google Cloud פרויקט.

תפקידים שנדרשים כדי לבחור או ליצור פרויקט

Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

יוצרים Google Cloud פרויקט:
```
gcloud projects create PROJECT_ID
```
מחליפים את PROJECT_ID בשם של פרויקט Google Cloud שיוצרים.
בוחרים את הפרויקט שיצרתם: Google Cloud
```
gcloud config set project PROJECT_ID
```
מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

מוודאים שהחיוב מופעל בפרויקט Google Cloud .

התקינו את ה-CLI של Google Cloud.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

יוצרים או בוחרים Google Cloud פרויקט.

תפקידים שנדרשים כדי לבחור או ליצור פרויקט

Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

יוצרים Google Cloud פרויקט:
```
gcloud projects create PROJECT_ID
```
מחליפים את PROJECT_ID בשם של פרויקט Google Cloud שיוצרים.
בוחרים את הפרויקט שיצרתם: Google Cloud
```
gcloud config set project PROJECT_ID
```
מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

מוודאים שהחיוב מופעל בפרויקט Google Cloud .

מעדכנים את הרכיבים של Google Cloud CLI:
```
gcloud components update --quiet
```
יוצרים חשבון שירות בפרויקט, אם עדיין אין לכם חשבון כזה. חשבון השירות הזה הוא היעד של מדיניות הגישה.

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

בקטע הזה מוסבר על התפקידים בניהול זהויות והרשאות גישה (IAM) שנדרשים לשימוש בבקרת גישה מבוססת-הקשר.

תפקידים ברמת הפרויקט

כדי לקבל את ההרשאה שנדרשת ברמת הפרויקט, צריך לבקש מהאדמין להקצות לחשבון המשתמש או לחשבון השירות את תפקיד ה-IAM‏ Service Account Admin ‏ (roles/iam.serviceAccountAdmin). כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

התפקיד המוגדר מראש הזה מכיל את ההרשאה the required permissions, שנדרשת ברמת הפרויקט.

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

תפקידים ברמת הארגון

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

אדמין של קישוריות ל-Cloud (roles/accesscontextmanager.gcpAccessAdmin)
אדמין ב-Access Context Manager (roles/accesscontextmanager.policyAdmin)

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

התפקיד המוגדר מראש הזה מכיל את ההרשאה the required permissions, שנדרשת ברמת הארגון.

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

קישור מדיניות גישה לרמות שונות של משאבים

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

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

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

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

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

בקטע הזה מפורטות רמות הגישה שנתמכות בחשבונות שירות.

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

תת-רשתות IP, שמבוססות על כתובת ה-IP הגלויה.
רשתות VPC, שמבוססות על כתובת ה-IP הפרטית.
מיקום גיאוגרפי, שמבוסס על כתובת ה-IP הציבורית.

כשחשבון השירות שולח בקשה לממשקי API של Google Cloud Google, בקרת הגישה מבוססת-הקשר בודקת את הבקשה ומשווה את כתובת ה-IP של הבקשה לכתובות ה-IP שצוינו במדיניות בקרת הגישה מבוססת-הקשר. אם כתובות ה-IP תואמות, הקריאה ל-API מותרת. אם כתובת ה-IP לא תואמת, הקריאה ל-API נדחית.
רמת גישה בהתאמה אישית עם ביטוי של Common Expression Language ‏ (CEL). הביטוי צריך להחזיר את הערך true כדי לאפשר גישה ואת הערך false כדי לדחות גישה.

הביטוי הבא ב-CEL שימושי להגבלת הגישה לפי חשבונות שירות.

הערך של הביטוי הוא true אם הבקשה הגיעה ממספר פרויקט אחד או יותר שצוינו:
```
    expression: "originatesFromProjects(origin, [PROJECT_NUMBER, ...])"
    
```
‫originatesFromProjects בודקת אם הבקשה מגיעה מרשת שמשויכת לפרויקט שצוין, ואם הבקשה מגיעה מכתובת IP פרטית.
השעה ביום, שמבוססת על השעה והתאריך של הבקשה באזור זמן שצוין.

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

יצירה של רמת גישה

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

פועלים לפי ההוראות ליצירת רמת גישה בסיסית או יצירת רמת גישה בהתאמה אישית.
חשוב לשים לב לשם המלא של מדיניות הגישה, שמופיע בפורמט הבא: accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

יצירת קשר בין משתמש לגישה

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

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

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

gcloud

מקשרים את רמת הגישה לחשבון שירות באמצעות ה-CLI של gcloud.

gcloud access-context-manager cloud-bindings create \
    --organization=ORGANIZATION_ID \
    --service-account=SERVICE_ACCOUNT_NAME@SERVICE_ACCOUNT_PROJECT_ID.iam.gserviceaccount.com \
    --level=accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME

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

‫ORGANIZATION_ID: מזהה הארגון ב- Google Cloud
SERVICE_ACCOUNT_NAME: השם, ולא כתובת האימייל, של חשבון השירות של היעד
‫SERVICE_ACCOUNT_PROJECT_ID: מזהה הפרויקט שמכיל את חשבון השירות של היעד
‫POLICY_ID: המזהה של מדיניות הגישה
‫ACCESS_LEVEL_NAME: השם של רמת הגישה שיצרתם

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

‫API בארכיטקטורת REST

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

יוצרים קובץ request.json עם התוכן הבא:
```
{
  "principal": {
    "serviceAccount": "SERVICE_ACCOUNT_NAME@SERVICE_ACCOUNT_PROJECT_ID.iam.gserviceaccount.com"
  },
  "accessLevels": ["accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME"]
}
```
מחליפים את מה שכתוב בשדות הבאים:
- SERVICE_ACCOUNT_NAME: השם, ולא כתובת האימייל, של חשבון השירות של היעד
- ‫SERVICE_ACCOUNT_PROJECT_ID: מזהה הפרויקט שמכיל את חשבון השירות של היעד
- ‫POLICY_ID: המזהה של מדיניות הגישה
- ‫ACCESS_LEVEL_NAME: השם של רמת הגישה שיצרתם

מריצים את הפקודה הבאה:

curl -H "X-Goog-User-Project: PROJECT_ID" -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d @request.json \
  "https://accesscontextmanager.googleapis.com/v1/organizations/ORGANIZATION_ID/gcpUserAccessBindings"

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

‫PROJECT_ID: מזהה הפרויקט שבו אתם משתמשים כדי לבצע את הקריאות ל-API
‫ORGANIZATION_ID: מזהה הארגון ב- Google Cloud.

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

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

gcloud

כדי לקשר את רמת הגישה לכל חשבונות השירות בפרויקט באמצעות ה-CLI של gcloud, מריצים את הפקודה הבאה:

gcloud access-context-manager cloud-bindings create \
  --organization=ORGANIZATION_ID \
  --service-account-project-number=PROJECT_NUMBER \
  --level=accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME

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

‫ORGANIZATION_ID: מזהה הארגון ב- Google Cloud
‫PROJECT_NUMBER: מספר הפרויקט שמכיל את כל חשבונות השירות שרוצים לקשר אליהם את הגישה
‫POLICY_ID: המזהה של מדיניות הגישה
‫ACCESS_LEVEL_NAME: השם של רמת הגישה שיצרתם.

‫API בארכיטקטורת REST

כדי לקשר את רמת הגישה לכל חשבונות השירות בפרויקט באמצעות API בארכיטקטורת REST:

יוצרים קובץ request.json עם התוכן הבא:
```
{
  "principal": {
    "serviceAccountProjectNumber": "PROJECT_NUMBER"
  },
  "accessLevels": ["accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME"]
}
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_NUMBER: מספר הפרויקט שמכיל את כל חשבונות השירות שרוצים לקשר אליהם את הגישה
- ‫POLICY_ID: המזהה של מדיניות הגישה
- ‫ACCESS_LEVEL_NAME: השם של רמת הגישה שיצרתם.

מריצים את הפקודה הבאה:

curl -H "X-Goog-User-Project: PROJECT_ID" -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json; charset=utf-8" \
-d @request.json \
"https://accesscontextmanager.googleapis.com/v1/organizations/ORGANIZATION_ID/gcpUserAccessBindings"

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

‫PROJECT_ID: מזהה הפרויקט שבו אתם משתמשים כדי לשלוח קריאות ל-API
‫ORGANIZATION_ID: מזהה הארגון ב- Google Cloud

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

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

שימוש במצב פרימטר לבדיקות

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

קישור מדיניות גישה במצב הרצת בדיקה

gcloud

כדי לקשר מדיניות גישה במצב הרצת בדיקה, מחליפים את הפרמטר --level בפרמטר --dry-run-level, בפורמט הבא:

--dry-run-level=accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME

‫API בארכיטקטורת REST

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

{
"principal": {
  "serviceAccountProjectNumber": "TARGET_PROJECT_NUMBER"
},
"dryRunAccessLevels": ["accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME"]
}

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

‫TARGET_PROJECT_NUMBER: מספר הפרויקט של פרויקט היעד
‫POLICY_ID: המזהה של מדיניות הגישה
‫ACCESS_LEVEL_NAME: השם של רמת הגישה

בדיקה של יומני ביקורת ב-Cloud

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

המסוף

כדי לראות את הדחיות של גישת חשבון שירות במצב הרצה יבשה של יומני הביקורת של Cloud באמצעות מסוף Google Cloud :

במסוף Google Cloud , נכנסים לדף Logs Explorer:

כניסה אל Logs Explorer

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

במסוף Google Cloud , בוחרים את הפרויקט או הארגון.

בשדה Log query (שאילתת יומן), מזינים את השאילתה הבאה:

protoPayload.serviceName="contextawareaccess.googleapis.com"
protoPayload.metadata.dryRunEvaluationResult:DENIED
SEARCH("`SERVICE_ACCOUNT_NAME`")

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

gcloud

כדי לראות את הדחיות של גישת חשבון שירות במצב פרימטר לבדיקות של Cloud Audit Logs באמצעות ה-CLI של gcloud:

gcloud logging read \
'protoPayload.serviceName="contextawareaccess.googleapis.com" AND
 protoPayload.metadata.dryRunEvaluationResult:DENIED AND
 SEARCH("`SERVICE_ACCOUNT_NAME`")' \
  --organization=ORGANIZATION_ID

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

‫ORGANIZATION_ID: מזהה הארגון
SERVICE_ACCOUNT_NAME: השם של חשבון השירות

הפקודה gcloud logging read תומכת בדגל --freshness כדי להציג מידע על רישום ביומן במהלך מסגרות זמן יחסיות. לדוגמה, אם מוסיפים את --freshness=3h לפקודה, אפשר לראות את הערכים ביומן של מצב ההרצה היבשה ב-3 השעות האחרונות.

פתרון בעיות

בקטע הזה מוסבר איך לפתור בעיות בגישה מודעת-הקשר לחשבונות שירות.

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

בדיקת יומני ביקורת של Cloud.

כדי לקבל מידע נוסף, אפשר להשתמש בשאילתת היומן הבאה ולעיין ברשומות ביומן.
```
protoPayload.serviceName="contextawareaccess.googleapis.com"
```
בודקים את שם המשאב של רמת הגישה שמדווחת בקרת גישה מבוססת-הקשר כשהיא מתעדת אירועי אכיפה.
מוודאים שרמת הגישה היא משאב ברמת הארגון.
חשוב לוודא שרמת הגישה במדיניות הגישה מבוססת על מאפיינים שנתמכים בחשבונות שירות.
מוודאים שמדיניות הגישה משויכת לחשבון השירות הרצוי.
מוודאים שזהות המשתמש לא מוגבלת על ידי מדיניות גישה. זה יכול לקרות כשזהות משתמש היא חברה בקבוצת Google שיש לה מדיניות גישה מקושרת. המדיניות הזו עשויה להגביל את הגישה של המשתמש, וכך למנוע את זרימת השיחה לחשבון השירות.
צריך לפנות לאדמין האבטחה.

הגישה נדחתה

הגישה נדחתה מהסיבות הבאות:

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

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

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

איך מנהלים את קישורי הגישה

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

מגבלות

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

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

תפקידים ברמת הפרויקט

תפקידים ברמת הארגון

קישור מדיניות גישה לרמות שונות של משאבים

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

יצירה של רמת גישה

יצירת קשר בין משתמש לגישה

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

gcloud

‫API בארכיטקטורת REST

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

gcloud

‫API בארכיטקטורת REST

שימוש במצב פרימטר לבדיקות

קישור מדיניות גישה במצב הרצת בדיקה

gcloud

‫API בארכיטקטורת REST

בדיקה של יומני ביקורת ב-Cloud

המסוף

gcloud

פתרון בעיות

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

הגישה נדחתה

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

הגדרת בקרת גישה מבוססת-הקשר לחשבונות שירות