مشاركة عبر

التحكم في الوصول في Azure Data Lake Storage Gen1

  • مقالة

ينفذ Azure Data Lake Storage Gen1 نموذج التحكم في الوصول الذي يستمد من HDFS، والذي بدوره مشتق من نموذج التحكم في الوصول POSIX. تلخص هذه المقالة أساسيات نموذج التحكم في الوصول Data Lake Storage Gen1.

قوائم التحكم بالوصول على الملفات والمجلدات

هناك نوعان من قوائم التحكم في الوصول (ACLs)، وAccess ACLsوACLs الافتراضية.

  • الوصول إلى قوائم التحكم بالوصول: تتحكم هذه في الوصول إلى كائن. تحتوي الملفات والمجلدات على قوائم التحكم في الوصول.

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

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

ملاحظة

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

الأذونات

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

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

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

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

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

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

في نموذج نمط POSIX الذي يستخدمه Data Lake Storage Gen1، يتم تخزين أذونات العنصر على العنصر نفسه. بمعنى آخر، لا يمكن توريث أذونات عنصر من العناصر الأصل.

فيما يلي بعض السيناريوهات الشائعة لمساعدتك على فهم الأذونات المطلوبة لتنفيذ عمليات معينة على حساب Data Lake Storage Gen1.

‏‏التشغيل عنصر / سياتل/ Portland/ Data.txt
قراءة Data.txt --X --X --X R--
إلحاق ب Data.txt --X --X --X -W-
حذف Data.txt --X --X -WX ---
إنشاء Data.txt --X --X -WX ---
قائمة / R-X --- --- ---
قائمة /سياتل/ --X R-X --- ---
قائمة /سياتل/بورتلاند/ --X --X R-X ---

ملاحظة

أذونات الكتابة على الملف غير مطلوبة لحذفه طالما أن الشرطين السابقين صحيحان.

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

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

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

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

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

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

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

جميع المستخدمين الذين يشكلون جزءا من دور المالكين لحساب Data Lake Storage Gen1 هم تلقائيا مستخدم فائق.

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

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

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

ملاحظة

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

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

الخلفية

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

نظرا لعدم وجود "مجموعة أساسية" مقترنة بالمستخدمين في Data Lake Storage Gen1، يتم تعيين المجموعة المالكة كما يلي.

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

  • الحالة 1: المجلد الجذر "/". يتم إنشاء هذا المجلد عند إنشاء حساب Data Lake Storage Gen1. في هذه الحالة، يتم تعيين المجموعة المالكة إلى GUID كل الصفر. لا تسمح هذه القيمة بأي وصول. وهو عنصر نائب حتى يتم تعيين مجموعة في مثل هذا الوقت.
  • الحالة 2 (كل حالة أخرى): عند إنشاء عنصر جديد، يتم نسخ المجموعة المالكة من المجلد الأصل.

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

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

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

ملاحظة

لا يمكن للمجموعة المالكة تغيير قوائم التحكم في الوصول لملف أو مجلد.

بالنسبة للحسابات التي تم إنشاؤها في سبتمبر 2018 أو قبله، تم تعيين المجموعة المالكة للمستخدم الذي أنشأ الحساب في حالة المجلد الجذر للحالة 1 أعلاه. حساب مستخدم واحد غير صالح لتوفير الأذونات عبر المجموعة المالكة، وبالتالي لا يتم منح أي أذونات بواسطة هذا الإعداد الافتراضي. يمكنك تعيين هذا الإذن لمجموعة مستخدمين صالحة.

خوارزمية التحقق من الوصول

يمثل الرمز الزائف التالي خوارزمية التحقق من الوصول لحسابات Data Lake Storage Gen1.

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 folder
  # Note: the "sticky bit" is not illustrated in this algorithm
  
# Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask IS NOT 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.permmissions & mask) == desired_perms)

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

القناع

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

ملاحظة

بالنسبة لحساب Data Lake Storage Gen1 جديد، يتم تعيين قناع Access ACL للمجلد الجذر ("/") افتراضيا إلى RWX.

الجزء اللاصق

