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

איחוד שירותי אימות הזהות של כוח עבודה מאחד את Cloud de Confiance by S3NS הארגון עם ספק זהויות חיצוני (IdP) כדי לאפשר כניסה יחידה (SSO).

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

בחירה בארכיטקטורה הנכונה

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

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

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

• איחוד שירותי אימות הזהות ב-Cloud Identity
• איחוד שירותי אימות הזהות של כוח עבודה, ללא סנכרון
• איחוד שירותי אימות הזהות של כוח עבודה עם מערכת לניהול זהויות בין דומיינים (SCIM)
• איחוד שירותי אימות הזהות של כוח עבודה ו-Cloud Identity היברידי

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

חלוקת השימוש באיחוד לפי שירות

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

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

אם אתם משתמשים באיחוד זהויות ב-Cloud Identity ובאיחוד שירותי אימות הזהות של כוח העבודה במקביל, אתם יכולים לחלק את השימוש בהם בדרכים הבאות:

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

  • יתרון: לכל משתמש יש זהות אחת בכל שירותי Google ושיטת כניסה אחת.

  • חסרונות: יש כמה חסרונות בחלוקה למחיצות לפי משתמשים, כולל:

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

    • משתמשים מקבוצות שונות לא יכולים לשתף קישורים ביניהם כי כתובות ה-URL שבהן משתמשים Cloud de Confiance במסוף, ב-Gemini Enterprise ובכלים אחרים שונות בהתאם לדרך שבה המשתמשים נכנסים לחשבון.

    • יכול להיות שלמשתמשים מקבוצות שונות תהיה גישה לקבוצות שונות של תכונות.

• חלוקה למחיצות לפי שירות: מגדירים כל שירות, כמוCloud de Confiance או Gemini Enterprise, כך שהוא מעניק גישה רק למשתמשים שמחוברים באמצעות איחוד שירותי אימות הזהות של כוח העבודה או למשתמשי Cloud Identity, אבל אף פעם לא לשניהם.

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

מומלץ לבצע חלוקה למחיצות לפי שירות, ובמיוחד להפריד בין Gemini Enterprise ו-Gemini Notebook Enterprise לבין שירותים אחרים. ‫Gemini Enterprise ומסוף Cloud de Confiance הניהול הם כלים נפרדים שנועדו למשימות שונות. ההבדלים בתהליכי הכניסה שלהם צריכים להשפיע באופן מינימלי על חוויית המשתמש הכוללת.

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

חיזוק הממשל של הקבוצה

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

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

• כללי מדיניות הרשאה אחת או יותר
• אפס כללי מדיניות דחייה או יותר
• אפס או יותר מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB)

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

• חשבון ראשי: משתמש מאומת שמזוהה על ידי מזהה חשבון ראשי. מזהה חשבון ראשי של כוח עבודה דומה לזה: principal://iam.googleapis.com/locations/global/workforcePools/ POOL_ID/subject/SUBJECT

  מזהה החשבון הראשי כולל את הפרטים הבאים:

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

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

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

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

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

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

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

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

הבחנה בין סוגים שונים של קבוצות

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

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

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

• בשביל Cloud de Confiance, צריך רק קבוצות גישה וקבוצות לאכיפה.
• ב-Gemini Enterprise, אתם צריכים קבוצות גישה, קבוצות לאכיפה, וגם – אם אתם משתמשים במחברים שמבוססים על הטמעת נתונים – קבוצות ארגוניות ושיתופיות מסוימות.

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

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

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

כדי להגדיר קבוצות גישה:

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

משתמשים בקבוצות גישה למדיניות שמעניקה גישה, כולל:

• מדיניות הרשאות IAM
• כללי תעבורת נתונים נכנסת (ingress) ב-VPC Service Controls

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

• ‫widget-sales-dashboard-readers: מעניק גישת קריאה למערך נתונים ספציפי ב-BigQuery ולמרכז הבקרה שמשויך אליו.

