قوائم التحكم بالوصول في Azure Data Lake Storage Gen2

مقالة
04/24/2024

ينفذ Azure Data Lake Storage Gen2 نموذجًا للتحكم في الوصول يدعم كلاً من Azure للتحكم في الوصول القائم على دور (Azure RBAC) وقوائم التحكم في الوصول الشبيهة بـ POSIX (ACLs). توضح هذه المقالة قوائم التحكم في الوصول في Data Lake Storage Gen2. للتعرف على كيفية دمج Azure RBAC مع ACLs، وكيفية تقييم النظام لها لاتخاذ قرارات التخويل، راجع نموذج التحكم في الوصول في Azure Data Lake Storage Gen2.

حول قوائم التحكم في الوصولACL

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

إشعار

تنطبق قوائم ACL فقط على كيانات الأمن في نفس المستأجر، ولا تنطبق على المستخدمين الذين يستخدمون المفتاح المشترك أو توقيع الوصول المشترك (SAS) للمصادقة الرمزية. وذلك لأنه لا توجد هوية مرتبطة بالمتصل، ومن ثمّ لا يمكن تنفيذ التصريح القائم على إذن كيان الأمن.

كيفية تعيين قوائم التحكم في الوصول

لتعيين أذونات مستوى الملف والدليل، راجع أيًا من المقالات التالية:

البيئة	مقال
Azure Storage Explorer	استخدام مستكشف تخزين Azure لإدارة قوائم التحكم بالوصول في Azure Data Lake Storage Gen2
مدخل Azure	استخدم مدخل Microsoft Azure لإدارة قوائم التحكم في الوصول في Azure Data Lake Storage Gen2
.NET	استخدام .NET لإدارة قوائم التحكم بالوصول في Azure Data Lake Storage Gen2
Java	استخدام Java لإدارة قوائم التحكم بالوصول في Azure Data Lake Storage Gen2
Python	استخدام Python لإدارة قوائم التحكم بالوصول في Azure Data Lake Storage Gen2
JavaScript (Node.js)	استخدم JavaScript SDK في Node.js لإدارة قوائم التحكم بالوصول في Azure Data Lake Storage Gen2
PowerShell	استخدام PowerShell لإدارة قوائم التحكم بالوصول في Azure Data Lake Storage Gen2
Azure CLI	استخدم Azure CLI لإدارة قوائم التحكم في الوصول في Azure Data Lake Storage Gen2
واجهة برمجة تطبيقات REST	المسار - تحديث

هام

إذا كان أساس الأمان هو كيان الخدمة ، فمن المهم استخدام معرف الكائن الخاص بكيان الخدمة وليس معرف الكائن لتسجيل التطبيق ذي الصلة. للحصول على معرف الكائن الخاص بكيان الخدمة، افتح Azure CLI، ثم استخدم هذا الأمر: az ad sp show --id <Your App ID> --query objectId. تأكد من استبدال <Your App ID> العنصر النائب بمعرف التطبيق لتسجيل التطبيق. يتم التعامل مع كيان الخدمة كمستخدم مسمى. ستضيف هذا المعرف إلى قائمة التحكم بالوصول كما تفعل مع أي مستخدم مسمى. يتم وصف المستخدمين المسماة لاحقا في هذه المقالة.

أنواع قوائم التحكم في الوصول

هناك نوعان من قوائم التحكم في الوصول: قوائم التحكم بالوصول وقوائم التحكم بالوصول الافتراضية.

تتحكم قوائم التحكم للوصول ACL في الوصول إلى عنصر. يتضمن كل من الملفات والدلائل قوائم ACL للوصول.

إن قوالب ACLs الافتراضية هي قوالب من قوالب ACLs مقترنة بدليل تحدد عناوين ACLs للوصول لأي عناصر من العناصر الخاصة التي تم إنشاؤها ضمن هذا الدليل. لا تحتوي الملفات على قوائم تحكم بالوصول افتراضية.

كل من قوائم ACL للوصول وقوائم ACL الافتراضية لهما البنية نفسها.

إشعار

لا يؤثر تغيير قائمة التحكم بالوصول الافتراضية على أحد الوالدين على الوصول إلى ACL أو ACL الافتراضي للعناصر الفرعية الموجودة بالفعل.

