Amazon S3 (Simple Storage Service), modern bulut depolamanın temel taşıdır; statik web sitesi varlıklarından petabaytlarca kritik iş verisine kadar her şey için neredeyse sonsuz bir depo sunar. Ölçeklenebilirliği, dayanıklılığı ve maliyet etkinliği, onu geliştiriciler, veri bilimciler ve işletmeler için vazgeçilmez bir araç hâline getirmiştir. S3’ü devasa, dijital bir Fort Knox olarak hayal edin; hazinelerini korumak için katmanlı savunmalarla son derece güvenli olabilir. Ancak her kale gibi, güvenliği yalnızca yapılandırmalarının doğruluğu kadar güçlüdür. Tek bir yanlış yapılandırılmış izin, gözden kaçmış bir politika veya ele geçirilmiş bir kimlik bilgisi, arka kapıyı açabilir ve dijital kasanızı saldırganın oyun alanına dönüştürebilir.

Bu makale, sadece bir S3 en iyi uygulamaları listesi değildir. S3 güvenliği için süregelen mücadeleyi iki perspektiften anlatır: Red Team’den kararlı bir saldırgan olan Alex ve Blue Team’den dikkatli bir savunmacı olan Blake. Saldırganların S3 kovalarını keşfetmek, istismar etmek ve veri çıkarmak için kullandıkları gölgeli taktikleri inceleyeceğiz. Ardından savunmacının bakış açısına geçerek, AWS’in zengin güvenlik araçlarını kullanarak çok katmanlı bir savunma stratejisini detaylı şekilde inşa edeceğiz.

Saldırı ve savunmaya geçmeden önce, S3’ü hem güçlü hem de karmaşık bir güvenlik sorunu yapan özelliklerini anlayalım.

Temel S3 Kavramları:

Buckets (Kovalar): S3’teki temel konteynerler. Kova adları global olarak benzersiz olmalıdır.
Objects (Objeler): S3’te depolanan veri (dosyalar) ve metadata’ları. Objeler birkaç bayttan terabaytlara kadar olabilir.
Keys (Anahtarlar): Bir kovadaki objelerin benzersiz tanımlayıcıları (temel olarak dosya yolu).
Regions (Bölgeler): S3 kovaları belirli AWS bölgelerinde oluşturulur; bu gecikme, maliyet ve düzenleyici uyumluluğu etkiler.

S3’ün Temel Özellikleri ve Güvenlik Etkileri:

Özellik	Açıklama	Yanlış Yönetildiğinde Güvenlik Etkisi
Versioning (Sürümleme)	Bir objenin birden fazla versiyonunu saklar.	Kazara silinmelere karşı korur, ancak kötü amaçlı dosyaları da koruyabilir. Yönetilmezse depolama maliyeti artar.
Server-Side Encryption (Sunucu Taraflı Şifreleme)	Veriyi SSE-S3, SSE-KMS veya SSE-C ile şifreler.	Şifrelenmemiş kovalar yetkisiz erişime açık olur. KMS anahtar yönetimi kritik önemdedir.
Access Control Lists (ACLs)	Kova ve obje seviyesinde temel okuma/yazma izinleri sağlar.	Yanlış yapılandırıldığında istemeden halka açık erişim verebilir. Bucket policy’de explicit Deny tarafından geçersiz kılınabilir.
Bucket Policies	JSON tabanlı politikalarla kovadaki kaynaklara ince ayarlı erişim kontrolü sağlar.	Karmaşık politikalar denetlenmesi zor olabilir. Hatalar aşırı izin veya meşru erişimin engellenmesine yol açabilir.
IAM Policies	IAM kullanıcıları, grupları ve roller için S3 ve diğer AWS servislerine erişimi kontrol eder.	Aşırı izinler ihlallerin başlıca sebebidir.
S3 Block Public Access	Hesap veya kova seviyesinde, ACL ve policy’ler üzerinden halka erişimi engeller.	Etkin değilse, ACL veya policy’ler veri sızıntısına yol açabilir.
S3 Object Lock	Write-Once-Read-Many (WORM) koruması sağlar; objelerin silinmesini veya üzerine yazılmasını önler.	Retention sürelerini yönetmek karmaşık olabilir; belirli izinlere sahip kullanıcılar Governance modunu aşabilir.
Logging (Server Access & CloudTrail)	Kova isteklerini (Server Access Logs) ve API çağrılarını (CloudTrail) kaydeder.	Etkin değilse veya doğru analiz edilmezse saldırılar fark edilmeyebilir. Logların kendisi de korunmalıdır.
Pre-signed URLs	Objeler için zaman sınırlı geçici URL’ler oluşturur.	Sızdırılırsa yetkisiz erişim sağlar. Kısa süreli ve minimum izinli olması gerekir.
S3 Access Points	Paylaşılan veri setlerine erişim için benzersiz host isimleri ve ayrı izinler sağlar.	Erişimi kolaylaştırır ama ek yapılandırma katmanı ekler.
S3 Object Lambda	S3 GET, HEAD ve LIST isteklerini değiştirip işlemek için kendi kodunuzu eklemenizi sağlar.	Lambda fonksiyonlarındaki kod açıkları güvenlik riskleri yaratabilir.

Neden S3 Hedef Alınır?

Saldırganlar S3’e çeşitli nedenlerle ilgi duyar:

Veri Zenginliği: Kişisel bilgiler, finansal kayıtlar, fikri mülkiyet, kimlik bilgileri, yedekler ve uygulama kodları içerir.
Yanlış Yapılandırma Yaygınlığı: Esneklik ve geçmişteki karmaşık erişim kontrolleri nedeniyle hatalar sık görülür.
Halka Açıklık Potansiyeli: İnternet üzerinden erişilebilir olması yanlış yapılandırılmış kovalarda global veri sızıntısı riski yaratır.
Otomasyon & Ölçeklenebilirlik: Saldırganlar, açık kovaları taramak ve istismar etmek için script ve araçlar kullanır.

Saldırganımız Alex metodiktir. Alex, başarılı bir S3 ihlalinin genellikle sabırlı keşif ve ince yapılandırma hatalarını fark etme ile başladığını bilir. Hedef organizasyonla ilişkili S3 kovalarını belirleyip zayıf noktaları test etmeyi amaçlar.

Bu metni takip eden aşamalar şunları hedefler:

