Kurumsal ortamlarda en pahalı güvenlik borçlarından biri şudur: “Root erişimi var ama kayıt yok.” Jump host/bastion kurmak tek başına yeterli değildir. Çünkü bastion, kayıt üretmiyorsa sadece “geçiş noktası” olur; denetim ve olay inceleme değerini üretmez.
Bu yazı, üretimde sahada en çok iş gördüğüm oturum kaydı bileşenlerini bir araya getirir:
- SSH ile bastion’a giriş
- TTY/terminal seviyesinde oturum kaydı (tlog gibi)
- Ayrıcalık yükseltme ve komut yürütme kayıtları (sudo I/O logging)
- Merkezi log hattı + erişim modeli + saklama
1) Hedefler: neyi kaydediyoruz, neyi kaydetmiyoruz?
Hedef:
- Kim bağlandı? (identity)
- Nereye gitti? (target)
- Ne yaptı? (komut + çıktı/etkileşim)
- Ne zaman yaptı? (zaman çizgisi)
- Kimin onayıyla yaptı? (ticket/break-glass)
Kaydetmemeniz gerekenler:
- Parolalar/secrets (mümkün olduğunca maske)
- Key material (private key) — zaten bastion’da olmamalı
2) SSHD hardening: kayıt için doğru temel
Temel SSHD yaklaşımı:
- Parola ile login kapalı (
PasswordAuthentication no) - Root login kapalı (
PermitRootLogin no) - Sadece yönetim segmentinden erişim (network policy/firewall)
- MFA/SSO (mümkünse) + kısa ömürlü sertifika/anahtar
SSHD tarafında “kayıt üretmek” tek başına yetmez; kayıt katmanını PAM / shell wrapper / terminal recorder üzerinden kurmak daha pratik olur.
3) tlog ile terminal oturum kaydı (genel yaklaşım)
Dağıtıma göre paket adı değişebilir. Ama konsept aynı:
- Kullanıcı bastion’a girer
- Shell açılmadan önce tlog devreye girer
- Oturum I/O’su (komut/çıktı) JSON gibi bir formatta yazılır
- Log collector bunu merkezi hatta taşır
Uygulama checklist’i:
- tlog kurulumu
- PAM entegrasyonu (login sırasında tlog)
- Oturum kayıtlarının yazılacağı dizin ve izinler (root-only)
- Log shipping (ör. Vector/Fluent Bit/rsyslog)
4) sudo I/O logging: “root olduktan sonra” kör kalma
Birçok ekip sadece SSH login’i kaydediyor; ama asıl kritik aksiyonlar sudo sonrası geliyor.
Sudo tarafında hedef:
- Komut + stdout/stderr kaydı
- I/O log’ların standart dizinde tutulması
- Erişim ve saklama politikası
Sudoers tarafında (örnek yaklaşım, dağıtıma göre değişebilir):
Defaults log_outputDefaults iolog_dir=/var/log/sudo-ioDefaults use_pty
Bu, “komutu gördük” seviyesini “çıktıyı da gördük” seviyesine taşır.
5) Merkezi log hattı: SIEM için normalize et
Bastion oturum kaydı bir “güvenlik telemetrisi”dir. SIEM’e giderken şu alanlar standardize olmalı:
actor: kullanıcı (SSO id, e-mail veya uid)src_ip: giriş IP’sitarget: hedef host/servissession_id: oturum kimliğicommand: komut (varsa)tty_output: çıktı (varsa; maskeleme uygulanmalı)ticket: change/incident id (break-glass ile zorunlu kılınabilir)
6) Saklama ve erişim modeli
Oturum kayıtlarında iki katman vardır:
- Görünürlük: SOC/SRE arama yapabilmeli
- Erişim: Ham oturum çıktısına erişim çok kısıtlı olmalı
Pratik yaklaşım:
- Sıcak arama: 7-14 gün
- Soğuk arşiv: 30-90 gün (uyum gereği)
- İmmutability/WORM: kritik sistemlerde tercih edilir
7) Doğrulama runbook’u
- Test kullanıcı ile bastion’a bağlan:
- basit komutlar çalıştır (
id,hostname,sudo -l) - kısa bir sudo işlemi yap (read-only bir komut bile olur)
- Bastion’da kayıt üretildi mi?
- tlog çıktısı yazılmış mı?
- sudo I/O dizininde dosya var mı?
- SIEM’de 5-10 dk içinde görüldü mü?
- actor/target/session_id alanları geliyor mu?
- arama performansı nasıl?
Session recording; iyi tasarlanırsa hem güvenlik hem operasyon için “kanıta dayalı yönetim” sağlar. Kötü tasarlanırsa ya hiç kullanılmaz (gürültü) ya da risk üretir (ham veri sızıntısı). Tasarımı; kayıt + taşıma + erişim + saklama olarak birlikte ele alın.