AWS Sızma Testi - Bir Kimlik Nelere Erişebilir?

Bulut güvenliği testinin en yaygın hatası, konsolda görünen bir ayarı kontrol etmekle o ayarın ne sonuç ürettiğini doğrulamayı karıştırmaktır. Bir role “read-only” adı verilmiş olabilir; ama trust policy, resource policy ve koşullar birlikte değerlendirildiğinde gerçekte ne okuyabiliyor? Bir bucket “private” görünebilir; peki account-level public access block, bucket policy, ACL ve access point politikaları aynı anda mı koruyor, yoksa yalnızca biri mi?

Bu playbook’un tek bir yönlendirici sorusu var ve her testi bu soru belirler: “İzin tanımlı mı?” değil, “Bu kimlik, tüm identity ve resource politikaları birlikte değerlendirildiğinde gerçekte hangi iş sonucunu üretebilir?” AWS’te gerçek risk tek bir izinden değil; kimlik politikaları, resource policy’ler, organization guardrail’leri, servis rolleri, ağ yolları, şifreleme anahtarları ve event tabanlı otomasyonların birleşiminden doğar. Tek başına masum iki izin, birlikte kullanıldığında hesaplar arası erişime ya da yüksek yetkili bir servis rolüyle kod çalıştırmaya dönüşebilir.

Aşağıda, düşük yetkili bir principal’ın başlangıç erişiminden cluster/hesap/organization etkisine giden yolun her halkasını hangi güvenli yöntemle test edeceğinizi bulacaksınız. Yazı yalnızca sahibi olduğunuz veya yazılı yetki aldığınız ortamlar içindir; kontroller belirli bir araca değil, AWS API davranışına, policy değerlendirme mantığına ve gözlemlenebilir sonuçlara dayanır.

---

1. Testin amacı: hangi sorulara kanıtla cevap vermelisiniz?

Testinizi baştan sona şu sorular yönlendirir; her biri tahminle değil kanıtla yanıtlanmalıdır:

• Organization, hesap, bölge ve servis sınırları eksiksiz görülebiliyor mu?
• İnsan, workload ve otomasyon kimlikleri nasıl doğrulanıyor?
• Düşük yetkili bir principal gerçekte hangi kaynaklara erişebiliyor?
• Bir izin başka servislerdeki izinlerle birleştiğinde yetki yükseltme oluşuyor mu?
• Hesaplar arası trust ilişkileri beklenen principal ve koşullarla sınırlı mı?
• İnternete açık kaynaklar gerçekten gerekli mi ve koruyucu katmanları çalışıyor mu?
• Şifreleme anahtarlarının politikası, şifrelediği veriden daha geniş erişim sağlıyor mu?
• Güvenlik kayıtları saldırganın erişebileceği hesaptan ayrılmış ve değiştirilemez mi?
• Riskli bir işlem algılanıp anlamlı bir alarma dönüşüyor ve sahibine ulaşıyor mu?
• Test sırasında oluşan kaynaklar, dış bağımlılıklar ve maliyet etkileri tamamen geri alınabiliyor mu?

---

2. Önce yöntem: güvenli test modeli

AWS’te “yanlışlıkla üretime dokunmak” ekstra bir boyut taşır: maliyet. Bu yüzden neyi test edeceğinizden önce nasıl test edeceğinizi netleştirin.

2.1 Test seviyeleri (S0–S4)

S3 ve S4 varsayılan kapsamın parçası değildir. Gerçek veriyi indirmek, üretim secret’ını çözmek, kalıcı access key üretmek, loglamayı durdurmak, yedek silmek, üretim kodunu değiştirmek, kontrolsüz maliyet doğuran kaynak oluşturmak veya guardrail kaldırmak ayrı ve açık yetki olmadan yapılmaz.

2.2 “İlk güvenli kanıtta dur” kuralı

Bir riskin etkisini göstermek için onu sömürmeniz gerekmez; minimum kanıt yeterlidir:

• Veri erişiminde: gerçek kayıt yerine benzersiz bir canary nesnesi.
• Secret erişiminde: gerçek değer yerine sentetik secret ve tek yönlü özet.
• Şifre çözmede: production ciphertext yerine test anahtarıyla üretilmiş test verisi.
• Servis rolü aktarımında: yönetici rolü yerine yalnızca canary kaynağa erişen sentetik rol.
• Event zincirinde: gerçek fonksiyon yerine sabit, zararsız çıktı üreten test fonksiyonu.
• Cross-account erişimde: production hesap yerine ayrılmış iki test hesabı.

Canary kanıtı alındığında zincir durur. Erişim mümkün olduğu için gerçek veriye geçilmez.

2.3 Durdurma koşulları

Şunlardan biri görülürse aktif test durur ve ilgili taraflara bildirilir: beklenmeyen faturalama/kaynak tüketimi artışı; üretim trafiğinde hata/gecikme/kapasite etkisi; kapsam dışı hesap/bölge/kaynağa geçiş; gerçek kişisel veri, credential veya üretim secret’ıyla karşılaşma; test kimliğinin beklenenden geniş yetkili çıkması; güvenlik otomasyonunun izolasyon/silme/erişim kesme başlatması; geri dönüş adımının başarısızlığı; merkezi loglama veya güvenlik kontrolünde beklenmeyen değişiklik.

