דפוסים ושיטות לניהול זהויות והרשאות גישה ב-Google Cloud

Last reviewed 2024-07-11 UTC

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

במסמך הזה, אנחנו יוצאים מנקודת הנחה שיש לכם:

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

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

    אם אין לכם עדיין גישה ל Google Cloud פרויקט וגישת אדמין ל-Cloud Identity, תוכלו לקרוא את המאמרים יצירת פרויקט והגדרת Cloud Identity. Google Cloud

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

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

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

צפייה בהמלצות ל-IAM ויישום שלהן

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

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

הטמעה

  1. בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.

  2. ‫BigQuery מופעל באופן אוטומטי בפרויקטים חדשים. כדי להפעיל את BigQuery בפרויקט קיים, צריך להפעיל את BigQuery API.

    הפעלת ה-API

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

  4. עוברים לדף BigQuery.

    כניסה ל-BigQuery

  5. מעתיקים את השאילתה הבאה ומדביקים אותה בשדה עורך:

    SELECT
   recommendation_details
FROM PROJECT_ID.DATASET.TABLE_NAME
WHERE recommender = "google.iam.policy.Recommender"
AND recommender_subtype = "REMOVE_ROLE"

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

    • ‫PROJECT_ID: Google Cloud מזהה הפרויקט שבו אתם משתמשים כדי להריץ את הדוגמה הזו
    • ‫DATASET: השם של מערך הנתונים שבחרתם כשמגדירים את העבודה של שירות העברת הנתונים ל-BigQuery.
    • ‫TABLE_NAME: השם של הטבלה שנוצרה על ידי המשימה של שירות העברת נתונים ל-BigQuery.

    מריצים את השאילתה הזו כדי לזהות את recommender_subtype סוג המשנה של ההמלצות של IAM RecommenderREMOVE_ROLE.

  6. לוחצים על Run. אפשר להשתמש בתוצאת השאילתה כדי לזהות תפקידים שלא נמצאים בשימוש ולשנות את הקישורים של תפקידי ה-IAM כך שיתאימו לצרכים.

    אפשר לשמור את תוצאות השאילתה ב-Sheets. מידע נוסף מופיע במאמר בנושא שמירת תוצאות של שאילתות ב-Sheets.

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

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

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

הגדרת גישה למשאבים באמצעות קבוצות Google

אפשר ליצור ולנהל קבוצת Google באמצעות Cloud Identity.‏ Cloud Identity הוא פתרון לניהול זהות כשירות (IDaaS) שמנהל משתמשים וקבוצות. אפשר גם להגדיר את Cloud Identity כך שיבצע איחוד בין זהויות ב-Google לבין ספקי זהויות אחרים, כמו Active Directory ו-Azure Active Directory.‏ קבוצות Google מאפשרות גם למשתמש לשלוח בקשה להצטרפות לקבוצה. הבקשה מועברת לאדמינים של הקבוצה, שיכולים לאשר או לדחות אותה. מידע נוסף זמין במאמר יצירת קבוצה ובחירת הגדרות הקבוצה.

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

הטמעה

בשלבים הבאים מוסבר איך ליצור קבוצה ב-Google ולתת לה גישת צפייה לפרויקט לדוגמה Google Cloud . חברים שמוסיפים לקבוצה הזו (או שנותנים להם גישה לבקשתם) יכולים לראות את פרויקט הדוגמהGoogle Cloud .

יצירת קבוצת Google לדוגמה

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

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

    מעבר אל קבוצות

  2. לוחצים על יצירה.

  3. ממלאים את הפרטים של הקבוצה.

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

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

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

  4. לוחצים על יצירת קבוצה.

הענקת גישה לקבוצה לפרויקט ב- Google Cloud

  1. בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.

  2. פותחים את Cloud Shell:

    כניסה ל-Cloud Shell

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

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=group:GROUP_EMAIL --role=roles/viewer

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

    • GROUP_EMAIL: כתובת האימייל של הקבוצה שיצרתם
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud

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

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

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

  2. כדי לבקש גישה לקבוצה, לוחצים על שליחת בקשת הצטרפות לקבוצה.

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

מתן גישה מוגבלת בזמן למשאבים ב- Google Cloud

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

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

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

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

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

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

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

הטמעה

אתם יכולים להשתמש בקישור תפקידים מותנה כדי לתת למפתחים גישה זמנית לניהול של מכונה ספציפית ב-Compute Engine. בדוגמה הזו, התוקף של הקישור לתפקיד יפוג ב-31 בדצמבר 2021.

  1. ב-Cloud Shell, מגדירים את המשתנים הבאים:

    export INSTANCE=create example-instance-1
