ISTANBUL TEKNOLOJI
ISO 27001ISO 9001PCI-DSSKVKK / GDPRMicrosoft Solutions PartnerCisco Gold PartnerFortinet ExpertVMware EnterpriseISO 27001ISO 9001PCI-DSSKVKK / GDPRMicrosoft Solutions PartnerCisco Gold PartnerFortinet ExpertVMware Enterprise
BlogSiber Güvenlik

Yama Yönetimi (Patch Management): Kurumsal Güncelleme Disiplini Rehberi

14.08.2026 7 dk okuma

Güvenlik açıklarının çoğu bilinen ve yaması yayınlanmış zafiyetlerden sömürülür. Risk bazlı önceliklendirme, test halkası ve acil yama prosedürüyle kurumsal yama yönetimi disiplinini anlatıyoruz.

Veri ihlali vakalarının önemli bir bölümü, saldırı anında zaten yaması yayınlanmış güvenlik açıkları üzerinden gerçekleşir. Başka bir deyişle birçok kurum, bilmediği bir tehdide değil, takip edemediği bir güncellemeye yenik düşer. Yama yönetimi (patch management), işletim sistemlerinden uygulamalara, ağ cihazlarından firmware'lere kadar tüm yazılım katmanında güncellemelerin planlı, ölçülü ve izlenebilir şekilde uygulanması disiplinidir.

Neden yamalar gecikir?

Sahada gördüğümüz üç ana neden vardır: kesinti korkusu ('sistem bozulursa'), envanter eksikliği ('neyin güncellenmesi gerektiğini bilmiyoruz') ve sorumluluk belirsizliği ('kim onaylayacak?'). Bu üçü de teknik değil, süreç sorunudur. Ücretsiz BT denetimi çalışmalarımızda ortalama bir KOBİ ağında 90 günden eski kritik yaması bekleyen sunucular bulmamız şaşırtıcı değildir.

Risk bazlı önceliklendirme

Her yama aynı aciliyette değildir. Doğru yaklaşım, CVSS puanını varlığın kritikliği ve açığın aktif sömürülüp sömürülmediği (KEV listeleri) ile birleştirmektir. İnternete açık bir sunucudaki aktif sömürülen açık 24-72 saat içinde; iç ağdaki bir istemcideki orta seviye açık ise normal aylık döngüde kapatılabilir. Bu sınıflandırma olmadan ya her şey gecikir ya da ekip yama yorgunluğuna düşer.

  • Acil (24-72 saat): Aktif sömürülen, internete açık sistemlerdeki kritik açıklar.
  • Yüksek (7 gün): Sunucu ve güvenlik cihazlarındaki kritik/yüksek açıklar.
  • Normal (30 gün): İstemci işletim sistemi ve uygulama güncellemeleri.
  • Planlı (çeyreklik): Firmware, sürücü ve düşük riskli iyileştirmeler.

Test halkası (ring) modeli

Güncellemeleri tüm ortama aynı anda dağıtmak yerine halkalar halinde ilerleyin: önce BT ekibinin cihazları, sonra gönüllü bir pilot grup, ardından genel dağıtım. Her halka arasında 3-7 gün gözlem süresi bırakın. Sunucularda ise önce üretim dışı (test/staging) kopyada doğrulama yapın. Bu model, 'yama sistemi bozdu' riskini yönetilebilir bir deneye dönüştürür.

Ölçüm ve raporlama

Yama yönetiminin olgunluğu üç metrikle ölçülür: yama paranlığı (patch latency — yayınlanma ile kurulum arasındaki süre), kapsam oranı (ortamdaki cihazların yüzde kaçı güncel) ve istisna listesi (bilinçli ertelenen yamaların sayısı ve gerekçesi). Bu metriklerin aylık raporlanması, siber güvenlik denetimleri sırasında da güçlü bir kanıt sunar.

Otomasyon ve dış kaynak

WSUS, Intune veya üçüncü parti RMM araçlarıyla dağıtım otomatikleştirilebilir; ancak otomasyon karar sürecini ortadan kaldırmaz. Güncelleme disiplini kurmakta zorlanan kurumlar için Yönetilen BT Hizmetleri kapsamında yama yönetimini SLA taahhüdüyle devralıyoruz. Siber güvenlik skorunuzu ölçerek mevcut durumunuzu da ücretsiz görebilirsiniz.

Unutmayın: yama yönetimi bir proje değil, sürekliliği olan bir operasyondur. En pahalı güvenlik ürünü bile 60 gün önce yayınlanmış bir yamayı kapatmaz.

Sıkça sorulan sorular

Yamalar ne sıklıkla uygulanmalı?
İstemciler için aylık döngü, sunucular için aylık planlı pencere ve aktif sömürülen kritik açıklar için 24-72 saatlik acil prosedür önerilir.
Yama sistemi bozarsa ne yapılır?
Test halkası modeli riski küçük bir pilot grupla sınırlar; ayrıca her kritik sunucu için geri dönüş planı (snapshot veya yedekten dönüş) önceden tanımlanmalıdır.

İlgili sayfalar

Ücretsiz BT denetimi talep edin

Diğer yazılar