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