Blog

  • PowerShell Komutları (Profesyonel Rehber)

    PowerShell Komutları (Profesyonel Rehber)

    Birçok kişi PowerShell komutları konusuna yalnızca “hangi komut ne işe yarar?” düzeyinde yaklaşır. Oysa profesyonel kullanımda asıl fark yaratan konu komut ezberi değil; cmdlet mantığını, pipeline yapısını, nesne tabanlı çalışma modelini ve çıktıyı rapora dönüştürme disiplinini doğru anlamaktır.

    PowerShell, modern Windows yönetiminin en kritik araçlarından biridir. Sadece komut satırından işlem yapmak için değil; otomasyon, raporlama, uzaktan yönetim, konfigürasyon standardizasyonu ve tekrarlayan operasyonların güvenli şekilde yönetilmesi için kullanılır.

    Bu rehberde en çok kullanılan PowerShell komutlarını, gerçek sistem yöneticisi senaryolarıyla birlikte ele alacağız. İçerik hem başlangıç seviyesine yol gösterecek hem de orta ve ileri seviye kullanıcılar için referans niteliğinde olacaktır.

    PowerShell’in en önemli özelliklerinden biri, çıktıları düz metin yerine nesne olarak iletmesidir. Bu sayede komutlar birbirine sadece yazı aktarmak yerine yapılandırılmış veri aktarır. Microsoft’un resmi dokümantasyonu da pipeline’ın, nesneleri bir komuttan diğerine bağlayan temel mekanizma olduğunu açık biçimde belirtir. Ayrıntılı teknik arka plan için şu kaynakları inceleyebilirsiniz: about_Pipelines ve Invoke-Command.

    PowerShell Neden Hâlâ Bu Kadar Kritik?

    GUI araçları birçok işlem için yeterli görünse de kurumsal ölçekte yönetim yapıldığında grafik arayüzler hızla yetersiz kalır. Bir kullanıcıyı tek ekrandan oluşturmak kolaydır; ama yüzlerce kullanıcıyı standardize edilmiş şekilde oluşturmak, yüzlerce sunucuda servis kontrolü yapmak, log toplamak veya düzenli rapor üretmek için komut tabanlı otomasyon gerekir.

    PowerShell bu noktada öne çıkar çünkü:

    • Windows yönetimi için doğal ekosisteme sahiptir.
    • Nesne tabanlıdır; çıktılar kolayca filtrelenir, sıralanır ve raporlanır.
    • Uzak sunucularda merkezi işlem yapabilir.
    • Script ve görev zamanlama ile tekrar eden işleri otomatikleştirir.
    • CSV, JSON ve REST API gibi modern entegrasyonlara kolayca bağlanabilir.

    PowerShell 7.x ile birlikte platform desteği genişlemiş, ancak Windows PowerShell 5.1 ile PowerShell 7.x arasında modül uyumluluğu ve davranış farklılıkları da oluşmuştur. Microsoft, Windows PowerShell 5.1’in .NET Framework üzerinde; PowerShell 7.x’in ise modern .NET üzerinde çalıştığını ve bu nedenle bazı modül ve davranış farkları bulunduğunu belirtir. Bu ayrım özellikle üretim scriptlerinde önemlidir. :contentReference[oaicite:1]{index=1}

    PowerShell’de Cmdlet Mantığı: Verb-Noun Standardı

    PowerShell komutları çoğunlukla Verb-Noun biçiminde adlandırılır. Bu standardizasyonun amacı komutların tahmin edilebilir ve okunabilir olmasıdır.

    Örnek cmdlet’ler:

    • Get-Service
    • Start-Service
    • Stop-Process
    • Get-ChildItem
    • Set-Location
    • Invoke-Command

    Bu yapı sayesinde bilmediğiniz bir komutu bile tahmin etmeniz kolaylaşır. Örneğin bir şeyi listelemek için çoğunlukla Get-, başlatmak için Start-, durdurmak için Stop-, yeni bir nesne oluşturmak için New- kullanılır.

    PowerShell Öğrenmenin En Kritik 3 Komutu

    Profesyonel kullanıma geçişte üç komut özellikle kritik rol oynar: Get-Command, Get-Help ve Get-Member. Bunlar sadece “komutlar” değildir; PowerShell’i öğrenme sistemidir.

    1. Get-Command

    Get-Command, sistemde kullanılabilir komutları listeler. Bir yönetici için keşif aracıdır.

    Get-Command

    Belirli bir isim desenine göre arama yapmak için:

    Get-Command *service*

    Belirli fiile göre arama yapmak için:

    Get-Command -Verb Get

    Belirli isim grubuna göre arama yapmak için:

    Get-Command -Noun Process

    Bu yaklaşım, yeni bir modül ya da teknoloji öğrenirken çok işe yarar. Örneğin “servislerle ilgili hangi komutlar var?” sorusunun cevabı birkaç saniyede bulunabilir.

    2. Get-Help

    Get-Help, bir cmdlet’in nasıl kullanıldığını, parametrelerini ve örneklerini gösterir.

    Get-Help Get-Service

    Örnekleri görmek için:

    Get-Help Get-Service -Examples

    Daha detaylı yardım için:

    Get-Help Get-Service -Detailed

    Pipeline desteğini görmek için tam yardım kullanmak özellikle önemlidir. Microsoft’un pipeline dokümantasyonu da, bir cmdlet’in hangi parametrelerinin pipeline girdisi kabul ettiğini anlamak için Get-Help -Full veya Get-Help -Parameter * kullanılmasını önerir. :contentReference[oaicite:2]{index=2}

    3. Get-Member

    Get-Member, PowerShell’in neden nesne tabanlı olduğunu anlamanın anahtarıdır. Bir komutun ürettiği nesnelerin hangi özellik ve metotlara sahip olduğunu gösterir.

    Get-Service | Get-Member

    Bu komutla Get-Service çıktısının sadece yazı olmadığını, aslında Status, Name, DisplayName gibi özelliklere sahip nesneler ürettiğini görürsünüz.

    Pipeline Mantığı: PowerShell’in Gerçek Gücü

    PowerShell’in profesyonel kullanımında kırılma noktası pipeline mantığını kavramaktır. Pipeline, bir komutun çıktısını diğerine gönderir; ancak burada iletilen şey çoğu zaman düz metin değil, nesnedir. Microsoft’un resmi açıklamasına göre pipeline, nesnelerin bir komuttan diğerine bağlanmasını sağlar ve parametreler nesneleri ByValue veya ByPropertyName ile kabul edebilir. :contentReference[oaicite:3]{index=3}

    Temel örnek:

    Get-Service | Where-Object Status -eq 'Running'

    Burada olan şey şudur:

    1. Get-Service servis nesnelerini üretir.
    2. Where-Object bu nesneleri filtreler.
    3. Sonuçta yalnızca çalışan servisler kalır.

    Bir adım daha ileri gidelim:

    Get-Service | Where-Object Status -eq 'Running' | Select-Object Name, Status

    Bu zincirde önce veri alınır, sonra filtrelenir, ardından sadece ihtiyaç duyulan alanlar seçilir. Günlük yönetim işlerinin çok büyük kısmı bu mantıkla çözülür.

    Pipeline Neden Düz Metin Zinciri Değildir?

    Linux dünyasına alışkın olanlar çoğu zaman pipeline’ı metin borusu gibi düşünür. PowerShell’de ise borudan akan şey bir nesne koleksiyonudur. Bu nedenle sütun seçme, özellik bazlı sıralama, filtreleme ve CSV’ye aktarma çok daha doğal hale gelir.

    ByValue ve ByPropertyName

    PowerShell’de bazı parametreler pipeline girişini doğrudan nesne türüne göre kabul eder (ByValue), bazıları ise nesnenin ilgili isimde bir özelliği varsa kabul eder (ByPropertyName). Microsoft’un about_Pipelines belgesi bu ayrımı açıkça tanımlar. Bu mantığı anlamak, “neden bazı komut zincirleri çalışıyor, bazıları çalışmıyor?” sorusunu çözmenin temelidir. :contentReference[oaicite:4]{index=4}

    En Çok Kullanılan PowerShell Komutları

    Aşağıdaki cmdlet’ler günlük sistem yönetiminde en sık başvurulan komutlar arasındadır. Bunları sadece tanım olarak değil, kullanım mantığıyla birlikte değerlendirmek gerekir.

    Get-ChildItem

    Dosya ve klasör içeriğini listeler. Windows tarafında klasik dir komutunun PowerShell karşılığı gibi düşünülse de çok daha güçlüdür.

    Get-ChildItem C:\Logs

    Alt klasörlerle birlikte taramak için:

    Get-ChildItem C:\Logs -Recurse

    Belli uzantıdaki dosyaları bulmak için:

    Get-ChildItem C:\Logs -Filter *.log -Recurse

    Gerçek kullanım senaryosu: Belirli bir klasörde son 7 günde değişen log dosyalarını bulmak.

    Get-ChildItem C:\Logs -File -Recurse |
    Where-Object LastWriteTime -gt (Get-Date).AddDays(-7) |
    Select-Object FullName, Length, LastWriteTime

    Set-Location

    Çalışma dizinini değiştirir.

    Set-Location D:\Scripts

    Tek başına basit görünür, ancak script akışında göreli yollarla çalışan otomasyonlarda önemlidir.

    Get-Process

    Sistemde çalışan process’leri listeler.

    Get-Process

    En çok CPU kullanan süreçleri sıralamak için:

    Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10 Name, Id, CPU

    Bu tip kullanım, performans analizi ve anlık sorun çözümünde çok değerlidir.

    Get-Service

    Servisleri listeler.

    Get-Service

    Sadece çalışan servisleri göstermek için:

    Get-Service | Where-Object Status -eq 'Running'

    Sadece durmuş olan kritik servisleri raporlamak için:

    Get-Service |
    Where-Object Status -eq 'Stopped' |
    Select-Object Name, DisplayName, Status

    Start-Service ve Stop-Service

    Servis başlatmak ve durdurmak için kullanılır.

    Start-Service Spooler
    Stop-Service Spooler

    Bu komutlar özellikle otomasyon, bakım penceresi ve servis sağlığı kontrolü için önemlidir.

    Where-Object

    Pipeline’dan gelen nesneleri filtreler. En çok kullanılan komutlardan biridir.

    Get-Process | Where-Object WorkingSet -gt 200MB

    PowerShell’de profesyonel kullanımın büyük kısmı veri alıp filtrelemeye dayanır. Bu yüzden Where-Object çekirdek araçtır.

    Select-Object

    Gereken alanları seçer. Raporlama için vazgeçilmezdir.

    Get-Service | Select-Object Name, Status, StartType

    İlk 5 sonucu almak için:

    Get-Process | Select-Object -First 5

    Son 5 sonucu almak için:

    Get-Process | Select-Object -Last 5

    Sort-Object

    Nesneleri belirli özelliklere göre sıralar. Microsoft dokümantasyonu, hem metin hem sayısal dönüşüm senaryoları için kullanılabildiğini ve script block ile özel sıralama yapılabildiğini gösterir. :contentReference[oaicite:5]{index=5}

    Get-Service | Sort-Object Status, Name

    Diskteki en büyük dosyaları bulmak için:

    Get-ChildItem D:\Data -File -Recurse |
    Sort-Object Length -Descending |
    Select-Object -First 20 FullName, Length

    ForEach-Object

    Pipeline’dan gelen her nesne için işlem yapar.

    Get-Service | ForEach-Object { $_.Name }

    Daha anlamlı örnek:

    Get-ChildItem C:\Temp -File |
    ForEach-Object {
        [PSCustomObject]@{
            Name = $_.Name
            SizeMB = [math]::Round($_.Length / 1MB, 2)
        }
    }

    Ancak Microsoft’un performans rehberi, pipeline içinde gereksiz şekilde başka pipeline’lar başlatmanın maliyetli olabileceğini ve özellikle Export-Csv gibi komutların her iterasyonda çağrılmasının ciddi performans kaybı oluşturduğunu vurgular. Bu nedenle ForEach-Object kullanırken akış tasarımına dikkat etmek gerekir. :contentReference[oaicite:6]{index=6}

    Format-Table

    Çıktıyı tablo halinde daha okunabilir gösterir.

    Get-Service | Select-Object Name, Status | Format-Table -AutoSize

    Önemli not: Format-Table raporlama zincirinin sonuna yakın kullanılmalıdır. Çünkü biçimlendirme komutları çıktıyı görsel amaçla düzenler; sonrasında CSV ya da JSON’a dönüştürmek istenirse sorun çıkabilir.

    Dosya Sistemi Yönetiminde Güçlü PowerShell Komutları Örnekleri

    PowerShell en çok dosya, klasör, log ve arşiv yönetiminde zaman kazandırır.

    Büyük Dosyaları Bulma

    Get-ChildItem D:\Shares -File -Recurse |
    Sort-Object Length -Descending |
    Select-Object -First 50 FullName, Length

    Belirli Tarihten Sonra Değişen Dosyaları Listeleme

    Get-ChildItem D:\Shares -File -Recurse |
    Where-Object LastWriteTime -gt (Get-Date).AddDays(-30) |
    Select-Object FullName, LastWriteTime

    Boş Klasörleri Bulma

    Get-ChildItem D:\Shares -Directory -Recurse |
    Where-Object { (Get-ChildItem $_.FullName -Force | Measure-Object).Count -eq 0 } |
    Select-Object FullName

    Bu örnekler özellikle file server housekeeping, storage analizi ve migration öncesi keşif işlemlerinde çok faydalıdır.

    Servis ve Process Yönetiminde Profesyonel Kullanım

    Sistem yöneticileri için servis sağlığı ve işlem takibi günlük işin merkezindedir.

    Durmuş Servisleri Listeleme

    Get-Service |
    Where-Object Status -eq 'Stopped' |
    Select-Object Name, DisplayName, StartType

    Otomatik Başlayan Ama Çalışmayan Servisleri Bulma

    Get-Service |
    Where-Object { $_.StartType -eq 'Automatic' -and $_.Status -ne 'Running' } |
    Select-Object Name, DisplayName, Status, StartType

    CPU Tüketen Süreçleri İzleme

    Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10 Name, Id, CPU, WorkingSet

    Bellek Kullanımına Göre Süreç Sıralama

    Get-Process |
    Sort-Object WorkingSet -Descending |
    Select-Object -First 10 Name, Id,
    @{Name='MemoryMB';Expression={[math]::Round($_.WorkingSet / 1MB, 2)}}

    Bu tip komutlar anlık troubleshooting sırasında çok değerlidir. GUI ile tek tek bakmak yerine birkaç saniyede filtrelenmiş sonuç alınabilir.

    Event Log Analizi için Kritik Komutlar

    Windows troubleshooting denildiğinde event log analizi vazgeçilmezdir. Burada Get-WinEvent öne çıkar.

    Get-WinEvent -LogName System -MaxEvents 50

    Son 24 saatteki hata kayıtlarını bulmak için:

    Get-WinEvent -LogName System |
    Where-Object {
        $_.LevelDisplayName -eq 'Error' -and
        $_.TimeCreated -gt (Get-Date).AddDays(-1)
    } |
    Select-Object TimeCreated, Id, ProviderName, Message

    Belirli Event ID’ye göre filtreleme:

    Get-WinEvent -LogName System |
    Where-Object Id -eq 7036 |
    Select-Object TimeCreated, Id, Message

    Bu yapı, özellikle servis restart’ları, disk hataları ve sistem kararsızlıklarında hızlı analiz sağlar.

    Ağ ve Bağlantı Kontrolünde Kullanılan Komutlar

    PowerShell sadece yerel sistem yönetimi için değil, ağ sağlığı ve bağlantı testleri için de sık kullanılır.

    Test-Connection

    Test-Connection, bir hedefe ICMP tabanlı erişim testi yapar.

    Test-Connection SRV-FS01 -Count 2

    Birden fazla sunucuyu test etmek için:

    'SRV-FS01','SRV-APP01','SRV-DB01' |
    ForEach-Object {
        Test-Connection $_ -Count 1 -ErrorAction SilentlyContinue
    }

    Basit Ulaşılabilirlik Raporu

    'SRV-FS01','SRV-APP01','SRV-DB01' |
    ForEach-Object {
        $result = Test-Connection $_ -Count 1 -Quiet -ErrorAction SilentlyContinue
        [PSCustomObject]@{
            ComputerName = $_
            Reachable    = $result
        }
    }

    Bu yaklaşım, günlük sağlık kontrolleri ve izleme scriptleri için temel oluşturur.

    Uzak Sunucu Yönetimi: Invoke-Command ve Remoting

    Kurumsal ortamda gerçek güç, aynı komutu onlarca hatta yüzlerce sunucuda merkezi biçimde çalıştırabilmektir. Bu noktada Invoke-Command kritik cmdlet’lerden biridir.

    Invoke-Command -ComputerName SRV-FS01 -ScriptBlock { Get-Service }

    Birden fazla sunucuda aynı komutu çalıştırmak için:

    Invoke-Command -ComputerName SRV-FS01,SRV-APP01,SRV-DB01 -ScriptBlock {
        Get-Service | Where-Object Status -eq 'Running'
    }

    Belirli bir servis durumunu uzaktan sorgulamak için:

    Invoke-Command -ComputerName SRV-FS01 -ScriptBlock {
        Get-Service -Name LanmanServer
    }

    Microsoft dokümantasyonuna göre Invoke-Command, yerel ya da uzak bilgisayarlarda komut çalıştırmak için kullanılır ve PowerShell remoting mimarisinin temel parçalarından biridir. :contentReference[oaicite:7]{index=7}

    Uzak Yönetimde Dikkat Edilmesi Gerekenler

    • Remoting yapılandırmasının açık olması gerekir.
    • Firewall ve WinRM izinleri doğru olmalıdır.
    • Yetki seviyesi üretim ortamında kontrollü kullanılmalıdır.
    • Yaygın komutlar önce test ortamında doğrulanmalıdır.

    Raporlama ve Veri Dışa Aktarma

    PowerShell’i profesyonel yapan şeylerden biri, çıktıyı yalnızca ekranda göstermeyip rapora dönüştürebilmesidir.

    Export-Csv

    Export-Csv, nesneleri CSV dosyasına aktarır. Microsoft dokümantasyonu bu cmdlet’in nesneleri satır/sütun yapısına dönüştürerek dışa aktardığını belirtir. :contentReference[oaicite:8]{index=8}

    Get-Service |
    Select-Object Name, Status, StartType |
    Export-Csv .\services.csv -NoTypeInformation

    Bu çıktı Excel’de rahatlıkla açılabilir ve ekiplerle paylaşılabilir.

    JSON Çıktısı

    Get-Service |
    Select-Object Name, Status, StartType |
    ConvertTo-Json

    JSON çıktısı özellikle API entegrasyonları ve otomasyon sistemlerinde kullanışlıdır.

    Örnek Sunucu Sağlık Raporu

    $services = Get-Service |
    Where-Object Status -eq 'Stopped' |
    Select-Object Name, DisplayName, Status, StartType
    
    $processes = Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10 Name, Id, CPU
    
    $services | Export-Csv .\stopped_services.csv -NoTypeInformation
    $processes | Export-Csv .\top_processes.csv -NoTypeInformation

    Bu yapı, günlük bakım raporları, audit çıktıları ve kapasite değerlendirmeleri için çok kullanışlıdır.

    PowerShell Performansı: Script Yazarken Nelere Dikkat Etmeli?

    Birçok yönetici PowerShell’de komutu çalıştırır ama ölçek büyüdüğünde performans maliyeti fark edilir hale gelir. Microsoft’un script performansı rehberi, özellikle pipeline içinde gereksiz pipeline başlatmaktan kaçınılmasını önerir. Aynı şekilde Export-Csv komutunu her döngü adımında çağırmak yerine, nesneleri üretip en sonda tek seferde CSV’ye aktarmak çok daha verimli olabilir. Microsoft’un örneğinde bu fark yüzlerce kat performans avantajı oluşturur. :contentReference[oaicite:9]{index=9}

    Verimsiz Yaklaşım Powershell Komutları

    Import-Csv .\Input.csv | ForEach-Object {
        [pscustomobject]@{
            Name = $_.Name
        } | Export-Csv .\Output.csv -Append -NoTypeInformation
    }

    Daha Doğru Yaklaşım

    Import-Csv .\Input.csv | ForEach-Object {
        [pscustomobject]@{
            Name = $_.Name
        }
    } | Export-Csv .\Output.csv -NoTypeInformation

    Bu ayrım küçük görünse de büyük veri setlerinde ciddi fark yaratır.

    Sistem Yöneticileri İçin 15 Pratik PowerShell Komutu

    Aşağıda günlük operasyonda çok iş gören, kısa ama güçlü komut seti yer alıyor.

    1. Sistemdeki komutları bulma

    Get-Command

    2. Komut örneklerini görme

    Get-Help Get-Service -Examples

    3. Nesne özelliklerini inceleme

    Get-Service | Get-Member

    4. Çalışan servisleri listeleme

    Get-Service | Where-Object Status -eq 'Running'

    5. Duran servisleri listeleme

    Get-Service | Where-Object Status -eq 'Stopped'

    6. En çok CPU kullanan süreçleri görme

    Get-Process | Sort-Object CPU -Descending | Select-Object -First 10

    7. En çok RAM kullanan süreçleri görme

    Get-Process | Sort-Object WorkingSet -Descending | Select-Object -First 10

    8. Son 50 sistem logunu çekme

    Get-WinEvent -LogName System -MaxEvents 50

    9. Belirli klasördeki .log dosyalarını bulma

    Get-ChildItem C:\Logs -Filter *.log -Recurse

    10. Son 7 günde değişen dosyaları bulma

    Get-ChildItem D:\Data -File -Recurse |
    Where-Object LastWriteTime -gt (Get-Date).AddDays(-7)

    11. Bir sunucuya ping atma

    Test-Connection SRV-FS01 -Count 2

    12. Uzak sunucuda servis listeleme

    Invoke-Command -ComputerName SRV-FS01 -ScriptBlock { Get-Service }

    13. CSV raporu oluşturma

    Get-Service | Select-Object Name, Status | Export-Csv .\services.csv -NoTypeInformation

    14. JSON çıktısı alma

    Get-Process | Select-Object Name, Id, CPU | ConvertTo-Json

    15. Sonuçları tablo biçiminde gösterme

    Get-Service | Select-Object Name, Status | Format-Table -AutoSize

    PowerShell Kullanırken En Sık Yapılan Hatalar

    Alias’larla Script Yazmak

    Konsolda hızlı çalışırken alias kullanmak cazip gelebilir; ancak üretim scriptlerinde gci yerine Get-ChildItem, ? yerine Where-Object kullanmak okunabilirlik ve bakım açısından daha doğrudur.

    Format Komutlarını Çok Erken Kullanmak

    Format-Table veya Format-List komutlarını pipeline’ın ortasında kullanmak, nesne akışını bozabilir. Bu komutlar sunum içindir; veri işleme zincirinin sonuna yakın kullanılmalıdır.

    Doğrudan Production Ortamında Deneme Yapmak

    Özellikle servis durdurma, dosya silme, yetki değiştirme gibi komutlar önce test ortamında doğrulanmalıdır. PowerShell güçlüdür; bu güç hatayı da büyütebilir.

    Pipeline Mantığını Anlamadan Kopyala-Yapıştır Kullanmak

    Bir komutun neden çalıştığını anlamadan kullanmak sürdürülebilir değildir. Özellikle Get-Member ve Get-Help bu nedenle sürekli kullanılmalıdır.

    Performans Etkisini Göz Ardı Etmek

    Büyük veri setlerinde ya da yüzlerce sunucuda çalışan scriptlerde küçük tasarım hataları ciddi gecikmeler yaratabilir. Microsoft’un performans önerileri bu konuda doğrudan uygulanabilir pratikler sunar. :contentReference[oaicite:10]{index=10}

    PowerShell 5.1 mi, PowerShell 7 mi?

    Bu soru sahada çok sık sorulur. Kısa cevap: ortamına göre değişir.

    • Windows PowerShell 5.1, eski kurumsal modüllerle yüksek uyumluluk sunar.
    • PowerShell 7.x, modern .NET tabanı, çapraz platform desteği ve performans iyileştirmeleriyle öne çıkar.

    Ancak tüm modüller PowerShell 7’de aynı şekilde çalışmayabilir. Özellikle eski Windows odaklı yönetim modüllerinde dikkatli test gerekir. Microsoft bu farkları resmi fark dokümanında ayrıntılı olarak listeler. :contentReference[oaicite:11]{index=11}

    Gerçek Kurumsal Senaryo

    Bir kurumda onlarca Windows sunucusunun servis sağlığı her sabah manuel olarak kontrol ediliyordu. Yönetim ekibi uzak masaüstü bağlantılarıyla tek tek sunuculara bağlanıyor, kritik servisleri gözle kontrol ediyor ve sorunları Excel’e işliyordu. Süreç hem yavaştı hem de insan hatasına açıktı.

    Bu süreç daha sonra PowerShell ile yeniden tasarlandı. Sunucu listesi bir metin dosyasında tutuldu, Invoke-Command ile kritik servisler merkezi olarak sorgulandı, sonuçlar filtrelenip Export-Csv ile raporlandı. Sonuç olarak günlük kontrol süresi ciddi biçimde kısaldı ve standart rapor üretimi mümkün hale geldi.

    Bu örnek, PowerShell’in neden sadece “komut çalıştırma” değil, gerçek bir operasyon standardizasyon aracı olduğunu net biçimde gösterir.

    Sonuç

    PowerShell komutları konusu yüzeysel ele alındığında yalnızca bir komut listesi gibi görünür. Oysa profesyonel seviyede PowerShell; nesne mantığı, pipeline disiplini, filtreleme, uzaktan yönetim ve raporlama yeteneği sayesinde sistem yöneticilerinin en güçlü araçlarından biri haline gelir.

    Bu rehberde ele alınan komutlar, günlük sistem yönetimi için çekirdek bir toolkit oluşturur. Ancak asıl değer komutların tek tek bilinmesinde değil; doğru sırayla birleştirilmesinde, çıktının anlamlandırılmasında ve otomasyona dönüştürülmesindedir.

    PowerShell’i gerçekten iyi kullanmak isteyen herkes için öneri nettir: Get-Command ile keşfet, Get-Help ile öğren, Get-Member ile nesneyi tanı, sonra pipeline ile gerçek gücü kullan.

    File server ve Windows yönetimi tarafında daha derin içerikler için şu rehberlere de göz atabilirsiniz: Windows File Server Güvenliği, NTFS Permission Tasarımı, File Server Migration ve Windows File Server Performans İyileştirme.

    Sık Sorulan Sorular

    PowerShell komutları neden bu kadar önemli?

    Çünkü PowerShell, Windows yönetiminde otomasyon, raporlama ve uzaktan yönetim için standart araçlardan biridir. Tekrarlayan işleri hızlandırır ve insan hatasını azaltır.

    PowerShell’de en önemli öğrenme komutları hangileridir?

    Get-Command, Get-Help ve Get-Member. Bu üç cmdlet, komut keşfi, yardım sistemi ve nesne mantığını anlamak için temel oluşturur.

    Pipeline mantığı neden kritik?

    Çünkü PowerShell’in asıl gücü komutları zincirlemekten gelir. Bir komutun çıktısı başka bir komuta nesne olarak aktarılır; bu da filtreleme, sıralama ve raporlamayı kolaylaştırır.

    PowerShell 7 mi yoksa Windows PowerShell 5.1 mi kullanılmalı?

    Modern özellikler ve çapraz platform desteği için PowerShell 7 avantajlıdır. Ancak bazı eski kurumsal modüller Windows PowerShell 5.1 ile daha uyumlu olabilir. Bu yüzden üretim ortamında test şarttır.

    Export-Csv neden bu kadar sık kullanılır?

    Çünkü PowerShell çıktısını paylaşılabilir, analiz edilebilir ve Excel’de açılabilir rapora dönüştürmenin en pratik yollarından biridir.

    Bu makalede detaylı en çok kullanılan bir sistem yöneticisi için en gerekli powershell komutları ile ilgili bilgiler verdim. Eklemek istediğiniz ya da sormak istediğiniz ne varsa yorumlarda belirtebilirsiniz.

  • Windows File Server Migration Rehberi (Adım Adım Veri Taşıma)

    Windows File Server Migration Rehberi (Adım Adım Veri Taşıma)

    Kurumsal IT altyapılarında zamanla depolama ihtiyaçlarının artması, eski sunucuların performansının yetersiz kalması veya yeni mimariye geçiş yapılması gibi nedenlerle file server migration süreci kaçınılmaz hale gelir.

    Ancak file server taşıma işlemi yalnızca verilerin kopyalanmasından ibaret değildir. NTFS permission yapısının korunması, kullanıcı kesintisinin minimuma indirilmesi ve veri bütünlüğünün sağlanması kritik öneme sahiptir.

    Bu rehberde Windows File Server migration sürecini baştan sona ele alıyoruz. Kurumsal ortamlarda kullanılan en güvenilir yöntemlerden biri olan Robocopy ile veri taşıma, permission migration ve kesintisiz geçiş stratejileri detaylı şekilde anlatılmaktadır.

    Windows File Server Migration Nedir?

    File Server Migration, mevcut bir dosya sunucusundaki verilerin ve erişim izinlerinin yeni bir sunucuya taşınması işlemidir.

    Migration sürecinin temel amaçları şunlardır:

    • Yeni donanıma geçiş
    • Daha hızlı storage kullanımı
    • Windows Server upgrade
    • Yedeklilik ve performans iyileştirme

    File Server Migration Öncesi Planlama

    Migration sürecinin başarılı olması için önceden planlama yapılması gerekir.

    Mevcut Yapının Analizi

    Öncelikle mevcut file server üzerinde aşağıdaki bilgiler analiz edilmelidir.

    • Klasör yapısı
    • Toplam veri boyutu
    • NTFS permission yapısı
    • Paylaşım isimleri
    • Kullanıcı erişim yoğunluğu

    Disk Alanı Kontrolü

    Yeni sunucunun yeterli depolama kapasitesine sahip olduğundan emin olunmalıdır.

    Get-PSDrive
    

    Permission Yapısının İncelenmesi

    NTFS izinleri migration sırasında korunmalıdır.

    Get-Acl "D:\Finance"
    

    File Server Migration Yöntemleri

    Windows ortamlarında file server migration için birkaç farklı yöntem kullanılabilir.

    • Robocopy
    • Storage Migration Service
    • DFS Replication
    • Backup Restore

    En yaygın ve güvenilir yöntem Robocopy kullanmaktır.

    Robocopy ile Dosya Sunucusu Taşıma

    Robocopy, Windows Server içerisinde bulunan güçlü bir dosya kopyalama aracıdır.

    Avantajları:

    • NTFS permission koruma
    • Resume özelliği
    • Büyük veri setlerinde yüksek performans
    • Log oluşturma

    Temel Robocopy Komutu

    
    robocopy D:\Data \\NewServer\Data /MIR /COPYALL /R:3 /W:5 /LOG:migration.log
    

    Parametre Açıklamaları

    • /MIR – Mirror mode (tam kopyalama)
    • /COPYALL – Tüm NTFS permission bilgilerini kopyalar
    • /R – Retry sayısı
    • /W – Bekleme süresi
    • /LOG – Log oluşturma

    Permission Migration

    Migration sırasında NTFS permission yapısının korunması önemlidir.

    Robocopy komutunda kullanılan /COPYALL parametresi aşağıdaki bilgileri taşır:

    • Data
    • Attributes
    • Timestamps
    • Security (NTFS permission)
    • Owner bilgisi

    Kesintisiz Migration Stratejisi

    Kullanıcı kesintisini azaltmak için migration genellikle iki aşamada yapılır.

    1. İlk Veri Kopyalama

    Veriler çalışma saatleri dışında ilk kez kopyalanır.

    
    robocopy D:\Data \\NewServer\Data /MIR /COPYALL
    

    2. Delta Sync

    Migration günü yalnızca değişen dosyalar kopyalanır.

    Bu işlem genellikle çok kısa sürer.

    Paylaşım Yapısının Taşınması

    File share yapılandırması da yeni sunucuya taşınmalıdır.

    PowerShell ile mevcut paylaşımlar listelenebilir.

    
    Get-SmbShare
    

    Yeni sunucuda share oluşturma:

    
    New-SmbShare -Name Finance -Path D:\Finance -FullAccess "Domain Admins"
    

    DNS veya Namespace Güncelleme

    Migration tamamlandıktan sonra kullanıcıların yeni sunucuya yönlendirilmesi gerekir.

    Bunun için aşağıdaki yöntemler kullanılabilir:

    • DNS Alias
    • DFS Namespace
    • Login Script güncellemesi

    Kurumsal ortamlarda en iyi yöntem genellikle DFS Namespace kullanmaktır.

    Migration Sonrası Kontroller

    Migration tamamlandıktan sonra aşağıdaki kontroller yapılmalıdır.

    • Dosya sayısı karşılaştırması
    • Permission doğrulaması
    • Kullanıcı erişim testi
    • Log inceleme

    Dosya sayısı kontrolü:

    
    robocopy D:\Data \\NewServer\Data /L /MIR
    

    Gerçek Hayat Senaryosu

    Bir kurumda 8 TB veri bulunan eski file server Windows Server 2012 üzerinde çalışıyordu. Performans sorunları ve storage yetersizliği nedeniyle yeni bir Windows Server 2022 sunucusuna migration planlandı.

    Migration süreci şu şekilde gerçekleştirildi:

    • Robocopy ile ilk veri kopyalama
    • Delta sync işlemi
    • DNS alias güncellemesi
    • Kullanıcı erişim testleri

    Bu yöntem sayesinde kullanıcılar neredeyse hiçbir kesinti yaşamadan yeni sunucuya geçiş yaptı.

    File Server Migration Best Practices

    • Migration öncesi test yapılmalı
    • Permission yapısı analiz edilmeli
    • Robocopy logları kontrol edilmeli
    • Downtime planı hazırlanmalı
    • Kullanıcı bilgilendirmesi yapılmalı

     

    File Server Migration, doğru planlama ve araçlar kullanıldığında oldukça güvenli şekilde gerçekleştirilebilir. Özellikle Robocopy kullanımı, NTFS permission yapısının korunmasını ve veri bütünlüğünün sağlanmasını mümkün kılar.

    Kurumsal ortamlarda migration sürecinin dikkatli planlanması, kesinti sürelerinin minimuma indirilmesi ve kullanıcı deneyiminin korunması açısından büyük önem taşır.

  • NTFS Permission Tasarımı ve AGDLP Modeli Rehberi

    NTFS Permission Tasarımı ve AGDLP Modeli Rehberi

    NTFS Permission Tasarımı: AGDLP Modeli ile Kurumsal Yetkilendirme Rehberi

    Kurumsal ortamlarda NTFS permission tasarımı, dosya sunucularının güvenli, sürdürülebilir ve yönetilebilir şekilde çalışması için kritik bir bileşendir. Yanlış yapılandırılmış izinler; veri sızıntısına, yetki karmaşasına, hatalı erişimlere ve operasyonel zorluklara neden olabilir.

    Özellikle büyük yapılarda kullanıcı bazlı yetki vermek yerine, grup tabanlı bir model kullanmak çok daha sağlıklı sonuç üretir. Bu noktada AGDLP modeli, Active Directory tabanlı ortamlarda en çok tercih edilen kurumsal yetkilendirme yaklaşımıdır. Bu rehberde NTFS permission tasarımı, share ve NTFS izin farkı, AGDLP modeli ve en iyi uygulamalar adım adım ele alınmaktadır.

    NTFS Permission Nedir?

    NTFS Permission Tasarımı

     

    NTFS permission, Windows işletim sistemlerinde dosya ve klasörlere erişim yetkilerini belirleyen güvenlik mekanizmasıdır. Bu yapı sayesinde bir kullanıcının veya grubun ilgili kaynağa hangi seviyede erişeceği tanımlanabilir.

    Temel izin türleri şunlardır:

    • Read: Dosya ve klasörleri görüntüleme
    • Write: Yeni içerik oluşturma veya veri yazma
    • Modify: Okuma, yazma, değiştirme ve silme
    • Full Control: Tüm işlemler ve izin yönetimi

    NTFS izinleri kullanıcı veya grup bazlı uygulanabilir. Ancak kurumsal yapılarda önerilen yaklaşım, doğrudan kullanıcıya yetki vermek yerine grup tabanlı yetkilendirme modelini kullanmaktır.

    Daha fazla teknik detay için Microsoft’un resmi dokümantasyonuna göz atabilirsiniz:
    NTFS permissions documentation.

    Share ve NTFS Permission Farkı

    Windows File Server ortamlarında iki temel yetkilendirme katmanı bulunur: Share Permission ve NTFS Permission. Bu iki yapı birbirini tamamlar ancak görevleri farklıdır.

    Share Permission

    Share permission, ağ üzerinden paylaşıma erişim seviyesini belirler. Kullanıcı paylaşıma network üzerinden bağlandığında ilk olarak bu katman devreye girer.

    NTFS Permission

    NTFS permission ise dosya ve klasör seviyesinde daha detaylı erişim kontrolü sağlar. Asıl güvenlik ve yetkilendirme yönetimi çoğu kurumsal ortamda burada yapılır.

    En yaygın ve doğru yaklaşım şu şekildedir:

    • Share permission: Geniş ve sade yapı
    • NTFS permission: Detaylı ve kontrollü yetkilendirme

    Örnek yapı:

    Share Permission
    Domain Users → Change
    

    Bu modelde gerçek erişim kontrolü NTFS tarafında yapılır. Böylece yönetim sadeleşir ve hata riski azalır.

    AGDLP Modeli Nedir?

    AGDLP modeli, Microsoft tabanlı ortamlarda önerilen kurumsal yetkilendirme yaklaşımıdır. Açılımı şu şekildedir:

    • A: Accounts
    • G: Global Groups
    • DL: Domain Local Groups
    • P: Permissions

    Bu modelin mantığı şudur: Kullanıcı doğrudan klasöre yetki almaz. Önce bir global gruba üye olur, bu global grup ilgili domain local gruba bağlanır ve izinler domain local grup üzerinden kaynağa verilir.

    AGDLP Modelinin Çalışma Mantığı

    Kullanıcı → Global Group → Domain Local Group → NTFS Permission
    

    Örnek senaryo:

    Ahmet
    ↓
    GG_Muhasebe
    ↓
    DL_Muhasebe_Modify
    ↓
    NTFS Modify
    

    Bu yapı sayesinde yetkiler kullanıcı bazlı değil, grup bazlı yönetilir. Bu da özellikle büyük yapılarda ciddi kolaylık sağlar.

    NTFS Permission Tasarımında Neden AGDLP Kullanılmalı?

    NTFS permission tasarımı yapılırken AGDLP modelinin tercih edilmesinin temel nedeni yönetilebilirlik ve sürdürülebilirliktir. Kullanıcı sayısı arttıkça doğrudan kullanıcı bazlı izin yapıları hızla karmaşık hale gelir.

    1. Yönetilebilirlik

    Kullanıcı işten ayrıldığında, departman değiştirdiğinde veya yeni biri eklendiğinde sadece grup üyeliği güncellenir. Klasör izinlerine tek tek müdahale edilmez.

    2. Ölçeklenebilirlik

    Büyük organizasyonlarda yüzlerce klasör ve binlerce kullanıcı olabilir. AGDLP modeli bu yapıyı merkezi ve düzenli biçimde yönetmeyi kolaylaştırır.

    3. Güvenlik

    Least privilege yani minimum yetki prensibinin uygulanmasını kolaylaştırır. Böylece kullanıcı yalnızca ihtiyaç duyduğu kaynağa erişir.

    4. Denetlenebilirlik

    Yetki yapısının grup bazlı olması audit, raporlama ve erişim incelemelerinde büyük avantaj sağlar.

    Kurumsal NTFS Permission Tasarım Örneği

    Kurumsal bir file server yapısında örnek klasör mimarisi aşağıdaki gibi olabilir:

    FileServer
     ├─ Finance
     ├─ HR
     ├─ Projects
    

    Her klasör için ihtiyaçlara göre okuma ve değiştirme grupları oluşturulabilir:

    DL_Finance_Read
    DL_Finance_Modify
    DL_HR_Read
    DL_HR_Modify
    DL_Projects_Read
    DL_Projects_Modify
    

    Bu gruplara NTFS izinleri atanır. Kullanıcılar ise doğrudan bu gruplara değil, ilgili global gruplara dahil edilir. Örnek:

    Kullanıcılar → GG_Finance_Users
    GG_Finance_Users → DL_Finance_Modify
    DL_Finance_Modify → Finance klasörü üzerinde Modify yetkisi
    

    Bu tasarım uzun vadede çok daha temiz bir yapı oluşturur.

    NTFS Permission Best Practices

    Kurumsal ortamlarda NTFS yetkilendirme best practice yaklaşımı için aşağıdaki kurallar önerilir:

    • Kullanıcılara doğrudan yetki verilmemeli
    • Yetkiler mümkün olduğunca grup üzerinden atanmalı
    • Full Control yalnızca gerçekten gerekli hesaplara verilmeli
    • Inheritance yapısı dikkatli planlanmalı
    • Paylaşım ve NTFS izinleri karıştırılmamalı
    • Departman bazlı ve rol bazlı grup isimlendirme standardı oluşturulmalı
    • Audit log mekanizması aktif tutulmalı
    • Düzenli yetki kontrolü yapılmalı

    En Sık Yapılan Hatalar

    • Everyone veya Authenticated Users grubuna gereğinden fazla yetki vermek
    • Doğrudan kullanıcı hesabına Modify veya Full Control vermek
    • Aynı klasörde hem karmaşık share hem karmaşık NTFS izinleri kullanmak
    • Departman değişikliklerinde eski grup üyeliklerini temizlememek

    Inheritance Yönetimi Neden Önemlidir?

    NTFS izinlerinde inheritance, üst klasörde tanımlanan izinlerin alt klasörlere otomatik aktarılması anlamına gelir. Bu mekanizma doğru kullanıldığında yönetimi kolaylaştırır; yanlış kullanıldığında ise erişim hatalarına yol açabilir.

    Özellikle hassas veri içeren klasörlerde inheritance durumu dikkatle kontrol edilmelidir. Her alt klasörün ayrı bir güvenlik ihtiyacı varsa, kalıtım yapısı bilinçli şekilde düzenlenmelidir.

    PowerShell ile NTFS Permission Denetleme

    Yetki kontrolü için PowerShell kullanmak oldukça faydalıdır. Aşağıdaki komut, ilgili klasör üzerindeki izinleri görüntüler:

    Get-Acl "D:\Finance"
    

    Bu komut ile klasöre atanmış erişim kuralları incelenebilir. Düzenli denetim yapmak, hatalı veya gereksiz izinlerin erken fark edilmesini sağlar.

    PowerShell içeriklerine ilgi duyuyorsanız, benzer yönetim senaryoları için diğer sistem yönetimi yazılarıma da göz atabilirsiniz.

    Gerçek Hayat Senaryosu

    Bir kurumda kullanıcılar doğrudan klasörlere yetkilendirilmişti. Başlangıçta bu yöntem kolay görünse de kullanıcı sayısı arttıkça izin yapısı kontrol edilemez hale geldi. Kimin hangi klasöre neden yetkili olduğu net biçimde takip edilemedi.

    Daha sonra AGDLP modeline geçildi ve yapı yeniden tasarlandı. Bu geçiş sonrasında:

    • Yetki yönetimi sadeleşti
    • Hatalı erişimler azaldı
    • Departman geçişleri daha hızlı yönetildi
    • Denetim süreçleri kolaylaştı

    Bu örnek, doğru NTFS permission tasarımı yapılmadığında oluşabilecek operasyonel yükü net biçimde göstermektedir.

    Sonuç

    NTFS permission tasarımı, Windows File Server yönetiminin en kritik parçalarından biridir. Güvenli, sürdürülebilir ve yönetilebilir bir yapı kurmak için kullanıcı bazlı değil, grup tabanlı bir yaklaşım benimsenmelidir.

    AGDLP modeli, Active Directory ortamlarında bu ihtiyacı karşılayan en doğru yapılardan biridir. Share ve NTFS izinlerinin doğru ayrıştırılması, grup isimlendirme standardı, inheritance kontrolü ve düzenli denetim süreçleri ile çok daha profesyonel bir permission mimarisi kurulabilir.

    Bu konuda daha geniş bir güvenlik bakışı için File Server güvenliğini güçlendirmek için hazırladığım File Server Hardening makalesi ile bu içeriği birlikte değerlendirmeniz faydalı olacaktır.

    Sık Sorulan Sorular

    NTFS permission doğrudan kullanıcıya verilir mi?

    Kurumsal ortamlarda bu yaklaşım önerilmez. Yetkilerin grup üzerinden verilmesi daha güvenli ve daha yönetilebilir bir model sunar.

    AGDLP modeli neden kullanılır?

    AGDLP modeli, yetkilendirme yapısını standartlaştırmak, erişim yönetimini kolaylaştırmak ve güvenliği artırmak için kullanılır.

    NTFS ve Share permission hangisi daha önemlidir?

    Detaylı erişim kontrolü çoğunlukla NTFS permission üzerinden yapılır. Share permission ise ağ erişim katmanını kontrol eder.

    Full Control yetkisi kimlere verilmelidir?

    Full Control yalnızca gerçekten ihtiyaç duyan yönetici hesaplara veya özel servis senaryolarına verilmelidir. Son kullanıcılar için genellikle gerekli değildir.

  • Windows File Server Güvenliği Rehberi

    Windows File Server Güvenliği Rehberi

    Kurumsal yapılarda Windows File Server güvenliği, veri bütünlüğü ve iş sürekliliği açısından kritik öneme sahiptir. Yanlış yapılandırılmış bir file server; yetkisiz erişim, veri sızıntısı ve ransomware saldırıları için en zayıf halka olabilir.

    Bu rehberde, Windows Server üzerinde çalışan bir file server için uygulanması gereken hardening adımlarını, güvenlik best practice’leri ve gerçek senaryolara dayalı önerileri detaylı şekilde ele alıyoruz.

    1️⃣ File Server Güvenliği Neden Kritik?

    File server’lar genellikle:

    • Finans verileri

    • İnsan kaynakları belgeleri

    • Proje dokümanları

    • Yedek dosyalar

    gibi kritik içerikleri barındırır.

    Bir saldırgan için domain controller’dan sonra en değerli hedeflerden biridir.

    Riskler:

    • Yetki eskalasyonu

    • Yanlış NTFS inheritance

    • SMB exploitleri

    • Fidye yazılımı yayılımı

    2️⃣Windows File Server NTFS Permission Best Practices

    Temel kural:

    Share permission basit, NTFS permission detaylı olmalı.

    Önerilen yapı:

    • Share: Domain Users → Change

    • Asıl yetkilendirme NTFS üzerinden yapılmalı

    Yanlış yapı:

    • Kullanıcılara direkt NTFS Full Control verilmesi

    • “Everyone” kullanımı

    3️⃣ AGDLP Yetkilendirme Modeli

    Kurumsal ortamlarda önerilen model:

    A → G → DL → P

    • A = Accounts

    • G = Global Group

    • DL = Domain Local Group

    • P = Permission

    Örnek yapı:

    Muhasebe_Users → GG_Muhasebe
    GG_Muhasebe → DL_Muhasebe_Read
    DL_Muhasebe_Read → NTFS Read

    Avantajları:

    • Yönetilebilirlik

    • Ölçeklenebilirlik

    • Denetlenebilir yapı

    4️⃣ SMB Güvenlik Ayarları

    SMBv1 Kapatılmalı

    PowerShell ile kontrol:

    Get-WindowsOptionalFeature Online FeatureName SMB1Protocol

    Kapatma:

    Disable-WindowsOptionalFeature Online FeatureName SMB1Protocol

    SMB Signing Aktif Edilmeli

    Group Policy:

    Computer Configuration
    → Windows Settings
    → Security Settings
    → Local Policies
    → Security Options
    • Microsoft network client: Digitally sign communications

    • Microsoft network server: Digitally sign communications

    Microsoft dokümantasyonuna göre SMB güvenliği modern Windows Server ortamlarında kritik bir güvenlik katmanı sağlar.

    Kaynak:
    https://learn.microsoft.com/en-us/windows-server/storage/file-server/file-server-smb-overview

    5️⃣ Access Based Enumeration (ABE)

    ABE aktif değilse kullanıcılar erişemediği klasörleri görebilir.

    Aktif etmek için:

    Set-SmbShare Name “PaylasimAdi” FolderEnumerationMode AccessBased

    Avantaj:

    • Bilgi sızmasını engeller

    • Kullanıcı deneyimini iyileştirir

    6️⃣ Audit Policy ve Log İzleme

    Audit etkin değilse, erişim takibi mümkün değildir.

    Group Policy:

    Advanced Audit Policy Configuration
    → Object Access
    → Audit File System

    Başarılı ve başarısız loglar açılmalı.

    Event Viewer’da takip:

    Security Log
    Event ID 4663

    Kurumsal ortamda öneri:

    • SIEM entegrasyonu

    • Haftalık log kontrolü

    • Kritik klasörlere özel denetim

    Windows File Server üzerinde dosya erişimlerini izlemek için Microsoft tarafından önerilen yöntem Advanced Audit Policy kullanmaktır.

    Kaynak:
    https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/audit-file-system

    7️⃣ Ransomware’e Karşı Koruma Stratejileri

    1. Shadow Copy Aktif Edilmeli

    Volume Shadow Copy Service (VSS) yapılandırılmalı.

    2. Immutable Backup

    Offline veya immutable storage kullanılmalı.

    3. Least Privilege Model

    Kullanıcılar Full Control almamalı.

    4. Network Segmentation

    File server ayrı VLAN’da konumlandırılmalı.

    5. Controlled Folder Access

    Windows Defender ile korunmalı.

    Ransomware saldırıları son yıllarda özellikle dosya sunucularını hedef almaktadır.

    Kaynak:
    https://www.cisa.gov/ransomware

    8️⃣ Ek Hardening Kontrolleri

    • Local admin kaldırılmalı

    • RDP sadece belirli IP’lere açık olmalı

    • Windows Firewall aktif olmalı

    • Gereksiz servisler kapatılmalı

    • Antivirüs exclusion listesi minimal tutulmalı

    • NTFS inheritance kontrol edilmeli

    PowerShell ile inheritance kontrol:

    (Get-Acl “D:\Paylasim”).AreAccessRulesProtected

    9️⃣ Gerçek Hayattan Bir Senaryo

    Bir kurumda NTFS yerine share permission üzerinden yetkilendirme yapılmıştı. Ransomware bulaşan bir kullanıcı hesabı, tüm paylaşıma yazma yetkisi sayesinde 2 TB veriyi şifreledi.

    Sebep:

    • Yetki fazlalığı

    • Audit eksikliği

    • SMB signing kapalı

    Hardening sonrası:

    • AGDLP modeline geçildi

    • ABE aktif edildi

    • Immutable backup devreye alındı

    Windows File Server güvenliği yalnızca antivirüs kurmak değildir. Doğru permission modeli, SMB güvenliği, audit politikaları ve yedekleme stratejileri birlikte uygulanmalıdır.

    Kurumsal ortamlarda hardening yapılmamış bir file server ciddi güvenlik riski oluşturur.

    Windows File Server Güvenliği Sık Sorulan Sorular (FAQ)

    Windows File Server’da en önemli güvenlik adımı nedir?

    Doğru NTFS permission modeli ve least privilege yaklaşımıdır.

    SMBv1 neden kapatılmalıdır?

    Güvenlik açıkları nedeniyle exploit riski taşır.

    Ransomware’e karşı en etkili yöntem nedir?

    Immutable backup ve minimum yetki prensibi.

     

  • Blockchain Mantığı ile PowerShell Log Bütünlüğü

    Blockchain Mantığı ile PowerShell Log Bütünlüğü

    Blockchain Log Bütünlüğü

    Hash zinciri kullanılarak log bütünlüğünün doğrulanması

    Bu yazımızda blockchain log bütünlüğü üzerine incelemelerde bulunacağız. Günümüz kurumsal sistemlerinde en kritik sorulardan biri şudur:

    Bir log kaydı gerçekten değişmeden mi duruyor?

    Merkezi log sistemleri kayıt tutar; ancak bu kayıtların sonradan değiştirilmediğini matematiksel olarak garanti etmek her zaman mümkün değildir. Log dosyaları silinebilir, satırlar düzenlenebilir veya belirli kayıtlar bilinçli olarak çıkarılabilir.

    İşte bu noktada blockchain mantığı ve kriptografi devreye girer.

    Blockchain’in asıl gücü kripto paralarda değil;
    hash zinciri, değiştirilemezlik ve doğrulanabilirlik özelliklerindedir.
    Bu prensipler, kurumsal log güvenliği için son derece güçlü bir temel oluşturur.

    Bu yazıda:

    • Blockchain’in kriptografik temelini,

    • Log bütünlüğüne nasıl uygulanabileceğini,

    • PowerShell ile log doğrulama mekanizmasını

    teknik ama anlaşılır bir şekilde ele alıyoruz.

    Blockchain Mantığı Nedir?

    Blockchain’in özeti oldukça nettir:

    Her kayıt, kendinden önceki kaydın hash değerini içerir.

    Bu yapı sayesinde:

    • Aradaki tek bir kayıt bile değiştirilirse,

    • Hash zinciri bozulur,

    • Manipülasyon anında tespit edilir.

    Bu mantık yalnızca dağıtık sistemler için değil, log sistemleri için de birebir uygundur. Özellikle güvenlik, denetim ve adli bilişim senaryolarında büyük avantaj sağlar.

    Hash Fonksiyonları ile Log Bütünlüğü

    Hash fonksiyonlarının temel özellikleri şunlardır:

    • Tek yönlüdür (geri döndürülemez)

    • Aynı girdi → aynı çıktı üretir

    • En ufak değişiklik → tamamen farklı hash oluşturur

    Örnek:

    Admin user logged in at 10:30
    SHA-256 → 3F1A9C8D4E...

    Bu log satırında tek bir karakter bile değişirse, üretilen hash değeri artık eşleşmez.
    İşte bu özellik, logların değiştirilemediğini ispatlamanın temelidir.

    Logları Blockchain Mantığıyla Zincirlemek

    Blockchain mantığını loglara uygulamak için her kayıtla birlikte şu bilgiler tutulur:

    • Log içeriği

    • Önceki log kaydının hash değeri

    • Zaman damgası

    Bu yapı sayesinde:

    • Loglar birbirine kriptografik olarak zincirlenir

    • Silme, ekleme veya değiştirme girişimleri fark edilir

    • Adli bilişim açısından inkâr edilemez delil oluşur

    PowerShell ile Log Hash Zinciri Oluşturma

    Log Üretimi (Hash Zinciri)

    Aşağıdaki PowerShell kodu, her log kaydını bir öncekinin hash’i ile zincirler:

    $previousHash = Get-Content ".\LastHash.txt"
    $logEntry = "Service restarted by SYSTEM at $(Get-Date)"
    
    $data = $previousHash + $logEntry
    $bytes = [System.Text.Encoding]::UTF8.GetBytes($data)
    $hash = [System.Security.Cryptography.SHA256]::Create().ComputeHash($bytes)
    $hashString = [BitConverter]::ToString($hash) -replace "-"
    
    "$logEntry | $hashString" | Add-Content ".\SecureLog.txt"
    $hashString | Set-Content ".\LastHash.txt"

    Bu yapı ile:

    • Her log kaydı zincirin bir parçası olur

    • Önceki kayda bağımlı hale gelir

    • Geriye dönük manipülasyon zorlaşır

    Log Bütünlüğü Doğrulama Script’i

    Gerçek güvenlik, log üretmekle değil doğrulamakla başlar.

    Aşağıdaki script:

    • Log dosyasını baştan sona kontrol eder

    • Hash zinciri kırılan ilk noktayı tespit eder

    • Manipülasyonun tam yerini gösterir

    PowerShell Log Doğrulama

    $lines = Get-Content ".\SecureLog.txt" $previousHash = "INITIAL"
     foreach ($line in $lines) { $parts = $line.Split("|") $logData = $parts[0].Trim() 
    $storedHash = $parts[1].Trim() 
    $data = $previousHash + $logData $bytes = [System.Text.Encoding]::UTF8.GetBytes($data)
     $computedHash = [BitConverter]::ToString( [System.Security.Cryptography.SHA256]::Create().ComputeHash($bytes) ) -replace "-"
     if ($computedHash -ne $storedHash) { Write-Host "❌ Log bütünlüğü BOZULDU!"
     -ForegroundColor Red Write-Host "Sorunlu kayıt: $logData" break } $previousHash = $storedHash } Write-Host "✅ Log zinciri sağlam." -ForegroundColor Green

    Bu doğrulama sayesinde:

    • Hangi logun oynandığı

    • Zincirin ne zaman kırıldığı

    • Kesin olarak ortaya çıkar

    Gerçek Hayat Senaryosu (Vaka Analizi)

    Bir sunucuda gece saatlerinde kritik bir servis restart edilir.

    • Event log mevcuttur

    • Ancak “log silinmiş olabilir mi?” sorusu gündeme gelir

    • Birden fazla admin erişimi vardır

    Hash zinciri kontrol edildiğinde:

    • Saat 02:14 kaydında zincirin bozulduğu görülür

    • Öncesi ve sonrası hash değerleri uyuşmaz

    • Müdahalenin zamanı netleşir

    Sonuç:

    • Log kaydı değiştirilmiştir

    • Zincir kırıldığı için inkâr edilemez

    • Adli bilişim açısından güçlü bir delil elde edilir

    Bu yaklaşım, “kim, ne zaman, ne yaptı?” sorusuna matematiksel cevap verir.

    Bu Yapı Blockchain midir?

    Teknik olarak:

    • Dağıtık yapı ❌

    • Mining ❌

    • Token ❌

    Ancak:

    • Kriptografik zincir ✔

    • Değiştirilemezlik ✔

    • Doğrulanabilirlik ✔

    Yani bu yapı, blockchain mantığının kurumsal sistemlere uyarlanmış halidir.

    Blockchain’i sadece kripto para teknolojisi olarak görmek büyük bir yanılgıdır.

    Asıl değer:

    • Kriptografide,

    • Hash zincirinde,

    • Veri bütünlüğündedir.

    Bir sistem yöneticisi için bu yaklaşım:

    Loglara güvenmenin matematiksel yoludur.

    Bu yazıda blockchain log bütünlüğü ile ilgili bilgiler verdik. Umarım faydalı olur.