PowerShell Auditing: GPO ile Script Block Logging ve Transcription

PowerShell yalnızca otomasyon aracı değildir; doğru yapılandırıldığında yönetici ve script aktivitelerinin izlenmesinde önemli bir kayıt kaynağıdır. Kurumsal Windows ortamlarında Transcription, Script Block Logging ve Module Logging birlikte değerlendirilerek hem operasyonel troubleshooting hem de güvenlik incelemeleri için daha anlamlı kayıtlar üretilebilir.

Amaç ve Kapsam

Bu rehberde Windows PowerShell 5.1 ağırlıklı kurumsal Windows ortamlarında PowerShell auditing yapılandırmasını ele alıyoruz. Amaç yalnızca TXT dosyası oluşturmak değil; hangi kayıt mekanizmasının neyi topladığını, GPO ile nasıl merkezi uygulanacağını, Event Viewer üzerinden nasıl doğrulanacağını ve logların nasıl korunacağını açıklamaktır.

Ön Koşullar

• Windows PowerShell 5.1 veya desteklenen PowerShell sürümü.
• Domain ortamında ilgili bilgisayarlara GPO uygulayabilecek yetki.
• Merkezi transcript klasörü kullanılacaksa kontrollü SMB paylaşımı ve uygun NTFS/share izinleri.
• Logların saklama süresi, erişim modeli ve SIEM/merkezi log toplama yaklaşımının önceden belirlenmesi.

PowerShell Auditing Bileşenleri

1. PowerShell Transcription

Transcription, PowerShell oturumundaki giriş ve konsol çıktısını metin tabanlı transcript dosyalarına kaydeder. Kullanıcının çalıştırdığı komutları ve ekranda oluşan çıktıyı operasyonel olarak incelemek için kullanışlıdır.

2. Script Block Logging

Script Block Logging; komutların, script block’ların, fonksiyonların ve scriptlerin PowerShell tarafından işlenmesini kaydeder. Windows PowerShell 5.1’de kayıtlar Microsoft-Windows-PowerShell/Operational kanalında tutulur ve özellikle Event ID 4104 güvenlik incelemelerinde önemlidir.

3. Module Logging

Module Logging, belirlenen PowerShell modüllerinin pipeline execution ayrıntılarını kaydetmek için kullanılır. Tüm modülleri izlemek mümkün olsa da yüksek hacimli ortamlarda gereksiz log üretimini önlemek için kapsamın ihtiyaca göre belirlenmesi daha sağlıklıdır.

GPO ile PowerShell Transcription Etkinleştirme

Windows PowerShell 5.1 için Group Policy Management Editor üzerinde aşağıdaki yolu kullanabilirsiniz:

Computer Configuration
  → Administrative Templates
    → Windows Components
      → Windows PowerShell
        → Turn on PowerShell Transcription

Policy’yi Enabled yaptıktan sonra ihtiyaç halinde Include invocation headers seçeneğini etkinleştirebilir ve bir Output Directory belirleyebilirsiniz.

Örnek yerel hedef:

C:\PSLogs

Kurumsal ortamda yerel klasör yerine erişimi sınırlandırılmış merkezi bir paylaşım tercih edilebilir. Ancak transcript dosyaları hassas komut ve çıktı içerebileceğinden, paylaşım izinleri sıradan dosya paylaşımı gibi tasarlanmamalıdır.

Script Block Logging Etkinleştirme

Aynı GPO ağacında:

Computer Configuration
  → Administrative Templates
    → Windows Components
      → Windows PowerShell
        → Turn on PowerShell Script Block Logging

Policy etkinleştirildikten sonra yeni PowerShell oturumlarında işlenen script block’lar Operational log’a yazılır.

Windows PowerShell 5.1 kayıtlarını görüntülemek için:

Event Viewer
  → Applications and Services Logs
    → Microsoft
      → Windows
        → PowerShell
          → Operational

Event ID 4104 kayıtlarını PowerShell ile sorgulamak için:

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-PowerShell/Operational'
    Id      = 4104
} -MaxEvents 20

Module Logging Etkinleştirme

GPO üzerinde Turn on Module Logging policy’sini etkinleştirerek izlenecek modülleri tanımlayabilirsiniz. Test ortamında tüm modülleri görmek için * kullanılabilir; üretimde ise log hacmi ve izleme ihtiyacı birlikte değerlendirilmelidir.

Bir oturum içinde belirli bir modülün pipeline logging özelliğini kontrol etmek için:

Import-Module ActiveDirectory
(Get-Module ActiveDirectory).LogPipelineExecutionDetails = $true

GPO Uygulamasını Doğrulama

İstemci veya sunucu üzerinde policy’nin geldiğini doğrulamak için:

gpupdate /force
gpresult /h C:\Temp\PowerShell-GPO.html

