שיטות מומלצות לשימוש בקבוצות Google

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

סוגי קבוצות

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

במסמך הזה אנחנו משתמשים בסוגי הקבוצות הבאים:

  • קבוצות ארגוניות

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

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

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

    דוגמאות לקבוצות ארגוניות: org.marketing-fte,‏ org.finance-all,‏ org.msmith-reports,‏ org.apac-all ו-org.summer-interns.

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

  • קבוצות שיתוף פעולה

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

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

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

    דוגמאות לקבוצות שיתוף פעולה: collab.security-discuss ו-collab.website-relaunch.

    קבוצות לשיתוף פעולה משמשות בדרך כלל לתקשורת באימייל.

  • קבוצות גישה

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

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

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

    דוגמאות לקבוצות גישה: access.prod-firewall-admins, access.finance-datamart-viewers ו-access.billing-dashboard-users.

    קבוצות גישה משמשות רק למתן גישה. הם לא משמשים למטרות תקשורת.

  • קבוצות אכיפה

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

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

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

    דוגמאות לקבוצות אכיפה: enforcement.users-in-restricted-locations, enforcement.fedramp-low ו-enforcement.sso-users.

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

לתת לקבוצות שמות שמשקפים את הסוג שלהן

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

מוסכמה למתן שמות

דוגמה למוסכמה למתן שמות שמאפשרת לראות את סוג הקבוצה:

  • קבוצות ארגוניות: org.GROUP_NAME@example.com. לדוגמה, org.finance-all@example.com.

  • קבוצות לשיתוף פעולה: collab.TEAM_NAME@example.com. לדוגמה, collab.msmiths-team@example.com.

  • קבוצות גישה: access.JOB_FUNCTION@example.com. לדוגמה, access.billing-dashboard-users@example.com.

  • קבוצות לאכיפה: enforcement.GROUP_DESCRIPTION@example.com. לדוגמה, enforcement.sso-users@example.com.

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

דומיינים משניים

במקום להשתמש במוסכמות למתן שמות, אפשר להשתמש בדומיינים משניים כדי להטמיע את סוג הקבוצה בשם – לדוגמה, access.example.com. דומיינים משניים שהם תת-דומיין של דומיין מאומת לא דורשים אימות ולא צריכים להיות קיימים ב-DNS. בנוסף, אם לא תיצרו רשומות DNS Mail Exchange‏ (MX) עבור הדומיינים המשניים, תוכלו לחסום אימיילים נכנסים שלא מיועדים לתקשורת עם קבוצות.

כללי קינון

לסוגים שונים של קבוצות יש כללים שונים לגבי האפשרות להוסיף קבוצה כחברה בקבוצה אחרת.

כללי קינון לקבוצות ארגוניות

מומלץ להשתמש בקבוצות ארגוניות מקוננות כדי לשקף את תרשים הארגון. בגישה הזו, כל עובד נכלל בקבוצה אחת, והקבוצות כוללות זו את זו. לדוגמה, קבוצה org.finance-all יכולה להכיל את הקבוצות org.finance-us, org.finance-germany ו-org.finance-australia כחברים.

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

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

כללי קינון לקבוצות שיתוף פעולה

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

קבוצות שיתוף פעולה יכולות לכלול קבוצות ארגוניות כחברים.

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

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

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

כללי קינון לקבוצות אכיפה

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

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

ניהול קבוצות ארגוניות

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

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

מכיוון שקבוצות ארגוניות מבוססות על נתונים של משאבי אנוש, מומלץ להקצות את הקבוצות האלה באופן בלעדי ממערכת מידע של משאבי אנוש או ממקור אמת חיצוני – למשל, ספק זהויות חיצוני (IdP) או מערכת לניהול זהויות כמו Sailpoint,‏ Okta או Entra ID.

לא מאפשרים שינויים בקבוצות

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

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

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

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

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

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

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

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

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

ניהול קבוצות לשיתוף פעולה

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

שימוש ב-Groups for Business לניהול קבוצות לשיתוף פעולה

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

השבתה של Groups for Business אם לא משתמשים בו

אם אתם משתמשים ב-Cloud Identity אבל לא ב-Google Workspace, אין סיבה להשתמש בקבוצות לשיתוף פעולה ב-Cloud Identity, ולכן מומלץ להשבית את 'קבוצות לעסקים' כדי למנוע מהמשתמשים שלכם ליצור קבוצות ב-Cloud Identity.

הוספת סיומת לקבוצות שיתוף פעולה

אם אתם משתמשים ב-Groups for Business, אתם יכולים להגדיר אותו כך שיוסיף סיומת. זה חשוב במיוחד אם אתם מאפשרים לכולם ליצור קבוצות חדשות של Groups for Business.

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

לא מומלץ להשתמש בקבוצות שיתוף פעולה לבקרת גישה

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

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

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

ניהול קבוצות גישה

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

