Yerel Güvenlik İlkesi: Parola ve Hesap Kilitleme Ayarları

Windows ortamlarında güvenliğin temeli, kullanıcı hesaplarının nasıl yönetildiğinden geçer. Parola politikaları ve hesap kilitleme ayarları, saldırganların brute force veya dictionary attack yöntemleriyle sisteme sızmalarını engelleyen ilk savunma hattıdır. Bu yazıda, Windows Server üzerinde Yerel Güvenlik İlkesi (Local Security Policy) aracılığıyla bu ayarları nasıl yapılandıracağımızı, gerçek dünya senaryolarıyla birlikte ele alacağız.

Yerel Güvenlik İlkesi Nedir?

Yerel Güvenlik İlkesi (secpol.msc), Windows Server ve Windows istemci sistemlerinde güvenlik ayarlarını merkezi olarak yönetmenizi sağlayan bir araçtır. Active Directory ortamında bu ayarlar genellikle Group Policy üzerinden uygulanır, ancak standalone sunucular veya workgroup ortamlarında doğrudan Yerel Güvenlik İlkesi kullanılır.

Bu araç üzerinden yönetilebilecek başlıca güvenlik kategorileri şunlardır:

• Account Policies (Hesap İlkeleri): Parola ve hesap kilitleme politikaları
• Local Policies: Denetim, kullanıcı hakları ve güvenlik seçenekleri
• Windows Firewall: Güvenlik duvarı kuralları
• Public Key Policies: Sertifika tabanlı güvenlik
• Software Restriction Policies: Yazılım kısıtlamaları

Biz bu yazıda özellikle Account Policies altındaki iki kritik başlığa odaklanacağız: Password Policy (Parola İlkesi) ve Account Lockout Policy (Hesap Kilitleme İlkesi).

Neden Bu Ayarlar Bu Kadar Önemli?

Geçen yıl bir müşterimizin sunucusunu incelediğimde, RDP’nin 3389 portuyla internete açık olduğunu ve herhangi bir hesap kilitleme politikasının tanımlı olmadığını gördüm. Olay günlüklerini açtığımda dakikada yüzlerce başarısız giriş denemesi görüyordum. “Administrator” hesabına yönelik klasik bir brute force saldırısıydı. Kilitleme politikası olmadığı için saldırgan teorik olarak sonsuz deneme yapabilirdi.

Bu tür senaryolar son derece yaygın. Özellikle şunları unutmamak lazım:

• Brute Force Saldırıları: Tüm olası parola kombinasyonlarını dener
• Dictionary Attacks: Yaygın parolalar listesini dener
• Credential Stuffing: Başka ihlallerden çalınan kullanıcı adı/parola çiftlerini dener
• Pass-the-Hash: Parola hash’ini ele geçirip doğrudan kullanır

Doğru yapılandırılmış bir parola ve kilitleme politikası, bu saldırıların büyük çoğunluğunu ya tamamen engeller ya da son derece zorlaştırır.

Yerel Güvenlik İlkesine Erişim

Önce bu araca nasıl erişeceğimizi ele alalım. Birkaç farklı yöntem var:

GUI Üzerinden Erişim

Win + R tuşlarına basıp secpol.msc yazabilir veya şu yolu takip edebilirsiniz:

Control Panel > Administrative Tools > Local Security Policy

PowerShell ile Açma

# Yerel Güvenlik İlkesi'ni PowerShell üzerinden açmak
Start-Process secpol.msc

# Veya doğrudan komut satırından
mmc.exe /a "%SystemRoot%system32SecPol.msc"

Secedit Aracı ile Mevcut Ayarları Görüntüleme

# Mevcut güvenlik ayarlarını bir dosyaya aktar
secedit /export /cfg C:SecurityConfigcurrent_policy.cfg /areas SECURITYPOLICY

# Dosyayı oku
Get-Content C:SecurityConfigcurrent_policy.cfg

Bu komutun çıktısı size mevcut tüm güvenlik ayarlarını gösterir. Özellikle [System Access] bölümü parola ve kilitleme politikalarını içerir.

Parola İlkesi (Password Policy) Ayarları

Yerel Güvenlik İlkesi açıkken sol panelde Security Settings > Account Policies > Password Policy yolunu takip edin. Karşınıza birkaç kritik ayar çıkacak.

