تشفير النسخ الاحتياطية الخاصة بنا: الوصول إلى خط النهاية هذا

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

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

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

كانت هناك بعض الأشياء المهمة في عيني أثناء اختبار هذا النهج:

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

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

تتبع وقت النسخ الاحتياطي

يستخدم SendGrid الجرافيت لمقاييس البنية التحتية الخاصة به ، وبينما يتم إرسال الغالبية العظمى عبر Sensu ، فإن الجرافيت سهل بما يكفي لإرسال المقاييس مباشرةً عبر خطوط bash - وهو مناسب جدًا نظرًا لأن البرامج النصية الاحتياطية في bash. لاحظ أن إرسال المقاييس إلى Graphite مباشرةً ليس قابلاً للتطوير بدرجة كبيرة ، ولكن نظرًا لأن هذه النسخ الاحتياطية تعمل مرة واحدة على الأكثر في الساعة ، فقد كان ذلك مناسبًا لاحتياجاتي.

اتضح أن هذا الجزء سهل نسبيًا.

لشرح ما حدث في هذا السطر الأخير ، أرسل Graphite مسار المقياس الذي أرسله (تأكد من أنه فريد) ، وقيمة المقياس ، ثم الوقت الحالي بتنسيق العصر. Netcat هو ما قررت استخدامه للبساطة ، وأعطيته مهلة ثانية واحدة لأنه ، وإلا فلن يخرج أبدًا. "عنوان url الخاص بالجرافيت" هو نقطة نهاية DNS الخاصة بنا للجرافيت في مركز البيانات.

الآن بعد أن أصبح لدي خط أساس للمقارنة به ، كنا مستعدين لبدء اختبار طرق التشفير.

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

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

نجحت الاختبارات باستخدام قواعد بيانات صغيرة جدًا ، بضع مئات من الميغابايت. تعمل الأداة كما هو متوقع وموثق ، ولكن هذا كان أكثر من اختبار وظيفي والسؤال الحقيقي كان "ما هو حجم عقوبة التشفير على قواعد البيانات الأكبر لدينا؟" نمت المثيلات الأكثر إرثًا في SendGrid إلى أحجام من 1-2 تيرابايت إلى وحش واحد 18 تيرابايت. ما كنت سأستخدمه للحالات الصغيرة يجب أن يكون أيضًا مقبولًا من الناحية التشغيلية في الحالات الأكبر.

هذا هو المكان الذي أصبحت فيه الاختبارات والمعايير مثيرة للاهتمام

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

في ذلك الوقت ، كانت قواعد البيانات هذه تستخدم 512 ميجا بايت كحجم ملف سجل العمليات ، وهذه مجموعة مشغولة إلى حد ما ، لذلك كانت هذه الملفات تدور كل دقيقة تقريبًا. عادة ، سيكون هذا ملحوظًا في أداء قاعدة البيانات ، لكنه كان محجوبًا في الغالب بعجائب محركات الأقراص ذات الحالة الصلبة. يبدو أن عدم تعيين أي سلاسل تشفير متوازية (اقرأ: استخدم واحدًا) يعني أننا نقضي وقتًا طويلاً في تشفير ملفات `.ibd` التي كان يسجلها سجل الإعادة من داخلنا يجعل فاصل النسخ الاحتياطي.

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

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

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

كنا بحاجة إلى إعادة ذلك إلى إطار زمني أكثر منطقية.

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

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

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

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

منذ أن كنت جديدًا على gpg2 أيضًا ، أصبحت هذه فرصة تعلم بالنسبة لي. واصل Colin ، عضو فريق InfoSec الرائع لدينا ، اختبار النسخ الاحتياطية واستعادتها باستخدام gpg2 حتى أكد أن استخدام gpg2 له مزايا متعددة لاستخدام ضغط xtrabackup المدمج بما في ذلك:

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

دائما مجال للتحسين

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

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