Windows Update Yönetimi ve Yama Politikaları

Yazar:komut.io ekibi
0 Yorum

Bir sistem yöneticisinin en sıkıcı ama bir o kadar da kritik görevi nedir diye sorsanız, büyük ihtimalle “patch management” yani yama yönetimi diyeceklerdir. Gecenin ikisinde çıkan kritik bir güvenlik açığı, sabah dokuzda ofis açılmadan yamanmak zorunda. Yoksa haberlere “şirket veri ihlali yaşadı” diye düşüyorsunuz. Windows ortamlarında update yönetimi, özellikle kurumsal ölçekte ciddi bir disiplin gerektiriyor. Bu yazıda WSUS’tan PowerShell otomasyonuna, test ortamlarından prod’a geçiş stratejilerine kadar her şeyi ele alacağız.

Windows Update Yönetiminin Temelleri

Windows Update, Microsoft’un yamalarını dağıtmak için kullandığı mekanizma. Ama küçük bir ev ortamından bahsetmiyoruz. Yüzlerce, binlerce Windows makinesi olan bir ortamda her bilgisayarın kendi başına update çekmesine izin verirseniz, hem bant genişliğinizi mahvedersiniz hem de hangi makinenin güncel olup olmadığını bilemezsiniz.

Patch Tuesday kavramından başlayalım. Microsoft, her ayın ikinci Salı günü güvenlik yamalarını yayınlar. Ama bazen kritik açıklar çıktığında bant dışı (out-of-band) yamalar da gelir. WannaCry saldırısından önce Microsoft MS17-010 yamasını yayınlamıştı, ama birçok kurum bunu zamanında uygulamamıştı. Sonuç malum.

Yamalar birkaç kategoriye ayrılır:

  • Critical: Uzaktan kod çalıştırma gibi kritik açıkları kapatır, acilen uygulanmalı
  • Important: Ayrıcalık yükseltme, bilgi ifşası gibi ciddi açıklar
  • Moderate: Sömürülmesi daha zor açıklar
  • Low: Çok düşük riskli değişiklikler
  • Definition Updates: Defender gibi araçlar için imza güncellemeleri
  • Feature Updates: Windows sürüm yükseltmeleri (bunları ayrı yönetmek lazım)

WSUS Kurulumu ve Yapılandırması

Windows Server Update Services, Microsoft’un ücretsiz sunduğu merkezi yama yönetim aracı. Kurumsal ortamların büyük çoğunluğu hala WSUS kullanıyor, her ne kadar modern alternatifleri çıkmış olsa da.

WSUS kurulumu PowerShell ile yapılabilir:

# WSUS rolünü Windows Server'a kur
Install-WindowsFeature -Name UpdateServices -IncludeManagementTools

# WSUS veritabanı ve içerik dizinini yapılandır
& "C:Program FilesUpdate ServicesToolsWsusUtil.exe" postinstall CONTENT_DIR=D:WSUS

WSUS kurulduktan sonra ilk yapmanız gereken şey downstream sync yapılandırmasıdır. Microsoft Update’ten mi yoksa başka bir WSUS sunucusundan mı alacağınızı belirlemeniz gerekiyor. Büyük ortamlarda hiyerarşik WSUS yapısı kurulur: merkezi bir upstream WSUS, şubelerdeki downstream WSUS’lara dağıtır.

# WSUS sunucu ayarlarını PowerShell ile yapılandır
$wsus = Get-WsusServer -Name "WSUS-SRV01" -PortNumber 8530

# Upstream sync ayarları
$wsus.GetConfiguration().SyncFromMicrosoftUpdate = $true
$wsus.GetConfiguration().Save()

# Ürün ve sınıflandırma seç
$wsusConfig = $wsus.GetSubscription()
$wsusConfig.StartSynchronization()

Grup İlkesi (GPO) üzerinden istemcileri WSUS’a yönlendirmek zorundasınız. Domain ortamında şu GPO ayarları kritik:

  • Computer Configuration > Administrative Templates > Windows Components > Windows Update
  • Specify intranet Microsoft update service location: WSUS sunucunuzun URL’si
  • Configure Automatic Updates: Politikanıza göre ayarlayın
  • No auto-restart with logged on users for scheduled automatic update installations: Kullanıcı deneyimi için açık tutabilirsiniz