• ‫dev-ssh-users: מעניק גישה ל-OS Login למכונות וירטואליות ב-Compute Engine בסביבת הפיתוח.

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

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

  • קבוצות ארגוניות כמו australia-fte מייצגות קבוצות כמו צוותים או לפי מיקום, ולא לפי תפקיד.

  • קבוצות תקשורת כמו security-discuss מיועדות לרשימות תפוצה או לשיתוף פעולה, ולא לקבוצות גישה.

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

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

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

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

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

• כללי מדיניות דחייה של IAM
• גבולות הגישה של חשבונות ראשיים
• כללי מדיניות של הארגון

דוגמאות לקבוצות אכיפה: users-in-restricted-locations, fedramp-low ו-mfa-users. בדרך כלל מספר קבוצות האכיפה קטן, ולא סביר שהוא ישפיע על מספר הקבוצות הכולל שהמשתמשים חברים בהן.

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

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

קבוצות ארגוניות מייצגות צוותים או קבוצות משנה במבנה הארגון, ובדרך כלל הן מבוססות על נתונים של משאבי אנוש. הקבוצות האלה לא מתאימות לניהול הגישה למשאבי Cloud de Confiance מהסיבות הבאות:

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

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

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

שימוש בקבוצות ארגוניות ובקבוצות שיתוף פעולה רק ב-Gemini Enterprise

קבוצות ארגוניות וקבוצות לשיתוף פעולה לא מתאימות לניהול גישה למשאבי Cloud de Confiance , אבל יכול להיות שתצטרכו אותן ל-Gemini Enterprise:

• הערכת ACL: כשמשתמשים במחברים שמבוססים על הטמעת נתונים כדי לשלב את Gemini Enterprise עם Microsoft 365, יכול להיות שהמערכת תיתקל במסמכים עם רשימות של בקרת גישה (ACL) שמפנות לקבוצות ארגוניות ולקבוצות שיתוף פעולה. אם ל-Gemini Enterprise אין גישה לחברות של משתמש בקבוצות האלה, יכול להיות שהוא לא יוכל להעריך בצורה נכונה אם למשתמש יש הרשאה לגשת למסמכים האלה.
• שיתוף נוטבוקים: ב-Gemini Notebook Enterprise, המשתמשים יכולים לשתף נוטבוקים. במקרים רבים, נוח יותר לאפשר למשתמשים לשתף מחברות עם קבוצות לשיתוף פעולה מאשר להגביל את השיתוף למשתמשים ספציפיים.

כדי לוודא שקבוצות משתמשים ארגוניות וקבוצות לשיתוף פעולה זמינות רק ב-Gemini Enterprise, אתם יכולים להגדיר את ספק ה-IdP באופן הבא:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• הגבלת הגישה למשתמשים לא מאוחדים: הגבלת גישת האדמין למספר קטן של משתמשים ב-Cloud Identity או ב-Google Workspace, כולל לפחות משתמש אחד עם גישת חירום.
• הגנה על משתמשים עם הרשאות אדמין: דורשים אימות דו-שלבי מכל המשתמשים עם הרשאות אדמין ומשתמשים עם גישת חירום.
• גישה בדיוק בזמן: אפשר להשתמש ב-Privileged Access Manager (PAM) כדי להעניק גישה אדמיניסטרטיבית בדיוק בזמן, במקום להעניק גישה קבועה.

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

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

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

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

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

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

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

• ספק הזהויות (IdP) שבו רוצים להשתמש לכניסה יחידה (SSO).
• מיפוי המאפיינים שמשמש להפקת מזהים של חשבונות משתמש מאסימונים או מטענות נכוֹנוּת (assertion) שסופקו על ידי ה-IdP.
• אופציונלי: דייר SCIM שמשמש לחיפוש מידע על חברות בקבוצה.

בחירת שם משמעותי לספק

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

מומלץ להימנע משימוש בשמות כמו oidc או saml, כי יכול להיות שהמשתמשים לא יכירו את ראשי התיבות האלה.

הצגת שירותים נפרדים בפורטל האפליקציות של ספק הזהויות (IdP)

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

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