مستويات الإذن

الأذونات على الدلائل والملفات في حاوية، هي قراءة وكتابة وتنفيذ، ويمكن استخدامها على الملفات والدلائل كما هو موضح في الجدول التالي:

	الملف	الدليل
قراءة (R)	يمكن قراءة محتويات الملف	يتطلب القراءة والتنفيذ لسرد محتويات الدليل
الكتابة (W)	يمكن كتابة ملف أو الإلحاق به	يتطلب الكتابة والتنفيذ لإنشاء عناصر تابعة في دليل
تنفيذ (X)	لا يعني أي شيء في سياق Azure Data Lake Storage Gen2	يلزم لاجتياز العناصر التابعة للدليل

إشعار

إذا كنت تمنح أذونات باستخدام قوائم التحكم في الوصول فقط (بدون Azure RBAC)، ثم لمنح حق الوصول للقراءة أو الكتابة إلى ملف أساسي للأمان، فستحتاج إلى منح أذونات تنفيذ أساس الأمان إلى المجلد الجذر للحاوية، وإلى كل مجلد في التسلسل الهرمي للمجلدات التي تؤدي إلى الملف.

نماذج مختصرة للأذونات

يتم استخدام RWX للإشارة إلى Read + Write + Execute. يوجد نموذج رقمي أكثر تكثيفا حيث Read=4 و Write =2 و Execute=1، يمثل مجموعها الأذونات. وفيما يلي بعض الأمثلة.

شكل رقمي	الصيغة المختصرة	تعريفه
7	`RWX`	قراءة + كتابة + تنفيذ
5	`R-X`	قراءة + تنفيذ
4	`R--`	قراءة
0	`---`	بدون أذونات

توريث الأذونات

في طراز POSIX المستخدم من قبل Data Lake Storage Gen2، تُخزن أذونات العنصر على العنصر نفسه. وبمعنى آخر، لا يمكن توريث أذونات عنصر من العناصر الأصلية إذا تم تعيين الأذونات بعد إنشاء العنصر الفرعي بالفعل. تُورث الأذونات فقط إذا تم تعيين الأذونات الافتراضية على العناصر الأصلية قبل إنشاء العناصر الفرعية.

يعرض الجدول التالي إدخالات ACL المطلوبة لتمكين أساس الأمان من تنفيذ العمليات المدرجة في عمود العملية .

يُبين هذا الجدول عمودًا يمثل كل مستوى من مستويات التسلسل الهرمي للدليل الوهمي. هناك عمود للدليل الجذري للحاوية (/)، ودليل فرعي يسمى Oregon، ودليل فرعي لدليل Oregon يسمى Portland، وملف نصي في دليل Portland يسمى Data.txt.

هام

يفترض هذا الجدول أنك تستخدم قوائم التحكم بالوصول فقط دون أي تعيينات أدوار Azure. لمشاهدة جدول مشابه يجمع بين Azure RBAC مع ACLs، راجع جدول الأذونات: الجمع بين Azure RBAC وABAC وACLs.

العملية	/	Oregon/	Portland/	Data.txt
اقرأ Data.txt	`--X`	`--X`	`--X`	`R--`
إلحاق Data.txt	`--X`	`--X`	`--X`	`RW-`
حذف Data.txt	`--X`	`--X`	`-WX`	`---`
حذف /أوريغون/	`-WX`	`RWX`	`RWX`	`RWX`
حذف /أوريغون/بورتلاند/	`--X`	`-WX`	`RWX`	`RWX`
إنشاء Data.txt	`--X`	`--X`	`-WX`	`---`
قائمة /	`R-X`	`---`	`---`	`---`
قائمة /Oregon/	`--X`	`R-X`	`---`	`---`
قائمة /Oregon/Portland/	`--X`	`--X`	`R-X`	`---`

حذف الملفات والدلائل

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

إشعار

لا يمكن حذف الدليل الجذر "/".

ما هي الأذونات المطلوبة لحذف الدليل ومحتوياته بشكل متكرر؟

لدى المتصل أذونات "مستخدم مميز "،

أو

