فهم التغييرات في تغيير المرجع المصدق الجذر لقاعدة بيانات Azure ل MariaDB

مقالة
03/10/2023

هام

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

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

إشعار

تحتوي هذه المقالة على مراجع لمصطلح slave، وهو مصطلح لم تعد Microsoft تستخدمه. عند إزالة المصطلح من البرنامج، بالتالي سنزيله من هذه المقالة.

لماذا يتطلب تحديث شهادة الجذر؟

يمكن لمستخدمي Azure Database for MariaDB استخدام الشهادة المعرفة مسبقا فقط للاتصال بخادم MariaDB الخاص بهم، الموجود هنا. ومع ذلك، نشر منتدي مستعرض المرجع المصدق مؤخرًا تقارير من شهادات متعددة صادرة عن الموردين CA لتكون غير متوافقة.

وفقًا لمتطلبات التوافق الخاصة بالمجال، بدأ موردو CA في إبطال شهادات CA لـ CAs غير المتوافقة، مما يتطلب من الخوادم استخدام الشهادات الصادرة عن CA المتوافقة والموقعة بواسطة شهادات CA من تلك CAs المتوافقة. نظرا لأن Azure Database for MariaDB استخدمت إحدى هذه الشهادات غير المتوافقة، فقد احتجنا إلى تدوير الشهادة إلى الإصدار المتوافق لتقليل التهديد المحتمل لخوادم MySQL.

هل أنا بحاجة إلى إجراء أي تغييرات على العميل للحفاظ على الاتصال؟

إذا اتبعت الخطوات المذكورة ضمن Create a combined CA certificate أدناه، فيمكنك متابعة الاتصال ما دام لم تتم إزالة شهادة BaltimoreCyberTrustRoot من شهادة CA المدمجة. للحفاظ على الاتصال، نوصي بالاحتفاظ بـ BaltimoreCyberTrustRoot في شهادة المرجع المصدق المدمجة حتى إشعار آخر.

إنشاء شهادة CA مجمعة

تنزيل BaltimoreCyberTrustRoot وDigiCertGlobalRootG2 CA من الروابط أدناه:
- https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem
- https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem
أنشئ متجراً مدمجاً لشهادات CA مع تضمين شهادتي BaltimoreCyberTrustRoot وDigiCertGlobalRootG2.
- بالنسبة لمستخدمي Java (MariaDB الاتصال or/J)، نفذ:
```
keytool -importcert -alias MariaDBServerCACert  -file D:\BaltimoreCyberTrustRoot.crt.pem  -keystore truststore -storepass password -noprompt
```
```
keytool -importcert -alias MariaDBServerCACert2  -file D:\DigiCertGlobalRootG2.crt.pem -keystore truststore -storepass password  -noprompt
```
  ثم استبدل ملف keystore الأصلي بالملف الجديد الذي تم إنشاؤه:
  - System.setProperty("javax.net.ssl.trustStore","path_to_truststore_file");
  - System.setProperty("javax.net.ssl.trustStorePassword","password");
- بالنسبة لمستخدمي .NET (MariaDB الاتصال or/NET، MariaDB الاتصال or)، تأكد من وجود كل من BaltimoreCyberTrustRoot وDigiCertGlobalRootG2 في متجر شهادات Windows، المراجع المصدقة الجذر الموثوق بها. في حال لم تكن هناك أي شهادات، قم باستيراد الشهادة المفقودة.
- بالنسبة لمستخدمي .NET على Linux الذين يستخدمون SSL_CERT_DIR، تأكد من وجود كل من BaltimoreCyberTrustRoot و DigiCertGlobalRootG2 في الدليل المشار إليه بواسطة SSL_CERT_DIR. في حال لم تكن هناك أي شهادات، قم باستيراد الشهادة المفقودة.
- بالنسبة للمستخدمين الآخرين (عميل MariaDB/MariaDB Workbench/C/C++/Go/Python/Ruby/PHP/NodeJS/Perl/Swift)، يمكنك دمج ملفي شهادة CA مثل هذا التنسيق أدناه
```
-----BEGIN CERTIFICATE-----
(Root CA1: BaltimoreCyberTrustRoot.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
```
استبدل ملف «pem» المرجع المصدق الجذر الأصلي بملف المرجع المصدق الجذر المدمج ثم أعد تشغيل التطبيق/العميل.
وفيما بعد، بعد توزيع الشهادة الجديدة على جانب الخادم، يمكنك تغيير ملف CA pem إلى DigiCertGlobalRootG2.crt.pem.

إذا كنت لا أستخدم SSL/TLS، فهل ما زلتُ بحاجة إلى تحديث المرجع المصدق الجذر؟

لا يتطلب اتخاذ أي إجراءات إذا كنت لا تستخدم SSL/TLS.

ماذا يحدث لو قمنا بإزالة شهادة BaltimoreCyberTrustRoot؟

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

الأسئلة الشائعة

1. إذا كنت لا أستخدم SSL/TLS، فهل ما زلت بحاجة إلى تحديث المرجع المصدق الجذر؟

لا توجد إجراءات مطلوبة إذا كنت لا تستخدم SSL/TLS.

2. إذا كنت أستخدم SSL/TLS، فهل أحتاج إلى إعادة تشغيل خادم قاعدة البيانات لتحديث المرجع المصدق الجذر؟

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

3. كيف أعرف ما إذا كنت أستخدم SSL/TLS مع التحقق من شهادة الجذر؟

بإمكانك تحديد ما إذا كانت اتصالاتك تتحقق من شهادة الجذر من خلال مراجعة سلسلة الاتصال الخاصة بك.

