בקרת גישה באמצעות IAM

בדף הזה מוסבר איך אפשר לשלוט בגישה למשאבים של Sensitive Data Protection.

Sensitive Data Protection משתמש בניהול זהויות והרשאות גישה (IAM) כדי לשלוט בגישה למשאבים. ‫IAM הוא כלי לניהול הרשאות פרטניות למשאבים ב- Google Cloud . במילים אחרות, IAM מאפשר לכם לקבוע מי יכול לבצע אילו פעולות על אילו משאבים.

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

למידע מפורט על IAM והמאפיינים שלו, תוכלו לעיין במסמכי העזרה של IAM.

ניהול הגישה למשאבים של Sensitive Data Protection

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

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

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

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

לא כל המשאבים תומכים במדיניות הרשאות. במאמר משאבים שתומכים במדיניות הרשאה במסמכי ה-IAM מוסבר לאילו משאבים אפשר לצרף מדיניות הרשאה.

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

איך נותנים תפקיד IAM בודד

כדי לתת תפקיד לחשבון ראשי, תוכלו לבצע את הפעולות הבאות:

המסוף

  1. נכנסים לדף IAM במסוף Google Cloud .

    כניסה לדף IAM

  2. בוחרים פרויקט, תיקייה או ארגון.
  3. בוחרים את החשבון הראשי שרוצים לתת לו את התפקיד:
    • כדי להעניק לישות מורשית תפקיד נוסף במשאב, מוצאים שורה שמכילה את הישות המורשית, לוחצים על Edit principal בשורה זו, ולוחצים על Add another role.

      כדי להקצות תפקיד לסוכן שירות, מסמנים את התיבה Include Google-provided role grants כדי לראות את כתובת האימייל שלו.

    • כדי להקצות תפקיד לחשבון משתמש שאין לו תפקידים קיימים במשאב, לוחצים על Grant Access ומזינים מזהה של חשבון משתמש, למשל my-user@example.com או //iam.googleapis.com/locations/global/workforcePools/example-pool/group/example-group@example.com.
  4. בוחרים את התפקיד שרוצים להקצות מהרשימה הנפתחת. בהתאם לנוהלי האבטחה המומלצים, כדאי לבחור תפקיד שמכיל רק את ההרשאות שהחשבון הראשי צריך.
  5. אם רוצים, מוסיפים תנאי לתפקיד.
  6. לוחצים על Save. חשבון המשתמש מקבל את התפקיד במשאב.

gcloud

  1. במסוף Google Cloud , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

    בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. הפקודה add-iam-policy-binding מאפשרת להקצות תפקיד לחשבון משתמש במהירות.

    לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

    • ‏RESOURCE_TYPE: סוג המשאב שרוצים לנהל את הגישה אליו. אפשר להשתמש ב-projects, ב-resource-manager folders או ב-organizations.

    • ‫RESOURCE_ID: מזהה הפרויקט, התיקייה או הארגון ב- Google Cloud . מזהי פרויקטים מכילים אותיות וספרות, למשל my-project. מזהי תיקיות וארגונים מכילים רק ספרות, למשל 123456789012.

    • ‏PRINCIPAL: מזהה של חשבון המשתמש או המנוי, שבדרך כלל נראה כך: PRINCIPAL_TYPE:ID. לדוגמה, user:my-user@example.com או principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/example-group@example.com. רשימה מלאה של הערכים שיכולים להיות ל-PRINCIPAL מופיעה במאמר מזהים של חשבונות משתמשים.

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

    • ‫ROLE_NAME: שם התפקיד שרוצים לתת. משתמשים באחד מהפורמטים הבאים:

      • תפקידים מוגדרים מראש: roles/SERVICE.IDENTIFIER
      • תפקידים בהתאמה אישית ברמת הפרויקט: projects/PROJECT_ID/roles/IDENTIFIER
      • תפקידים בהתאמה אישית ברמת הארגון: organizations/ORG_ID/roles/IDENTIFIER

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

    • ‏CONDITION: התנאי שרוצים להוסיף לקישור התפקידים. אם לא רוצים להוסיף תנאי, אפשר להשתמש בערך None. מידע נוסף על התנאים מופיע במאמר סקירה כללית של התנאים.

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

    ‫Linux,‏ macOS או Cloud Shell

    gcloud RESOURCE_TYPE add-iam-policy-binding RESOURCE_ID \
    --member=PRINCIPAL --role=ROLE_NAME \
    --condition=CONDITION

    ‏Windows (PowerShell)

    gcloud RESOURCE_TYPE add-iam-policy-binding RESOURCE_ID `
    --member=PRINCIPAL --role=ROLE_NAME `
    --condition=CONDITION

    Windows‏ (cmd.exe)

    gcloud RESOURCE_TYPE add-iam-policy-binding RESOURCE_ID ^
    --member=PRINCIPAL --role=ROLE_NAME ^
    --condition=CONDITION

    התשובה תכלול את מדיניות ההרשאות המעודכנת של IAM.