2.4 Test kimlikleri ve test hesabı standardı

Tek bir yönetici kimliğiyle tüm değerlendirmeyi yapmak, etkin güven sınırlarını ölçmeyi imkansız kılar çünkü her kapıyı zaten açık bir anahtarla denersiniz. En az şu profilleri ayrı test edin: organization görünürlüğü olan salt okunur denetçi; düşük yetkili geliştirici; dağıtım otomasyonu rolü; uygulama çalışma rolü; hesap yöneticisi; güvenlik/log hesabı okuyucusu; acil durum erişim rolü; harici hesap için sentetik test rolü. Kimlikler federasyon üzerinden, MFA korumalı, kısa oturumlu ve benzersiz oturum adıyla kullanılmalıdır.

S2 ve üzeri kontroller mümkünse production organizasyonu içindeki ayrılmış bir test hesabında yapılır. Bu hesap: production verisi içermez; merkezi loglama/algılamaya bağlıdır; guardrail’leri production ile aynı alır; sıkı bütçe ve kotaya sahiptir; dış bağlantıları sınırlıdır; test kaynaklarını otomatik sona erdiren etiket ve yaşam döngüsü kuralları kullanır; gerektiğinde bütünüyle kapatılabilir.

---

3. Kanıt modeli: bulguyu nasıl kaydedersiniz?

Her kontrol için şu kaydı tutun:

Test ID:
Zaman (UTC):
Test seviyesi (S0–S4):
Kaynak hesap / bölge sınıfı:
Test principal'ı:
İlgili servis ve kaynak türü:
İncelenen policy veya gönderilen istek:
Beklenen güvenli sonuç:
Gözlenen sonuç:
Karar: PASS / FAIL / PARTIAL / BLOCKED / N/A
Maskelenmiş kanıt veya kanıt hash'i:
Maliyet ve servis etkisi:
Geri dönüş adımı ve doğrulaması:

Şunlar daima maskelenir: hesap numarası ve gerçek ARN’ler; kullanıcı/rol adları; IP, alan adı, bucket adları; access key, session token, imzalı istekler; secret ve parameter değerleri; veritabanı endpoint’leri ve snapshot adları; loglardaki kişisel/iş verileri.

Sonuç durumları: PASS (güvenli davranış kanıtlandı), FAIL (risk veya önkoşul güvenle doğrulandı), PARTIAL (bazı policy katmanları koruyor, bazıları korumuyor ya da yalnızca alarm üretiliyor), BLOCKED (yetki/görünürlük/bağımlılık/onay eksikliği nedeniyle tamamlanamadı), N/A (mimari gereği uygulanamaz).

Kritik nüans: AccessDenied her zaman PASS değildir. Ret, kontrolün güvenli olduğu anlamına gelebilir; ama test kimliğinin envanteri görmeye bile yetkisi yoksa sonuç aslında BLOCKED’tır. Ret kararının doğru policy katmanından ve beklenen nedenle geldiğini doğrulamadan geçmiş saymayın.

---

4. Uçtan uca test akışı

Aşama 0 Organization ve güven sınırı haritası

Komuttan önce harita. Amaç servis listesi değil; “hangi principal, hangi policy katmanlarını geçerek hangi iş verisine veya çalışma rolüne ulaşabilir?” grafiğidir. Üzerine şunları ilişkilendirin: organization/OU/hesap hiyerarşisi; yönetim, güvenlik, log arşivi, ağ ve workload hesapları; organization policy’leri ve delegated administrator rolleri; insan ve workload kimlik kaynakları; cross-account trust ilişkileri; merkezi ağ, DNS ve internet çıkış yolları; veri sınıfları, KMS anahtarları ve yedek hedefleri; merkezi audit/config/threat detection akışı; CI/CD ve IaC yolu.

Aşama 1 Global ve çok bölgeli keşif (S1)

Not: etiketsiz kaynak otomatik olarak “düşük riskli” sayılmaz.

Aşama 2 Organization guardrail’leri ve hesap temeli

AWS-ORG-01 Root kullanıcı. MFA, access key yokluğu, günlük işte kullanılmaması, güncel iletişim bilgisi, kullanım alarmı. Aktif root oturumu açmak varsayılan test değildir; yapılandırma ve audit kanıtı yeterlidir.

AWS-ORG-02 SCP kapsamı. Her OU’nun etkili guardrail’lerini hesaplayın: region restriction, log koruması, güvenlik servislerinin kapatılamaması, public erişim ve root sınırları. Bulgu: kritik deny guardrail’inin yalnızca bazı hesaplara uygulanması veya geniş istisna.

AWS-ORG-03 Delegated admin ve yönetim hesabı. Güvenlik servisleri için delegated admin, management account’taki insan erişimi, workload otomasyonunun organization yönetimine ulaşamaması, hesap oluşturma/taşıma yetkileri.

AWS-ORG-04 Varsayılan güvenlik temeli. Yeni hesap açıldığında otomatik gelen kontroller: merkezi audit, config recording, threat detection, public access guardrail’leri, varsayılan şifreleme, bütçe/iletişim, varsayılan ağların yönetimi. Bir landing zone kontrolü yalnızca mevcut hesaplarda değil, sentetik yeni hesap yaşam döngüsünde de doğrulanmalıdır (S3 + maliyet onayı).

Aşama 3 Kimlik doğrulama, IAM ve yetki yükseltme

AWS testinin kalbi burasıdır ve buradaki tek altın kural şudur: IAM, identity policy listesi değildir; etkin karar birçok katmanın kesişimidir.

Identity policy
  ∩ permissions boundary
  ∩ session policy
  ∩ service control policy (SCP)
  ∩ resource policy / trust policy
  ∩ koşullar (conditions)
  − explicit deny
= etkin yetki ve iş etkisi

Bir principal’ın “ne yapabildiğini” bu formülü çözmeden söyleyemezsiniz. Aşağıdaki testlerin hepsi bu kesişimi farklı açılardan yoklar.

AWS-IAM-01 Federasyon, MFA, oturum. İnsan erişiminin merkezi kimlikten gelmesi, ayrıcalıklı roller için phishing-resistant MFA, oturum süresi/yeniden doğrulama, devre dışı kullanıcının hızlı kaldırılması, permission set atamalarının onayı.

AWS-IAM-02 Yerel kullanıcı ve access key. Konsol parolası/key taşıyan yerel kullanıcıları gerekçelendirin. Yaş tek başına yetmez; son kullanım, servis, kaynak IP ve sahip birlikte değerlendirilir. İki aktif key, hiç kullanılmamış key ve rotation sonrası açık kalan eski key işaretlenir. Bulgu: insan kullanıcısında kalıcı key, paylaşımlı kullanıcı, otomasyonda sahipsiz credential.

AWS-IAM-03 Trust policy analizi. Wildcard principal; root principal’a aşırı geniş trust; harici hesaplar için ExternalId/organization/kaynak koşulları; web identity için audience/subject sınırı; servis principal’ı için SourceArn/SourceAccount; session tag davranışı; role chaining ve maksimum oturum süresi. Unutmayın: “Bu rolü kim assume edebilir?” sorusu yalnızca trust policy ile değil, karşı taraftaki assume izniyle birlikte cevaplanır.

AWS-IAM-04 Wildcard ve koşulsuz izinler. Action:*, Resource:*, NotAction/NotResource bağlamıyla incelenir. “Read-only” adlı bir rolün decrypt, secret ve log yetkileri ayrıca değerlendirilir. Tag tabanlı koşulların principal tarafından değiştirilebilir etiketlere güvenip güvenmediği kontrol edilir.

AWS-IAM-05 Doğrudan policy manipülasyonu. Şu yetki aileleri ayrı saldırı yolu sayılır: inline policy yazma; managed policy bağlama; yeni policy version oluşturup varsayılan yapma; trust policy değiştirme; permissions boundary kaldırma/değiştirme; grup/permission set ataması değiştirme; yeni access key/login profile oluşturma. S1’de yalnızca etkin izin analizi; S2’de ayrılmış test principal’ı ve etkisiz canary policy gerçek yükseltme uygulanmaz.

AWS-IAM-06 Rol aktarımı + servis oluşturma birleşimi. Bir principal’ın rolü bir servise aktarabilmesi (PassRole) tek başına değerlendirilmez; şunlarla kesişimi hesaplanır: function oluşturma/güncelleme; instance/task/job/notebook/build oluşturma; stack/deployment oluşturma; otomasyon dokümanı veya uzaktan komut; event target/scheduler/pipeline; container task definition. Bulgu: düşük yetkili principal’ın, kendi yetkisinden güçlü bir rolü, kontrol ettiği kodu çalıştıran servise aktarabilmesi.

AWS-IAM-07 Implicit privilege escalation. Yönetici eylemi içermeyen ama yüksek riskli yetkiler:

AWS-IAM-08 Cross-account erişim matrisi. Her trust ilişkisini şu sütunlarla kaydedin ve organization içi erişimi otomatik güvenli saymayın:

Kaynak hesap sınıfı → Hedef hesap sınıfı → Principal türü → Rol → Koşullar
→ Oturum süresi → Etkin izin → Erişilen veri → Alarm durumu

Özellikle development→production, workload→log arşivi ve vendor→yönetim rolü yollarını inceleyin.

AWS-IAM-09 Kullanılmayan ve gölge yetkiler. Uzun süredir kullanılmayan rol/policy, hiç assume edilmemiş roller, eski kişilere ait bağlar, aynı yöneticiliği veren çoklu yollar, acil durum rolünün normal işte kullanımı.

Aşama 4 Audit, configuration ve algılama

Önlemeyi test ettiğiniz kadar görebilmeyi de test edin ve güvenlik kayıtlarının saldırganın ulaşamayacağı bir güven alanında olduğunu doğrulayın.

