Playbook لمعالجة متطلبات الأمان الشائعة مع قاعدة بيانات Azure SQL ومثيل Azure SQL المُدار

  • مقالة

ينطبق على: قاعدة بيانات Azure SQL مثيل Azure SQL المُدار

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

حل متطلبات الأمان الشائعة

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

عروض نشر قاعدة بيانات Azure SQL التي يغطيها هذا الدليل

عروض النشر غير المشمولة في هذا الدليل

  • Azure Synapse Analytics
  • الأجهزة الظاهرية في Azure SQL (خدمة تأجير البنية التحتية)
  • SQL Server

الجمهور

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

  • مهندسو تصميم الأمان
  • مديرو الأمان
  • موظفو التوافق
  • موظفو الخصوصية
  • مهندسو الأمان

استخدام هذا الدليل

هذا المستند مخصص كرفيق لتوثيق أمان قاعدة بيانات Azure SQL الموجودة لدينا.

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

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

المصادقة

المصادقة هي عملية إثبات أن المستخدم هو من يدعي أنه. تدعم قاعدة بيانات SQL Azure ومثيل SQL المدار نوعين من المصادقة:

  • مصادقة SQL.
  • مصادقة Azure Active Directory.

ملاحظة

مصادقة Microsoft Azure Active Directory قد لا تكون معتمدة لجميع الأدوات وتطبيقات الجهات الثالثة.

الإدارة المركزية للهويات

تقدم إدارة الهوية المركزية المزايا التالية:

  • إدارة حسابات المجموعة والتحكم في أذونات المستخدم دون تكرار تسجيلات الدخول عبر الخوادم وقواعد البيانات والمثيلات المدارة.
  • إدارة الأذونات بطريقة مبسطة ومرنة.
  • إدارة التطبيقات على نطاق واسع.

كيفية التنفيذ:

  • استخدام مصادقة Microsoft Azure Active Directory (Azure AD) لإدارة الهوية المركزية.

أفضل الممارسات:

  • إنشاء مستأجر Microsoft Azure Active Directory وإنشاء مستخدمين لتمثيل المستخدمين البشريين وإنشاء أساسيات الخدمة لتمثيل التطبيقات والخدمات وأدوات الأتمتة. يعادل مديرو الخدمات حسابات الخدمات في Windows وLinux.

  • تعيين حقوق الوصول إلى الموارد إلى أساسيات Microsoft Azure Active Directory عبر تعيين المجموعة: إنشاء مجموعات Microsoft Azure Active Directory ومنح حق الوصول إلى المجموعات وإضافة أعضاء فرديين إلى المجموعات. في قاعدة بياناتك، قم بإنشاء مستخدمي قاعدة البيانات المضمنة التي تعين مجموعاتك في Microsoft Azure Active Directory. لتعيين أذونات داخل قاعدة البيانات، ضع المستخدمين المقترنين بمجموعات Microsoft Azure Active Directory في أدوار قاعدة البيانات مع الأذونات المناسبة.

    ملاحظة

    في مثيل SQL المدار، يمكنك أيضاً إنشاء تسجيلات الدخول التي تعين أساسيات Microsoft Azure Active Directory في قاعدة البيانات الرئيسية. انظر CREATE LOGIN (Transact-SQL).

  • يؤدي استخدام مجموعات Microsoft Azure Active Directory إلى تبسيط إدارة الأذونات ويمكن لكل من مالك المجموعة، ومالك المورد إضافة/إزالة الأعضاء إلى/من المجموعة.

  • إنشاء مجموعة منفصلة لمسؤولي Microsoft Azure Active Directory لكل خادم أو مثيل مدار.

  • مراقبة تغييرات عضوية مجموعة Microsoft Azure Active Directory باستخدام تقارير نشاط تدقيق Microsoft Azure Active Directory.

  • فيما يخص مثيلاً مداراً، يلزم القيام بخطوة منفصلة لإنشاء مسؤول Microsoft Azure Active Directory.

ملاحظة

  • يتم تسجيل مصادقة Microsoft Azure Active Directory في سجلات تدقيق Azure SQL، ولكن ليس في سجلات تسجيل الدخول إلى Microsoft Azure Active Directory.
  • لا تنطبق أذونات Azure RBAC الممنوحة في Azure على Azure SQL Database أو أذونات المثيل المُدار من SQL. يجب إنشاء/تعيين هذه الأذونات يدوياً باستخدام أذونات SQL الموجودة.
  • من جانب العميل، تحتاج مصادقة Microsoft Azure Active Directory إلى الوصول إلى الإنترنت أو عبر المسار المحدد من قبل المستخدم (UDR) إلى شبكة ظاهرية.
  • الرمز المميز للوصول إلى Microsoft Azure Active Directory مخزن مؤقتاً من جانب العميل ويعتمد العمر الخاص به على تكوين الرمز المميز للوصول. راجع المقالة، أعمار الرمز المميز للوصول المكون في Microsoft Azure Active Directory
  • للحصول على إرشادات حول استكشاف أخطاء مصادقة Microsoft Azure Active Directory وإصلاحها، راجع المدونة التالية: استكشاف وإصلاح الأخطاء في Microsoft Azure Active Directory.

مصادقة Azure Active Directory متعددة العوامل

المشار إليه في: الممارسة OSA #2، التحكم في الوصول إلى ISO

تساعد المصادقة متعددة العوامل في Microsoft Azure Active Directory على توفير أمان إضافي من خلال طلب أكثر من نموذج مصادقة.

كيفية التنفيذ:

  • تمكين المصادقة متعددة العوامل في Microsoft Azure Active Directory باستخدام الوصول المشروط واستخدام المصادقة التفاعلية.

  • البديل هو تمكين المصادقة متعددة العوامل لـ Microsoft Azure Active Directory بالكامل أو Azure AD Domain.

أفضل الممارسات:

تقليل استخدام المصادقة المستندة إلى كلمة المرور للمستخدمين

المشار إليه في: الممارسة OSA #4، التحكم في الوصول إلى ISO

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

كيفية التنفيذ:

  • استخدم مصادقة Microsoft Azure Active Directory المتكاملة التي تلغي استخدام كلمات المرور.

أفضل الممارسات:

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

المشار إليه في: الممارسة OSA #4، التحكم في الوصول إلى ISO

كيفية التنفيذ:

  • تمكين الهوية المدارة في Azure. يمكنك أيضاً استخدام المصادقة المتكاملة أو المستندة إلى الشهادة.