Gelişmiş S3 Açıklarını Anlamak: Yaygın ve sofistike yanlış yapılandırmaları ve etkilerini kavramak.
Saldırgan Yöntemlerini Öğrenmek: Saldırganların S3 kovalarını nasıl keşfettiğini, eriştiğini ve kullandığını anlamak.
Sağlam Savunma Stratejileri Uygulamak: IAM, bucket policies, şifreleme, logging, monitoring ve diğer AWS servislerini kullanarak S3’ü güvence altına almak.
Gerçekçi Senaryoları İncelemek: Detaylı ihlal ve müdahale senaryolarını analiz etmek.
Pratik Araç ve Komutları Kullanmak: AWS CLI komutları, policy örnekleri ve üçüncü taraf araçlarla S3 güvenliğini yönetmek.
Sürekli Gözetimin Önemini Kavramak: S3 güvenliği tek seferlik bir kurulum değil, sürekli bir süreçtir.

resim

1.1. Halka Açık Bilinen Kova İsimleri ve Permütasyonlar

Birçok organizasyon öngörülebilir adlandırma kuralları kullanır (örn. companyname-assets, companyname-backup).
Alex, araçlar ve wordlist’ler kullanarak bu adların permütasyonlarını üretir ve test eder.

1.2. Google Dorking

Alex, gelişmiş Google aramalarıyla halka açık kova URL’lerini veya kamuya açık belgelerdeki referanslarını bulmaya çalışır.

Örnek sorgular:

site:s3.amazonaws.com companyname
inurl:.s3.amazonaws.com filetype:bak OR filetype:sql OR filetype:config
intitle:"index of /" "bucket-name"

(Block Public Access nedeniyle bu son yöntem artık daha az yaygın.)

1.3. Sertifika Şeffaflık (CT) Logları

Bir kova HTTPS ile web sitesi barındırıyorsa, adı Certificate Transparency (CT) loglarında görünebilir.

Araçlar:

ctfr.py, certstream

Örnek kullanım:

python ctfr.py -d '*.s3.amazonaws.com' -o ct_s3_logs.txt

1.4. DNS Keşfi ve Alt Alan Adı Taraması

Statik web barındırmak için kullanılan kovalar genellikle CNAME kayıtları ile onlara yönlendirilir.

Araçlar: dnsrecon, subfinder, amass

subfinder -d targetcompany.com | grep 's3.amazonaws.com'

1.5. Web Sayfaları ve Mobil Uygulamaların Analizi

İstemci tarafı kodu (JavaScript, mobil uygulama binary’leri) bazen hardcoded S3 kova adları veya URL’leri içerir.
Alex; decompiler’lar, Burp Suite gibi proxy araçları ve tarayıcı geliştirici araçlarını kullanır.

1.6. GitHub & Kamuya Açık Kod Depoları

Geliştiriciler bazen yanlışlıkla kova isimlerini, erişim anahtarlarını veya pre-signed URL oluşturma mantığını commit eder.

Araçlar: git-secrets, truffleHog, GitHub aramaları
Örnek GitHub sorgusu:

"s3.amazonaws.com" org:targetcompany language:javascript

1.7. Shodan / Censys

Shodan ve Censys gibi arama motorları, özellikle S3 bir web uygulaması altyapısının parçasıysa, kova bilgilerini ortaya çıkarabilir.

Örnek sorgular:

hostname:.s3.amazonaws.com org:"Target Company"

ya da
HTTP başlıkları / içerikleri üzerinden S3’e işaret eden kayıtlar.

Kullanılan Araçlar

S3Scanner:

s3scanner scan --buckets-file company-bucket-names.txt

Lazys3: Ruby script, kova permütasyonları için.
curl ile Manuel Kontrol:

curl -s -I "http://<bucketname>.s3.amazonaws.com" | grep "HTTP/1.1 301 Moved Permanently"

Alex’in Günlüğü

“DNS keşfi ve GitHub analiziyle birkaç potansiyel kova adı buldum.
Bunlardan biri acme-corp-dev-backups. İçeriği hemen listelemedi ama adı bile bir ipucu.”

MITRE ATT&CK TTP Eşlemesi

T1596.005 (Active Scanning): S3Scanner gibi araçlarla aktif tarama.
T1593.002 (Search Open Websites/Domains): Google Dorking, Shodan kullanımı.
T1590 (Gather Victim Network Information): DNS keşfi.

resim

İlk Erişim Başlangıcı – Potansiyel Kovaları Test Etme

2.1. Halka Açık Listeleme/Okuma Hatalarının İstismarı

Bu en kolay zaferdir. Eğer bir kova anonim listeleme ve okuma izni veriyorsa, Alex sadece AWS CLI veya s3browser gibi araçları kullanabilir.
--no-sign-request çalışıyorsa, kova public’tir.

Komutlar:

# Halka açık kova nesnelerini listele
aws s3 ls s3://acme-corp-dev-backups --no-sign-request  

# Halka açık kovadan dosya indirme
aws s3 cp s3://acme-corp-dev-backups/latest_db_dump.sql.gz ./ --no-sign-request

2.2. Yanlış Yapılandırılmış ACL’ler

Kova tam anlamıyla public olmasa bile, ACL’ler “Authenticated Users” (herhangi bir AWS hesabı ile giriş yapan kullanıcı) veya spesifik harici hesaplara erişim verebilir.
Alex, kendi AWS hesabıyla deneyerek bu erişimleri test edebilir.

Komut (örnek):

aws s3api get-bucket-acl --bucket acme-corp-dev-backups

2.3. Sızdırılmış Kimlik Bilgileri / IAM Anahtarları

Eğer Recon aşamasında Alex, GitHub gibi yerlerde AWS Access Key (AKIA…) ve Secret Key bulduysa bu doğrudan giriş yoludur.

Konfigürasyon:

aws configure --profile hacked_profile  
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE  
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY  
Default region name [None]: us-east-1  
Default output format [None]: json

Kullanım:

aws s3 ls s3://some-target-bucket --profile hacked_profile

2.4. Önceden İmzalanmış (Pre-signed) URL’lerin İstismarı

Pre-signed URL’ler belirli S3 işlemleri için zaman sınırlı geçici kimlik bilgileridir.
Alex şunları yapabilir:
- Intercept (Yakalama): Web trafiğinde veya loglarda pre-signed URL’leri ele geçirme.
- Parameter Tampering: Güvensiz oluşturulan URL’lerde parametrelerle oynama (ör. object key değiştirme).
- Long Expiry: Çok uzun süreli geçerli URL bulursa, uzun süreli bir giriş noktası haline gelir.

