AWS IAM Kimlik Bilgileri Nasıl Güvenli Yönetilir?

Giriş

AWS'de her API çağrısı kimlik doğrulamadan geçer. 2025 Verizon Veri İhlali Raporu, temel web uygulama saldırılarının %88'inin çalınan kimlik bilgileriyle başladığını söylüyor Verizon DBIR. Ortamda dolaşan access key'ler, root şifreleri ve rol token'ları üzerinde yeterince durulmadığında, saldırganın işi fazlasıyla kolaylaşıyor.

Bu yazı IAM kimlik bilgisi türlerini, hangi senaryoda hangisinin kullanılması gerektiğini ve bunları saldırı yüzeyinden nasıl uzak tutacağınızı ele alıyor.

Root kullanıcısı hesabın sahibi: Peki ne kadar kullanılmalı?

AWS hesabı oluşturulurken belirlenen e-posta ve parola, sınırsız yetkiye sahip root kullanıcısını tanımlar. Bu hesap, Organizations tarafından uygulanan Servis Kontrol Politikaları (SCP) dışında hiçbir kısıtlamaya tabi değildir. Fatura bilgileri, hesap kapatma, AWS Destek planı değişikliği gibi işlemleri yalnızca root yürütebilir.

AWS, 2024 ortasından itibaren standalone hesaplarda root kullanıcısı için MFA'yı kademeli olarak zorunlu kılmaya başladı AWS Security Blog. Organizations ile açılan yeni hesaplarda root şifresi rastgele üretilir ve hiçbir yerde saklanmaz. Peki ya 2017 öncesi açılan eski hesaplar? Onlarda root parolası, Amazon.com alışveriş şifresiyle aynı olabilir. Bu risk bugün hâlâ canlı.

Güvenlik çerçevesinden bakıldığında root, bir "break glass" hesabıdır. Günlük operasyonlarda kullanılması, yetki sınırlaması olmayan bir hesabı sürekli aktif tutmak anlamına gelir.

Aralık 2024'te AWS, root kullanıcıları için MFA'yı zorunlu hale getirme takvimini duyurdu; bu, uzun süredir beklenen bir adımdı AWS Security Blog. Buna göre standalone hesaplarda root MFA'sı kademeli olarak dayatılacak. Yine de bu takvimi beklemek yerine hemen şimdi harekete geçmek, savunmayı saldırgandan bir adım önde tutar.

Root için minimum güvenlik adımları:

• Root e-postasını yalnızca güvenilir kişilerin erişebildiği izole bir posta kutusuna tanımlayın.
• Donanım tabanlı MFA ekleyin. FIDO2 security key, TOTP'ye kıyasla phishing saldırılarına karşı daha dirençlidir.
• Root için hiçbir koşulda access key oluşturmayın.
• CloudTrail'de ConsoleLogin olaylarını root kullanıcısı için izleyin ve anlık SNS alarmı kurun.

IAM login profile: Herkesin konsola ihtiyacı yok

Verizon DBIR 2025'e göre kimlik bilgisi hırsızlığı, veri ihlallerinin en yaygın giriş vektörü olmaya devam ediyor Verizon DBIR. IAM kullanıcıları için oluşturulan login profile, AWS Management Console'a parolayla erişimi sağlar. Ancak yalnızca API veya CLI kullanacak servis hesaplarına konsol erişimi vermek, saldırı yüzeyini boşuna genişletir. AWS, hesap düzeyinde bir parola politikasını zorunlu kılmaz; bu yapılandırmayı sizin elinizle yapmanız gerekir.

Bir IAM parola politikasında bulunması gerekenler:

• Minimum 14 karakter
• Büyük harf, küçük harf, rakam ve özel karakter zorunluluğu
• Maksimum 90 gün parola ömrü
• Son 24 parolanın tekrar kullanılamaması

Konsol erişimi olan her hesap bir kimlik avı hedefidir. Microsoft'un 2019 araştırması, MFA'nın hesap ele geçirme saldırılarının %99.9'unu engellediğini gösteriyor Microsoft Security Blog. Peki MFA olmadan güçlü bir parola politikası tek başına yeterli mi? Kısa cevap: Hayır. Ele geçirilmiş bir parola, MFA yoksa saldırgana tüm yetkileri açar.

