systemd-journal-remote ile Merkezi Loglama: mTLS ve Retention

Kurumsal altyapıda loglama iki uç arasında sıkışır:

• “Her host’a agent kuralım, her şeyi dışarı basalım” → maliyet/karmaşıklık artar
• “Local’de kalsın” → incident’ta kanıt kaybolur, korelasyon zorlaşır

systemd ekosistemi, birçok Linux dağıtımında zaten var. Bu yazıda, systemd-journal-upload + systemd-journal-remote ile journald loglarını mTLS üzerinden merkezi toplayıp, retention/disk bütçesi disipliniyle işletmenin pratik yolunu anlatıyorum.

1) Mimari karar: journal-remote nerede durmalı?

Sahada en stabil topoloji:

• Her host: journald (zaten var) + systemd-journal-upload
• Merkez: 2 adet log gateway (HA) + disk budget + backpressure

Bu gateway katmanı:

• mTLS terminasyonu yapar
• allow list uygular (kim log basabilir?)
• local storage’da “ham kanıt” saklar (incident için)
• isterse downstream’e (Loki/ELK/SIEM) forward eder

2) Güvenlik: mTLS ve kimlik modeli

En sık yapılan hata, log endpoint’ini “iç ağda” diye açık bırakmaktır. Log akışı da bir saldırı yüzeyidir.

Minimum model:

• Gateway’de TLS zorunlu
• Client cert ile kimlik (mTLS)
• Sertifika CN/SAN üzerinden host identity (örn. host=web-12.prod)
• Rate limit / connection limit (log fırtınasında kendini koru)

3) Kurulum (özet adımlar)

Komutlar dağıtıma göre değişebilir. Buradaki hedef runbook akışıdır.

A) Gateway: systemd-journal-remote

• HTTPS listener
• Storage dizini
• Sertifika/anahtar

Kontrol:

systemctl status systemd-journal-remote
ss -lntp | rg -n "19532|journal" || true

B) Client: systemd-journal-upload

• Gateway URL
• Client certificate
• Retry/backoff

Kontrol:

systemctl status systemd-journal-upload
journalctl -u systemd-journal-upload -n 50 --no-pager

4) Retention: “sonsuz disk” yok, politika var

Merkezi log katmanının en kritik kararı retention’dır:

• Kaç gün ham log tutulacak? (örn. 7/14/30)
• Disk dolunca ne olacak? (drop mı, rotate mı, backpressure mı)
• Compliance kapsamı var mı? (WORM/S3 Object Lock gibi ayrı katman gerekir mi)

Pratik yaklaşım:

• Gateway’de kısa retention (incident kanıtı için)
• Uzun retention gerekiyorsa downstream archiving (object storage)

5) Operasyon: hangi sinyalleri izleyeceğim?

• Gateway disk usage + inode
• Upload queue/backpressure (varsa)
• TLS handshake error rate (sertifika rotasyonu sorunları)
• Client başarısız upload sayısı (kayıp kanıt riski)

Bu sinyaller “loglama çalışıyor” demenin gerçek karşılığıdır.

6) Incident runbook: “log gelmiyor” dediğinde

1. Client tarafı:
   • systemd-journal-upload çalışıyor mu?
   • TLS hatası var mı? (sertifika süresi, chain)
   • DNS/route var mı? (gateway erişimi)
2. Gateway tarafı:
   • servis ayakta mı?
   • disk dolu mu?
   • connection limit’e takılıyor mu?
3. Mitigasyon:
   • disk baskısı varsa retention’ı geçici daralt
   • sertifika sorunu varsa acil “known-good” cert ile dön
4. Kalıcı önlem:
   • sertifika rotasyon otomasyonu
   • disk budget + alarm
   • downstream arşiv (compliance gerekiyorsa)

Sonuç

systemd-journal-remote ile merkezi loglama; “yeni bir agent” projesi olmadan kanıt zincirinizi güçlendirmenin düşük sürtünmeli yoludur. Sahada değer; servisi kurmakta değil, mTLS kimlik modeli, retention/disk bütçesi ve incident runbook disiplinini birlikte işletmekte ortaya çıkar. Log, sadece debug değil; operasyonel gerçekliğin kanıtıdır.