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

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

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

יצירת ACL

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

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

בהמשך המסמך מוסברים כמה מושגים שחשוב להכיר כדי ליצור מודלים של רשימות בקרת גישה (ACL) וליצור אותן, כמו ירושה והכלה.

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

כדי להשתמש ב-Google Cloud Search, המשתמשים והקבוצות צריכים להיות משויכים לכתובת אימייל ב-Google. יכול להיות שלמחברי תוכן אין את כתובות האימייל האלה כשהם יוצרים אינדקס לפריטים במאגר. עם זאת, ערכת ה-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 מראה איך משתמשים בשיטה setInheritFrom() כדי להעביר בירושה חשבונות משתמשים שאושרו באופן עקיף וחשבונות משתמשים שנדחו באופן עקיף.

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

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

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

בהתאם לבקרת הגישה, כללי הגישה הם:

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

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

אם מגדירים את ההורשה באמצעות השיטה setInheritFrom(), צריך להגדיר את סוג ההורשה באמצעות השיטה setInheritanceType(). סוג ההורשה קובע איך רשימת בקרת הגישה של צאצא משולבת עם רשימת בקרת הגישה של ההורה. התג 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) עבור שרשרת מתחילה בהערכה של צאצא עם ההורים שלו, ויכולה להתקדם עד להורה הבסיסי.

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

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

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

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

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

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

בהתאם לבקרת הגישה, כללי הגישה הם:

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

איור 2. שיטת setInheritFrom() שנמצאת בשימוש.

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

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

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

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

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

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

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

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

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

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