مشاركة عبر

إدارة الهوية والوصول

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

تعتمد هذه المقالة على الاعتبارات والتوصيات حول مناطق هبوط Azure. لمزيد من المعلومات، راجع إدارة الهوية والوصول.

تصميم منطقة البيانات المنتقل إليها

تدعم التحليلات على نطاق السحابة نموذج التحكم في الوصول باستخدام هويات Azure Active Directory (Azure AD). يستخدم النموذج كلا من التحكم في الوصول المستند إلى دور Azure (Azure RBAC) وقوائم التحكم في الوصول (ACLs).

راجع أنشطة إدارة وإدارة Azure التي تقوم بها فرقك. ضع في اعتبارك تحليلاتك على نطاق السحابة على Azure. تحديد أفضل توزيع ممكن للمسؤوليات داخل مؤسستك.

تعيينات الأدوار

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

يجب السماح بوصول فريق التطوير وهويات المستخدمين الخاصة بهم إلى بيئة التطوير لتمكينهم من التكرار بسرعة أكبر، والتعرف على قدرات معينة داخل خدمات Azure واستكشاف المشكلات وإصلاحها بشكل فعال. سيساعد الوصول إلى بيئة التطوير عند تطوير البنية الأساسية أو تحسينها كتعليمية (IaC) وغيرها من أدوات التعليمات البرمجية. بمجرد أن يعمل التنفيذ داخل بيئة التطوير كما هو متوقع، يمكن طرحه باستمرار في البيئات الأعلى. يجب تأمين البيئات الأعلى، مثل الاختبار وال prod، لفريق تطبيق البيانات. يجب أن يكون لمدير الخدمة فقط حق الوصول إلى هذه البيئات، وبالتالي يجب تنفيذ جميع عمليات التوزيع من خلال الهوية الأساسية للخدمة باستخدام مسارات CI/CD. للتلخيص، في بيئة التطوير، يجب توفير حقوق الوصول إلى كيان الخدمة وهويات مستخدم AND وفي البيئات الأعلى، يجب توفير حقوق الوصول فقط إلى هوية كيان الخدمة.

لكي تتمكن من إنشاء الموارد وتعيينات الأدوار بين الموارد داخل مجموعة (مجموعات) موارد تطبيق البيانات، ContributorUser Access Administrator يجب توفير الحقوق. سيسمح هذا للفرق بإنشاء الخدمات والتحكم فيها داخل بيئتها داخل حدود Azure Policy. توصي التحليلات على نطاق السحابة باستخدام نقاط النهاية الخاصة للتغلب على مخاطر النقل غير المصرح للبيانات، وكما يجب حظر خيارات الاتصال الأخرى من قبل فريق النظام الأساسي Azure عبر النهج، ستتطلب فرق تطبيقات البيانات حقوق الوصول إلى الشبكة الظاهرية المشتركة لمنطقة البيانات المنتقل إليها لتكون قادرة على إعداد اتصال الشبكة المطلوب للخدمات التي يخططون لاستخدامها بنجاح. لاتباع مبدأ الامتياز الأقل، والتغلب على التعارضات بين فرق تطبيقات البيانات المختلفة وفصل واضح بين الفرق، تقترح التحليلات على نطاق السحابة إنشاء شبكة فرعية مخصصة لكل فريق تطبيق بيانات وإنشاء Network Contributor تعيين دور لتلك الشبكة الفرعية (نطاق المورد التابع). يسمح تعيين الدور هذا للفرق بالانضمام إلى الشبكة الفرعية باستخدام نقاط النهاية الخاصة.

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

لتمكين استخدام الخدمة الذاتية للموارد المشتركة الأخرى داخل منطقة البيانات المنتقل إليها، يلزم عدد قليل من تعيينات الأدوار الإضافية. إذا كان الوصول إلى بيئة Databricks مطلوبا، يجب على المؤسسات استخدام SCIM Synch من AAD لتوفير الوصول. هذا مهم، حيث تقوم هذه الآلية تلقائيا بمزامنة المستخدمين والمجموعات من AAD إلى مستوى بيانات Databricks وأيضا إزالة حقوق الوصول تلقائيا عندما يغادر فرد المؤسسة أو الشركة. لا يمكن أن يكون هذا هو الحال، إذا تم استخدام حسابات مستخدمين منفصلة في Azure Databricks. يجب إضافة فرق تطبيق البيانات إلى مساحة عمل Databricks في shared-product-rg و في shared-integration-rg. داخل Azure Databricks، يجب منح Can Restart فرق تطبيق البيانات حقوق الوصول إلى مجموعة محددة مسبقا لتكون قادرة على تشغيل أحمال العمل داخل مساحة العمل.

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

ملخص متطلبات التحكم في الوصول المستندة إلى الدور

لأغراض التنفيذ التلقائي لتوزيع مناطق البيانات المنتقل إليها، تحتاج إلى هذه الأدوار:

اسم الدور

الوصف

النطاق

مساهم منطقة DNS الخاصة

توزيع جميع مناطق DNS الخاصة لجميع خدمات البيانات في اشتراك واحد ومجموعة موارد. يجب أن يكون Private DNS Zone Contributor كيان الخدمة في مجموعة موارد DNS العمومية التي تم إنشاؤها أثناء توزيع منطقة هبوط إدارة البيانات. هذا الدور مطلوب لنشر سجلات A لنقاط النهاية الخاصة.