يجب أن يحتوي الدليل الرئيسي على أذونات الكتابة + التنفيذ.
يتطلب الدليل المراد حذفه، وكل دليل داخله، أذونات القراءة + الكتابة + التنفيذ.

إشعار

لا تحتاج إلى أذونات الكتابة لحذف الملفات في الدلائل. أيضًا، لا يمكن أبدًا حذف الدليل الجذري "/".

المستخدمون والهويات

يحتوي كل ملف ودليل على أذونات مميزة لهذه الهويات:

المستخدم المالك
المجموعة المالكة
المستخدمون المحدّدون
المجموعات المحدّدة
كيانات الخدمة المحدّدة
الهويات المُدارة المحدّدة
جميع المستخدمين الآخرين

هويات المستخدمين والمجموعات هي هويات Microsoft Entra. لذلك، ما لم تتم الإشارة إلى خلاف ذلك، يمكن للمستخدم، في سياق Data Lake Storage Gen2، الرجوع إلى مستخدم Microsoft Entra أو كيان الخدمة أو الهوية المدارة أو مجموعة الأمان.

المستخدم الفائق

يتمتع المستخدم الفائق بأكبر قدر من الحقوق لجميع المستخدمين. مستخدم فائق:

لديه أذونات RWX لكافة الملفات والمجلدات.
يمكنه تغيير الأذونات على أي ملف أو مجلد.
يمكنه تغيير المستخدم المالك أو مجموعة المالك لأي ملف أو مجلد.

إذا تم إنشاء حاوية أو ملف أو دليل باستخدام Shared Key أو Account SAS أو Service SAS، فسيتم تعيين المالك والمجموعة المالكة إلى $superuser.

المستخدم المالك

المستخدم الذي أنشأ العنصر هو المستخدم المالك للعنصر تلقائيًا. يمكن للمستخدم المالك:

تغيير أذونات ملف مملوك.
غَيِّر المجموعة المالكة للملف المملوك، طالما أن المستخدم المالك هو أيضًا عضو في المجموعة المستهدفة.

إشعار

لا يمكن للمستخدم المالك تغيير المستخدم المالك لملف أو دليل. يمكن للمستخدمين المتميزين فقط تغيير المستخدم المالك لملف أو دليل.

المجموعة المالكة

في قوائم ACL POSIX، يقترن كل مستخدم بمجموعة أساسية. فعلى سبيل المثال، قد ينتمي المستعمل "Alice" إلى مجموعة "التمويل". قد ينتمي Alice أيضًا إلى مجموعات متعددة، ولكن يتم دائمًا تعيين مجموعة واحدة كمجموعة أساسية. في POSIX، عندما يقوم Alice بإنشاء ملف، يتم تعيين المجموعة المالكة لهذا الملف إلى مجموعتها الأساسية، والتي هي في هذه الحالة "تمويل." بخلاف ذلك، تتصرف المجموعة المالكة على غرار الأذونات المخصصة للمستخدمين/المجموعات الأخرى.

تعيين المجموعة المالكة لملف أو دليل جديد

الحالة 1: الدليل /الجذر . يُنشأ هذا الدليل عند إنشاء حاوية Data Lake Storage Gen2. في هذه الحالة، تُعين المجموعة المالكة للمستخدم الذي أنشأ الحاوية إذا تم ذلك باستخدام OAuth. إذا تم إنشاء الحاوية باستخدام Shared Key أو Account SAS أو Service SAS، فسيتم تعيين المالك والمجموعة المالكة إلى $superuser.
الحالة 2 (كل حالة أخرى): عند إنشاء عنصر جديد، يتم نسخ المجموعة المالكة من الدليل الأصل.

تغيير المجموعة المالكة

يمكن تغيير المجموعة المالكة عن طريق:

أي مستخدمين متميزين.
المستخدم المالك، إذا كان المستخدم المالك أيضًا عضوًا في المجموعة المستهدفة.

إشعار

لا يمكن للمجموعة المالكة تغيير قوائم ACL لملف أو دليل. بينما يتم تعيين مجموعة المالك إلى المستخدم الذي أنشأ الحساب في حالة الدليل الجذر، الحالة 1 أعلاه، حساب مستخدم واحد غير صالح لتوفير الأذونات عبر مجموعة المالك. يمكنك تعيين هذا الإذن إلى مجموعة مستخدمين صالحة إذا كان ذلك ممكنًا.