📓 Alex’in Günlüğü

“acme-corp-dev-backups kovası halka açık listelenebilir değildi. Ama kendi AWS hesabımla denediğimde, listeleme için Access Denied aldım.
Buna rağmen şu çalıştı:

aws s3api head-object --bucket acme-corp-dev-backups --key config/db.yaml

Bu da nesne seviyesinde anonim okuma ya da özel ACL hatası demekti.
db.yaml eski veritabanı kimlik bilgilerini içeriyordu. Bingo! 🎯”

MITRE ATT&CK Eşlemesi

T1078 (Valid Accounts): Sızdırılmış kimlik bilgilerini kullanma.
T1190 (Exploit Public-Facing Application): Halka açık S3 kovalarına erişim.
T1550.003 (Adversary-in-the-Middle): Pre-signed URL’lerin yakalanması / manipülasyonu.

Yani bu aşama saldırganın ilk erişim için üç temel yolu gösteriyor:

Public bucket’lar,
Yanlış ACL konfigürasyonu,
Sızdırılmış kimlik bilgileri / pre-signed URL kötüye kullanımı.

resim

S3 Post-Exploitation (Saldırı Sonrası) Aşamaları ve Savunma

Saldırganın Adımları (Alex)

3.1. Nesnelerin ve Yapının Keşfi (Enumeration)

Eğer listeleme (list) yetkisi varsa, Alex bucket’ın içeriklerini ve dizin yapısını haritalandırır.

aws s3 ls s3://acme-corp-internal-docs --recursive --profile hacked_profile

3.2. Hassas Verilerin İndirilmesi

Ana hedef genellikle veri hırsızlığıdır (data theft).

aws s3 sync s3://acme-corp-pii-archive ./leaked_pii_data --profile hacked_profile

3.3. Kötü Amaçlı Dosya Yükleme (Write Access varsa)

Alex yazma izni bulursa şunları yükleyebilir:

Webshell: Eğer bucket bir web uygulamasına hizmet ediyorsa
Malware: Bucket’tan veri tüketen sistemleri enfekte etmek için
Phishing içerikleri: Şirketin alan adını kullanarak sahte içerikler barındırmak için

aws s3 cp evil.php s3://acme-corp-webapp-bucket/uploads/evil.php --profile hacked_profile

3.4. Mevcut Nesneleri Manipüle Etme (Data Integrity Attack)

Alex mevcut dosyaları indirip, değiştirip tekrar yükleyebilir:

aws s3 cp s3://acme-corp-config-bucket/app_settings.json ./ --profile hacked_profile
# Dosya lokal olarak değiştirilir...
aws s3 cp ./app_settings.json s3://acme-corp-config-bucket/app_settings.json --profile hacked_profile

3.5. Yetki Yükseltme (Privilege Escalation)

IAM Role Trust Abuse: EC2 veya Lambda gibi servislerin bucket’tan kod/config okuduğu senaryolarda Alex dosyaları manipüle ederek yetki kazanabilir.
EC2 User Data Scripts: S3 üzerinde saklanan kullanıcı veri scriptlerini değiştirerek yeni başlatılan EC2 instance’larında komut çalıştırabilir.

3.6. Veri Sızdırma (Data Exfiltration)

Doğrudan İndirme: Sync veya cp ile
Cross-Account Replication: Bucket’ı kendi kontrolündeki bir bucket’a replike edecek şekilde ayarlamak
S3’ü C2 Kanalı Olarak Kullanma: Komutları bir objeye yazıp çıktıları başka bir objeden alma (nadiren kullanılır ama mümkündür).

3.7. İzleri Gizleme (Covering Tracks)

Server Access Logs silmek: Çok zor, genellikle ayrı bucket’a yönlendirilir.
CloudTrail manipülasyonu: Yüksek ayrıcalık gerekir (StopLogging, DeleteTrail). Daha yaygın taktik hızlı exfiltration ve normal trafiğe karışmaktır.

MITRE ATT&CK Eşleştirmesi

T1530: Bulut depolama nesnesinden veri çekme
T1078.004: Ele geçirilmiş cloud hesaplarını kullanma
T1526: Cloud servis keşfi
T1098.002: Cloud instance metadata API istismarı (EC2 pivot)
T1567: Web servisi üzerinden veri sızdırma (S3 API kullanımı)

Savunmacının Adımları (Blake)

Blake’in misyonu, S3 üzerinde derinlemesine savunma (defense-in-depth) stratejisi uygulamak.

IAM ve S3 Güvenliği

IAM Kullanıcıları, Grupları, Roller
- Root User asla kullanılmaz.
- İnsan kullanıcıları için IAM User açılır.
- Yetkiler gruplara atanır, kullanıcılar gruplara eklenir.
- Servisler (EC2, Lambda vb.) için IAM Roles kullanılır (Access Key değil).

Bucket Policy vs IAM Policy

Bucket Policy: Kaynak bazlı (resource-based), bucket’a doğrudan eklenir.
- Çapraz hesap (cross-account) erişimi için ideal.
- IP veya VPC kısıtlamaları için uygundur.
IAM Policy: Kimlik bazlı (identity-based).
- Kullanıcı, grup veya role atanır.
- Birden çok servisi kapsayan yetkiler için uygundur.

Değerlendirme Mantığı:

Explicit Deny > Allow
Eğer Deny yoksa, Allow varsa → erişim var.
Hiç Allow yoksa → implicit deny.

Güvenli Policy Oluşturma (Least Privilege)

s3:* yerine gereken spesifik aksiyonlar (s3:GetObject, s3:PutObject, s3:ListBucket) verilmeli.

Kaynak bazlı kısıtlama:

"Resource": "arn:aws:s3:::my-secure-bucket/uploads/*"

Koşullar (Conditions):
- aws:SourceIp → belirli IP aralıkları
- aws:SourceVpc, aws:SourceVpce → belirli VPC erişimleri
- s3:x-amz-acl → PutObject için spesifik ACL şartı
- aws:PrincipalTag + s3:ResourceTag → ABAC (Attribute-Based Access Control)

ABAC (Öznitelik Tabanlı Yetkilendirme)

Kullanıcı/rol ve S3 kaynaklarına etiketler (tags) eklenir.

Politika: erişim yalnızca tag eşleşirse izin verilir.

"Condition": {
  "StringEquals": {
    "aws:PrincipalTag/project": "${s3:ResourceTag/project}"
  }
}

