تنفيذ استراتيجيات التحكم في الوصول
التحكم في الوصول في كتالوج Unity مبني على أربعة نماذج مكملة تعمل معا لفرض وصول آمن ودقيق عبر بيئة بياناتك.
| آلِيَّة | ينطبق على | حالة الاستخدام |
|---|---|---|
| الامتيازات والملكية | الكتالوجات، المخططات، الجداول | الوصول الأساسي والتفويض — من يمكنه الوصول إلى ماذا |
| التحكم في الوصول القائم على السمات (ABAC) | الأشياء الموسومة عبر الكتالوجات والمخططات | سياسات مركزية مدفوعة بالوسم لتنفيذ ديناميكي |
| مرشحات الصفوف والأعمدة على مستوى الجدول | الجداول الفردية | التصفية أو التمويه لكل جدول باستخدام UDFs |
| روابط مساحة العمل | الكتالوجات، المواقع الخارجية، بيانات التخزين | تقييد الوصول إلى الكائنات من مساحات عمل محددة |
تركز هذه الوحدة على الامتيازات والملكية — الأساس الذي تبنى عليه جميع النماذج الأخرى. يتم تغطية أمان الصفوف والأعمدة الدقيق في الوحدتين التاليتين. يتم تغطية ABAC بعمق في وحدة كائنات كتالوج Govern Unity .
يستخدم كتالوج Unity نموذج امتياز للتحكم في الوصول إلى الكائنات القابلة للتأمين مثل الكتالوجات والمخططات والجداول وطرق العرض. تحدد المنح من (المدير، مثل المجموعة أو المستخدم) الذي يمكنه تنفيذ الإجراء (امتياز مثل SELECT أو MODIFY أو CREATE) على أي كائن (مثل جدول). يمكن تعيين الامتيازات بشكل صريح في كل مستوى من مستويات الاحتواء أو توريثها من مستويات أعلى مثل المخططات أو الكتالوجات. يعد فهم هذه الأنماط أمرا أساسيا لتصميم هياكل أذونات آمنة وقابلة للصيانة.
في Azure، يعد مخزن تعريف كتالوج Unity حاوية ذات مستوى أعلى لجميع الكائنات القابلة للتأمين ويتم دمجها بإحكام مع مساحات عمل Azure Databricks:
- المنطقة المحدودة: يتم إنشاء مخزن تعريف في منطقة Azure معينة ولا يمكن تعيينه إلا لمساحات العمل في نفس المنطقة.
- واحد لكل مساحة عمل: يمكن ربط كل مساحة عمل Azure Databricks بمخزن تعريف واحد فقط في كل مرة.
بسبب ربط المنطقة هذه، غالبا ما تنشئ المؤسسات مخازن تعريف متعددة (واحد لكل منطقة) إذا كانت تعمل عبر مناطق جغرافية مختلفة في Azure. يجب أن تأخذ سياسات إدارة البيانات في الحسبان هذه الحدود.
الاستعلام عن جدول بصلاحيات صريحة في كل مستوى
عندما يحتاج مستخدم أو مجموعة إلى الاستعلام عن جدول، لا يكفي منح SELECT مباشرة على الجدول. يتطلب كتالوج الوحدة أذونات على جميع مستويات الاحتواء. هذا يعني أن المستفيد من المنحة يحتاج:
- استخدم الكتالوج في الكتالوج الذي يحتوي على المخطط،
- استخدم SCHEMA في المخطط الذي يحتوي على الجدول، و
- حدد على الجدول نفسه.
إذا كان أي من هذه الامتيازات مفقودا، فلن يتمكن المستخدم من الاستعلام عن الجدول بنجاح. يسمى هذا النهج باسم نموذج الامتياز الصريح لأنه يتم منح الأذونات بشكل فردي في كل مستوى. إنه آمن بطبيعته لأنه لا يتم منح الوصول إلى كائنات أخرى عن غير قصد ، ولكنه يتطلب المزيد من الجهد الإداري. على سبيل المثال، إذا كان هناك آلاف الجداول في مخطط، فيجب منح كل جدول بشكل صريح، وهو ما يستغرق وقتا طويلا للصيانة.
الاستعلام عن جدول يحتوي على الأذونات الموروثة من المخطط
يقلل توريث الامتيازات من النفقات الإدارية العامة عن طريق منح أذونات على مستوى أعلى. بدلا من تعيين SELECT على كل جدول على حدة، يمكن للمسؤول منح SELECT في المخطط. بالاقتران مع امتيازات USE SCHEMA و USE CATALOG ، يمنح هذا تلقائيا المستفيد من المنحة SELECT على جميع الجداول وطرق العرض داخل هذا المخطط ، بما في ذلك أي تم إنشاؤه في المستقبل.
يعمل هذا النهج على تبسيط الإدارة ، خاصة عند وجود أعداد كبيرة من الجداول. ومع ذلك ، فهو أقل تقييدا من النموذج الصريح لأن جميع الكائنات الحالية والمستقبلية داخل المخطط تصبح متاحة. ومع ذلك، لا يزال الوصول مقتصرا على هذا المخطط، حيث لا يزال يتعذر الوصول إلى المخططات الأخرى ما لم يتم منحها بشكل منفصل.
الاستعلام عن جدول بصلاحيات موروثة من الكتالوج
يمكن أن يمتد الميراث أيضا من مستوى الكتالوج. من خلال منح استخدام كتالوجوجميع الامتيازات (أو SELECT) في الكتالوج، يرث المستفيد تلقائيا الأذونات اللازمة على جميع المخططات والجداول وطرق العرض داخل هذا الكتالوج. يتضمن ذلك أي مخططات أو كائنات تم إنشاؤها في المستقبل.
هذا النموذج هو الأكثر تساهلا لأنه يفتح الوصول عبر الكتالوج بأكمله. إنه مناسب عند الرغبة في الوصول الواسع ، مثل منح مجموعة من المحللين القدرة على الاستعلام عن كل شيء داخل كتالوج معين. ومع ذلك ، يحتاج المسؤولون إلى تقييم ما إذا كان يجب عرض جميع الكائنات الموجودة في الكتالوج بعناية بهذه الطريقة ، نظرا لعدم وجود دقة على مستوى المخطط أو الجدول عند الوراثة من الكتالوج.
إنشاء جدول: صريح عند المخطط
يتطلب إنشاء جداول جديدة أكثر من أذونات SELECT. كحد أدنى، يجب أن يكون لدى المستفيد منها:
- استخدم الكتالوج في الكتالوج المحتوي ،
- استخدام SCHEMA في المخطط الهدف، و
- إنشاء جدول على هذا المخطط.
باستخدام هذه الأذونات، يمكن للمستفيد من المنحة إنشاء جداول جديدة في هذا المخطط المحدد. يقيد هذا الإعداد الصريح إنشاء الجدول بمخطط واحد ويتجنب منح امتيازات غير ضرورية في مكان آخر. إنه خيار شائع عندما تسمح مخططات معينة فقط بإنشاء كائن جديد.
إنشاء جدول: موروث من الكتالوج
في البيئات الأكثر تساهلا، يمكن توريث حقوق إنشاء الجدول من مستوى الكتالوج. من خلال منح USE CATALOG و USE SCHEMA و CREATE TABLE في الكتالوج ، يكون لدى المستفيد تلقائيا القدرة على إنشاء جداول في أي مخطط داخل هذا الكتالوج ، بما في ذلك المخططات التي قد تتم إضافتها لاحقا.
هذا النهج أسهل في الصيانة ولكنه ينطوي على مخاطر أكبر ، لأنه يتيح إنشاء طاولة في كل مكان داخل الكتالوج. إنه الأنسب للكتالوجات المصممة للعمل التعاوني أو الاستكشافي، حيث يكون الإنشاء غير المقيد مقبولا.
منح الأذونات باستخدام ANSI SQL
يتبع كتالوج الوحدة معيار ANSI SQL Data Control Language (DCL) لمنح الامتيازات وإبطالها. هذا يعني أنه يمكنك إدارة الأذونات باستخدام عبارات مألوفة مثل GRANTوREVOKE. على سبيل المثال، إذا كنت تريد السماح لمحللي المجموعة بالاستعلام عن جدول معين، فيمكنك إصدار:
GRANT SELECT ON TABLE sales TO `analysts`;
إذا كنت تريد أن تجتاز المجموعة نفسها المخطط والكتالوج المحتملين ، فستحتاج أيضا إلى:
GRANT USE SCHEMA ON SCHEMA finance TO `analysts`;
GRANT USE CATALOG ON CATALOG corpdata TO `analysts`;
للسماح بإنشاء جدول ضمن مخطط، يمكنك منح:
GRANT CREATE TABLE ON SCHEMA finance TO `analysts`;
يمكن إبطال الأذونات بطريقة مماثلة:
REVOKE SELECT ON TABLE sales FROM `analysts`;
يمكن تشغيل عبارات SQL هذه من دفتر ملاحظات Databricks أو محرر SQL في مساحة العمل أو في Databricks SQL.
منح الأذونات باستخدام واجهة مستخدم Azure Databricks
بالنسبة لأولئك الأشخاص الذين يفضلون نهجا رسوما، يمكن أيضا إدارة أذونات كتالوج الوحدة مباشرة في واجهة مستخدم Azure Databricks. في مستكشف الكتالوج (المعروف سابقا باسم مستكشف البيانات)، يمكنك التنقل عبر الكتالوجات والمخططات والجداول. يحتوي كل كائن على علامة تبويب الأذونات حيث يمكنك إضافة مستخدمين أو مجموعات أو كيانات خدمة كأساسيات، وتعيين امتيازات مثل تحديد أو استخدام مخطط أو كافة الامتيازات.
على سبيل المثال، لمنح SELECT على جدول من خلال واجهة المستخدم:
- افتح مستكشف الكتالوج.
- انتقل إلى الكتالوج والمخطط اللذين يحتويان على الجدول الهدف.
- حدد الجدول، ثم انتقل إلى علامة التبويب الأذونات .
- أضف المجموعة (على سبيل المثال، المحللون) وقم بتعيين امتياز SELECT .
يمكنك تكرار نفس العملية على مستوى المخطط أو الكتالوج لتعيين أذونات أوسع. تعرض واجهة المستخدم أيضا بوضوح الامتيازات الموروثة ، مما يسهل تدقيق الوصول عبر المستويات.
تحقق من الامتيازات الممنوحة
بعد منح الامتيازات، يجب عليك التحقق من أن الأذونات الصحيحة موجودة. يوفر كتالوج Unity أمر SHOW GRANTS لعرض جميع الامتيازات على كائن أو لعنصر معين.
لرؤية جميع المنح على الجدول، استخدم أمر SHOW GRANTS مع نوع الكائن والاسم:
-- Show all privileges granted on a table
SHOW GRANTS ON TABLE sales.reporting.monthly_revenue;
يرجع هذا الأمر قائمة تظهر كل رئيس، والامتيازات التي يحملها، والكائن الذي تنطبق عليه تلك الامتيازات. يمكنك أيضا التحقق من المنح على المخططات أو الكتالوجات أو الكائنات القابلة للتأمين باستخدام نفس النمط.
إذا كنت تريد رؤية امتيازات لمدير معين، أدرج اسم المدير في الأمر:
-- Show privileges for a specific group
SHOW GRANTS `finance-team` ON TABLE sales.reporting.monthly_revenue;
عند مراجعة الامتيازات، تذكر أن المنح الموروثة قد لا تظهر في المخرجات الخاصة بالجدول المحدد. إذا كان لدى المستخدم خيار SELECT على مستوى المخطط أو الكتالوج، فإن هذا الامتياز ينطبق على الجدول من خلال الوراثة، لكن منح SHOW على الجدول نفسه قد لا يعرضها. للحصول على صورة كاملة، تحقق من المنح على جميع مستويات التسلسل الهرمي.
فهم قوائم التحكم في الوصول (ACL)
قوائم التحكم في الوصول (ACL) هي العمود الفقري لنموذج تخويل Unity Catalog: فهي تربط بشكل صريح مديرابامتياز على كائن قابل للتأمين. لفهم كيفية عمل قوائم التحكم في الوصول ، يمكننا تقسيم هذه الأجزاء الثلاث - الامتيازات ، والتأمينات ، والمبادئ - ثم معرفة كيفية تفاعلها في منحة نموذجية.
الامتيازات
الامتيازات هي العمليات أو الإجراءات المحددة التي يمكن تنفيذها على كائنات قابلة للتأمين. في كتالوج Unity، تدعم أنواع مختلفة من الكائنات مجموعات امتيازات مختلفة. على سبيل المثال، بالنسبة للجدول ، تتضمن SELECTالامتيازات المسموح بها ، MODIFY، MANAGE، ALL PRIVILEGES (التي تتوسع إلى جميع الامتيازات القابلة للتطبيق) من بين أمور أخرى. بالنسبة إلى المخطط، امتيازات مثل USE SCHEMA، CREATE TABLE، ALL PRIVILEGESوتطبيق MANAGE . على مستوى الكتالوج ، سترى امتيازات مثل USE CATALOG، CREATE SCHEMA، BROWSE، ALL PRIVILEGESوالمزيد.
نظرا لأنه ليس كل امتياز منطقيا لكل كائن (على سبيل المثال ، MODIFY في طريقة العرض لا معنى له) ، فإن كتالوج الوحدة يحد من الامتيازات الصالحة للأنواع القابلة للتأمين. الاختصار ALL PRIVILEGES قوي من حيث أنه يمنح "كل امتياز قابل للتطبيق" على كائن ما ، ومع إضافة امتيازات جديدة بمرور الوقت ، تغطي المنحة ALL PRIVILEGES تلقائيا تلك الامتيازات الجديدة أيضا.
المواد القابلة للتأمين
المؤهلات القابلة للتأمين هي الكائنات التي يمكنك منحها أو إبطال الامتيازات. في كتالوج الوحدة، تكون العناصر القابلة للتأمين هرمية: يوجد المخزن التعريفي (أو الكتالوج) في الأعلى، متبوعا بالكتالوجات، ثم المخططات، ثم الجداول/طرق العرض، وأنواع الكائنات الأخرى مثل الوظائف ووحدات التخزين والمواقع الخارجية وما إلى ذلك.
بسبب هذا التسلسل الهرمي ، يمكن توريث الامتيازات (إذا سمح بذلك) من المستويات الأعلى إلى المستويات الأدنى.
مديري المدارس
المديرون هم "من" في قائمة التحكم في الوصول (ACL) - الهوية التي تمنح لها الامتيازات. في كتالوج الوحدة / Azure Databricks، يمكن أن يكون المدير مستخدما أو كيان خدمة (للهويات البرمجية) أو مجموعة. غالبا ما تكون المجموعات مفضلة لسهولة الإدارة: يمكنك تعيين امتيازات للمجموعات، ثم يرث المستخدمون هذه الامتيازات من خلال العضوية، بدلا من منحها لكل فرد.
يستخدم بناء جملة تسمية الأساسيات في SQL علامات خلفية عند وجود أحرف خاصة (على سبيل المثال، "@" في اسم مستخدم أو شرطات في معرف كيان خدمة). على سبيل المثال،
GRANT SELECT ON TABLE t TO `alice@company.com`;
أو
GRANT SELECT ON TABLE t TO `aaaaaaaa-bbbb-cccc-1111-222222222222`; -- service principal
وتجدر الإشارة أيضا إلى: account users هو كيان مضمن يمثل جميع مستخدمي الحساب؛ يمكنك منح امتيازات ( account users ولكن ليس لمجموعة users مساحة العمل المحلية) في كتالوج Unity.
عندما تقوم بتجميع هذه القطع معا ، فإن قائمة التحكم في الوصول (ACL) هي ببساطة عبارة مثل: امنح هذا الامتياز لهذا المدير على هذا الكائن القابل للتأمين. في وقت التشغيل، عندما يحاول المستخدم تنفيذ عملية (على سبيل المثال تحديد من جدول)، يتحقق النظام من قوائم التحكم في الوصول على طول التسلسل الهرمي (الكتالوج والمخطط والجدول) ويقيم ما إذا كان المستخدم (عبر عضوية المجموعة أو المنح الصريحة أو المنح الموروثة) لديه المجموعة المطلوبة من الأذونات للنجاح.
تكامل معرف Microsoft Entra
في Azure Databricks، تتم إدارة هويات كتالوج الوحدة من خلال معرف Microsoft Entra. هذا يعني أن جميع المستخدمين وكيانات الخدمة والمجموعات المشار إليها في المنح يجب أن تكون موجودة في معرف Microsoft Entra. تتضمن النقاط الرئيسية ما يلي:
- المستخدمون والمجموعات: لا يدعم كتالوج الوحدة المستخدمين أو المجموعات المحلية لمساحة العمل. يجب عليك توفيرها وإدارتها في معرف Microsoft Entra، ويقوم كتالوج الوحدة بمزامنتها في حساب Azure Databricks.
- كيانات الخدمة: يتم تسجيل الهويات البرمجية كتطبيقات Microsoft Entra ويمكن منحها امتيازات في كتالوج Unity. عادة ما يتم تخزين بيانات الاعتماد في Azure Key Vault أو الوصول إليها من خلال الهويات المدارة.
-
مستخدمو الحساب: يمثل المبدأ
account usersالمضمن الخاص جميع مستخدمي معرف Microsoft Entra في حساب Azure Databricks، ويمكن استخدامه عندما يكون الوصول الواسع مقبولا.
نظرا لأن كتالوج الوحدة يعتمد على معرف Microsoft Entra، يجب على المسؤولين التنسيق عن كثب مع مسؤولي معرف Microsoft Entra لضمان بقاء عضويات المجموعة وتعيينات الأدوار دقيقة.