Dağıtık Sistemlerde Güvenlik: AWS ve Hibrit Bulut Altyapılarında IAM Zafiyetleri ve Sıkılaştırma

Giriş: Yeni Çevre Güvenliği Olarak Kimlik (Identity as the New Perimeter)

Şunu biliyor muydun? Bir AWS S3 bucket’ı veya iç ağdaki bir veritabanı tamamen internete kapalı (private) olsa bile, sızdırılan tek bir kimlik belgesi (credential) veya yanlış yapılandırılmış bir IAM rolü tüm altyapının saniyeler içinde ele geçirilmesine neden olabilir.

Geleneksel bilgi güvenliği mimarisinde sınır güvenliği, büyük ölçüde network cihazlarına (Firewall, IPS/IDS) ve izole edilmiş ağ bölgelerine (DMZ) dayandırılmaktaydı. Bu modelde, ağın içi “güvenli”, dışı ise “güvensiz” olarak kabul edilirdi. Ancak bulut bilişimin yükselişi, dağıtık mikroservis mimarileri, sunucusuz (serverless) teknolojiler ve uzaktan çalışma modelleriyle birlikte fiziksel veya mantıksal ağ sınırları ortadan kalkmıştır. Bulut ortamlarında, kaynaklara erişim ağ tabanlı kurallardan ziyade API çağrıları üzerinden yönetildiği için geleneksel “kale ve hendek” yaklaşımı artık yetersizdir.

Bu paradigma değişikliği, Sıfır Güven (Zero Trust) felsefesinin temelini oluşturur. Sıfır Güven yaklaşımı, ağın neresinden gelirse gelsin hiçbir isteğe varsayılan olarak güvenilmemesi gerektiğini savunur. Bulut mimarilerinde yeni sınır hattı (perimeter) artık ağ bileşenleri değil, Kimlik ve Erişim Yönetimi (IAM) katmanıdır.

AWS IAM Anatomisi ve Kritik Yanlış Yapılandırmalar (Misconfigurations)

AWS IAM, çok katmanlı ve karmaşık bir yapılandırma mekanizmasına sahiptir. IAM politikalarının değerlendirme mantığı (Evaluation Logic) üç temel kavrama dayanır: Default Deny (Varsayılan Red), Explicit Allow (Açık İzin) ve Explicit Deny (Açık Red).

Bir kimlik bir kaynağa erişmek istediğinde, AWS tüm politikaları sırayla değerlendirir:

1. Başlangıçta tüm istekler “Default Deny” durumundadır.
2. Tüm politikalar arasında “Explicit Deny” olup olmadığı kontrol edilir. Varsa, erişim kesinlikle engellenir (Deny her zaman Allow’u ezer).
3. “Explicit Deny” yoksa, politikalar arasında “Explicit Allow” olup olmadığına bakılır. “Explicit Allow” varsa erişime izin verilir. Aksi halde istek reddedilir.

Bu karmaşık mantık, özellikle kimlik tabanlı politikalar (Identity-based policies) ve kaynak tabanlı politikalar (Resource-based policies) bir araya geldiğinde zafiyetlere yol açabilmektedir.

Sektörel Yanlış Yapılandırma Örnekleri

Aşırı Yetkili Wildcard (*) Kullanımı:
Bulut mühendisleri, hızlı entegrasyon sağlamak adına genellikle en az yetki prensibini göz ardı ederek politikalarda wildcard (*) kullanma eğilimindedir. Örneğin, yalnızca S3 üzerindeki nesneleri listelemesi gereken bir role s3:* yetkisi vermek, nesnelerin silinmesine veya bucket politikalarının değiştirilmesine (S3 Bucket Takeover) zemin hazırlar.

Güven İlişkilerinde (Trust Relationships) “Principal”: “*” Yanılgısı:
Rol üstlenme (AssumeRole) süreçlerinde, kaynağa kimlerin erişebileceğini belirleyen Güven Politikaları (Trust Policies) kritik bir rol oynar. Aşağıdaki gibi yapılandırılmış bir politika, dışarıdan herhangi bir hesaba ait kullanıcının rolü üstlenebilmesine yol açar:

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

