تدقيق قواعد البيانات في الشبكة الجزء 2: ملاحظات ما بعد النشر

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

البيانات المعدة وتصفية فئة الأوامر

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

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

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

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

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

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

أداء

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

لكن لا شيء يخلو من إيجابيات وسلبيات.

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

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

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

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

القرارات السابقة تؤتي ثمارها

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

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

لكننا أيضًا لم نرغب في التخطيط على أساس أوقات "التشغيل العادي" فقط.

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

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

المفاضلات

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

ولكن كان هذا يعني استهلاكًا كبيرًا لعمليات الإدخال والإخراج على القرص من جانب قاعدة البيانات والذي كنا نعلم أنه يمكن أن يؤثر على جودة خدمة المكالمات الموجهة للعملاء لقواعد البيانات هذه.

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

أخيرا

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