كيف ترسل سجلات الأجهزة إلى مجمع بعيد بأمان

يستطيع الجهاز إصدار السجلات، ويقع المجمع على الجانب الآخر من الإنترنت، وأول سؤال يطرحه الجميع هو أي نفق نبني۔ هذا التأطير يبدأ من المكان الخطأ۔ ما يحدد النقل هو التنسيق الذي يمكن للجهاز إنتاجه، والمصادقة التي سيقبلها المجمع، وما يُفترض أن تعنيه كلمة “تم التسليم” عندما ينقطع الرابط۔ دوّن تلك الإجابات الثلاث، وعندئذ يختار النقل نفسه عادةً۔

ابدأ مما يستطيع الجهاز إصداره

لا توجد في الممارسة سوى ثلاثة أشكال۔ أحداث syslog فردية عبر UDP أو TCP، أو رفع HTTPS موثّق مدمج في المنتج، أو ملفات كاملة تُكتب على القرص ويجب نقلها۔ الجدار الناري الذي لا يستطيع إلا إرسال syslog عبر UDP لن يصبح مرسلاً TLS لأنك أضفت نفقاً؛ سيظل يرسل حزم بيانات غير مؤكدة، لكن داخل غلاف مشفّر الآن۔

لذا احصر المرسل أولاً: البروتوكول، ودعم TLS وأي مكتبة TLS، وهل يستطيع التحقق من شهادة المجمع، وهل يستطيع تقديم شهادة عميل، وهل ينجو مخزن الإرسال من إعادة التشغيل۔ وأي شيء لا يستطيع الجهاز فعله يجب أن يفعله شيء آخر في المسار، وذلك الشيء الآخر يصبح جزءاً من تصميمك۔

سجلات TLS عبر syslog: أقصر مسار عندما يتحدث الطرفان به

إذا كان الجهاز يدعم syslog عبر TLS وينهي المجمع ذلك، فاستخدمه وتوقّف۔ يحمي بروتوكول التطبيق نفسه، ويتحقق المجمع من المرسل، ولا توجد قفزة إضافية تملك توافرها الآن۔ المفاجأة أن “syslog عبر TLS” يغطي طيفاً واسعاً من التطبيقات، وإرشادات syslog الآمن الحالية تجاوزت قوائم الشيفرات في الدروس القديمة، وهكذا يتحول مُمرِّر عامل إلى مُمرِّر معطّل بعد ترقية مكتبة۔

في rsyslog، اسم وحدة النقل وحده يخبرك بأي حقبة أنت: lmnsd_gtls يلفّ GnuTLS، بينما lmnsd_ossl يلفّ OpenSSL وهو ما تشيعه حزم 8.x الحالية۔ إجراء توجيه مع التحقق من الشهادة يبدو تقريباً هكذا، وتستحق أسماء المعاملات الدقيقة التحقق مقابل النسخة المثبتة لديك:

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

تحقّق من الطرف قبل أن تنقّح المرسل۔ openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error إما يكمل مصافحة بسلسلة صالحة أو يخبرك بدقة أي فحص فشل۔ اختبر من الجهاز، لا من حاسوبك المحمول، لأن مخزن الثقة الخاص بالجهاز هو المهم۔

SFTP: مناسب للملفات، وخاطئ للتدفقات

التسليم القائم على الملفات يناسب الأجهزة التي تكتب سجلات مُدوّرة ولا شيء غير ذلك۔ يمنحك النقل القائم على SSH مفاتيح المضيف ومفاتيح لكل حساب ونظام ملفات يمكنك تدقيقه، وهي قصة ثقة معقولة لجهاز لا يستطيع TLS إطلاقاً۔ وهو خيار رديء لتدفقات الأحداث، حيث يعني “يُكتب الملف كل ساعة” أن انقطاعاً يكلفك ذيل الساعة الحالية۔

أبقِ التحقق من المضيف مفعّلاً۔ استدعاء دفعة يوقفه لتجنّب مطالبة يبطل المصادقة الوحيدة التي يملكها النقل:

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

ثبّت مفتاح المضيف في known_hosts الخاص بالحساب أثناء التجهيز، وقيّد الحساب بالدليل الهدف، وفضّل نظام internal-sftp الفرعي مع chroot۔ وخطّط أيضاً لقصة إعادة الإرسال: إذا أُعيد إرسال ملف بعد فشل جزئي، فيجب أن يميز المجمع النسخة المكررة من الملف الجديد، عادةً بالاسم مع المجموع الاختباري لا بوقت الوصول۔

عندما تكون البوابة المحلية أو النفق هي الجواب الصادق

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

نفق موقع أو جهاز موجّه هو الخيار الأثقل والصحيح عندما يجب أن يحتفظ المجمع بعنوان خاص ويحمل عدة خدمات، لا السجلات فقط۔ يجلب تخطيط العناوين وقواعد الوصول ومسارات العودة ودورة حياة طرف النفق۔ ولا يحسّن البروتوكول الداخلي: فـ syslog عبر UDP داخل نفق IPsec يبقى خدمة حزم بيانات بلا إقرار تسليم۔

أياً ما تختار، أبقِ تفويض المجمع أضيق من النقل۔ هوية النفق تنتمي إلى طرف، ولا تقول شيئاً عن أي جهاز أدنى أنتج حقل اسم مضيف معيناً في رسالة۔

اكتب عقد التسليم قبل أن تسلّم

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

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

أبقِ التصميم صغيراً بما يكفي لشرحه في فقرة واحدة: أصغر نقل مدعوم يحمل الأحداث المطلوبة، مع بيان صريح للضمانات التي لا يوفرها۔ وإذا كان الجواب يحتاج قفزتين، فقل ذلك في دليل التشغيل وأعطِ كل قفزة مالكاً۔