Minimum Parola Uzunluğu

Minimum password length ayarı, kullanıcıların en az kaç karakter uzunluğunda parola belirleyebileceğini kontrol eder.

Microsoft’un güncel önerisi en az 14 karakter, ancak kurumsal ortamlarda 16 veya daha fazlası daha güvenli kabul edilir. Eski standart olan 8 karakter artık tamamen yetersiz; modern GPU’larla 8 karakterli bir parola dakikalar içinde kırılabilir.

# PowerShell ile minimum parola uzunluğunu ayarla
net accounts /minpwlen:14

# Mevcut parola politikasını görüntüle
net accounts

# Secedit ile daha detaylı yapılandırma için önce template oluştur
$secConfig = @"
[System Access]
MinimumPasswordLength = 14
"@
$secConfig | Out-File -FilePath "C:Temppwpolicy.inf" -Encoding Unicode

Parola Karmaşıklığı Gereksinimleri

Password must meet complexity requirements ayarı etkinleştirildiğinde, Windows parolanın şu kriterleri karşılamasını zorunlu kılar:

• Büyük harf (A-Z)
• Küçük harf (a-z)
• Rakam (0-9)
• Özel karakter (!@#$%^&*)

Bu dört kategoriden en az üçünü içermeli ve kullanıcı adını ya da tam adı barındırmamalıdır.

Parola Geçerlilik Süresi

Maximum password age ve Minimum password age ayarları parolaların ne kadar süre geçerli kalacağını belirler.

Burada önemli bir nokta var: NIST (National Institute of Standards and Technology), 2017’den itibaren düzenli parola değiştirme zorunluluğunun artık önerilmediğini belirtiyor. Çünkü insanlar her değiştirmede Parola1, Parola2 gibi tahmin edilebilir parolalar seçiyor. Ancak kurumsal uyumluluk gereksinimleri (PCI-DSS, ISO 27001 gibi) hâlâ belirli aralıklarla değiştirme zorunluluğu getirebilir.

Pratik öneri:

• Maximum password age: 90 gün (uyumluluk gerektiriyorsa), yoksa 0 (süresiz)
• Minimum password age: 1 gün (kullanıcıların hemen geri değiştirmesini engeller)

Parola Geçmiş Kaydı

Enforce password history ayarı, kullanıcının son kaç parolayı tekrar kullanamayacağını belirler. Önerilen değer 24‘tür. Bu sayede kullanıcılar döngüsel parola kullanımını engellenmiş olur.

# Net accounts komutuyla tüm parola politikalarını bir arada ayarla
net accounts /minpwlen:14 /maxpwage:90 /minpwage:1 /uniquepw:24

# Secedit ile kapsamlı parola politikası uygulama
$infContent = @"
[Unicode]
Unicode=yes
[System Access]
MinimumPasswordLength = 14
PasswordComplexity = 1
MaximumPasswordAge = 90
MinimumPasswordAge = 1
PasswordHistorySize = 24
ClearTextPassword = 0
[Version]
signature="`$CHICAGO`$"
Revision = 1
"@

$infContent | Out-File -FilePath "C:Temppassword_policy.inf" -Encoding Unicode
secedit /configure /db C:Tempsecedit.sdb /cfg C:Temppassword_policy.inf /areas SECURITYPOLICY

Hesap Kilitleme İlkesi (Account Lockout Policy)

Bu bölüm, brute force saldırılarına karşı en kritik savunma mekanizmasını içeriyor. Security Settings > Account Policies > Account Lockout Policy yolunu takip edin.

Hesap Kilitleme Eşiği

Account lockout threshold, kaç başarısız giriş denemesinin ardından hesabın kilitleneceğini belirler. Bu değer 0 olarak ayarlanırsa hesap kilitleme devre dışı kalır (ki bu son derece tehlikelidir).

Önerilen değer: 5 deneme

Çok düşük bir eşik (örneğin 3) meşru kullanıcıların sık sık kilitlenmesine yol açar. Çok yüksek bir eşik (örneğin 20) ise brute force saldırılarına kapı aralar. 5 iyi bir denge noktasıdır.

# Hesap kilitleme eşiğini 5 olarak ayarla
net accounts /lockoutthreshold:5

# Mevcut kilitleme ayarlarını kontrol et
net accounts | Select-String -Pattern "lockout"

Hesap Kilitleme Süresi

Account lockout duration, kilitlenen hesabın kaç dakika sonra otomatik olarak açılacağını belirler. 0 değeri, hesabın yalnızca bir yönetici tarafından açılabileceği anlamına gelir.

İki farklı yaklaşım var:

• Otomasyon yaklaşımı: 30 dakika kilitleme süresi. Saldırgan beklemek zorunda kalır, meşru kullanıcı da zaten Help Desk’i arayacaktır.
• Manuel açma yaklaşımı: 0 değeri, sadece admin açabilir. Daha güvenli ama operasyonel yük yaratır.

Yoğun kullanıcı desteğinin zor olduğu küçük ortamlarda 30 dakika mantıklı, kurumsal ortamlarda 0 daha uygundur.

Kilitleme Sayacının Sıfırlanma Süresi

Reset account lockout counter after, başarısız giriş denemelerinin sayacının kaç dakika sonra sıfırlanacağını belirler. Bu değer kilitleme süresinden küçük veya eşit olmalıdır.

Örneğin: Kilitleme eşiği 5, sıfırlanma süresi 30 dakika. Saldırgan 4 başarısız deneme yaparsa, 30 dakika beklemek zorunda kalır, sonra tekrar 4 deneme hakkı kazanır. Bu yavaş brute force saldırılarını engellemiyor gibi görünse de gerçekte saldırıyı pratik olarak işlevsiz kılar.

# Tüm kilitleme ayarlarını bir arada yapılandır
net accounts /lockoutthreshold:5 /lockoutduration:30 /lockoutwindow:30

# PowerShell ile Active Directory üzerinde kilitleme politikası (domain ortamı için)
Import-Module ActiveDirectory
Set-ADDefaultDomainPasswordPolicy -Identity "company.local" `
    -LockoutThreshold 5 `
    -LockoutDuration "00:30:00" `
    -LockoutObservationWindow "00:30:00"

Secedit ile Toplu Yapılandırma

Birden fazla sunucuyu yapılandırmanız gerektiğinde GUI yerine secedit aracını kullanmak çok daha pratiktir. Şöyle kapsamlı bir yapılandırma scripti hazırlayabilirsiniz:

# Kapsamli guvenlik politikasi uygulama scripti
# Oncelikle mevcut konfigurasyonu yedekle
$backupPath = "C:SecurityBackups$(Get-Date -Format 'yyyyMMdd_HHmmss')_policy_backup.cfg"
New-Item -ItemType Directory -Path "C:SecurityBackups" -Force | Out-Null
secedit /export /cfg $backupPath /areas SECURITYPOLICY
Write-Host "Mevcut politika yedeklendi: $backupPath" -ForegroundColor Green

# Yeni politika dosyasini olustur
$newPolicy = @"
[Unicode]
Unicode=yes
[System Access]
MinimumPasswordLength = 14
PasswordComplexity = 1
MaximumPasswordAge = 90
MinimumPasswordAge = 1
PasswordHistorySize = 24
ClearTextPassword = 0
LockoutBadCount = 5
ResetLockoutCount = 30
LockoutDuration = 30
[Version]
signature="`$CHICAGO`$"
Revision = 1
"@

$policyPath = "C:Tempsecurity_policy.inf"
$newPolicy | Out-File -FilePath $policyPath -Encoding Unicode

# Politikayi uygula
secedit /configure /db "C:Tempsecedit_apply.sdb" /cfg $policyPath /areas SECURITYPOLICY /log "C:Tempsecedit_apply.log"

Write-Host "Politika basariyla uygulanmistir." -ForegroundColor Green
Write-Host "Log dosyasi: C:Tempsecedit_apply.log" -ForegroundColor Yellow

Kilitli Hesapların Yönetimi

Politikayı uyguladıktan sonra operasyonel tarafı da düşünmeniz gerekiyor. Hesaplar kilitlendiğinde ne yapacaksınız?

# Kilitli hesaplari listele (Active Directory ortami)
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LockedOut, LastLogonDate

# Belirli bir hesabi kilidi ac
Unlock-ADAccount -Identity "kullanici.adi"

# Tum kilitli hesaplari ac (dikkatli kullanin!)
Search-ADAccount -LockedOut | Unlock-ADAccount

# Yerel hesap kilidinii acma (standalone sunucu)
net user KullaniciAdi /active:yes

# Hesabin kilitli olup olmadigini kontrol et
net user KullaniciAdi | findstr /i "active"

Büyük ortamlarda bu işlemleri otomatize etmek için bir monitoring scripti yazmak mantıklıdır:

# Kilitli hesaplari izle ve bildirim gonder
# Bu scripti Task Scheduler ile her 15 dakikada bir calistirabilirsiniz

$lockedAccounts = Search-ADAccount -LockedOut

if ($lockedAccounts.Count -gt 0) {
    $report = $lockedAccounts | Select-Object Name, SamAccountName, @{
        Name = 'LastAttempt'
        Expression = { (Get-ADUser $_.SamAccountName -Properties PasswordLastSet).PasswordLastSet }
    }

    # E-posta bildirimi (SMTP ayarlarinizi guncellemeniz gerekir)
    $emailBody = $report | Format-Table | Out-String
    Send-MailMessage `
        -From "[email protected]" `
        -To "[email protected]" `
        -Subject "Kilitli Hesap Uyarisi: $($lockedAccounts.Count) hesap kilitlendi" `
        -Body $emailBody `
        -SmtpServer "mail.company.com"

    Write-EventLog -LogName Application -Source "SecurityMonitor" `
        -EventId 9001 -EntryType Warning `
        -Message "Kilitli hesap tespit edildi: $($lockedAccounts.Count) hesap"
}

