איחוד שירותי אימות הזהות של כוח העבודה

באמצעות איחוד של Workload Identity, משתמשים בספק הזהויות החיצוני (IdP) יכולים להשתמש בכניסה יחידה (SSO) כדי לגשת למשאבים של Google Cloud .

מה זה איחוד שירותי אימות הזהות של כוח עבודה?

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

פדרציה לעומת סנכרון

איחוד שירותי אימות הזהות של כוח העבודה מאחד זהויות מה-IdP שלכם, כך שהוא לא מאחסן חשבונות משתמשים ב- Google Cloud. לכן, איחוד שירותי אימות הזהות של כוח עבודה לא דורש סנכרון, כלומר לא צריך להשתמש בכלים כדי לסנכרן זהויות משתמשים מה-IdP עם זהויות שמנוהלות על ידי Google ודורשות חשבונות Google. לדוגמה, אם משתמשים באיחוד שירותי אימות הזהות של כוח העבודה, לא צריך להשתמש ב-Google Cloud Directory Sync (GCDS) של Cloud Identity.

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

איחוד שירותי אימות הזהות של כוח העבודה לעומת איחוד שירותי אימות הזהות של עומסי העבודה

איחוד שירותי אימות הזהות של כוח עבודה מאחד זהויות של משתמשים, בעוד שאיחוד Workload Identity מאחד זהויות של עומסי עבודה.

מידע נוסף זמין במאמר איחוד שירותי אימות הזהויות של עומסי עבודה.

גישה על סמך מאפיינים

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

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

פרוטוקולים נתמכים

אפשר להשתמש באיחוד שירותי אימות הזהות של כוח עבודה עם כל IdP שתומך ב-OpenID Connect (OIDC) או ב-SAML 2.0, כמו Microsoft Entra ID,‏ Active Directory Federation Services ‏(AD FS),‏ Okta ואחרים.

מושגים מרכזיים

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

מאגרי זהויות של כוח עבודה

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

באמצעות המאגרים האלה, אפשר:

  • לקבץ זהויות משתמשים. לדוגמה, employees או partners
  • להעניק הרשאת גישה ב-IAM למאגר שלם או לקבוצת משנה שלו.
  • לאחד זהויות מ-IdP אחד או יותר.
  • להגדיר כללי מדיניות על קבוצת משתמשים שצריכים הרשאות גישה דומות.
  • לציין פרטי הגדרות שספציפיים ל-IdP, כולל מיפוי מאפיינים ותנאי מאפיינים.
  • לאפשר לזהויות של צד שלישי גישה ל-CLI ול-API של Google Cloud.
  • לרשום גישה של משתמשים שנמצאים במאגר ביומני הביקורת של Cloud, יחד עם מזהה המאגר.

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

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

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

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

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

איחוד שירותי אימות הזהות של כוח עבודה תואם למפרט OAuth 2.0 Token Exchange (RFC 8693). אתם צריכים לספק פרטי כניסה מספק הזהויות החיצוני שלכם ל-Security Token Service, שמאמת את הזהות בפרטי הכניסה. לאחר מכן הוא מחזיר בתמורה אסימון גישה לטווח קצר. Google Cloud

סוגים של זרימת OIDC

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

Google Cloud מסוף איחוד שירותי אימות הזהויות של כוח העבודה

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

מאפיינים

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

מיפויים של מאפיינים

אפשר למפות את המאפיינים האלה לשימוש על ידי Google Cloud באמצעות Common Expression Language (CEL).

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

אפשר גם להגדיר מאפיינים מותאמים אישית ב-IdP ואז להשתמש בהם במוצרים ספציפיים של Google Cloud Google Cloud. לדוגמה, בכללי מדיניות ההרשאות של IAM.

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