export ZONE=us-west1-b
export USER=USER_ID_TO_GIVE_TEMPORARY_ACCESS_TO

    מחליפים את USER_ID_TO_GIVE_TEMPORARY_ACCESS_TO בשם המשתמש של המשתמש בארגון שרוצים לתת לו גישה זמנית.

  2. יצירת מכונה לדוגמה של Compute Engine:

    gcloud compute instances create $INSTANCE \
    --zone $ZONE \
    --machine-type g1-small

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

  3. נותנים למשתמש שבחרתם גישה זמנית:

    gcloud compute instances add-iam-policy-binding $INSTANCE \
    --zone=$ZONE \
    --member="user:$USER" \
    --role='roles/compute.instanceAdmin.v1' \
    --condition='expression=request.time < timestamp("2022-01-01T00:00:00Z"),title=expires_end_of_2021,description=Expires at midnight on 2021-12-31'

  4. שומרים את המכונה של Compute Engine שיצרתם. בהמשך המסמך הזה, בניהול גישה עם הרשאות, נשתמש במופע הזה.

    אפשר גם למחוק את מופע example-instance-1 על ידי הרצת הפקודה הבאה:

    gcloud compute instances delete $INSTANCE

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

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

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

מומלץ להשתמש ביומני הביקורת הבאים לרישום ביומן של פעולות אדמיניסטרטיביות שקשורות לזהות ולגישה:

  • יומני הביקורת Admin Activity
  • יומני הביקורת Policy Denied

ביומני הביקורת Admin Activity נשמרים שינויים שבוצעו במשאבי Google Cloud , כמו פרויקטים, מכונות ב-Compute Engine וחשבונות שירות. אלה דוגמאות לאירועים שנשמרים ביומני הביקורת Admin Activity:

  • יצירה של חשבון שירות.
  • שינוי במדיניות IAM.
  • הורדה של מפתח של חשבון שירות.

ביומני הביקורת של מדיניות הגישה שנדחתה מתועד מתי נדחתה הגישה של משתמש או חשבון שירות ל Google Cloud שירות בגלל הפרה של מדיניות האבטחה.

הגדרה של יומני ביקורת בענן לאירועים במחזור החיים של הזהויות

אתם יכולים לצפות ביומני ביקורת במסוף או להריץ שאילתות ביומנים באמצעות Cloud Logging API או ממשק שורת הפקודה. Google Cloud

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

הטמעה

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

  • בוצעו שינויים במדיניות IAM.
  • נוצרו חשבונות שירות חדשים.
  • נוצרו מפתחות חדשים לחשבון השירות.

הצגת שינויים במדיניות IAM

  1. במסוף Google Cloud , נכנסים לדף Logging > Logs Explorer.
  2. בדף Logs Explorer, בוחרים פרויקט קיים Google Cloud .

  3. מדביקים את השאילתה הבאה בכלי ליצירת שאילתות:

    logName="projects/<PROJECT>/logs/cloudaudit.googleapis.com%2Factivity" AND
