Amazon SCS-C02: Günlükleme, Denetim ve Adli Bilişim — Çalışma kılavuzu

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS Security Specialty SCS-C02 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Amazon sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Amazon GuardDuty Bulguları ve Düzeltme

GuardDuty, arka planda üç telemetri akışını sürekli olarak alan, yönetilen bir tehdit tespit hizmetidir: CloudTrail yönetim (ve isteğe bağlı olarak S3 veri) olayları, VPC Akış Günlükleri ve Route 53 DNS sorgu günlükleri. GuardDuty’nin bu günlük kaynaklarını kullanabilmesi için bunları ayrıca etkinleştirmeniz, teslim etmeniz veya bunlar için ödeme yapmanız gerekmez; hizmet, yinelenen bir akışı doğrudan okur. Bu nedenle GuardDuty, tek bir API çağrısıyla açılabilir ve herhangi bir günlük işlem hattı mühendisliğine gerek kalmadan dakikalar içinde bulgu üretmeye başlayabilir.

Bulgular, 0.1 ile 8.9 arasında bir önem derecesi değeri taşır ve bu değerler Düşük (0.1–3.9), Orta (4.0–6.9) ve Yüksek (7.0–8.9) olarak eşlenir. Tipik olarak işlem yapılabilir bulgular arasında UnauthorizedAccess:EC2/SSHBruteForce, Backdoor:EC2/C&CActivity.B!DNS, CryptoCurrency:EC2/BitcoinTool.B ve Recon:IAMUser/MaliciousIPCaller yer alır. Düzeltme yöntemleri bulguya göre değişir: EC2 tabanlı bir güvenlik ihlali genellikle örneği bir karantina güvenlik grubuyla izole etmeyi, adli analiz için birimlerin anlık görüntüsünü almayı ve sonlandırmayı gerektirir; IAM tabanlı bir bulgu ise erişim anahtarlarını döndürmeyi ve principal’ın son CloudTrail etkinliğini gözden geçirmeyi gerektirir.

Çoklu hesap ortamları için, GuardDuty’yi AWS Organizations aracılığıyla etkinleştirin ve bir delegated administrator (yetkilendirilmiş yönetici) hesabı (genellikle Güvenlik Araçları hesabı) belirleyin. Yetkilendirilmiş yönetici, hizmetin açık olduğu her Bölge’de mevcut ve yeni tüm üye hesaplarda GuardDuty’yi otomatik olarak etkinleştirebilir. Yetkilendirilmiş yönetici yapılandırması olmadan, her hesaba özgü GuardDuty bulguları her üyede izole kalır; dedektörleri tek tek etkinleştirmek, bunları merkezi olarak toplamaz.

AWS Security Hub ve Hesaplar Arası Toplama

Security Hub, normalleştirme ve toplama katmanıdır. GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config ve onlarca iş ortağı ürününden bulguları alır ve bunları AWS Security Finding Format (ASFF) biçimine dönüştürür. Ayrıca CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS ve NIST 800-53 gibi standartlara göre kendi kontrollerini de çalıştırır.

Hesaplar arası, Bölgeler arası toplama, GuardDuty ile aynı şekilde çalışır: Security Hub’ı Organizations yetkilendirilmiş yöneticisine kaydedin, ardından diğer Bölgelerden gelen bulguların bu tek bir panelde kopyalanması için bir aggregation Region (toplama Bölgesi) belirleyin. Yaygın bir hata, her hesapta Security Hub’ı etkinleştirip birleştirilmiş bir görünüm beklemektir; yetkilendirilmiş yönetici ve toplama Bölgesi olmadan, her hesap yine de yalnızca kendi bulgularını görür.

Security Hub kendi başına e-posta göndermez. Bildirimler ve otomasyonlar, varsayılan EventBridge veri yolundaki Security Hub bulgu olaylarını eşleştirerek ve bunları SNS, Lambda, Step Functions veya Systems Manager Otomasyon belgelerine yönlendirerek oluşturulur.

CloudTrail: Yönetim ve Veri Olayları Karşılaştırması

CloudTrail iki kategoride etkinlik kaydeder ve bunları karıştırmak, tespit kapsamındaki en yaygın tek eksikliktir.

• Yönetim olayları: kontrol düzlemi işlemleri — RunInstances, CreateBucket, AttachRolePolicy, PutBucketAcl. Herhangi bir yeni iz (trail) üzerinde varsayılan olarak etkindir.

• Veri olayları: yüksek hacimli, kaynak düzeyinde işlemler — S3 nesne düzeyinde çağrılar (GetObject, PutObject, DeleteObject, PutObjectAcl), Lambda Invoke, DynamoDB öğe düzeyinde API çağrıları. Varsayılan olarak devre dışıdır ve ayrıca faturalandırılır.

Eğer bir güvenlik gereksinimi “birisi PutObjectAcl aracılığıyla bir S3 nesnesini herkese açık hale getirdiğinde tespit et” ise, yalnızca yönetim olaylarını içeren basit bir iz bunu yakalamaz çünkü tek tek nesneler üzerindeki ACL değişiklikleri veri olaylarıdır. Benzer şekilde, hassas bir bucket’tan GetObject ile veri çıkışı, veri olayları olmadan görünmezdir. PutBucketAcl (bucket düzeyinde) bir yönetim olayıdır ve günlüğe kaydedilir; PutObjectAcl (nesne düzeyinde) ise kaydedilmez.

Yönetim veya yetkilendirilmiş yönetici hesabında oluşturulmuş bir organization trail (kuruluş izi) kullanın; böylece her üye hesabın olayları tek bir S3 bucket’ında yakalanır ve üye hesap principal’ları tarafından devre dışı bırakılamaz. İzi (trail) şunlarla koruyun:

• Hedef bucket üzerinde, yetkisiz şifre çözmeyi reddeden bir KMS anahtar politikası ile SSE-KMS şifrelemesi.

• CloudTrail hizmet principal’ı olmadan s3:PutObject işlemini reddeden ve silmeyi reddeden bir bucket politikası.

• Log file integrity validation (Günlük dosyası bütünlük doğrulaması) etkinleştirilmiş olmalı; bu, kurcalanmanın kanıtlanabilmesi için SHA-256 ile imzalanmış saatlik özet dosyaları üretir.

Örnek oluşturma:

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name central-ct-logs \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

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

EventBridge ve SNS ile Uyarı Oluşturma

EventBridge, bulguları insan ve otomatik müdahale birimlerine bağlayan yönlendirme yapısıdır. Her GuardDuty bulgusu, her Security Hub bulgu güncellemesi ve CloudTrail’den türetilen her olay, varsayılan olay veri yoluna (event bus) düşer. Kurallar, filtreleme yapmak için JSON olay desenlerini kullanır, ardından bir veya daha fazla hedefe (SNS, Lambda, SQS, Kinesis Data Firehose, Step Functions, Systems Manager) dağıtım yapar.

Yüksek önem dereceli GuardDuty bulguları için, hem e-posta için bir SNS konusuna hem de analiz için OpenSearch’ü besleyen bir Firehose teslim akışına yönlendirilen standart bir desen:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [ { "numeric": [ ">=", 7 ] } ] }
}

E-postaya yönlendirilen Security Hub KRİTİK bulguları için:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["CRITICAL"] },
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

E-posta uç noktası basit bir SNS aboneliğidir; abonenin, teslimat başlamadan önce e-postayla gönderilen bağlantı aracılığıyla onaylaması gerekir. Tek bir kural en fazla beş hedef taşıyabilir, bu nedenle uyarı ve alt sistem analizleri için yinelenen kurallar gerekmez.

Desenleri yazarken, CloudTrail yönetim olaylarının "detail-type": "AWS API Call via CloudTrail" ile geldiğini unutmayın; oysa veri olayları, CloudWatch Logs’a yayın yapan bir iz yapılandırmadığınız ve bir metrik filtresi kullanmadığınız veya EventBridge’in CloudTrail veri olayı entegrasyonu aracılığıyla abone olmadığınız sürece varsayılan veri yolunda görünmez. Veri olaylarını etkinleştirmeden varsayılan veri yolunda "eventName": "PutObjectAcl" ile eşleşen bir EventBridge kuralı yazmak sıfır eşleşme verir.

