Share via

قاعدة بيانات Azure لتشفير بيانات MySQL باستخدام مفتاح مدار من قبل العميل

  • مقالة

تُطبق على: قاعدة بيانات Azure للخادم الوحيد الخاص بـ MySQL

هام

قاعدة بيانات Azure لخادم MySQL الفردي على مسار الإيقاف. نوصي بشدة بالترقية إلى قاعدة بيانات Azure لخادم MySQL المرن. لمزيد من المعلومات حول الترحيل إلى خادم Azure Database for MySQL المرن، راجع ما الذي يحدث لقاعدة بيانات Azure لخادم MySQL الفردي؟

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

يتم تعيين تشفير البيانات مع مفاتيح يديرها العملاء لقاعدة بيانات Azure لـ MySQL، على مستوى الخادم. وفيما يخص خادم معين، يتم استخدام مفتاح مدار من قبل العميل، يسمى مفتاح تشفير المفتاح (KEK)، لتشفير مفتاح تشفير البيانات (DEK) الذي تستخدمه الخدمة. KEK هو مفتاح غير متماثل مخزن في مثيل Azure Key Vault المملوك للعميل والمدار من قبل العميل. يوصف مفتاح تشفير المفتاح (KEK) ومفتاح تشفير البيانات (DEK) بمزيد من التفصيل لاحقاً في هذه المقالة.

Azure Key Vault هو نظام لإدارة المفتاح الخارجي المستند إلى الإنترنت. إنه متوفر بشكل كبير ويوفر تخزينا آمنا وقابلا للتطوير لمفاتيح تشفير RSA، مدعوما اختياريا بوحدات أمان الأجهزة التي تم التحقق من صحتها FIPS 140 (HSMs). فهو لا يسمح بالوصول المباشر إلى مفتاح مخزن، إلا أنه يوفر خدمات التشفير/فك التشفير باستخدام المفتاح إلى الكيانات المعتمدة. يمكن لـ Key Vault إنشاء المفتاح أو استيراده أو نقله من جهاز HSM محلي.

إشعار

يتم دعم هذه الميزة فقط على تخزين "التخزين للأغراض العامة v2 (دعم يصل إلى 16 تيرابايت)" المتوفرة في مستويات التسعير للأغراض العامة والذاكرة المحسنة. راجع مفاهيم التخزين لمزيد من التفاصيل. للحصول على قيود أخرى، يرجى مراجعة قسم التقييدات.

المزايا

يوفر تشفير البيانات باستخدام المفاتيح المُدارة بواسطة العميل لقاعدة بيانات Azure لـ MySQL المزايا التالية:

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

المصطلحات والوصف

مفتاح تشفير البيانات (DEK): مفتاح AES256 متماثل يستخدم لتشفير قسم أو كتلة بيانات. يؤدي تشفير كل كتلة من البيانات بمفتاح مختلف إلى زيادة صعوبة هجمات تحليل التشفير. يلزم الوصول إلى مفاتيح التشفير من قبل موفر الموارد أو مثيل التطبيق المسؤول عن تشفير وفك تشفير كتلة معينة من البيانات. عند استبدال DEK بمفتاح جديد، يجب إعادة تشفير البيانات الموجودة في الكتلة المرتبطة به بالمفتاح الجديد فقط.

مفتاح تشفير المفتاح (KEK): مفتاح تشفير يستخدم لتشفير مفاتيح التشفير. يسمح مفتاح تشفير المفاتيح الذي لا يترك Key Vault أبداً بتشفير مفاتيح التشفير نفسها والتحكم فيها. قد يكون الكيان الذي لديه حق الوصول إلى مفتاح تشفير المفاتيح مختلفاً عن الكيان الذي يتطلب مفتاح تشفير. نظراً لأن مفتاح تشفير المفاتيح مطلوب لفك تشفير مفاتيح التشفير، فإن مفتاح تشفير المفاتيح هو بفعالية نقطة واحدة يمكن من خلالها حذف مفاتيح التشفير بشكل فعال عن طريق حذف مفتاح تشفير المفاتيح.

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

كيفية عمل تشفير البيانات باستخدام مفتاح مدار من قبل العميل

Diagram that shows an overview of Bring Your Own Key