أفضل الممارسات:

حماية كلمات المرور والبيانات السرية

بخصوص الحالات التي لا يمكن فيها تجنب كلمات المرور، تأكد من تأمينها.

كيفية التنفيذ:

  • استخدام Azure Key Vault لتخزين كلمات المرور والبيانات السرية. كلما أمكن، استخدم المصادقة متعددة العوامل لقاعدة بيانات Azure SQL مع مستخدمي Microsoft Azure Active Directory.

أفضل الممارسات:

  • إذا لم يكن تجنب كلمات المرور أو البيانات السرية ممكناً، فقم بتخزين كلمات مرور المستخدم وأسرار التطبيق في Azure Key Vault وإدارة الوصول من خلال نهج الوصول إلى Key Vault.

  • قد توفر الأطر المختلفة لتطوير التطبيق أيضاً آليات خاصة بكل إطار لحماية البيانات السرية في التطبيق. على سبيل المثال: ASP.NET core app.

استخدام مصادقة SQL في التطبيقات القديمة

تشير مصادقة SQL إلى مصادقة المستخدم عند الاتصال بقاعدة بيانات Azure SQL أو مثيل SQL المدار باستخدام اسم المستخدم وكلمة المرور. سوف تحتاج إلى إنشاء تسجيل الدخول في كل خادم أو مثيل مدار، وإنشاء مستخدم في كل قاعدة بيانات.

كيفية التنفيذ:

  • استخدم مصادقة SQL.

أفضل الممارسات:

إدارة الوصول

إدارة الوصول (وتسمى أيضاً التخويل) هي عملية التحكم في وصول المستخدمين المصرح لهم وامتيازاتهم إلى قاعدة بيانات Azure SQL أو مثيل SQL المدار وإدارتها.

تنفيذ مبدأ الامتياز الأقل

المشار إليه في: عناصر تحكم FedRamp AC-06، NIST: AC-6، الممارسة OSA 3#

ينص مبدأ الامتياز الأقل على أنه لا ينبغي أن يتمتع المستخدمون بامتيازات أكثر من اللازم لإكمال مهامهم. لمزيد من المعلومات، راجع المقال ما يكفي من الإدارة.

كيفية التنفيذ:

تعيين الأذونات الضرورية فقط لإكمال المهام المطلوبة:

  • في قواعد بيانات SQL:

    • استخدام الأذونات الدقيقة وأدوار قاعدة البيانات المحددة من قبل المستخدم (أو أدوار الخادم في مثيل SQL مُدار):
      1. إنشاء الأدوار المطلوبة
      2. إنشاء المستخدمين المطلوبين
      3. إضافة المستخدمين كأعضاء إلى الأدوار
      4. ثم تعيين الأذونات إلى الأدوار.
    • التأكد من عدم تعيين المستخدمين إلى أدوار غير ضرورية.

  • في Azure Resource Manager:

أفضل الممارسات:

الممارسات الأفضل التالية اختيارية ولكنها ستؤدي إلى إدارة ودعم أفضل لإستراتيجية أمانك:

  • إن أمكن، فابدأ بأقل مجموعة ممكنة من الأذونات وابدأ في إضافة الأذونات واحدة تلو الأخرى إذا كانت هناك ضرورة حقيقية (ومبرر) - ​​على عكس النهج المعاكس: إزالة الأذونات خطوة بخطوة.

  • الامتناع عن تعيين أذونات للمستخدمين الفرديين. استخدام الأدوار (أدوار قاعدة البيانات أو الخادم) باستمرار بدلاً من ذلك. تساعد الأدوار بشكل كبير في إعداد تقارير الأذونات واستكشاف الأخطاء وإصلاحها. (يدعم التحكم في الوصول استناداً إلى الدور في Azure تعيين الإذن فقط عبر الأدوار).

  • إنشاء واستخدام الأدوار المخصصة مع الأذونات المطلوبة بالتحديد. الأدوار النموذجية المستخدمة في الممارسة:

    • نشر الأمان
    • مسؤول
    • المطور
    • موظفو الدعم
    • المدقق
    • العمليات الآلية
    • المستخدم النهائي

  • استخدم الأدوار المضمنة فقط عندما تتطابق أذونات الأدوار تماماً مع الأذونات المطلوبة للمستخدم. يمكنك تعيين المستخدمين لأدوار متعددة.

  • تذكر أن الأذونات في محرك قاعدة البيانات يمكن تطبيقها ضمن النطاقات التالية (كلما كان النطاق أصغر كلما كان تأثير الأذونات الممنوحة أقل):

    ملاحظة

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

  • إجراء فحوصات منتظمة باستخدام تقييم الثغرة الأمنية (VA) لاختبار أذونات كثيرة جداً.

تنفيذ فصل الواجبات

المشار إليه في: FedRamp: AC-04، NIST: AC-5، ISO: A.6.1.2، PCI 6.4.2، SOC: CM-3، SDL-3

يصف فصل الواجبات، المعروف أيضاً باسم الفصل بين الواجبات، مطلب تقسيم المهام الحساسة إلى مهام متعددة يتم تعيينها لمستخدمين مختلفين. فصل الواجبات يساعد على منع خرق البيانات.

كيفية التنفيذ:

  • تحديد مستوى فصل الواجبات المطلوب. أمثلة:

    • بين بيئات التطوير/الاختبار والتشغيل
    • المهام الحساسة المتعلقة بالأمان مقابل مهام مستوى الإدارة لمسؤول قاعدة البيانات (DBA) مقابل مهام المطور.
      • أمثلة: المدقق، وإنشاء سياسة أمان للأمان على مستوى الدور (RLS)، وتنفيذ عناصر قاعدة بيانات SQL بأذونات لغة توصيف البيانات.

  • تحديد تدرج هرمي شامل للمستخدمين (والعمليات الآلية) الذين يصلون إلى النظام.

  • إنشاء الأدوار وفقاً لمجموعات المستخدمين المطلوبة وتعيين الأذونات للأدوار.

    • بالنسبة للمهام على مستوى الإدارة في مدخل Microsoft Azure أو عبر PowerShell-automation استخدم أدوار Azure. إما العثور على دور مضمن يطابق المتطلبات، وإما إنشاء دور مخصص في Azure باستخدام الأذونات المتاحة
    • إنشاء أدوار الخادم للمهام على مستوى الخادم (إنشاء تسجيلات دخول جديدة وقواعد بيانات) في مثيل مدار.
    • إنشاء أدوار قاعدة البيانات للمهام على مستوى قاعدة البيانات.

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

  • تنفيذ تشفير البيانات الشفاف (TDE) باستخدام مفاتيح يديرها العميل في Azure Key Vault لتمكين فصل الواجبات بين مالك البيانات ومالك الأمان.

  • للتأكد من أن مسؤول قاعدة البيانات (DBA) لا يمكنه رؤية البيانات التي تعتبر حساسة للغاية ولا يزال بإمكانه القيام بمهام مسؤول قاعدة البيانات (DBA)، يمكنك استخدام Always Encrypted مع فصل الأدوار.

  • في الحالات التي يكون فيها استخدام Always Encrypted غير ممكن، أو على الأقل لا يخلو من التكاليف والجهود الرئيسية التي قد تجعل النظام شبه غير قابل للاستخدام، يمكن أن يتم إجراء الاختراقات والتخفيف من حدتها من خلال استخدام عناصر تحكم تعويضية مثل:

أفضل الممارسات:

  • تأكد من استخدام حسابات مختلفة لبيئات التطوير/الاختبار والتشغيل. حسابات مختلفة تساعد على التوافق لفصل أنظمة الاختبار والتشغيل.

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

  • استخدم الأدوار المضمنة عندما تتطابق الأذونات تماماً مع الأذونات المطلوبة - إذا أدى اتحاد جميع الأذونات من عدة أدوار مضمنة إلى تطابق بنسبة 100٪، فيمكنك أيضاً تعيين أدوار متعددة بشكل متزامن.

  • إنشاء واستخدام أدوار المستخدم المعرفة عندما تمنح الأدوار المضمنة أذونات كثيرة جداً أو أذونات غير كافية.

  • يمكن أيضاً القيام بمهام الدور مؤقتاً، والمعروف أيضاً باسم الفصل الديناميكي للواجبات (DSD)، إما ضمن خطوات وظيفة عامل SQL في T-SQL أو باستخدام Azure PIM لأدوار Azure.

  • تأكد من أن مسؤولي قاعدة البيانات (DBAs) لا يملكون حق الوصول إلى مفاتيح التشفير أو مخازن المفاتيح، وأن مسؤولي الأمان الذين لديهم حق الوصول إلى المفاتيح ليس لديهم حق الوصول إلى قاعدة البيانات بدورهم. يمكن أن يؤدي استخدام إدارة المفاتيح القابلة للتوسيع (EKM) إلى تسهيل تحقيق هذا الفصل. يمكن استخدام Azure Key Vault لتنفيذ إدارة المفاتيح القابلة للتوسيع (EKM).

  • تأكد دائماً من وجود سجل التدقيق للإجراءات المتعلقة بالأمان.

  • يمكنك استرداد تعريف الأدوار المضمنة في Azure للاطلاع على الأذونات المستخدمة وإنشاء دور مخصص استناداً إلى مقتطفات وتراكمات منها عبر PowerShell.

  • نظراً لأن أي عضو في دور قاعدة بيانات db_owner يمكنه تغيير إعدادات الأمان مثل تشفير البيانات الشفافة (TDE)، أو تغيير SLO، يجب منح هذه العضوية بعناية. ومع ذلك، هناك العديد من المهام التي تتطلب امتيازات db_owner. مهمة مثل تغيير أي إعداد في قاعدة البيانات مثل تغيير خيارات قاعدة البيانات. يلعب التدقيق دوراً رئيسياً في أي حل.

  • لا يمكن تقييد أذونات db_owner، وبالتالي منع حساب إداري من عرض بيانات المستخدم. إذا كانت هناك بيانات حساسة للغاية في قاعدة بيانات، يمكن استخدام "Always Encrypted" لمنع db_owners أو أي مسؤول قاعدة بيانات آخر من عرضها بأمان.

ملاحظة

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

بالنسبة للقراء الذين يرغبون في الغوص بشكل أعمق في فصل الواجبات (SoD)، نوصي بالموارد التالية:

إجراء استعراض التعليمة البرمجية بانتظام

المشار إليه في: PCI: 6.3.2، SOC: SDL-3

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

كيفية التنفيذ:

  • استخدم أداة قاعدة بيانات مثل Azure Data Studio التي تدعم التحكم في المصدر.

  • تنفيذ عملية نشر التعليمة البرمجية المنفصلة.

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

أفضل الممارسات:

  • التوحيد القياسي: يساعد في تنفيذ إجراء قياسي يجب اتباعه لأي تحديثات في التعليمة البرمجية.

  • يحتوي تقييم الثغرات الأمنية على القواعد التي تتحقق من الأذونات الزائدة، واستخدام خوارزميات التشفير القديمة، ومشاكل الأمان الأخرى داخل مخطط قاعدة البيانات.

  • يمكن إجراء المزيد من الفحوصات في بيئة ضمان الجودة أو الاختبار باستخدام الحماية المتقدمة من التهديدات التي تفحص بحثاً عن التعليمة البرمجية الأكثر عرضة لهجوم SQL.

  • أمثلة على ما يجب البحث عنه:

    • إنشاء مستخدم أو تغيير إعدادات الأمان من داخل النشر التلقائي لتحديث التعليمة البرمجية لـ SQL.
    • إجراء مخزن يقوم بناءً على المعلمات المتوفرة، بتحديث قيمة نقدية في خلية بطريقة غير مطابقة.

  • تأكد من أن الشخص الذي يجري المراجعة هو شخص آخر غير مؤلف التعليمة البرمجية الأصلية وعلى دراية باستعراض التعليمة البرمجية والتشفير الآمن.

  • تأكد من معرفة جميع مصادر تغييرات التعليمة البرمجية. يمكن أن تكون التعليمة البرمجية في البرامج النصية T-SQL. يمكن أن تكون أوامر مخصصة يتم تنفيذها أو نشرها في نماذج مثل العروض والوظائف والمشغلات والإجراءات المخزنة. يمكن أن يكون جزءاً من تعريف مهمة عامل SQL (خطوات). كما يمكن تنفيذها من داخل حزم SSIS، ومصنع بيانات Azure، وغيرها من الخدمات.

حماية البيانات

حماية البيانات هي مجموعة من القدرات لحماية المعلومات المهمة من الاختراق عن طريق التشفير أو التعتيم.

ملاحظة

