Cloud IAM Loglarından Yetki Analizi: Bulut Ortamlarında Kim, Ne Zaman, Ne Yetkiyle?

Bulut altyapılarında (IaaS / PaaS / SaaS) güvenliğin kalbi IAM (Identity and Access Management) sistemleridir. IAM logları; kimlik doğrulama, yetki atama, rol kullanımı ve policy değişiklikleri gibi kritik olayları kaydeder. Adli bilişim açısından bu loglar, yetki suistimali, iç tehdit, yanlış konfigürasyon ve hesap ele geçirme vakalarında en güçlü delil kaynaklarından biridir.

Cloud IAM Nedir? (Adli Perspektif)

Cloud IAM; kullanıcılar, servis hesapları, roller ve politikalar üzerinden erişim kontrolünü yönetir.

Temel Bileşenler

Kimlikler: Kullanıcı, servis hesabı, role session
Yetkiler: Policy, permission, scope
Erişim Yöntemi: Console, API, CLI, SDK
Oturum Türleri: Kalıcı, geçici (assume role / token)

IAM Logları Neden Kritik?
1. Yetki Suistimalini Ortaya Çıkarır

- Kim admin yetkisi aldı?
- Ne zaman aldı?
- Gerçekten kullanıldı mı?

2. Hesap Ele Geçirme ve Lateral Movement

- Normal kullanıcı → yüksek yetkili rol
- Servis hesabı üzerinden gizli erişim
- Cross-account / cross-project geçişler

3. Zaman Çizelgesi Rekonstrüksiyonu

- Policy değişikliği
- Rol varsayımı
- API çağrıları

IAM Loglarında Nerelerde İz Var?
Başlıca Log Türleri

Auth logları: Login, MFA, başarısız denemeler
Audit logları: Policy create/update/delete
Access logları: API çağrıları (who/what/when)
Role session logları: Assume role / token issuance

Yetki Analizi: Nelere Bakılmalı?
Kimlik Türü

- İnsan kullanıcı mı?
- Servis hesabı mı?
- Geçici rol mü?

Yetki Kapsamı (Scope / Permission)

- Geniş (:) yetkiler
- Admin / Owner rolleri
- Hassas servisler (IAM, KMS, Storage, Compute)

Erişim Yöntemi

- Console (interactive)
- API / CLI (automation)
- SDK (application)

Teknik Örnekler (Analiz Yaklaşımı)
Yetki Değişikliği Olaylarını Filtreleme

1# Mantıksal örnek
2filter logs where eventType in (CreatePolicy, AttachPolicy, UpdateRole)

Bu filtre:

- Yeni yetki eklemelerini
- Rol genişletmelerini
- Riskli değişiklikleri

öne çıkarır.

Role Assume (Geçici Yetki) Analizi

1# Mantıksal korelasyon
2correlate(assume_role_events, api_calls)

Amaç:

- Rol ne zaman alındı?
- Hangi API’ler çağrıldı?
- Rol süresi dolmadan neler yapıldı?

Yetki–Davranış Uyumu Kontrolü

1# Mantıksal kontrol
2compare(granted_permissions, used_permissions)

Verilen yetki ≫ kullanılan yetki
→ Aşırı yetkilendirme (misconfiguration)

Yaygın Yetki Suistimali Senaryoları
1. Aşırı Yetkili Servis Hesabı

- CI/CD pipeline’a admin rolü
- Log’larda otomasyon görünümlü saldırı

2. Geçici Yetki ile Kalıcı Etki

- Kısa süreli role assume
- Kalıcı backdoor (yeni kullanıcı/policy)

3. Policy Drift (Yetki Sürüklenmesi)

- Zamanla eklenen küçük izinler
- Fark edilmeden admin seviyesine çıkış

Adli Senaryo Örneği

Olay:
Bulut ortamında yetkisiz veri silme.

Analiz:

- IAM logları: gece 02:18’de role assume
- Rol: “BackupOperator”
- Ardından storage delete API çağrıları
- Role policy’si 1 saat önce güncellenmiş

Sonuç:

- Yanlış policy güncellemesi
- Geçici rol ile kritik işlem
- Kasıt değil, konfigürasyon hatası

Anti-Forensics ve Zorluklar
Yaygın Taktikler

- Kısa TTL’li token
- Hızlı policy geri alma
- Servis hesabı arkasına saklanma

Adli Analistler İçin Pratik İpuçları
“Kim” ile “Ne”yi Ayır

- Kimlik ≠ işlem

Yetki Değişikliklerini Kilit Nokta Yap

- Öncesi / sonrası fark analizi

Servis Hesaplarını Önceliklendir

- İnsan hatası → görünür
- Servis hesabı hatası → sessiz

Zaman Dilimini Dikkate Al

- Bulut saatleri + kullanıcı lokali

Hukuki ve Adli Değer

Mahkemelerde:

- Yetki atama zamanı
- Yetki kullanımı
- Kimlik–işlem korelasyonu

çok güçlü delil oluşturur.

#AdliBilişim #kaynak