AWS-LOG-01 Organization ve çok bölgeli audit. Tüm hesap/bölgeyi kapsayan organization trail, global service event’leri, gerekli data event kapsamı, log file validation, ayrı log arşiv hesabına teslim, teslim hatası/gecikme alarmı.

AWS-LOG-02 Log deposu koruması. Log bucket’ına yazan servis ile okuyan analist rolü ayrılır; workload hesapları log silememeli, lifecycle değiştirememeli, anahtarı devre dışı bırakamamalı. Versioning, Object Lock ihtiyacı, şifreleme, dar resource policy.

AWS-LOG-03 Kritik kontrol değişiklikleri. Şu işlemlerin hem kaydedildiğini hem alarma dönüştüğünü doğrulayın: trail durdurma/silme, config recorder değişikliği, threat detection kapatma, security service admin değişikliği, SCP/log bucket policy değişikliği, KMS disable/deletion schedule, public erişim gevşetme, root/break-glass kullanımı.

AWS-LOG-04 Configuration drift. Kritik kaynak türlerinin config geçmişi, yeni hesap/bölgenin otomatik kapsama girmesi, noncompliant kaynak için ticket/otomatik düzeltme ve bu düzeltmenin iş etkisi/geri dönüşü.

AWS-LOG-05 Detection doğrulaması. S2 hesabında benzersiz oturumla zararsız olaylar üretin: başarısız role assumption, reddedilmiş canary secret erişimi, public policy ekleme denemesi, izin verilmeyen bölge kullanımı, test SG’sine geniş kural ekleyip hemen geri alma, sentetik key için sınırlı anormal API örüntüsü. API olayı, merkezi log, detection, alarm, ticket ve sahibine ulaşma zamanı ayrı ölçülür.

Aşama 5 VPC, ağ ve edge güvenliği

Ağda tek bir kural değil, kaynak IP + route + NACL + hedef listener + host firewall birlikte değerlendirilir. Bir security group’un geniş olması tek başına internet erişilebilirliği kanıtı değildir ama savunma derinliği eksikliği olabilir.

• AWS-NET-01 VPC/subnet mimarisi: public/private/isolated/management ayrımı, route table ve IGW/NAT yolları, shared VPC/transit gateway/peering/VPN, overlapping CIDR, prod↔dev geçiş yolları.
• AWS-NET-02 Security group etkin erişim grafiği: 0.0.0.0/0 ve ::/0 kuralları, yönetim portları, SG referans zincirleri, geniş egress, sahipsiz gruplar, LB→uygulama→DB yolu.
• AWS-NET-03 NACL ve stateless davranış: inbound+outbound birlikte, ephemeral port aralıkları, IPv4/IPv6 eşdeğerliği, yanlış sıra numarası kaynaklı bypass.
• AWS-NET-04 VPC endpoint ve endpoint policy: private workload’ların public servis endpoint’ine çıkması, endpoint policy’nin yalnızca gerekli principal/kaynağa izin vermesi. Endpoint bulunması data perimeter sağlandığı anlamına gelmez; identity, resource ve endpoint policy birlikte test edilir.
• AWS-NET-05 Flow log kapsamı: kritik VPC/subnet/interface kapsamı, accept+reject kaydı, merkezi hedef, sorgulanabilirlik, flow log durdurma/silme yetkileri.
• AWS-NET-06 Load balancer ve TLS: şema seçimi, listener kuralları, HTTP→HTTPS yönlendirme, modern TLS policy ve sertifika yaşam döngüsü, backend yeniden şifreleme ihtiyacı, access log, sağlık kontrolü uç noktasının bilgi sızıntısı.
• AWS-NET-07 WAF/CDN/origin: WAF ilişkilendirmesi ve kapsamı, kural istisnaları, rate-based kontroller, CDN arkasındaki origin’e doğrudan erişimin engellenmesi, host header/cache davranışı. Aktif uygulama saldırısı varsayılan kapsam değildir; cloud-side kontrol zincirinin yerleşimi ve güvenli canary isteklerine verdiği sonuç ölçülür.
• AWS-NET-08 DNS ve sertifika: public/private zone ayrımı, dangling alias/terk edilmiş kayıt, zone delegation yetkileri, DNSSEC ihtiyacı, sertifika doğrulama kayıtları ve otomatik yenileme, wildcard sertifika kullanımı.

Aşama 6 Compute ve instance güvenliği

