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

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

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

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

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

שיקולים ארכיטקטוניים:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שיטות מומלצות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שיטות מומלצות:

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

משתמשים במאגר אחד לכל IdP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שיטות מומלצות:

בחירת שם משמעותי לספק.
משתמשים בפורטל האפליקציות של ספק הזהויות כדי לחשוף שירותים ספציפיים.
משתמשים בספק אחד לכל מאגר כדי למנוע התנגשויות בין נושאים.
משתמשים באותו מאגר ובאותו ספק עבור Google Cloud מסוף Gemini Enterprise.
שימוש ב-URI של מנפיק ספציפי לדייר.
מומלץ להימנע משימוש בזרם הענקת גישה משתמע של OpenID Connect ‏ (OIDC).

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

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

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

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

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

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

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

בקשת הצטרפות כתובת URL
Google Cloud מסוף איחוד שירותי אימות הזהות של כוח העבודה, שנקרא גם המסוף (מאוחד) https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fconsole.cloud.google
Gemini Enterprise https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fvertexaisearch.cloud.google%2Fhome%2Fcid%2FWEBAPP_ID
‫NotebookLM Enterprise https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fnotebooklm.cloud.google%2Fglobal%2F%3Fproject%3DPROJECT_NUMBER
אפליקציות אינטרנט עם רכישות מתוך האפליקציה כתובת ה-URL של האפליקציה, לדוגמה https://iap.example.com/

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

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

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

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

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

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

שימוש באותו מאגר ואותו ספק בשביל מסוף Google Cloud ו-Gemini Enterprise

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

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

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

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

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

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

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

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

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

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

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

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

שיטות מומלצות:

שימוש במזהה נושא שלא ניתן לשינוי.
אין לעשות שימוש חוזר במזהי נושאים.‫
Microsoft Entra ID: צריך להשתמש ב-UPN כמזהה הנושא.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ניהול קבוצות

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

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

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

מקור Google Cloud Gemini Enterprise
SAML או אסימון מזהה
Microsoft Graph API - -
דייר SCIM - -

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

מקור Google Cloud Gemini Enterprise
SAML או אסימון מזהה - -
Microsoft Graph API
דייר SCIM - -

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

  • ‫Gemini Enterprise משתמש בחברות בקבוצות מדייר ה-SCIM ומתעלם מפרטי החברות בקבוצות מטענת הנכונות (assertion) של SAML או מהאסימון המזהה.
  • Google Cloud משתמש בפרטי החברות בקבוצה מטענת ה-SAML או מהאסימון המזהה, ומתעלם מפרטי החברות בקבוצה מדייר SCIM.
מקור Google Cloud Gemini Enterprise
SAML או אסימון מזהה -
Microsoft Graph API - -
דייר SCIM -

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

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

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

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

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

שיטות מומלצות:

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

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

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

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

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

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

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

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

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

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

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

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

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

    • כדי לנהל את הגישה אל Google Cloud, צריך לכלול קבוצות גישה וקבוצות אכיפה.
    • המסנן שנדרש כדי לנהל את הגישה ל-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 במסוף Google Cloud או להפעיל detailed audit logging.

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

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

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

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

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

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

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

ניהול הגישה

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

שיטות מומלצות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יכול להיות שאימותים נוספים בכניסה יחידה ייראו מיותרים אם ספק הזהויות כבר אוכף אימות רב-שלבי, אבל ההגדרה הזו עוזרת להגן על המשתמשים אם ספק הזהויות נפרץ. אימותים נוספים של 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/*

המזהה הזה תואם לכל משתמש שספק הזהויות מאפשר לו להתאמת ל-Google Cloud.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בכל פעם שמבחינים בפעילות חשודה שמשפיעה על משאב ב-Google Cloud, יומני הביקורת של 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 בכלGoogle Cloud הארגון. כדי להגדיל עוד יותר את רמת הפירוט של יומני הכניסה, מפעילים רישום מפורט ביומן הביקורת.

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

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