(نطاق مجموعة الموارد) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}

مساهم الشبكة

لإعداد تناظر الشبكة الظاهرية بين شبكة منطقة البيانات المنتقل إليها وشبكة منطقة إدارة البيانات المنتقل إليها، يحتاج كيان الخدمة إلى Network Contributor حقوق الوصول على مجموعة الموارد للشبكة الظاهرية البعيدة.

(نطاق مجموعة الموارد) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}

المسؤول عن وصول المستخدم

هذا الإذن مطلوب لمشاركة وقت تشغيل التكامل المستضاف ذاتيا الذي يتم نشره في integration-rg مجموعة الموارد مع مصانع البيانات الأخرى. كما يلزم تعيين Azure Data Factory والوصول إلى الهويات المدارة في Azure Synapse Analytics على أنظمة ملفات حساب التخزين المعنية.

(نطاق المورد) /subscriptions/{{dataLandingZone}subscriptionId}

ملاحظة

يمكن تقليل عدد تعيينات الأدوار في سيناريو الإنتاج. Network Contributor تعيين الدور مطلوب فقط لإعداد تناظر الشبكة الظاهرية بين منطقة إدارة البيانات المنتقل إليها ومنطقة البيانات المنتقل إليها. بدون هذا الاعتبار، لا تعمل دقة DNS. يتم إسقاط نسبة استخدام الشبكة الواردة والصادرة لأنه لا يوجد خط رؤية لجدار حماية Azure.

Private DNS Zone Contributor غير مطلوب أيضا إذا كان نشر سجلات DNS A لنقاط النهاية الخاصة تلقائيا من خلال نهج Azure مع deployIfNotExists التأثير. وينطبق الشيء نفسه على User Access Administrator لأنه يمكن أتمتة التوزيع باستخدام deployIfNotExists النهج.

تعيينات الأدوار لمنتجات البيانات

تعيينات الدور التالية مطلوبة لنشر منتج بيانات داخل منطقة هبوط البيانات:

اسم الدور

الوصف

النطاق

مساهم منطقة DNS الخاصة

توزيع جميع مناطق DNS الخاصة لجميع خدمات البيانات في اشتراك واحد ومجموعة موارد. يجب أن يكون Private DNS Zone Contributor كيان الخدمة في مجموعة موارد DNS العمومية التي تم إنشاؤها أثناء توزيع منطقة هبوط إدارة البيانات. هذا الدور مطلوب لنشر سجلات A لنقاط النهاية الخاصة المعنية.

(نطاق مجموعة الموارد) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}

مساهم

نشر جميع خدمات تدفق تكامل البيانات في مجموعة موارد واحدة ضمن اشتراك منطقة البيانات المنتقل إليها. يتطلب Contributor كيان الخدمة تعيين دور على مجموعة الموارد هذه.

(نطاق مجموعة الموارد) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}

مساهم الشبكة

لتوزيع نقاط النهاية الخاصة إلى الشبكة الفرعية Private Link المحددة، والتي تم إنشاؤها أثناء توزيع منطقة هبوط البيانات، يتطلب Network Contributor كيان الخدمة الوصول إلى تلك الشبكة الفرعية.

(نطاق الموارد التابعة) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"

الوصول إلى الموارد الأخرى

خارج Azure، سيتطلب فريقا Data Product وData Integration أيضا الوصول إلى مستودع لتخزين البيانات الاصطناعية للتعليمات البرمجية والتعاون بشكل فعال وطرح التحديثات والتغييرات باستمرار عبر CI/CD إلى بيئات أعلى. بالإضافة إلى ذلك، يجب توفير لوحة مشروع للسماح بالتطوير السريع وتخطيط الدورات المتكررة وتعقب المهام بالإضافة إلى ملاحظات المستخدم وطلبات الميزات.

وأخيرا، تتطلب أتمتة CI/CD إعداد اتصال ب Azure، والذي يتم في معظم الخدمات عبر مبادئ الخدمة. ومن ثم، ستحتاج الفرق إلى الوصول إلى مبدأ الخدمة لتحقيق الأتمتة داخل مشروعها.

إدارة الوصول إلى البيانات

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

بالنسبة لمنتجات البيانات في مستودعات بيانات Azure، ضع في اعتبارك استخدام قوائم التحكم في الوصول (ACLs). لمزيد من المعلومات، راجع نموذج التحكم في الوصول في Azure Data Lake Storage Gen2. يتم دعم استخدام Azure AD المرور مع قوائم التحكم في الوصول من قبل معظم خدمات Azure الأصلية، بما في ذلك التعلم الآلي من Microsoft Azure وAzure Synapse SQL بلا خادم وApache Spark ل Azure Synapse وAzure Databricks.

من المحتمل استخدام التخزين متعدد اللغات الآخر في التحليلات على نطاق السحابة. تتضمن الأمثلة قاعدة بيانات Azure ل PostgreSQL وقاعدة بيانات Azure ل MySQL وقاعدة بيانات Azure SQL ومثيل SQL المدار وتجمعات Azure Synapse SQL المخصصة. يمكن استخدامها من قبل فرق تطبيقات البيانات لتخزين منتجات البيانات.

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

يمنح هذا الأسلوب أيضا موقعا واحدا للإدارة ويسمح بمراجعة حقوق الوصول داخل Azure Graph.

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

الخطوات التالية