تشهد Microsoft إلى قاعدة بيانات SQL Azure ومثيل SQL المدار على أنهما متوافقان مع FIPS 140-2 المستوى 1. يتم ذلك بعد التحقق من الاستخدام الصارم لخوارزميات FIPS 140-2 المستوى 1 المقبولة ومثيلات FIPS 140-2 المستوى 1 المصادق عليها لتلك الخوارزميات بما في ذلك الاتساق مع أطوال المفاتيح المطلوبة وإدارة المفاتيح وإنشاء المفاتيح وتخزين المفاتيح. يهدف هذا التصديق إلى السماح لعملائنا بالاستجابة للحاجة أو المتطلبات لاستخدام مثيلات FIPS 140-2 المستوى 1 المصادق عليها في معالجة البيانات أو تسليم الأنظمة أو التطبيقات. نحدد المصطلحين "متوافق مع FIPS 140-2 المستوى 1" و"التوافق مع FIPS 140-2 المستوى 1" المستخدم في البيان أعلاه لإثبات قابليتهما للتطبيق على استخدام الحكومة الأمريكية والكندية للمصطلح المختلف "FIPS 140-2 المستوى 1 الذي تم التحقق من صحته."

تشفير البيانات عند النقل

المشار إليه في: الممارسة OSA #6، التحكم في العائلة ISO: التشفير

يحمي بياناتك أثناء انتقال البيانات بين العميل والخادم. انتقل إلى أمان الشبكة.

تشفير البيانات الثابتة

المشار إليه في: الممارسة OSA #6، التحكم في العائلة ISO: التشفير

تشفير البيانات الثابتة هو الحماية المشفرة للبيانات عند استمرارها في ملفات قاعدة البيانات والسجل وملفات النسخة الاحتياطية.

كيفية التنفيذ:

  • يتم تمكين تشفير قاعدة البيانات الشفافة (TDE) باستخدام المفاتيح المُدارة للخدمة بشكل افتراضي لأي قواعد بيانات تم إنشاؤها بعد عام 2017 في قاعدة بيانات Azure SQL ومثيل SQL المُدار.
  • في مثيل مدار، إذا تم إنشاء قاعدة البيانات من عملية استعادة باستخدام خادم محلي، فسيتم تطبيق إعداد TDE لقاعدة البيانات الأصلية. إذا لم يتم تمكين TDE في قاعدة البيانات الأصلية، فإننا نوصي بتشغيل TDE بشكل يدوي للمثيل المُدار.

أفضل الممارسات:

  • لا تخزن البيانات التي تتطلب تشفير البيانات الثابتة في قاعدة البيانات الرئيسية. لا يمكن تشفير قاعدة البيانات الرئيسية باستخدام TDE.

  • استخدم المفاتيح المُدارة بواسطة العميل في Azure Key Vault إذا كنت بحاجة إلى مزيد من الشفافية والتحكم الدقيق في حماية TDE. يتيح Azure Key Vault القدرة على إبطال الأذونات في أي وقت لجعل قاعدة البيانات غير قابلة للوصول. يمكنك إدارة حماة TDE مركزياً جنباً إلى جنب مع المفاتيح الأخرى، أو تدوير واقي TDE وفقاً لجدولك الخاص باستخدام Azure Key Vault.

  • إذا كنت تستخدم مفاتيح يديرها العميل في Azure Key Vault، فاتبع المقالات وإرشادات تكوين TDE باستخدام Azure Key Vault وكيفية تكوين Geo-DR باستخدام Azure Key Vault.

ملاحظة

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

حماية البيانات الحساسة المستخدمة من المستخدمين ذوي الامتيازات العالية وغير المصرح لهم

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

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

كيفية التنفيذ:

  • استخدام Always Encrypted لضمان عدم عرض البيانات الحساسة في نص غير مشفر في قاعدة بيانات Azure SQL أو مثيل SQL المدار، حتى في الذاكرة/قيد الاستخدام. تعمل ميزة Always Encrypted على حماية البيانات من مسؤولي قواعد البيانات (DBA) ومسؤولي السحابة (أو الجهات الفاعلة السيئة التي يمكنها انتحال شخصية المستخدمين ذوي الامتيازات العالية ولكن غير المصرح لهم) وتمنحك مزيداً من التحكم في من يمكنه الوصول إلى بياناتك.

أفضل الممارسات:

  • ميزة Always Encrypted ليست بديلاً لتشفير البيانات الثابتة (TDE) أو أثناء النقل (SSL/TLS). لا ينبغي استخدام Always Encrypted في البيانات غير الحساسة لتقليل تأثير الأداء والوظائف. يوصى باستخدام ميزة Always Encrypted بالاقتران مع TDE وبروتوكول أمان طبقة النقل (TLS) من أجل الحماية الشاملة للبيانات في حالة الثبوت، والنقل، والاستخدام.

  • قم بتقييم تأثير تشفير أعمدة البيانات الحساسة المحددة قبل نشر ميزة Always Encrypted في قاعدة بيانات التشغيل. بشكل عام، تقلل Always Encrypted من وظيفة الاستعلامات على أعمدة مشفرة ولها قيود أخرى، المدرجة في تفاصيل ميزة Always Encrypted. لذلك، قد تحتاج إلى إعادة تصميم تطبيقك لإعادة تنفيذ الوظيفة، ولا يدعم الاستعلام، من جانب العميل وإعادة تشكيل مخطط قاعدة البيانات أو أيٍ منهم، بما في ذلك تعريفات الإجراءات والوظائف والعروض والمشغلات المخزنة. قد لا تعمل التطبيقات الحالية مع الأعمدة المشفرة إذا لم تلتزم بالقيود والقيود الخاصة بـ Always Encrypted. بينما يتزايد النظام البيئي الخاص بأدوات Microsoft ومنتجاتها وخدماتها التي تدعم ميزة Always Encrypted، فإن عدداً منها لا يعمل مع الأعمدة المشفرة. قد يؤثر تشفير العمود أيضاً على أداء الاستعلام، اعتماداً على خصائص حمل عملك.

  • إدارة مفاتيح Always Encrypted مع فصل الأدوار إذا كنت تستخدم ميزة Always Encrypted لحماية البيانات من مسؤولي قواعد البيانات (DBA) الضارين. مع فصل الأدوار، يقوم مسؤول الأمان بإنشاء المفاتيح الفعلية. يقوم مسؤول قاعدة البيانات (DBA) بإنشاء مفتاح العمود الرئيسي وعناصر بيانات تعريف مفتاح تشفير العمود التي تصف المفاتيح الفعلية في قاعدة البيانات. أثناء هذه العملية، لا يحتاج مسؤول الأمان إلى الوصول إلى قاعدة البيانات ، ولا يحتاج مسؤول قاعدة البيانات (DBA) إلى الوصول إلى المفاتيح المادية في نص غير مشفر.

  • قم بتخزين مفاتيح العمود الرئيسية في Azure Key Vault لتسهيل الإدارة. تجنب استخدام مخزن شهادات Windows (وبشكل عام، حلول مخزن المفاتيح الموزعة، بدلاً من حلول إدارة المفاتيح المركزية) التي تجعل إدارة المفاتيح صعبة.

  • فكر جيداً في المفاضلات باستخدام مفاتيح متعددة (المفتاح الرئيسي للعمود أو مفاتيح تشفير العمود). احتفظ بعدد المفاتيح قليلاً لتقليل تكلفة إدارة المفاتيح. عادةً ما يكون مفتاح عمود رئيسي واحد ومفتاح تشفير عمود واحد لكل قاعدة بيانات كافيين في بيئات الحالة الثابتة (ليس في منتصف تدوير المفتاح). قد تحتاج إلى مفاتيح إضافية إذا كانت لديك مجموعات مختلفة من المستخدمين، كل منها يستخدم مفاتيح مختلفة ويصل إلى بيانات مختلفة.

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

  • استخدم التشفير المحدد إذا كانت الحسابات (المساواة) في البيانات بحاجة إلى الدعم. خلاف ذلك، استخدم التشفير العشوائي. تجنب استخدام التشفير المحدد لمجموعات البيانات منخفضة الإنتروبيا، أو مجموعات البيانات ذات التوزيع المعروف للجمهور.

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

  • لا يدعم Always Encrypted بسهولة منح حق الوصول المؤقت إلى المفاتيح (والبيانات المحمية). على سبيل المثال، إذا كنت بحاجة إلى مشاركة المفاتيح مع مسؤول قاعدة البيانات (DBA) للسماح لمسؤول قاعدة البيانات (DBA) بإجراء بعض عمليات التطهير على البيانات الحساسة والمشفرة. الطريقة الوحيدة لإبطال لإلغاء الوصول إلى البيانات من مسؤول قاعدة البيانات (DBA) بطريقة موثوقة هي تدوير كل من مفاتيح تشفير العمود ومفاتيح العمود الرئيسية التي تحمي البيانات، وهي عملية مكلفة.

  • للوصول إلى قيم النص العادي في الأعمدة المشفرة، يحتاج المستخدم إلى الوصول إلى مفتاح العمود الرئيسي (CMK) الذي يحمي الأعمدة، والذي تم تكوينه في مخزن المفاتيح الذي يحمل مفتاح العمود الرئيسي (CMK). يحتاج المستخدم أيضاً إلى الحصول على أذونات قاعدة البيانات VIEW ANY COLUMN MASTER KEY DEFINITION وVIEW ANY COLUMN ENCRYPTION KEY DEFINITION.

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

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

كيفية التنفيذ:

  • استخدام التشفير على مستوى الخلية (CLE). راجع المقالة، تشفير عمود البيانات للحصول على التفاصيل.
  • استخدم Always Encrypted، ولكن كن على علم بحدودها. القيود مذكورة أدناه.

أفضل الممارسات

عند استخدام التشفير على مستوى الخلية (CLE):

  • التحكم في الوصول إلى المفاتيح من خلال أذونات وأدوار SQL.

  • استخدم مقاييس التشفير المتقدمة (AES 256 الموصى به) لتشفير البيانات. تم إهمال الخوارزميات، مثل RC4 وDES وTripleDES، ويجب عدم استخدامها بسبب نقاط الضعف المعروفة.

  • حماية المفاتيح المتماثلة بمفاتيح/شهادات غير متماثلة (وليس كلمات مرور) لتجنب استخدام 3DES.

  • كن حذراً عند ترحيل قاعدة بيانات باستخدام التشفير على مستوى الخلية عبر تصدير/استيراد (ملفات bacpac).

ضع في اعتبارك أن Always Encrypted مصمم بشكل أساسي لحماية البيانات الحساسة المستخدمة من المستخدمين ذوي الامتيازات العالية لقاعدة بيانات Azure SQL (مشغلي السحابة، مسؤولي قاعدة البيانات (DBAs))- راجع حماية البيانات الحساسة المستخدمة من المستخدمين ذوي الامتيازات العالية وغير المصرح لهم. كن على علم بالتحديات التالية عند استخدام "Always Encrypted" لحماية البيانات من مستخدمي التطبيق:

  • بشكل افتراضي، جميع برامج تشغيل عملاء Microsoft التي تدعم "Always Encrypted" تحتفظ بذاكرة تخزين مؤقت عمومية (واحد لكل تطبيق) من مفاتيح تشفير العمود. بمجرد حصول برنامج تشغيل جهاز العميل على مفتاح تشفير عمود نص غير مشفر عن طريق الاتصال بمخزن مفاتيح يحمل المفتاح الرئيسي للعمود، يتم تخزين مفتاح تشفير عمود النص غير المشفر مؤقتاً. وهذا يجعل عزل البيانات عن مستخدمي تطبيق متعدد المستخدمين أمراً صعباً. إذا كان تطبيقك ينتحل شخصية المستخدمين النهائيين عند التفاعل مع مخزن المفاتيح (مثل Azure Key Vault)، بعد أن يقوم استعلام المستخدم بملء ذاكرة التخزين المؤقت بمفتاح تشفير العمود، فسيستخدم استعلاماً لاحقاً يتطلب نفس المفتاح ولكن يتم تشغيله بواسطة مستخدم آخر سيستخدم المفتاح المخزن مؤقتاً. لن يقوم برنامج التشغيل بالاتصال بمخزن المفاتيح ولن يتحقق مما إذا كان المستخدم الثاني لديه إذن للوصول إلى مفتاح تشفير العمود. ونتيجة لذلك، يمكن للمستخدم رؤية البيانات المشفرة حتى إذا لم يكن لدى المستخدم حق الوصول إلى المفاتيح. لتحقيق عزل المستخدمين داخل تطبيق متعدد المستخدمين، يمكنك تعطيل التخزين المؤقت لمفتاح تشفير العمود. سيؤدي تعطيل التخزين المؤقت إلى زيادة النفقات الإضافية للأداء، حيث سيحتاج برنامج التشغيل إلى الاتصال بمخزن المفاتيح لكل عملية تشفير أو فك تشفير للبيانات.

حماية البيانات من العرض غير المصرح به من قبل مستخدمي التطبيق مع الحفاظ على تنسيق البيانات

هناك تقنية أخرى لمنع المستخدمين غير المصرح لهم من عرض البيانات وهي تعتيم أو إخفاء البيانات مع الحفاظ على أنواع وتنسيقات البيانات لضمان أن تطبيقات المستخدم يمكن أن تستمر في معالجة البيانات وعرضها.

كيفية التنفيذ:

ملاحظة

لا يعمل Always Encrypted مع إخفاء البيانات الديناميكي (DDM). لا يمكن تشفير وإخفاء نفس العمود، ما يعني أنك بحاجة إلى منح الأولوية لحماية البيانات قيد الاستخدام مقابل إخفاء بيانات مستخدمي التطبيق عبر إخفاء البيانات الديناميكي (DDM).

أفضل الممارسات:

ملاحظة

لا يمكن استخدام إخفاء البيانات الديناميكي (DDM) لحماية البيانات من المستخدمين ذوي الامتيازات العالية. لا ينطبق نهج الإخفاء على المستخدمين الذين لديهم حق الوصول الإداري مثل db_owner.

  • لا تسمح لمستخدمي التطبيق بتشغيل استعلامات مخصصة (حيث قد يتمكنون من الغلب على إخفاء البيانات الديناميكي (DDM)).

  • استخدم نهج التحكم في الوصول المناسب (عبر أذونات SQL والأدوار والأمان على مستوى الصف (RLS)) لتقييد أذونات المستخدم لإجراء التحديثات في الأعمدة المخفية. لا يؤدي إنشاء قناع على عمود إلى منع التحديثات في هذا العمود. يمكن للمستخدمين الذين يتلقون بيانات مخفية عند الاستعلام عن العمود المخفي تحديث البيانات إذا كان لديهم أذونات الكتابة.

  • لا يحتفظ إخفاء البيانات الديناميكي (DDM) بالخصائص الإحصائية للقيم المخفية. قد يؤثر هذا على نتائج الاستعلام (على سبيل المثال، الاستعلامات التي تحتوي على دالات التقييم التصفية أو الروابط على البيانات المخفية).

أمان الشبكة

يشير أمان الشبكة إلى عناصر التحكم في الوصول وأفضل الممارسات لتأمين بياناتك أثناء النقل إلى قاعدة بيانات Azure SQL.

تكوين العميل للاتصال بشكل آمن إلى قاعدة بيانات SQL/مثيل SQL المدار

أفضل الممارسات حول كيفية منع أجهزة العميل والتطبيقات مع نقاط الضعف المعروفة (على سبيل المثال، باستخدام بروتوكولات TLS القديمة ومجموعات التشفير) من الاتصال بقاعدة بيانات Azure SQL ومثيل SQL المدار.

كيفية التنفيذ:

  • تأكد من أن الأجهزة العميلة التي تتصل بـ Azure SQL Database وSQL Managed Instance تستخدم أحدث إصدار من Transport Layer Security (TLS).

أفضل الممارسات:

  • فرض الحد الأدنى من إصدار TLS على مستوى خادم SQL Managed أو SQL Managed Instance باستخدام المستوى الأدنى من إعداد إصدار TLS. نوصي بإعداد الحد الأدنى من إصدار TLS على 1.2، بعد الاختبار للتأكد من أن تطبيقاتك تدعمه. يتضمن TLS 1.2 إصلاحات عاجلة للثغرات الأمنية الموجودة في الإصدارات السابقة.

  • تكوين جميع التطبيقات والأدوات للاتصال بقاعدة بيانات SQL مع تمكين التشفير

    • تشفير = تشغيل، TrustServerCertificate = إيقاف (أو ما يعادلها مع برامج التشغيل الجهاز غير Microsoft).

  • إذا كان تطبيقك يستخدم برنامج تشغيل لا يدعم بروتوكول أمان طبقة النقل (TLS) أو يدعم إصداراً قديماً من بروتوكول أمان طبقة النقل (TLS)، فاستبدل برنامج التشغيل، إذا أمكن. إذا لم يكن ذلك ممكناً، فقيم مخاطر الأمان بعناية.

تصغير سطح الهجوم

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

المشار إليه في: الممارسة OSA #5

كيفية التنفيذ:

في قاعدة بيانات SQL:

  • تعيين السماح بالوصول إلى خدمات Azure إلى إيقاف على مستوى الخادم
  • استخدام نقاط تقديم خدمة الشبكة الظاهرية وقواعد جدار حماية الشبكة الظاهرية.
  • استخدم Private Link.

في مثيل SQL المدار:

أفضل الممارسات:

  • تقييد الوصول إلى قاعدة بيانات Azure SQL ومثيل SQL المُدار عن طريق الاتصال بنقطة نهاية خاصة (على سبيل المثال، باستخدام مسار بيانات خاص):

    • يمكن عزل مثيل مدار داخل شبكة ظاهرية لمنع الوصول الخارجي. يمكن للتطبيقات والأدوات الموجودة في نفس الشبكة الظاهرية أو الموجودة في نفس المنطقة الوصول إليها مباشرة. يمكن أن تستخدم التطبيقات والأدوات الموجودة في منطقة مختلفة اتصال شبكة ظاهرية بشبكة ظاهرية أو نظير دائرة ExpressRoute لإنشاء اتصال. يجب على العميل استخدام مجموعات أمان الشبكة (NSG) لتقييد الوصول عبر المنفذ 1433 فقط إلى الموارد التي تتطلب الوصول إلى مثيل مُدار.
    • بالنسبة إلى قاعدة بيانات SQL، استخدم ميزة الارتباط الخاص التي توفر عنوان IP خاصاً مخصصاً للخادم داخل الشبكة الظاهرية. يمكنك أيضاً استخدام نقاط نهاية خدمة الشبكة الظاهرية مع قواعد جدار حماية الشبكة الظاهرية لتقييد الوصول إلى الخوادم.
    • يجب على مستخدمي الأجهزة المحمولة استخدام اتصالات VPN من نقطة إلى موقع للاتصال عبر مسار البيانات.
    • يجب على المستخدمين المتصلين بشبكتهم المحلية استخدام اتصال VPN من موقع إلى موقع أو ExpressRoute للاتصال عبر مسار البيانات.

  • يمكنك الوصول إلى قاعدة بيانات SQL Azure ومثيل SQL المدار عن طريق الاتصال بنقطة نهاية عامة (على سبيل المثال، باستخدام مسار بيانات عام). يجب مراعاة أفضل الممارسات التالية:

ملاحظة

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

تكوين Power BI للاتصالات الآمنة بقاعدة بيانات SQL/مثيل SQL المدار

أفضل الممارسات:

قم بتكوين خدمة التطبيقات للاتصالات الآمنة بقاعدة بيانات SQL/مثيل SQL المدار

أفضل الممارسات:

تكوين استضافة الجهاز الظاهري Azure للاتصالات الآمنة بقاعدة بيانات SQL/مثيل SQL المدار

أفضل الممارسات:

  • استخدم مجموعة من قواعد "السماح" و"الرفض" في مجموعات NSG لأجهزة Azure الظاهرية للتحكم في المناطق التي يمكن الوصول إليها من الجهاز الظاهري.

  • تأكد من تهيئة الجهاز الظاهري وفقاً للمقالة، أفضل ممارسات الأمان لأحمال عمل IaaS في Azure.

  • تأكد من أن جميع الأجهزة الظاهرية مقترنة بشبكة ظاهرية معينة وشبكة فرعية.

  • قم بتقييم ما إذا كنت بحاجة إلى المسار الافتراضي 0.0.0.0/Internet وفقاً للإرشادات الموجودة على حول التوجيه للأسفل الإجباري.

    • إذا كانت الإجابة بنعم - على سبيل المثال، الشبكة الفرعية للواجهة الأمامية - فاحتفظ بالمسار الافتراضي.
    • إذا كانت الإجابة "لا" - على سبيل المثال، الطبقة الوسطى أو الشبكة الفرعية الخلفية - فقم بتمكين فرض التوجيه للأسفل بحيث لا تنتقل نسبة استخدام الشبكة عبر الإنترنت للوصول داخلياً (ويعرف أيضاً باسم أماكن العمل المشتركة).

  • تنفيذ مسارات افتراضية اختيارية إذا كنت تستخدم التناظر أو تتصل داخلياً.

  • تنفيذ المسارات المحددة بواسطة المستخدم إذا كنت بحاجة إلى إرسال كل حركة المرور في الشبكة الظاهرية إلى شبكة الجهاز الظاهري لفحص الحزمة.

  • استخدام نقاط تقديم خدمة الشبكة الظاهرية للوصول الآمن إلى خدمات PaaS مثل تخزين Azure عبر شبكة Azure الأساسية.

الحماية من هجمات رفض الخدمة الموزعة (DDoS)

هجمات رفض الخدمة الموزعة (DDoS) هي محاولات من قبل مستخدم ضار لإرسال تدفق من نسبة استخدام الشبكة إلى قاعدة بيانات Azure SQL بهدف إرباك البنية الأساسية لـ Azure والتسبب في رفض عمليات تسجيل الدخول الصالحة وحمل العمل.

المشار إليه في: الممارسة OSA #9

كيفية التنفيذ:

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

أفضل الممارسات:

  • اتبع الممارسات الموضحة في تصغير سطح الهجوم يساعد على تقليل تهديدات الهجوم الموزع لحجب الخدمة.

  • يساعد تنبيه بيانات اعتماد SQL من القوة الغاشمة للحماية من التهديدات المتقدمة في اكتشاف هجمات القوة الغاشمة. في بعض الحالات، يمكن للتنبيه تمييز أحمال عمل اختبار الاختراق.

  • لتطبيقات Azure لاستضافة الأجهزة الظاهرية المتصلة بقاعدة بيانات SQL:

    • اتبع التوصية لتقييد الوصول عبر نقاط نهاية مواجهة الإنترنت في Microsoft Defender for Cloud.
    • استخدام مجموعات مقياس الجهاز الظاهري لتشغيل مثيلات متعددة من التطبيق الخاص بك على الأجهزة الظاهرية Azure.
    • قم بتعطيل RDP وSSH من الإنترنت لمنع هجوم القوة الغاشمة.

المراقبة، التسجيل، والتدقيق

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

حماية قواعد البيانات من الهجمات

تمكنك الحماية المتقدمة من التهديدات من كشف التهديدات المحتملة والاستجابة لها عند حدوثها من خلال توفير تنبيهات أمنية حول الأنشطة الغريبة.

كيفية التنفيذ:

أفضل الممارسات:

  • قم بتكوين Microsoft Defender لـ SQL لخادم معين أو مثيل مُدار. يمكنك أيضاً تكوين Microsoft Defender for SQL لجميع الخوادم والمثيلات المُدارة في الاشتراك عن طريق تمكين Microsoft Defender for Cloud.

  • للحصول على تجربة تحقيق كاملة، يوصى بتمكين SQL Database Auditing. من خلال التدقيق، يمكنك تعقب أحداث قاعدة البيانات وكتابتها إلى سجل تدقيق في حساب تخزين Azure أو مساحة عمل سجل تحليلات Azure.

تدقيق أحداث الأمان المهمة

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

كيفية التنفيذ:

  • تمكين SQL Database Auditing أو Managed Instance Auditing لتتبع أحداث قاعدة البيانات وكتابتها في سجل تدقيق في حساب تخزين Azure أو مساحة عمل تحليلات السجل (إصدار أولي) أو مراكز الأحداث (إصدار أولي).

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

أفضل الممارسات:

  • من خلال تكوين تدقيق قاعدة بيانات SQL على الخادم أو تدقيق المثيل المُدار لتدقيق الأحداث، سيتم تدقيق جميع قواعد البيانات الموجودة والتي تم إنشاؤها حديثاً على هذا الخادم.
  • يتضمن نهج التدقيق بشكل افتراضي جميع الإجراءات (الاستعلامات والإجراءات المخزنة وتسجيلات الدخول الناجحة والفاشلة) مقابل قواعد البيانات، ما قد يؤدي إلى ارتفاع حجم سجلات التدقيق. يُنصح العملاء بتكوين التدقيق لأنواع مختلفة من الإجراءات ومجموعات الإجراءات باستخدام PowerShell. سيساعد تكوين هذا في التحكم في عدد الإجراءات التي تم تدقيقها، وتصغير مخاطر فقدان الحدث. تسمح تكوينات التدقيق المخصصة للعملاء بالتقاط بيانات التدقيق المطلوبة فقط.
  • يمكن استهلاك سجلات التدقيق مباشرة في مدخل Microsoft Azure، أو من موقع التخزين الذي تم تكوينه.

ملاحظة

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

المزيد من الموارد:

سجلات تدقيق آمنة