PowerShell ile Update Yönetimi

WSUS arayüzü her zaman yeterli olmaz. Raporlama, otomasyon ve toplu işlemler için PowerShell şart.

# Belirli bir bilgisayardaki eksik güncellemeleri listele
$UpdateSession = New-Object -ComObject Microsoft.Update.Session
$UpdateSearcher = $UpdateSession.CreateUpdateSearcher()
$SearchResult = $UpdateSearcher.Search("IsInstalled=0 and Type='Software'")

foreach ($Update in $SearchResult.Updates) {
    Write-Host "Eksik Guncelleme: $($Update.Title)" -ForegroundColor Yellow
    Write-Host "Onem Derecesi: $($Update.MsrcSeverity)" -ForegroundColor Cyan
}

Uzak makinelerde update durumu kontrol etmek için PSWindowsUpdate modülü işinizi çok kolaylaştırır:

# PSWindowsUpdate modulunu kur
Install-Module PSWindowsUpdate -Force

# Birden fazla sunucuya yama uygula
$Servers = @("SRV-WEB01", "SRV-WEB02", "SRV-DB01", "SRV-APP01")

foreach ($Server in $Servers) {
    Write-Host "[$Server] Guncelleme kontrol ediliyor..." -ForegroundColor Green
    Invoke-WUJob -ComputerName $Server -Script {
        Import-Module PSWindowsUpdate
        Install-WindowsUpdate -AcceptAll -AutoReboot -Verbose
    } -Credential (Get-Credential) -RunNow
}

Peki ya sadece kritik güncellemeleri uygulamak istiyorsanız? Özellikle production sunucularda her yamayı körü körüne uygulamak yerine, kritik güvenlik yamalarını önceliklendirmek daha mantıklı:

# Sadece kritik ve onemli guncelleme yukle, feature update alma
Import-Module PSWindowsUpdate

Get-WindowsUpdate -MicrosoftUpdate -NotCategory "Feature Packs" -Severity Critical, Important |
    Where-Object { $_.Title -notlike "*Preview*" } |
    Install-WindowsUpdate -AcceptAll -IgnoreReboot

# Yeniden baslatma gerekiyor mu kontrol et
if (Get-WURebootStatus -Silent) {
    Write-Host "Yeniden baslatma gerekiyor!" -ForegroundColor Red
}

Test Ortamı Stratejisi ve Ring Deployment

Yamayı doğrudan production’a uygulamak, paraşütsüz atlamak gibidir. Mutlaka aşamalı bir dağıtım stratejisi (ring deployment) kullanmalısınız.

Tipik bir ring yapısı şöyle olabilir:

  • Ring 0 – Pilot: IT ekibinin kendi bilgisayarları, 5-10 makine. Yama çıktıktan sonra ilk 3-5 gün içinde uygulanır.
  • Ring 1 – Early Adopters: Teknik kullanıcılar, geliştiriciler. 1-2 hafta sonra.
  • Ring 2 – Broad Deployment: Genel kullanıcılar. 2-3 hafta sonra.
  • Ring 3 – Critical Systems: Domain controller’lar, veritabanı sunucuları, ERP sistemleri. 3-4 hafta sonra, hafta sonu maintenance window’unda.

Bu yapıyı WSUS’ta bilgisayar grupları oluşturarak uygulayabilirsiniz:

# WSUS'ta deployment ring gruplarini olustur
$wsus = Get-WsusServer

$Ring0 = $wsus.CreateComputerTargetGroup("Ring0-Pilot")
$Ring1 = $wsus.CreateComputerTargetGroup("Ring1-EarlyAdopters")
$Ring2 = $wsus.CreateComputerTargetGroup("Ring2-BroadDeployment")
$Ring3 = $wsus.CreateComputerTargetGroup("Ring3-CriticalSystems")

Write-Host "Deployment ring gruplari olusturuldu." -ForegroundColor Green

Gerçek dünya senaryosu: Bir finans şirketinde çalışıyorsunuz. Ay sonu kapanışı yaklaşıyor, muhasebe ekibi yoğun. Kritik bir Exchange yamayı Ring 2’de dağıttınız, ama Exchange’i Ring 3’te tutmayı unuttunuz. Patch uygulandı, Exchange yeniden başladı, muhasebe ekibi mailler gönderemediler. Bu tür olayları engellemek için her sistemin hangi ring’te olduğunu belgeleyen bir CMDB (Configuration Management Database) şart.

