כל שירותי Google, כולל Google Cloud, Google Marketing Platform ו-Google Ads, מסתמכים על הכניסה לחשבון Google לאימות משתמשים. במאמר הזה מוסבר על מודל הדומיין שמשמש את Google Sign-In לאימות ולניהול זהויות. מודל הדומיין עוזר להבין איך הכניסה באמצעות חשבון Google פועלת בהקשר ארגוני, איך מתבצע ניהול הזהויות ואיך אפשר לשלב אותו עם ספק זהויות (IdP) חיצוני. בתרשים הבא מוצגות האינטראקציות בין הישויות האלה.
כפי שרואים בדיאגרמה הזו, במרכז המודל נמצא הזיהוי של Google, שמשמש לכניסה לחשבון Google. הזהות ב-Google קשורה למספר ישויות אחרות שכולן רלוונטיות בהקשר של ניהול זהויות:
- Google for consumers כולל את הישויות שרלוונטיות לשימוש בשירותי Google כמו Gmail שמתמקדים בצרכנים.
- Google for organizations מכיל ישויות שמנוהלות על ידי 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 יש יחידה ארגונית (OU) בסיסית, שמתחתיה אפשר ליצור עוד יחידות ארגוניות לפי הצורך. אפשר גם ליצור היררכיה של יחידות ארגוניות.
ב-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 ולהפעיל אותה לכניסה יחידה (SSO) ל-Google, צריך לעמוד בשני תנאים מוקדמים:
- ספק הזהויות החיצוני צריך לזהות את הזהות
alice@example.comולאפשר להשתמש בה לכניסה יחידה (SSO). - בחשבון שלכם ב-Cloud Identity או ב-Google Workspace צריך להיות חשבון משתמש שמשתמש ב-
alice@example.comבתור הזהות שלו. חשבון המשתמש הזה צריך להתקיים לפני הניסיון הראשון לכניסה יחידה.
במקום ליצור ולתחזק חשבונות משתמשים ב-Cloud Identity או ב-Google Workspace באופן ידני, אתם יכולים לשלב בין כניסה יחידה (SSO) שמבוססת על SAML לבין הקצאת הרשאות אוטומטית למשתמשים כדי להפוך את התהליך לאוטומטי. הרעיון מאחורי הקצאת הרשאות אוטומטית למשתמשים הוא לסנכרן את כל המשתמשים והקבוצות או חלק מהם ממקור חיצוני מהימן עם Cloud Identity או Google Workspace.
בהתאם לבחירה שלכם ב-IdP, יכול להיות שרכיב התוכנה יטפל בכניסה יחידה מבוססת 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 כולל גם סוג נוסף של חשבון משתמש: חשבונות שירות. חשבונות שירות שייכים לפרויקטים וממלאים תפקיד חשוב בניהול הזהויות.
צומת הארגון
ארגון הוא הצומת של הרמה הבסיסית (root) בהיררכיית המשאבים של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, בלי צורך לתחזק אישורים או פרטי כניסה אחרים.
המאמרים הבאים
- כדאי לעיין בדוגמאות לארכיטקטורות לניהול זהויות.