السيناريو الأول للحل: مقياس عمومي وإمكانية وصول آمنة للمصمم
في الوحدة السابقة، عملت من خلال سيناريو على مقياس عمومي لشبكة تسليم المحتوى. في هذه الوحدة، ستستعرض حلاً واحداً محتملاً وبعض العناصر الواجب مراعاتها.
أثناء استعراض الحل، يجب مقارنة الحل المُقدَم بالحل الذي أوجدته في الوحدة السابقة. في كثيرٍ من الأحيان، يُوجَد أكثر من حل صحيح لأي مشكلة، ولكن هناك دائماً مفاضلات. ما العناصر الموجودة في حلك والتي تختلف عن تلك الموجودة في الحل المقترح؟ هل هناك أي شيء في حلك قد تعيد التفكير فيه؟ هل هناك أي شيء في الحل المُقدَم تعتقد أنه جرى تناوله بصورة أكثر شمولاً في حلك؟
خيار التوزيع والتكوين
القرار الأول الذي يجب مراعاته هو أي خيارات توزيع Azure SQL يجب عليك تحديده. على الرغم من أن SQL Server في جهاز ظاهري لخدمة Azure (VM) سينجح، قد يتيح عرض النظام الأساسي كخدمة (PaaS) تقديم ملائمة أفضل بتكاليف إدارية أقل.
يستخدم العميل وقت تشغيل اللغة العامة (CLR)، وهو ميزة ذات نطاق مثيل. إن ميزة مثيل Azure SQL المُدار هي خيار نشر النظام الأساسي كخدمة (PaaS) الوحيد الذي يدعم ميزات ذات نطاق مثيل مثل CLR وService Broker وقاعدة بيانات البريد الإلكتروني. لهذا السبب، يمكن أن يسمح مثيل Azure SQL المُدار للعميل بالانتقال إلى عرض النظام الأساسي كخدمة (PaaS) دون الحاجة إلى إعادة كتابة تطبيقات CLR الخاصة به في حل متوافق مع قاعدة بيانات Azure SQL (مثل وظائف قاعدة البيانات المرنة).
القرار التالي المفترض اتخاذه ينطوي على مستوى الخدمة. لأن العميل يريد الفصل بين حِمل القراءة وحِمل الكتابة الخاص به، فإن استخدام مستوى الخدمات الأساسية للأعمال سيكون أبسط طريقة لتحقيق ذلك. يشتمل مستوى الخدمات الأساسية للأعمال على مجموعة قابلية وصول عالية التوفر تعمل في سرية. يمكن استخدام إحدى النُسخ المماثلة الثانوية هذه لأحمال القراءة فقط.
تعتبر الأعمال الأساسية نصف التكوين هنا لفصل أحمال العمل الخاصة بالقراءة والكتابة. ينص السيناريو على أن العميل يحتاج إلى أن يكون قادراً على التوسع في مناطق متعددة مع ورود استعلامات متعددة في الوقت نفسه، مع فصل حِمل القراءة عن حِمل الكتابة.
الخياران اللذان بإمكانهما مواجهة هذا التحدي هما مجموعات النسخ الجغرافي المتماثل وتجاوز الفشل التلقائي. ومع ذلك، فإن النسخ المتماثل الجغرافي غير مُدَّعم حالياً في مثيل Azure SQL المُدار. ولذلك، فإن استخدام مجموعة تجاوز الفشل التلقائي هو الخيار الوحيد الذي يمكن أن يساعد هذا السيناريو في الحصول على مقياس قراءة عمومي.
نظراً لأن العميل يستخدم مجموعات تجاوز الفشل التلقائي، فسيعتمد ما إذا كان يحتاج إلى مستوى من الخدمات الأساسية للأعمال أم لا على عدد نقاط النهاية للقراءة فقط التي يتطلبها حِمل عمل تحليلاته. مع مجموعة تجاوز الفشل التلقائي في مستوى الخدمات الأساسية للأعمال، سيحصل العميل على ثلاث نقاط نهاية قابلة للقراءة:
- نسخة مماثلة ثانوية واحدة من مجموعة قابلية الوصول عالية التوفر في المنطقة الأساسية
- النسخة الثانوية لمجموعة تجاوز الفشل (وهي النسخة المماثلة الأساسية لقاعدة البيانات في المنطقة الثانوية)
- النسخة المماثلة الثانوية من مجموعة قابلية وصول عالية التوفر في المنطقة الثانوية
إذا كان حِمل عمل التحليلات لا يحتاج إلى كل هذه النسخ المماثلة المقروءة، فقد يكون استخدام الغرض العام حلاً أكثر فعالية من حيث التكلفة.
تحديد طرق المصادقة الأنسب
يتضمن الجزء الآخر من هذا السيناريو تحديد أفضل طريقة لكل تطبيق أو شخص للاتصال بالحل، نظراً للحاجة إلى إنشاء واستخدام أكثر التقنيات الممكنة أماناً. إذا قسَّمت السيناريو، فسيحتاج أربعة عملاء منفصلين الوصول إلى مثيل Azure SQL المُدار:
- تطبيق قيد التشغيل على جهاز Azure الافتراضي
- تطبيق قيد التشغيل على جهاز غير متصل بخدمة Azure مرتبط بالمجال
- محللو قواعد البيانات (DBAs) أو المستخدمون الآخرون لأدوات مسؤول SQL (SQL Server Management Studio، وAzure Data Studio، وPowerShell) من جهاز غير متصل بخدمة Azure مرتبط بالمجال
- التطبيقات القديمة التي تعمل على جهاز غير متصل بخدمة Azure حيث لا يمكنك تغيير برنامج تشغيل الجهاز أو سلسلة الاتصال
لنلقِ نظرةً على هؤلاء العملاء من حيث كيفية اختيار طريقة المصادقة وبعض الاعتبارات والقيود الإضافية.
تطبيق قيد التشغيل على جهاز Azure الافتراضي
الهويات المُدارة لمصادر Azure هي عموماً ذلك الشكل من المصادقة الذي لا يتطلب كلمة مرور والمُستحسن للتطبيقات التي تعمل على الأجهزة الظاهرية لخدمة Azure.
تطبيق قيد التشغيل على جهاز غير متصل بخدمة Azure مرتبط بالمجال
بالنسبة إلى الأجهزة غير المتصلة بخدمة Azure، لا يعد استخدام الهويات المُدارة خياراً. المصادقة المتكاملة عبر معرف Microsoft Entra هي طريقة المصادقة الموصى بها للتطبيقات التي تعمل على الأجهزة المرتبطة بالمجال خارج Azure، على افتراض أن المجال قد تم توحيده مع معرف Microsoft Entra.
إذا لم يكن الجهاز غير المتصل بخدمة Azure غير مرتبط بالمجال، يمكنك:
- إنشاء هوية تطبيق لتطبيقك في معرف Microsoft Entra.
- إقران شهادة مع هوية التطبيق.
- تعديل تطبيقك للحصول على رمز مميز لقاعدة بيانات SQL Azure عن طريق تقديم معرّف العميل وشهادة.
على الرغم من أن الشهادة يجب أن تحتوي على مفتاح خاص ويجب نشرها على الجهاز الذي يستضيف تطبيقك، على الأقل تجنب الترميز المضمن لبيانات التطبيق السرية في التعليمات البرمجية للتطبيق أو تكوينه. (ستحتاج إلى تكوين التطبيق باستخدام بصمة الإبهام الخاصة بالشهادة.)
محللو قواعد البيانات (DBAs) أو المستخدمون الآخرون لأدوات مسؤول SQL من جهاز غير متصل بخدمة Azure غير مرتبط المجال
بالنسبة للمستخدمين خارج Azure، فإن التخلص من استخدام كلمات المرور هو الأفضل إذا كان ذلك ممكناً. يمكنك إزالة استخدام كلمات المرور مع أدوات SQL باستخدام مصادقة Microsoft Entra المتكاملة. ومع ذلك، يجب تشغيل الأدوات على جهاز مرتبط بالمجال، ويجب أن يكون المجال قد تم توحيده مع معرف Microsoft Entra، وهو ما لا ينطبق على هذا السيناريو.
نظرا لأن البيئة لا تفي بالمتطلبات الأساسية للمصادقة المتكاملة، نوصي باستخدام مصادقة Microsoft Entra التفاعلية مع المصادقة متعددة العوامل، والتي تدعمها معظم أدوات SQL.
التطبيقات القديمة التي تعمل على جهاز غير متصل بخدمة Azure حيث لا يمكنك تغيير برنامج تشغيل الجهاز أو سلسلة الاتصال
في السيناريوهات التي لا يمكن فيها تغيير برنامج التشغيل أو سلسلة الاتصال، ليس هناك خيار متاح اليوم للتخلص من كلمات المرور. يجب أن تستمر هذه التطبيقات القديمة في استخدام مصادقة SQL. قد تفكر في التعمق أكثر في القيود وكيف يمكن التخلص منها من أجل استخدام نهج أكثر أماناً وحمايةً للتطبيقات للمصادقة.