Gerçek Dünya Senaryosu: Orta Ölçekli Bir Firma

Yaklaşık 150 kullanıcılı, tek domain controller’ı olan bir firma düşünelim. Bu firmada şu sorunlar yaşandı:

• Birden fazla çalışanın hesabı ele geçirildi
• Parola politikası yoktu, çalışanlar “Firma2023” gibi parolalar kullanıyordu
• RDP her yerde açıktı
• Hesap kilitleme devre dışıydı

Uyguladığımız çözüm adımları şöyleydi:

1. Adım: Mevcut durumu analiz et

# Süresi dolmus parolalari olan hesaplari bul
Search-ADAccount -PasswordExpired | Select-Object Name, SamAccountName, PasswordLastSet

# Parola hic degistirilmemis hesaplari bul
Get-ADUser -Filter * -Properties PasswordNeverExpires, PasswordLastSet |
    Where-Object { $_.PasswordNeverExpires -eq $true } |
    Select-Object Name, SamAccountName, PasswordLastSet |
    Sort-Object PasswordLastSet

2. Adım: Domain password policy güncellendi, Fine-Grained Password Policy ile servis hesapları için ayrı politika tanımlandı.

3. Adım: Tüm kullanıcılara bir sonraki girişte parola değiştirme zorunluluğu getirildi.

