IAM’de En Az Ayrıcalık: Neden Bu Kadar Önemli ve Nasıl Uygulanır?

Giriş

Bulut güvenlik ihlallerinin neredeyse tamamı müşteri kaynaklı. Gartner’ın 2020’de yaptığı ve 2025’i işaret eden çarpıcı öngörüye göre, bulut güvenliği başarısızlıklarının %99’u kullanıcı kuruluşun sorumluluğunda olacak (Gartner). İtiraf edelim: çoğumuz bu istatistiğe katkıda bulunduk. Aceleyle AdministratorAccess yapıştırıp geçtiğimiz, “nasıl olsa test ortamı” dediğimiz politikalar, üretime taşındığında bombaya dönüştü.

İyi haber şu ki, bir IAM politikasını Admin* seviyesinden yalnızca gereken minimum izinlere indirgemek sandığınızdan kolay. Bu yazı, AWS’de adım adım nasıl yapacağınızı ve aynı prensipleri Azure ile GCP’de nasıl uygulayacağınızı anlatıyor.

En az ayrıcalık tam olarak nedir?

En az ayrıcalık, bir kimliğe (kullanıcı, rol, servis hesabı) yalnızca mevcut görevini yapması için gereken en düşük yetki seviyesinin verilmesini öngören temel bir güvenlik prensibidir. Sıfır güven (zero trust) mimarisinin de temel taşlarından biridir: hiçbir varlığa varsayılan güven duyulmaz, her istek yetkilendirme kontrollerinden geçer.

2025 Verizon DBIR’e göre, bulut ortamlarındaki "Temel Web Uygulaması Saldırıları"nın %88’inde ele geçirilen kimlik bilgileri kullanılıyor (Verizon, 2025). Kimlik bilgilerini koruyamadığınız her senaryoda, en az ayrıcalık sizin son savunma hattınızdır. IAM bağlamında bu ilke, Action: "*" ve Resource: "*" gibi joker karakterlerden kaçınmak anlamına gelir. Ne kadar spesifik olursanız, olası bir kimlik hırsızlığında saldırganın hareket alanı o kadar daralır.

Geniş yetkilerin yol açtığı riskler

Bulutta her ek izin, saldırı yüzeyini büyütür. AdministratorAccess politikasına sahip bir kullanıcı, hesaptaki tüm kaynaklara sınırsız erişime sahiptir. Bu kullanıcının erişim anahtarı sızdığında, saldırgan saniyeler içinde veritabanlarını silebilir, S3 bucket’larındaki hassas verileri dışarı aktarabilir veya kaynakları kripto para madenciliği için kullanabilir.

Tek bir aşırı yetkili rol, “patlama alanını” (blast radius) tüm hesaba yayar. Oysa kaynak ve eylem bazında daraltılmış bir politika, aynı kimlik çalınsa bile etkiyi belirli bir bucket veya bölgeyle sınırlar. Bu, teorik bir risk değil, sürekli karşılaşılan bir gerçeklik.

Adım adım politika daraltma (AWS ile uygulamalı örnek)

Aşağıdaki süreç, tipik bir AdministratorAccess politikasını en az ayrıcalıklı hale getiriyor. Adımları kendi ortamınıza uyarlayabilirsiniz.

Başlangıç: AdministratorAccess (Çok Geniş)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
  }]
}

Bu politika, hesaptaki her kaynağa, her türlü işleme yetki verir. Üretim ortamında asla bulunmamalıdır. Varsa, acil eylem planınızın ilk maddesi bu politikayı kaldırmak olmalıdır.

Adım 1: Servise Göre Kısıtlama

Sadece EC2 ve S3 servislerine erişim sağlayın:

{
  "Version": "2012-10-17",
  "Statement": [
    { "Sid": "PermitEC2", "Effect": "Allow", "Action": "ec2:*", "Resource": "*" },
    { "Sid": "PermitS3", "Effect": "Allow", "Action": "s3:*", "Resource": "*" }
  ]
}

ec2:* ve s3:*, ilgili servislerin tüm API çağrılarını kapsar; hâlâ geniş, ama en azından RDS, IAM gibi alanlara dokunulamaz. Bu adım, “hangi servisleri kullanıyorum?” farkındalığını yaratması açısından değerlidir.