Yukarıdaki politika, sadece belirli bir hizmete (örn: ec2.amazonaws.com) veya hesap ID’sine kısıtlanmadığında, zafiyet global bir saldırı yüzeyi oluşturur (Confused Deputy Attack vb. saldırılara açık hale gelir).

IAM Üzerinde Yetki Yükseltme (Privilege Escalation) Senaryoları

Saldırganlar, bulut ortamında yatay hareket (lateral movement) ve yetki yükseltme işlemlerini gerçekleştirmek için IAM API çağrılarını kötüye kullanırlar. Düşük yetkili bir kullanıcı veya kompromize olmuş bir EC2 örneği üzerinden yönetici yetkilerine (AdministratorAccess) sıçramak için kullanılan temel ofansif senaryolar şunlardır:

1. iam:CreatePolicyVersion Aracılığıyla Yetki Yükseltme

Saldırgan, sahip olduğu düşük yetkili kullanıcıya atanmış müşteri tarafından yönetilen (customer-managed) bir politikanın versiyonunu güncelleyebilme yetkisine sahipse, kendisine tam yetki verecek yeni bir politika versiyonu oluşturup bunu varsayılan olarak ayarlayabilir.

Kötüye kullanılan yetki:

• iam:CreatePolicyVersion

Örnek Saldırı Senaryosu (Yeni Versiyon Oluşturma):

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

Saldırgan bu JSON belgesini aws iam create-policy-version --policy-arn <PolicyARN> --policy-document file://evil-policy.json --set-as-default komutu ile uygulayarak doğrudan Administrator hakları kazanır.

2. iam:PutUserPolicy veya iam:AttachUserPolicy Kötüye Kullanımı

Eğer saldırgan, kendisine (veya kompromize ettiği hedefe) politika atama veya iç içe politika (inline policy) yazma haklarına sahipse, doğrudan kendi haklarını yükseltebilir.

Kötüye kullanılan yetki:

• iam:AttachUserPolicy
• iam:PutUserPolicy

Saldırgan komutu: aws iam attach-user-policy --user-name hacker --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

3. iam:PassRole ve Gelişmiş Compute Yetki Yükseltmeleri

Bulutta en kritik ancak en az anlaşılan yetkilerden biri iam:PassRole yetkisidir. Bu yetki, kullanıcının bir IAM rolünü bir AWS servisine (örn: EC2 veya Lambda) “geçirmesini” (atamasını) sağlar.

Eğer saldırgan;

1. iam:PassRole yetkisine sahipse ve
2. Herhangi bir EC2 örneği (ec2:RunInstances) başlatabiliyorsa veya Lambda fonksiyonu (lambda:CreateFunction / lambda:InvokeFunction) oluşturabiliyorsa,

kendisinde Administrator yetkisi olmasa bile, Administrator yetkisine sahip bir IAM rolünü (örn: arn:aws:iam::123456789012:role/AdminRole) başlattığı bir EC2 örneğine veya Lambda fonksiyonuna atayabilir. Daha sonra çalıştırdığı kod (veya örneğe bağlandığı kabuk) vasıtasıyla bu yüksek yetkili rol üzerinden tüm AWS altyapısını ele geçirir.

Hibrit Bulut ve Dağıtık Sistemlerde Kimlik Riskleri

Modern kurumsal mimariler genellikle tamamen bulut tabanlı değildir. Kurumlar, mevcut Active Directory (AD) altyapılarını AWS ile entegre etmek için SAML tabanlı Federasyon veya AWS IAM Identity Center (eski adıyla AWS SSO) kullanırlar.

Yatay Geçiş (Lateral Movement) Riski:
Bu mimarilerde, eğer on-premise ağda bulunan AD ortamı sızma testleri veya gerçek bir APT (Gelişmiş Sürekli Tehdit) aktörü tarafından ele geçirilirse, saldırgan Golden Ticket saldırıları veya ADFS (Active Directory Federation Services) imzalama sertifikasını (Token-signing certificate) ele geçirerek bulut altyapısına doğrudan erişim sağlayabilir (Golden SAML). Bu durum, lokaldeki bir kimlik avı saldırısının buluttaki veritabanlarının silinmesi veya kripto madencilik botnetlerinin kurulması ile sonuçlanabileceği anlamına gelir.