Access Key'ler: Uzun vadeli ve geçici anahtarlar

AWS API'lerine programatik erişim iki tür anahtarla mümkündür. GitHub, 2024'te platform genelinde 39 milyondan fazla gizli anahtar tespit etti; AWS access key'leri en sık sızan bulut kimlik bilgileri arasında GitHub Blog. Peki bu anahtarlar nereye sızıyor? Büyük çoğunluğu .env dosyalarına, CI/CD değişkenlerine ya da doğrudan kaynak koda gömülmüş halde bulunuyor.

Uzun Vadeli Anahtarlar (AKIA)

Access Key ID'leri AKIA ile başlar, süresiz geçerlidir ve kullanıcı başına en fazla iki anahtar oluşturulabilir. Açığa çıkan bir AKIA anahtarı, otomatik tarayıcılar tarafından dakikalar içinde tespit edilip kripto mining'den veri sızdırmaya kadar çeşitli amaçlarla kullanılır.

Geçici anahtar kullanımının mümkün olduğu hiçbir senaryoda uzun vadeli anahtar kullanılmamalıdır. Kullanmak zorunda kalındığında 90 günde bir rotasyon şarttır. Rotasyon sırasında eski anahtarı hemen Inactive duruma getirip bir hafta boyunca hata log'larını izledikten sonra silmek, en risksiz yöntemdir.

Geçici Oturum Anahtarları (ASIA)

STS tarafından üretilir, ASIA ile başlar ve 15 dakika ile 12 saat arasında bir ömre sahiptir. Access Key ve Secret Key'e ek olarak bir Session Token taşırlar. Çalınsalar bile kısa sürede geçersiz hale gelmeleri en büyük avantajlarıdır. 15 dakikalık bir pencerede ciddi hasar verebilmek, önceden konumlanmış altyapı olmadan neredeyse imkansızdır.

MFA: İsteğe bağlı değil, zorunlu

Microsoft'un araştırmasına göre MFA, hesap ele geçirme saldırılarının %99.9'unu engelliyor Microsoft Security Blog. AWS üç MFA yöntemini destekler: sanal TOTP uygulamaları, donanım tabanlı TOTP token'lar ve FIDO2/U2F security key'ler. Haziran 2024'te AWS, FIDO2 passkey desteğini IAM için kullanıma sundu AWS Security Blog. Passkey'ler, cihazınızdaki parmak izi veya yüz tanıma gibi biyometrik doğrulamayı MFA faktörü olarak kullanır.

Güvenlik açısından FIDO2, phishing saldırılarına karşı TOTP'den daha dirençlidir. TOTP kodları iyi kurgulanmış bir ortadaki adam saldırısıyla çalınabilir. FIDO2 ise origin doğrulaması yaparak yalnızca gerçek AWS konsoluna yanıt verir. Peki neden hâlâ TOTP kullanılıyor? Çünkü donanım token maliyeti ve dağıtım lojistiği, büyük ekiplerde FIDO2'ye geçişi yavaşlatıyor. Yine de root hesabı için donanım MFA pazarlıksız bir gereklilik.

IAM politikalarıyla MFA'yı zorunlu kılmak için aws:MultiFactorAuthPresent koşulu kullanılır.

Servisler kimlik bilgilerini nasıl alır? IMDSv1'den IMDSv2'ye geçiş

EC2, Lambda, ECS gibi servisler IAM Role + AssumeRole ile çalışır. Servis rolü üstlenir, AWS Trust Policy'yi kontrol eder ve geçici kimlik bilgisi döner. Akışın kendisi güvenli. Asıl sorun, bu bilgilerin servise nasıl iletildiğinde başlıyor.

Capital One İhlali ve IMDS'nin Tehlikeli Yüzü