איך מבטלים תפקידים בודדים ב-IAM

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

המסוף

  1. נכנסים לדף IAM במסוף Google Cloud .

    כניסה לדף IAM

  2. בוחרים פרויקט, תיקייה או ארגון.
  3. מחפשים את השורה שמכילה את חשבון המשתמש שרוצים לבטל את הגישה שלו. בשורה הזו לוחצים על Edit principal.
  4. לוחצים על הלחצן מחיקה ליד התפקיד שרוצים לבטל ואז על שמירה.

gcloud

  1. במסוף Google Cloud , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

    בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. כדי לבטל תפקיד של משתמש, מריצים את הפקודה remove-iam-policy-binding:

    gcloud RESOURCE_TYPE remove-iam-policy-binding RESOURCE_ID \
    --member=PRINCIPAL --role=ROLE_NAME

    מספקים את הערכים הבאים:

    • RESOURCE_TYPE: סוג המשאב שרוצים לנהל את הגישה אליו. משתמשים ב-projects, ב-resource-manager folders או ב-organizations.

    • ‫RESOURCE_ID: מזהה הפרויקט, התיקייה או הארגון ב- Google Cloud . מזהי פרויקטים מכילים אותיות וספרות, למשל my-project. מזהי תיקיות וארגונים מכילים רק ספרות, למשל 123456789012.

    • ‏PRINCIPAL: מזהה של חשבון המשתמש, שבדרך כלל נראה כך: PRINCIPAL_TYPE:ID. לדוגמה, user:my-user@example.com או principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/example-group@example.com.

      בסוג חשבון המשתמש user, שם הדומיין במזהה חייב להיות דומיין של Google Workspace או דומיין של Cloud Identity. מידע על הגדרת דומיין ב-Cloud Identity מופיע במאמר סקירה כללית של Cloud Identity.

    • ‫ROLE_NAME: שם התפקיד שרוצים לבטל. משתמשים באחד מהפורמטים הבאים:

      • תפקידים מוגדרים מראש: roles/SERVICE.IDENTIFIER
      • תפקידים בהתאמה אישית ברמת הפרויקט: projects/PROJECT_ID/roles/IDENTIFIER
      • תפקידים בהתאמה אישית ברמת הארגון: organizations/ORG_ID/roles/IDENTIFIER

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

    לדוגמה, כדי לבטל את התפקיד Project Creator מחשבון השירות example-service-account@example-project.iam.gserviceaccount.com בפרויקט example-project:

    gcloud projects remove-iam-policy-binding example-project \
      --member=serviceAccount:example-service-account@example-project.iam.gserviceaccount.com \
      --role=roles/resourcemanager.projectCreator

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

גישה מותנית

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

התנאים במדיניות ההרשאה מבוססים על סוגי המאפיינים הבאים:

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

מידע נוסף על מאפייני התנאים שנתמכים על ידי Sensitive Data Protection מופיע במאמר הסבר על מאפיינים לתנאים ב-IAM בתיעוד של IAM.

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

במאמר ניהול קישורי תפקידים מותנים במסמכי התיעוד של IAM מוסבר איך מוסיפים תנאים לקישורי תפקידים.

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