Adım 2: Salt Okunur (Read‑Only) İşlemlere Daraltma

Kullanıcının yalnızca listeleme ve okuma yapabilmesini, ancak hiçbir şey oluşturamamasını veya silememesini sağlayalım:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EC2-ReadOnly",
      "Effect": "Allow",
      "Action": ["ec2:Describe*", "ec2:Get*"],
      "Resource": "*"
    },
    {
      "Sid": "S3-ReadOnly",
      "Effect": "Allow",
      "Action": ["s3:Get*", "s3:List*"],
      "Resource": "*"
    }
  ]
}

Burada Describe* ve Get* gibi önekli eylemler kullanarak değişiklik yapabilecek Create*, Delete*, Put* gibi izinleri dışarıda bıraktık. Bu geçiş, çoğu denetim ve raporlama görevi için yeterlidir.

Adım 3: Belirli Kaynaklara Kısıtlama (Gerçek En Az Ayrıcalık)

Şimdi hedef kaynakları daraltıyoruz:

• EC2 için sadece ap‑southeast‑1 (Singapur) bölgesindeki instance’lara tam erişim
• S3 için sadece my‑corporate‑bucket adlı bucket’a okuma erişimi

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EC2-ReadOnly-Global",
      "Effect": "Allow",
      "Action": ["ec2:Describe*", "ec2:Get*"],
      "Resource": "*"
    },
    {
      "Sid": "EC2-FullAccess-Singapore",
      "Effect": "Allow",
      "Action": ["ec2:*"],
      "Resource": "arn:aws:ec2:ap-southeast-1:*:instance/*"
    },
    {
      "Sid": "S3-ReadOnly-CorporateBucket",
      "Effect": "Allow",
      "Action": ["s3:Get*", "s3:List*"],
      "Resource": [
        "arn:aws:s3:::my-corporate-bucket",
        "arn:aws:s3:::my-corporate-bucket/*"
      ]
    }
  ]
}

Bu nihai politika, ilk haline kıyasla saldırı yüzeyini dramatik şekilde küçültür.

Diğer bulutlarda en az ayrıcalık: Azure ve GCP

Bu üç büyük sağlayıcıda prensip aynıdır, yalnızca uygulama araçları değişir.

• Azure RBAC: Azure, yerleşik (built‑in) roller sunar (örneğin, Reader, Contributor, Owner). En az ayrıcalık için, bu genel roller yerine özel (custom) roller oluşturup yalnızca ihtiyaç duyulan eylemleri atayabilirsiniz. Azure AD Privileged Identity Management (PIM) ile just‑in‑time yetkilendirme de mümkündür. Önemli bir tuzak: Contributor rolü, Azure Key Vault’taki sırları varsayılan olarak okuyamaz, ancak VM’lere bu sırları enjekte edebilir; bu tür ince ayrımları anlamak, en az ayrıcalık tasarımının kritik parçasıdır (Azure Belgeleri).
• GCP IAM: GCP, önceden tanımlanmış roller (predefined roles) ve özel roller sunar. Kaynak hiyerarşisi (organizasyon > klasör > proje) sayesinde politikalar yukarıdan aşağıya devralınır. IAM Recommender, aşırı izinleri otomatik olarak tespit eder ve size daraltma önerileri sunar (GCP Belgeleri).

Her üç platformda da “izin yükseltme” (privilege escalation) riski vardır; örneğin, iam.serviceAccounts.actAs gibi bir yetki, GCP’de yeni bir kimlik üstlenmeye yol açabilir. AWS tarafında ise iam:PassRole, iam:CreatePolicyVersion gibi eylemler özellikle tehlikelidir ve mümkünse hiçbir rolde bulunmamalıdır.

Sürekli en az ayrıcalık için stratejiler ve araçlar

Politika yazmak bir başlangıçtır; asıl mesele bu durumu sürdürmektir.

