בקרת הגישה ב-Google Cloud Search מבוססת על חשבון Google של המשתמש. כשמוסיפים תוכן לאינדקס, כל רשימות ה-ACL של הפריטים חייבות להתאים למשתמש Google חוקי או מזהי קבוצות (כתובות אימייל).
במקרים רבים למאגר אין ידע ישיר על Google חשבונות. במקום זאת, יכול להיות שהמשתמשים מיוצגים על ידי חשבונות מקומיים או כניסה מאוחדת עם מזהה וספק זהויות, מאשר כתובת האימייל של המשתמש, כדי לזהות כל חשבון. המזהה הזה נקרא מזהה חיצוני.
מקורות של זהויות שנוצרו באמצעות מסוף Admin עוזרים לגשר על הפער הזה על ידי:
- הגדרת שדה משתמש מותאם אישית כדי לאחסן מזהים חיצוניים. השדה הזה משמש לזיהוי מזהים חיצוניים ל-Google חשבון.
- הגדרת מרחב שמות לקבוצות אבטחה מנוהלות על ידי מאגר ספק זהויות.
יש להשתמש במקורות זהות כאשר:
- המאגר לא יודע מה כתובת האימייל הראשית של המשתמש ב-Google Workspace או ב-Google Cloud Directory.
- במאגר מוגדרות קבוצות של בקרת גישה שלא תואמות לקבוצות מבוססות-אימייל ב-Google Workspace.
מקורות זהויות משפרים את יעילות ההוספה לאינדקס על ידי הפרדתם מאינדקס ממיפוי זהויות. הניתוק הזה מאפשר לדחות חיפוש של נתוני המשתמש במהלך יצירת רשימות ACL והוספה לאינדקס של פריטים.
פריסה לדוגמה
איור 1 מציג פריסה לדוגמה שבה גם בארגון וגם בענן מאגרים משמשים ארגון. כל מאגר משתמש בסוג אחר של מזהה חיצוני כדי להפנות למשתמשים.
מאגר 1 מזהה את המשתמש באמצעות כתובת האימייל שצוינה באמצעות SAML. כי למאגר הראשון יש מידע על כתובת האימייל הראשית של המשתמש ב- לא צריך מקור זהות, ב-Google Workspace או ב-Cloud Directory.
Repository 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 של משתמשים
משתמשים ב getUserPrincpal() או getGroupPrincipal() כדי ליצור חשבונות משתמשים באמצעות מזהה חיצוני נתון.
תוכלו להיעזר בדוגמה הבאה כדי לאחזר הרשאות לקובץ. האלה ההרשאות כוללות את השם של כל משתמש שיש לו גישה לקובץ.
קטע הקוד הבא מראה איך ליצור חשבונות משתמשים שהם בעלים
באמצעות המזהה החיצוני (externalUserName
) ששמור במאפיינים.
לבסוף, קטע הקוד הבא מראה איך ליצור חשבונות משתמשים קוראים של הקובץ.
אחרי שיוצרים רשימת קוראים ובעלים, אפשר ליצור את ה-ACL:
ב-API ל-REST נעשה שימוש בדפוס הזה
identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID
את המזהה כשיוצרים חשבונות משתמשים. נחזור לטבלאות הקודמות.
אם תיצרו רשימת ACL עם id1_identity
של אן (SAMAccountName), המזהה
צריך להפוך ל:
identitysources/id1_identity/users/example/ann
המזהה המלא הזה נקרא מזהה הביניים של המשתמש כי הוא מספק גשר בין המזהה החיצוני למזהי Google שמאוחסנים ב-Cloud Directory.
למידע נוסף על בניית מודלים של רשימות ACL שמשמשות למאגר, ראו: רשימות ACL.
מיפוי קבוצות
מקורות של זהויות משמשים גם כמרחב שמות לקבוצות שנמצאות בשימוש ברשימות ACL. אפשר להשתמש במרחב השמות הזה כדי ליצור קבוצות שמשמשות לאבטחה ולמפות אותן למטרות בלבד או באופן מקומי למאגר.
שימוש ב-Cloud Identity Groups API כדי ליצור קבוצה ולנהל את החברים בה. כדי לשייך את הקבוצה אל מקור זהויות, צריך להשתמש בשם המשאב של מקור הזהויות בתור מרחב השמות של הקבוצה.
קטע הקוד הבא מראה איך ליצור קבוצה באמצעות Cloud Identity Groups API:
יצירת רשימת ACL קבוצתית
כדי ליצור רשימת ACL קבוצתית, משתמשים ב getGroupPrincipal() כדי ליצור חשבון משתמש קבוצתי באמצעות מזהה חיצוני נתון. לאחר מכן, יוצרים ACL באמצעות Acl.Builder הכיתה באופן הבא:
מחברי זהויות
אפשר להשתמש במזהים חיצוניים שאינם של Google כדי ליצור רשימות ACL ופריטים לאינדקס, משתמשים לא יוכלו לראות פריטים בחיפוש עד שהמזהים החיצוניים שלהם יפנו ל-Google מזהה ב-Cloud Directory. יש שלוש דרכים להבטיח ספריית Cloud יודעת גם את המזהה ב-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
, לקבוצה החדשה אין גישה עד שהפריט יתווסף מחדש לאינדקס.