4. Adım: Help Desk ekibine hesap kilidi açma prosedürü anlatıldı ve bir ticket sistemi entegrasyonu yapıldı.

İlk hafta 40’tan fazla hesap kilitlendi, çünkü insanlar zayıf parolalarını hatırlamıyordu. İkinci haftadan itibaren bu sayı dramatik şekilde düştü.

Fine-Grained Password Policy: Farklı Gruplara Farklı Politikalar

Active Directory ortamlarında standart domain politikasının yanı sıra belirli kullanıcı gruplarına özel politikalar uygulayabilirsiniz. Bu özelliğe Fine-Grained Password Policy (PSO) denir ve Windows Server 2008’den itibaren kullanılabilir.

Örneğin servis hesaplarına veya yöneticilere daha sıkı parola gereksinimleri uygulayabilirsiniz:

# Yoneticiler icin daha siki politika olustur
New-ADFineGrainedPasswordPolicy `
    -Name "AdminPasswordPolicy" `
    -Precedence 10 `
    -MinPasswordLength 20 `
    -PasswordHistoryCount 24 `
    -ComplexityEnabled $true `
    -ReversibleEncryptionEnabled $false `
    -MaxPasswordAge "60.00:00:00" `
    -MinPasswordAge "1.00:00:00" `
    -LockoutThreshold 3 `
    -LockoutDuration "01:00:00" `
    -LockoutObservationWindow "01:00:00"

# Politikayi Domain Admins grubuna uygula
Add-ADFineGrainedPasswordPolicySubject `
    -Identity "AdminPasswordPolicy" `
    -Subjects "Domain Admins"

# Politikayi kontrol et
Get-ADFineGrainedPasswordPolicy -Identity "AdminPasswordPolicy"

# Bir kullaniciya uygulanan efektif politikayi gor
Get-ADUserResultantPasswordPolicy -Identity "admin.kullanici"

Yaygın Hatalar ve Kaçınılması Gerekenler

Yıllarca sistem yöneticiliği yaparak gözlemlediğim en yaygın hatalar şunlar:

• Administrator hesabını yeniden adlandırmamak: Saldırganlar “Administrator” hesabını hedef alır. Yeniden adlandırın ve devre dışı bir “Administrator” tuzak hesabı bırakın.

• Servis hesaplarını unutmak: Uygulama servis hesaplarına da parola politikası uygulandığında servisler çalışmayı durdurabilir. Managed Service Account (MSA) veya Group Managed Service Account (gMSA) kullanımı bu sorunu çözer.

• Kilitleme politikasını test etmeden uygulamak: Üretim ortamında uygulamadan önce test ortamında deneyin. Yanlış yapılandırma tüm kullanıcıları etkileyebilir.

• 0 kilitleme süresi ayarlayıp destek ekibini haberdar etmemek: Eğer hesaplar sadece yönetici tarafından açılabiliyorsa, 7/24 destek kanalı olmalı.

• Event Log’ları izlememek: Politika var ama kimse bakmıyorsa değeri sınırlıdır. Event ID 4740 (hesap kilitleme), 4625 (başarısız giriş) ve 4648 (açık kimlik bilgisiyle giriş) olaylarını mutlaka izleyin.

# Son 24 saatteki hesap kilitleme olaylarini goruntule
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4740
    StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, @{
    Name = 'LockedAccount'
    Expression = { $_.Properties[0].Value }
}, @{
    Name = 'CallerComputer'
    Expression = { $_.Properties[1].Value }
} | Sort-Object TimeCreated -Descending

Uyumluluk Gereksinimlerine Göre Ayarlar

Farklı uyumluluk standartları farklı minimum gereksinimler belirler:

• PCI-DSS 4.0: Minimum 12 karakter, 90 gün maksimum geçerlilik, kilitleme eşiği maksimum 10 deneme
• NIST SP 800-63B: Minimum 8 karakter (ama 15+ önerilir), parola listesi kontrolü, zorunlu değiştirme yok
• CIS Benchmark (Windows Server 2022): Minimum 14 karakter, kilitleme eşiği 5 veya daha az, 15 dakika kilitleme süresi
• ISO 27001: Kuruluş bazlı risk değerlendirmesine göre belirlenir

Hangi standarda tabi olduğunuzu bilmek, politikanızı doğru yapılandırmanın başlangıç noktasıdır.

Sonuç

Parola ve hesap kilitleme politikaları, Windows Server güvenliğinin temel yapı taşlarından biridir. Doğru yapılandırıldığında brute force saldırılarını büyük ölçüde engeller, credential stuffing girişimlerini işlevsiz kılar ve uyumluluk gereksinimlerini karşılamanıza yardımcı olur.

Özetleyecek olursam şu maddeleri uygulamak başlangıç için yeterlidir:

• Minimum 14 karakter parola uzunluğu
• Karmaşıklık gereksinimlerini etkinleştir
• Parola geçmişini 24 olarak ayarla
• Kilitleme eşiğini 5 olarak belirle
• Kilitleme süresini 30 dakika veya 0 (admin açacak) yap
• Event Log izlemesini mutlaka kur

Bu ayarlar ne kadar erken uygulanırsa o kadar iyidir. Bir ihlal yaşandıktan sonra pişman olmak yerine, beş dakikalık bir yapılandırmayla sisteminizi çok daha güvenli hale getirebilirsiniz. Güvenlik her zaman reaktif değil proaktif olmalı.