AWS IAM policy yapısı nasıl çalışır?

Giriş

AWS konsolunda bir butona tıkladığında arka planda tek bir soru sorulur. Bu kimlik bu işlemi yapabilir mi? Cevabı veren şey IAM policy. JSON gibi duran bu belgeler, bulut güvenliğinin temel kilididir ve yanlış yazıldığında kapı sessizce aralanır ve çoğu ekip bunu fark etmez.

2026 verileri durumu netleştiriyor. Bulut ihlallerinin %45'i doğrudan bulutta gerçekleşiyor ve ortalama maliyet 5,17 milyon dolar. Şirketlerin %80'i son bir yılda en az bir bulut ihlali yaşadı. Bu ihlallerin %70'inden fazlası çalınmış kimliklerden kaynaklanıyor ve temel sebep policy hataları olarak raporlandı.

Bu yazıda policy anatomisini, Effect önceliğini, Action ve Resource yazarken yapılan hataları ve Condition ile daraltmayı göreceksin. Amaç kopyala-yapıştır değil, mantığı anlamak ve aynahatayı tekrarlamamak. Çünkü güvenlik, izin vermemekle başlar ve bu yaklaşım uzun vadede maliyetleri düşürür özellikle çok hesaplı yapılarda.

IAM policy nedir ve hangi parçalardan oluşur?

IAM policy, AWS'de izinleri tanımlayan JSON belgedir ve kimliğe ya da kaynağa eklendiğinde çalışır. SentinelOne'ın 2026 raporuna göre şirketlerin %80'i geçen yıl bulut ihlali yaşadı, bu da policy tasarımını teorik bir konu olmaktan çıkarıp günlük operasyon haline getiriyor ve ekipleri zorluyor (SentinelOne, 2026).

AWS dokümantasyonu yedi policy tipini sayar. Bunlar identity-based, resource-based, permissions boundary, SCP, RCP, ACL ve session policy'dir. Pratikte en çok ilk ikisi kullanılır ve her ikisi de JSON tabanlıdır. Her policy en az bir Statement içerir ve Statement içinde Effect, Action, Resource ve opsiyonel Condition bulunur ve bu yapı değişmez.

