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

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

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

יצירת ACL

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

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

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

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

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

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

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

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

מחיקת מקום מארח ופריט

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

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

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

• משתמש 1 הוא חשבון משתמש ישיר שמותר על ידי פריט א'.
• משתמש 2 הוא חשבון משתמש ישיר מורשה של פריט ב'.
• משתמש 3 הוא חשבון משתמש ישיר מורשה של פריט ג'.
• פריט ג' יורש את רשימת ה-ACL של פריט א'.
• פריט ב' נותן לפריט א' את השם של פריט א' כמאגר שלו.
• פריט ג' נותן לפריט ב' את השם של פריט ב' כמאגר שלו.

כללי הגישה מבוססים על בקרות הגישה:

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

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

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

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

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

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

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

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

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

• משתמש 1 הוא חשבון משתמש ישיר שמותר על ידי פריט א'.
• משתמש 2 הוא חשבון משתמש ישיר מורשה של פריט ד'.
• פריט ד' ופריט E יורשים את רשימת ה-ACL של פריט א'.
• פריט ד' נותנים שם לפריט א' כמאגר שלו.
• פריטים א' ו-E הם פריטים ברמה הבסיסית (root) כי אין להם פריט במאגר.

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

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