Ardından yeni bir PowerShell oturumu açın, birkaç test komutu çalıştırın ve hem transcript hedefini hem de Operational log’u kontrol edin.

Transcript Dosyalarını Kontrol Etme

Yerel test hedefi C:\PSLogs ise:

Get-ChildItem -Path 'C:\PSLogs' -File -Recurse |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 10 FullName, LastWriteTime, Length

Bir transcript’in içeriğini incelemek için dosya yolunu doğruladıktan sonra Get-Content kullanabilirsiniz.

PowerShell 7 Kullanıyorsanız

PowerShell 7 ile Windows PowerShell 5.1’in logging yollarını birebir aynı kabul etmeyin. PowerShell 7 kendi PowerShell Core Group Policy ayarlarını ve yapılandırma seçeneklerini destekler. Windows üzerinde PowerShell Core event provider kayıtları PowerShellCore/Operational kanalında görülebilir. Aynı bilgisayarda 5.1 ve 7 birlikte kullanılıyorsa iki ortamın logging yapılandırmasını ayrı ayrı doğrulamak gerekir.

Güvenlik Açısından Kritik Nokta: Loglar da Hassas Veridir

Script Block Logging ve transcription kapsamı genişledikçe logların parola, token, connection string veya başka hassas değerler içerme ihtimali artar. Bu nedenle “daha fazla log her zaman daha güvenlidir” yaklaşımı doğru değildir.

• Transcript klasörüne normal kullanıcıların değiştirme/silme yetkisini sınırlandırın.
• Merkezi log hedefini ayrı erişim politikalarıyla koruyun.
• Scriptlerde düz metin parola ve secret kullanımından kaçının.
• Event log kapasitesini ve retention politikasını izleyin.
• Gerekli ortamlarda Protected Event Logging yaklaşımını değerlendirin.

Yaygın Hatalar ve Troubleshooting

Transcript dosyası oluşmuyor

Önce gpresult ile GPO’nun gerçekten uygulandığını doğrulayın. Output Directory bir ağ paylaşımıysa istemci bilgisayarın ve ilgili güvenlik bağlamının hedefe yazabildiğini kontrol edin.

Event ID 4104 görünmüyor

Script Block Logging policy’sinin etkin olduğunu doğrulayın ve policy uygulandıktan sonra yeni bir PowerShell oturumu başlatın. Windows PowerShell 5.1 ile PowerShell 7 log kanallarını karıştırmadığınızdan emin olun.

Log hacmi çok büyüyor

Script Block Invocation Logging ve geniş kapsamlı Module Logging ciddi miktarda kayıt üretebilir. İhtiyaç olmayan ayrıntılı seçenekleri varsayılan olarak tüm altyapıya yaymak yerine önce pilot OU üzerinde log hacmini ölçün.

Loglarda hassas bilgiler görülüyor

Öncelikle scriptlerin secret yönetimini düzeltin. Log erişimini kısıtlayın ve güvenlik gereksiniminiz uygunsa Protected Event Logging kullanın. Auditing sistemi yeni bir bilgi sızıntısı kaynağına dönüşmemelidir.

Kurumsal Uygulama Önerisi

PowerShell auditing’i tek bir policy olarak değil, katmanlı bir kayıt stratejisi olarak tasarlayın. Transcription kullanıcı oturumunun okunabilir kaydını sağlarken Script Block Logging güvenlik analizi için daha ayrıntılı içerik sunar; Module Logging ise seçilen modüllerin pipeline faaliyetlerini tamamlayıcı olarak izler.

Önce test OU’sunda etkinleştirip log hacmini ve uygulama davranışını gözlemlemek, ardından sunucu ve yönetici workstation’larına kontrollü biçimde yaymak daha güvenli bir yöntemdir. Yüksek değerli sistemlerin loglarını merkezi SIEM veya log toplama altyapısına aktarmak ayrıca değerlendirilmelidir.

Sonuç

PowerShell auditing için yalnızca transcript dosyası oluşturmak yeterli değildir. GPO ile Transcription, Script Block Logging ve gerektiğinde Module Logging birlikte tasarlandığında hem troubleshooting hem de olay inceleme kabiliyeti belirgin şekilde güçlenir.

En önemli nokta, üretilen logların kendisinin de hassas veri olduğunun unutulmamasıdır. Doğru erişim modeli, saklama politikası ve merkezi toplama yaklaşımı olmadan logging kapsamını artırmak yeni riskler oluşturabilir.

İlgili Rehberler

• PowerShell Komutları – Profesyonel Rehber
• PowerShell Script Nedir ve Nasıl Yazılır?
• PowerShell Event Log Analizi
• PowerShell Secret Management
• Windows Server Health Check ve Otomatik Raporlama