تأمين بوابة Power Pages الخاصة بك: تعمّق في أذونات الجداول ونطاقاتها

By Mirko Peters · 2026-08-11

مرحبًا بعودتكم إلى مدونة البودكاست! عند بناء تطبيقات ويب موجّهة للعملاء على منصة Microsoft Power Platform، لا يمكن أن يكون الأمن أمرًا ثانويًا. فـ Power Pages أداة رائعة لنشر بوابات خارجية قوية بسرعة، ومتصلة مباشرةً بـ Dataverse. غير أن القوة الكبيرة تأتي مع مسؤولية كبيرة، وتحديدًا مسؤولية التأكد من أن البيانات الحساسة لمؤسستكم لا تتسرب عن طريق الخطأ إلى العامة أو تتجاوز حدود المؤسسة.

Automatically translated with AI from the original post. Read the English original

مرحبًا بعودتكم إلى مدونة البودكاست! عند بناء تطبيقات ويب موجّهة للعملاء على منصة Microsoft Power Platform، لا يمكن أن يكون الأمن أمرًا ثانويًا. فـ Power Pages أداة رائعة لنشر بوابات خارجية قوية بسرعة، ومتصلة مباشرةً بـ Dataverse. غير أن القوة الكبيرة تأتي مع مسؤولية كبيرة، وتحديدًا مسؤولية التأكد من أن البيانات الحساسة لمؤسستكم لا تتسرب عن طريق الخطأ إلى العامة أو تتجاوز حدود المؤسسة.

في هذا المقال، سنتوسع بشكل كبير في مفاهيم الأمن المعمارية الأساسية التي ناقشناها في حلقتنا الأخيرة. إن لم تستمعوا إليها بعد، فتأكدوا من الاطلاع على حلقة Build Customer Portals with Power Pages and Dataverse لتجدوا شرحًا كاملًا لإعداد البيئة، وإدارة الهويات الخارجية، ونشر أول حل للبوابة.

لنتعمّق في آليات أمن Power Pages، بدءًا من كيفية تخطيط حدود البيانات وإتقان أذونات الجداول.

مقدمة في أمن Power Pages

عند إنشاء موقع Power Pages لأول مرة، توفر المنصة مساحة عمل مرنة وقابلة للتخصيص بدرجة كبيرة. but تحت هذه المساحة يوجد خط اتصال مباشر ببيئة Microsoft Dataverse الخاصة بكم. إذا أُسيئت إدارة إعدادات الأمان، فقد يتعرض كل سجل في قاعدة البيانات للكشف عبر نقطة نهاية غير مؤمنة أو عرض قائمة مُعدّ بنطاق غير محكم.

يعتمد الأمن في Power Pages على استراتيجية دفاع متعددة الطبقات. في الطبقة الخارجية توجد آليات المصادقة، مثل Azure AD B2C والحسابات المحلية أو موفري الهوية الخارجيين، والتي تضمن إثبات المستخدمين لهوياتهم. وفي الطبقة الداخلية توجد أدوار الويب وأذونات جداول Dataverse. تحدد هذه الأذونات بدقة ما يمكن للهويات الموثّقة رؤيته أو إنشاؤه أو تحديثه أو حذفه. والحرص على إعداد ذلك بشكل صحيح هو الفارق بين بوابة مؤسسية آمنة وخرق بيانات كبير ينتظر الحدوث.

تخطيط حدود البيانات وأذونات الجداول

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

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

• نطاق جهة الاتصال: يمكن للمستخدم التفاعل فقط مع السجلات المرتبطة مباشرةً بسجل جهة الاتصال الخاص به.
• نطاق الحساب: يمكن للمستخدم التفاعل مع السجلات المرتبطة بشركته أو بالحساب بأكمله.
• النطاق العام: يمكن للمستخدم رؤية جميع السجلات في الجدول بأكمله (ويُخصّص عادةً لمقالات قاعدة المعرفة العامة أو البيانات الوصفية).

بتحديد هذه الحدود مبكرًا، ترسّخ خط أساس لمبدأ أقل الصلاحيات قبل بناء أي إعداد في بيئة التطوير لديك.

فهم الفرق بين نطاقي جهة الاتصال والحساب

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

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

من ناحية أخرى، صُمّم نطاق الحساب (Account Scope) لبنيات بوابات B2B. في سيناريو B2B، تريد أن يتمكن مدير الحسابات أو مسؤول المشتريات الرئيسي من عرض جميع الحالات والطلبات والفواتير المرتبطة بحساب الشركة الأم. عند تعيين نطاق Account إلى Table Permission، تقوم البوابة بتقييم حساب الأب المرتبط بسجل Contact الخاص بالمستخدم المسجَّل دخوله، ثم تعرض بعد ذلك جميع السجلات الفرعية المرتبطة التي تنتمي إلى تلك المؤسسة. ويُعد تعيين هذه العلاقة بشكل صحيح في Dataverse أمرًا حاسمًا لنجاح B2B.

تحديد أدوار الويب وتجنب مزلقة "Authenticated Users"