• AWS-EC2-01 Public maruziyet: public IP/IPv6, public subnet route, SG/NACL yolu, LB arkasında olması beklenen instance’a doğrudan erişim, yönetim portlarının kaynak ağı.
• AWS-EC2-02 Instance Metadata Service: token zorunluluğu (IMDSv2), hop limit, metadata endpoint’in gerçekten gerekmesi, container/reverse proxy senaryolarında erişim. Aktif SSRF doğrulamasında gerçek uygulama ve credential kullanılmaz; sentetik instance profile ve yalnızca canary kaynağa erişen test endpoint’i kullanılır, temporary credential kanıta alınmaz.
• AWS-EC2-03 Instance profile ve rol kapsamı: her instance’ın role ihtiyacının gerekçesi, aynı rolün farklı güven seviyelerinde paylaşılması, secret/decrypt/object/remote-management izinleri, role assumption ve cross-account erişim.
• AWS-EC2-04 User data, launch template, image: user data içinde secret/token bulunmaması, launch template değişiklik yetkileri, image sahibi/paylaşımı/güncelliği/provenance, yeni instance’ın güvenlik temelini otomatik alması.
• AWS-EC2-05 Disk ve snapshot: varsayılan EBS şifrelemesi, volume/snapshot anahtarları, public/cross-account snapshot paylaşımı, kopyalama/dışa çıkarma yolları, silinen instance sonrası volume kalıcılığı. Gerçek snapshot restore edilmez; S2 sentetik disk ve canary dosyayla yapılır.
• AWS-EC2-06 Uzaktan yönetim ve patch: doğrudan SSH/RDP yerine merkezi ve kayıtlı oturum, oturum loglarının ayrı hesaba gitmesi, patch baseline ve uyumsuz/yönetim dışı instance’lar.
• AWS-EC2-07 Yaşam döngüsü: termination/stop protection, auto scaling health replacement, kullanılmayan elastic IP/volume/snapshot/image temizliği.

Aşama 7 Object storage (S3) güvenliği

Public erişim tek bir ayar değil, katmanlı bir karardır. Şu katmanları birlikte inceleyin: account-level public access block, bucket-level public access block, bucket policy, bucket/object ACL, access point ve multi-region access point policy, website hosting, organization/VPC endpoint koşulları. Public access analyzer sonucu tek başına yeterli değildir; anonim canary nesne isteği yalnızca açık test bucket’ında ve S2 onayıyla yapılır.

• AWS-S3-02 Bucket policy: wildcard/cross-account principal, secure transport zorunluluğu, organization/source VPC/source ARN/principal tag koşulları, deny guardrail’leri, yanlış veya kontrol edilebilir context key.
• AWS-S3-03 Şifreleme ve anahtar etkisi: varsayılan SSE, kurum yönetimli anahtar gereken veri sınıfları, upload’ta şifreleme zorunluluğu, replication/inventory çıktısının şifrelenmesi, KMS key policy’nin bucket politikasını aşan erişim oluşturması.
• AWS-S3-04 Versioning, Object Lock, silme direnci: delete marker davranışı, Object Lock ihtiyacı, lifecycle’ın eski sürümleri silmesi, replication/backup ve aynı principal’ın veri ile korumayı birlikte silebilmesi (ransomware senaryosu).
• AWS-S3-05 Kritik bucket sınıfları: audit log, IaC state, CI/CD artefaktı, yedek ve hassas veri bucket’larında okuma/yazma/policy-lifecycle/anahtar yönetimi farklı principal’lara ayrılmalı.
• AWS-S3-06 Event notification saldırı yüzeyi: notification config değiştirme, hedef function/queue/topic resource policy’si, SourceArn/SourceAccount doğrulaması, event filtre kapsamı, hedef execution role yetkisi. S2’de test bucket’ı, sabit çıktı üreten test hedefi ve canary rol; production notification değiştirilmez.
• AWS-S3-07 CORS, presigned URL, access log: geniş origin/method kombinasyonları, presigned URL süresi/yetki kaynağı, access log hedefinin yazma/okuma ayrımı, object ownership, hassas object adlarının loglara yansıması.

Aşama 8 KMS ve kriptografik sınırlar

Decrypt izni tek başına bir bulgu değildir; asıl soru bu iznin bir veri yoluna bağlanıp bağlanmadığıdır:

Principal → decrypt/grant yetkisi → anahtar
         → bu anahtarla şifrelenen kaynaklar
         → ciphertext veya kaynağı okuma yetkisi
         → gerçek veri etkisi

Ciphertext’e erişemeyen principal ile secret/object/snapshot/database verisine de erişebilen principal’ın riski aynı değildir.

• AWS-KMS-01 Key policy ve etkin principal: key policy + IAM policy + grant’ler birlikte çözülür; account root principal kullanımının IAM’e ne ölçüde yetki devrettiği anlaşılır; wildcard/cross-account ve yönetici-kullanıcı ayrımı.
• AWS-KMS-03 Koşullar ve data perimeter: ViaService, encryption context, caller account/organization/alias koşulları; direct decrypt gerekliliği; çok bölgeli anahtar ve replica policy tutarlılığı.
• AWS-KMS-04 Grant yönetimi: grant create/retire/revoke yetkileri, grant constraint kullanımı, servis kaynaklı geçici grant’ler, kullanılmayan/geniş grant’ler.
• AWS-KMS-05 Yaşam döngüsü ve görev ayrılığı: rotation, disable/deletion schedule yetkileri, anahtar yöneticisi ile veriyi çözen kullanıcının ayrılması, yedek/log anahtarlarının workload hesaplarından korunması. Aktif decrypt testi production anahtarı/ciphertext’iyle yapılmaz; ayrılmış test anahtarı ve canary ciphertext kullanılır.