Temel iskelet her zaman aynıdır ve aşağıdaki örnek en az ayrıcalık prensibini gösterir. Bu yapı, sadece belirli bir S3 bucket'ından okuma izni verir ve başka hiçbir kaynağa dokunmaz. Örneği incelemek, parçaların nasıl birleştiğini anlamayı kolaylaştırır ve hataları azaltır.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "S3ReadOnly",
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::fatura-bucket/*"
  }]
}

Bu örnekte Version alanı 2012-10-17 olarak kalır ve policy dil sürümünü sabitler. Effect alanı Allow değerini alır ve izni açar. Action alanı s3:GetObject ile sadece okuma işlemine izin verir ve yazma yetkisi vermez. Resource alanı arn:aws:s3:::fatura-bucket/* ile hedefi tek bucket ile sınırlar. Hepsi tek Statement içinde çalışır ve başka kaynağa taşmaz.

Policy türleri üçe ayrılır ve seçim yönetim yükünü belirler. AWS Managed hazır gelir ve AWS tarafından güncellenir, hızlı başlangıç için uygundur. Customer Managed senin yazdığın, yeniden kullanılabilir ve merkezi kontrol sağlar. Inline ise doğrudan kullanıcıya gömülür, tekil kalır ve kimlik silindiğinde kaybolur, bu yüzden dikkatli kullanılmalıdır.

Effect önceliği neden Allow ve Deny karışıklığı yaratır?

Unit42 araştırmasına göre AWS root hesaplarında MFA kapalı olma oranı %42'ye yükseldi ve bu oran son iki yılda artış gösterdi. Bu durum, policy hatalarının etkisini büyütüyor çünkü root hesabı tüm policy'leri atlayabilir ve denetimsiz kalır (Unit42, 2021).

AWS değerlendirme sırası değişmez ve üç adımdan oluşur. İlk adım Implicit Denydir ve her şey yasaktır. İkinci adımda tüm ilgili policy'ler toplanır ve birleştirilir. Üçüncü adımda Explicit Deny var mı diye bakılır, varsa işlem durur. Dördüncü adımda Deny yoksa Explicit Allow aranır ve bulunursa izin verilir.

Bu sıra neden önemlidir? Çünkü ekipler genelde Allow yazmaya odaklanır ve Denyi unutur. Oysa hassas kaynaklarda Deny, güvenlik ağıdır ve hataları telafi eder. Örneğin üretim veritabanına Delete izni veren bir Allow varsa, aynı kaynağa Deny yazarak bunu ezebilir ve riski sıfırlayabilirsin.

Action ve Resource yazarken en sık yapılan hatalar neler?

SentinelOne'a göre bulut ihlallerinin %31'inden fazlası yanlış yapılandırma ve manuel hatalardan kaynaklanıyor ve bu oran her yıl artıyor. Bu hataların başında Action ve Resource alanlarında wildcard kullanımı geliyor ve ekipler bunu kolaylık sanıyor (SentinelOne, 2026).

Unit42 ise AWS erişim anahtarlarının %83'ünün 90 günden uzun süredir döndürülmediğini buldu. Bu bulgu, geniş izinler ile eski anahtarların birleştiğinde saldırgan için açık kapı oluşturduğunu gösteriyor ve riski katlıyor. Action alanı, işlemin hangi servise ait olduğunu ve o servisteki hangi API fonksiyonunun çağrılacağını belirtir. Yazım formatı her zaman servis:ApiCall şeklindedir (Örn: s3:PutObject). AWS'de binlerce farklı işlem bulunur ve bu standart yapı sayesinde her biri üzerinde hassas kontrol sağlanır.

En riskli yazım "Action": "*" ve "Resource": "*" kombinasyonudur ve bu AdministratorAccess etkisidir. İkinci risk s3:* gibi servis genelidir ve bucket silme dahil her şeyi açar. Üçüncü risk iam:* vermektir ve kullanıcı yaratma yetkisi içerir. Doğru yaklaşım en az ayrıcalıktır ve her zaman spesifik yazmaktır.

S3'ten sadece okuma gerekiyorsa Action alanına s3:GetObject ve s3:ListBucket yazılmalı ve Resource alanına hem bucket ARN'i hem de obje ARN'i eklenmelidir. ARN yapısı arn:partition:service:region:account-id:resource şeklindedir ve global servislerde region boş bırakılır. Bu detaylar, izni daraltır.

Condition ve Principal ne zaman kullanılmalı?

Kimlik ihlalleri bulut ihlallerinin %70'inden fazlasını oluşturuyor ve bu oran kimlik yönetimini merkeze koyuyor. Bu tablo, Condition kullanmadan yazılan her policy'nin eksik olduğunu gösteriyor ve ekiplerin bunu atlamaması gerekiyor (SentinelOne, 2026).

Trend Micro analizine göre bulut güvenlik sorunlarının %65-70'i yanlış yapılandırmadan geliyor ve bu sorunların çoğu Condition ve Principal eksikliğinden kaynaklanıyor. Condition, isteğin bağlamına bakar ve IP adresi, MFA durumu, kaynak tag'i veya VPC ID gibi değerlerle filtreler. Bu filtreler, çalınmış anahtarın etkisini azaltır.

Principal alanı ise sadece resource-based policy'lerde zorunludur ve kime izin verdiğini belirtir. S3 bucket policy veya KMS key policy yazarken spesifik rol ARN'i verilmelidir. "Principal": "*" yazmak herkese açmak demektir ve genelde hatadır. Doğrusu aws:PrincipalOrgID ile organizasyon sınırlamasıdır.

NotAction, NotResource, NotPrincipal neden tehlikelidir?

Bulut güvenlik hatalarının %95'i insan hatasından kaynaklanan yanlış yapılandırmalardır ve bu hataların en sinsi olanları Not operatörleridir çünkü ters mantıkla çalışırlar ve gözden kaçarlar (SentinelOne, 2026).

NotAction, belirttiğin işlem hariç her şeye izin verir ve ekipler bunu genelde yanlış anlar. "NotAction": "ec2:*" yazdığında EC2 hariç IAM, S3, RDS dahil her şeyi açarsın. Çoğu kişi EC2'yi yasakladığını sanır, oysa geri kalanı serbest bırakır ve fark etmez.

NotResource benzer şekilde çalışır ve belirttiğin kaynak hariç her yere izin verir. En tehlikelisi NotPrincipal ile Allow kombinasyonudur ve "Effect": "Allow", "NotPrincipal": {"AWS": "arn:aws:iam::123456789012:user/Ali"} yazarsan, Ali hariç tüm AWS hesaplarına izin vermiş olursun. Bu, internete açık policy demektir.

Sıkça Sorulan Sorular

IAM policy'de varsayılan davranış nedir?

Varsayılan davranış Implicit Denydir ve hiçbir policy yoksa erişim reddedilir. SentinelOne 2026'da şirketlerin %80'inin ihlal yaşadığını raporladı ve bu oran, varsayılanı güvenli tutmanın neden önemli olduğunu gösteriyor. Çünkü varsayılan açık olsaydı, her yeni kaynak otomatik olarak risk oluştururdu ve denetim imkansız hale gelirdi.

Explicit Deny ne zaman kullanılmalı?

Hassas kaynaklarda her zaman kullanılmalıdır ve güvenlik stratejisinin parçası olmalıdır. Örneğin üretim veritabanına silme iznini engellemek için Deny yazılır. Unit42'ye göre root MFA kapalı oranı %42 ve bu boşlukta Deny son savunma hattıdır, Allowu ezer ve hataları telafi eder.

Action'da wildcard kullanmak güvenli mi?

Hayır, güvenli değildir ve çoğu ihlalin sebebidir. "s3:*" yazmak, GetObject dahil 100'den fazla izni açar ve DeleteBucket gibi yıkıcı işlemleri de içerir. İhlallerin %31'i yanlış yapılandırmadan geliyor ve wildcard başlıca sebep budur, bu yüzden her zaman spesifik yazılmalıdır.

Resource "*" ne zaman kabul edilebilir?

Neredeyse hiç kabul edilmez ve sadece istisnai durumlarda kullanılır. Sadece iam:ListUsers gibi hesap seviyesi salt-okunur işlemlerde kullanılabilir. Veri içeren servislerde her zaman spesifik ARN yazılmalı ve wildcard'tan kaçınılmalıdır, aksi halde veri sızıntısı riski artar.

Condition ile MFA zorunlu kılınabilir mi?

Evet, Condition ile zorunlu kılınabilir ve bu en iyi uygulamalardan biridir. "Bool": {"aws:MultiFactorAuthPresent": "true"} koşulu eklenir. Kimlik ihlalleri bulut ihlallerinin %70'inden fazlasını oluşturuyor, MFA bu riski doğrudan keser ve Condition olmadan policy eksik kalır ve denetimden geçemez.