Bir cihazın günlüklerini uzak toplayıcıya güvenle nasıl gönderirsiniz

Cihaz günlük üretebiliyor, toplayıcı internetin diğer tarafında duruyor ve herkesin sorduğu ilk soru hangi tünelin kurulacağı. Bu çerçeve yanlış yerden başlıyor. Taşımayı belirleyen, cihazın üretebildiği biçim, toplayıcının kabul edeceği kimlik doğrulama ve bağlantı düştüğünde “teslim edildi”nin ne anlama gelmesi gerektiğidir. Bu üç yanıtı yazın, taşıma genellikle kendini seçer.

Cihazın üretebildiğiyle başlayın

Pratikte yalnızca üç biçim var. UDP veya TCP üzerinden tek tek syslog olayları, ürüne gömülü kimlik doğrulamalı HTTPS yüklemesi ya da diske yazılıp taşınması gereken tam dosyalar. Yalnızca UDP syslog gönderebilen bir güvenlik duvarı, tünel eklediğiniz için TLS göndericisi olmaz; onaysız datagramları göndermeye devam eder, artık şifreli bir zarfın içinde.

Öyleyse önce göndericiyi envanterleyin: protokol, TLS desteği ve hangi TLS kitaplığı, toplayıcının sertifikasını doğrulayabiliyor mu, istemci sertifikası sunabiliyor mu ve gönderme tamponu yeniden başlatmaya dayanıyor mu. Cihazın yapamadığı her şeyi yolda başka bir şey yapmalı ve o başka şey tasarımınızın parçası olur.

TLS syslog: iki uç da konuştuğunda en kısa yol

Cihaz TLS üzerinden syslog destekliyorsa ve toplayıcı bunu sonlandırıyorsa, bunu kullanın ve durun. Uygulama protokolü kendini korur, toplayıcı göndericiyi doğrular ve artık kullanılabilirliğini üstlendiğiniz ekstra bir atlama yoktur. Tuzak, “TLS syslog”un geniş bir uygulama yelpazesini kapsamasıdır ve güvenli syslog için güncel yönergeler eski eğitimlerdeki şifre listelerinin ötesine geçti; bu yüzden çalışan bir iletici kitaplık güncellemesinden sonra bozulur.

rsyslog'da taşıma modülünün adı hangi çağda olduğunuzu söyler: lmnsd_gtls GnuTLS'i sarar, lmnsd_ossl ise OpenSSL'i sarar ve güncel 8.x paketleri bunu sağlar. Sertifika doğrulamalı bir iletme işlemi yaklaşık böyle görünür ve tam parametre adlarını kurulu sürümünüzle karşılaştırmaya değer:

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")

Göndericide hata ayıklamadan önce uç noktayı doğrulayın. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error ya geçerli bir zincirle el sıkışmayı tamamlar ya da hangi denetimin başarısız olduğunu tam olarak söyler. Cihazdan test edin, dizüstü bilgisayarınızdan değil, çünkü önemli olan cihazın güven deposudur.

SFTP: dosyalar için iyi, akışlar için yanlış

Dosya tabanlı teslimat, yalnızca dönen günlükler yazan cihazlara uygundur. SSH tabanlı aktarım size ana makine anahtarları, hesap başına anahtarlar ve denetleyebileceğiniz bir dosya sistemi verir; bu, TLS'i hiç yapamayan bir cihaz için makul bir güven öyküsüdür. Olay akışları için kötü bir seçimdir; burada “dosya her saat yazılır” ifadesi bir kesintinin size geçerli saatin kuyruğunu kaybettirdiği anlamına gelir.

Ana makine doğrulamasını açık tutun. Bir istemden kaçınmak için onu kapatan toplu çağrı, taşımanın sahip olduğu tek kimlik doğrulamayı yok eder:

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

Hazırlık sırasında ana makine anahtarını hesabın known_hosts dosyasına sabitleyin, hesabı hedef dizinle sınırlayın ve chroot'lu internal-sftp alt sistemini tercih edin. Yeniden gönderme öyküsünü de planlayın: kısmi bir hatadan sonra bir dosya yeniden gönderilirse, toplayıcı bir kopyayı yeni dosyadan ayırt edebilmelidir; genellikle varış zamanıyla değil, ad artı sağlama toplamıyla.

Yerel ağ geçidi veya tünel dürüst yanıt olduğunda

Bazı cihazlar yalnızca kimsenin açığa çıkarmak istemediği bir biçimde konuşabilir. Bu durumda cihazın kendi ağındaki yetkili bir toplayıcı yerel biçimi alır ve TLS üzerinden ileri iletir. Bu meşru bir tasarımdır, ancak ne satın aldığı konusunda kesin olun: ağ geçidinde başlayan şifreleme, cihaz ile ağ geçidi arasındaki bölümü geriye dönük korumaz; bu nedenle o atlamanın hâlâ kendi güven sınırına ve erişim denetimine ihtiyacı vardır.

Yönlendirilmiş site veya cihaz tüneli en ağır seçenektir ve toplayıcının özel bir adresi koruması gerektiğinde ve yalnızca günlükleri değil birkaç hizmeti taşıması gerektiğinde doğru olandır. Adres planlaması, erişim kuralları, dönüş yolları ve tünel uç noktasının yaşam döngüsünü getirir. İç protokolü de iyileştirmez: IPsec tüneli içindeki UDP syslog, teslimat onayı olmayan bir datagram hizmeti olarak kalır.

Ne seçerseniz seçin, toplayıcı yetkisini taşımadan daha dar tutun. Tünel kimliği bir uç noktaya aittir ve mesajdaki belirli bir ana makine adı alanını hangi alt cihazın ürettiği hakkında hiçbir şey söylemez.

Göndermeden önce teslimat sözleşmesini yazın

Şifreleme, kimlik doğrulama ve saklama farklı soruları yanıtlar ve kuyruk bir saklama politikası değildir. İlk günlük cihazdan çıkmadan önce, bu toplayıcıda onayın gerçekte ne anlama geldiğine karar verin: hatta alındı, işlenmek üzere kabul edildi veya depoya dayanıklı biçimde yazıldı. Bunlar üç farklı garantidir ve yalnızca sonuncusu toplayıcının yeniden başlatılmasına dayanır.

Sonra operasyonel soruları yazılı olarak yanıtlayın. Gönderilmemiş olaylar nerede bekler ve bu tampon elektrik kesintisine dayanır mı? Dolduğunda ne olur ve kime bildirilir? Yeniden denemeler nasıl sınırlanır ve kopyalar nasıl tanımlanır? İletme atlaması ana makine adını yeniden yazabildiğine göre, hangi alan göndericinin kimliğini kanıtlar?

Tasarımı tek paragrafta açıklanabilecek kadar küçük tutun: gerekli olayları taşıyan en küçük desteklenen taşıma, artı sağlamadığı garantilerin açık bir beyanı. Yanıt iki atlama gerektiriyorsa bunu runbook'ta söyleyin ve her atlamaya bir sahip atayın.