Zero Trust Mimarisinde Adli Bilişim Zorlukları: Güvenin Olmadığı Yerde Delil Toplamak

Zero Trust yaklaşımı “asla güvenme, her zaman doğrula” prensibiyle tasarlanır. Kimlik, cihaz, uygulama ve ağ her erişimde yeniden doğrulanır. Güvenlik açısından güçlü olan bu model, adli bilişimde yeni ve karmaşık zorluklar doğurur: dağınık loglar, mikro-segmentasyon, kısa ömürlü oturumlar ve şifreli trafik. Bu makalede Zero Trust ortamlarında nerelerde zorlanıldığını, hangi delillerin kritik olduğunu ve nasıl toparlanabileceğini ele alıyoruz.

Zero Trust Nedir? (Adli Perspektif)

Zero Trust; ağ sınırına güvenmez, kimlik ve bağlam merkezlidir.

- Sürekli doğrulama (continuous verification)
- En az ayrıcalık (least privilege)
- Mikro-segmentasyon
- Güçlü şifreleme

Adli Bilişim Açısından Neden Zor?
1. Mikro-Segmentasyon ve Parçalı İzler

- Trafik küçük parçalara bölünür
- Doğu–batı (east–west) trafik yoğun
- Tek bir “merkezi log” yok

2. Kısa Ömürlü Kimlikler ve Oturumlar

- Token’lar dakikalar içinde yenilenir
- Cihaz durumu (posture) anlık değişir
- Oturum süreleri kısadır

Bu durum zaman çizelgesi kurmayı zorlaştırır.

3. Uçtan Uca Şifreleme

- TLS her yerde
- Paket içeriği görünmez
- DPI (deep packet inspection) sınırlı

Zero Trust Mimaride Nerelerde Delil Var?
Kritik Delil Katmanları

- Kimlik & IAM logları (auth, token, MFA)
- Cihaz durumu (EDR/MDM posture)
- Policy decision logları (allow/deny)
- Uygulama erişim logları
- Ağ meta-verisi (flow, timing, SNI)
- Audit trail (policy değişiklikleri)

Tipik Adli Zorluklar (Örneklerle)
🔻 Dağınık Log Ekosistemi

- Kimlik sağlayıcı ayrı
- Uygulama ayrı
- Ağ ayrı
- Cihaz ayrı

→ Korelasyon şart.

🔻 Yanıltıcı “Başarısızlık” Desenleri

- MFA reddi ≠ saldırı
- Cihaz posture fail ≠ kötü niyet
- Policy deny ≠ erişim denemesi

🔻 Zaman ve Bağlam Kayması

- Token issuance zamanı ≠ erişim zamanı
- Policy update anı ≠ etkili olduğu an

Adli Analize Nereden Başlanmalı?
1. Kimlik Olaylarını Merkez Al

- Auth success/failure
- Token issuance/refresh
- MFA challenge’ları

1# Mantıksal yaklaşım
2correlate(auth_logs, token_logs, mfa_logs)

2. Policy Kararlarını İncele

- Hangi kural izin verdi?
- Hangi bağlamla?
- Kural ne zaman değişti?

1# Mantıksal
2analyze(policy_decisions, policy_changes)

3. Cihaz Posture ve EDR İzlerini Ekle

- Cihaz uyumlu muydu?
- EDR alarmı var mıydı?
- Jailbreak/root tespiti?

Adli Senaryo Örneği

Olay:
Yetkisiz veri erişimi şüphesi.

Analiz:

IAM: Başarılı auth + MFA
Policy: “Compliant device + trusted app” kuralı
Cihaz: EDR’da anomali yok
Ağ: Kısa süreli yüksek veri çıkışı

Korelasyon:

- Policy kuralı 12 dk önce gevşetilmiş
- Token bu pencerede alınmış

Sonuç:

Yanlış policy değişikliği ile erişim
Kötü niyet değil, konfigürasyon hatası

Anti-Forensics ve Zero Trust
Yaygın Taktikler

- Token theft (kısa pencerede kullanım)
- Policy değişikliğini geçici yapma
- Log gürültüsü (auth flood)

Adli Analistler İçin Pratik İpuçları
Kimlik Zaman Çizelgesi Oluştur

- Auth → Token → Access → Logout

Policy Değişikliklerini Kilit Nokta Yap

- Öncesi/sonrası farkı çıkar

Meta-Veriyi Hafife Alma

- SNI, timing, byte count altın değerindedir

Tek Kaynağa Güvenme

- IAM + policy + cihaz + ağ birlikte

Hukuki ve Adli Değer

Mahkemelerde:

- Policy decision kayıtları
- IAM audit trail

Değişiklik zamanları özellikle güçlüdür.

#AdliBilişim #kaynak