إن كانت سلسلة الاتصال الخاصة بك تتضمن sslmode=verify-ca أو sslmode=verify-identity، فأنت بحاجة إلى تحديث الشهادة.
إذا كانت سلسلة الاتصال تتضمن sslmode=disable أو sslmode=allow أو sslmode=prefer أو sslmode=require, فأنت تحتاج إلى تحديث الشهادات.
إذا لم تحدد سلسلة الاتصال «sslmode»، فلن تحتاج إلى تحديث الشهادات.

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

4. ما هو التأثير في حالة استخدام App Service مع قاعدة بيانات Azure ل MariaDB؟

بالنسبة لخدمات تطبيق Azure، الاتصال بقاعدة بيانات Azure ل MariaDB، هناك سيناريوهان محتملان اعتمادا على كيفية استخدام SSL مع التطبيق الخاص بك.

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

5. ما هو التأثير في حالة استخدام خدمات Azure Kubernetes (AKS) مع قاعدة بيانات Azure ل MariaDB؟

إذا كنت تحاول الاتصال بقاعدة بيانات Azure ل MariaDB باستخدام خدمات Azure Kubernetes (AKS)، فهي مشابهة للوصول من بيئة مضيفة مخصصة للعملاء. راجع الخطوات هنا.

6. ما هو التأثير إذا كان استخدام Azure Data Factory للاتصال بقاعدة بيانات Azure ل MariaDB؟

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

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

7. هل أحتاج إلى وقت تعطل للصيانة خادم قاعدة البيانات من أجل هذا التغيير؟

‏‏لا. نظرا لأن التغيير هنا فقط من جانب العميل للاتصال بخادم قاعدة البيانات، فلا يوجد وقت تعطل للصيانة مطلوب لخادم قاعدة البيانات لهذا التغيير.

8. كم مرة تقوم Microsoft بتحديث شهاداتها أو ما هو نهج انتهاء الصلاحية؟

يتم توفير هذه الشهادات المستخدمة من قبل قاعدة بيانات Azure ل MariaDB من قبل المراجع المصدقة الموثوق بها (CA). لذلك يرتبط دعم هذه الشهادات بدعم هذه الشهادات من قبل المرجع المصدق. من المُقرر أن تنتهي صلاحية شهادة BaltimoreCyberTrustRoot في عام 2025، لذلك تحتاج Microsoft إلى إجراء تغيير الشهادة قبل انتهاء الصلاحية.

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

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

10. إذا كنت أستخدم النسخ المتماثل للبيانات، فهل أحتاج إلى تنفيذ أي إجراء؟

إذا كان النسخ المتماثل للبيانات من جهاز ظاهري (محلي أو جهاز ظاهري Azure) إلى قاعدة بيانات Azure ل MySQL، فستحتاج إلى التحقق مما إذا كان يتم استخدام SSL لإنشاء النسخة المتماثلة. شغّل SHOW SLAVE STATUS وتحقق من الإعداد التالي.
```
Master_SSL_Allowed            : Yes
Master_SSL_CA_File            : ~\azure_mysqlservice.pem
Master_SSL_CA_Path            :
Master_SSL_Cert               : ~\azure_mysqlclient_cert.pem
Master_SSL_Cipher             :
Master_SSL_Key                : ~\azure_mysqlclient_key.pem
```

في حال كنت تستخدم النسخ المتماثل للبيانات للاتصال بـAzure Database for MySQL، فهناك أمران يجب مراعاتهما:

إذا كان النسخ المتماثل للبيانات من جهاز ظاهري (محلي أو جهاز ظاهري Azure) إلى قاعدة بيانات Azure ل MySQL، فستحتاج إلى التحقق مما إذا كان يتم استخدام SSL لإنشاء النسخة المتماثلة. شغّل SHOW SLAVE STATUS وتحقق من الإعداد التالي.
```
Master_SSL_Allowed            : Yes
Master_SSL_CA_File            : ~\azure_mysqlservice.pem
Master_SSL_CA_Path            :
Master_SSL_Cert               : ~\azure_mysqlclient_cert.pem
Master_SSL_Cipher             :
Master_SSL_Key                : ~\azure_mysqlclient_key.pem
```
إذا رأيت أن الشهادة متوفرة CA_file SSL_Cert SSL_Key، فستحتاج إلى تحديث الملف عن طريق إضافة الشهادة الجديدة وإنشاء ملف شهادة مدمج.
إذا كان النسخ المتماثل للبيانات بين قاعدة بيانات Azure ل MySQL، فستحتاج إلى إعادة تعيين النسخة المتماثلة عن طريق تنفيذ CALL mysql.az_replication_change_master وتوفير شهادة الجذر المزدوج الجديدة كمعلمة أخيرة master_ssl_ca.

11. هل لدينا استعلام من جانب الخادم للتحقق من استخدام SSL؟

وللتحقق مما إذا كنت تستخدم اتصال SSL للاتصال بالخادم، راجع التحقق من SSL.

12. هل يلزمني أية إجراءات في حال إن كان لدي DigiCertGlobalRootG2 بالفعل في ملف الشهادة الخاص بي؟

‏‏لا. لا يتطلب اتخاذ أي إجراء إذا كان ملف الشهادة يحتوي بالفعل على DigiCertGlobalRootG2.

13. ماذا لو كانت لدي أسئلة أخرى؟

إذا كانت لديك أسئلة، فاحصل على إجابات من خبراء المجتمع في Microsoft Q&A. في حال امتلاكك خطة دعم وحاجتك إلى مساعدة فنية، تواصل معنا:

Share via