כל שירותי Google, כולל Google Cloud, Google Marketing Platform ו-Google Ads, מסתמכים על הכניסה לחשבון Google לאימות משתמשים. במאמר הזה מוסבר על מודל הדומיין שעליו מסתמכת מערכת הכניסה לחשבון Google לצורך אימות וניהול זהויות. מודל הדומיין עוזר להבין איך הכניסה באמצעות חשבון Google פועלת בהקשר ארגוני, איך מנוהלים אמצעי הזיהוי ואיך אפשר לשלב אותה עם ספק זהויות (IdP) חיצוני. בתרשים הבא מוצגת האינטראקציה בין הישויות האלה.
כפי שרואים בתרשים הזה, במרכז המודל נמצא הזהות של Google, שמשמשת לכניסה באמצעות חשבון Google. הזהות ב-Google קשורה למספר ישויות אחרות שכולן רלוונטיות בהקשר של ניהול זהויות:
- Google for consumers מכיל את הישויות שרלוונטיות לשימוש בשירותי Google כמו Gmail שמתמקדים בצרכנים.
- Google לארגונים כולל ישויות שמנוהלות על ידי Cloud Identity או Google Workspace. הישויות האלה הן הרלוונטיות ביותר לניהול זהויות ארגוניות.
- Google Cloud מכיל את הישויות שספציפיות ל-Google Cloud.
- הקטע External מכיל ישויות שרלוונטיות אם משלבים את Google עם ספק זהויות חיצוני.
חיצים מלאים בתרשים מציינים שיש הפניה בין ישויות או שיש ישות שמכילה ישות אחרת. לעומת זאת, חצים מקווקווים מציינים קשר פדרציה.
זהויות ב-Google
לזהויות, למשתמשים ולחשבונות משתמשים יש תפקיד חשוב בניהול הזהויות. שלושת המונחים קשורים זה לזה באופן הדוק, ולפעמים אפילו משתמשים בהם כמילים נרדפות. עם זאת, בהקשר של ניהול זהויות, כדאי להבחין בין המושגים:
זהות היא שם שמזהה באופן ייחודי את האדם שמקיים אינטראקציה עם שירות Google. Google משתמשת בכתובות אימייל למטרה הזו. כתובת האימייל של אדם מסוים נחשבת לזהות שלו ב-Google.
התהליך שבו מאמתים את הקשר בין אדם לבין זהות נקרא אימות או כניסה לחשבון. במסגרת התהליך הזה, האדם צריך להוכיח שזו אכן הזהות שלו.
יכול להיות שלאדם מסוים יש כמה כתובות אימייל. מכיוון ששירותי Google משתמשים בכתובת אימייל כמזהה, אדם כזה ייחשב כבעל כמה מזהים.
חשבון משתמש הוא מבנה נתונים שעוקב אחרי מאפיינים, פעילויות והגדרות שצריך להחיל בכל פעם שישות מסוימת מקיימת אינטראקציה עם שירות Google. חשבונות משתמשים לא נוצרים באופן אוטומטי, אלא צריך להקצות אותם לפני הכניסה הראשונה.
חשבונות משתמשים מזוהים באמצעות מזהה שלא נחשף חיצונית. לכן, בממשקי משתמש או בממשקי API צריך להפנות לחשבון המשתמש באופן עקיף באמצעות הזהות המשויכת שלו, כמו
alice@gmail.com. למרות ההפניה העקיפה הזו, כל הנתונים ופרטי ההגדרה משויכים לחשבון המשתמש, ולא לזהות.
ברוב המקרים, יש קשר של אחד לאחד בין חשבונות משתמשים לבין זהויות, ולכן קל לבלבל ביניהם. עם זאת, זה לא תמיד המצב, כפי שמודגם במקרים הקיצוניים הבאים:
הקשר בין חשבונות משתמשים לבין זהויות לא קבוע. אתם יכולים לשנות את כתובת האימייל הראשית של חשבון משתמש, וכך לשייך למשתמש זהות אחרת.
אדמינים ב-Cloud Identity או ב-Google Workspace יכולים אפילו להחליף בין כתובות האימייל הראשיות של שני משתמשים. לדוגמה, אם החלפתם את כתובות האימייל הראשיות של אליס (
alice@example.com) ושל בוב (bob@example.com), אליס תשתמש בחשבון המשתמש הקודם של בוב ובוב ישתמש בחשבון המשתמש הקודם של אליס. הנתונים וההגדרות משויכים לחשבון המשתמש ולא לזהות, ולכן אליס תשתמש עכשיו גם בהגדרות ובנתונים הקיימים של בוב (ובוב ישתמש עכשיו בהגדרות ובנתונים של אליס). באיור הבא מוצג הקשר הזה.
בהגדרה לא מאוחדת, צריך גם לאפס את הסיסמאות כדי שאליס ובוב יוכלו להחליף חשבונות משתמשים. בהגדרה מאוחדת שבה אלי ודני משתמשים ב-IdP חיצוני כדי לבצע אימות, לא צריך לאפס את הסיסמאות.
יכול להיות שלא יהיה יחס של 1:1 בין הזהות לבין המשתמשים. אפשר לשייך חשבון פרטי לכמה זהויות בכוונה, כמו בדוגמה הבאה.
יכול להיות גם שזהות אחת מתייחסת לשני חשבונות משתמשים שונים. מומלץ להימנע מהמצב הזה, אבל הוא יכול לקרות במקרה של חשבון משתמש שמתנגש עם חשבון אחר. במקרה כזה, במהלך האימות מוצג למשתמש מסך בחירה שבו הוא בוחר את חשבון המשתמש שבו הוא רוצה להשתמש.
Google מבחינה בין שני סוגים של חשבונות משתמשים: חשבונות משתמשים פרטיים וחשבונות מנוהלים. בקטעים הבאים מוסבר בפירוט על שני סוגי חשבונות המשתמשים ועל הישויות שקשורות אליהם.
Google למשתמשים פרטיים
אם יש לכם כתובת אימייל ב-Gmail כמו alice@gmail.com, אז חשבון Gmail שלכם הוא חשבון לשימוש פרטי. באופן דומה, אם משתמשים בקישור יצירת חשבון בדף הכניסה לחשבון Google, ובמהלך ההרשמה מספקים כתובת אימייל מותאמת אישית שנמצאת בבעלותכם, כמו alice@example.com, החשבון שייווצר יהיה גם חשבון פרטי.
חשבון פרטי
חשבונות לצרכן נוצרים בשירות עצמי ומיועדים בעיקר לשימוש פרטי. למי שיצר את החשבון הפרטי יש שליטה מלאה בחשבון ובכל הנתונים שנוצרו באמצעות החשבון. כתובת האימייל שבה אותו אדם השתמש במהלך ההרשמה הופכת לכתובת אימייל ראשית של חשבון פרטי, ומשמשת כזהות שלו. האדם הזה יכול להוסיף כתובות אימייל לחשבון פרטי. כתובות האימייל האלה משמשות כזהויות נוספות ואפשר להשתמש בהן גם לכניסה לחשבון.
כשמשתמשים בחשבון לצרכן בכתובת אימייל ראשית שתואמת לדומיין הראשי או המשני של חשבון Cloud Identity או Google Workspace, החשבון לצרכן נקרא גם חשבון משתמש לא מנוהל.
חשבון פרטי יכול להיות חבר בכל מספר של קבוצות.
Google לארגונים
אם הארגון שלכם משתמש בשירותי Google, מומלץ להשתמש בחשבונות משתמשים מנוהלים. החשבונות האלה נקראים מנוהלים כי הארגון יכול לשלוט באופן מלא במחזור החיים ובהגדרות שלהם.
חשבונות מנוהלים הם תכונה של Cloud Identity ו-Google Workspace.
חשבון Cloud Identity או Google Workspace
חשבון Cloud Identity או Google Workspace הוא המאגר ברמה העליונה של משתמשים, קבוצות, הגדרות ונתונים. חשבון Cloud Identity או Google Workspace נוצר כשחברה נרשמת ל-Cloud Identity או ל-Google Workspace, והוא מקביל למושג דייר.
Cloud Identity ו-Google Workspace חולקים פלטפורמה טכנית משותפת. שני המוצרים משתמשים באותה קבוצה של ממשקי API וכלי ניהול, וכוללים את הרעיון של חשבון כמאגר למשתמשים ולקבוצות. המאגר הזה מזוהה באמצעות שם דומיין. לצורך ניהול משתמשים, קבוצות ואימות, אפשר להחשיב את שני המוצרים כדומים ברוב המקרים.
חשבון מכיל קבוצות ויחידה ארגונית אחת או יותר.
יחידה ארגונית
יחידה ארגונית (OU) היא קונטיינר משנה של חשבונות משתמשים, שמאפשר לפלח את חשבונות המשתמשים שמוגדרים בחשבון Cloud Identity או בחשבון Google Workspace לקבוצות נפרדות, כדי להקל על הניהול שלהם.
היחידות הארגוניות מאורגנות בצורה היררכית. לכל חשבון Cloud Identity או חשבון Google Workspace יש יחידה ארגונית בסיסית, שמתחתיה אפשר ליצור עוד יחידות ארגוניות לפי הצורך. אפשר גם ליצור יחידות ארגוניות מקוננות.
ב-Cloud Identity וב-Google Workspace אפשר להחיל הגדרות מסוימות לפי יחידה ארגונית, כמו הקצאת רישיונות או אימות דו-שלבי. ההגדרות האלה חלות באופן אוטומטי על כל המשתמשים ביחידה הארגונית, והן גם עוברות בירושה ליחידות ארגוניות ברמת הצאצא. לכן, ליחידות ארגוניות יש תפקיד חשוב בניהול ההגדרות של Cloud Identity ו-Google Workspace.
חשבון משתמש לא יכול להשתייך ליותר מיחידה ארגונית אחת, ולכן יחידות ארגוניות שונות מקבוצות. יחידות ארגוניות שימושיות להחלת הגדרות על חשבונות משתמשים, אבל הן לא מיועדות לניהול גישה. כדי לנהל את הגישה, מומלץ להשתמש בקבוצות.
למרות שיחידות ארגוניות דומות לGoogle Cloud תיקיות, הן משמשות למטרות שונות ואין קשר ביניהן.
חשבון מנוהל
חשבונות משתמשים מנוהלים פועלים באופן דומה לחשבונות משתמשים לצרכנים, אבל אדמינים של חשבון Cloud Identity או Google Workspace יכולים לשלוט בהם באופן מלא.
הזהות של חשבון משתמש מנוהל מוגדרת על ידי כתובת האימייל הראשית שלו. כתובת האימייל הראשית חייבת להשתמש בדומיין שתואם לאחד מהדומיינים הראשיים, המשניים או דומייני הכינוי שנוספו לחשבון Cloud Identity או לחשבון Google Workspace. לחשבונות משתמשים מנוהלים יכולות להיות כתובות אימייל נוספות שהן כינויים וכתובת אימייל לשחזור חשבון, אבל הכתובות האלה לא נחשבות לזהויות ואי אפשר להשתמש בהן לכניסה. לדוגמה, אם כתובת האימייל הראשית של אליס היא alice@example.com והיא הגדירה את ally@example.com ככתובת אימייל שהיא כינוי ואת alice@gmail.com ככתובת אימייל לשחזור חשבון, אז כתובת האימייל היחידה שאליס יכולה להשתמש בה לכניסה היא alice@example.com.
חשבונות מנוהלים נכללים ביחידה ארגונית ויכולים להיות חברים בכל מספר של קבוצות.
חשבונות משתמשים מנוהלים מיועדים לשימוש על ידי משתמשים אנושיים ולא על ידי משתמשים שהם מכונות. חשבון משתמש שהוא מכונה הוא סוג מיוחד של חשבון שמשמש אפליקציה או מכונה וירטואלית (VM), ולא אדם. למשתמשים שהם מכונות,Google Cloud מספק חשבונות שירות. (בהמשך המסמך מופיע מידע נוסף על חשבונות שירות).
קבוצה
קבוצות מאפשרות לכם לאגד כמה משתמשים. אתם יכולים להשתמש בקבוצות כדי לנהל רשימת תפוצה או כדי להחיל בקרת גישה או הגדרה משותפת על כמה משתמשים.
ב-Cloud Identity וב-Google Workspace, קבוצות מזוהות לפי כתובת אימייל – לדוגמה, billing-admins@example.com. בדומה לכתובת האימייל הראשית של משתמש, כתובת אימייל קבוצתית צריכה להיות אחת מהכתובות בדומיינים הראשיים, המשניים או החלופיים של חשבון Cloud Identity או Google Workspace. כתובת האימייל לא צריכה להתאים לתיבת דואר, אלא אם הקבוצה משמשת כרשימת תפוצה. האימות עדיין מתבצע באמצעות כתובת האימייל של המשתמש ולא באמצעות כתובת אימייל קבוצתית, ולכן משתמש לא יכול להיכנס באמצעות כתובת אימייל קבוצתית.
הקבוצה יכולה לכלול את הישויות הבאות כחברים:
- משתמשים (משתמשים מנוהלים או חשבונות לשימוש אישי)
- קבוצות אחרות
- חשבונות שירות
בניגוד ליחידה ארגונית, קבוצות לא פועלות כמאגר:
- משתמש או קבוצה יכולים להיות חברים בכל מספר של קבוצות, לא רק בקבוצה אחת.
- מחיקה של קבוצה לא מוחקת את המשתמשים או הקבוצות שחברים בה.
קבוצות יכולות לכלול חברים מכל חשבון Cloud Identity או Google Workspace, וגם מחשבונות פרטיים. אפשר להשתמש בהגדרה איסור הוספת חברים שלא מהארגון כדי להגביל את החברים לחשבונות משתמשים מאותו חשבון Cloud Identity או Google Workspace.
זהויות חיצוניות
איחוד של חשבון Cloud Identity או Google Workspace עם ספק זהויות חיצוני מאפשר לעובדים להשתמש בזהות ובפרטי הכניסה הקיימים שלהם כדי להיכנס לשירותי Google.
ברמה הבסיסית ביותר, איחוד כולל הגדרה של כניסה יחידה (SSO) באמצעות SAML, שמקשרת בין זהויות ב-Cloud Identity או ב-Google Workspace לבין זהויות שמנוהלות על ידי ספק הזהויות החיצוני. כדי לקשר זהות כמו alice@example.com ולאפשר לה כניסה יחידה ל-Google, צריך לעמוד בשני תנאים מוקדמים:
- ספק הזהויות החיצוני צריך לזהות את הזהות
alice@example.comולאפשר להשתמש בה לכניסה יחידה. - בחשבון שלכם ב-Cloud Identity או ב-Google Workspace צריך להיות חשבון משתמש שמשתמש ב-
alice@example.comבתור הזהות שלו. חשבון המשתמש הזה צריך להתקיים לפני הניסיון הראשון לכניסה יחידה.
במקום ליצור ולתחזק חשבונות משתמשים ב-Cloud Identity או ב-Google Workspace באופן ידני, אתם יכולים לשלב בין כניסה יחידה (SSO) מבוססת SAML לבין הקצאת הרשאות אוטומטית למשתמשים כדי לאוטומט את התהליך. הרעיון מאחורי הקצאת הרשאות אוטומטית למשתמשים הוא לסנכרן את כל המשתמשים והקבוצות או חלק מהם ממקור חיצוני מהימן עם Cloud Identity או Google Workspace.
בהתאם לבחירה שלכם בספק הזהויות, יכול להיות שרכיב התוכנה יטפל גם בכניסה יחידה שמבוססת על SAML וגם בהקצאת הרשאות אוטומטית למשתמשים, או שיידרשו רכיבים נפרדים. לכן, מודל הדומיין מבחין בין ספק זהויות SAML לבין מקור חיצוני מהימן.
ספק זהויות חיצוני של SAML
ספק הזהויות החיצוני הוא המערכת היחידה לאימות, והוא מספק לעובדים חוויית כניסה יחידה שמשתרעת על פני אפליקציות. הוא חיצוני ל-Google, ולכן הוא נקרא ספק זהויות חיצוני.
כשמגדירים כניסה יחידה, מערכת Cloud Identity או Google Workspace מעבירה החלטות אימות לספק זהויות (IdP) בשיטת SAML. במונחים של SAML, Cloud Identity או Google Workspace פועלים כספק שירותים שנותן אמון ב-IdP של SAML כדי לאמת את זהות המשתמש בשמו.
ספקי הזהויות החיצוניים הנפוצים כוללים את Active Directory Federation Services (AD FS), Entra ID, Okta או Ping Identity.
מקור חיצוני מהימן
המקור המוסמך לזהויות הוא המערכת היחידה שבה אתם משתמשים כדי ליצור, לנהל ולמחוק זהויות של העובדים שלכם. הוא חיצוני ל-Google ולכן הוא נקרא מקור חיצוני מהימן.
ממקור חיצוני מהימן, אפשר להקצות באופן אוטומטי חשבונות משתמשים וקבוצות ל-Cloud Identity או ל-Google Workspace. יכול להיות שהקצאת ההרשאות מתבצעת על ידי המקור המוסמך עצמו, או באמצעות תוכנת ביניים להקצאת הרשאות.
כדי שהקצאת הרשאות אוטומטית למשתמשים תפעל בצורה יעילה, צריך להקצות למשתמשים זהות שספק הזהויות (IdP) של SAML מזהה. אם אתם ממפים בין זהויות (לדוגמה, אם אתם ממפים את הזהות alice@example.com ב-Cloud Identity או ב-Google Workspace ל-u12345@corp.example.com ב-IdP של SAML), אז גם ה-IdP של SAML וגם תוכנת הביניים לאספקת הרשאות צריכים לבצע את אותו מיפוי.
חשבון משתמש חיצוני
ספקי זהויות חיצוניים מניחים שיש להם מושג של חשבון משתמש שעוקב אחרי השם, המאפיינים וההגדרה.
ממקור הסמכותי (או מתוכנת הביניים לאספקת הרשאות) מצפים לספק את כל חשבונות המשתמשים החיצוניים (או קבוצת משנה שלהם) ל-Cloud Identity או ל-Google Workspace, כדי לאפשר חוויית כניסה חלקה. במקרים רבים, מספיק להעביר רק קבוצת משנה של מאפייני המשתמש (כמו כתובת אימייל, שם פרטי ושם משפחה) אל Cloud Identity או אל Google Workspace, כדי לצמצם את כפילות הנתונים.
קבוצה חיצונית
אם ספק הזהויות החיצוני תומך במושג של קבוצה, אתם יכולים גם למפות את הקבוצות האלה לקבוצות ב-Cloud Identity או ב-Google Workspace.
מיפוי קבוצות והקצאת הרשאות אוטומטית לקבוצות הם אופציונליים ולא נדרשים לכניסה יחידה, אבל שני השלבים יכולים להיות שימושיים אם רוצים לעשות שימוש חוזר בקבוצות קיימות כדי לשלוט בגישה ב-Google Workspace או Google Cloud.
Google Cloud
בדומה לשירותים אחרים של Google, Google Cloud מסתמך על הכניסה לחשבון Google כדי לאמת את המשתמשים. Google Cloud משולב גם באופן הדוק עם Google Workspace ו-Cloud Identity כדי לאפשר לכם לנהל את המשאבים בצורה יעילה.
Google Cloud מציג את המושגים של צמתי ארגון, תיקיות ופרויקטים. הישויות האלה משמשות בעיקר לניהול גישה והגדרות, ולכן הן רלוונטיות רק באופן חלקי בהקשר של ניהול זהויות. עם זאת, Google Cloud כולל גם סוג נוסף של חשבון משתמש: חשבונות שירות. חשבונות שירות שייכים לפרויקטים וממלאים תפקיד חשוב בניהול הזהויות.
צומת הארגון
ארגון הוא צומת הבסיס בהיררכיית המשאבים שלGoogle Cloud ומשמש כמאגר לפרויקטים ולתיקיות. ארגונים מאפשרים לכם לבנות היררכיה של משאבים, והם חיוניים לניהול משאבים בצורה מרכזית ויעילה.
כל ארגון שייך לחשבון אחד בלבד של Cloud Identity או של Google Workspace. שם הארגון נגזר משם הדומיין הראשי של חשבון Cloud Identity או Google Workspace התואם.
תיקייה
תיקיות הן צמתים ב Google Cloud היררכיית המשאבים, והן יכולות להכיל פרויקטים, תיקיות אחרות או גם וגם. אתם יכולים להשתמש בתיקיות כדי לקבץ משאבים שיש להם מדיניות משותפת של ניהול זהויות והרשאות גישה (IAM) או מדיניות ארגונית. המדיניות הזו חלה באופן אוטומטי על כל הפרויקטים בתיקייה, והיא גם עוברת בירושה לתיקיות צאצא.
תיקיות דומות ליחידות ארגוניות, אבל הן לא קשורות אליהן. יחידות ארגוניות עוזרות לכם לנהל משתמשים ולהחיל הגדרות או מדיניות משותפות על משתמשים, בעוד שתיקיות עוזרות לכם לנהל פרויקטים ולהחיל הגדרות או מדיניות משותפות על פרויקטים. Google Cloud
פרויקט
פרויקט הוא מאגר למשאבים. לפרויקטים יש תפקיד חשוב בניהול ממשקי API, חיוב וגישה למשאבים.
בניהול הזהויות, הפרויקטים רלוונטיים כי הם המאגרים של חשבונות השירות.
חשבון שירות
חשבון שירות (או Google Cloud חשבון שירות) הוא סוג מיוחד של חשבון משתמש שמיועד לשימוש באפליקציות ובסוגים אחרים של משתמשי מכונה.
כל חשבון שירות שייך לפרויקט Google Cloud . כמו בחשבונות משתמשים מנוהלים, אדמינים יכולים לשלוט באופן מלא במחזור החיים ובהגדרות של חשבון שירות.
גם חשבונות שירות משתמשים בכתובת אימייל כזהות שלהם, אבל בניגוד לחשבונות משתמש מנוהלים, כתובת האימייל תמיד משתמשת בדומיין בבעלות Google, כמו developer.gserviceaccount.com.
חשבונות שירות לא משתתפים בפדרציה וגם אין להם סיסמה. ב- Google Cloud, אתם משתמשים ב-IAM כדי לשלוט בהרשאה שיש לחשבון שירות למשאב מחשוב, כמו מכונה וירטואלית (VM) או פונקציית Cloud Run, וכך לא צריך לנהל פרטי כניסה. מחוץ ל- Google Cloud, אפשר להשתמש במפתחות של חשבונות שירות כדי לאפשר לאפליקציה לבצע אימות באמצעות חשבון שירות.
חשבון שירות Kubernetes
חשבונות שירות ב-Kubernetes הם מושג ב-Kubernetes והם רלוונטיים כשמשתמשים ב-Google Kubernetes Engine (GKE). בדומה לחשבונות שירות, חשבונות שירות של Kubernetes מיועדים לשימוש של אפליקציות, ולא של בני אדם. Google Cloud
אפשר להשתמש בחשבונות שירות של Kubernetes כדי לבצע אימות כשיישום קורא ל-Kubernetes API של אשכול Kubernetes, אבל אי אפשר להשתמש בהם מחוץ לאשכול. ממשקי Google API לא מזהים אותם, ולכן הם לא יכולים להחליף Google Cloud חשבון שירות.
כשפורסים אפליקציה כPod של Kubernetes, אפשר לשייך את ה-Pod לחשבון שירות. השיוך הזה מאפשר לאפליקציה להשתמש ב-Kubernetes API בלי להגדיר או לתחזק אישורים או פרטי כניסה אחרים.
באמצעות Workload Identity, אפשר לקשר חשבון שירות של Kubernetes לחשבון שירות Google Cloud . הקישור הזה מאפשר לאפליקציה גם לבצע אימות ל-Google APIs, שוב בלי צורך לתחזק אישורים או פרטי כניסה אחרים.
המאמרים הבאים
- כדאי לעיין בדוגמאות לארכיטקטורות לניהול זהויות.