רשימות ACL של מפות

כדי לוודא שרק משתמשים שיש להם גישה לפריט יכולים לראות אותו בתוצאת חיפוש, צריך להוסיף לאינדקס את הפריטים עם רשימות בקרת הגישה (ACL) שלהם מהמאגר הארגוני. צריך ליצור מודל של רשימות ה-ACL של המאגר ולכלול את רשימות ה-ACL האלה כשמוסיפים פריטים לאינדקס במאגר. ערכת ה-SDK של Content Connector מספקת קבוצה עשירה של שיטות ACL חזקות מספיק כדי ליצור מודלים של רשימות ה-ACL של רוב המאגרים.

הערה: ‏Content Connector SDK תומך ברשימות ACL של דומיין יחיד, אבל לא ברשימות ACL של כמה דומיינים. אי אפשר להעניק גישה למשתמשים ולקבוצות מחוץ לארגון. אין השפעה על כל רשימות ACL שמתייחסות למשתמשים או לקבוצות מחוץ לארגון.

יצירת רשימת ACL

יצירת ACL היא תהליך דו-שלבי:

1. יוצרים Principal באמצעות שיטות סטטיות בכיתה ACL.
2. משתמשים בכיתה Acl.Builder כדי ליצור את רשימת ה-ACL באמצעות חשבון המשתמש.

בהמשך המסמך נסביר על כמה מושגים שצריך להכיר כדי ליצור ולתכנן רשימות ACL, כמו ירושה וכליא.

יצירת חשבון משתמש באמצעות מזהה חיצוני

כדי להשתמש ב-Google Cloud Search, המשתמשים והקבוצות צריכים לפתור לכתובת אימייל של Google. כשמזינים ב-Index פריטים במאגר, יכול להיות שמחברי התוכן לא יכללו את כתובות האימייל האלה. עם זאת, ה-SDK של Content Connector מאפשר להשתמש בכל מזהה חיצוני (מזהה שמעניק למשתמש או לקבוצה גישה לפריטי המאגר) במקום כתובת אימייל, כדי להוסיף פריט לאינדקס. משתמשים ב-method‏ getUserPrincipal() או ב-method‏ getGroupPrincpal() כדי ליצור חשבונות משתמשים שמכילים מזהים חיצוניים. יש עוד כמה שיטות סטטיות בכיתה ACL שמשמשות ליצירת אובייקטים מסוג Principal.

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

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

ירושה של ACL

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

הגדרת ירושה

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

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

הערה: אם מגדירים את הירושה באמצעות השיטה setInheritFrom(), צריך להגדיר את סוג הירושה באמצעות השיטה setInheritanceType(). מידע על סוגי הירושה זמין במאמר הגדרת סוג הירושה.

באיור 1 מוצג איך משתמשים ב-method‏ setInheritFrom() כדי לרשת חשבונות משתמשים שמוגדרים מורשים או נדחים באופן עקיף.

איור 1. השיטה setInheritFrom().

אמצעי הבקרה על הגישה מיוצגים באיור 1:

• משתמש 1 הוא חשבון משתמש מורשה ישירות של פריט א'.
• משתמש 2 הוא חשבון משתמש מורשה ישיר של פריט ב'.
• פריט ב' יורש את רשימת ה-ACL של פריט א'.

על סמך אמצעי בקרת הגישה, כללי הגישה הם:

• אין צורך לציין את משתמש 1 באופן מפורש כחשבון משתמש של פריט ב' כדי שהוא יהיה חשבון משתמש מורשה עקיף של פריט ב'. הגישה עוברת בירושה כי משתמש 1 מופיע כחשבון משתמש מורשה ישיר של פריט א', ופריט ב' יורש את רשימת ה-ACL שלו מפריט א'.
• משתמש 2 הוא לא חשבון משתמש מורשה עקיף לפריט א'.

הגדרת סוג הירושה

אם מגדירים את הירושה באמצעות השיטה setInheritFrom(), צריך להגדיר את סוג הירושה באמצעות השיטה setInheritanceType(). סוג הירושה קובע איך ה-ACL של הצאצא משתלב עם ה-ACL של ההורה. הפונקציה Acl.InheritanceType מטמיעה שלושה סוגים של ירושה:

• BOTH_PERMIT – מגדירים את סוג הירושה כ-BOTH_PERMIT כדי להעניק למשתמש גישה לפריט רק אם גם רשימת ה-ACL של הפריט הצאצא וגם רשימת ה-ACL של הפריט שהתקבל בירושה מההורה מאפשרות למשתמש לגשת לפריט הזה.

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

• PARENT_OVERRIDE – מגדירים את סוג הירושה ל-PARENT_OVERRIDE כדי לאלץ את רשימת ה-ACL של הפריט ההורה לקבל עדיפות על פני רשימת ה-ACL של הפריט הצאצא כש יש ביניהם סתירה. לכן, אם רשימת ה-ACL של פריט הצאצא דוחה את הגישה של המשתמש בתור 'קריאה נדחתה', למשתמש עדיין תהיה גישה אם יש לו גישה לפריט ההורה בתור 'קריאה'. לעומת זאת, גם אם הרשאת הגישה של הפריט הצאצא מקצה גישה למשתמש, למשתמש לא תהיה גישה אם הרשאת הקריאה שלו בפריט ההורה נדחתה.

כשבודקים שרשרת ירושה של ACL, סדר הבדיקה יכול לשנות את התוצאה של החלטת ההרשאה. Cloud Search מספק סדר הערכה של עלים לשורש ברשתות של ירושה של ACL. באופן ספציפי, ההחלטה של ACL בשרשור מתחילה בהערכה של הצאצא עם ההורים שלו, וניתן להמשיך עד להורה ברמה הבסיסית (root).

לדוגמה, אם לסוג הירושה של הצאצא מוגדר CHILD_OVERRIDE והמשתמש יש לו גישה לצאצא, מערכת Drive לא צריכה להעריך את ההורה. עם זאת, אם לנכס הצאצא יש את הערך PARENT_OVERRIDE או BOTH_PERMIT, מערכת Drive ממשיכה להעריך את הירושה בהמשך שרשרת הנכסים.

מחיקת פריטים ובלימה

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

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

אמצעי בקרת הגישה האלה מיוצגים באיור 2:

• משתמש 1 הוא חשבון משתמש מורשה ישירות של פריט א'.
• משתמש 2 הוא חשבון משתמש מורשה ישיר של פריט ב'.
• משתמש 3 הוא חשבון משתמש מורשה ישיר של פריט C.
• פריט C יורש את רשימת ה-ACL של פריט A.
• פריט ב' מציין את פריט א' כקונטיינר שלו.
• פריט ג' מציין את פריט ב' כקונטיינר שלו.

על סמך אמצעי בקרת הגישה, כללי הגישה הם:

• הגישה העקיפה מגיעה מהשיטה setInheritFrom(). לכן, משתמש 1 יכול לגשת לפריט ג' כי פריט ג' יורש את רשימת ה-ACL של פריט א'.
• גישה עקיפה לא מגיעה מפריט ג' שמכיל את פריט ב'. לכן, משתמש 2 לא יכול לגשת לפריט ג'.

איור 2. השיטה setInheritFrom() שבשימוש.

ההפרדה בין ירושת ACL לבין היררכיית האחסון מאפשרת ליצור מודלים של מבנים קיימים רבים ושונים.

כשפריט נמחק בהצלחה:

• לא ניתן יהיה לחפש פריטים שהכילו פריט שנמחק, והם יימחקו ממקור הנתונים של Google.
• לא ניתן יהיה לחפש פריטים שצוין בהם הפריט שנמחק באמצעות השיטה setInheritFrom().

אם במשאב יש פריט שנמחק באמצעות השיטה setInheritFrom(), אבל לא הוגדר לו מאגר באמצעות setContainer(), או שההיררכיה של המאגר לא מכילה פריטים שנמחקו, הפריט והנתונים שלו יישארו במקור הנתונים של Google. אתם אחראים למחוק את הפריט.

באיור 3 מוצגת דוגמה לאופן שבו מתבצעת מחיקה בהיררכיית פריטים.

איור 3. מחיקה של פריט וירושה של ACL.

אמצעי בקרת הגישה האלה מיוצגים באיור 3:

• משתמש 1 הוא חשבון משתמש מורשה ישירות של פריט א'.
• משתמש 2 הוא חשבון משתמש מורשה ישיר של פריט D.
• פריט D ופריט E יורשים את רשימת ה-ACL של פריט A.
• פריט D מציין את פריט א' כקונטיינר שלו.
• הפריטים A ו-E הם פריטים ברמת הבסיס כי אין להם פריט מאגר.

מחיקה מדורגת דרך ההפניות לקונטיינרים. כשפריט א' נמחק:

• כל הצאצאים של ההפניה setInheritFrom() יאבדו את הגישה של כל המשתמשים.
• אף משתמש לא יכול לגשת לפריט א'.
• הפריט D נמחק באופן משתמע. אף משתמש לא יכול לגשת לפריט D.
• הפריט E לא נמחק, כי המחיקה מתבצעת רק דרך הפניות לקונטיינרים.
• לא ניתן לגשת לפריט E ואף משתמש לא יכול לחפש אותו.