تمثل أدوار الويب (Web Roles) الجسر بين المستخدمين المصادَق عليهم وبين Table Permissions في Dataverse. تتضمن Power Pages افتراضيًا دورًا يُدعى "Authenticated Users". وهنا يقع كثير من المسؤولين في فخ أمني خطير.

بشكل افتراضي، أي مستخدم يسجّل الدخول بنجاح إلى بوابتك ينضم تلقائيًا إلى دور Authenticated Users. وإذا أرفقت بهذا الدور الافتراضي أذونات جداول واسعة، أو الأسوأ من ذلك أذونات بنطاق Global، فسيرث كل شخص يسجّل في موقعك تلك الصلاحيات الواسعة فورًا. وهذا نمط مضاد للأمان بالغ الخطورة.

بدلًا من ذلك، ينبغي أن تُنشئ أدوار ويب مخصصة ودقيقة تناسب الفئات المحددة من المستخدمين لديك. على سبيل المثال:

• CustomerUser: مرتبط بنطاق Contact للجداول التشغيلية مثل Cases وOrders، ويتيح للمستخدمين متابعة تفاعلاتهم الخاصة.
• AccountManager: مرتبط بنطاق Account، ويمنح القادة المعينين في المؤسسة إمكانية الاطلاع على أصول الشركة بأكملها.
• KnowledgeBaseViewer: مرتبط بنطاق Global، لكنه مقيّد بصرامة بإجراءات القراءة فقط على مقالات الدعم المتاحة للعموم.

أزل دائمًا الوصول الافتراضي غير الضروري، واحرص على أن يُسند المستخدمون صراحةً إلى أدوار مصممة لغرض محدد بناءً على علاقتهم بالمؤسسة.

تشديد إمكانية الرؤية على مستوى الحقول وحماية PII

التحكم في الوصول على مستوى الصفوف عبر نطاقات الجداول ليس سوى نصف المعركة. فأنت بحاجة أيضًا إلى الاهتمام بدقة بما يظهر داخل كل صف وكل قائمة. فكشف المعلومات الشخصية القابلة للتعريف (PII) مثل أرقام الهواتف وعناوين المنازل والتفاصيل المالية وملاحظات الموظفين الداخلية قد يؤدي إلى انتهاكات جسيمة للامتثال (مثل إخفاقات GDPR أو CCPA).

عند إنشاء القوائم والنماذج الأساسية في Power Pages، تأكد من تنقية عروضك من الأعمدة الحساسة. فكون الحقل مخفيًا في تخطيط النموذج الظاهر للمستخدم لا يعني أنه لا يمكن فحصه أو سحبه عبر واجهات برمجة التطبيقات (Web APIs) الأساسية إذا كانت الأذونات واسعة أكثر من اللازم. استخدم عروضًا منفصلة ومحصّنة (مثل عرض مخصص باسم "PublicView") لا يحتوي إلا على أعمدة آمنة ومنقّحة. وإذا كان لا بد من بقاء بعض الأعمدة في جدول قاعدة البيانات، فكّر في تطبيق أمان على مستوى الأعمدة في Dataverse لتقييد الوصول إليها بالكامل على مستوى محرك قاعدة البيانات.

اختبار الاختراق لأذونات البوابة

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

أنشئ حسابات مستخدمين تجريبية لكل دور ويب حددته. سجّل الدخول كمستخدم CustomerUser عادي وحاول عرض بيانات تعود إلى Contact أو Account آخر. جرّب التلاعب المباشر بعناوين URL والعبث بقيم GUID عبر استبدال معرّفات السجلات في شريط عنوان المتصفح، لترى هل يمنع الخادم الطلبات غير المصرح بها بشكل صحيح. علاوة على ذلك، راجع سجلات التشخيص والتدقيق في بوابتك للتحقق من أن محاولات تجاوز الصلاحيات تُفضي إلى استجابات 403 Forbidden مناسبة.

الخلاصة وأفضل الممارسات

تأمين بوابة Power Pages يتطلب تخطيطًا متعمدًا، والالتزام الصارم بمبدأ أقل الصلاحيات الممكنة، وفهمًا عميقًا لأذونات جداول Dataverse ونطاقاتها. فبالابتعاد عن الإعدادات الافتراضية الخطرة مثل دور Authenticated Users، وتحديد نطاق وصول الجداول بدقة على مستوى Contact أو Account، وتشديد إمكانية الرؤية على مستوى الحقول، يمكنك بناء بوابة عملاء عالية الكفاءة وآمنة بشكل استثنائي.

لاستكشاف هذا الموضوع بعمق أكبر والاطلاع على دليل تنفيذ كامل من البداية إلى النهاية، يشمل إعداد الهويات الخارجية وتصميم بنية الحل والتحضير للإطلاق، استمعوا إلى حلقتنا الصوتية المرافقة: Build Customer Portals with Power Pages and Dataverse. شكرًا لقراءتكم، وترقبوا المزيد من النصائح المتخصصة لإتقان Microsoft Power Platform!