אלו המאפיינים:

  • ‫google.subject (חובה): מזהה ייחודי של המשתמש המאמת. בדרך כלל מדובר בטענת הנכוֹנוּת (assertion) לגבי הנושא של ה-JWT, כי הרישומים של יומני הביקורת של Cloud מתעדים את התוכן של השדה הזה בתור חשבון ראשי. אפשר להשתמש בשדה הזה כדי להגדיר את IAM לקבלת החלטות לגבי הרשאות. מומלץ לא להשתמש בערך שאפשר לשנות, כי אם משנים את הערך בספריית המשתמשים של ה-IdP, המשתמש מאבד את הגישה.

    האורך המקסימלי הוא 127 בייטים.

  • ‫google.groups (אופציונלי): אוסף הקבוצות שהמשתמש שמבצע את האימות חבר בהן. אתם יכולים להגדיר ביטוי לוגי באמצעות קבוצת משנה של CEL שמפיקה מערך מחרוזות. אפשר גם להשתמש בשדה הזה כדי להגדיר את IAM לקבלת החלטות לגבי הרשאות. המגבלות של google.groups הן:

    • מומלץ להגביל את שם הקבוצה ל-40 תווים.

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

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

  • ‫google.display_name (אופציונלי): מאפיין שמשמש להגדרת השם של המשתמש שנכנס לחשבון ב Google Cloud מסוף. אי אפשר להשתמש במאפיין הזה בכללי מדיניות ההרשאות ב-IAM וגם לא בתנאי המאפיין.

    האורך המקסימלי הוא 100 בייטים.

  • ‫google.profile_photo (אופציונלי): כתובת URL של התמונה הממוזערת של המשתמש. מומלץ להשתמש בתמונה בגודל 400x400 פיקסלים. כשהמאפיין הזה מוגדר, התמונה מוצגת כתמונת הפרופיל של המשתמש במסוף Google Cloud . אם הערך לא מוגדר או שאי אפשר לאחזר אותו, יוצג במקום זאת סמל משתמש גנרי. אי אפשר להשתמש במאפיין הזה בכללי מדיניות ההרשאה ב-IAM וגם לא בתנאי המאפיין.

  • ‫google.posix_username (אופציונלי): מחרוזת ייחודית של שם משתמש שתואמת ל-POSIX ומשמשת למטרות הבאות:

    ‫ + התחברות באמצעות OS Login עם איחוד שירותי אימות הזהות של כוח עבודה (תצוגה מקדימה).

    אי אפשר להשתמש במאפיין הזה בכללי מדיניות ההרשאה ב-IAM וגם לא בתנאי המאפיין. האורך המקסימלי הוא 32 תווים.

* google.email (אופציונלי): מאפיין שמשמש למיפוי כתובות אימייל של משתמשים מאוחדים שמחוברים מה-IdP למוצרים שמשולבים באמצעות שילוב לקוח OAuth של איחוד זהויות של כוח העבודה. אי אפשר להשתמש במאפיין הזה בכללי מדיניות ההרשאות ב-IAM וגם לא בתנאי המאפיין.

לדוגמה, כדי למפות כתובות אימייל מ-Okta באמצעות פרוטוקול OIDC, צריך לכלול את google.email=assertion.email במיפוי המאפיינים.

