قوائم ACL في الخريطة

لضمان أنّ المستخدمين الذين لديهم إذن الوصول إلى عنصر معيّن هم فقط من يمكنهم الاطّلاع على ذلك العنصر ضمن نتيجة بحث، عليك فهرسة العناصر باستخدام قوائم التحكّم في الوصول (ACL) من مستودع المؤسسة. يجب وضع نماذج لجداول التحكم في الوصول إلى مستودعك و تضمين جداول التحكم في الوصول هذه عند فهرسة العناصر في المستودع. توفّر حزمة تطوير البرامج (SDK) لـ Content Connector مجموعة غنية من طرق الوصول إلى البيانات (ACL) القوية بما يكفي لوضع نماذج لجداول الوصول إلى البيانات في معظم المستودعات.

ملاحظة: تتيح حزمة تطوير البرامج (SDK) لـ Content Connector استخدام جداول التحكم في الوصول (ACL) لنطاق واحد فقط، وليس جداول التحكم في الوصول على مستوى نطاقات متعددة. لا يمكنك منح إذن الوصول إلى أي مستخدمين ومجموعات خارج مؤسستك. ولا يكون لأي قوائم أذونات وصول جماعي تشير إلى مستخدمين أو مجموعات خارج مؤسستك أي تأثير.

إنشاء قائمة تحكم بالوصول

يتطلّب إنشاء قائمة أذونات وصول عملية من خطوتَين:

1. أنشئ ملفًا شخصيًا في Principal باستخدام طرق ثابتة في فئة ACL.
2. استخدِم فئة Acl.Builder لإنشاء قائمة التحكّم بالوصول باستخدام المستخدم الرئيسي.

يتناول الجزء المتبقّي من هذا المستند بعض المفاهيم التي تحتاج إلى معرفتها لنمذجة ملفّات ACL وإنشاءها، مثل اكتساب الأذونات والحصر.

إنشاء مبدأ باستخدام رقم تعريف خارجي

تتطلّب خدمة Google Cloud Search أن يتمّ حلّ أسماء المستخدمين والمجموعات إلى عنوان بريد إلكتروني على Google. عند فهرسة عناصر المستودع، قد لا تتوفّر لأدوات ربط المحتوى عناوين البريد الإلكتروني التالية. ومع ذلك، تسمح لك حزمة تطوير البرامج (SDK) لـ Content Connector باستخدام أي معرّف خارجي (معرّف يمنح مستخدمًا أو مجموعة إذن الوصول إلى عناصر المستودع)، بدلاً من عنوان بريد إلكتروني، لفهرسة عنصر. استخدِم الطريقة getUserPrincipal() أو الطريقة getGroupPrincpal() لإنشاء عناصر تحكم أساسية تحتوي على أرقام تعريف خارجية. هناك عدة methods static أخرى في فئة ACL تُستخدَم لإنشاء كائنات Principal.

ملاحظة: لا تظهر للمستخدمين العناصر في نتائج البحث إلى أن تتم مزامنة معرّفهم الخارجي مع حساباتهم على Google. يمكن إجراء مزامنة معرّفات مستخدمي أو مجموعات خارجية مع عنوان بريد إلكتروني على Google باستخدام أداة ربط هوية. لمزيد من المعلومات عن موصّلات الهوية، اطّلِع على مقالة إنشاء موصّل هوية.

تحذير: بعد إعادة ربط هوية عنصر بهوية أخرى، عليك إعادة فهرسة العناصر لتصبح الهوية الجديدة سارية. لمزيد من المعلومات، يُرجى الرجوع إلى مقالة إعادة ربط الهويات.

اكتساب أذونات قائمة التحكّم في الوصول

يشير اكتساب أذونات الوصول إلى الملفات إلى التفويض لعنصر معيّن وأحد المستخدِمين، استنادًا إلى نتيجة تركيبة من جداول أذونات الوصول إلى الملفات للعنصر وجداول أذونات الوصول إلى الملفات لسلسلة اكتساب الأذونات. تعتمد القواعد المستخدَمة لاتخاذ قرار التفويض على المستودع وعلى سمات العنصر.