CloudWatch Logs, Insights, Metrik Filtreleri ve Alarmlar

CloudTrail’i (ve VPC Akış Loglarını ve uygulama loglarını) CloudWatch Logs’a göndermek, neredeyse gerçek zamanlı tespit imkanı sağlar. Metrik filtreleri, gelen her log olayını bir desene göre tarar ve özel bir CloudWatch metriğini artırır; bu metrik üzerindeki bir CloudWatch alarmı ise SNS’yi tetikler.

Örnek: Tekrarlanan konsol oturum açma hatalarında alarm oluşturma.

aws logs put-metric-filter \
  --log-group-name /aws/cloudtrail/org \
  --filter-name ConsoleSignInFailures \
  --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }' \
  --metric-transformations metricName=ConsoleLoginFailures,metricNamespace=Security,metricValue=1

CloudWatch Logs Insights, bir alarm tetiklendikten sonra olay müdahalesi için kullanışlı olan, amaca özel bir sorgu dili kullanarak anlık sorgulama imkanı sunar:

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName

Yaygın Tuzaklar

• Eksik S3 nesne seviyesi aktivitesi: PutObjectAcl, GetObject ve DeleteObject veri olaylarıdır. Varsayılan bir trail yalnızca yönetim olaylarını yakalar; veri olayı seçicileri eklemeniz gerekir, aksi takdirde bu API adlarını hedefleyen bulgu, alarm veya EventBridge kuralı sessizce asla tetiklenmez.

• Yetkilendirilmiş yönetici olmadan merkezi görünürlük: Her hesapta GuardDuty veya Security Hub’ı etkinleştirmek sonuçları birleştirmez. Bulgular yalnızca AWS Organizations’ta bir yetkilendirilmiş yönetici kaydettikten ve Security Hub için bir toplama Bölgesi seçtikten sonra merkezi olarak toplanır. Hesaplar arası davetler küçük ortamlar için işe yarar ancak ölçeklenmez ve her hesap için ayrı kabul gerektirir.

• Filtrelerde yönetim ve veri olayı karmaşası: PutBucketAcl (bucket) bir yönetim olayıdır ve herhangi bir standart EventBridge veya metrik filtresinde çalışır; PutObjectAcl (nesne) ise, desen ne kadar iyi hazırlanmış olursa olsun, veri olayları etkinleştirilip aynı işlem hattına teslim edilmedikçe çalışmaz.

Pratik Problem: Kullanım Senaryosu

Senaryo: Meridian Financial, özel bir güvenlik hesabına ve merkezi bir loglama hesabına sahip çoklu hesaplı bir AWS Organization yapısı işletmektedir. Ortamları, S3’te müşteri PII’si (Kişisel Tanımlanabilir Bilgi), EC2/Lambda üzerinde işlem API’leri içermekte ve CloudTrail halihazırda yönetim olaylarını merkezi bir S3 bucket’ına yazmaktadır; ekipler daha hızlı tespit ve hesaplar arasında koordineli müdahale istemektedir.

Zorluk: Güvenlik mühendisleri, S3 GET işlemlerinde ani bir artış ve potansiyel veri sızdırmaya işaret eden ilgili GuardDuty bulguları tespit etti, ancak uyarılar çok gürültülü ve ilişkili CloudTrail bağlamından ve hesaplar arası otomatik sınırlandırmadan yoksun.

Önerilen Yaklaşım:

1. Her üye hesapta Amazon GuardDuty’yi etkinleştirin ve güvenlik hesabını GuardDuty yetkilendirilmiş yöneticisi olarak atayın; bulguların nesne düzeyinde erişim anormalliklerini içermesi için S3 veri olayı korumasını etkinleştirin.
2. Her hesap için CloudTrail’i, yönetim olaylarını saklama amacıyla merkezi S3’e teslim edecek ve seçilmiş yüksek değerli veri olaylarını (S3 GetObject/PutObject/DeleteObject ve Lambda Invoke) düşük gecikmeli denetim için güvenlik hesabındaki CloudWatch Logs’a iletecek şekilde yapılandırın.
3. Güvenlik hesabında AWS Security Hub’ı açın ve GuardDuty bulgularının, CloudTrail kaynaklı bulguların ve Config/Inspector sonuçlarının merkezileştirilip normalleştirilmesi için üye hesaplarla hesaplar arası toplamayı etkinleştirin.
4. Yüksek önem dereceli GuardDuty ve Security Hub bulgularıyla eşleşen ve bunları çağrı cihazı bildirimleri için SNS’ye ve CloudTrail bağlamını kullanarak sınırlandırma eylemleri (API anahtarlarını iptal etme, IAM oturumunu sonlandırma, EC2 ENI’sini izole etme) gerçekleştiren bir düzeltme Lambda’sına yönlendiren EventBridge kuralları oluşturun.
5. IAM principal’ına göre kapsamı belirlenmiş anormal s3:GetObject oranları için CloudWatch Logs metrik filtreleri ve aynı EventBridge/SNS/Lambda işlem hattını tetikleyen bir alarm ekleyin; olay triyajı için uyarıları ilişkili CloudTrail olaylarıyla zenginleştirmek amacıyla güvenlik hesabındaki CloudWatch Logs Insights sorgularını kullanın.

Gerekçe: Bulguları merkezileştirmek (GuardDuty + Security Hub) ve hedeflenmiş CloudTrail veri olaylarını CloudWatch’a göndermek, EventBridge/SNS/Lambda aracılığıyla düşük gecikmeli korelasyon, uyarı ve otomatik sınırlandırma sağlar—bu da AWS’in tespit, hesaplar arası toplama ve otomatik müdahale için en iyi uygulamalarıyla uyumludur.

Merkezi CloudTrail ve Log Bütünlüğü

CloudTrail, AWS API aktivitesinin yetkili kaydıdır ve herhangi bir denetim mimarisinin temeli, ideal olarak AWS Organizations içindeki özel bir log arşivi hesabında bulunan, merkezi tek bir S3 bucket’ına teslimat yapan tek bir çok Bölgeli (multi-Region) trail‘dir. Çok Bölgeli bir trail, mevcut her Bölgedeki ve AWS’in daha sonra başlatacağı herhangi bir Bölgedeki yönetim olaylarını otomatik olarak yakalar — tek Bölgeli bir trail ise, başka bir yerde bir iş yükü başlatıldığı anda kör noktalar oluşturur ki bu, denetimler sırasında klasik bir bütünlük hatasıdır. Organizasyon düzeyinde uygulandığında, trail aynı zamanda her üye hesabın olaylarını da yakalar, böylece organizasyona katılan yeni bir hesap, her hesap için ayrı bir yapılandırma gerektirmeden kapsama alınır.

Trail üzerinde log dosyası doğrulamasını etkinleştirin. CloudTrail daha sonra, teslim edilen log dosyalarının SHA-256 hash’lerini içeren imzalanmış bir özet dosyasını her saat aynı S3 bucket’ına teslim eder. aws cloudtrail validate-logs komutu, özet zincirini takip ederek kurcalama, silme veya boşlukları tespit eder. Doğrulama olmadan, bir savunmacı logların olay sonrası değiştirilmediğini kanıtlayamaz, bu da onları adli kanıt olarak geçersiz kılar.

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name corp-audit-logs \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail start-logging --name org-trail