דוגמאות Google Cloud למוצרים שתומכים בשילוב של לקוח OAuth: כוללות את המוצרים הבאים:

  • שרת proxy לאימות זהויות (IAP) עם איחוד שירותי אימות הזהות של כוח עבודה

  • Secure Source Manager עם איחוד שירותי אימות הזהות של כוח עבודה

  • ‫attribute.KEY (אופציונלי): מאפיין בהגדרת ה-IdP החיצוני שנמצא באסימון IdP של המשתמש. תוכלו להשתמש במאפיין המותאם אישית כדי להגדיר את אסטרטגיית ההרשאות במדיניות הרשאה ב-IAM.

    לדוגמה, ב-IdP, אתם יכולים להגדיר מאפיין כמו מרכז העלויות של המשתמש כ-costcenter = "1234", ואז להפנות אל ה-principal באופן הבא:

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workforcePools/WORKFORCE_POOL_ID/attribute.costcenter/1234

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

    אתם יכולים להגדיר עד 50 כללי מיפוי של מאפיינים מותאמים אישית. הגודל המקסימלי של כל כלל כזה הוא 2,048 תווים.

    אין מגבלות על המאפיינים שאפשר למפות כאן, אבל מומלץ מאוד לבחור מאפיינים שהערכים שלהם יציבים. לדוגמה, מאפיין כמו attribute.job_description עשוי להשתנות מסיבות רבות (למשל, שיפור הקריאוּת). במקום זאת, כדאי להשתמש ב-attribute.role, כי שינויים בו מעידים על שינוי באחריות המוקצית, והם תואמים לשינויים בגישה שהוענקה למשתמש.

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

  • הפונקציה split מפצלת מחרוזת בערך המפריד שצוין. לדוגמה, כדי לחלץ את המאפיין username ממאפיין של כתובת אימייל, על ידי פיצול הערך שלו ב-@ ושימוש במחרוזת הראשונה, משתמשים במיפוי המאפיינים הבא: 

    attribute.username=assertion.email.split("@")[0]

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

    attribute.department=assertion.department.join(".")

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

תנאים של מאפיינים הם ביטויי CEL אופציונליים, שמאפשרים להגדיר אילוצים לגבי מאפייני הזהות ש- Google Cloud מקבל.

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

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

תנאי מאפיינים לספקי זהויות מרובי-דיירים

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

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

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

רישום מפורט ביומן הביקורת

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

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

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

מפתחות אינטרנט בפורמט JSON

הספק של מאגר הזהויות של כוח עבודה יכול לגשת למפתחות אינטרנט מסוג JSON ‏ (JWKs) שה-IdP מספק בשדה jwks_uri במסמך /.well-known/openid-configuration. אם ספק ה-OIDC לא נותן את המידע הזה, או אם אין גישה ציבורית למונפק, אפשר להעלות באופן ידני את מפתחות ה-JWK כשיוצרים או מעדכנים את ספק ה-OIDC.

תמיכה ב-SCIM

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

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

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

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

זהויות פורמט של מזהה
זהות יחידה במאגר זהויות של כוח עבודה principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
כל הזהויות של כוח העבודה בקבוצה principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
כל הזהויות של כוח העבודה עם ערך מאפיין ספציפי principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
כל הזהויות במאגר זהויות של כוח עבודה principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

רשימה מלאה של מזהי ישויות מורשות מופיעה במאמר מזהים של ישויות מורשות.

שיקולים נוספים

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

הגבלת הגישה בין ארגונים

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

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

ברוב Google Cloud ממשקי ה-API (ממשקי API שמבוססים על משאבים), החיובים והשימוש במכסות משויכים לפרויקט שמכיל את המשאב. חלק מממשקי ה-API (ממשקי API שמבוססים על לקוחות) מחייבים את הפרויקט שמשויך ללקוח, שנקרא פרויקט המכסה.

כשיוצרים קובץ תצורה של איחוד שירותי אימות הזהות של כוח עבודה, מציינים פרויקט של משתמש במאגרי כוח עבודה. הפרויקט הזה מזהה את האפליקציה שלכם ב-Google APIs ומשמש כפרויקט ברירת המחדל של המכסה ל-APIs מבוססי-לקוח, אלא אם אתם משתמשים ב-CLI של gcloud כדי לשלוח את הבקשה. צריכה להיות לכם ההרשאה serviceusage.services.use, שכלולה בתפקיד 'Service Usage Consumer' (roles/serviceusage.serviceUsageConsumer), בפרויקט שצוין.

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

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

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

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

לדוגמה, נניח שחברה בשם Enterprise Example Organization לוקחת חברה אחרת בשם Partner Example Organization Inc כקבלנית, כדי שתספק לה שירותי DevOps של Google Kubernetes Engine‏ (GKE). כדי שכוח העבודה של Partner Example Organization יוכל לספק את השירותים, הוא צריך לקבל גישה ל-Google Kubernetes Engine‏ (GKE) ול Google Cloud משאבים אחרים בארגון של Enterprise Example Organization. לארגון Enterprise Example Organization כבר יש מאגר זהויות של כוח עבודה בשם enterprise-example-organization-employees.