ضبط الاكتساب

يمكن أن يتضمّن كل عنصر عناصر تحكم مسموح بها مباشرةً وعناصر تحكم مرفوضة مباشرةً، يتم تحديدها باستخدام الطريقتَين setReaders() و setDeniedReaders(). "العنصر الأساسي المسموح به مباشرةً" هو مستخدم تم تحديده في قائمة التحكّم في الوصول (ACL) التي تمنحه إمكانية الوصول المباشر إلى عنصر معيّن. إنّ المبدأ المباشر المرفوض هو مستخدم تم تحديده في قائمة أذونات وصول للمستخدمين على أنّه ليس لديه إذن بالوصول إلى عنصر معيّن.

يمكن أن يكتسب العنصر أيضًا العناصر الرئيسية المسموح بها بشكل غير مباشر و العناصر الرئيسية المرفوضة بشكل غير مباشر باستخدام الطريقة setInheritFrom(). المستخدم الرئيسي المسموح به بشكل غير مباشر هو مستخدم لديه إذن وصول غير مباشر إلى عنصر معيّن من خلال اكتساب أذونات الوصول إلى الملفات (ACL). إنّ المستخدم المحظور بشكل غير مباشر هو مستخدم تم منعه من الوصول إلى عنصر معيّن من خلال اكتساب أذونات ACL.

ملاحظة: في حال ضبط الاستيلاء باستخدام الطريقة setInheritFrom() ، عليك ضبط نوع الاستيلاء باستخدام الطريقة setInheritanceType(). للحصول على معلومات عن أنواع اكتساب السمات، يُرجى الرجوع إلى مقالة ضبط نوع اكتساب السمات.

يوضّح الشكل 1 كيفية استخدام الطريقة setInheritFrom() لتلقّي عناصر التحكم غير المباشرة المسموح بها وغير المباشرة المرفوضة.

الشكل 1. طريقة setInheritFrom():

يتم تمثيل عناصر التحكّم في الوصول هذه في الشكل 1:

• المستخدم 1 هو مبدأ مسموح به مباشرةً للعنصر "أ".
• المستخدم 2 هو مبدأ مسموح به مباشرةً للعنصر "ب".
• يكتسب العنصر "ب" قائمة "الوصول إلى البيانات" للعنصر "أ".

استنادًا إلى عناصر التحكّم في الوصول، تكون قواعد الوصول على النحو التالي:

• لا يلزم تحديد "المستخدم 1" صراحةً كمستخدم أساسي للعنصر "ب" ليكون مستخدمًا أساسيًا مسموحًا به بشكل غير مباشر للعنصر "ب"، لأنّ إذن الوصول يتم اكتسابه لأنّ "المستخدم 1" مُدرَج كمستخدم أساسي مسموح به بشكل مباشر للعنصر "أ" ويكتسب العنصر "ب"ملف التحكم في الوصول (ACL) من العنصر "أ".
• المستخدم 2 ليس مشرفًا مسموحًا به بشكل غير مباشر للعنصر "أ".

ضبط نوع اكتساب السمات

في حال ضبط الإرث باستخدام الطريقة setInheritFrom() ، يجب ضبط نوع الإرث باستخدام الطريقة setInheritanceType(). يحدِّد نوع اكتساب الأذونات كيفية دمج جدول تحكم الوصول (ACL) للعنصر الفرعي مع جدول تحكم الوصول للعنصر الرئيسي. تنفِّذ Acl.InheritanceType ثلاثة أنواع من اكتساب السمات:

• ‫BOTH_PERMIT - اضبط نوع اكتساب الأذونات على BOTH_PERMIT لمنح مستخدم إذن الوصول إلى العنصر فقط عندما تسمح له كل من قائمة أذونات الوصول إلى العنصر الفرعي وقائمة أذونات الوصول إلى العنصر المورَّث من العنصر الرئيسي بالوصول إلى هذا العنصر.

