SNMP hâlâ ağ izleme dünyasının omurgası. Ama SNMPv2c ile “community string” kullanmak; pratikte paylaşılan parola kullanmaktır. Üretimde bunun sonucu genelde üç problem olur:
- Community sızar → cihaz envanteri ve topoloji görünür olur
- ACL geniş kalır → gereksiz yüzey alanı oluşur
- “Bir string” herkesindir → rotasyon yapılamaz, kim kullandı bilinmez
SNMPv3 bu yüzden sadece “daha yeni sürüm” değil; yetki + şifreleme + işletilebilirlik fırsatıdır.
Hedef mimari: üç katman
SNMPv3’ü sahada problemsiz işletmek için şu üç katmanı netleştirin:
- Kimlik: SNMP kullanıcıları (auth + privacy)
- Yetki: view ile hangi OID’ler okunabilir?
- Ağ sınırı: sadece poller IP’leri / mgmt VRF / ACL
1) Kullanıcı stratejisi: tek kullanıcı yerine rol bazlı kullanıcılar
En temiz model:
- snmp_ro: sadece okuma, sınırlı view
- snmp_trap (opsiyonel): informs/trap için ayrı kullanıcı (cihaz destekliyorsa)
Bu, rotasyonu ve “kim neyi okuyor” disiplinini kolaylaştırır.
2) View tasarımı: “her şeyi oku” yerine minimal OID seti
Monitoring ekibi çoğu zaman “her şeyi alalım” ister. Ama güvenli ve stabil yaklaşım:
- Interface sayaçları
- CPU/memory sıcaklık/fan gibi health
- Routing adjacency/route counts gibi high-level sinyaller (ihtiyaca göre)
Vendor’a göre OID’ler değişir; ama ilke aynı: gerekli metrikleri kapsayan dar view.
3) Ağ sınırı: SNMP’yi “mgmt düzlemi” gibi ele al
Sahada en güvenli pratikler:
- SNMP sadece mgmt VRF / yönetim VLAN üzerinden konuşsun
- ACL sadece poller IP’lerine izin versin (geniş subnetlerden kaçın)
- UDP/161 (poll) ve gerekiyorsa UDP/162 (trap) açık olsun; gereksiz yönlere kapalı kalsın
4) Trap/Inform: “gürültü” değil, olay sinyali
Trap’ler yanlış kurgulanırsa gürültü üretir. Değerli trap sınıfları:
- Power supply / fan failure
- Link down (özellikle uplink’ler)
- BGP/OSPF adjacency down (core/edge)
- Config change (vendor destekliyorsa)
Rollout runbook: SNMPv2c → SNMPv3 geçişi
- Poller tarafında SNMPv3 kullanıcı/şifreleri tanımla
- Cihazlarda SNMPv3 kullanıcılarını ekle (authPriv)
- ACL’leri daralt (önce izleme, sonra sıkılaştırma)
- Poller’da SNMPv3’ü aktif et; cihaz bazında doğrula
- Her şey stabil olunca SNMPv2c community’leri kaldır
İzleme ve alarm: SNMP’nin kendisini de izle
SNMP tarafında gözden kaçan iki kritik sinyal:
- Timeout/latency: poll süresi uzuyorsa control-plane veya ACL sorunu olabilir
- Auth fail: yanlış kullanıcı/şifre, ya da istenmeyen tarama
Bu sinyalleri merkezi log/SIEM’e taşırsanız “sessiz problem” sınıfı azalır.
Kapanış: SNMPv3, güvenli observability’nin en düşük maliyetli adımlarından biri
SNMPv3’ü doğru tasarladığınızda iki kazanım birlikte gelir: monitoring verisi daha güvenli akar ve operasyon ekibi “community paylaşımı” gibi kırılgan pratiklerden kurtulur. En önemli nokta; SNMPv3’ü bir defa açıp geçmek değil, kullanıcı/view/ACL disiplinini yaşayan bir süreç olarak işletmektir.