Windows Update for Business (WUfB)

Modern Windows 10/11 ortamlarında ve Azure AD join cihazlarda Windows Update for Business giderek daha fazla tercih ediliyor. WSUS’a göre daha az altyapı gerektiriyor, Intune ile entegre çalışıyor.

WUfB’yi GPO ile yapılandırabilirsiniz:

# WUfB deferral ayarlarini Group Policy ile yapilandir
# Bu ayarlar registry uzerinden de uygulanabilir

# Quality Update (guvenlik yamalari) icin 7 gun erteleme
Set-ItemProperty -Path "HKLM:SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate" `
    -Name "DeferQualityUpdates" -Value 1 -Type DWord

Set-ItemProperty -Path "HKLM:SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate" `
    -Name "DeferQualityUpdatesPeriodInDays" -Value 7 -Type DWord

# Feature Update icin 30 gun erteleme
Set-ItemProperty -Path "HKLM:SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate" `
    -Name "DeferFeatureUpdates" -Value 1 -Type DWord

Set-ItemProperty -Path "HKLM:SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate" `
    -Name "DeferFeatureUpdatesPeriodInDays" -Value 30 -Type DWord

Hybrid ortamlarda (hem domain join hem Azure AD join cihazlar varsa) WUfB ve WSUS birlikte kullanılabilir. Ama bu yapı biraz karmaşıklaşıyor, dikkatli olmak lazım.

Maintenance Window Planlaması

Sunuculara yama uygularken yeniden başlatma kaçınılmaz. Bu yeniden başlatmayı iş saatlerinde yapmak kabul edilemez. Maintenance window planlaması, SLA’larınıza ve iş gereksinimlerinize göre şekillenmelidir.

# Otomatik yama ve reboot icin scheduled task olustur
$Action = New-ScheduledTaskAction -Execute "PowerShell.exe" `
    -Argument "-NonInteractive -Command `"Import-Module PSWindowsUpdate; Install-WindowsUpdate -AcceptAll -AutoReboot`""

# Her ay ikinci Salinin ertesi gunu (Carsamba) gece 02:00'da calistir
$Trigger = New-ScheduledTaskTrigger -Weekly -WeeksInterval 1 `
    -DaysOfWeek Wednesday -At "02:00AM"

# Sadece Patch Tuesday'den sonraki Carsamba calistirmak icin
# Tarih kontrolu ekle
$Settings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit (New-TimeSpan -Hours 4) `
    -RestartCount 3 -RestartInterval (New-TimeSpan -Minutes 10)

Register-ScheduledTask -TaskName "Monthly-PatchManagement" `
    -Action $Action -Trigger $Trigger -Settings $Settings `
    -RunLevel Highest -Force

Write-Host "Maintenance window task olusturuldu." -ForegroundColor Green

Cluster ortamlarında durum daha da kritik. SQL Always On veya Hyper-V cluster’larınız varsa, node’ları sırayla güncellemeniz gerekiyor. Bir node’u güncellerken iş yükü diğerine geçer, sonra sıra değişir.

Uyumluluk Raporlaması ve Denetim

Yama yönetiminin sadece teknik boyutu değil, uyumluluk boyutu da var. ISO 27001, PCI DSS, KVKK gibi standartlar belirli patch SLA’ları zorunlu kılar. Örneğin PCI DSS, kritik güvenlik yamalarının 30 gün içinde uygulanmasını şart koşar.

# Ortamdaki tum makinelerin patch uyumluluk raporunu olustur
$Computers = Get-ADComputer -Filter {OperatingSystem -like "*Windows*"} `
    -Properties OperatingSystem, LastLogonDate |
    Where-Object { $_.LastLogonDate -gt (Get-Date).AddDays(-30) }

$Report = foreach ($Computer in $Computers) {
    try {
        $OS = Get-WmiObject -ComputerName $Computer.Name `
            -Class Win32_OperatingSystem -ErrorAction Stop

        $HotFixes = Get-HotFix -ComputerName $Computer.Name -ErrorAction Stop |
            Sort-Object InstalledOn -Descending |
            Select-Object -First 1

        [PSCustomObject]@{
            ComputerName    = $Computer.Name
            OS              = $OS.Caption
            LastPatch       = $HotFixes.InstalledOn
            DaysSinceUpdate = ((Get-Date) - $HotFixes.InstalledOn).Days
            Status          = if (((Get-Date) - $HotFixes.InstalledOn).Days -gt 30) {
                "UYUMSUZ"
            } else {
                "Uyumlu"
            }
        }
    }
    catch {
        [PSCustomObject]@{
            ComputerName    = $Computer.Name
            OS              = "Erisilemez"
            LastPatch       = "N/A"
            DaysSinceUpdate = 999
            Status          = "KONTROL EDILEMEDI"
        }
    }
}