لكي يستخدم خادم MySQL المفاتيح المُدارة بواسطة العميل والمخزنة في Key Vault لتشفير DEK، يمنح مسؤول Key Vault حقوق الوصول التالية إلى الخادم:

  • get - لاسترداد الجزء العام وخصائص المفتاح في المخزن الرئيسي.
  • wrapKey: لتكون قادراً على تشفير مفتاح التشفير. يتم تخزين مفاتيح التشفير المشفرة في قاعدة بيانات Azure لـ MySQL.
  • unwrapKey: لتكون قادراً على فك تشفير مفتاح التشفير. تحتاج قاعدة بيانات Azure لـ MySQL إلى مفتاح التشفير الذي تم فك تشفيره لتشفير/فك تشفير البيانات

يمكن لمسؤول key vault كذلك تمكين تسجيل أحداث تدقيق Key Vault، بحيث يمكن تدقيقها لاحقاً.

عند تكوين الخادم لاستخدام المفتاح المدار من قبل العميل المخزن في Key Vault، يرسل الخادم مفتاح التشفير إلى Key Vault للتشفير. تقوم Key Vault بإرجاع مفتاح التشفير المشفر، والذي يتم تخزينه بعد ذلك في قاعدة بيانات المستخدم. وبالمثل، عند الحاجة، يرسل الخادم مفتاح التشفير المحمي إلى key vault لفك التشفير. يمكن للمدققين استخدام Azure Monitor لمراجعة سجلات AuditEvent الخاصة بـ key vault، في حالة تمكين التسجيل.

متطلبات تكوين تشفير البيانات لقاعدة بيانات Azure لـ MySQL

فيما يلي متطلبات تكوين Key Vault:

  • يجب أن ينتمي Key Vault وقاعدة بيانات Azure ل MySQL إلى نفس مستأجر Microsoft Entra. عدم دعم Key Vault وتفاعلات الخادم. يتطلب نقل مورد Key Vault بعد ذلك إعادة تكوين تشفير البيانات.
  • تمكين ميزة soft-delete على خزنة المفاتيح مع تعيين فترة الاحتفاظ إلى 90 يوماً، للحماية من فقدان البيانات في حالة حدوث حذف غير مقصود للمفتاح (أو Key Vault). يتم الاحتفاظ بالموارد المحذوفة مبدئياً لمدة 90 يوماً بشكل افتراضي، ما لم يتم تعيين فترة الاستبقاء بشكل صريح إلى <=90 يوماً. إجراءات الاسترداد والمسح لها أذونات خاصة بها مرتبطة بسياسة الوصول إلى Key Vault. يتم إيقاف تشغيل ميزة الحذف الناعم افتراضياً، ولكن يمكنك تمكينها من خلال PowerShell أو Azure CLI (لاحظ أنه لا يمكنك تمكينها من خلال مدخل Microsoft Azure).
  • تمكين ميزة Purge Protection على key vault مع تعيين فترة الاستبقاء إلى 90 يوماً. لا يمكن تمكين الحماية من المسح إلا بعد تمكين الحذف المبدئي. يمكن تشغيله عبر Azure CLI أو PowerShell. عند تشغيل الحماية من المسح، لا يمكن إزالة مخزن أو عنصر في الحالة المحذوفة حتى انقضاء فترة الاحتفاظ. لا يزال من الممكن استعادة الخزائن والعناصر المحذوفة بشكل مبدئي، مما يضمن اتباع سياسة الاحتفاظ.
  • امنح قاعدة بيانات Azure لـ MySQL حق الوصول إلى خزنة المفاتيح باستخدام أذونات get و wrapKey و unwrapKey باستخدام هويتها الفريدة المُدارة. في مدخل Microsoft Azure، يتم إنشاء هوية "Service" الفريدة تلقائياً عند تمكين تشفير البيانات على MySQL. راجع تكوين تشفير البيانات لـ MySQL للحصول على إرشادات مفصلة خطوة بخطوة عند استخدام مدخل Microsoft Azure.

فيما يلي متطلبات تكوين المفتاح المدار من قبل العميل:

  • يمكن أن يكون المفتاح الذي يديره العميل لاستخدامه لتشفير مفتاح التشفير غير متماثل فقط، RSA 2048.
  • يجب أن يكون تاريخ تنشيط المفتاح (إذا تم تعيينه) تاريخاً ووقتاً في الماضي. تاريخ انتهاء الصلاحية غير محدد.
  • يجب أن يكون المفتاح في الحالة ممكّن.
  • يجب أن يكون للمفتاح حذف مبدئي مع تعيين فترة الاستبقاء إلى 90 يوماً. يؤدي هذا ضمنياً إلى تعيين السمة الرئيسية المطلوبة: “Recoverable”. إذا تم تعيين الاستبقاء إلى < 90 يوماً، يتم تعيين recoveryLevel: "CustomizedRecoverable"، والذي لا يتطلب لذلك تأكد من تعيين فترة الاستبقاء إلى 90 يوماً.
  • يجب تمكين حماية المسح للمفتاح.
  • إن كنت تستورد مفتاحاً موجوداً في مخزن المفاتيح، فتأكد من توفيره بتنسيقات الملفات المدعومة (.pfxأو .byokأو .backup).

التوصيات

في حال استخدام تشفير البيانات باستخدام مفتاح يديره العميل، فيما يلي توصيات لتكوين Key Vault:

  • قم بتعيين تأمين مورد على Key Vault للتحكم في من يمكنه حذف هذا المورد الهام ومنع الحذف العرضي أو غير المصرح به.

  • تمكين التدقيق وإعداد التقارير على جميع مفاتيح التشفير. توفر Key Vault سجلات يسهل إدخالها في معلومات الأمان وأدوات إدارة الأحداث الأخرى. تحليلات سجلات Azure Monitor هي أحد الأمثلة على خدمة متكاملة بالفعل.

  • تأكد من وجود Key Vault وقاعدة بيانات Azure لـ MySQL في نفس المنطقة، لضمان وصول أسرع لعمليات wrap و unwrap مفاتيح التشفير.

  • تأمين Azure KeyVault إلى نقطة النهاية الخاصة والشبكات المحددة فقط والسماح لخدمات Microsoft الموثوق بها بتأمين الموارد.

    trusted-service-with-AKV

فيما يلي توصيات لتكوين مفتاح مدار من خلال العميل:

  • احتفظ بنسخة من أداة حماية المفتاح المدار من خلال العميل في مكان آمن أو احفظها في خدمة الضمان.

  • في حال إنشاء المفتاح في Key Vault، فقم بإنشاء نسخة احتياطية للمفتاح قبل استخدام المفتاح للمرة الأولى. يمكنك فقط استعادة النسخ الاحتياطي إلى Key Vault. لمزيد من المعلومات حول أمر النسخ الاحتياطي، يرجى مراجعةBackup-AzKeyVaultKey.

حالة المفتاح الذي لا يمكن الوصول إليه من قبل العميل

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

  • إذا أنشأنا خادم “Point In Time Restore” لقاعدة بيانات Azure لـ MySQL، والذي تم تمكين تشفير البيانات فيه، فسيكون الخادم الذي تم إنشاؤه حديثاً في حالة يتعذر الوصول إليها. يمكنك إصلاح ذلك من خلال مدخل Microsoft Azure أو CLI.
  • إذا قمنا بإنشاء نسخة طبق الأصل للقراءة لقاعدة بيانات Azure الخاصة بك لـ MySQL، والتي تم تمكين تشفير البيانات، سيكون خادم النسخة المتماثلة في حالة تعذر الوصول إليها. يمكنك إصلاح ذلك من خلال مدخل Microsoft Azure أو CLI.
  • إذا قمت بحذف KeyVault، فلن تتمكن قاعدة بيانات Azure لـ MySQL من الوصول إلى المفتاح وستنتقل إلى حالة يتعذر الوصول إليها. استرداد Key Vault وإعادة التحقق من تشفير البيانات لجعل الخادم متوفراً.
  • إذا قمت بحذف مفتاح من KeyVault، فلن تتمكن قاعدة بيانات Azure لـ MySQL من الوصول إلى المفتاح وستنتقل إلى حالة يتعذر الوصول إليها. استرداد المفتاح وإعادة التحقق من تشفير البيانات لجعل الخادم متوفراً.
  • في حال انتهاء صلاحية المفتاح المخزن في Azure KeyVault، فسيصبح المفتاح غير صالح وستنتقل قاعدة بيانات Azure لـ MySQL إلى حالة يتعذر الوصول إليها. قم بتمديد تاريخ انتهاء صلاحية المفتاح باستخدام CLI ثم أعد التحقق من تشفير البيانات لجعل الخادم متوفراً.

إبطال الوصول إلى المفتاح العرضي من Key Vault

