החלטה לגבי צירוף זהויות ל-Google Cloud

Last reviewed 2026-01-02 UTC

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

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

סקירה כללית

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

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

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

נקודות החלטה לגבי צירוף משתמשים חדשים ל-UCP Identity

כדי לבחור את העיצוב הטוב ביותר להקצאת הרשאות לארגון, צריך לקבל את ההחלטות הבאות:

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

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

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

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

אפשרות 1: שימוש ב-Google כמקור הראשי לזהויות (ללא איחוד)

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

ב-Cloud Identity וב-Google Workspace יש מבחר גדול של שילובים מוכנים לשימוש עם אפליקציות פופולריות של צד שלישי. אפשר גם להשתמש בפרוטוקולים סטנדרטיים כמו SAML,‏ OAuth ו-OpenID Connect כדי לשלב את האפליקציות המותאמות אישית עם Cloud Identity או עם Google Workspace.

כדאי להשתמש בשיטה הזו אם מתקיים התנאי הבא:

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

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

למידע נוסף, קראו את המאמרים הבאים:

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

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

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

כדאי להשתמש בשיטה הזו אם מתקיים התנאי הבא:

  • יש לכם ספק זהויות קיים כמו Active Directory,‏ Microsoft Entra ID,‏ ForgeRock,‏ Okta או Ping Identity.
  • אתם רוצים שהעובדים ישתמשו בזהות ובפרטי הכניסה הקיימים שלהם כדי להיכנס ל- Google Cloud ולשירותי Google אחרים, כמו Google Ads ו-Google Marketing Platform.

לא מומלץ להשתמש בשיטה הזו אם לארגון שלכם אין ספק זהויות קיים.

למידע נוסף, קראו את המאמרים הבאים:

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

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

כדאי להשתמש בשיטה הזו אם מתקיים התנאי הבא:

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

לא מומלץ להשתמש באסטרטגיה הזו אם לארגון שלכם אין ספק זהויות קיים או אם המשתמשים שלכם צריכים גישה לשירותים אחרים של Google, כמו Google Workspace או Google Ads.

למידע נוסף, קראו את המאמרים הבאים:

איך לאחד חשבונות משתמשים קיימים

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

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

אלה האפשרויות לאיחוד החשבונות:

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

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

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

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

כדאי להשתמש בשיטה הזו אם מתקיים התנאי הבא:

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

  • אין לכם חשבונות משתמשים לצרכן בדומיין.
  • אתם רוצים לוודא שכל הנתונים מכל חשבונות המשתמשים לצרכן בדומיין שלכם יאוחדו לחשבונות מנוהלים לפני שתתחילו להשתמש ב-Google Cloud.

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

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

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

כדאי להשתמש בשיטה הזו אם מתקיים התנאי הבא:

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

לא מומלץ להשתמש באסטרטגיה הזו אם רוצים לחסוך זמן בתהליך האיחוד.

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

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

אפשר להסיר חשבונות לשימוש אישי בנסיבות הבאות:

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

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

כדאי להשתמש בשיטה הזו אם מתקיים התנאי הבא:

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

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

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

שיטות מומלצות להוספת זהויות

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

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

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

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

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

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

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