# Raporu CSV'ye aktar
$Report | Export-Csv -Path "C:ReportsPatchCompliance_$(Get-Date -Format 'yyyyMMdd').csv" `
    -NoTypeInformation -Encoding UTF8

# Uyumsuz makineleri ekrana yazdir
$Report | Where-Object { $_.Status -ne "Uyumlu" } |
    Format-Table -AutoSize

Patch Geri Alma (Rollback) Senaryoları

Her yama kusursuz değildir. Bazen bir yama uygulandıktan sonra uygulamalar çöker, sürücüler bozulur veya beklenmedik davranışlar ortaya çıkar. Rollback planınız olmazsa felakete davetiye çıkarırsınız.

Fiziksel sunucularda rollback için en güvenli yöntem önceden snapshot veya yedek almak. VMware/Hyper-V ortamlarında bu çok kolay:

# Yama oncesi VM snapshot al (Hyper-V)
$VMName = "SRV-APP01"
$SnapshotName = "PrePatch_$(Get-Date -Format 'yyyyMMdd_HHmm')"

Checkpoint-VM -Name $VMName -SnapshotName $SnapshotName
Write-Host "$VMName icin snapshot alindi: $SnapshotName" -ForegroundColor Green

# Sorun olursa geri don
# Restore-VMCheckpoint -VMName $VMName -Name $SnapshotName -Confirm:$false

# Yama basariyla uygulandiktan sonra snapshot sil (disk alanini geri al)
# Remove-VMCheckpoint -VMName $VMName -Name $SnapshotName

Belirli bir Windows Update’i kaldırmak için:

# Belirli bir KB'yi kaldır
$KB = "KB5034441"
$HotFix = Get-HotFix -Id $KB -ErrorAction SilentlyContinue

if ($HotFix) {
    Write-Host "$KB kaldiriliyor..." -ForegroundColor Yellow
    wusa.exe /uninstall /kb:${KB} /quiet /norestart
    Write-Host "$KB kaldirildi. Yeniden baslatma gerekiyor." -ForegroundColor Green
} else {
    Write-Host "$KB bu sistemde yuklu degil." -ForegroundColor Cyan
}

Microsoft Endpoint Configuration Manager (MECM/SCCM)

Büyük kurumsal ortamlarda (500+ istemci) WSUS tek başına yetmez. MECM (eski adıyla SCCM), yama yönetimini çok daha granüler ve raporlanabilir hale getirir. Software Update Point rolü üzerinden WSUS’u yönetir, üstüne gelişmiş dağıtım kuralları, uyumluluk raporları ve Automatic Deployment Rules (ADR) ekler.

ADR ile her ay otomatik olarak yeni güvenlik yamalarını alıp belirli koleksiyonlara dağıtabilirsiniz. Örneğin “Her Patch Tuesday’den sonraki Çarşamba, kritik güvenlik yamalarını Test koleksiyonuna dağıt, 7 gün sonra Production’a geç” şeklinde kurallar tanımlanabilir.

MECM ortamında update compliance durumu sorgulamak için WQL kullanılır:

# MECM/SCCM uzerinden uyumluluk raporu (PowerShell + WMI)
$SiteServer = "MECM-SRV01"
$SiteCode = "P01"

$Query = "SELECT ResourceID, Name, LastStatusMessageTime FROM SMS_UpdateComplianceStatus WHERE Status=2"

$NonCompliant = Get-WmiObject -ComputerName $SiteServer `
    -Namespace "rootSMSsite_$SiteCode" `
    -Query $Query

Write-Host "Uyumsuz makine sayisi: $($NonCompliant.Count)" -ForegroundColor Red
$NonCompliant | Select-Object Name, LastStatusMessageTime | Format-Table -AutoSize

Zero-Day Yamalar ve Acil Durum Prosedürleri

2021’de ProxyLogon (Exchange), 2022’de Log4Shell, 2024’te başka kritik açıklar. Zero-day veya aktif olarak sömürülen açıklar için normal yama döngünüzü bekleyemezsiniz.

Acil durum yama prosedürünüz şunları içermeli:

  • Değerlendirme: CVSS skoru 9.0 üzeri mi? Aktif sömürme var mı? Ortamınızı etkiliyor mu?
  • İletişim: Yönetim ve ilgili birimlere bilgilendirme, onay alınması
  • Test: Mümkünse hızlı bir test ortamında doğrulama (en azından 1-2 makine)
  • Acil Dağıtım: Önce kritik internet’e açık sistemler, sonra iç ağ
  • Doğrulama: Yamanın uygulandığının ve sistemlerin ayakta olduğunun kontrolü
  • Belgeleme: Yapılan işlemlerin kayıt altına alınması

Acil durumlarda tüm sunuculara hızlıca yama uygulamak için:

# Acil durum yama scripti - Belirli KB'yi tum sunuculara hizlica dagit
$CriticalKB = "KB5034441"
$ServerList = Get-Content "C:AdminServerList.txt"
$Credential = Get-Credential -Message "Admin kimlik bilgilerini girin"

$Results = Invoke-Command -ComputerName $ServerList -Credential $Credential -ScriptBlock {
    param($KB)
    Import-Module PSWindowsUpdate
    $Update = Get-WindowsUpdate -KBArticleID $KB
    if ($Update) {
        Install-WindowsUpdate -KBArticleID $KB -AcceptAll -IgnoreReboot
        "YUKLENDI: $KB"
    } else {
        "BULUNAMADI veya ZATEN YUKLU: $KB"
    }
} -ArgumentList $CriticalKB

$Results | Format-Table PSComputerName, @{N="Durum";E={$_}} -AutoSize

Patch Yönetiminde Sık Yapılan Hatalar

Yıllarca farklı ortamlarda çalışırken gördüğüm yaygın hataları paylaşayım:

  • Test etmeden production’a uygulamak: “Hızlı olalım” diye test adımı atlanıyor, sonra production çöküyor.
  • Feature update’leri güvenlik yaması gibi davranmak: Feature update’ler çok daha fazla değişiklik içerir, ayrı bir süreç gerektirir.
  • Rollback planı yapmamak: “Sorun olursa hallederiz” mantığı, gece 03:00’teki paniğe davetiye.
  • Sadece Windows güncellemelerini yapmak: Third-party uygulamalar (Adobe, Java, Chrome, Office) da kritik açıklar barındırır. Bunlar için ayrı bir süreç gerekir.
  • Belgesi olmayan süreçler: Kim ne zaman neyi güncelledi? 3 ay sonra denetimde bu soruyu yanıtlayamazsanız sıkıntı.
  • Eski işletim sistemleri: Hala Windows Server 2012 R2 çalıştıran sistemler varsa, önceliğiniz o olmalı. End-of-life sistemlerde yama yok demek, açık kapı demek.

Sonuç

Windows Update yönetimi, “ayarla unut” yaklaşımıyla değil, sürekli dikkat ve iyileştirme gerektiren bir disiplindir. WSUS ile merkezi yönetim, PowerShell ile otomasyon, ring deployment ile kontrollü dağıtım ve düzenli uyumluluk raporlaması bu disiplinin temel taşlarıdır.

Küçük ortamlar için bile en azından bir WSUS sunucusu, GPO ile yönetilen update politikaları ve aylık maintenance window yeterli bir başlangıçtır. Büyük ortamlarda MECM, Intune veya üçüncü parti çözümler (Ivanti, ManageEngine Patch Manager Plus gibi) devreye girer.

Unutmayın, her yama uygulanmamış sistem potansiyel bir giriş noktasıdır. WannaCry’ın vurduğu sistemlerin büyük çoğunluğu, yaması aylar önce yayınlanmış olan MS17-010’u uygulamamıştı. Yama yönetimi bazen sıkıcı gelir, ama bu sıkıcı rutinin bir gün sizi büyük bir felaketten kurtarabileceğini hiç aklınızdan çıkarmayın.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir