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

במדריך הזה מוסבר איך להגדיר בקרת גישה מבוססת-הקשר כדי לאבטח את הגישה של חשבון השירות לממשקי ה-API של Cloud de Confiance by S3NS , על סמך רמות הגישה שאתם מגדירים.

מגבלות

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

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

  • כללי מדיניות של בקרת גישה מבוססת-הקשר לא יכולים לחסום חיבורים לאשכולות פרטיים של Google Kubernetes Engine (GKE) באמצעות kubectl, או ל-Cloud SQL באמצעות Auth Proxy.

  • אם רמת הגישה שאתם מקשרים לחשבון שירות מכילה מאפיינים לא נתמכים, כמו מאפייני Device, בקרת הגישה מבוססת-ההקשר תדחה את הגישה ל-API.

  • בחשבונות שירות אין תמיכה ברמות גישה מוגדרות היקף.

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

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

  1. לוודא שיש לכם ארגון ב-Cloud de Confiance ופרויקט אחד לפחות ב-Cloud de Confiance .
  2. התקינו את ה-CLI של Google Cloud.

  3. הגדירו שה-CLI של gcloud ישתמש בזהות המאוחדת שלכם.

    איך נכנסים ל-CLI של gcloud באמצעות הזהות המאוחדת?

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

    gcloud init
  5. יוצרים או בוחרים פרויקט ב- Cloud de Confiance .

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

    • בחירת פרויקט: כדי לבחור פרויקט לא נדרש תפקיד IAM ספציפי – אתם יכולים לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים?
    • יוצרים פרויקט ב- Cloud de Confiance :

      gcloud projects create PROJECT_ID

      מחליפים את PROJECT_ID בשם של הפרויקט ב- Cloud de Confiance שאתם יוצרים.

    • בוחרים את הפרויקט שיצרתם ב- Cloud de Confiance :

      gcloud config set project PROJECT_ID

      מחליפים את PROJECT_ID בשם הפרויקט ב- Cloud de Confiance .

  6. מוודאים שהחיוב מופעל בפרויקט ב- Cloud de Confiance .

  7. מפעילים את ממשקי ה-API של IAM, של Access Context Manager ושל Resource Manager, אם הם עדיין לא מופעלים:

    התפקידים שנדרשים כדי להפעיל ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    gcloud services enable accesscontextmanager.googleapis.com cloudresourcemanager.googleapis.com iam.googleapis.com
  8. מעדכנים את הרכיבים של Google Cloud CLI:
    gcloud components update --quiet
  9. אם עדיין אין לכם חשבון שירות, צרו חשבון שירות בפרויקט. חשבון השירות הזה הוא היעד של מדיניות בקרת הגישה מבוססת-ההקשר.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • רמת גישה בהתאמה אישית עם ביטוי ב-Common Expression Language ‏ (CEL). הביטוי חייב להחזיר את הערך true כדי לאפשר גישה, ואת הערך false כדי לדחות את הגישה.

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

    הביטוי מקבל את הערך true אם הבקשה הגיעה ממספר פרויקט אחד או יותר שצוינו:

        expression: "originatesFromProjects(origin, ['projects/PROJECT_NUMBER'])"
        

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

  • השעה ביום, שמבוססת על השעה והתאריך של הבקשה באזור זמן מסוים.

    למידע נוסף, קראו את המאמר הגדרת תנאי גישה לפי שעה ויום.

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

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

  1. פועלים לפי ההוראות ליצירת רמת גישה בסיסית או ליצירת רמת גישה בהתאמה אישית.

  2. שימו לב לשם המלא של רמת הגישה, שמופיע בפורמט הבא: 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.s3ns.iam.gserviceaccount.com \
    --level=accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME

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

  • ‫ORGANIZATION_ID: מזהה הארגון ב- Cloud de Confiance.
  • ‫SERVICE_ACCOUNT_NAME: המזהה של חשבון השירות המטורגט (החלק בכתובת האימייל שלפני הסמל @).
  • ‫SERVICE_ACCOUNT_PROJECT_ID: מזהה הפרויקט שמכיל את חשבון השירות המיועד.
  • ‫POLICY_ID: המזהה של מדיניות בקרת הגישה ב-Access Context Manager.
  • ‫ACCESS_LEVEL_NAME: השם של רמת הגישה שיצרתם.

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

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

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

  1. יוצרים קובץ request.json עם התוכן הבא:

    {
      "principal": {
        "serviceAccount": "SERVICE_ACCOUNT_NAME@SERVICE_ACCOUNT_PROJECT_ID.s3ns.iam.gserviceaccount.com"
      },
      "accessLevels": ["accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME"]
    }
    

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

    • ‫SERVICE_ACCOUNT_NAME: המזהה של חשבון השירות המטורגט (החלק בכתובת האימייל שלפני הסמל @).

    • ‫SERVICE_ACCOUNT_PROJECT_ID: מזהה הפרויקט שמכיל את חשבון השירות המיועד.

    • ‫POLICY_ID: המזהה של מדיניות הגישה ב-Access Context Manager.

    • ‫ACCESS_LEVEL_NAME: השם של רמת הגישה שיצרתם.

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

    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: מזהה הארגון ב- Cloud de Confiance.

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

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

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: מזהה הארגון ב- Cloud de Confiance.
  • ‫PROJECT_NUMBER: מספר הפרויקט שמכיל את כל חשבונות השירות שרוצים לקשר אליהם את הגישה.
  • ‫POLICY_ID: המזהה של מדיניות בקרת הגישה ב-Access Context Manager.
  • ‫ACCESS_LEVEL_NAME: השם של רמת הגישה שיצרתם.

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

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

  1. יוצרים קובץ request.json עם התוכן הבא:

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

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

    • ‫PROJECT_NUMBER: מספר הפרויקט שמכיל את כל חשבונות השירות שרוצים לקשר אליהם את הגישה.
    • ‫POLICY_ID: המזהה של מדיניות הגישה ב-Access Context Manager.
    • ‫ACCESS_LEVEL_NAME: השם של רמת הגישה שיצרתם.
  2. מריצים את הפקודה הבאה:

    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: מזהה הארגון ב- Cloud de Confiance.

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

התגובה מה-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 Context Manager.
  • ‫ACCESS_LEVEL_NAME: השם של רמת הגישה.

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

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

המסוף

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

נכנסים לדף Logs Explorer ב- במסוף Cloud de Confiance :

נכנסים לדף Logs Explorer.

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

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

  2. בשדה Log query, מזינים את השאילתה הבאה:

    protoPayload.serviceName="contextawareaccess.googleapis.com"
    protoPayload.metadata.dryRunEvaluationResult:DENIED
    SEARCH("SERVICE_ACCOUNT_NAME")
    
  3. בבורר טווח התאריכים, בוחרים זמן יחסי מוגדר מראש, כמו Last 30 minutes,‏ Last 1 hour או Last 24 hours, או מציינים טווח בהתאמה אישית.

gcloud

כדי להציג את דחיות הגישה של חשבון השירות במצב פרימטר לבדיקות של יומני הביקורת של Cloud באמצעות ה-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 השעות האחרונות.

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