שיטות מומלצות לשימוש בקבוצות 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, אתם יכולים להשתמש בGroups for Business כדי לנהל קבוצות לשיתוף פעולה. ההגדרה הזו מאפשרת למשתמשים להשתמש בקבוצות Google כדי ליצור קבוצות, לעיין בהן ולהצטרף אליהן. כדי לאפשר למשתמשים ליצור קבוצות חדשות לשיתוף פעולה, צריך להגדיר את Groups for Business.

השבתה של 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, אבל לגישה הזו יש כמה חסרונות:

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

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

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

    חלק מספקי הזהויות לא מקבלים שליטה סמכותית על קבוצות. לדוגמה, יכול להיות שהם לא ימחקו קבוצה ב-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).