כדי לאפשר ל-Partner Example Organization לנהל גישה למשאבים של Enterprise Example Organization, הארגון Enterprise Example Organization יוצר מאגר כוח עבודה נפרד למשתמשי כוח העבודה של Partner Example Organization, כדי ש-Partner Example Organization יוכל לנהל אותו. ‫Enterprise Example Organization מספק את מאגר כוח העבודה לאדמין של Partner Example Organization. האדמין של Partner Example Organization משתמש ב-IdP משלו כדי להעניק גישה לכוח העבודה שלו.

כדי לעשות זאת, האדמין של Enterprise Example Organization צריך:

  1. ליצור זהות, כמו partner-organization-admin@example.com, לאדמין של Partner Example Organization ב-IdP של Enterprise Example Organization, שכבר מוגדרת במאגר שנקרא enterprise-example-organization-employees.

  2. ליצור מאגר כוח עבודה חדש בשם example-organization-partner.

  3. ליצור את מדיניות ההרשאה הבאה למאגר example-organization-partner:

    {
  "bindings": [
    {
      "role": "roles/iam.workforcePoolEditor",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/enterprise-example-organization-employees/subject/partner-organization-admin@example.com"
      ]
    }
  ]
}

  4. להקצות תפקידים למאגר example-organization-partner במשאבים שאליהם כוח העבודה של החברה הקבלנית צריך לגשת בארגון של Enterprise Example Organization.

האדמין של Partner Example Organization יכול עכשיו להגדיר את המאגר example-organization-partner כדי להתחבר ל-IdP שלהם. לאחר מכן הוא יכול לאפשר לכוח עבודה של Partner Example Organization להיכנס עם פרטי הכניסה ל-IdP של Partner Example Organization. אחרי שמשתמשי כוח העבודה של Partner Example Organization נכנסו, הם יכולים לגשת Google Cloud למשאבים, בכפוף לכללי המדיניות שהוגדרו על ידי Enterprise Example Organization.

שיטות מומלצות לשימוש בקבוצות אבטחה

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

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

מגבלות של VPC Service Controls

תכונות ניהול של איחוד שירותי אימות הזהות של כוח עבודה, כולל ממשקי API להגדרת מאגרי כוח עבודה, לא תומכות ב-VPC Service Controls. עם זאת, Google Cloud מוצרים שתומכים גם באיחוד שירותי אימות הזהות של כוח עבודה וגם ב-VPC Service Controls פועלים כמו שמתואר במסמכים, והם כפופים לבדיקות מדיניות של VPC Service Controls. בנוסף, אפשר להשתמש בזהויות של צד שלישי, כמו משתמשים במאגר הזהויות של כוח העבודה וזהויות של עומסי עבודה, בכללי תעבורת נתונים נכנסת (ingress) או יוצאת (egress) של VPC Service Controls.

עבור בקשות Security Token Service API שבהן קהל היעד הוא מאגר איחוד שירותי אימות הזהויות של כוח עבודה (שהוא משאב ברמת הארגון), צריך להגדיר כללי יציאה. הפעולה הזו נדרשת כי VPC Service Controls לא תומך בהוספה ישירה של משאבים ברמת הארגון לאזורים. כללי תעבורת נתונים יוצאת (egress) הבאים מאפשרים לבקשות שמקורן בגבולות הגזרה להגיע אל Workforce STS APIs שפועלים עם מאגרי עובדים ברמת הארגון:

- egressTo:
    operations:
      - serviceName: 'sts.googleapis.com'
        methodSelectors:
          - method: '*'
    resources:
      - '*'
  egressFrom:
    identityType: ANY_IDENTITY

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

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

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

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