ב-Google Cloud Search, בקרת הגישה מבוססת על חשבון Google של המשתמש. כשמבצעים אינדוקס לתוכן, כל רשימות ה-ACL של הפריטים חייבות להפנות למזהי משתמשים או קבוצות תקינים ב-Google (כתובות אימייל).
במקרים רבים, למאגר אין ידע ישיר לגבי חשבונות Google. במקום זאת, חשבונות מקומיים מייצגים משתמשים, או שהמשתמשים משתמשים בכניסה מאוחדת עם ספק זהויות. הזיהוי הזה, מלבד כתובת האימייל, נקרא מזהה חיצוני.
מקורות הזהויות שנוצרים באמצעות מסוף Admin מגשרים על הפער בין מערכות הזהויות באמצעות:
- הגדרת שדה משתמש מותאם אישית לאחסון מזהים חיצוניים. השדה הזה מתרגם מזהויות חיצוניות לחשבון Google.
- הגדרה של מרחב שמות לקבוצות אבטחה שמנוהלות על ידי מאגר או ספק זהויות.
כדאי להשתמש במקורות זהות במקרים הבאים:
- מאגר המידע לא מכיר את כתובת האימייל הראשית של המשתמש בספרייה של Google Workspace או Google Cloud.
- המאגר מגדיר קבוצות של בקרת גישה שלא תואמות לקבוצות מבוססות-אימייל ב-Google Workspace.
מקורות הזהויות משפרים את היעילות על ידי הפרדה בין יצירת האינדקס לבין מיפוי הזהויות. כך אפשר לדחות את החיפוש של המשתמשים כשיוצרים רשימות ACL ומבצעים אינדוקס לפריטים.
פריסה לדוגמה
איור 1 מציג ארגון שמשתמש במאגרי מידע מקומיים ובמאגרי מידע בענן. כל אחד מהם משתמש בסוג אחר של מזהה חיצוני.
מאגר 1 מזהה משתמשים לפי כתובת אימייל באמצעות SAML. מכיוון שהיא יודעת את כתובת האימייל הראשית ב-Google Workspace או בספריית Cloud, היא לא צריכה מקור זהויות.
מאגר 2 משתלב עם ספרייה מקומית ומזהה משתמשים לפי sAMAccountName. מכיוון שהמאפיין הזה משמש כמזהה חיצוני, צריך להגדיר מקור זהויות.
יצירת מקור זהויות
אם אתם צריכים מקור זהויות, כדאי לעיין במאמר בנושא מיפוי זהויות משתמשים ב-Cloud Search.
צריך ליצור את מקור הזהויות לפני שיוצרים מחבר תוכן. צריך את המזהה שלו כדי ליצור רשימות ACL ולבצע אינדוקס של נתונים. יצירה של מקור זהויות יוצרת גם מאפיין משתמש מותאם אישית בספריית Cloud כדי לאחסן מזהים חיצוניים. שם המאפיין הוא IDENTITY_SOURCE_ID_identity.
בטבלה הזו מוצגים שני מקורות זהויות: אחד לשמות חשבונות SAM ואחד למזהי משתמשים (uid).
| מקור זהויות | מאפיין משתמש | מזהה חיצוני |
|---|---|---|
id1 |
id1_identity |
sAMAccountName |
id2 |
id2_identity |
uid |
יוצרים מקור זהויות לכל סוג של מזהה חיצוני שמשמש בארגון.
בטבלה הזו אפשר לראות איך משתמש עם חשבון Google ושני מזהים חיצוניים מופיע ב-Cloud Directory:
| משתמש | אימייל | id1_identity |
id2_identity |
|---|---|---|---|
| רות | ann@example.com |
example\ann |
1001 |
כשיוצרים ACL לאינדוקס, אפשר להפנות לאותו משתמש באמצעות כל אחד מהמזהים האלה.
כתיבה של רשימות ACL של משתמשים
משתמשים ב-getUserPrincipal() או ב-getGroupPrincipal() כדי ליצור ישויות ראשיות באמצעות מזהים חיצוניים.
בדוגמה הזו מאחזרים את ההרשאות לקובץ, כולל משתמשים עם גישה:
קטע הקוד הזה יוצר ישויות ראשיות לבעלים באמצעות המאפיין externalUserName:
קטע הקוד הזה יוצר ישויות ראשיות לקוראים:
אחרי שמוסיפים קוראים ובעלים, יוצרים את רשימת ה-ACL:
ב-API ל-REST משתמשים בתבנית identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID.
הכתובת id1_identity של אן מפוענחת ל-identitysources/id1_identity/users/example/ann. זהו המזהה הזמני של המשתמש.
מידע נוסף על יצירת מודלים של רשימות ACL במאגרים זמין במאמר בנושא רשימות ACL.
מיפוי קבוצות
מקורות הזהויות משמשים גם כמרחב שמות לקבוצות ACL. אפשר להשתמש באפשרות הזו כדי ליצור קבוצות ולמפות אותן לשימוש באבטחה בלבד או לשימוש מקומי במאגר.
משתמשים ב-Cloud Identity Groups API כדי ליצור קבוצות ולנהל את החברות בהן. משייכים את הקבוצה למקור זהויות באמצעות השם של מקור הזהויות כמרחב השמות.
קטע הקוד הבא יוצר קבוצה:
יצירת ACL של קבוצה
משתמשים ב-getGroupPrincipal() כדי ליצור ישות קבוצתית עם מזהה חיצוני, ואז יוצרים את ה-ACL:
מחברי זהויות
משתמשים לא יכולים לראות פריטים בתוצאות החיפוש עד שהמזהים החיצוניים שלהם מתורגמים למזהה Google בספריית Cloud. יש שלוש דרכים לוודא זאת:
- עדכון ידני של פרופילי משתמשים במסוף Admin (מומלץ רק לבדיקות).
- מיפוי מזהים באמצעות Directory API.
- יוצרים מחבר זהויות באמצעות Identity Connector SDK.
מחברי זהויות ממפים מזהים חיצוניים מזהויות ארגוניות לזהויות פנימיות ב-Google. אם יוצרים מקור זהויות, צריך ליצור גם מחבר זהויות.
Google Cloud Directory Sync (GCDS) היא דוגמה למחבר זהויות. הכלי ממפה את פרטי המשתמשים והקבוצות מ-Active Directory למאגר Google Cloud.
סנכרון זהויות באמצעות API בארכיטקטורת REST
משתמשים בשיטה update כדי לסנכרן זהויות.
מיפוי מחדש של זהויות
אחרי מיפוי מחדש של זהות, צריך ליצור מחדש את האינדקס של הפריטים כדי שהשינוי ייכנס לתוקף.
- אם מסירים או משנים מיפוי משתמשים, המיפוי המקורי נשאר עד לאינדוקס מחדש.
- אם מוחקים קבוצה ממופה ויוצרים קבוצה חדשה עם אותו
groupKey, לא תהיה גישה עד שתבצעו אינדוקס מחדש.