Giriş
AWS'de güvenlik duvarı yoktur. Her işlem bir API çağrısıdır. EC2 başlatma, S3 okuma, güvenlik grubu değişikliği hepsi imza ister. IAM bu imzayı kontrol eder.
2026'da veri ihlallerinin %45'i bulutta gerçekleşti. Ortalama maliyet 5,17 milyon dolar oldu (SentinelOne, 2026). Aynı yıl kimliği ele geçirilmiş hesaplar bulut ihlallerinin %70'inden fazlasını tetikledi. Kuruluşların %77'si kimlik ve erişimi öncelikli bulut riski saydı.
Bu tablo IAM'i ilk savunma hattı yapar. Yazıda IAM'in ne olduğunu, dört parçasını, root riskini, kullanıcı-rol farkını, policy mantığını, ARN yapısını ve Organizations ile hesap izolasyonunu adım göreceksin. Her bölümde 2025-2026 verileri var. Pratik kontrollerle ilerleyeceğiz.
- Bulut ihlallerinin %45'i 2026'da bulutta yaşandı, ortalama maliyet 5,17 milyon $ (SentinelOne, 2026).
- Kimliği ele geçirilmiş hesaplar bulut ihlallerinin %70'inden fazlasını tetikliyor.
- IAM'de varsayılan kural Implicit Deny'dir. Açık izin yoksa erişim yoktur.
AWS IAM tam olarak neyi kontrol eder?
AWS IAM, kimin hangi API eylemini hangi kaynakta yapabileceğini belirler. 2026'da kuruluşların %77'si kimlik ve erişim güvenliğini öncelikli bulut riski saydı (SentinelOne, 2026). Bu oran ağ çevresinden kimlik çevresine geçişi gösterir.
Geleneksel ağda iç ve dış vardır. Bulutta her istek kimlikle gelir. IAM kimliği doğrular. Policy ile yetkiyi sınırlar. Doğru kurulum sınırları korur. Hata olursa saldırgan API ile güvenlik grubunu değiştirir. Bu fark, güvenlik modelini ağdan kimliğe taşır. Kimlik doğrulanmadan hiçbir API çalışmaz.
Citation capsule: IAM her API çağrısını kimlik bazında filtreler. 2026'da bulut ihlallerinin %45'i bu katmandaki hatalardan beslendi. Varsayılan red, açık izin ve koşullu kurallar birlikte çalışır. Bu tasarım insan hatasının etkisini azaltır (SentinelOne, 2026).
IAM'in dört temel bileşeni nedir?
IAM'i dört parça ile anlarız. 2026'da kimliği ele geçirilmiş hesaplar bulut ihlallerinin %70'inden fazlasını oluşturdu (SentinelOne, 2026). Bu parçalar riski azaltmak için birlikte çalışır.
| Kavram | Açıklama |
|---|---|
| Principal | İşlemi yapan varlık. Kullanıcı, rol, servis veya federated kimlik. |
| Policy | JSON izin kuralı. Hangi eylemin nerede yapılabileceğini tanımlar. |
| Credential | API imzalama anahtarı. Access Key, Secret Key, Session Token. |
| Least Privilege | Sadece gerekli izin. Varsayılan duruş. |
Principal olmadan istek yoktur. Policy olmadan yetki yoktur. Credential olmadan imza yoktur. Bu üçlü birlikte çalışır. Biri eksik olursa zincir kırılır. UNIQUE INSIGHT En sık hata: geniş policy ile başlamak ve hiç daraltmamak. Başlangıçta izinleri küçük tutmak gerekir.
Root kullanıcı neden hâlâ risk oluşturur?
Root hesap her şeye yetkilidir. Unit 42 araştırmasında AWS root hesaplarında MFA kapalı olan kuruluş oranı %24'ten %42'ye çıktı (Unit 42 Palo Alto Networks, 2021). Bu artış temel hijyenin gerilediğini gösterir.
AWS root'u sadece hesap ve fatura için saklamayı önerir (AWS Docs). Günlük işler için federasyon kullanılmalıdır. Donanım anahtarı veya passkey ile MFA şarttır. Kullanım acil durumla sınırlı kalmalıdır. Bu yaklaşım kalıcı anahtar riskini azaltır. Root kullanımı denetlenebilir olur. Her kullanımda alarm üretmek iyi pratiktir.
Citation capsule: Root ele geçirilirse IdP dahil tüm kontroller aşılır. 2021'den beri MFA'sız root oranı %42'ye yükseldi. AWS insan kullanıcılar için Identity Center ve geçici kimlik ister. Bu yaklaşım kalıcı anahtar riskini azaltır (Unit 42, AWS Docs).
IAM kullanıcısı ile IAM rolü nasıl farklı çalışır?
Fark kalıcılıktadır. Unit 42'ye göre AWS erişim anahtarlarını 90 günden uzun süre döndürmeyen kuruluş oranı %68'den %83'e yükseldi (Unit 42, 2021). Kalıcı anahtar sızıntı riskini büyütür.
Kullanıcılar eski yöntemdir. Roller servisler ve federasyon içindir. AWS en iyi uygulamaları insan için Identity Center, iş yükü için rol önerir (AWS Docs). Geçici kimlik sızsa bile süresi kısadır. Bu tasarım anahtar rotasyonu yükünü ortadan kaldırır. Operasyonel hata yüzdesi düşer.
Policy değerlendirme mantığı nasıl işler?
IAM'de varsayılan kural Implicit Deny'dir. 2026'da bulut güvenlik hatalarının %95'i yanlış yapılandırmadan kaynaklandı (SentinelOne, 2026). Açık izin yoksa red vardır. Explicit Deny her zaman Allow'u ezer.
Formül basittir. Principal + Action + Resource + Condition. Koşul eklemek riski azaltır. Örneğin tls, IP, zaman. UNIQUE INSIGHT Çoğu ekip Allow'u yazar, Deny'i unutur. Bu unutkanlık geniş izinlere yol açar. Denetimlerde ilk bulunan hata budur. Peki bu varsayılan red pratikte neyi kurtarır? Policy yazarken önce Deny senaryolarını listelemek faydalıdır.
ARN yapısı neden gereklidir?
Policy'de kaynağı net belirtmek gerekir. 2026'da bulut ihlallerinin %31'i yanlış yapılandırma ve insan hatasından geldi (SentinelOne, 2026). ARN bu hatayı azaltır.
Format: arn:partition:service:region:account-id:resource-type/resource-name. Örnek: arn:aws:s3:::my-bucket. Partition aws, aws-us-gov veya aws-cn olabilir. Region bazı servislerde boş kalır. ARN olmadan izin genişler. Dar ARN dar yetki demektir. Policy'de Resource alanına tam ARN yaz. Joker * kullanımını sınırla. Loglarda ve CloudTrail'de de ARN görünür. Bu izlenebilirliği artırır. Tam ARN kullanmak en iyi pratiktir.
AWS'de istek nasıl imzalanır ve Organizations neyi izole eder?
Her API isteği kriptografik olarak imzalanır. 2026'da profesyonellerin %69'u araç görünürlüğü ve yapılandırma yönetiminde zorlandığını söyledi (SentinelOne, 2026). İmza Access Key ID, Secret Access Key ve isteğe bağlı Session Token ile oluşur. İmza isteğin kimden geldiğini kanıtlar. Geçici kimliklerde token süresi kısadır ve risk azalır.
Kalıcı anahtarlar sızarsa risk büyür. Bu yüzden AWS anahtar rotasyonu ister. AWS Organizations birden fazla hesabı tek yapıda toplar. Fatura ve SCP ile merkezi kontrol sağlar. Bilmen gereken: hesaplar arasında varsayılan çapraz erişim yoktur. Her hesap kendi sınırını korur. Yönetim hesabı sadece SCP ile yetki verir. Bu izolasyon ihlal etkisini sınırlar. Bu tasarım, tek hesap ele geçse bile diğerlerini korur.
En az ayrıcalık ilkesini pratikte nasıl uygularsınız?
En az ayrıcalık sadece gerekli izni vermektir. 2026'da ihlallerin %31'i yanlış yapılandırmadan kaynaklandı (SentinelOne, 2026). Bu ilke sürekli daraltma ister.
AWS üç adım önerir (AWS Docs). Bir, yönetilen policy ile başla. İki, Access Analyzer ile son erişimi gör. Üç, müşteri yönetimli dar policy yaz. Kullanılmayan kullanıcı ve rolleri sil. Koşullar ekle. Public erişimi analiz et. Bu adımlar izinleri küçültür ve denetimi kolaylaştırır.
Citation capsule: Least privilege bir hedef değil süreçtir. 2026'da hataların %95'i yapılandırmadan geldi. AWS geçici kimlik, MFA ve Access Analyzer ile izinleri daraltmayı önerir. Bu yaklaşım ihlal maliyetini düşürür (SentinelOne, AWS Docs).
2025-2026'da en sık görülen IAM hataları neler?
Hatalar tekrar eder. 2026'da kuruluşların %80'i son bir yılda en az bir bulut ihlali yaşadı (SentinelOne, 2026). Aynı raporda %32 altyapı izlenmiyor. Her izlenmeyen varlık ortalama 115 zaaf taşıyor.
Beş yaygın hata: 1) Root'ta MFA yok. Oran %42. 2) IAM kullanıcılarında MFA yok. Oran %69 (Unit 42). 3) Anahtar rotasyonu yok. Oran %83. 4) Aşırı izinli rol. 5) Kullanılmayan kimlikler. Bu liste denetimlerde ilk bakılacak yerdir.
Sıkça Sorulan Sorular (FAQ)
AWS IAM tam olarak nedir?
AWS IAM, kimlerin hangi API eylemini hangi kaynakta yapabileceğini kontrol eder. Kimlik doğrular, policy ile yetki verir. 2026'da kimliği ele geçirilmiş hesaplar bulut ihlallerinin %70'inden fazlasını oluşturdu (SentinelOne, 2026). Bu yüzden IAM bulut güvenliğinin çekirdeğidir.
Root hesabını ne zaman kullanmalıyım?
Root'u neredeyse hiç kullanma. Sadece hesap kapatma ve ödeme gibi temel işlemler için. AWS root için donanım MFA önerir (AWS Docs). Unit 42'ye göre MFA'sız root oranı %42'ye çıktı (Unit 42, 2021). Günlük işler için federasyon kullan.
IAM kullanıcısı yerine ne kullanmalıyım?
İnsanlar için IAM Identity Center ile federasyon kullan. İş yükleri için IAM rolü kullan. AWS uzun süreli anahtar yerine geçici kimlik ister (AWS Docs). Unit 42'ye göre anahtarlarını 90 günden uzun döndürmeyen oran %83 (Unit 42, 2021).
En az ayrıcalığı nasıl ölçerim?
IAM Access Analyzer ve CloudTrail son erişim verisi ile ölç. Kullanılmayan izinleri sil. 2026'da ihlallerin %31'i yanlış yapılandırmadan geldi (SentinelOne, 2026). AWS yönetilen policy ile başla, sonra müşteri yönetimli dar policy'e geç (AWS Docs).
ARN neden önemli?
ARN her AWS kaynağının benzersiz adresidir. Policy'de Resource alanına ARN yazılır. Yanlış ARN geniş izin yaratır. 2026'da güvenlik hatalarının %95'i yanlış yapılandırmadan kaynaklandı (SentinelOne, 2026). Dar ARN kullanmak en az ayrıcalığın temelidir.

Comments
Loading comments...