זהויות וחשבונות משתמשים

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

בסביבת Android Enterprise, יש שלוש מערכות שונות שבהן מאוחסן מידע על חשבונות משתמשים:

• ספריית המשתמשים של הארגון היא המקור המוסמך למידע על המשתמשים.
• אתם (ספקי פתרונות ה-EMM) צריכים לשמור לפחות על ספרייה מינימלית של משתמשי הארגון.
• ‫Google שומרת מידע מסוים על חשבונות Google מנוהלים ועל חשבונות Google כדי לספק ניהול אפליקציות דרך Google Play.

---

משאב Users מייצג חשבון שמשויך לארגון. החשבון יכול להיות ספציפי למכשיר, או להיות משויך לאדם שיש לו כמה מכשירים ומשתמש בחשבון בכל המכשירים. החשבון יכול לספק גישה רק ל-Google Play לניהול מכשירי ארגון, או לשירותים אחרים של Google, בהתאם לאופן שבו הגדרתם את הארגון של הלקוח:

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

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

טבלה 1: שדות ושיטות של Users API

	חשבונות Google Play מנוהלים	חשבונות Google מנוהלים
שדה
id [מזהה]
סיווג
accountIdentifier	מזהה ייחודי שאתם יוצרים וממפים למזהה (userId) שמוחזר מ-Google Play. לא להשתמש בפרטים אישיים מזהים (PII).	לא מוגדר.
accountType	deviceAccount, userAccount	userAccount
displayName	השם שמוצג ברכיבי ממשק משתמש, למשל ב-Google Play. אל תשתמשו בפרטים אישיים מזהים.	לא מוגדר.
managementType	emmManaged	googleManaged, emmManaged
primaryEmail	לא מוגדר.	השדה הזה הוא המפתח הראשי שבאמצעותו מנהלים את הסנכרון מחשבונות דומיין בניהול Google לחשבונות משתמש במערכת.
Methods
delete
generateAuthenticationToken
generateToken
get
getAvailableProductSet
insert
list
revokeToken
setAvailableProductSet
עדכון

---

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

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

שיפורים בהרשמה

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

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

ביצענו את השינויים הבאים:

• האימות של משתמש הקצה במהלך שיוך המכשיר מטופל עכשיו על ידי Google/Android. בקר מדיניות המכשיר (DPC) של EMM דורש שמערכת Android תאמת את המשתמש בנקודה המתאימה, ואז מערכת Android מחזירה את הזהות של המשתמש המחובר לבקר DPC.

• כשמבקשים אימות משתמש, מערכת ה-EMM צריכה להעביר אסימון הרשמה ל-Android. הטוקן הזה מוחזר על ידי קריאה ל-Android Enterprise API, ויכול להיות שהוא מקודד בתוך מטען הייעודי (payload) של קוד ה-QR, של NFC או של הרשמה ללא מגע.

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

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

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

יתרונות

התהליך החדש כולל את השיפורים העיקריים הבאים:

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

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

• חוויית משתמש משופרת: עם חשבונות Google מנוהלים, אתם מקבלים חוויית שימוש עשירה יותר ב-Android, שכוללת תכונות עוצמתיות לשימוש במכשירים שונים, כמו שיתוף והעתקה והדבקה.

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

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

מחזור החיים של חשבונות Google מנוהלים

בארגונים שמשתמשים בחשבונות Google, חשבונות המשתמשים בפתרון EMM משקפים חשבונות משתמשים קיימים שמשויכים לשירות אחר של Google (כמו Google Workspace). החשבונות האלה הם googleManaged (טבלה 1) כי שירותי הקצה העורפי של Google הם המקור ליצירה של החשבון ולמידע עליו.

כספקי EMM, אתם יכולים לספק מנגנונים במסוף שלכם כדי להקל על יצירה וסנכרון שוטף של חשבונות משתמשים שמוחזקים במערכת שלכם עם מקורות חשבונות הדומיין של Google באמצעות כלים כמו Google Cloud Directory Sync‏ (GCDS) ו-Google Admin SDK Directory API. לסקירה כללית של גישות שונות. מודל הזהויות של דומיין שמנוהל על ידי Google דורש שחשבון המשתמש יתקיים בהקשר של הפתרון שלכם (מסוף EMM, שרת EMM, אולי במאגר נתונים) לפני שאפשר יהיה להקצות אותו לאחד מהמכשירים של המשתמש בהקשר של פרופיל לצורכי עבודה.

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

סנכרון של חשבונות לקוח

בפריסה של חשבונות Google, הארגון יכול להשתמש בכלי GCDS כדי לסנכרן את הנתונים בדומיין G Suite עם הנתונים בספריית LDAP. לחלופין, אם הארגון נותן לכם גישה, אתם יכולים להשתמש ב-GCDS כדי לעשות זאת בשם הארגון.

הכלי GCDS קורא ל-Google Directory API ומסנכרן שמות משתמשים, אבל לא סיסמאות.