كيفية تقييم الأذونات

يتم تقييم الهويات بالترتيب التالي:

المستخدم المتميز
المستخدم المالك
المستخدم المسمى أو مدير الخدمة أو الهوية المدارة
امتلاك مجموعة أو مجموعة مسماة
جميع المستخدمين الآخرين

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

تعتبر جميع المجموعات المسماة معًا. إذا كان أساس الأمان عضوًا في أكثر من مجموعة مسماة، يقوم النظام بتقييم كل مجموعة حتى يتم منح الإذن المطلوب. إذا لم توفر أي من المجموعات المسماة الإذن المطلوب، فسينتقل النظام لتقييم طلب مقابل الإذن المقترن بجميع المستخدمين الآخرين.

يمثل الرمز الزائف التالي خوارزمية فحص الوصول لحسابات التخزين. تُبين هذه الخوارزمية الترتيب الذي يتم به تقييم الهويات.

def access_check( user, desired_perms, path ) :
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

القناع

كما هو موضح في خوارزمية التحقق من الوصول، يحد القناع من الوصول للمستخدمين المحددين والمجموعة المالكة والمجموعات المسماة.

بالنسبة إلى حاوية Data Lake Storage Gen2 جديدة، يتم تعيين قناع الوصول إلى ACL للدليل الجذر ("/") افتراضيا إلى 750 للدلائل و640 للملفات. يُبين الجدول التالي التدوين الرمزي لمستويات الأذونات هذه.

الكيان	الدلائل	الملفات
المستخدم المالك	`rwx`	`rw-`
المجموعة المالكة	`r-x`	`r--`
أخرى	`---`	`---`

لا تتلقى الملفات بت X لأنها ليست متصلة بالملفات الموجودة في نظام التخزين فقط.

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

الجزء اللاصق

الجزء اللاصق هو ميزة أكثر تقدمًا لحاوية POSIX. في سياق Data Lake Storage Gen2، من غير المحتمل أن تكون هناك حاجة إلى جزء لاصق. باختصار، إذا تم تمكين الجزء اللاصق في الدليل، فلا يمكن حذف العنصر الفرعي أو إعادة تسميته إلا من قبل المستخدم المالك للعنصر الفرعي، أو مالك الدليل، أو المستخدم المتميز ($ superuser).

لا يظهر الجزء اللاصق في مدخل Microsoft Azure.

الأذونات الافتراضية على الملفات والأدلة الجديدة

عند إنشاء ملف أو دليل جديد ضمن دليل موجود، يحدد ACL الافتراضي على الدليل الأصلي:

دليل فرعي ACL الافتراضي والوصول إلى ACL.
الوصول إلى ACL لملف تابع (لا تحتوي الملفات على ACL افتراضي).

umask

عند إنشاء ACL افتراضي، يتم تطبيق umask على الوصول إلى ACL لتحديد الأذونات الأولية لـ ACL الافتراضي. إذا تم تعريف ACL افتراضي على الدليل الأصل، يتم تجاهل umask بشكل فعال ويتم استخدام ACL الافتراضي للدليل الأصل لتعريف هذه القيم الأولية بدلاً من ذلك.

يعد umask قيمة 9 بت على الدلائل الأصلية التي تحتوي على قيمة RWX لـ امتلاك مستخدم وامتلاك مجموعة وأخرى.

umask قيمة ثابتة من Azure Data Lake Storage Gen2 تم تعيينها إلى 007. تترجم هذه القيمة إلى:

مكون umask	شكل رقمي	الصيغة المختصرة	المعنى
umask.owning_user	0	`---`	لامتلاك المستخدم، انسخ ACL الخاصة بالوصول للأصل إلى ACL الافتراضية للتابع
umask.owning_group	0	`---`	لامتلاك مجموعة، انسخ ACL الخاصة بالوصول للأصل إلى ACL الافتراضية للتابع
umask.other	7	`RWX`	بالنسبة إلى الآخرين، أزِل جميع الأذونات الموجودة على قائمة التحكم في الوصول إلى الفرع