Aşama 9 Secret ve configuration verisi

• AWS-SEC-01/02 Envanter ve resource policy: secret sahibi, kullanan workload, rotation planı, replication ve KMS ilişkisi; wildcard/beklenmeyen principal, organization/source koşulları, resource policy ile identity policy kesişimi, harici hesabın anahtarı da kullanabilmesi.
• AWS-SEC-03 Rotation’ın gerçek davranışı: “rotation enabled” etiketiyle yetinmeyin; son başarılı rotation, başarısız denemeler, eski credential’ın iptali ve uygulamanın yeni değeri kullanması doğrulanır.
• AWS-SEC-04 Yanlış yerde tutulan secret: function environment variable, instance user data, image katmanı, build logu, IaC state, object metadata/tag, düz metin configuration. Bulunan değerler kanıta kopyalanmaz; yalnızca konum, tür ve rotasyon ihtiyacı kaydedilir.
• AWS-SEC-05 Canary secret doğrulaması: sentetik secret yalnızca belirlenen test rolünce okunabilmeli; düşük yetkili insan rolü, başka workload rolü ve harici hesap reddedilmeli. Alarm zinciri hem başarılı hem reddedilmiş erişim için ölçülür.

Aşama 10 Managed database ve veri servisleri

PubliclyAccessible: false tek başına private erişim kanıtı değildir; peering, transit ve shared network yolları hesaba katılır.

• AWS-DB-01 Public erişilebilirlik: publicly accessible + subnet route + SG/NACL + DNS + proxy yolu birlikte.
• AWS-DB-02/04 Şifreleme ve TLS: instance/storage/log/replica/snapshot/export şifrelemesi, KMS erişimi, client TLS zorunluluğu, sertifika doğrulama, güvenlik parametreleri, varsayılan parameter group.
• AWS-DB-03 Kimlik doğrulama: statik admin parolası kullanımı, IAM/database authentication, secret rotation, master user sınırı, uygulama rolü ayrıcalıkları.
• AWS-DB-05 Snapshot/export paylaşımı: public snapshot, cross-account paylaşım, export hedefi/role, restore ile erişilebilecek veri sınıfı. Production snapshot restore edilmez; sentetik verili test DB’si kullanılır.
• AWS-DB-06/07 Backup ve NoSQL/cache: retention/PITR/deletion protection, multi-AZ, cross-region/account backup, restore tatbikatı; NoSQL/cache için resource policy, stream tüketicileri, şifreleme/TLS, public/peered yol, cache authentication.

Aşama 11 Serverless ve event-driven mimari

• AWS-SRV-01 Execution role: her function ayrı ve minimum yetkili role; aynı rolün farklı veri sınıfları arasında paylaşılmaması; secret/decrypt/network/cross-account yetkileri; trust policy.
• AWS-SRV-02 Invoke ve resource policy: public function URL/API integration, wildcard principal, SourceArn/SourceAccount, cross-account invoke, async destination erişimi.
• AWS-SRV-03 Kod/config değiştirme yetkisi: code/layer/env/handler/runtime güncelleme yetkilerinin execution role ile birleşimi, code signing ve artefakt provenance, deployment principal sınırı.
• AWS-SRV-04/05/06 Environment, concurrency, VPC: env’de secret, paylaşılan layer sahipliği, geçici depoda veri kalıntısı; reserved concurrency, retry/DLQ, recursive invocation koruması, timeout/memory ve sınırsız event’in maliyet/availability etkisi; function’ın VPC ihtiyacı ve egress yolu.
• AWS-SRV-07 Event source güveni: kaynakların kimliği, event filter kapsamı, replay/duplicate davranışı, poison message/DLQ yolu, hedef role ve resource policy.

Aşama 12 Messaging ve entegrasyon

• AWS-MSG-01/02 Queue ve topic policy: public/cross-account send-receive-publish-subscribe, SourceArn/SourceAccount, TLS zorunluluğu, SSE, onaysız harici subscription, DLQ erişimi, filter davranışı.
• AWS-MSG-03 Event bus ve rule: cross-account PutEvents, event bus resource policy, rule/target değiştirme yetkisi, target role aktarımı, archive/replay yetkileri, event içeriğinde secret.
• AWS-MSG-04 Event injection doğrulaması: S2’de sentetik event yalnızca test bus/queue/topic’a; hedef sabit canary çıktı üretir; production consumer/veri/target role kullanılmaz.

Aşama 13 Container ve artefakt servisleri

Bu bölüm AWS kontrol düzlemine odaklanır; küme içi ayrıntılar ayrı Kubernetes playbook’uyla yürütülür.

• AWS-CON-01 Registry: repository policy ve cross-account pull/push, tag immutability, scan-on-push, lifecycle, encryption/replication, public repository kullanımı.
• AWS-CON-02 Rol ayrımı: control/agent execution role ile application task role ayrılır; secret/registry erişimi yalnızca gerekli role; task definition güncelleme + rol aktarımı birleşik etkisi.
• AWS-CON-03 Runtime ve ağ: public IP, network mode/SG, privileged/capability, host volume/socket, read-only root fs, log/secret injection.
• AWS-CON-04 Cluster kontrol düzlemi: endpoint erişimi, control plane logları, workload identity trust koşulları, node role kapsamı, cluster/node group yetkileri.