Teslimat hataları neredeyse her zaman CloudTrail hatalarından değil, akış aşağısındaki izin sorunlarından kaynaklanır. S3 bucket’ı, trail oluşturulmadan önce mevcut olmalı, bucket politikası trail ile eşleşen bir aws:SourceArn koşuluyla cloudtrail.amazonaws.com‘a s3:PutObject izni vermeli ve nesne sahibi, bucket sahibi olmalıdır (bucket-owner-full-control). Eğer trail SSE-KMS kullanıyorsa, CMK politikası CloudTrail hizmet sorumlusu (service principal) için kms:GenerateDataKey* iznine izin vermeli ve her tüketicinin (Athena, güvenlik mühendisleri, Lambda ayrıştırıcıları) o anahtar üzerinde kms:Decrypt iznine sahip olması gerekir. Yaygın bir kesinti senaryosu: loglar sorunsuz bir şekilde teslim edilir, ancak sorgu rolü log şifreleme CMK’sinde Decrypt iznine sahip olmadığı için Athena sorguları “AccessDenied” hatası döndürür. Bunu şifrelemeyi devre dışı bırakarak değil, anahtar politikası üzerinde düzeltin.

CloudWatch Logs, Metrik Filtreleri ve Gerçek Zamanlı Alarmlama

CloudTrail, S3’e 5 ila 15 dakikalık toplu işlemlerle teslimat yapar. Bu, geriye dönük denetim için yeterli olsa da gerçek zamanlı tespit için çok yavaştır. Hassas olaylar için alarm oluşturmak amacıyla, iz (trail) kaydını CloudWatch Logs‘a (bir iz seçeneğidir) akış olarak gönderin veya belirli olayları EventBridge aracılığıyla yönlendirin. CloudWatch Logs yaklaşımı, JSON olaylarıyla desen eşleştirmesi yapan ve bir CloudWatch metriğini artıran metrik filtreleri kullanır. Bu metrik daha sonra bir CloudWatch Alarmı’nı ve SNS bildirimini tetikler. Bunun en bilinen örneği, root konsol oturum açma işlemidir:

{ $.eventName = "ConsoleLogin" && $.userIdentity.type = "Root" }

EventBridge, dar kapsamlı ve iyi bilinen olaylar (KMS anahtarının devre dışı bırakılması, IAM ilkesi değişiklikleri gibi) için genellikle daha iyidir çünkü kurallar, herhangi bir Logs maliyeti olmadan doğrudan Lambda’yı veya Step Functions’ı tetikleyebilir. Toplu sayımlara veya pano (dashboard) oluşturmaya ihtiyacınız olduğunda metrik filtrelerini kullanın.

CloudWatch Logs’daki saklama (retention) süresi varsayılan olarak Asla Sona Ermez (Never Expire) şeklindedir; bu hem maliyetlidir hem de nadiren doğru bir seçimdir. Her bir log grubu için (aws logs put-retention-policy), uyumluluk rejimine uygun olarak açık bir saklama süresi belirleyin. Yaygın uygulama, 90 gün boyunca CloudWatch’ta sıcak (hot) tutmak ve uzun vadeli arşivi bir abonelik filtresi veya Kinesis Data Firehose aracılığıyla S3’te saklamaktır.

Hassas veri hijyeni için, hesap seviyesinde CloudWatch Logs veri koruma ilkeleri uygulayın. Bunlar, alım (ingestion) sırasında eşleşen dizeleri maskelemek için yönetilen veri tanımlayıcılarını (kredi kartı numaraları, AWS gizli anahtarları, SSN’ler) kullanır. En önemlisi, maskeyi kaldırmak logs:Unmask iznini gerektirir; bu izni yalnızca bir acil durum (break-glass) rolüne verin. Unmask iznine sahip olmayan ancak log grubunu okuyabilen kullanıcılar yalnızca yıldız işaretleri görür. Hesap genelindeki bir ilke, mevcut ve gelecekteki tüm log gruplarına uygulanır ki bu doğru bir kontroldür. Grup başına ilkeler, yeni hizmetler yeni gruplar oluşturdukça zamanla tutarsızlaşabilir.

Büyük Ölçekte Log Sorgulama: Insights ve Athena

İki sorgu motoru, farklı veri katmanlarına hitap eder.

• CloudWatch Logs Insights, halihazırda CloudWatch Logs’ta bulunan verileri amaca özel bir sorgu dili kullanarak sorgular. Yakın zamandaki operasyonel veriler (Lambda logları, Logs’taki VPC Akış Logları, uygulama logları) için idealdir. Hızlıdır, şema kurulumu gerektirmez, ancak CloudWatch saklama süresi ve taranan GB başına maliyet ile sınırlıdır.