EC2 sunucuları, rol kimlik bilgilerini 169.254.169.254 IP'sindeki Instance Metadata Service'ten alır. IMDSv1, bu bilgiyi herhangi bir oturum token'ı olmadan düz HTTP GET ile sunar. 2019'da Capital One ihlalinde saldırgan, yanlış yapılandırılmış bir WAF'ı atlatarak SSRF zafiyeti üzerinden IMDSv1'e ulaştı ve 100 milyondan fazla müşteri kaydına erişti KrebsOnSecurity. Capital One, bu ihlal sonucunda 190 milyon dolarlık uzlaşma bedeli ödedi.

IMDSv2 bu açığı kapatır. Metadata'ya erişmek için önce PUT isteğiyle süre sınırlı bir oturum token'ı almak gerekir. SSRF zafiyetlerinin büyük çoğunluğu yalnızca GET isteği gönderebildiği için IMDSv2, bu saldırı sınıfını etkisiz kılar.

Mart 2024'te AWS, hesap düzeyinde tüm yeni EC2 örneklerinde IMDSv2'yi varsayılan olarak ayarlama özelliğini kullanıma sundu AWS What's New. Mevcut örnekler için MetadataOptions.HttpTokens parametresini required olarak güncellemek, Capital One benzeri bir ihlalin maliyetini ortadan kaldırır.

İzleme ve Sürekli Denetim

Kimlik bilgisi güvenliği "kur ve unut" işi değildir. Peki düzenli denetim yapılmadığında ne oluyor? 2025 Verizon DBIR, ihlallerin %68'inde insan faktörünün bulunduğunu söylüyor Verizon DBIR. Unutulan access key'ler, rotasyonu atlanan anahtarlar ve MFA'sız hesaplar bu istatistiğin içinde.

Aylık olarak çalıştırılması gereken kontroller:

• Credential Report: Kullanılmayan ve rotasyon süresi geçmiş access key'leri tespit eder.
• IMDS Durumu: ec2 describe-instances ile MetadataOptions.HttpTokens değerini kontrol edin.
• MFA Eksiklikleri: IAM credential report, MFA aktif olmayan kullanıcıları listeler.
• CloudTrail: GetCallerIdentity, CreateAccessKey, AssumeRole gibi hassas çağrıları izleyin.

AWS Config'in iam-user-mfa-enabled, access-keys-rotated ve ec2-imdsv2-check kuralları bu kontrolleri otomatize eder. AWS Security Hub, bu kuralların sonuçlarını merkezi bir dashboard'da toplar AWS Security Hub.

Harekete geçme zamanı

Buraya kadar okuduğunuz her şey, uygulamaya dökülmediğinde yalnızca teoriden ibaret. AWS ortamınızın güvenliğini bugün sıkılaştırmak için atabileceğiniz üç hızlı adım:

1. Credential report çekin. 90 gündür kullanılmayan her access key'i devre dışı bırakın.
2. IMDSv2'yi zorunlu kılın. Mevcut EC2 örneklerinde HttpTokens değerini required yapın.
3. MFA durumunu denetleyin. Root başta olmak üzere tüm insan kullanıcılar için MFA'yı zorunlu kılın.

Bu üç adım, önümüzdeki bir saat içinde tamamlanabilir. Capital One'ın 190 milyon dolarlık dersini tekrar etmeye gerek yok.

Sıkça Sorulan Sorular (FAQ)

Sonuç

AWS kimlik bilgisi yönetimi, üzerinde en az konuşulan ama ihlal anında en ağır faturayı çıkaran güvenlik katmanıdır. Özetle:

• Root hesabı MFA ile kilitleyin ve günlük işlerden uzak tutun.
• Uzun vadeli access key'leri azaltın, rotasyonu otomatikleştirin.
• IMDSv2'yi zorunlu kılın; Capital One benzeri bir SSRF açığının maliyeti hesaplanamaz.
• MFA'yı tüm insan kullanıcılar için zorunlu tutun.
• Aylık denetimleri AWS Config ve Security Hub ile otomatize edin.

Bulut ortamında dolaşan her access key, her rol token'ı ve her metadata çağrısı, savunulması gereken bir yüzeydir. Görünmez olanı görünür kılmak, güvenliğin ilk adımıdır.