Aşama 14 Backup, felaket kurtarma ve silme direnci

• AWS-BCK-01/02 Plan ve vault: kritik kaynakların plana dahil olması, tag/selection hataları, retention/lifecycle, cross-region/account copy; vault policy, Vault Lock ihtiyacı, recovery point silme yetkisi, backup operator ile workload admin ayrımı, anahtar silmenin yedekleri de etkileyip etkilemediği.
• AWS-BCK-03 Restore testi: restore yalnızca “job completed” ile başarılı sayılmaz. Ayrılmış ağda sentetik veriyle veri bütünlüğü, uygulama tarafından kullanılabilirlik, gerekli KMS erişimi, DNS/dependency davranışı ve RTO/RPO doğrulanır.
• AWS-BCK-04 Ransomware senaryosu: aynı principal’ın production verisini, snapshot’ı, recovery point’i, logları ve KMS anahtarını birlikte silebilip silemediği grafik üzerinde analiz edilir. Aktif silme yapılmaz.

Aşama 15 Tedarik zinciri ve infrastructure as code

• AWS-SC-01 CI/CD kimliği: uzun ömürlü key yerine federated workload identity, repository/branch/environment koşulları, pipeline rolü ile deployment rolü ayrımı, cross-account deployment trust, session tag ile izlenebilirlik.
• AWS-SC-02 Artefakt bütünlüğü: build çıktısının provenance’ı, imza/digest doğrulaması, artefakt yazma yetkileri, aynı principal’ın hem build hem onay hem production deploy yapmaması, mutable artefakt kullanımı.
• AWS-SC-03/04 State ve stack rolleri: state şifreleme/kilit/versioning, state okuma-yazma principal’ları, plan dosyalarında secret; stack execution role, template/parameter güncelleme yetkisinin birleşik etkisi, custom resource/macro trust, deletion protection/rollback davranışı.

Aşama 16 Maliyet ve kaynak kötüye kullanımı

• AWS-COST-01 Bütçe ve anomali: hesap/proje/servis bazında bütçe, maliyet anomali alarmı, alarm sahibinin güncelliği, yeni bölge/pahalı servis kullanımına tepki süresi.
• AWS-COST-02 Oluşturma sınırları: büyük instance/GPU/yüksek concurrency/data transfer maliyeti yaratabilecek izinler, service quota ve guardrail’ler, otomatik sona erme kuralları. Aktif maliyet testi S4’tür ve düşük bütçe, kısa süre, otomatik durdurma olmadan yapılmaz.

---

5. Servisler arası saldırı yolu senaryoları

Tekil bulguları test etmeyi öğrendikten sonra asıl beceri onları zincirlemektir. Amaç hesabı ele geçirmek değil, izinlerin birleşik etkisini minimum ve geri alınabilir kanıtla göstermektir.

Senaryo 1 Rol aktarımı → servis → daha güçlü çalışma kimliği. Düşük yetkili principal’ın aktarabileceği roller ve oluşturabildiği kod-çalıştıran servis kaynakları hesaplanır; S2’de yalnızca canary object okuyabilen sentetik rol kullanılır; workload canary erişimini doğrulayıp sona erer; kaynaklar kaldırılır. Kök neden: PassRole izni rol ARN’i ve hedef servis koşullarıyla sınırlandırılmamış, kaynak oluşturma izniyle birleşmiştir.

Senaryo 2 Object event’i → function → execution role. Notification değiştirme + object yazma kesişimi çıkarılır; hedef function resource policy’sinin kaynak koşulları incelenir; S2’de test bucket/function/canary rol; sentetik olay sabit canary log üretir; production değiştirilmez.

Senaryo 3 KMS decrypt → şifreli veri. Principal’ın kullanabildiği anahtarlar ve bunlarla şifrelenmiş, principal’ın okuyabildiği kaynaklar eşleştirilir; production verisi yerine test anahtarıyla üretilmiş canary ciphertext kullanılır; decrypt başarılı olunca veri yolu kanıtlanır.

Senaryo 4 Instance metadata → temporary role → yanal erişim. Token/hop-limit ayarları salt okunur incelenir; instance profile’ın eriştiği kaynaklar çıkarılır; S2’de sentetik instance, canary role, canary object; temporary credential kaydedilmez, yalnızca canary erişimi doğrulanır.

Senaryo 5 Function güncelleme → execution role. Function code/config güncelleyebilen principal’lar ve execution role etkisi belirlenir; production function değiştirilmez; aynı permission pattern S2’de sentetik function/canary role ile doğrulanır.

Senaryo 6 Stack/template kontrolü → deployment role. Stack oluşturma/güncelleme + execution role aktarımı birlikte analiz edilir; sentetik stack yalnızca otomatik silinen düşük etkili canary kaynak oluşturur; rollback ve tüm bağımlı kaynakların silindiği doğrulanır.