الأسئلة المتداولة

هل يجب عليّ تمكين دعم قوائم ACL؟

‏‏لا. يتم تمكين التحكم في الوصول عبر قوائم ACL لحساب التخزين طالما تم تشغيل ميزة مساحة الأسماء الهرمية (HNS).

إذا تم إيقاف تشغيل HNS، فلا تزال قواعد تخويل Azure RBAC سارية.

ما هي أفضل طريقة لتطبيق قوائم ACL؟

استخدم دائما مجموعات أمان Microsoft Entra ككيان معين في إدخال ACL. مقاومة الفرصة للتعيين المباشر للمستخدمين الفرديين أو كيانات الخدمة. سيسمح لك استخدام هذه البنية بإضافة وإزالة المستخدمين أو كيانات الخدمة دون الحاجة إلى إعادة تطبيق قوائم التحكم بالوصول على بنية دليل بأكمله. بدلا من ذلك، يمكنك فقط إضافة المستخدمين وكيانات الخدمة أو إزالتهم من مجموعة أمان Microsoft Entra المناسبة.

هناك العديد من الطرق المختلفة لإنشاء مجموعات. على سبيل المثال، تخيل أن لديك دليلاً باسم /LogData يحتوي على بيانات السجل التي يتم إنشاؤها بواسطة الخادم الخاص بك. يستوعب Azure Data Factory (ADF) البيانات في هذا المجلد. سيقوم مستخدمون محددون من فريق هندسة الخدمة بتحميل السجلات وإدارة المستخدمين الآخرين لهذا المجلد، وستقوم مجموعات Databricks المختلفة بتحليل السجلات من هذا المجلد.

لتمكين هذه الأنشطة، يمكنك إنشاء LogsWriter مجموعة و LogsReader مجموعة. ومن ثم يمكنك تعيين الأذونات على النحو التالي:

أضف مجموعة LogsWriter إلى ACL لدليل / LogData بأذونات rwx.
أضف مجموعة LogsReader إلى ACL لدليل / LogData بأذونات r-x.
أضف عنصر الخدمة الرئيسي أو هوية الخدمة المدارة (MSI) لوحدة التغذية التلقائية للمستندات إلى مجموعة LogsWriters.
أضف المستخدمين في فريق هندسة الخدمة إلى مجموعة LogsWriter.
أضف عنصر الخدمة الرئيسي أو MSI لقاعدة البيانات إلى المجموعة LogsReader.

إذا ترك أحد المستخدمين في فريق هندسة الخدمة الشركة، فيمكنك إزالته من مجموعة LogsWriter. إذا لم تضف هذا المستخدم إلى مجموعة ولكن قمت، بدلاً من ذلك، بإضافة إدخال ACL مخصص لذلك المستخدم، يجب إزالة إدخال ACL هذا من الدليل /LogData. قد تحتاج أيضًا إلى إزالة الإدخال من جميع الدلائل الفرعية والملفات في التسلسل الهرمي للدليل بأكمله من الدليل /LogData.

لإنشاء مجموعة وإضافة أعضاء، راجع إنشاء مجموعة أساسية وإضافة أعضاء باستخدام معرف Microsoft Entra.

هام

يعتمد Azure Data Lake Storage Gen2 على معرف Microsoft Entra لإدارة مجموعات الأمان. يوصي Microsoft Entra ID بتقييد عضوية المجموعة لأساس أمان معين إلى أقل من 200. ترجع هذه التوصية إلى تقييد رموز ويب JSON المميزة (JWT) التي توفر معلومات عضوية مجموعة كيان الأمان داخل تطبيقات Microsoft Entra. قد يؤدي تجاوز هذا الحد إلى مشكلات أداء غير متوقعة مع Data Lake Storage Gen2. لمعرفة المزيد، راجع تكوين مطالبات المجموعة للتطبيقات باستخدام معرف Microsoft Entra.

كيف يتم تقييم أذونات Azure RBAC وACL؟

لمعرفة كيفية تقييم النظام ل Azure RBAC وACLs معا لاتخاذ قرارات التخويل لموارد حساب التخزين، راجع كيفية تقييم الأذونات.

