إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
هناك طرق مختلفة للاتصال ب SQL Server والمصادقة عليه باستخدام Power Apps. توضح هذه المقالة المفاهيم التي يمكن أن تكون مفيدة في تحديد كيفية الاتصال ب SQL Server باستخدام نهج أمان يطابق متطلبات تطبيقك.
مهم
تم إصدار ميزة الاتصالات الضمنية الآمنة في يناير 2024. تشجع Microsoft بشدة جميع التطبيقات التي تستخدم حاليا اتصالات ضمنية للتحويل إلى اتصالات ضمنية آمنة وإبطال الاتصالات المشتركة مع المستخدمين النهائيين.
الفرق بين الاتصالات الضمنية الصريحة والضمنية والآمنة
يتم إنشاء اتصال ب SQL Server كلما قمت بإنشاء تطبيق باستخدام Power Apps المتصل ب SQL Server. عند نشر مثل هذه التطبيقات ومشاركتها مع الآخرين، يتم نشر كل من التطبيق والاتصال لهؤلاء المستخدمين. بمعنى آخر، التطبيق والاتصال - كلاهما مرئي للمستخدمين الذين تتم مشاركة التطبيقات معهم.
يمكن أن يكون أسلوب المصادقة المستخدم لمثل هذه الاتصالات صريحا أو ضمنيا. يمكننا أيضا أن نقول إن مثل هذا الاتصال مشترك بشكل صريح أو ضمني.
- يعني الاتصال المشترك صراحة أنه يجب على المستخدم النهائي للتطبيق المصادقة على SQL Server باستخدام بيانات الاعتماد الصريحة الخاصة به. عادة ما تحدث هذه المصادقة خلف الكواليس كجزء من تأكيد اتصال مصادقة Microsoft Entra أو Windows. لا يلاحظ المستخدم حتى عند إجراء المصادقة.
- يعني الاتصال المشترك ضمنيا أن المستخدم يستخدم ضمنيا بيانات اعتماد الحساب الذي استخدمه صانع التطبيق للاتصال بمصدر البيانات ومصادقته أثناء إنشاء التطبيق. لا يتم استخدام بيانات اعتماد المستخدم النهائي للمصادقة. في كل مرة يقوم فيها المستخدم النهائي بتشغيل التطبيق، يستخدم بيانات الاعتماد التي أنشأ الكاتب التطبيق بها.
- يشير الاتصال المشترك الآمن ضمنيا إلى سيناريو يستخدم فيه المستخدم النهائي للتطبيق ضمنيا بيانات اعتماد الحساب التي استخدمها صانع التطبيق للاتصال بمصدر البيانات والمصادقة عليه أثناء إنشاء التطبيق. وهذا يعني أن بيانات اعتماد المستخدم النهائي لا تستخدم للمصادقة. بدلا من ذلك، عندما يقوم المستخدم بتشغيل التطبيق، فإنه يستخدم بيانات الاعتماد التي أنشأها كاتب التطبيق. من المهم ملاحظة أنه لا يتم تزويد المستخدم النهائي بالوصول المباشر إلى الاتصال، ويسمح التطبيق فقط بالوصول إلى مجموعة محدودة من الإجراءات والجداول.
يمكن استخدام أنواع مصادقة الاتصال الأربعة التالية مع SQL Server ل Power Apps:
| نوع المصادقة | أسلوب اتصال Power Apps |
|---|---|
| Microsoft Entra Integrated | صريح |
| مصادقة SQL Server | ضمني / ضمني آمن |
| مصادقة Windows | ضمني / ضمني آمن |
| مصادقة Windows (غير المشتركة) | صريح |
مخاطر مشاركة الاتصال الضمنية
تستخدم جميع التطبيقات الجديدة تلقائيا الاتصالات الضمنية الآمنة الجديدة. ومع ذلك، مع التطبيقات التي تستخدم "الاتصالات الضمنية" القديمة، يتم نشر كل من التطبيق واتصالاته للمستخدمين النهائيين، فهذا يعني أنه يمكن للمستخدمين النهائيين تأليف تطبيقات جديدة استنادا إلى تلك الاتصالات.
عندما يستخدم الكاتب اتصالات ضمنية آمنة، فهذا يعني أنه لا يتم مشاركة أي اتصال ولا يتلقى أي مستخدم كائن الاتصال. هذا يلغي خطر إعادة مستخدم كاتب اتصال لإنشاء تطبيق جديد. بدلا من ذلك، يعمل التطبيق مع اتصال وكيل على علم بالتطبيق ويتواصل فقط مع هذا التطبيق المحدد. يسمح اتصال الوكيل بإجراءات محدودة (إنشاء وقراءة وتحديث وحذف) والوصول إلى جداول معينة في التطبيق يتم تعريفها عند نشر التطبيق. لذلك، يتم منح الإجراءات المصرح بها والوصول فقط للمستخدم النهائي.
يقوم الاتصال الضمني البسيط للنمط القديم بتوزيع كائن اتصال فعليا على المستخدم النهائي. على سبيل المثال، إذا قمت بإنشاء تطبيق يقوم بتصفية البيانات التي لا تريد أن يراها المستخدمون. ولكن البيانات المصفاة موجودة في قاعدة البيانات. ولكنك تعتمد على عامل التصفية الذي قمت بتكوينه لضمان عدم رؤية المستخدمين النهائيين لبيانات معينة.
مرة أخرى، مع الاتصالات الضمنية البسيطة ذات النمط القديم، بعد نشر التطبيق، يمكن للمستخدمين النهائيين استخدام الاتصال المنشور مع تطبيقك في أي تطبيقات جديدة يقومون بإنشائها. في التطبيقات الجديدة، يمكن للمستخدمين رؤية البيانات التي قمت بتصفيتها في التطبيق الخاص بك. من المهم استخدام الاتصالات الضمنية الآمنة الجديدة.
مهم
بمجرد نشر اتصال مشترك ضمنيا أقدم للمستخدمين النهائيين، فإن القيود التي قد تكون وضعتها في التطبيق الذي شاركته (مثل عوامل التصفية أو الوصول للقراءة فقط) لم تعد صالحة للتطبيقات الجديدة التي ينشئها المستخدمون النهائيون. سيكون للمستخدمين النهائيين أي حقوق تسمح بها المصادقة كجزء من الاتصال المشترك ضمنيا. لذلك، عند تحويل تطبيق لاستخدام اتصالات ضمنية آمنة، يجب عليك أيضا إبطال الاتصالات التي شاركتها مع تطبيقك. يمكن للمسؤولين الحصول على تقرير عن التطبيقات ذات الاتصالات المشتركة ضمنيا مع مجموعة أدوات COE.
أمان العميل والخادم
لا يمكنك الاعتماد على أمان البيانات من خلال التصفية أو العمليات الأخرى من جانب العميل لتكون آمنة. يجب أن تضمن التطبيقات التي تتطلب تصفية آمنة للبيانات حدوث كل من تعريف المستخدم وتصفيته على الخادم.
استخدم خدمات مثل معرف Microsoft Entra بدلا من الاعتماد على عوامل التصفية المصممة داخل التطبيقات عندما يتعلق الأمر بهوية المستخدم والأمان. يضمن هذا التكوين عمل عوامل التصفية من جانب الخادم كما هو متوقع.
توضح الرسوم التوضيحية التالية كيف تختلف أنماط الأمان داخل التطبيقات بين نماذج الأمان من جانب العميل والخادم.
في نمط تطبيق أمان العميل، [1] يصادق المستخدم فقط على التطبيق على جانب العميل. ثم [2] يطلب التطبيق معلومات الخدمة، و[3] تقوم الخدمة بإرجاع المعلومات استنادا إلى طلب البيانات فقط.
في نمط أمان من جانب الخادم، [1] يقوم المستخدم أولا بالمصادقة على الخدمة بحيث يكون المستخدم معروفا للخدمة. ثم، [2] عند إجراء استدعاء من التطبيق، تستخدم الخدمة [3] الهوية المعروفة للمستخدم الحالي لتصفية البيانات بشكل مناسب و[4] ترجع البيانات.
سيناريوهات المشاركة الضمنية للأقسام الموضحة أعلاه هي مزيج من هذين النمطين. يجب على المستخدم تسجيل الدخول إلى خدمة Power Apps باستخدام بيانات اعتماد Microsoft Entra. هذا السلوك هو نمط تطبيق أمان الخادم. يعرف المستخدم باستخدام هوية Microsoft Entra على الخدمة. ومن ثم، يقتصر التطبيق على مجموعة المستخدمين الذين شارك Power Apps التطبيق إليه رسميا.
ومع ذلك، فإن الاتصال المشترك الضمني ب SQL Server هو نمط تطبيق أمان العميل. يعرف SQL Server فقط أنه يتم استخدام اسم مستخدم وكلمة مرور محددين. يمكن تجاوز أي تصفية من جانب العميل، على سبيل المثال، باستخدام تطبيق جديد باستخدام نفس اسم المستخدم وكلمة المرور.
لتصفية البيانات بشكل آمن على جانب الخادم، استخدم ميزات الأمان المضمنة في SQL Server مثل أمان مستوى الصف للصفوف، وأذونات الرفض لعناصر معينة (مثل الأعمدة) لمستخدمين محددين. يستخدم هذا الأسلوب هوية مستخدم Microsoft Entra لتصفية البيانات على الخادم.
استخدمت بعض خدمات الشركات الحالية نهجا حيث يتم التقاط هوية المستخدم في طبقة بيانات الأعمال بنفس الطريقة التي يستخدمها Microsoft Dataverse. في هذه الحالة، قد تستخدم طبقة العمل أو لا تستخدم ميزات الأمان على مستوى صف SQL Server ورفضها مباشرة. إذا لم يحدث ذلك، فغالبا ما يتم تمكين الأمان باستخدام الإجراءات أو طرق العرض المخزنة.
تستخدم طبقة العمل (على جانب الخادم) هوية مستخدم Microsoft Entra معروفة لاستدعاء إجراء مخزن ككيان SQL Server وتصفية البيانات. ومع ذلك، لا يتصل Power Apps حاليا بالإجراءات المخزنة. قد تستدعي طبقة الأعمال أيضا طريقة عرض تستخدم هوية Microsoft Entra ككيان SQL Server. في هذه الحالة، استخدم Power Apps للاتصال بطرق العرض بحيث تتم تصفية البيانات على جانب الخادم. قد يحتاج عرض طرق العرض فقط للمستخدمين إلى تدفقات Power Automate للتحديثات.