אם הארגון משתמש ב-Microsoft Active Directory ורוצה לשמור על סנכרון בין הסיסמאות של המשתמשים ב-G Suite לבין הסיסמאות שלהם ב-Active Directory, הוא יכול להשתמש בכלי G Suite Password Sync‏ (GSPS) עם GCDS.

הוראות לאדמינים לגבי GCDS מופיעות במאמר הכנת הדומיין שלכם ב-G Suite לסינכרון.

Google Directory API

בפריסה של חשבונות Google, אפשר להשתמש ב-Google Directory API כדי לסנכרן ספריות פעילות, סיסמאות או את שניהם:

• שימוש ב-Directory API לסנכרון של ספריות בלבד אם יש לכם גישת קריאה בלבד לדומיין Google המנוהל של הארגון, אתם יכולים להשתמש ב-Google Directory API כדי לקבל מ-Google מידע על חשבון Google, כמו שמות משתמשים (אבל לא סיסמאות). מכיוון שאין לכם אפשרות לכתוב נתונים בחשבונות Google של המשתמשים, הארגון אחראי באופן מלא למחזורי החיים של החשבונות.

  תרחיש 1 ותרחישי אימות של כניסה יחידה (SSO) מבוססת-SAML מתארים את המצב הזה בצורה מלאה יותר.

  מידע על שימוש ב-Directory API בדרך הזו זמין במאמר אחזור כל המשתמשים בחשבון במסמכי התיעוד של Directory API.

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

  תרחיש 2 מתאר את המצב הזה בצורה מלאה יותר.

  במדריך למפתחים בנושא Directory API: User Accounts מוסבר איך משתמשים ב-Directory API כדי לנהל את פרטי חשבונות המשתמשים.

תרחישים של חשבונות Google

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

תרחיש 1: הלקוח אחראי למחזורי החיים של החשבונות

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

אתם מקבלים מידע על חשבונות משתמשים מתוך ספריית ה-LDAP של הארגון, ומשווים אותו לנתוני חשבון Google שאתם מקבלים מ-Google באמצעות Directory API של Google.

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

במקרה כזה:

• יש לכם הרשאת קריאה בלבד לחשבונות Google.
• מסד הנתונים שלכם מקבל שמות של חשבונות Google, אבל לא שמות משתמש או סיסמאות של LDAP.
• אתם משתמשים ב-Google Directory API כדי לקבל מידע בסיסי על החשבון של המשתמשים של הלקוח. (המידע שזמין לכם הוא מידע שלא ניתן לערוך אותו, שמוחזר על ידי בקשת Users.get). אתם משתמשים במידע הזה כדי לוודא שחשבונות Google של המשתמשים קיימים, כדי שהמשתמשים יוכלו לאמת את הזהות שלהם במכשירים.
• הלקוח משתמש בכלי GCDS כדי לבצע סנכרון חד-כיווני לאכלוס חשבונות Google של משתמשים. (הארגון כנראה משתמש גם ב-GCDS לסינכרון שוטף משלו אחרי השלמת הקצאת ההרשאות). אפשר גם להשתמש בכלי GSPS כדי לסנכרן לא רק את שמות המשתמשים, אלא גם את הסיסמאות.

תרחיש 2: מערכת ה-EMM אחראית למחזורי החיים של החשבונות

בתרחיש הזה, אתם מטפלים בתהליך של יצירת חשבונות Google בשם הלקוח, ואתם אחראים למחזור החיים של חשבונות המשתמשים.

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

במקרה כזה:

• יש לכם הרשאת קריאה וכתיבה בחשבונות Google.
• מסד הנתונים מקבל שמות של חשבונות Google ושמות משתמשים ב-LDAP (ואופציונלית, גיבובים של סיסמאות).
• אתם משתמשים ב-Google Directory API בשם הלקוח כדי לקרוא ולכתוב פרטי חשבון של משתמשים בארגון. (המידע שזמין לכם הוא המידע שאי אפשר לכתוב בו, שמוחזר על ידי בקשת Users.get). אתם משתמשים במידע הזה כדי לוודא שחשבונות Google של המשתמשים קיימים, כדי שהמשתמשים יוכלו לאמת את הזהות שלהם במכשירים.
• לא נעשה שימוש בכלי GCDS.

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

תרחישי אימות של כניסה יחידה (SSO) מבוססת-SAML

בפריסה של חשבונות Google, יכול להיות שאתם או הלקוח שלכם תשתמשו ב-Security Assertion Markup Language ‏ (SAML) עם ספק זהויות (IdP) כדי לאמת את חשבון Google שמשויך לכל משתמש. אתם משתמשים בשמות של חשבונות Google כדי לוודא שחשבונות Google של המשתמשים קיימים. זה נדרש לאימות המשתמשים כשהם נכנסים למכשירים שלהם. לדוגמה, אפשר להשתמש ב-SAML בתרחיש 2. לפרטים על אופן ההגדרה, אפשר לעיין במאמר בנושא הגדרת כניסה יחידה (SSO) לחשבונות G Suite.