• CHILD_OVERRIDE - اضبط نوع اكتساب الملكية على CHILD_OVERRIDE لإجبار قائمة أذونات التحكم في الوصول الخاصة بالملف الفرعي على أن تكون لها الأولوية على قائمة أذونات التحكم في الوصول الخاصة بالملف الرئيسي المُكتسَبة عند حدوث تعارض بينهما. وبالتالي، إذا كانت قائمة التحكّم في الوصول إلى العنصر الرئيسي ترفض منح المستخدم إذن الوصول بصفته قارئًا مرفوضًا، سيظل بإمكان المستخدم الوصول إلى العنصر الأول إذا كان لديه إذن الوصول إلى العنصر الثاني بصفته قارئًا. في المقابل، حتى إذا كانت قائمة التحكّم بالوصول إلى العنصر الرئيسي تمنح إذن الوصول إلى المستخدم، لن يحصل المستخدم على إذن الوصول إذا كان قارئًا مرفوضًا للعنصر الفرعي.

• PARENT_OVERRIDE - اضبط نوع اكتساب الأذونات على PARENT_OVERRIDE لفرض منح إذن الوصول إلى الملفات (ACL) للعنصر الرئيسي الأولوية على إذن الوصول إلى الملفات للعنصر الفرعي عندما يكون هناك تعارض بينهما. وبالتالي، إذا كانت قائمة التحكّم في الوصول إلى العنصر الفرعي ترفض منح المستخدم إذن الوصول بصفته "قارئًا" مرفوضًا، سيظل بإمكان المستخدم الوصول إذا كان لديه إذن الوصول إلى العنصر الرئيسي بصفته "قارئًا". في المقابل، حتى إذا كانت قائمة التحكّم في الوصول إلى العنصر الفرعي تمنح المستخدم إذن الوصول، لن يحصل المستخدم على إذن الوصول إذا كان قارئًا مرفوضًا للعنصر الرئيسي.

عند تقييم سلسلة اكتساب الأذونات، يمكن أن يغيّر ترتيب التقييم نتيجة قرار التفويض. تقدِّم Cloud Search ترتيب التقييم من الورقة إلى الجذر لسلّسل اكتساب أذونات الوصول إلى الملفات. على وجه التحديد، يبدأ قرار ACL للسلسلة بتقييم العنصر الفرعي مع العناصر الرئيسية، ويمكن أن يتقدّم إلى العنصر الرئيسي.

على سبيل المثال، إذا كان الحساب الفرعي للطفل من النوع CHILD_OVERRIDE وكان لدى المستخدم إذن الوصول إلى الحساب الفرعي، لن يحتاج Drive إلى تقييم الحساب الرئيسي. ومع ذلك، إذا كان لدى الطفل الإذن PARENT_OVERRIDE أو BOTH_PERMIT، يواصل Drive تقييم الإذن بالوصول إلى أعلى السلسلة.

الاحتواء وحذف العناصر

عند فهرسة عنصر، يمكنك تصنيفه كحاوية باستخدام الطريقة setContainer() لفئة IndexingItemBuilder. تُنشئ علاقة الحاوية/المحتوَى التسلسل الهرمي للعناصر وتؤكّد حذف العناصر بشكل صحيح. عند حذف حاوية، يتم أيضًا حذف العناصر المضمّنة فيها.

إنّ علاقات الحاوية مستقلة تمامًا عن قواعد اكتساب أذونات الوصول إلى الملفات. على سبيل المثال، يمكن أن يحتوي مجلد على ملف في نظام ملفات بغرض حذفه، ولكن يرث إذن الوصول إلى الملفات من مجلد مختلف. لا يؤدي حذف مجلد إلى حذف العناصر التي تكتسِب قائمة التحكّم في الوصول الخاصة به، ما لم تكن هذه العناصر موجودة أيضًا في التسلسل الهرمي للاحتواء في المجلد.