(resource.type="project" OR resource.type="service_account") AND
resource.labels.project_id="<PROJECT>" AND
(protoPayload.methodName="SetIamPolicy" OR
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccount"
OR
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey")

    מחליפים את PROJECT במזהה הפרויקט ב- Google Cloud .

  4. לוחצים על Run query.

הצגת שינויים בחברות בקבוצה

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

אישור גישה

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

  • אילו משתמשים יכולים לגשת לחשבון שירות.
  • אילו משתמשים יכולים לקרוא את הנתונים במערך הנתונים הזה ב-BigQuery, שיש בו פרטים אישיים מזהים (PII).

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

שימוש בכלי הניתוח למדיניות כדי לבדוק את גישת המשתמש

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

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

הטמעה

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

  1. ב-Cloud Shell, מפעילים את Cloud Asset API בפרויקט:

    הפעלת ה-API

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

    gcloud asset analyze-iam-policy --organization="YOUR_ORG_ID" \
    --identity="user:USERNAME_TO_CERTIFY"

    מחליפים את הפרטים הבאים:

    • ‫YOUR_ORG_ID: מזהה הארגון ב- Google Cloud
    • ‫USERNAME_TO_CERTIFY: שם המשתמש של המשתמש שרוצים לאמת את הרשאות הגישה שלו. Google Cloud

  3. מחלצים את נתוני מדיניות IAM ל-BigQuery. מידע נוסף זמין במאמר כתיבת ניתוח מדיניות ל-BigQuery.

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

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

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

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

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

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

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

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

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

הטמעה

בתהליך לדוגמה הזה, אתם (כאדמינים) יוצרים קבוצת Google עם גישה מורשית למכונות של Compute Engine. אתם יוצרים חשבון שירות ב- Google Cloud שמקבל גישה לניהול מכונות של Compute Engine. אתם משייכים את הקבוצה לחשבון השירות, כדי שחברי הקבוצה יוכלו להתחזות לחשבון השירות למשך התקופה שבה הם חברים בקבוצה עם הגישה המורשית.

יצירת קבוצה ב-Google לגישה עם הרשאות מיוחדות

  1. בתור Google Cloud אדמינים, בוחרים או יוצרים Google Cloud פרויקט.

    מעבר לניהול משאבים

  2. מפעילים את החיוב בפרויקט. הפעלת החיוב

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

    נותנים לקבוצה את השם הבא: elevated-compute-access

יצירה של Google Cloud חשבון שירות

  1. ב-Cloud Shell, מפעילים את IAM Service Account Credentials API בפרויקט שיצרתם בשלב יצירת קבוצת Google לגישה עם הרשאות.

    הפעלת ממשקי ה-API

  2. מגדירים את המשתנים הבאים:

    export PROJECT_ID=$DEVSHELL_PROJECT_ID
export PRIV_SERVICE_ACCOUNT_NAME=elevated-compute-access
export DELEGATE_GROUP=GROUP_EMAIL_ADDRESS

    מחליפים את GROUP_EMAIL_ADDRESS בשם המלא של קבוצת Google שיצרתם.

  3. יוצרים את חשבון השירות:

    gcloud IAMservice-accounts create $PRIV_SERVICE_ACCOUNT_NAME \
    --description="Elevated compute access" \
    --display-name="Elevated compute access"

  4. מקצים לחשבון השירות את התפקיד 'אדמין Compute':

    gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:$PRIV_SERVICE_ACCOUNT_NAME@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/compute.admin"

  5. נותנים לקבוצת Google שיצרתם גישת צרכן שירות לפרויקט:

    gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="group:$DELEGATE_GROUP" \
    --role="roles/serviceusage.serviceUsageConsumer"

    ההרשאה הזו מאפשרת לחברים בקבוצת Google להתחזות לחשבון השירות שיצרתם.

  6. נותנים לקבוצת Google את היכולת להתחזות לחשבון השירות שיצרתם:

    gcloud IAMservice-accounts add-iam-policy-binding
$PRIV_SERVICE_ACCOUNT_NAME@$PROJECT_ID.iam.gserviceaccount.com --member="group
:$DELEGATE_GROUP" --role="roles/iam.serviceAccountTokenCreator"

  7. אם יצרתם מכונת Compute Engine לדוגמה ושמרתם אותה לצורך ההליך שמתואר במאמר מתן גישה למשאבים עם הגבלת זמן, אתם יכולים לדלג על השלב הזה ולהשתמש במכונה לדוגמה כדי להריץ את השלבים שמופיעים בדוגמה הזו. Google Cloud

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

    gcloud compute instances create example-instance-1 \
    --zone us-west1-b \
    --machine-type g1-small

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

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

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

  1. כדי לקבל את מדיניות ה-IAM הנוכחית של הפרויקט:

    gcloud projects get-iam-policy $PROJECT_ID > /tmp/policy.yaml

  2. משנים את קובץ המדיניות כדי להפעיל יומני גישה לנתונים של Compute Engine API:

    cat <<EOF >> /tmp/policy.yaml
auditConfigs:
- auditLogConfigs:
 - logType: ADMIN_READ
 - logType: DATA_READ
 - logType: DATA_WRITE
 service: compute.googleapis.com
EOF

  3. מגדירים את המדיניות החדשה:

    gcloud projects set-iam-policy $PROJECT_ID /tmp/policy.yaml

בדיקת התחזות באמצעות חשבון משתמש ללא הרשאות אדמין

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

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

  1. נכנסים לקבוצות Google באמצעות חשבון משתמש בלי הרשאת אדמין ומבקשים להצטרף לקבוצה elevated-compute-access.

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

  3. ב-Cloud Shell, מריצים את הפקודה הבאה כדי להגדיר את פרויקט ברירת המחדל:

    gcloud config set project PROJECT_ID

    מחליפים את PROJECT_ID במזהה הפרויקט שיצרתם קודם בקטע יצירת קבוצת Google לגישה עם הרשאות.

  4. מנסים להציג רשימה של מכונות Compute Engine בפרויקט הזה:

    gcloud compute instances list

    מוצגת הודעת שגיאה שמציינת שלמשתמש Google Cloud אין הרשאה לגשת למשאבים של Compute Engine.

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

    gcloud compute instances list
--impersonate-service-account=elevated-compute-access@$PROJECT_ID.iam.gserviceaccount.com

    הפקודה הזו מציגה רשימה של מכונות Compute Engine בפרויקט על ידי התחזות לחשבון השירות שקיבלתם אליו גישה כשקיבלתם חברות בקבוצת Google‏ elevated-compute-access.

    מוצגת לכם מכונת Compute Engine שיצרתם באמצעות חשבון האדמין.example-instance-1

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

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

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

  2. ב-Cloud Logging, מזינים את השאילתה הבאה כדי לבדוק את יומני הגישה לנתונים:

    logName="projects/<PROJECT_ID>/logs/cloudaudit.googleapis.com%2Fdata_access"
AND
protoPayload.authenticationInfo.principalEmail="elevated-compute-access@PROJECT_ID.iam.gserviceaccount.com"

    מחליפים את PROJECT_ID במזהה הפרויקט ומריצים את השאילתה.

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

  3. בודקים את מטען הנתונים של יומן הביקורת, ובמיוחד את האובייקט protoPayload.authenticationInfo במטען הנתונים. שם המשתמש של המשתמש שהתחזה לחשבון השירות מתועד כערך של המפתח principalEmail באובייקט firstPartyPrincipal.

  4. אדמינים יכולים גם לבדוק את הממצאים של איומים על אירועים במרכז הבקרה של Security Command Center. מידע נוסף על Security Command Center זמין במאמר שימוש ב-Event Threat Detection.

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