בחירת הכלי הנכון לניהול קבוצות הגישה

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

  • מי (חברים באיזו קבוצה ארגונית) יכול להצטרף לקבוצת גישה

  • אילו דרישות צריך לעמוד בהן כדי שמשתמש יוכל להצטרף לקבוצה

    לדוגמה, האם המשתמשים צריכים לספק הצדקה?

  • משך החיים המקסימלי של חברות בקבוצה

  • אם צריך לאשר את ההצטרפות לקבוצה, ומי צריך לאשר אותה

  • תמיכה בנתיב ביקורת

כלי אחד שעונה על הדרישות האלה הוא JIT Groups.

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

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

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

שימוש בקבוצות הגישה לעומס עבודה ספציפי

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

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

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

איך מאפשרים למשתמשים למצוא קבוצות גישה ולהצטרף אליהן

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

הגדרת תוקף המינויים כברירת מחדל

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

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

הקצאת בעלים לכל קבוצה

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

הגבלת החשיפה של קבוצות גישה

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

הגבלת משתמשים חיצוניים

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

משתמשים בקבוצות אבטחה ב-Cloud Identity ובהגבלות על קבוצות כדי לאפשר או לאסור על חברים חיצוניים להצטרף לקבוצות גישה. בנוסף, כדאי להשתמש במוסכמה מיוחדת למתן שמות, כמו external.access.GROUP_NAME@example.com, לקבוצות גישה שמאפשרות למשתמשים מחוץ לארגון להצטרף.

ניהול קבוצות אכיפה

כדי לנהל את קבוצות האכיפה, כדאי לפעול לפי השיטות המומלצות הבאות.

בחירת הכלי הנכון לניהול קבוצות האכיפה

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

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

אם אתם לא יכולים להשתמש בקבוצות דינמיות, כדאי לשקול שימוש ב-Terraform או בכלי אחר של תשתית כקוד (IaC) כדי להקצות את קבוצות האכיפה. אם אתם משתמשים ב-IaC כדי ליצור קבוצות לאכיפה, הקפידו לא לתת גישה רחבה שלא לצורך לצינור.

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

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

קבוצות לאכיפה משמשות גם להחלת אמצעי בקרה לאימות, כמו הקצאת פרופיל SAML או אימות דו-שלבי (2SV).

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

המשתמשים לא יכולים לצאת מקבוצת אכיפה

האפשרות לאפשר למשתמשים לצאת מקבוצת אכיפה נוגדת את העקרונות של בקרת גישה חובה. כדי למנוע ממשתמשים לעזוב את הקבוצה, צריך להשתמש ב-Groups Settings API כדי להגדיר את המאפיין whoCanLeaveGroup לערך NONE_CAN_LEAVE.

שיטות מומלצות לשימוש ב-IdP חיצוניים

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

לא מומלץ להשתמש במקור חיצוני לקבוצות גישה

אפשר לנהל קבוצות גישה בספק הזהויות החיצוני ולהקצות להן הרשאות ב-Cloud Identity, אבל לגישה הזו יש כמה חסרונות:

  • עיכובים בהקצאת הרשאות

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

  • סיכון של סטייה

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

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

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

שימוש בדומיין משני אם ממפים קבוצות לפי שם

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

במקרים רבים, ספקי IdP מאפשרים לעקוף את הבעיה הזו על ידי יצירת כתובת אימייל פסאודו מתוך שם הקבוצה, למשל באמצעות my-group@example.com. השיטה הזו עובדת, אבל היא עלולה לגרום להתנגשויות אם כתובת האימייל הזו כבר נמצאת בשימוש של קבוצה או משתמש אחרים. במקרה הגרוע ביותר, גורם זדוני יכול לנצל את התנגשות השמות הזו כדי ליצור קבוצות אבטחה שמתחזות לסוג אחר של קבוצה, שפחות נבדקת.

כדי למנוע את הסיכון להתנגשויות, צריך להשתמש בדומיין משני ייעודי לקבוצות שמוקצות ממקור חיצוני, כמו groups.example.com.

לא להעניק לצינורות עיבוד נתונים לפריסה את תפקיד אדמין הקבוצות

אם אתם משתמשים ב-IaC כדי לנהל קבוצות (לדוגמה, Terraform), לצינור הפריסה שלכם צריכות להיות ההרשאות הנדרשות כדי לבצע את המשימה. התפקיד 'אדמין בקבוצות' מאפשר ליצור קבוצות, אבל הוא גם מאפשר לכל גורם ראשי עם התפקיד הזה לנהל את כל הקבוצות בחשבון Cloud Identity.

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

אלה השלבים לביצוע הגישה הזו:

  1. יוצרים תפקיד אדמין בהתאמה אישית שכולל רק את ההרשאה ליצירת קבוצות ב-Admin API.

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

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

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

שימוש ב-Cloud Logging לביקורת ולמעקב אחרי הקבוצות.

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

ביקורת על שינויים בחברות

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

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

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

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

הפעלת שיתוף של יומן הביקורת של Cloud Identity

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