تدقيق قواعد البيانات في The Grid

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

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

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

1. ما هي الخيارات المتاحة لدينا بقدر البرامج التي يمكنها القيام بذلك؟
2. ما هو تأثير الأداء المتوقع وكم يمكننا اختبار ذلك مسبقًا؟
3. هل يمكننا القيام بذلك دون توقف لتوافر الكتابة؟

الاختيارات والاختيارات

في SendGrid ، نتبع عملية مخطط التصميم لأي مشروع كبير أو مشترك بين الفريق. شارك في هذا المشروع عدد من الفرق كأصحاب المصلحة بما في ذلك:

• التدقيق الداخلي باعتباره الفريق المسؤول عن تحديد مخزن البيانات في نطاق رقابة الامتثال هذه ولجمع الأدلة يأتي وقت التدقيق
• InfoSec هو الفريق الذي كان من المفترض أن يقوم بتحليل ومعالجة الاستجابة للحوادث المستمدة من سجلات تدقيق قاعدة البيانات هذه
• DB Ops كفريق يكتب الكود الذي ينشر ويدير ويضبط هذه الميزة الجديدة لقواعد البيانات في النطاق

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

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

كانت خياراتنا:

• تدقيق البرنامج المساعد Percona
• مراجعة Mcafee MySQL

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

كان الأخير حلاً جديدًا تم فتحه مؤخرًا فقط بواسطة Mcafee وكان مثيرًا للاهتمام بما يكفي للنظر فيه لأنه ادعى أنه يدعم تصفية مستوى الجدول الذي لم يفعله المكون الإضافي Percona. نظرًا لأننا عرفنا أن إحدى مجموعات النطاق الخاصة بنا بحاجة فعليًا إلى تدقيق حوالي 24 جدولًا من إجمالي 300 ، يبدو أن هذه ميزة قيمة بما يكفي لجعل المكون الإضافي Mcafee منافسًا.

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

تراجع عن

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

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

من ناحية أخرى ، كان الحل الوسط Percona البرنامج المساعد. وهو يدعم إرسال الأحداث إلى سجل النظام محليًا ولكنه لا يوفر أي عوامل تصفية للجدول. لقد علمنا أن هذا يعني أن المجموعات الأكثر انشغالًا في النطاق سترسل عددًا كبيرًا من الأحداث ، ومعظمها ليس في الواقع من الجداول التي نريد تدقيقها. وقد شكل هذا خطرًا على طبقة syslog-Received / logstash الخاصة بمكدس مراقبة InfoSec. نظرًا لأن DB ops لا يمكنها الوصول إلى ذلك ، فهذا يعني أن نجاح هذا المشروع كان مسعى ملكية مشتركة.

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

تخطيط النشر

نطاق التثبيت

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

لا توقف

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

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

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

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

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

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

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

يراقب

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

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

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

قررنا مراقبة ما يلي:

• تحقق من تكوين mysql المباشر للمكوِّن الإضافي للتدقيق للتأكد من ذلك
  • كان المكون الإضافي في حالة نشطة
  • تم تعيين Audit_log_policy على QUERIES

يؤكد هذا الفحص أن قاعدة البيانات الموجودة في النطاق لم يتم تغيير تكوينها أثناء التنقل لأن هذه الإعدادات ديناميكية ويمكن أن تتغير خارج ملف my.cnf الموجود على القرص .

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

عقبات على طول الطريق

تدقيق تكوين البرنامج المساعد

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

تكوين rsyslog

هذا شيء لم أكن أعرفه قبل هذا المشروع. تكوين Rsyslog هو لغته الخاصة تقريبًا. علي سبيل المثال:

• استخدم علامة @ ثانية أمام الوجهة البعيدة لإرسال السجلات عبر TCP بدلاً من UDP. أردنا الاستفادة من هذه الميزة لمنح مزيد من الضمان لتسليم السجلات.
• يحتوي rsyslog على صفحة مخصصة حول كيفية تهيئته لإعادة التوجيه الموثوقة ، والتي أثبتت أنها مفيدة حقًا للمبتدئين في الأداة مثلي.
• سيقوم rsyslog ، بشكل افتراضي ، أيضًا بنقل بياناته إلى / var / log / messages وهو أمر غير مرغوب فيه في حالتي لأن هذا عدد كبير من الأحداث. إذا كنت بحاجة إلى جعل المنشأة التي تستخدمها لا تفعل ذلك ، فيجب عليك إضافة local5. * ~ إلى نهاية التكوين الخاص بك

تمرين إطفاء

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

• تأكد من أن أحداث التدقيق تتدفق عبر منفذ TCP المعين
• استخدم قاعدة iptables لإسقاط كل حركة المرور على هذا المنفذ / sbin / iptables -A OUTPUT -p tcp –dport {PORT-NUMBER-HERE} -j DROP
• شاهد نشاط الكتابة على القرص والملفات الموجودة في WorkDirectory الذي تم تكوينه في تكوين rsyslog . ستستند أسماء الملفات إلى ActionQueueFileName للمنشأة التي تتلقى هذه الأحداث

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

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

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