Sync Sorunları ve Hayalet (Zombie) Hesaplar:
Hibrit ortamlarda işten ayrılan personelin hesaplarının on-premise AD üzerinde kapatılmasına rağmen senkronizasyon hataları veya doğrudan AWS üzerinde açılmış yerel (local) IAM kullanıcıları nedeniyle bulutta aktif kalması ciddi bir saldırı yüzeyi oluşturur. Bu “zombi” kimlik belgeleri genellikle uzun ömürlü access key’ler (AKIA…) ile birleştiğinde yıllarca tespit edilemeyen arka kapılara dönüşür.

Defansif Sıkılaştırma ve Altyapı Güvenliği (Remediation & Hardening)

Mimarideki bu zafiyetleri kapatmak, proaktif bir defansif mühendislik gerektirir. Sıkılaştırma operasyonları hem organizasyonel düzeyde hem de Sürekli Entegrasyon (CI/CD) boru hatlarında yürütülmelidir.

Organizasyon Düzeyinde Service Control Policies (SCP):
AWS Organizations kullanılarak yapılandırılan Service Control Policies (SCP), bir hesabın sınırlarını çizer ve hesap root kullanıcısı dahil kimsenin aşamayacağı global güvenlik kuralları (guardrails) oluşturur. Örneğin, CloudTrail kayıtlarının silinmesini engelleyen bir SCP, savunma mekanizmalarının kör edilmesinin önüne geçer:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail"
      ],
      "Resource": "*"
    }
  ]
}

Least Privilege Otomasyonu:
Geliştiricilerin başlangıçta talep ettiği yüksek yetkiler, IAM Access Analyzer kullanılarak zaman içinde denetlenmelidir. Bu servis, belirli bir süre boyunca kullanılmayan API yetkilerini tespit eder ve geriye dönük olarak IAM politikalarını daraltmak için güvenli şablonlar önerir. Uzun ömürlü IAM Access Key kullanımları tamamen kaldırılmalı, yerine kısa süreli STS tabanlı roller (IAM Identity Center vb.) tercih edilmelidir.

Kod Olarak Altyapı (IaC) Boru Hattında Statik Analiz:
Kimlik zafiyetlerini daha bulut ortamına yansımadan (“Shift-Left” yaklaşımı) engellemek en etkili defans yöntemidir. Terraform, CloudFormation veya Pulumi ile yazılan altyapı kodları; Checkov, Trivy veya Tfsec gibi statik kod analizi (SAST) araçlarıyla CI/CD süreçlerinde denetlenmelidir. Bir geliştirici, politikasında Action: "*" veya Resource: "*" barındıran bir Terraform kodu commit ettiğinde, bu araçlar hatayı tespit edip deployment (dağıtım) işlemini anında kırmalıdır (fail).

Sonuç

Bulut mimarilerinde güvenliği sağlamak için atılması gereken kritik adımlar şunlardır:

• Kimlik Yeni Sınırdır: “Identity is the new perimeter” söylemi sadece kavramsal bir slogan değil; teknik, ofansif ve defansif stratejilerin merkezine alınması gereken bir gerçektir.
• En Düşük Yetki Prensibi: AWS IAM üzerinde Principle of Least Privilege katı bir şekilde uygulanmalı, wildcard kullanımından kaçınılmalıdır.
• Global Kısıtlamalar: Service Control Policies (SCP) ile root dahil herkes için geçerli global güvenlik kuralları (guardrails) oluşturulmalıdır.
• Sürekli Denetim: IaC süreçlerinde otomatize edilmiş statik analiz araçları (SAST) kullanılarak, zafiyetler canlıya çıkmadan önce boru hattında (pipeline) tespit edilip engellenmelidir.
• Geçici Yetkilendirme: Uzun ömürlü erişim anahtarları (access keys) yerine geçici (STS tabanlı) roller tercih edilmelidir.

Kaynakça

1. AWS Identity and Access Management (IAM) Documentation
2. Rhino Security Labs - AWS IAM Privilege Escalation
3. CyberArk - Golden SAML Attack