• Amazon Athena, S3’teki verilere karşı Presto/Trino SQL çalıştırır. CloudTrail, ALB erişim logları, S3’te depolanan VPC Akış Logları ve CloudFront logları üzerindeki büyük ölçekli adli (forensic) sorgular için idealdir. Taranan TB başına 5$ maliyeti vardır; tarama maliyetini önemli ölçüde düşürmek için tarihe/Bölgeye (Region) göre bölüm projeksiyonu (partition projection) veya Glue bölümlerini kullanın.

Tipik bir adli kullanım senaryosu: bir KMS anahtarını kimin devre dışı bıraktığını belirlemek. CloudTrail JSON’u iç içe (nested) olduğundan, CloudTrail tarafından oluşturulan Athena tablosu userIdentity alanını bir struct olarak sunar:

SELECT eventTime,
       userIdentity.arn                                         AS principal,
       userIdentity.sessionContext.sessionIssuer.arn            AS assumed_role,
       userIdentity.sessionContext.attributes.mfaAuthenticated  AS mfa,
       sourceIPAddress,
       requestParameters
FROM   cloudtrail_logs
WHERE  eventName = 'DisableKey'
  AND  eventTime BETWEEN '2024-05-01T03:00:00Z' AND '2024-05-01T03:30:00Z';

ALB bot analizi için, ALB erişim loglarını S3’e etkinleştirin, log öneki (prefix) üzerinde bir Athena tablosu tanımlayın, ardından bilinen kötü amaçlı IP’lerin bulunduğu bir tabloyla birleştirin (join) ve toplam sonucu QuickSight’ta görselleştirin. QuickSight, verileri Athena’dan okur, bu nedenle işlem hattı (pipeline) şöyledir: ALB → S3 → Athena → QuickSight. ALB loglarını CloudWatch Logs Insights’a göndermek, desteklenen yerel bir yol değildir — ALB logları yalnızca S3’e gönderilir.

VPC Akış Logları her iki hedefe de gidebilir: filter dstPort=3389 and action="REJECT" türündeki taktiksel araştırmalar için Logs’u, aylık ölçekteki trend sorguları için ise S3’ü (Parquet formatında, bölümlenmiş olarak) seçin.

Audit Manager Kanıt Toplama

AWS Audit Manager, PCI DSS, HIPAA, SOC 2 ve CIS gibi çerçevelerle (framework) eşleştirilmiş sürekli kanıt toplamayı otomatikleştirir. Config kurallarından, Security Hub bulgularından, CloudTrail olaylarından ve kaynak envanterinden kanıtları çeker ve bunları kontrol değerlendirmeleri altında paketler. Organizations yönetim hesabında veya delege edilmiş yönetici hesabında etkinleştirildiğinde, tüm üye hesaplardan veri toplayarak bir değerlendirme raporu oluşturur. Bu rapor, denetçilerin manuel ekran görüntüleri yerine kabul ettiği, bir manifestosu olan sıkıştırılmış bir kanıt paketidir. Bir senaryo sürekli, çoklu hesaplı, çerçeve uyumlu kanıt istediğinde doğru cevap budur: Tek başına Config, kaynak uyumluluğu sağlar ancak çerçeve eşleştirmesi sunmaz; Security Hub bulgular verir ancak değerlendirme paketlemesi yapmaz; kendi geliştirdiğiniz bir Athena raporu ise sürekli değildir.

Tuzak Özeti

• Eksik loglar için CloudTrail’i suçlamak genellikle yanlıştır: bucket mevcut olmayabilir, bucket policy’si CloudTrail principal’ını reddediyor olabilir veya nesne sahipliği (object ownership) yanlış yapılandırılmış olabilir. Önce S3’ü kontrol edin.

• Tek Bölgeli (single-Region) bir trail daha ucuz gibi görünse de eksik bir denetim geçmişi oluşturur; kuruluş genelinde kapsama için varsayılan doğru cevap çok Bölgeli (multi-Region) olandır.