Blake’in Stratejisi

Tüm S3 erişimleri IAM Roller üzerinden yönetiliyor.
Üç ayda bir IAM Policy incelemeleri yapılıyor.
Bucket Policy sadece cross-account deny ve VPC endpoint enforcement için kullanılıyor.
ABAC rollout başlatıldı.
S3 Block Public Access tüm hesap ve bucket seviyesinde aktif.

S3 Güvenlik Sertleştirmesi (Security Hardening)

Public Access Kontrolleri (S3 Block Public Access)

BlockPublicAcls (true): Bir bucket ve içindeki objeler üzerinde var olan tüm public ACL’leri yok sayar.
IgnorePublicAcls (true): S3, tüm public ACL’leri yok sayar. Yeni public ACL’ler uygulanamaz.
BlockPublicPolicy (true): Public erişim veren bir Bucket Policy konulmaya çalışılırsa bu isteği reddeder.
RestrictPublicBuckets (true): Public policy’ye sahip bucket’lara erişimi yalnızca AWS servis yetkililerine ve bucket sahibinin hesabındaki yetkili kullanıcılara kısıtlar.

aws s3api put-public-access-block \
--bucket my-secure-bucket \
--public-access-block-configuration \
"BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

Veri Şifreleme (Data Encryption for S3)

1. Encryption in Transit (Taşınırken Şifreleme)

HTTPS (TLS) zorunlu kullanılmalı.

Bucket policy ile HTTP erişimlerini reddetmek mümkün:

{
  "Sid": "DenyInsecureTransport",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::my-secure-bucket/*",
  "Condition": {
    "Bool": { "aws:SecureTransport": "false" }
  }
}

2. Encryption at Rest (Dinamik Veri Şifreleme)

SSE-S3: Amazon S3 tarafından yönetilen anahtarlarla (AES-256) şifreleme. Basit uygulama.
SSE-KMS: AWS Key Management Service (KMS) tarafından yönetilen CMK’ler (Customer Master Keys). Daha fazla kontrol, audit (CloudTrail logları), özel müşteri anahtarları kullanılabilir.
SSE-C: Müşteri tarafından sağlanan anahtarlarla şifreleme. Anahtar yönetimi karmaşık.

Varsayılan bucket şifrelemesini açmak için:

aws s3api put-bucket-encryption \
--bucket my-secure-bucket \
--server-side-encryption-configuration '{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "AES256"
      }
    }
  ]
}'

SSE-KMS zorunlu hale getirmek için Bucket Policy:

{
  "Sid": "DenyInsecureTransport",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::my-secure-bucket/*",
  "Condition": {
    "Bool": { "aws:SecureTransport": "false" }
  }
}

Encryption at Rest (Dinamik Veri Şifreleme)

SSE-S3: Amazon S3 tarafından yönetilen anahtarlarla (AES-256) şifreleme. Basit uygulama.
SSE-KMS: AWS Key Management Service (KMS) tarafından yönetilen CMK’ler (Customer Master Keys). Daha fazla kontrol, audit (CloudTrail logları), özel müşteri anahtarları kullanılabilir.
SSE-C: Müşteri tarafından sağlanan anahtarlarla şifreleme. Anahtar yönetimi karmaşık.

Varsayılan bucket şifrelemesini açmak için:

aws s3api put-bucket-encryption \
--bucket my-secure-bucket \
--server-side-encryption-configuration '{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "AES256"
      }
    }
  ]
}'

SSE-KMS zorunlu hale getirmek için Bucket Policy:

{
  "Sid": "DenyUnencryptedObjectUploads",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-secure-bucket/*",
  "Condition": {
    "Null": { "s3:x-amz-server-side-encryption": "true" },
    "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
  }
}

Blake’in Stratejisi: “Tüm bucket’larda varsayılan şifreleme etkinleştirilmiştir, öncelikle hassas veriler için CMK’ları kullanan SSE-KMS, anahtar politikaları ve denetim izleri üzerinde ince ayarlı kontrol sağlar.
HTTPS, bucket politikaları aracılığıyla zorlanır.

Logging & Monitoring for S3

1. S3 Server Access Logs

Bucket’a yapılan her isteğin detaylarını kaydeder:
- İstek sahibi (requester)
- Bucket adı
- İstek zamanı
- İşlem türü (action)
- Yanıt durumu (response status)
- Hata kodu (error code)
Loglar farklı bir bucket’a gönderilmelidir. ( Bir bucket kendi loglarını kendisine yazamaz)
Kullanım Senaryosu: Olay inceleme (forensics), güvenlik analizi, erişim pattern’lerinin izlenmesi

🔧 Aktifleştirme Örneği:

Güvenli ayrı bir bucket’a yönlendirilmelidir.
Kullanım Alanları: Olay incelemesi (forensics), güvenlik analizi.


# (Requires a log delivery policy on the target bucket)
aws s3api put-bucket-logging --bucket my-source-bucket \
--bucket-logging-status '{
"LoggingEnabled": {
"TargetBucket": "my-log-bucket",
"TargetPrefix": "s3-access-logs/my-source-bucket/"
}
}'

2. AWS CloudTrail

Management Events: Bucket/policy değişiklikleri gibi yönetimsel işlemleri kaydeder. Varsayılan olarak aktiftir.
Data Events: Nesne (object) seviyesindeki işlemleri kaydeder (GetObject, PutObject, DeleteObject).
- Varsayılan olarak kapalıdır, manuel olarak bucket bazında açılması gerekir.
- Yüksek hacimli log üretir → maliyetli olabilir.
Kullanım Senaryosu: Denetim (audit), uyumluluk, operasyonel hata ayıklama, güvenlik olay incelemesi

Data Events Aktifleştirme Örneği:


aws cloudtrail put-event-selectors --trail-name my-trail \
--event-selectors '[
{
"ReadWriteType": "All",
"IncludeManagementEvents": true,
"DataResources": [
{ "Type": "AWS::S3::Object", "Values": ["arn:aws:s3:::my-data-bucket/"] }
]
}
]

3. Amazon GuardDuty (S3 Protection)

Sürekli izleme: CloudTrail Management Events + S3 Data Events
Tespit ettiği tehditler:
- Şüpheli veri erişim pattern’leri (örn. anormal GetObject aktiviteleri)
- Bilinen kötü niyetli IP adreslerinden API çağrıları
- Logging’in devre dışı bırakılmaya çalışılması
- Bucket policy manipülasyonu
Ekstra özellik: S3 için Malware Protection → yüklenen objelerde kötü amaçlı yazılım taraması yapılabilir

S3 Malware Protection Örneği:

# Not: Bu komut aslında EBS için daha yaygın. 
# S3 için ayar, GuardDuty console veya API üzerinden yapılır.

# Örnek: Belirli bir bucket için malware scan ayarlama
aws guardduty update-malware-scan-settings --detector-id <detector-id> \
--scan-resource-criteria '{"S3Bucket":{"Includes":[{"Name":"my-sensitive-bucket"}]}}' \
--ebs-volumes MalwareProtectionStatus=ENABLED

4. Amazon Macie

Makine öğrenimi + pattern matching ile S3 üzerindeki hassas verileri bulur, sınıflandırır, korur.
Tespit edilen veri türleri:
- Kişisel veriler (PII)
- Finansal veriler
- Credentials (anahtar/parola vb.)
Ek özellikler:
- Unencrypted bucket’ları bulma
- Riskli erişim pattern’lerini raporlama
Aktifleştirme: Console üzerinden. Hedef bucket’lar için Macie job tanımlanır.

5. CloudWatch Alarms & EventBridge

CloudWatch Alarms:
- S3 metriklerine göre alarm kurabilirsiniz (örn. NumberOfObjects, BucketSizeBytes)
- CloudTrail metriklerine göre alarm (örn. çok sayıda AccessDenied)
EventBridge:
- GuardDuty S3 bulgularına göre otomatik aksiyon tetikleme (örn. Lambda fonksiyon çağırma)

EventBridge Örneği (GuardDuty tetikleyince Lambda çalıştırma):

{
  "Source": ["aws.guardduty"],
  "DetailType": ["GuardDuty Finding"],
  "Detail": {
    "severity": [7, 8, 9],
    "resource": { "resourceType": ["S3Bucket"] }
  }
}

Blake’in Stratejisi (Savunma Senaryosu)

Tüm server access logları + CloudTrail logları → Merkezi, değiştirilemez (immutable) log arşiv bucket’ına gönderiliyor.
GuardDuty + S3 Protection + Malware Scanning aktif.
Amazon Macie → Hassas verilerin olduğu bucket’ları her gece tarıyor.

- EventBridge kuralları → Kritik GuardDuty bulgularında otomatik bildirim ve müdahale tetikleniyor.

7. S3 Veri Dayanıklılığı & Veri Yönetimi

7.1. Versioning (Sürümleme)

Tüm kritik bucket’larda versioning aktif edilmelidir.
Amaç:
- Yanlışlıkla silme (delete) veya üzerine yazma (overwrite) olaylarına karşı koruma
- Geri alma (rollback) işlemlerine destek

Aktifleştirme Komutu:

aws s3api put-bucket-versioning \
--bucket my-versioned-bucket \
--versioning-configuration Status=Enabled

7.2. S3 Object Lock

WORM (Write Once, Read Many) uyumluluğu sağlar.
Modlar:
- Governance Mode: Belirli IAM izinlerine sahip kullanıcılar retention ayarlarını aşabilir veya nesneleri silebilir.
- Compliance Mode: Hiçbir kullanıcı (root dahil) retention süresi boyunca nesneyi silemez veya üzerine yazamaz.
Not: Bucket Object Lock özelliği oluşturma sırasında etkinleştirilmelidir. Sonradan eklenemez.

Örnek: Object Lock + 365 Günlük COMPLIANCE Retention

aws s3api put-object-lock-configuration --bucket my-locked-bucket \
--object-lock-configuration '{
  "ObjectLockEnabled": "Enabled",
  "Rule": {
    "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 365 }
  }
}'

7.3. Replication (CRR / SRR)

Nesneleri başka bir bucket’a otomatik kopyalar:
- Cross-Region Replication (CRR): Başka bir AWS bölgesine (disaster recovery, global erişim için).
- Same-Region Replication (SRR): Aynı bölge içinde (log toplama, ayrı erişim alanı için).
Önkoşullar:
- Kaynak ve hedef bucket’larda versioning açık olmalı.
- IAM rolü tanımlanarak S3’e replikasyon izni verilmelidir.

Kullanım Senaryoları:

Felaket kurtarma (Disaster Recovery)
Dağıtık kullanıcılar için düşük gecikmeli erişim
Log konsolidasyonu

7.4. Lifecycle Policies

Nesneleri farklı storage sınıflarına otomatik taşıma veya süresi dolduğunda silme.
Kullanım Senaryoları:
- Maliyet optimizasyonu
- Veri saklama politikalarının uygulanması

Örnek Lifecycle Policy

logs/ prefix’li nesneleri 90 gün sonra Glacier’e taşı
365 gün sonra tamamen sil

{
  "ID": "ArchiveOldLogs",
  "Status": "Enabled",
  "Filter": { "Prefix": "logs/" },
  "Transitions": [
    { "Days": 90, "StorageClass": "GLACIER" }
  ],
  "Expiration": { "Days": 365 }
}

CLI ile uygulama:

aws s3api put-bucket-lifecycle-configuration \
--bucket my-archive-bucket \
--lifecycle-configuration file://lifecycle.json

Stratejik Özet

Versioning → Yanlışlıkla silme/overwrite koruması
Object Lock (Compliance Mode) → Regülasyon uyumu (WORM, finans/sağlık sektöründe zorunlu olabilir)
Replication (CRR/SRR) → Felaket kurtarma, çoklu-bölge erişim
Lifecycle Policies → Maliyet azaltma + Veri saklama politikaları

9. S3 Güvenlik – Pre-signed URLs, Auditing & Incident Response

9.1. Pre-signed URLs (Savunma Perspektifi)

Risk: Pre-signed URL yanlış yönetilirse saldırgan tarafından dosya yükleme / silme için kullanılabilir.
Savunma Stratejisi:

Kısa Süreli URL: ExpiresIn süresini minimumda tut (ör. 300 saniye).
Least Privilege IAM: URL üreten rol sadece gerekli izinlere sahip olmalı (örn. s3:PutObject sadece belirli bir key için).
Content-MD5: Yüklenen objenin bütünlüğünü kontrol etmek için Content-MD5 header zorunlu kıl.
Sunucu Taraflı Validasyon: Upload sonrası Lambda ile tetikleme → Dosya tipi, boyut kontrolü + malware taraması.

Python (Boto3) Örneği:

import boto3
import logging
from botocore.client import Config
from botocore.exceptions import ClientError

s3_client = boto3.client('s3', region_name='us-east-1', config=Config(signature_version='s3v4'))

try:
    response = s3_client.generate_presigned_url(
        'put_object',
        Params={
            'Bucket': 'my-upload-bucket',
            'Key': 'user_uploads/image.jpg',
            'ContentType': 'image/jpeg'
        },
        ExpiresIn=300  # 5 dakika
    )
    print(response)
except ClientError as e:
    logging.error(e)
    # return None

9.2. Vulnerability Management & Auditing for S3

AWS Config

Sürekli izleme ve uyumluluk kuralları
Örnek kurallar:
- s3-bucket-public-read-prohibited
- s3-bucket-ssl-requests-only
- s3-bucket-logging-enabled

Üçüncü Parti Araçlar

Cloud Custodian → Policy bazlı otomatik remediate

policies:
  - name: s3-unencrypted-buckets
    resource: s3
    filters:
      - type: value
        key: "ServerSideEncryptionConfiguration.Rules[0].ApplyServerSideEncryptionByDefault.SSEAlgorithm"
        value: absent
    actions:
      - type: notify
        template: default.html
        subject: "Unencrypted S3 Bucket Found!"
        to:
          - security-team@example.com
        transport:
          type: sqs
          queue: cloud-custodian-mailer

Prowler → CLI tabanlı AWS güvenlik denetimi, CIS benchmark’lar dahil

CloudQuery → Cloud konfigürasyonlarını SQL ile sorgulama

SELECT arn, name, region, server_side_encryption_configuration
FROM aws_s3_buckets
WHERE server_side_encryption_configuration IS NULL;

Manuel Denetimler

Düzenli S3 permission review
Penetrasyon testlerinde mutlaka S3 scope’a dahil edilmeli

9.3. Gerçek Senaryo (Acme Corp)

Kurulum:

Bucket: acme-webapp-user-uploads (profil fotoğrafları için)

Saldırgan (Alex)

Recon (Gün 1): Bucket public değil (Access Denied → ✅).
ACL Probing: Kendi AWS hesabıyla obje denemeleri.
Exploit Upload Feature (Gün 2):
- Client-side validation var ama server-side yok → profile.php yükletiyor.
- Pre-signed URL → PHP webshell upload ediyor.
Webshell Access:

http://acme-webapp-user-uploads.s3-website-us-east-1.amazonaws.com/user_123/profile.php?cmd=ls

1. → Komut çalıştırıyor.

Persistence & Exfiltration (Gün 3): DB cred bulup sızdırıyor.

Savunmacı (Blake)

İlk Alarm:
- GuardDuty S3 Malware Protection → MaliciousFileUploadedToS3
- Alternatif: CloudTrail Data Event → .php upload’ı EventBridge/Lambda ile tetiklenebilir
Investigation:
- GuardDuty alert → Slack
- CloudTrail → hangi IAM rol pre-signed URL üretti?
- S3 Access Logs → GetObject request analizi
Containment:
```
aws s3api delete-object --bucket acme-webapp-user-uploads --key user_123/profile.php
```
- - Kötü objeyi sil
- Gerekirse PutObject deny eden bucket policy uygula
- Web server loglarını incele

Eradication:
- Uygulama fix: Server-side validation eklenmeli
- Bucket taraması → başka kötü dosya var mı?
- Web server hardening
Recovery:
- Credential rotation
- Gerekirse restore from backup
Lessons Learned:
- Dev’lere secure upload eğitimi
- WAF kuralları → php, exe upload engeli
- EventBridge → anormal extension alarmı
- Gereksizse bucket’ı website endpoint olarak açma
Stratejik Dersler
Pre-signed URL çok güçlü ama yanlış konfig ile ölümcül olabilir.
S3 güvenliği → sadece bucket policy değil, uygulama + network + IAM + logging + monitoring katmanlarıyla ele alınmalı.
CloudTrail + GuardDuty + Config + Custodian → birlikte çalıştığında saldırı zinciri kısa sürede kırılabilir.

1. Olay Müdahalesi Senaryosu (Örnek: Kötü Amaçlı Upload)

Adımlar:

Kullanıcıyı Kilitle (Lock User): Eğer saldırgan bir uygulama hesabı üzerinden upload yaptıysa, o kullanıcı hesabı hemen askıya alınır.
Geçici Bucket Policy Uygula: Yeni dosya yüklemeleri engellenir.

{
  "Sid": "TemporaryBlockUploads",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::acme-webapp-user-uploads/*"
}

- Web Sunucu Loglarını İncele: Yüklenen dosyaya erişim olup olmadığını, komut çalıştırılıp çalıştırılmadığını tespit et.

Eradikasyon (Day 2-3):

Uygulamadaki “file type validation” zafiyetini kapat.
Pre-signed URL sadece güvenli dosya tipleri için oluşturulmalı.
Bucket içindeki tüm dosyalar taranmalı.
PHP çalıştırma açığı varsa (genelde web server config hatası), kapatılmalı.

Recovery (Day 3):

Etkilenen sistemler gerekiyorsa yedekten dönülür.
Ele geçirilen credential’lar (ör. DB şifreleri) hemen rotate edilir.

Lessons Learned (Day 4+):

Geliştiricilere güvenli dosya yükleme eğitimi.
Pre-signed URL’ler için sıkı validation.
WAF kuralları (şüpheli uzantılar blok).
Daha özel CloudWatch alarmları.
Bucket’ların web site endpoint olarak açılmasının gerekliliği gözden geçirilmeli.
S3 Object Lambda ile upload/download öncesi ek validasyon veya maskeleme yapılabilir.
S3 Access Points ile her uygulama için ayrı erişim noktası oluşturulmalı.

2. Saldırganın Araçları (Alex’in Toolkit’i)

Eylem	Komut / Araç
Public Bucket bulma	`aws s3 ls s3://<bucket> --no-sign-request` , S3Scanner, Google Dorks (`site:s3.amazonaws.com`)
Bucket içeriğini listeleme	`aws s3 ls s3://<bucket> --recursive`
Dosya indirme	`aws s3 cp s3://<bucket>/<key> ./`
Dosya yükleme	`aws s3 cp ./file s3://<bucket>/<key>`
Bucket ACL kontrolü	`aws s3api get-bucket-acl --bucket <bucket>`
Sızdırılan Key kullanımı	`aws configure --profile hacked` + tüm AWS CLI komutları
JS dosyalarında bucket arama	`grep -r "s3.amazonaws.com" ./js_files/`
Shodan araması	`hostname:.s3.amazonaws.com`

3. Savunma Araçları (Blake’in Arsenal’i)

Eylem	Komut / Policy
Public Access blokla	`aws s3api put-public-access-block --bucket <bucket> --public-access-block-configuration ...`
Default Encryption aç	`aws s3api put-bucket-encryption --bucket <bucket> ...`
Versioning aç	`aws s3api put-bucket-versioning --bucket <bucket> --versioning-configuration Status=Enabled`
Access Logging aç	`aws s3api put-bucket-logging --bucket <src_bucket> --bucket-logging-status '{...}'`
CloudTrail Data Events	`aws cloudtrail put-event-selectors --trail-name <trail> ...`
HTTPS zorunlu	Policy: `{ "Bool": { "aws:SecureTransport": "false" } }`
KMS ile şifreleme zorunlu	Policy: `{ "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } }`
IP ile sınırla	`{ "NotIpAddress": { "aws:SourceIp": "1.2.3.4/32" } }`
VPC Endpoint zorunlu	`{ "StringNotEquals": { "aws:sourceVpce": "vpce-12345678" } }`
GuardDuty S3 koruması	Konsol → S3 Protection Enable
Macie	Sensitive data discovery jobs
AWS Config	`s3-bucket-public-read-prohibited`, `s3-bucket-ssl-requests-only`
Pre-signed URL üret	`boto3.client('s3').generate_presigned_url(...)`
Şüpheli dosyayı karantinaya al	`aws s3 mv s3://<src>/<obj> s3://<quarantine>/<obj>`

4. S3 Güvenliği için Temel AWS Servisleri

IAM → Yetkilendirme
CloudTrail → Loglama
GuardDuty → Tehdit tespiti
Macie → Hassas veri analizi
AWS Config → Uyumluluk denetimi
KMS → Şifreleme
WAF → Web saldırılarını önleme
EventBridge + Lambda → Otomatik response

5. Temel Güvenlik İlkeleri

Least Privilege → Gereksiz izin verme
Block Public Access → Her zaman kapalı tut
Encrypt Data → Hem at rest (AES256/KMS) hem in-transit (HTTPS)
Log Everything → CloudTrail + S3 Access Logs
Monitor Actively → GuardDuty, Macie, CloudWatch
Automate → Config, Custodian, EventBridge + Lambda
Protect Credentials → IAM roles, kısa süreli credential, güvenli pre-signed URL
Regular Audit → Politikaları ve erişimi denetle
Lifecycle Management → Versioning, Object Lock, Lifecycle Rules

6. Yeni Tehditler & Gelecek

Ransomware → Cloud storage hedefliyor.
S3 Batch misconfig exploiti.
AI tabanlı saldırılar → otomatik keşif & veri analizi.
Savunmada AI → Macie & GuardDuty → ML tabanlı anomali tespiti.
Data Sovereignty → Nitro Enclaves + S3 ile veri ülke sınırında kalmalı.

Terim	Açıklama
S3 (Simple Storage Service)	Nesne tabanlı, dağıtık AWS depolama servisi. Objeler (dosyalar) bucket’lar içinde saklanır; yüksek dayanıklılık ve ölçek sağlar.
Bucket (Kova)	S3’te nesnelerin tutulduğu benzersiz isimli konteyner. Her bucket kendi politika, versioning ve yapılandırmasına sahiptir.
Object (Obje)	S3’te depolanan veri birimi (dosya) ve ona ait metadata. Objeler key (anahtar) ile tanımlanır.
Key (Anahtar)	Bir bucket içindeki objeyi benzersiz şekilde tanımlayan isim/yol (path).
Region (Bölge)	S3 bucket’ının oluşturulduğu AWS coğrafi bölgesi; gecikme, maliyet ve uyumluluğu etkiler.
Versioning (Sürümleme)	Aynı objenin geçmiş sürümlerini saklama özelliği; yanlışlıkla silme/overwrite durumlarında geri dönüş sağlar.
Object Lock	WORM (Write-Once-Read-Many) koruması: nesnelerin belirli süre silinmesini veya üzerine yazılmasını engeller (Governance/Compliance modları).
Server-Side Encryption (SSE)	S3 üzerinde veriyi sunucu tarafında şifreleme. SSE-S3 (Amazon yönetir), SSE-KMS (KMS ile CMK kullanılır), SSE-C (müşteri anahtarı) seçenekleri vardır.
ACL (Access Control List)	Bucket/objeye doğrudan uygulanabilen basit okuma/yazma izinleri; modern tavsiye IAM/policy üzerinden yönetmektir.
Bucket Policy	JSON formatında, kaynak bazlı (resource) erişim politikası; IP, VPC veya koşullarla (Condition) ince ayar yapılabilir.
IAM (Identity and Access Management)	AWS kimlik, rol ve politika yönetim servisi; kullanıcı/rol bazlı erişim kontrolü sağlar.
IAM Role	Servislere (EC2, Lambda vb.) atanan, geçici kimlik bilgileri sağlayan güvenli kimlik mekanizması.
Pre-signed URL	Belirli obje için zaman sınırlı ve işlem tipi sınırlı geçici erişim URL’si; süresi/izinleri dikkatle yönetilmezse risklidir.
Block Public Access	Hesap veya bucket seviyesinde public ACL/policy’lerini devre dışı bırakan güvenlik ayarı; yanlış yapılandırmayı engeller.
S3 Access Points	Büyük veri setlerine uygulama-özel erişim noktaları sağlayan, ayrı DNS/izinler ile yönetilen erişim modeli.
S3 Object Lambda	GET/HEAD/LIST istekleri sırasında obje içeriğini işleyip döndürebilen Lambda entegrasyonu; iş mantığı güvenliği önemlidir.
S3 Server Access Logs	S3 isteklerinin (kimin, ne zaman, hangi objeye) kaydını tutan loglar; ayrı, güvenli bucket’a yönlendirilmelidir.
CloudTrail (Management & Data Events)	AWS API çağrılarını (yönetimsel ve isteğe bağlı obje düzeyi) kaydeden denetim servisi; olay inceleme için kritik.
GuardDuty (S3 Protection)	Anomali tespiti sağlayan tehdit algılama servisi; S3 için malware ve şüpheli erişim bulguları üretir.
Macie	Makine öğrenimi ve desen eşleştirme ile S3 içindeki hassas verileri (PII, krediler vb.) keşfeden sınıflandırma servisi.
CloudWatch & EventBridge	Metrik/alarmlar (CloudWatch) ve olay tabanlı otomatik iş akışları (EventBridge) ile izleme ve otomasyon sağlar.
WAF (Web Application Firewall)	Web uygulaması katmanında kötü amaçlı istekleri sınırlayan kurallar seti; zararlı upload ve injection’ları azaltır.
IMDS (Instance Metadata Service)	EC2 örneğinin metadata ve geçici IAM kimlik bilgilerini sağlayan servis (169.254.169.254); yanlış kullanım risklidir.
IMDSv2	Token tabanlı daha güvenli IMDS sürümü; SSRF benzeri istismarları zorlaştırır.
SSRF (Server-Side Request Forgery)	Uygulamanın sunucu üzerinden iç ağ veya IMDS gibi hedeflere istek yaptırılmasıyla bilgi/kimlik sızdırma tekniği.
EBS (Elastic Block Store)	EC2 için blok depolama; şifreleme, snapshot yönetimi ve erişim kontrolü önemlidir.
Replication (CRR / SRR)	Objeleri cross-region (CRR) veya same-region (SRR) başka bucket’a otomatik çoğaltma; versioning önkoşuludur.
Lifecycle Policy	Objeleri zamanla farklı depolama sınıflarına taşıma veya silme kuralları; maliyet ve uyumluluk yönetimi sağlar.
Cloud Custodian	Policy tabanlı otomatik keşif ve remediate aracı; uyumluluk sorunlarını otomatik düzeltmeye yardımcı olur.
Data Exfiltration	Yetkisiz veri dışa aktarımı; S3 üzerinden sync/cp, cross-account replication veya C2 teknikleriyle yapılabilir.
Least Privilege	İzinleri en düşük ihtiyaca göre verme ilkesi; `s3:*` yerine spesifik aksiyonlara izin verilmeli.
ABAC (Attribute-Based Access Control)	Kullanıcı/rol ve kaynak etiketlerine (tags) dayalı koşullu erişim kontrolü; esnek politika uygulamaları sağlar.
S3 Malware Protection	GuardDuty veya ek hizmetlerle S3’e yüklenen dosyaların malware taranması; otomatik tespit ve uyarı sağlar.

AWS S3 Bucket Nedir?

Saldırı ve savunmaya geçmeden önce, S3’ü hem güçlü hem de karmaşık bir güvenlik sorunu yapan özelliklerini anlayalım.

S3’ün Temel Özellikleri ve Güvenlik Etkileri:

Neden S3 Hedef Alınır?

1.1. Halka Açık Bilinen Kova İsimleri ve Permütasyonlar

1.2. Google Dorking

1.3. Sertifika Şeffaflık (CT) Logları

1.4. DNS Keşfi ve Alt Alan Adı Taraması

1.5. Web Sayfaları ve Mobil Uygulamaların Analizi

1.6. GitHub & Kamuya Açık Kod Depoları

1.7. Shodan / Censys

Kullanılan Araçlar

Alex’in Günlüğü

MITRE ATT&CK TTP Eşlemesi

İlk Erişim Başlangıcı – Potansiyel Kovaları Test Etme

2.1. Halka Açık Listeleme/Okuma Hatalarının İstismarı

2.2. Yanlış Yapılandırılmış ACL’ler

2.3. Sızdırılmış Kimlik Bilgileri / IAM Anahtarları

2.4. Önceden İmzalanmış (Pre-signed) URL’lerin İstismarı

📓 Alex’in Günlüğü

MITRE ATT&CK Eşlemesi

S3 Post-Exploitation (Saldırı Sonrası) Aşamaları ve Savunma

Saldırganın Adımları (Alex)

3.1. Nesnelerin ve Yapının Keşfi (Enumeration)

3.2. Hassas Verilerin İndirilmesi

3.3. Kötü Amaçlı Dosya Yükleme (Write Access varsa)

3.4. Mevcut Nesneleri Manipüle Etme (Data Integrity Attack)

3.5. Yetki Yükseltme (Privilege Escalation)

3.6. Veri Sızdırma (Data Exfiltration)

3.7. İzleri Gizleme (Covering Tracks)

MITRE ATT&CK Eşleştirmesi

Savunmacının Adımları (Blake)

IAM ve S3 Güvenliği

Bucket Policy vs IAM Policy

Güvenli Policy Oluşturma (Least Privilege)

ABAC (Öznitelik Tabanlı Yetkilendirme)

Blake’in Stratejisi

S3 Güvenlik Sertleştirmesi (Security Hardening)

Public Access Kontrolleri (S3 Block Public Access)

Veri Şifreleme (Data Encryption for S3)

1. Encryption in Transit (Taşınırken Şifreleme)

2. Encryption at Rest (Dinamik Veri Şifreleme)

Encryption at Rest (Dinamik Veri Şifreleme)

Logging & Monitoring for S3

1. S3 Server Access Logs

2. AWS CloudTrail

3. Amazon GuardDuty (S3 Protection)

4. Amazon Macie

5. CloudWatch Alarms & EventBridge

Blake’in Stratejisi (Savunma Senaryosu)

- EventBridge kuralları → Kritik GuardDuty bulgularında otomatik bildirim ve müdahale tetikleniyor.

7. S3 Veri Dayanıklılığı & Veri Yönetimi

7.1. Versioning (Sürümleme)

7.2. S3 Object Lock

7.3. Replication (CRR / SRR)

7.4. Lifecycle Policies

Stratejik Özet

9. S3 Güvenlik – Pre-signed URLs, Auditing & Incident Response

9.1. Pre-signed URLs (Savunma Perspektifi)

9.2. Vulnerability Management & Auditing for S3

AWS Config

Üçüncü Parti Araçlar

Manuel Denetimler

9.3. Gerçek Senaryo (Acme Corp)

Saldırgan (Alex)

Savunmacı (Blake)

Stratejik Dersler

1. Olay Müdahalesi Senaryosu (Örnek: Kötü Amaçlı Upload)

Adımlar:

2. Saldırganın Araçları (Alex’in Toolkit’i)

3. Savunma Araçları (Blake’in Arsenal’i)

4. S3 Güvenliği için Temel AWS Servisleri

5. Temel Güvenlik İlkeleri

6. Yeni Tehditler & Gelecek