בקרת הגישה ב-Google Cloud Search מבוססת על חשבון Google של המשתמש. כשמוסיפים תוכן לאינדקס, כל רשימות ה-ACL של הפריטים חייבות לעבור למזהים חוקיים של משתמשים או קבוצות ב-Google (כתובות אימייל).
במקרים רבים למאגר אין ידע ישיר על חשבונות Google. במקום זאת, יכול להיות שהמשתמשים מיוצגים על ידי חשבונות מקומיים או להשתמש בכניסה מאוחדת עם מזהה וספק זהויות, מלבד כתובת האימייל של המשתמשים, כדי לזהות כל חשבון. המזהה הזה נקרא המזהה החיצוני.
מקורות של זהויות, שנוצרים באמצעות מסוף Admin, עוזרים לגשר על הפער הזה בין מערכות הזהויות על ידי:
- הגדרת שדה משתמש מותאם אישית לאחסון מזהים חיצוניים. השדה הזה משמש לזיהוי מזהים חיצוניים של חשבון Google.
- מגדירים מרחב שמות לקבוצות אבטחה שמנוהלות על ידי מאגר או ספק זהויות.
יש להשתמש במקורות זהות כאשר:
- למאגר אין מידע על כתובת האימייל הראשית של המשתמש ב-Google Workspace או ב-Google Cloud Directory.
- במאגר מוגדרות קבוצות לבקרת גישה שלא תואמות לקבוצות מבוססות אימייל ב-Google Workspace.
מקורות זהויות משפרים את יעילות ההוספה לאינדקס על ידי הפרדת ההוספה לאינדקס ממיפוי הזהויות. ההצמדה הזו מאפשרת לעכב את חיפוש המשתמש כשיוצרים רשימות ACL והוספה לאינדקס.
פריסה לדוגמה
באיור 1 מוצגת פריסה לדוגמה שבה ארגונים משתמשים גם במאגרים בארגון וגם במאגרים בענן. כל מאגר משתמש בסוג אחר של מזהה חיצוני כדי להפנות למשתמשים.
Repository 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:
user | אימייל | 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), המזהה צריך לפתור את הבעיה:
identitysources/id1_identity/users/example/ann
המזהה כולו נקרא המזהה הביניים של המשתמש, כי הוא מספק מגשר בין המזהה החיצוני למזהי Google שמאוחסנים בספריית Cloud.
למידע נוסף על בניית מודלים של רשימות 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. התהליך הזה מומלץ למי שלא יכול להשתמש ב-SDK של מחבר הזהויות.
- יוצרים מחבר זהויות באמצעות ה-SDK של מחבר הזהויות. ערכת ה-SDK הזו מפשטת את השימוש ב-Directory API למיפוי מזהים.
מחברי זהויות הם תוכנות שמשמשות למיפוי של מזהים חיצוניים מזהויות ארגוניות (משתמשים וקבוצות) לזהויות פנימיות של Google שמשמשות את Google Cloud Search. אם אתם חייבים ליצור מקור זהות, עליכם ליצור מחבר זהויות.
Google Cloud Directory Sync (GCDS) הוא דוגמה למחבר זהויות. מחבר הזהויות הזה ממפה את המידע של המשתמשים והקבוצות מ-Active Directory של Microsoft ל-Cloud Directory, יחד עם מאפייני המשתמשים שיכולים לייצג את הזהות שלהם במערכות אחרות.
סנכרון זהויות באמצעות API ל-REST
משתמשים בשיטה update
כדי לסנכרן זהויות באמצעות API ל-REST.
מיפוי מחדש של זהויות
אחרי מיפוי מחדש של זהות פריט לזהות אחרת, צריך להוסיף פריטים לאינדקס מחדש כדי שהזהות החדשה תיכנס לתוקף. לדוגמה,
- אם תנסו להסיר מיפוי ממשתמש או למפות אותו מחדש למשתמש אחר, המיפוי המקורי עדיין יישמר עד שתיצרו את האינדקס מחדש.
- אם מוחקים קבוצה ממופה שנמצאת ברשימת ACL של פריט, ואז יוצרים קבוצה חדשה עם אותו
groupKey
, לקבוצה החדשה לא תהיה גישה לפריט עד שהפריט יתווסף לאינדקס מחדש.