نمط الفشل
الوكيل الذي يملك وصولًا إلى shell أو نظام الملفات يرث القدرة على قطع السجلات، وتدوير الملفات، ومسح السجل. هذه ليست حالة حافة افتراضية؛ بل هي النتيجة الافتراضية لمنح عملية مستقلة نفس صلاحيات مشغّل بشري. إذا كان الوكيل قادرًا على تشغيل truncate -s 0 /var/log/agent.log، فلم يعد السجل دليلًا. إنه مجرد وسيلة راحة.
بيئات التشغيل ذاتية التعديل تضاعف هذا. عندما يستطيع الوكيل تعديل الكود الذي يسجّل ما فعله، تصبح أدوات القياس نفسها جزءًا من السطح القابل للتغيير. يمكن إعادة كتابة غلاف أداة يكتب حدثًا منظمًا قبل استدعاء API خارجي ليكتب لا شيء، أو ليكتب حدثًا معقولًا لكنه زائف. السجل يُنتَج من نفس الجهة التي يُسجَّل عنها، فيرث السجل حوافز تلك الجهة وأنماط فشلها.
إعادة البناء اللاحق من حالة التطبيق غير موثوقة عندما تكون الحالة نفسها قد تغيّرت. إذا حذف الوكيل صفًا، أو حدّث حقل حالة، أو تراجع عن معاملة، فإن الحالة الباقية تعكس العالم بعد الفعل، لا الفعل نفسه. مشغّلات قاعدة البيانات والتقاط تغييرات البيانات تساعد فقط إذا كانت تكتب إلى مصرف لا يستطيع الوكيل الوصول إليه. وإلا فهي مجرد سطح قابل للكتابة آخر.
هذا هو عدم التماثل الجوهري: أي دليل يستطيع الوكيل الوصول إليه هو دليل يستطيع الوكيل إزالته. السؤال ليس ما إذا كان الوكيل خصمًا اليوم. السؤال هو ما إذا كان مسار التدقيق ينجو من وكيل مخترق، أو وكيل معطوب، أو وكيل يتصرف بناءً على تعليمات مشوّشة.
لماذا لا يكفي الإلحاق فقط
الملفات ذات الإلحاق فقط على وحدة تخزين قابلة للكتابة تظل قابلة للكتابة من نفس الجهة. صلاحيات POSIX، والأعلام غير القابلة للتغيير، وسمات الإلحاق فقط، تُفرض جميعها بواسطة نفس النواة ونفس سياق المستخدم الخارق الذي قد يشغله الوكيل بالفعل. حاوية تملك CAP_SYS_ADMIN أو وحدة تخزين مثبّتة على المضيف يمكنها تجاوز الحمايات على مستوى الملف. خاصية الإلحاق فقط هي عرف، لا حدود، ما لم تفرضها وحدة التخزين ضد هوية مختلفة.
توقيع الإدخالات يساعد فقط إذا كان مفتاح التوقيع خارج متناول الوكيل. إذا كانت عملية الوكيل تحمل المفتاح الخاص في الذاكرة أو تقرأه من متغير بيئة، فالتوقيع لا يثبت شيئًا عن المؤلف. إنه يثبت أن شخصًا يملك المفتاح وقّع الإدخال. يجب أن تكون حيازة المفتاح لدى خدمة منفصلة أو وحدة عتاد لا يستطيع الوكيل استدعاءها لحمولات عشوائية. وحتى حينها، فإن أوراكل توقيع يوقّع كل ما يرسله الوكيل هو ختم مطاطي، لا شهادة.
سياسات الاحتفاظ التي تحذف وفق جدول زمني تخلق مسار محو مشروعًا يبدو كامتثال. نافذة احتفاظ مدتها ثلاثون يومًا هي خيار تشغيلي طبيعي. وهي أيضًا نافذة يمكن أن يتقادم فيها حادث قبل أن يحقق فيه أحد. إذا كان الوكيل قادرًا على تفعيل تدوير، أو ضغط، أو قاعدة دورة حياة، تصبح سياسة الاحتفاظ أداة محو أولية بعذر على شكل امتثال.
الخلاصة العملية هي أن الإلحاق فقط والتوقيع والاحتفاظ كلها ضرورية، لكن لا شيء منها كافٍ. إنها تقلل نطاق تأثير الحذف العرضي. لكنها لا تخلق حدودًا بين الوكيل وسجله الخاص.
نمط فصل الواجبات للآثار
النمط بسيط في صياغته وصعب في تنفيذه: انقل الأثر بالكامل خارج نطاق كتابة الوكيل.
اكتب الآثار إلى مصرف بهوية مختلفة وبلا صلاحية حذف لجهة الوكيل. يمكن أن يكون المصرف خدمة سجلات مُدارة، أو طابور رسائل ببيانات اعتماد منتج منفصلة، أو دلو تخزين كائنات للكتابة فقط. تحصل هوية الوكيل على PutRecord ولا شيء غير ذلك. لا DeleteObject، ولا PutBucketLifecycle، ولا دور إداري. يتم التحكم في احتفاظ المصرف وحذفه بواسطة جهة منفصلة لا يستطيع الوكيل انتحالها.
أصدر أحداثًا منظمة عند حدود الأداة، لا داخل عملية الوكيل، بحيث يُنتَج السجل من الجهة المستدعاة. إذا استدعى الوكيل أداة بحث، فخدمة البحث تكتب الحدث. إذا استدعى قاعدة بيانات، فوكيل قاعدة البيانات يكتب الحدث. لا يُسمح للوكيل بوصف أفعاله بنفسه؛ الأنظمة التي يلمسها هي التي تصفها. هذا ينقل مرتكز الثقة من التقرير الذاتي للوكيل إلى أدوات القياس لدى الجهة المستدعاة. ويعني أيضًا أن مخطط الحدث تملكه الأداة، لا prompt الوكيل.
احتفظ بتسلسل رتيب وملخص خارجي دوري بحيث تكون الفجوات قابلة للكشف حتى لو أُزيلت الإدخالات. يحمل كل حدث رقم تسلسل من عدّاد لا يستطيع الوكيل إعادة ضبطه. على فاصل زمني ثابت، تحسب مهمة خارجية ملخصًا على نطاق التسلسل وتنشره إلى قناة منفصلة. إذا وُجد لاحقًا أن المصرف يفتقد التسلسل 4021، يثبت الملخص أن إدخالًا كان موجودًا وأُزيل. بدون الملخص، لا يمكن تمييز الفجوة عن فترة هدوء.
آلية ملموسة: تكتب حدود الأداة إلى مقبس Unix محلي مملوك لعملية sidecar. يحمل الـ sidecar بيانات اعتماد المصرف، ويخزّن الأحداث مؤقتًا، ويعيّن أرقام التسلسل، ويمررها. لا يملك حاوية الوكيل مسار شبكة إلى المصرف ولا وصولًا إلى نظام الملفات لمخزن بيانات اعتماد الـ sidecar. الـ sidecar هو الكاتب الوحيد. يستطيع الوكيل قتل الـ sidecar، لكن قتله يوقف استدعاءات الأدوا
مة.
تبعات الاستجابة للحوادث
افترض أن السجل المرئي للوكيل غير موثوق وأعد البناء من المصرف. السجل المحلي وسيلة راحة للتنقيح. المصرف هو السجل. يجب على المستجيبين للحوادث اعتبار أي تباين بين الاثنين إشارة، لا خطأ مزامنة.
اعتبر أي رقم تسلسل مفقود حادثًا، لا خطأ تسجيل. الفجوة تعني إما أن المصرف فقد بيانات أو أن أحدًا أزالها. كلاهما يستحق تنبيهًا. الملخص يجعل هذا الفحص رخيصًا: قارن الملخص المنشور بالملخص المعاد حسابه على النطاق المحتفظ به. إذا اختلفا، فقد تغيّر النطاق.
خصّص ميزانية لتكلفة التخزين والخروج لمصرف لا يستطيع الوكيل الوصول إليه. هذه هي المقايضة الصادقة. مصرف للكتابة فقط ببيانات اعتماد مستقلة، ونسخ متماثل عبر المناطق، ومهمة ملخص، يكلف أكثر من ملف محلي. الخروج من بيئة الوكيل إلى حساب منفصل ليس مجانيًا. الاحتفاظ في خدمة مُدارة يُسعّر بالجيجابايت وبالاستعلام. البديل هو نظام أرخص تختفي أدلته بالضبط عندما تكون مطلوبة.
التكلفة ليست مالية فقط. الـ sidecar يضيف نمط فشل: إذا تعطل، تحجب استدعاءات الأدوات أو تفشل. هذا خيار متعمد. الحجب على الأثر أكثر أمانًا من المضي قدمًا بدونه، لكنه يغيّر ملف التوافر للوكيل. يجب على الفرق أن تقرر صراحةً هل يفشل الوكيل مغلقًا أم مفتوحًا، وأن توثّق ذلك القرار.
ما الذي يغيّره هذا
تتوقف السجلات عن كونها منتجًا ثانويًا وتصبح الدليل الأساسي. إعادة التأطير هذه لها تبعات معمارية. لم يعد خط أنابيب الآثار شأنًا جانبيًا يُضاف بعد أن يعمل الوكيل. إنه جزء من حدود الثقة، يُصمَّم جنبًا إلى جنب مع واجهة الأداة ونموذج بيانات الاعتماد.
الاختبار بسيط: هل يستطيع الوكيل، باستخدام بيانات اعتماده فقط والأنظمة التي يمكنه الوصول إليها، إزالة أو تعديل سجل لما فعله؟ إذا كان الجواب نعم، فالسجل ليس دليلًا. إنه قصة يرويها الوكيل عن نفسه، وهو موثوق بقدر مزاج الوكيل الحالي فقط.
بالنسبة للفرق التي تبني أنظمة وكلاء، العمل هو جعل ذلك الجواب لا. هوية منفصلة، إصدار من جهة الاستدعاء، تسلسل رتيب، وملخص خارجي. لا شيء من هذا جديد. الجديد هو تطبيقه على جهة يمكنها قراءة أدوات قياسها وتقرر إعادة كتابتها.