يتم تمثيل عناصر التحكّم في الوصول هذه في الشكل 2:

• المستخدم 1 هو مبدأ مسموح به مباشرةً للعنصر "أ".
• المستخدم 2 هو مبدأ مسموح به مباشرةً للعنصر "ب".
• المستخدم 3 هو مبدأ مسموح به مباشرةً للعنصر "ج".
• يكتسب العنصر "ج" قائمة التحكّم في الوصول الخاصة بالعنصر "أ".
• يُحدِّد العنصر "ب" العنصر "أ" كونه الحاوية.
• يُحدِّد العنصر "ج" العنصر "ب" كونه الحاوية.

استنادًا إلى عناصر التحكّم في الوصول، تكون قواعد الوصول على النحو التالي:

• تأتي إمكانية الوصول غير المباشرة من طريقة setInheritFrom(). وبالتالي، يمكن للمستخدم 1 الوصول إلى العنصر "ج" لأنّ العنصر "ج" يكتسب قائمة التحكّم بالوصول الخاصة بالعنصر "أ".
• لا يأتي الوصول غير المباشر من العنصر "ج" الذي يحتوي عليه العنصر "ب". وبالتالي، لا يمكن للمستخدم 2 الوصول إلى العنصر "ج".

الشكل 2. طريقة setInheritFrom() المستخدَمة

يتيح لك فصل اكتساب أذونات الوصول إلى الملفات من التسلسل الهرمي للاحتواء وضع نماذج لكثير من الهياكل الحالية المختلفة.

عند حذف عنصر بنجاح:

• يصبح أي عنصر يتضمّن عنصرًا تم حذفه غير قابل للبحث عنه ويتم تحديد موعد لحذفه من مصدر بيانات Google.
• يصبح أي عنصر حدّد العنصر المحذوف باستخدام الطريقة setInheritFrom() غير قابل للبحث.

إذا كان المورد يتضمّن عنصرًا تم حذفه باستخدام الأسلوب setInheritFrom() ، ولكنّه لا يتضمّن حاوية تم ضبطها باستخدام setContainer()، أو إذا لم يتضمّن التسلسل الهرمي للحاويات أي عناصر تم حذفها، يبقى هذا العنصر وبياناته في مصدر بيانات Google. أنت المسؤول عن حذف العنصر.

يعرض الشكل 3 مثالاً على كيفية عمل الحذف في التسلسل الهرمي للعناصر.

الشكل 3. حذف عنصر وميزة اكتساب أذونات الوصول إلى الملفات

يتم تمثيل عناصر التحكّم في الوصول هذه في الشكل 3:

• المستخدم 1 هو مبدأ مسموح به مباشرةً للعنصر "أ".
• المستخدم 2 هو مبدأ مسموح به مباشرةً للعنصر "د".
• يرث كلّ من العنصر "د" والعنصر "هـ" قائمة التحكّم في الوصول الخاصة بالعنصر "أ".
• يُحدِّد العنصر "د" العنصر "أ" كساقه.
• العنصران "أ" و"هـ" هما عنصران على مستوى الجذر لأنّهما لا يتضمّنان عنصرًا حاويًا.

يتم حذف العناصر المتسلسلة من خلال مراجع الحاوية. عند حذف العنصر "أ":

• سيفقد جميع المستخدمين إمكانية الوصول إلى جميع العناصر الفرعية للإشارة setInheritFrom().
• لا يمكن لأي مستخدم الوصول إلى العنصر "أ".
• يتم حذف العنصر "د" بشكل ضمني. لا يمكن لأي مستخدم الوصول إلى العنصر "د".
• لا يتم حذف العنصر "هـ"، لأنّ الحذف لا يتم إلا من خلال مراجع الحاويات.
• يصبح العنصر "هـ" غير قابل للوصول إليه ولا يمكن لأي مستخدم البحث عنه.