• IAM Access Analyzer (AWS): Kaynak tabanlı politikaları tarar, dış hesaplarla paylaşılan kaynakları bulur ve aşırı izinleri belirler. Politika önerileri sunar.
• Service Control Policies (SCP’ler): AWS Organizations ile hesap düzeyinde güvenlik sınırları çizer. Örneğin, ec2:* iznini sadece belirli bölgelerle sınırlayan bir SCP, alt hesaplarda yanlışlıkla geniş bir politika yazılmasını engeller.
• Altyapı Olarak Kod (IaC): Terraform, Pulumi veya AWS CDK ile politikaları sürüm kontrolüne alın. Her değişikliği kod incelemesinden (code review) geçirin. CI/CD pipeline’ında joker karakter (*) kullanımını yasaklayan statik analiz kuralları ekleyin.
• Düzenli Erişim Değerlendirmesi (Access Review): En az ayrıcalığın zamanla bozulmasını önlemek için üç ayda bir, kullanılmayan roller ve aşırı izinler için otomatik raporlar alın. AWS IAM Access Advisor, son kullanılan servis bilgilerini göstererek hangi izinlerin kaldırılabileceğini söyler.
• Çok Faktörlü Kimlik Doğrulama (MFA): En az ayrıcalıklı politikalar bile kimlik hırsızlığını engelleyemez; bu yüzden tüm kullanıcılar için MFA’yı zorunlu kılın.

İzleme ve Uyarı Mekanizmaları

En az ayrıcalıklı bir politika yazmak yetmez; ihlal girişimlerini ve politika değişikliklerini izlemeniz gerekir. Bir politika değiştiğinde, bu değişikliğin farkında değilseniz en az ayrıcalık hızla buharlaşır.

• AWS CloudTrail + Config: IAM olaylarını CloudTrail ile kaydedin. iam-policy-changed gibi AWS Config kurallarıyla politika değişikliklerinde anlık uyarı alın. CloudTrail Lake ile “sıra dışı erişim kalıpları” için otomatik sorgu çalıştırabilirsiniz.
• Azure Activity Log + Sentinel: Azure RBAC değişikliklerini Activity Log’da izleyin. Sentinel playbook’larıyla beklenmedik rol atamalarını otomatik olarak geri alabilir veya yetkiliye bildirebilirsiniz.
• GCP Cloud Audit Logs + Security Command Center: SetIamPolicy çağrılarını Cloud Audit Logs’a kaydedin. Security Command Center Premium katmanında, IAM anomalilerini tehdit algılama ile birleştirerek proaktif uyarılar alabilirsiniz.

How to Generate Least Privilege IAM Policies with AWS Access Analyzer

Victor Feynman'ın bu 5 dakikalık demosu, CloudTrail log'larından otomatik olarak en az ayrıcalıklı politikalar oluşturma sürecini uygulamalı olarak gösteriyor.

Sonuç

En az ayrıcalık, bulut güvenliğinin en eski ama en çok ihlal edilen kurallarından biridir. Bir IAM politikasını Admin* seviyesinden ihtiyaca özel hale getirmek genellikle birkaç dakika sürer. Asıl mesele, bu disiplini sürdürmektir.

Bugün atabileceğiniz ilk adım şu: En kritik IAM rollerinizi gözden geçirin ve joker karakterleri (*) tek tek kaldırmaya başlayın. Politika simülatöründe beklenmedik erişim engelleriyle karşılaşırsanız endişelenmeyin; hataları daraltarak ilerlemek, hiç daraltmamaktan iyidir. Unutmayın, her kaldırdığınız izin, bir sonraki güvenlik olayında sizi koruyacak bir kalkandır.

Sıkça sorulan sorular

Kaynakça / ek okuma

• Verizon, “2025 Data Breach Investigations Report (DBIR)”, 2025. Verizon
• Security Boulevard (atıfla Gartner), “Top Cloud Security Challenges Businesses Face in 2025”, 2025. Security Boulevard
• AWS Well‑Architected Framework, Security Pillar: Identity and Access Management, 2025. AWS
• Microsoft Azure Belgeleri, “Azure RBAC için en iyi uygulamalar”, 2025. Azure
• Google Cloud Belgeleri, “IAM’i güvenli kullanma”, 2025. GCP
• Cybersecurity Insiders / Fortinet, “2025 State of Cloud Security Report”, 2025. Cybersecurity Insiders
• AWS IAM Policy Simulator, Simulator