בטבלה הבאה מפורטים שירותים נפוצים של Google שתומכים באיחוד שירותי אימות הזהות של כוח העבודה, וכתובות ה-URL לכניסה אוטומטית:

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

• ‫POOL: השם של מאגר הזהויות של כוח העבודה.
• ‫PROVIDER: שם ספק המאגר.
• ‫WEBAPP_ID: מזהה אתר Gemini Enterprise.
• ‫PROJECT_NUMBER: מספר הפרויקט של Gemini Notebook Enterprise.

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

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

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

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

שימוש באותו מאגר ובאותו ספק עבור Cloud de Confiance מסוף Gemini Enterprise

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

שימוש ב-URI של מנפיק ספציפי לדייר

כשמגדירים ספק, מציינים URI של מנפיק כדי לזהות באופן ייחודי את ספק הזהויות. עם זאת, בהתאם להגדרת ספק הזהויות, יכול להיות שמזהה ה-URI של הגורם המנפיק לא יהיה ייחודי לדייר של הארגון. לדוגמה, אם משתמשים ב-URI כללי או משותף של מנפיק, כמו נקודת הקצה הנפוצה של Microsoft Entra ID‏ (https://login.microsoftonline.com/common/v2.0), יכול להיות שתאפשרו בטעות למשתמשים מארגונים אחרים לבצע אימות לארגון שלכם Cloud de Confiance.

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

הימנעו משימוש בזרם הענקת גישה משתמע של OpenID Connect ‏ (OIDC)

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

ניהול משתמשים

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

1. קובעים את מזהה הנושא על ידי החלת מיפוי המאפיינים של google.subject. מזהה הנושא צריך להיות ייחודי למשתמש במאגר הזהויות של כוח העבודה, אבל הוא לא צריך להיות ייחודי ב- Cloud de Confiance.

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

   principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/\
   subject/SUBJECT
   

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

שימוש במזהה נושא שלא ניתן לשינוי

כשמזהה הנושא של משתמש משתנה, המזהה הראשי שלו משתנה. כתוצאה מכך, Cloud de Confiance המערכת לא מזהה אותם יותר כאותו משתמש:

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

כדי לשמור על יציבות של מזהה המשתמש הראשי, צריך להשתמש במיפוי מאפיינים שיוצר ערך יציב למאפיין google.subject.

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

כדי לעזור לכם לבחור מזהה ל-google.subject, כדאי לשקול את הדרישות הבאות לפי סדר עדיפות יורד:

1. ייחודיות: הערך מזהה באופן ייחודי משתמש ב-IdP.
2. שימושיות: הערך משמעותי, או לפחות ניתן לחיפוש בקלות בספריית המשתמשים של ספק ה-IdP.
3. אי אפשרות לשינוי: אי אפשר לשנות את הערך, או שאפשר לשנות אותו רק על ידי אדמינים.

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

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

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

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

• ממפים את google.subject למזהה משתמש שספק הזהויות לא מאפשר שימוש חוזר בו.
• כשמוחקים משתמש ב-IdP, צריך להשתמש ב-locations.workforcePools.subjects.delete API כדי למחוק את הנתונים של המשתמש ב- Cloud de Confiance ולחסום את השימוש באותו מזהה משתמש לכניסה לחשבון עד שכל הנתונים יימחקו באופן סופי.

Microsoft Entra ID: שימוש ב-UPN בתור מזהה הנושא

השיטה המומלצת הזו רלוונטית רק אם אתם משתמשים ב-Microsoft Entra ID כספק הזהויות (IdP).

אם אתם משתמשים ב-Microsoft Entra ID, המזהים שבהם אתם יכולים להשתמש כמזהה הנושא כוללים את האפשרויות הבאות:

• השם הראשי של המשתמש (upn)
• מזהה אובייקט (oid)
• כתובת אימייל (הכתובת הראשית ב-proxyAddresses)

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

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

לעומת זאת, מזהה האובייקט וכתובת האימייל של המשתמש פחות מתאימים מהסיבות הבאות:

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

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

ניהול קבוצות

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

• טענת הנכונות (assertion) של SAML או טוקן של מזהה שסופק על ידי ספק הזהויות (IdP).
• ‫Microsoft Graph API, אם אתם משתמשים ב-Microsoft Entra ID כספק הזהויות שלכם.
• דייר SCIM שמשויך לספק מאגר הזהויות של כוח העבודה.

כברירת מחדל, איחוד שירותי אימות הזהויות של כוח העבודה משתמש רק בטענת הנכונות (assertion) של SAML או בטוקן של מזהה:

אם אתם משתמשים ב-Microsoft Entra ID כספק הזהויות שלכם, אתם יכולים להפעיל את התכונה מאפיינים נוספים. לאחר מכן, איחוד שירותי אימות הזהות של כוח העבודה משתמש רק ב-Microsoft Graph API כמקור לחברויות בקבוצות:

אם אתם משתמשים ב-Gemini Enterprise, אתם יכולים להגדיר את איחוד שירותי אימות הזהות של כוח העבודה כך שישתמש בדייר SCIM. ההגדרה הזו משנה את ההתנהגות באופן הבא:

• ‫Gemini Enterprise משתמש בחברות בקבוצות מדייר SCIM ומתעלם מפרטי החברות בקבוצות מהצהרת SAML או מטוקן של מזהה.
• Cloud de Confiance משתמש במידע על חברות בקבוצה מתוך הצהרת SAML או טוקן של מזהה, ומתעלם ממידע על חברות בקבוצה מתוך דייר SCIM.

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

1. כדי לקבוע את מזהה הקבוצה, מבצעים אחת מהפעולות הבאות:
   • הצהרת SAML או טוקן של מזהה: צריך להחיל את מיפוי המאפיינים עבור google.groups.
   • דייר SCIM: צריך להחיל את מיפוי הטענות עבור google.group.
   • ‫Microsoft Graph API: פועלים לפי שלב extra-attributes-type בהגדרת הספק.

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

   principalSet://iam.googleapis.com/locations/global/workforcePools/\
   POOL_ID/group/GROUP_ID
   

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

שימוש במזהה קבוצה שלא ניתן לשינוי

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

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

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

צמצום מספר חברי הקבוצה בהצהרות או באסימונים

יכול להיות ש-IdP יכלול כברירת מחדל בטענות הנכונות (assertions) של SAML או באסימוני מזהה יותר חברויות בקבוצות ממה שנדרש לניהול הגישה ל-Gemini Enterprise ולמשאבי Cloud de Confiance . הכללת חברויות מיותרות בקבוצות יוצרת כמה סיכונים:

• אובדן חלקי של הגישה: ספקי זהויות רבים מטילים מגבלות על מספר החברויות בקבוצות שהם יכולים לכלול באסימון או בהצהרה. כשמשתמש חורג מהמגבלה הזו (חריגה של קבוצה), יכול להיות שספק הזהויות יסיר חלק מהחברויות בקבוצה, וכתוצאה מכך המשתמש יאבד גישה למשאבים מסוימים.
• כשלים בכניסה: איחוד שירותי אימות הזהות של כוח העבודה מגביל את הגודל ואת מספר החברויות בקבוצות שמיפוי המאפיינים google.groups יכול ליצור. משתמשים שחורגים מאחת המגבלות האלה לא יכולים להיכנס לחשבון.
• שימוש לא עקבי בקבוצות: אם חושפים קבוצות ל- Cloud de Confiance, בעלי הפרויקט עשויים להשתמש בקבוצות האלה כדי לנהל את הגישה למשאבים, גם אם לא התכוונתם להשתמש בקבוצות מסוימות ב-Cloud de Confiance.

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

• סינון לפי סוג קבוצה: חלק מספקי ה-IdP, כולל Microsoft Entra ID, מאפשרים להגדיר מסנן שקובע אילו קבוצות ייכללו בטענות נכוֹנוּת או באסימונים. אתם יכולים להגדיר מסנן להחרגת סוגי קבוצות שלא רלוונטיים להגדרה שלכם ולשירותים שאתם מתכננים להשתמש בהם.

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

  סוג הקבוצה	Cloud de Confiance	‫Gemini (ללא סנכרון)	‫Gemini‏ (SCIM)
  קבוצות גישה			-
  קבוצות אכיפה			-
  קבוצות ארגוניות	לא נדרש	*	-
  קבוצות של שיתוף פעולה	לא נדרש	*	-

  * חובה רק אם משתמשים במחברים שמבוססים על העברת נתונים.

  • כדי לנהל את הגישה ל Cloud de Confiance, צריך לכלול קבוצות גישה וקבוצות אכיפה.
  • הפילטר שנדרש לניהול הגישה ל-Gemini Enterprise תלוי בשאלה אם אתם משתמשים ב-SCIM. אם אתם משתמשים ב-SCIM,‏ Gemini Enterprise מתעלם מחברות בקבוצות שכלולות בהצהרות או באסימונים, כך שאתם לא צריכים לכלול קבוצות ספציפיות ל-Gemini Enterprise. אם אתם לא משתמשים ב-SCIM, אתם צריכים לכלול קבוצות גישה וקבוצות אכיפה שנדרשות ל-Gemini Enterprise. בהתאם לתוכניות שלכם להשתמש במחברים שמבוססים על הטמעת נתונים, יכול להיות שתצטרכו לכלול גם קבוצות מסוימות של שיתוף פעולה וקבוצות ארגוניות.

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

• מסנן מאפיינים נוספים: אם אתם משתמשים ב-Microsoft Entra ID והפעלתם את התכונה מאפיינים נוספים, אתם יכולים לציין מסנן באמצעות הדגל --extra-attributes-filter. איחוד שירותי אימות הזהות של כוח עבודה מעביר את המסנן הזה אל Microsoft Graph API כשמבקשים חברות בקבוצה.

כדי לבדוק או לפתור בעיות במסננים, אפשר להשתמש בכלי Debug IdP token במסוף Cloud de Confiance או להפעיל detailed audit logging.

Microsoft Entra ID: שימוש במזהה אובייקט כמזהה הקבוצה

השיטה המומלצת הזו רלוונטית רק אם אתם משתמשים ב-Microsoft Entra ID כספק הזהויות (IdP).

אם אתם משתמשים ב-Microsoft Entra ID, המזהים שבהם אתם יכולים להשתמש כמזהה הקבוצה כוללים את האפשרויות הבאות:

• מזהה אובייקט (oid)
• כתובת האימייל
• השם המוצג

מבין האפשרויות האלה, אנחנו ממליצים להשתמש במזהה האובייקט (oid) כמזהה הקבוצה מהסיבות הבאות:

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

לא משנה איזה מזהה תבחרו, מומלץ להימנע משינויים כמו המרה של המזהים לאותיות קטנות.

ניהול הגישה

שיטות מומלצות להגבלת הגישה ולניהול הרשאות גישה זמניות (JIT).

שימוש במשתמשי Cloud Identity לגישת חירום

כדי להבטיח גישה רציפה לסביבות Cloud de Confiance שלכם, מומלץ ליצור משתמשים עם גישת חירום לכל סביבה.

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

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

כדי לצמצם את הסיכונים האלה, כדאי להשתמש ב-Cloud Identity או ב-Google Workspace עבור משתמשים עם גישת חירום, גם אם אתם משתמשים באיחוד שירותי אימות הזהות של כוח העבודה עבור משתמשים אחרים:

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

מידע נוסף על משתמשים עם גישת חירום זמין במאמר בנושא שיטות מומלצות לגישה רציפה אל Cloud de Confiance by S3NS.

שימוש ב-Cloud Identity לגישה עם הרשאות גבוהות

למשתמשים עם הרשאות גבוהות יש גישה רחבה לסביבה Cloud de Confiance שלכם. דוגמאות למשתמשים כאלה:

• משתמשים עם התפקיד אדמין ארגוני (roles/resourcemanager.organizationAdmin)
• משתמשים עם התפקיד Security Admin ‏ (roles/iam.securityAdmin) או תפקיד דומה שיכול לשנות את מדיניות ההרשאות בחלקים משמעותיים בהיררכיית המשאבים שלכם ב- Cloud de Confiance

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

כדי לצמצם את הסיכונים האלה, כדאי להשתמש ב-Cloud Identity למשתמשים עם הרשאות גבוהות:

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

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

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

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

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

• מחילים אילוץ מותאם אישית של מדיניות הארגון על פרויקט Gemini Enterprise שמשתמש בפונקציה MemberTypeMatches כדי להגביל את סוגי החשבונות המורשים ל-iam.googleapis.com/WorkforcePoolPrincipal ו-iam.googleapis.com/WorkforcePoolPrincipalSet. אלה סוגי הגורמים המורשים העיקריים שמשמשים באיחוד שירותי אימות הזהות של כוח העבודה.
• בכל שאר הפרויקטים, מחילים אילוץ שמאפשר את כל סוגי החשבונות הראשיים, למעט iam.googleapis.com/WorkforcePoolPrincipal ו-iam.googleapis.com/WorkforcePoolPrincipalSet.

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

לא מעניקים גישה לכל החברים במאגר

איחוד שירותי אימות הזהות של כוח העבודה תומך במזהה ראשי עם wildcard בפורמט הבא:

principalSet://iam.googleapis.com/locations/global/workforcePools/
POOL_ID/*

המזהה הזה תואם לכל משתמש שספק הזהויות מאפשר לו לבצע אימות ל-Cloud de Confiance.

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

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

הגבלת אורך הסשן

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

• להשתמש במסוף (מאוחד) ולעבור בין Gemini Enterprise לבין פורטלים אחרים שתומכים באיחוד שירותי אימות הזהות של כוח העבודה.
• שימוש באפליקציות אינטרנט שמוגנות על ידי IAP.
• מקבלים אסימוני רענון מאוחדים ואסימוני גישה מאוחדים – לדוגמה, על ידי הפעלת gcloud auth login.

סשן נשאר בתוקף עד שאחד מהמקרים הבאים מתרחש:

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

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

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

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

התאמת משך הסשן לדרישות של גישת JIT

כדי לנהל גישה עם הרשאות, יכול להיות שספקי הזהויות שלכם תומכים בקבוצות עם הרשאות זמניות שחברים יכולים להפעיל באופן זמני. שימוש בקבוצות עם הרשאות זמניות לניהול גישה עם הרשאות מיוחדות ל- Cloud de Confiance או ל-Gemini Enterprise עלול להוביל לסיכונים הבאים:

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

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

מעקב אחרי הפעילות

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

הפעלת יומני גישה לנתונים

איחוד שירותי אימות הזהות של כוח העבודה יכול ליצור יומנים שמאפשרים לעקוב אחרי פעילויות של כניסה והחלפת אסימונים. ‫Security Token Service API כותב את היומנים האלה, שכוללים את השיטות הבאות:

• google.identity.sts.SecurityTokenService.WebSignIn
• google.identity.sts.SecurityTokenService.WebSignOut
• google.identity.sts.v1.SecurityTokenService.ExchangeToken
• google.identity.sts.v1beta.SecurityTokenService.ExchangeToken

כל היומנים שקשורים לפעילויות של כניסה והחלפת טוקנים מסווגים כיומני גישה לנתונים ומושבתים כברירת מחדל. כדי לתעד את היומנים האלה, צריך להפעיל את יומני הגישה לנתונים של Security Token Service API בכלCloud de Confiance הארגון. כדי להגדיל עוד יותר את רמת הפירוט של יומני הכניסה, מפעילים רישום מפורט ביומן הביקורת.

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

• יומני ביקורת של IAM SCIM
• יומני ביקורת של פרטי כניסה לחשבון שירות
• יומני ביקורת של התחברויות ב-Cloud Identity וב-Google Workspace

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

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