قد يحدث أن شخصاً لديه حقوق وصول كافية إلى Key Vault بتعطيل وصول الخادم إلى المفتاح بطريق الخطأ عن طريق:

  • إبطال أذونات getو wrapKeyو unwrapKey لمخزن المفاتيح من الخادم.
  • حذف المفتاح.
  • حذف key vault.
  • تغيير قواعد جدار حماية في key vault.
  • حذف الهوية المدارة للخادم في معرف Microsoft Entra.

مراقبة المفتاح المدار من قبل العميل في Key Vault

لمراقبة حالة قاعدة البيانات وتمكين التنبيه لفقدان الوصول إلى أداة حماية تشفير البيانات الشفاف قم بتكوين ميزات Azure التالية:

  • Azure Resource Health: تظهر قاعدة البيانات التي يتعذر الوصول إليها والتي فقدت الوصول إلى مفتاح العميل على أنها "يتعذر الوصول إليها" بعد رفض الاتصال الأول بقاعدة البيانات.

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

  • Action groups: حدد هذه المجموعات لإرسال إخطارات وتنبيهات إليك استناداً إلى تفضيلاتك.

الاستعادة والنسخ المتماثل باستخدام المفتاح المدار للعميل في Key Vault

بعد تشفير Azure Database for MySQL باستخدام المفتاح الذي يديره العميل المخزن في Key Vault، يتم أيضاً تشفير أي نسخة تم إنشاؤها حديثاً من الخادم. يمكنك إنشاء هذه النسخة الجديدة إما من خلال عملية استعادة محلية أو جغرافية، أو من خلال قراءة النسخ المتماثلة. ومع ذلك، يمكن تغيير النسخة لتعكس مفتاح العميل الجديد المدار للتشفير. تبدأ النسخ الاحتياطية القديمة للخادم باستخدام أحدث مفتاح، عند تغيير المفتاح المدار من قبل العميل.

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

  • بدء عملية استعادة أو قراءة إنشاء النسخة المتماثلة من قاعدة بيانات Azure المصدر لـ MySQL.
  • احتفظ بالخادم الذي تم إنشاؤه حديثاً (استعادة/نسخة متماثلة) في حالة يتعذر الوصول إليها، لأن هويته الفريدة لم تمنح بعد الأذونات لـKey Vault.
  • على خادم النسخ المتماثل / المستعاد، أعد التحقق من صحة المفتاح الذي يديره العميل في إعدادات تشفير البيانات لضمان منح الخادم الذي تم إنشاؤه حديثاً أذونات التفاف وإلغاء التفاف للمفتاح المخزن في Key Vault.

القيود

بالنسبة لقاعدة بيانات Azure لـ MySQL، فإن دعم تشفير البيانات الثابتة باستخدام المفتاح المدار للعملاء (CMK) يتميز بقيود قليلة -

  • يقتصر دعم هذه الوظيفة على مستويات التسعير للأغراض العامة و الذاكرة المحسنة.

  • هذه الميزة مدعومة فقط في المناطق والخوادم، التي تدعم تخزين الأغراض العامة v2 (حتى 16 تيرابايت). للحصول على قائمة مناطق Azure التي تدعم التخزين حتى 16 تيرابايت، يرجى مراجعة قسم التخزين في الوثائق هنا

    إشعار

    • جميع خوادم MySQL الجديدة التي تم إنشاؤها في مناطق Azure التي تدعم تخزين الأغراض العامة v2، يتوفر دعم التشفير باستخدام مفاتيح مدير العملاء. لن يتأهل خادم Point In Time Restored (PITR) أو قراءة النسخة المتماثلة على الرغم من أنها "جديدة" من الناحية النظرية.
    • للتحقق من صحة إذا كان خادمك المخصص للتخزين للأغراض العامة v2، يمكنك الانتقال إلى جزء مستوى التسعير في المدخل ورؤية الحد الأقصى لحجم التخزين المدعوم من الخادم المقدم لديك. إذا كان بإمكانك نقل شريط التمرير حتى 4 تيرابايت، فإن الخادم الخاص بك يعمل على التخزين للأغراض العامة v1 ولن يدعم التشفير باستخدام المفاتيح المدارة من قبل العميل. ومع ذلك، يتم تشفير البيانات باستخدام مفاتيح مدارة من خلال الخدمة في جميع الأوقات. يرجى التواصل مع AskAzureDBforMySQL@service.microsoft.com إن كانت لديك أي أسئلة.

  • التشفير مدعوم فقط مع مفتاح التشفير RSA 2048.

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