Senaryo 7 Resource policy → cross-account veri erişimi. Resource policy yazabilen principal ve harici erişimi engelleyen guardrail’ler incelenir; iki ayrılmış test hesabı arasında canary object/secret kullanılır; kanıttan sonra policy/kaynak hemen kaldırılır.

Senaryo 8 Snapshot paylaşımı → veri kopyalama. Snapshot attribute değiştirme + KMS erişimi birlikte hesaplanır; production snapshot kullanılmaz; sentetik verili test snapshot’ı ayrılmış hesaba paylaşılır, canary bütünlüğü doğrulanıp kopyalar silinir.

Senaryo 9 Log korumasını aşma. Workload admin’inin trail/destination/log bucket/lifecycle/KMS yetkileri çıkarılır; production loglaması durdurulmaz; ayrılmış test trail’inde engellenmesi beklenen değişiklik denenir; explicit deny + audit olayı + alarm birlikte kaydedilir.

---

6. Risk derecelendirme

Şiddeti API action’ın adına göre değil, şu boyutları birlikte değerlendirerek verin:

Aynı teknik bulgu bağlama göre farklı derecelenir: PassRole tek başına kritik değildir, güçlü bir rol ve saldırganın kodunu çalıştıran servisle birleşince kritik olur. Decrypt ciphertext erişimi olmadan sınırlıdır, secret/object/snapshot okumayla birleşince yükselir. Public IP tek başına doğrulanmış açıklık değildir; route, SG, listener ve uygulama kimlik doğrulamasıyla birlikte değerlendirilir. Yönetici rolündeki wildcard bir tasarım kararı olabilir; aynı wildcard’ın düşük yetkili role verilmesi apayrı bir bulgudur.

---

7. Geri dönüş ve kapanış

Test, ortam başladığı hal kadar temiz bırakılınca biter. AWS’te bu, birden çok bölgeyi ve gizli bağımlılıkları taramayı gerektirir:

1. Aktif test isteklerini ve event üretimini durdurun.
2. Scheduler, rule, target, subscription, notification bağlantılarını kaldırın.
3. Function, task, instance, stack ve diğer compute kaynaklarını sonlandırın.
4. Geçici role, policy, trust, grant ve resource policy değişikliklerini geri alın.
5. Canary secret, object, key, queue, log group ve database kaynaklarını silin.
6. Snapshot, image, backup, replica ve cross-account kopyaları kontrol edin.
7. SG, endpoint, DNS, certificate ve load balancer bağımlılıklarını kaldırın.
8. Test access key, session, certificate ve federated assignment’ları iptal edin.
9. Etiket envanteriyle tüm bölgelerde kalan test kaynaklarını tekrar arayın.
10. Faturalama, audit, config ve detection kayıtlarını başlangıç baz çizgisiyle karşılaştırın.

Bir stack’in silinmiş görünmesi geri dönüşün tamamlandığını göstermez. Retain policy, deletion protection, snapshot, log group, network interface, elastic IP, secret replica, KMS deletion schedule ve cross-account kopyalar ayrıca doğrulanmalıdır.

Kapanış ölçütleri: her test bir durumla kaydedildi; kapsam tüm hesap/bölge/global servisler için ölçüldü; her FAIL için gerçek veri kullanmadan tekrar üretilebilir kanıt var; her BLOCKED’ın nedeni ve görünürlük etkisi yazıldı; canary/geçici kaynakların kalmadığı envanter ve audit üzerinden doğrulandı; beklenmeyen maliyet/servis etkisi oluşmadı; kanıtlar maskelenip saklama süresi belirlendi; bulgulara sahip ve hedef tarih atandı; kritik yollar için kısa vadeli telafi tanımlandı; yeniden test ölçütleri API kararı veya algılama sonucu olarak açıklandı.

---

Son söz

İyi bir AWS pentesti, yüzlerce yapılandırma sonucunu yan yana koymakla değil, bu sonuçların bir saldırgan açısından nasıl birleştiğini göstermekle değer kazanır. En yararlı çıktı; bir principal’ın başlangıç erişiminden hangi policy, trust, servis rolü, event ve veri yoluyla daha yüksek etkiye ulaşabileceğini, zincirin hangi halkasında güvenle durdurulabileceğini ve düzeltmenin nasıl ölçüleceğini açıkça ortaya koyar. Çünkü sonuçta test ettiğimiz şey, iznin tanımı değil; kararıdır.

---

Bu playbook, Red in Pulse ekibinin AWS güvenlik değerlendirmelerinde izlediği yaklaşımın çerçevesidir: tanımlı izinleri değil etkin kararları ölçen, saldırı yollarını canary ve dry-run disipliniyle güvenle doğrulayan, ortamı ve maliyeti başladığı hal kadar temiz bırakan bir metodoloji. Ortamınızın gerçek etkin yetki sınırlarını sadece policy’lerinin varlığını değil bu titizlikte test ettirmek isterseniz, kapsam görüşmesi için bizimle iletişime geçebilirsiniz.