السيناريو الثاني للحل - التطبيقات ذات المهام الحرجة
في الوحدة السابقة، عملت من خلال سيناريو تتضمن قابلية وصول عالية لنظام إفادة الطوارئ 911. في هذه الوحدة، ستستعرض حلاً واحداً محتملاً وبعض العناصر الأخرى الواجب مراعاتها.
أثناء استعراض الحل، يجب مقارنة الحل المُقدَم بالحل الذي أوجدته في الوحدة السابقة. في كثيرٍ من الأحيان، يُوجَد أكثر من حل صحيح لأي مشكلة، ولكن هناك دائماً مفاضلات. ما العناصر الموجودة في حلك والتي تختلف عن تلك الموجودة في الحل المقترح؟ هل هناك أي شيء في حلك قد تعيد التفكير فيه؟ هل هناك أي شيء في الحل المُقدَم تعتقد أنه جرى تناوله بصورة أكثر شمولاً في حلك؟
خيار التوزيع والتكوين
غالباً ما يكون التحديد الأول في معالجة السيناريو هو تحديد خيار نشر Azure SQL الذي من المحتمل أن يكون هو الأفضل. إذا كنت تفكر في اتفاقية على مستوى الخدمة (SLA) وحدها، فالمتطلب هو اتفاقية على مستوى الخدمة (SLA) بنسبة 99.995 بالمائة، والتي يمكن أن تقدمها قاعدة بيانات Azure SQL فقط. للحصول على تلك الاتفاقية على مستوى الخدمة، يجب عليك نشر مستوى الخدمات الأساسية للأعمال وتمكين استخدام مناطق الإتاحة.
وهناك مجموعة أخرى من القرارات تتعلق بكيفية تمكين التكرار الجغرافي والحفاظ على قابلية وصول عالية في حالات الكوارث. على الرغم من أن مجموعات النسخ الجغرافي المتماثل وتجاوز الفشل التلقائي كلاهما خيارين هنا، فإن مجموعات تجاوز الفشل التلقائي ستمكِّن العميل من تجاوز الفشل إذا لزم الأمر دون أي تغيير بسلاسل اتصال. يمكن أن يساعد هذا الإعداد على تقليل وقت التعطل لتحديث سلاسل اتصال التطبيقات، لأنه لن تكون هناك حاجة إليه. يمكنك أيضاً تكوين استعلامات المراقبة للتحقق من الحالة. بهذه الطريقة، إذا وقع خطأ ما، يمكنك حتى فرض تجاوز الفشل.
في هذا التكوين، من المهم أيضاً التفكير في الدور الذي يلعبه التوصيل الشبكي. للحفاظ على قابلية وصول عالية، يجب أن يكون تطبيقك أقرب ما يمكن من قاعدة بياناتك، وبالتأكيد في المنطقة نفسها. ستحتاج إلى التأكد من نشر تطبيقك في كلا منطقتي مجموعة تجاوز الفشل التلقائي، لذلك توجد نسخة مكررة من التطبيق (على سبيل المثال، تطبيق ويب). إذا كان هناك تجاوز للفشل، يمكنك استخدام Azure Traffic Manager لإعادة توجيه نسبة استخدام الشبكة إلى التطبيق في المنطقة الثانوية.
محللو قواعد البيانات (DBAs) والبيانات الحساسة
وقد أعرب منسقو نظام إفادة الطوارئ 911 عن قلقهم بشأن حماية البيانات الحساسة (مثل التاريخ الصحي والمعلومات الشخصية الأخرى)، مع السماح لمحللي قواعد البيانات (DBAs) بالقيام بعملهم.
للتأكد من أن محللي قواعد البيانات (DBAs) لا يمكنهم رؤية البيانات الحساسة المخزنة في أعمدة معينة ومن مراقبة كافة الوصول إلى الجداول التي تحتوي على بيانات حساسة، يمكنك استخدام بعض تقنيات SQL Azure. استخدام SQL Audit هو أفضل ممارسة لمراقبة الوصول ولكن سيظل محللو قواعد البيانات (DBAs) غير قادرين على رؤية البيانات. سيساعد تصنيف البيانات الحساسة باستخدام Data Classification حيث ستُسمى البيانات الحساسة ويمكنك تعقبها باستخدام SQL Audit. ومع ذلك، مع تنفيذها، سيظل محللو قواعد البيانات (DBAs) غير قادرين على رؤية البيانات الحساسة. يمكنك استخدام إخفاء البيانات الديناميكي للمساعدة على إخفاء البيانات الحساسة، ولكن من غير الممكن منع db_owner من عرض بيانات المستخدم باستخدام الأذونات فقط.
إذا كانت البيانات الموجودة في قاعدة البيانات شديدة الحساسية، يمكنك استخدام خاصية "Always Encrypted" لمنع حتى db_owners من رؤيتها بأمان. يمكنك إدارة مفاتيح Always Encrypted مع فصل الدور، بحيث لا يمكن لمسؤول الأمان الوصول إلى قاعدة البيانات ولا يمكن لمحلل قواعد البيانات (DBA) الوصول إلى المفاتيح الفعلية في النص غير المشفر. باستخدام هذه الاستراتيجية جنباً إلى جنب مع المراقبة من خلال SQL Audit، يمكنك مراقبة الوصول إلى البيانات الحساسة وإخفائها وتعقبها، حتى من محللي قواعد البيانات (DBAs) الذين يتمتعون بحقوق db_owner.
يحتاج محللو قواعد البيانات (DBAs) إلى إخفاء بيانات حساسة، لكنهم ما زالوا بحاجة إلى أن يكونوا قادرين على استكشاف أخطاء الأداء وإصلاحها باستخدام مدخل Microsoft Azure وSQL Server Management Studio أو Azure Data Studio. ويجب أن يكونوا قادرين على إنشاء مستخدمي قاعدة بيانات مضمنين جدد يجب تعيينهم إلى أساسيات Microsoft Entra.
أحد الحلول هو إنشاء مجموعة Microsoft Entra تسمى SQL DBA لDBAs على كل مثيل. بعد ذلك، عيِّن المجموعة إلى دور Azure للتحكم في الوصول المستند إلى الدور (RBAC) من أجل SQL Server Contributor. وأخيرا، يمكنك تعيين المجموعة لتكون مسؤول Microsoft Entra على الخادم المنطقي.