ما هي حدود تعيينات دور Azure وإدخالات ACL؟

يوفر الجدول التالي عرضًا موجزًا للقيود التي يجب مراعاتها في أثناء استخدام Azure RBAC لإدارة الأذونات "الخشنة" (الأذونات التي تنطبق على حسابات التخزين أو الحاويات) واستخدام قوائم ACL لإدارة الأذونات "الدقيقة" (الأذونات التي تنطبق على الملفات والدلائل). استخدم مجموعات الأمان لمهام ACL. باستخدام المجموعات، يقل احتمال أن تتجاوز الحد الأقصى لعدد مهام الدور لكل اشتراك والحد الأقصى لعدد إدخالات ACL لكل ملف أو دليل.

آلِيَّة	النطاق	الحدود	مستوى الإذن المدعوم
Azure RBAC	حسابات التخزين،و الحاويات. مهام دور Azure عبر الموارد على مستوى الاشتراك أو مجموعة الموارد.	4000 تعيين دور Azure في اشتراك	أدوار Azure (مضمنة أو مخصصة)
قائمة التحكم بالوصول (ACL)	دليل، ملف	32 إدخالات ACL (فعليًا 28 إدخالات ACL) لكل ملف ولكل دليل. يحتوي كل من قوائم التحكم للوصول والقوائم الافتراضية على حد دخول ACL 32 الخاص به.	إذن ACL

هل تدعم Data Lake Storage Gen2 توريث Azure RBAC؟

لتوريث تعيينات دور Azure. تتدفق المهام بدءًا من الاشتراك ومجموعة الموارد وموارد حساب التخزين وصولاً إلى مورد الحاوية.

هل تدعم Data Lake Storage Gen2 توريث قوائم ACL؟

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

ما هي الأذونات المطلوبة لحذف الدليل ومحتوياته بشكل متكرر؟

لدى المتصل أذونات "مستخدم مميز "،

أو

يجب أن يحتوي الدليل الرئيسي على أذونات الكتابة + التنفيذ.
يتطلب الدليل المراد حذفه، وكل دليل داخله، أذونات القراءة + الكتابة + التنفيذ.

إشعار

لا تحتاج إلى أذونات الكتابة لحذف الملفات في الدلائل. أيضًا، لا يمكن أبدًا حذف الدليل الجذري "/".

من هو مالك الملف أو الدليل؟

يصبح منشئ الملف أو الدليل هو المالك. في حالة الدليل الجذري، هذه هي هوية المستخدم الذي أنشأ الحاوية.

ما المجموعة التي تم تعيينها كمجموعة مالكة لملف أو دليل عند الإنشاء؟

تُنسخ المجموعة المالكة من المجموعة المالكة للدليل الأصلي الذي يتم بموجبه إنشاء الملف أو الدليل الجديد.

أنا المستخدم المالك للملف ولكن ليس لديّ أذونات RWX أحتاجها. ماذا أفعل؟

يمكن للمستخدم المالك تغيير أذونات الملف لمنح أنفسهم أي أذونات RWX يحتاجونها.

لماذا أرى أحيانًا GUIDs في قوائم ACL؟

يتم عرض GUID إذا كان الإدخال يمثل مستخدما ولم يعد هذا المستخدم موجودا في Microsoft Entra. يحدث هذا عادة عندما يغادر المستخدم الشركة أو إذا تم حذف حسابه في معرف Microsoft Entra. بالإضافة إلى ذلك، لا يمتلك مديرو الخدمة ومجموعات الأمان اسمًا رئيسيًا للمستخدم (UPN) لتحديدهم، ومن ثمّ يتم تمثيلهم من خلال سمة OID الخاصة بهم (دليل). لتنظيف قوائم التحكم بالوصول، احذف إدخالات GUID هذه يدويا.

كيف أعين قوائم ACL بشكل صحيح لمدير الخدمة؟