البت الملصق هو ميزة أكثر تقدما لنظام ملفات POSIX. في سياق Data Lake Storage Gen1، من غير المحتمل أن تكون هناك حاجة إلى البت اللاصق. باختصار، إذا تم تمكين البت اللاصق على مجلد، يمكن حذف عنصر تابع أو إعادة تسميته فقط من قبل المستخدم المالك للعنصر التابع.

لا يتم عرض البت اللاصق في مدخل Microsoft Azure.

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

عند إنشاء ملف أو مجلد جديد ضمن مجلد موجود، تحدد قائمة التحكم بالوصول الافتراضية على المجلد الأصل ما يلي:

  • قائمة التحكم بالوصول الافتراضية للمجلد التابع وAccess ACL.
  • Access ACL الخاص بملف تابع (لا تحتوي الملفات على قائمة التحكم بالوصول الافتراضية).

umask

عند إنشاء ملف أو مجلد، يتم استخدام umask لتعديل كيفية تعيين قوائم التحكم في الوصول الافتراضية على العنصر التابع. umask هي قيمة 9 بت على المجلدات الأصلية التي تحتوي على قيمة RWX لامتلاك المستخدموالمجموعة المالكةوغيرها.

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

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

تعني قيمة umask المستخدمة من قبل Azure Data Lake Storage Gen1 بشكل فعال أن قيمة الأخرى لا يتم إرسالها بشكل افتراضي على الأطفال الجدد - بغض النظر عما يشير إليه قائمة التحكم بالوصول الافتراضية.

يوضح الرمز الزائف التالي كيفية تطبيق umask عند إنشاء قوائم ACL لعنصر تابع.

def set_default_acls_for_new_child(parent, child):
    child.acls = []
    for entry in parent.acls :
        new_entry = None
        if (entry.type == OWNING_USER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_user))
        elif (entry.type == OWNING_GROUP) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_group))
        elif (entry.type == OTHER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.other))
        else :
            new_entry = entry.clone(perms = entry.perms )
        child_acls.add( new_entry )

الأسئلة الشائعة حول قوائم التحكم في الوصول في Data Lake Storage Gen1

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

كلا. التحكم في الوصول عبر قوائم التحكم بالوصول قيد التشغيل دائما لحساب Data Lake Storage Gen1.

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

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

ملاحظة

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

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

يصبح منشئ ملف أو مجلد هو المالك.

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

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

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

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

عندما أنظر إلى قوائم التحكم في الوصول في مدخل Microsoft Azure، أرى أسماء المستخدمين ولكن من خلال واجهات برمجة التطبيقات، أرى معرفات الرسومات، لماذا هذا؟

يتم تخزين الإدخالات في قوائم التحكم في الوصول ك GUIDs تتوافق مع المستخدمين في Microsoft Entra ID. تقوم واجهات برمجة التطبيقات بإعادة معرفات المستخدم الرسومية كما هي. يحاول مدخل Microsoft Azure تسهيل استخدام قوائم التحكم في الوصول عن طريق ترجمة معرفات المستخدم الرسومية إلى أسماء مألوفة عندما يكون ذلك ممكنا.

لماذا أرى أحيانا معرفات الرسومات في قوائم التحكم بالوصول عند استخدام مدخل Microsoft Azure؟

يتم عرض GUID عندما لا يكون المستخدم موجودا في Microsoft Entra بعد الآن. يحدث هذا عادة عندما يغادر المستخدم الشركة أو إذا تم حذف حسابه في Microsoft Entra ID. تأكد أيضا من أنك تستخدم المعرف الصحيح لإعداد قوائم التحكم في الوصول (التفاصيل المعنية أدناه).

عند استخدام كيان الخدمة، ما هو المعرف الذي يجب استخدامه لتعيين قوائم التحكم في الوصول؟

في مدخل Microsoft Azure، انتقل إلى Microsoft Entra ID -> تطبيقات المؤسسة وحدد التطبيق الخاص بك. يجب أن تعرض علامة التبويب Overview معرف كائن وهذا ما يجب استخدامه عند إضافة قوائم التحكم في الوصول إلى البيانات (وليس معرف التطبيق).

هل يدعم Data Lake Storage Gen1 توريث قوائم التحكم بالوصول؟

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

ما هي حدود إدخالات قائمة التحكم بالوصول على الملفات والمجلدات؟

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

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

راجع أيضًا