• SSE-KMS ile şifrelenmiş loglar, CMK policy’si bu principal’lara kms:Decrypt izni vermediği sürece Athena, Lambda ayrıştırıcıları veya mühendisler tarafından görülemez — çözümü şifrelemeyi devre dışı bırakmak değil, anahtar politikasını (key policy) düzeltmektir.

Pratik Problem: Kullanım Senaryosu

Senaryo: Meridian Financial; production, staging ve özel bir loglama hesabına sahip çoklu hesaplı bir AWS Organization yapısı işletmektedir. Ortamları, müşteriye yönelik API’leri, analitik sistemlerini ve IAM tarafından yönetilen gizli bilgileri (secrets) barındırmaktadır. Olay müdahalesini (incident response) ve uyumluluk taleplerini desteklemek için merkezi, kurcalamaya karşı korumalı (tamper-evident) loglamaya ve hızlı araştırma araçlarına ihtiyaç duymaktadırlar.

Zorluk: Yakın zamanda gerçekleşen şüpheli bir dizi konsol girişi ve IAM policy değişikliği saatlerce fark edilmedi. Log bütünlüğünün ve zamanında uyarı mekanizmalarının, adli yeniden yapılandırma (forensic reconstruction) ve Audit Manager kanıt toplama için yetersiz olduğuna dair endişeler bulunmaktadır.

Önerilen Yaklaşım:

1. Tüm bölgelerde bir AWS Organizations CloudTrail (organization trail) etkinleştirin, CloudTrail log dosyası bütünlük doğrulamasını (log file integrity validation) açın, logları ve özet dosyalarını (digest files) merkezi bir S3 bucket’ına teslim edin. Bu bucket, şifre çözme yetkisini küçük bir güvenlik ekibiyle sınırlayan bir key policy’ye sahip bir KMS CMK ile şifrelenmeli ve S3 erişim loglaması (access logging) ile sürüm oluşturma (versioning) etkinleştirilmelidir.
2. Yönetim (management) ve seçili veri (data) olaylarını CloudWatch Logs’a akışla göndermesi için CloudTrail’i yapılandırın. Ardından, yüksek riskli desenler (yeni IP’lerden başarısız konsol girişleri, CreateUser, PutRolePolicy) için CloudWatch Logs metrik filtreleri oluşturun ve anlık bildirim (paging) ile otomatik bir Lambda playbook’u için bu filtrelere CloudWatch Alarms’ı SNS topic’lerine bağlayın.
3. Yakın zamandaki olayların interaktif olarak araştırılması için CloudWatch Logs Insights panoları (dashboards) dağıtın ve kanıtları politikaya uygun olarak saklamak için loglama hesabında saklama (retention) ve yaşam döngüsü (lifecycle) kuralları belirleyin.
4. AWS Glue ile CloudTrail S3 nesnelerini kataloglayın ve büyük ölçekli geriye dönük analizler yapmak ve araştırmacılar için CSV formatında kanıt çıktıları üretmek amacıyla (bölge/tarih/servise göre bölümlenmiş - partitioned) Athena sorguları çalıştırın.
5. CloudTrail, AWS Config ve IAM kanıtlarını otomatik olarak bir kanıt klasörüne (evidence folder) toplayan ve uyumluluk denetçileri için periyodik dışa aktarımlar planlayan bir AWS Audit Manager değerlendirmesi (assessment) oluşturun.

Gerekçe: CloudTrail’i merkezileştirmek ve doğrulamak, gerçek zamanlı metrik filtreleri ve alarmlar için CloudWatch’a akış sağlamak ve ölçeklenebilir sorgular için Athena/Logs Insights kullanmak; tespit, değişmez (immutable) loglama ve adli hazırlık (forensic readiness) için AWS en iyi uygulamalarını takip eder. Audit Manager ise denetimler için kanıt toplama sürecini otomatikleştirir.

← Tehdit Tespiti ve Uyarı · Tüm alanlar · Şifreleme →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Amazon'a göz atın →