عند تعريف قوائم التحكم في الوصول لكيانات الخدمة، من المهم استخدام معرف الكائن (OID) لمدير الخدمة لتسجيل التطبيق الذي قمت بإنشائه. من المهم ملاحظة أن التطبيقات المسجلة لها كيان خدمة منفصل في مستأجر Microsoft Entra المحدد. تحتوي التطبيقات المسجلة على OID مرئي في مدخل Microsoft Azure، ولكن كيان الخدمة لديه OID آخر (مختلف). مقالة للحصول على OID لكيان الخدمة الذي يتوافق مع تسجيل التطبيق، يمكنك استخدام الأمر az ad sp show. حدد معرف التطبيق كضابط. فيما يلي مثال على الحصول على OID لكيان الخدمة الذي يتوافق مع تسجيل تطبيق مع معرف التطبيق = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. شَغِل الأمر التالي في Azure CLI:

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

سيُعرض OID.

عندما يكون لديك OID الصحيح لكيان الخدمة، انتقل إلى صفحة Storage Explorer Manage Access لإضافة OID وتعيين الأذونات المناسبة ل OID. تأكد من تحديد حفظ

هل يمكنني إنشاء ACL للحاوية؟

‏‏لا. لا تحتوي الحاوية على ACL. ومع ذلك، يمكنك تعيين ACL للدليل الجذري للحاوية. تحتوي كل حاوية على دليل جذري، وتشترك في نفس اسم الحاوية. على سبيل المثال، إذا تمت تسمية my-containerالحاوية ، فإن الدليل الجذر يسمى my-container/.

تحتوي Azure Storage REST API على عملية تسمى Set Container ACL، ولكن لا يمكن استخدام هذه العملية لتعيين ACL لحاوية أو الدليل الجذر للحاوية. بدلا من ذلك، يتم استخدام هذه العملية للإشارة إلى ما إذا كان يمكن الوصول إلى الكائنات الثنائية كبيرة الحجم في حاوية مع طلب مجهول. نوصي بطلب تخويل لجميع طلبات بيانات الكائن الثنائي كبير الحجم. لمزيد من المعلومات، راجع نظرة عامة: معالجة الوصول للقراءة المجهولة لبيانات الكائن الثنائي كبير الحجم.

أين يمكنني معرفة المزيد عن نموذج POSIX للتحكم في الدخول؟

(راجع أيضًا )

نموذج التحكم بالوصول في Azure Data Lake Storage Gen2

قوائم التحكم بالوصول في Azure Data Lake Storage Gen2

حول قوائم التحكم في الوصولACL

كيفية تعيين قوائم التحكم في الوصول

أنواع قوائم التحكم في الوصول

مستويات الإذن

نماذج مختصرة للأذونات

توريث الأذونات

السيناريوهات الشائعة المتعلقة بأذونات ACL

حذف الملفات والدلائل

ما هي الأذونات المطلوبة لحذف الدليل ومحتوياته بشكل متكرر؟

المستخدمون والهويات

المستخدم الفائق

المستخدم المالك

المجموعة المالكة

تعيين المجموعة المالكة لملف أو دليل جديد

تغيير المجموعة المالكة

كيفية تقييم الأذونات

القناع

الجزء اللاصق

الأذونات الافتراضية على الملفات والأدلة الجديدة

umask

الأسئلة المتداولة

هل يجب عليّ تمكين دعم قوائم ACL؟

ما هي أفضل طريقة لتطبيق قوائم ACL؟

كيف يتم تقييم أذونات Azure RBAC وACL؟

ما هي حدود تعيينات دور Azure وإدخالات ACL؟

هل تدعم Data Lake Storage Gen2 توريث Azure RBAC؟

هل تدعم Data Lake Storage Gen2 توريث قوائم ACL؟

ما هي الأذونات المطلوبة لحذف الدليل ومحتوياته بشكل متكرر؟

من هو مالك الملف أو الدليل؟

ما المجموعة التي تم تعيينها كمجموعة مالكة لملف أو دليل عند الإنشاء؟

أنا المستخدم المالك للملف ولكن ليس لديّ أذونات RWX أحتاجها. ماذا أفعل؟

لماذا أرى أحيانًا GUIDs في قوائم ACL؟

كيف أعين قوائم ACL بشكل صحيح لمدير الخدمة؟

هل يمكنني إنشاء ACL للحاوية؟

أين يمكنني معرفة المزيد عن نموذج POSIX للتحكم في الدخول؟

(راجع أيضًا )

الموارد الإضافية