Dağıtık sistemlerde “zaman” genelde altyapı checklist’inin en altına yazılır; ta ki bir gün TLS sertifikaları “henüz geçerli değil” desin, SIEM korelasyonları kaybolsun, ya da bir postmortem’de olay akışı saat farkından dolayı yanlış kurgulansın. Zaman senkronizasyonu; logların düzgün görünmesi için değil, güvenlik ve operasyonel doğruluk için bir kontrol katmanıdır.
Bu yazıda NTP/PTP’yi “kurduk geçti” değil; mimari, güvenlik ve runbook perspektifiyle ele alıyorum.
1) Önce hedefi tanımla: milisaniye mi, doğruluk mu, tutarlılık mı?
Her sistemin zaman ihtiyacı aynı değil:
- Genel kurumsal sunucular: saniye düzeyinde tutarlılık çoğu zaman yeterlidir.
- Güvenlik / log korelasyonu: saniye altı sapmalar analiz kalitesini düşürür (özellikle yüksek hacimli olaylarda).
- Finans / ölçüm / telekom / endüstriyel: alt-milisaniye veya mikro saniye düzeyi gerekebilir; bu noktada PTP devreye girer.
Hedefi netleştirmeden “PTP kuralım” demek, çoğu kurumda gereksiz karmaşıklık üretir.
2) NTP mimarisi: hiyerarşi, yedeklilik ve kontrol
Sağlam bir NTP tasarımı genelde üç katmanla daha yönetilebilir olur:
- Kaynak (upstream) katmanı: İnternet veya kurum dışı referanslar (çoklu kaynak).
- Kurumsal zaman servisi katmanı: En az 2 örnek; tercihen farklı hata alanlarında.
- İstemci katmanı: Tüm sunucu/cihazlar; sadece kurumsal zaman servislerine konuşur.
Bu hiyerarşinin pratik getirisi şudur: İstemcilerin internete doğrudan NTP çıkışı yoktur; hem güvenlik hem de davranış kontrolü artar.
3) PTP ne zaman gerekir? (ve ne zaman gereksizdir?)
PTP’yi (IEEE 1588) anlamlı kılan şey, çok daha düşük jitter ve daha iyi determinism hedefidir. Fakat PTP “kabloladım oldu” değildir:
- Switch’lerin PTP aware olması (boundary/transparent clock desteği)
- NIC ve sürücü desteği
- Topoloji ve VLAN/segment planı
- PTP kaynak saatinin (grandmaster) güvenilirliği
Eğer ihtiyacın “log korelasyonu ve TLS” ise, çoğu kurumda iyi tasarlanmış NTP katmanı + iyi izleme yeterlidir.
4) Güvenlik: zaman katmanına saldırı bir üretim incident’ıdır
Zaman kayması, yalnızca “yanlış saat” değildir. Operasyonel karşılığı:
- TLS el sıkışması sorunları
- Kerberos/SSO “clock skew” hataları
- SIEM korelasyon bozulması (yanlış zincirleme)
- Audit / log kanıt değerinin zayıflaması
Bu yüzden zaman katmanında şu guardrail’leri isterim:
- İstemciler yalnızca iç zaman servislerine konuşsun
- Zaman servisleri için ayrı management segmenti ve sınırlı erişim
- NTP daemon’ında “allow” list yaklaşımı
- Mümkünse NTS (Network Time Security) gibi güvenli modlar
5) İzlenebilirlik: “offset var mı?” değil, “trend nereye gidiyor?”
İzleme tarafında tek metrikle yetinmek hata olur. Ben şu sinyalleri ayrı takip ederim:
- Offset (ms): şimdi ne kadar sapıyoruz?
- Skew / drift: sapma trendi sabit mi artıyor mu?
- Stratum / kaynak kalitesi: istemci hangi kaynağa kilitlendi?
- Step vs slew: saat ileri/geri “zıplıyor” mu?
- NTP reachability: erişim aralıklı mı?
Alarm eşiği örneği (kurumsal genel sistemler için):
- Uyarı: offset > 50ms (kalıcı 5-10 dk)
- Kritik: offset > 200ms
Bu eşikler mutlak doğru değildir; uygulama toleransı ve güvenlik analizi ihtiyacı belirler.
6) Operasyon runbook: “saat bozuldu” diye reboot atma
Zaman sapmasında ilk refleks reboot olmasın. Daha iyi triage sırası:
- İstemci NTP kaynaklarını doğrula (hangi kaynak, hangi gecikme?)
- Sunucuda yoğun CPU / IO / VM steal var mı kontrol et
- NTP erişimi firewall/NAT/ACL ile kesiliyor mu bak
- Kaynak zaman servislerinde sapma var mı bak (tek noktaya kilitlenme?)
- Gerekirse kontrollü step (bazı servislerde etkisi büyük olabilir)
7) Kapanış: zaman katmanı bir altyapı detayı değil, güven katmanı
Kurumsal yapılarda NTP/PTP; network ekibinin “UDP açtık” işi değildir. Mimari hedef, güvenlik modeli, gözlemlenebilirlik ve runbook aynı paket olmalıdır. Zaman düzgünse; TLS, SIEM, postmortem ve kapasite planı daha doğru çalışır. Zaman bozuksa; en iyi platform bile “gerçeklikten kopar”.