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

  • مقالة
  • قراءة خلال 9 دقائق

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

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

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

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

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

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

ملاحظة

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

الأذونات

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

الملف المجلد
القراءة (R) يمكن قراءة محتويات الملف يتطلب قراءةوتنفيذ لسرد محتويات المجلد
الكتابة (W) يمكن كتابة ملف أو الإلحاق به يتطلب الكتابةوالتنفيذ لإنشاء عناصر فرعية في مجلد
التنفيذ (X) لا يعني أي شيء في سياق 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.

‏‏التشغيل العنصر / سياتل/ بورتلاند/ 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 ---

ملاحظة

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

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

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

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

هويات المستخدمين والمجموعات هي هويات Azure Active Directory (Azure AD). لذلك، ما لم يذكر خلاف ذلك، يمكن أن يعني "المستخدم"، في سياق Data Lake Storage Gen1، إما مستخدم Azure AD أو مجموعة أمان Azure AD.

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

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

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

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

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

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

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

ملاحظة

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

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

الخلفية

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

نظرا لعدم وجود "مجموعة أساسية" مرتبطة بالمستخدمين في 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 ، من غير المرجح أن تكون هناك حاجة إلى البت اللزج. باختصار، إذا تم تمكين البت اللزج على مجلد، فلا يمكن حذف عنصر تابع أو إعادة تسميته إلا بواسطة المستخدم المالك للعنصر التابع.

لا يظهر البت اللزج في مدخل Azure.

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

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

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

أوماسك

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

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

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

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

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

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

هل يجب علي تمكين دعم قوائم التحكم في الوصول؟

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

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

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

ملاحظة

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

روبوت Who هو مالك ملف أو مجلد؟

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

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

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

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

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

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

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

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

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

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

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

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

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

ما هي حدود إدخالات ACL على الملفات والمجلدات؟

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

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

راجع أيضًا