تقييد الوصول إلى حساب التخزين لدعم فصل الواجبات وفصل مسؤول قاعدة البيانات (DBA) عن المدققين.

كيفية التنفيذ:

  • عند حفظ سجلات التدقيق إلى تخزين Azure، تأكد من أن الوصول إلى حساب التخزين مقيد بالحد الأدنى من مبادئ الأمان. التحكم في من لديه حق الوصول إلى حساب التخزين.
  • لمزيد من المعلومات، راجع السماح بالوصول إلى تخزين Azure.

أفضل الممارسات:

إدارة الأمان

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

تأكد من تكوين قواعد البيانات لتلبي أفضل ممارسات الأمان

بتحسين أمان قاعدة البيانات بشكل استباقي من خلال اكتشاف الثغرات الأمنية المحتملة في قاعدة البيانات ومعالجتها.

كيفية التنفيذ:

أفضل الممارسات:

  • في البداية، تشغيل تقييم الثغرات الأمنية (VA) على قواعد بياناتك وتكرارها عن طريق إصلاح فشل عمليات الفحص التي تعارض أفضل ممارسات الأمان. قم بإعداد الخطوط الأساسية للتكوينات المقبولة حتى يخرج الفحص نظيفاً، أو يتم اجتياز جميع عمليات الفحص.

  • قم بتكوين عمليات الفحص الدورية المتكررة للتشغيل مرة واحدة في الأسبوع وقم بتهيئة الشخص ذي الصلة لتلقي رسائل البريد الإلكتروني الموجزة.

  • راجع ملخص تقييم الثغرات الأمنية (VA) بعد كل فحص أسبوعي. بالنسبة لأي ثغرات أمنية تم العثور عليها، قم بتقييم الانحراف من نتيجة الفحص السابقة وحدد ما إذا كان يجب حل عملية الفحص. تقييم ما إذا كان هناك سبب مشروع للتغيير في التكوين.

  • حل عمليات الفحص وتحديث الخطوط الأساسية عند الاقتضاء. إنشاء عناصر البطاقات لحل الإجراءات وتعقبها حتى يتم حلها.

المزيد من الموارد:

تحديد البيانات الحساسة ووضع علامة عليها

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

كيفية التنفيذ:

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

أفضل الممارسات:

  • مراقبة لوحة معلومات التصنيف بشكل منتظم لإجراء تقييم دقيق لحالة تصنيف قاعدة البيانات. يمكن تصدير تقرير عن حالة تصنيف قاعدة البيانات أو طباعته للمشاركة في أغراض التوافق والتدقيق.

  • مراقبة حالة البيانات الحساسة الموصى بها باستمرار في تقييم الثغرات الأمنية لـ SQL. تعقب قاعدة اكتشاف البيانات الحساسة وتحديد أي انحراف في الأعمدة الموصى بها للتصنيف.

  • استخدم التصنيف بطريقة تتناسب مع احتياجات مؤسستك المحددة. قم بتخصيص نهج حماية البيانات في Microsoft Azure (تسميات الحساسية وأنواع المعلومات ومنطق الاكتشاف) في نهج حماية معلومات SQL في Microsoft Defender for Cloud.

تعقب الوصول إلى البيانات الحساسة

مراقبة من يصل إلى البيانات الحساسة وتسجيل الاستعلامات على البيانات الحساسة في سجلات التدقيق.

كيفية التنفيذ:

أفضل الممارسات:

تصور حالة الأمان والتوافق

استخدام نظام إدارة أمان البنية الأساسية الموحد الذي يقوي الوضع الأمني ​​لمراكز بياناتك (بما في ذلك قواعد البيانات في قاعدة بيانات SQL). عرض قائمة بالتوصيات المتعلقة بأمان قواعد البيانات وحالة التوافق.

كيفية التنفيذ:

تهديدات الأمان الشائعة وعمليات التخفيف من المخاطر المحتملة

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

تهديد الأمان: نقل غير مصرّح للبيانات

إن النقل غير المصرّح للبيانات هو نسخ البيانات أو نقلها أو استردادها من جهاز كمبيوتر أو خادم. راجع تعريف النقل غير المصرّح للبيانات على ويكيبيديا.

يمثل الاتصال بالخادم عبر نقطة نهاية عامة خطراً للنقل غير المصرّح للبيانات لأنه يتطلب من العملاء فتح جدران الحماية الخاصة بهم لعناوين IP العامة.

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

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

التخفيف المحتمل من المخاطر:

اليوم، توفر قاعدة بيانات Azure SQL ومثيل SQL المدار التقنيات التالية للتخفيف من تهديدات النقل غير المصرّح للبيانات:

  • استخدم مجموعة من قواعد "السماح" و"الرفض" في مجموعات NSG الخاصة بأجهزة Azure الظاهرية للتحكم في المناطق التي يمكن الوصول إليها من الجهاز الظاهري.
  • إذا كنت تستخدم خادماً في قاعدة بيانات SQL، فعين الخيارات التالية:
    • السماح بإيقاف خدمات Azure.
    • السماح فقط بنسبة استخدام الشبكة من الشبكة الفرعية التي تحتوي على جهاز Azure الظاهري عن طريق إعداد قاعدة جدار حماية الشبكة الظاهرية.
    • استخدام رابط خاص
  • بالنسبة لمثيل SQL المدار، فإن استخدام وصول IP الخاص بشكل افتراضي يعالج أول مخاوف تتعلق بالنقل غير المصرح للبيانات إلى جهاز ظاهري محتال. قم بتشغيل ميزة تفويض الشبكة الفرعية على شبكة فرعية لتعيين النهج الأكثر تقييداً تلقائياً على الشبكة الفرعية لمثيل SQL المدار.
  • تتعرض مخاوف مسؤول قاعدة البيانات المحتال بشكل أكبر مع مثيل SQL المدار نظراً لأنها تحتوي على مساحة سطح أكبر ومتطلبات الشبكات مرئية للعملاء. أفضل تخفيف لذلك هو تطبيق جميع الممارسات الواردة في دليل الأمان هذا لمنع سيناريو مسؤول قاعدة البيانات المحتال في المركز الأول (ليس فقط للنقل غير المصرح للبيانات). Always Encrypted هو أسلوب واحد لحماية البيانات الحساسة عن طريق تشفيرها والحفاظ على المفتاح غير قابل للوصول لمسؤول قاعدة البيانات.

جوانب الأمان لاستمرارية الأعمال وتوافرها

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

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