Amazon SCS-C02: Olay Müdahalesi ve Adli Bilişim — Çalışma kılavuzu
Ş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.
Güvenliği İhlal Edilmiş EC2 Instance’larının İzolasyonu
Bir EC2 instance’ının güvenliğinin ihlal edildiğinden şüphelenildiğinde ilk operasyonel hedef, delilleri yok etmeden kontrol altına almaktır. AWS’te kontrol altına alma, instance’ın ağ erişimini, yaşam döngüsü bağlantılarını ve müdahale ekiplerinin erişilebilirliğini etkileyen katmanlı bir aktivitedir.
Standart izolasyon sırası, instance’ın security group’unu sıkılaştırmakla başlar. İdeal olarak her instance’ın kendine özel bir security group’u olduğundan, ingress ve egress kurallarını yalnızca adli bilişim ekibinin (veya özel bir teşhis security group’unun) ona ulaşmasına izin veren minimum bir setle değiştirebilirsiniz. Eğer instance bir Application Load Balancer arkasındaysa veya bir hedef grubundaysa, önce kaydını silin; eğer bir Auto Scaling grubunun üyesiyse, ASG’nin hemen bir yenisini başlatmasını veya daha kötüsü, “sağlıksız” instance’ı soruşturmanın ortasında sonlandırmasını önlemek için --should-decrement-desired-capacity bayrağıyla gruptan ayırın.
aws autoscaling detach-instances \
--instance-ids i-0abc123 \
--auto-scaling-group-name web-asg \
--should-decrement-desired-capacity
aws elbv2 deregister-targets \
--target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web/abc \
--targets Id=i-0abc123
aws ec2 modify-instance-attribute \
--instance-id i-0abc123 \
--disable-api-termination
Sonlandırma korumasını (termination protection) etkinleştirmek çok önemlidir, çünkü iyi niyetli bir operatör, bir otomasyon betiği veya bir ASG scale-in olayı, korumaya çalıştığınız volume’leri yok edebilir. Sonlandırma koruması, ASG’den ayırmanın yerini tutmaz — bir ASG, siz instance’ı grubun kapsamından çıkarmadığınız sürece, scale-in sırasında korumalı instance’ları yine de sonlandırabilir.
Anında giden trafiği kesmeniz gereken alt ağ seviyesinde kontrol altına alma durumlarında (örneğin, bilinen kötü amaçlı IP’lere sinyal gönderen bir instance), alt ağın network ACL’ine ilk numaralı kural olarak açık bir “tümünü reddet” giden kuralı ekleyebilirsiniz. Bu, stateless (durum bilgisi tutmayan) bir işlemdir ve security group değişikliklerinin aksine tüm akışlarda anında etkili olur (security group’lar yalnızca yeni akışları etkiler). Adli bilişim erişim yolunuz bir teşhis SG’si aracılığıyla kurulduktan sonra, müdahale ekibinin alt ağının hedefe SG izin listesi üzerinden ulaşabilmesi için NACL reddetme kuralı kaldırılabilir.
Geçici ve Kalıcı Delillerin Korunması
Geçici deliller — proses listeleri, açık ağ soketleri, yüklenmiş çekirdek modülleri, bellek içerikleri, tmpfs içerikleri — instance durduğu anda yok olur. Kalıcı deliller EBS üzerinde yaşar ve durdurma/başlatma işlemlerinden etkilenmez, ancak volume’ler ayrılırsa veya instance snapshot alınmadan sonlandırılırsa yine de kaybolabilir. İşlem sırası kuralı: önce instance çalışır durumdayken geçici artefaktları toplayın, ardından EBS snapshot’larını alın.
Geçici artefakt toplama işlemi, bir insanın etkileşimli bir shell’de komut yazması yerine, betik haline getirilmeli ve SSM Run Command aracılığıyla yürütülmelidir. Run Command; komutun çağrılmasını, parametreleri, yürüten principal’ı ve çıktıyı CloudWatch Logs veya S3’e kaydeder. Bu kayıt, kendi başına delil zinciri kaydının bir parçası haline gelir.
Pratik Problem: Kullanım Senaryosu
Senaryo: Meridian Financial, müşteri odaklı web uygulamalarını tek bir AWS hesabında, birden fazla VPC’de, Application Load Balancer’ların arkasındaki Auto Scaling gruplarını, EBS tabanlı EC2 instance’larını, merkezi CloudTrail ve CloudWatch loglamasını, GuardDuty’yi ve KMS ile şifrelenmiş S3 tabanlı bir log arşivini kullanarak çalıştırmaktadır. Güvenlik operasyonları ekibi, uzaktan yönetim için AWS Systems Manager kullanmakta ve yedekleri ile snapshot’ları özel bir kurtarma hesabında saklamaktadır.
Problem: Üretimdeki bir EC2 instance’ı, şüpheli giden trafik ve beklenmedik proses aktivitesi ile güvenlik ihlali belirtileri göstermektedir. Ekibin, denetim izlerini yok etmeden adli bilişim analizi için hem geçici bellek hem de kalıcı disk delillerini koruyarak instance’ı izole etmesi gerekmektedir.
Önerilen Yaklaşım:
- Auto Scaling ve ELB API’lerini kullanarak instance’ı hedef gruplarından ayırın ve Auto Scaling süreçlerini askıya alın, ardından kısıtlayıcı bir Security Group (tüm gelen/giden trafiği reddet) uygulayın ve AWS Systems Manager Session Manager aracılığıyla yönetimi sürdürürken ağ erişimini izole etmek için instance’ın Network ACL kurallarını güncelleyin.
- AWS Systems Manager Run Command kullanarak, RAM dökümünü bağlı, şifreli bir EBS volume’üne veya doğrudan SSE-KMS ile şifrelenmiş ve saklama için S3 Object Lock etkinleştirilmiş bir S3 bucket’ına yazan bir guest içi bellek yakalama (ör. LiME) işlemi yürütün.
- Bağlı tüm volume’lerin belirli bir anın EBS snapshot’larını yakalamak için EC2 CreateSnapshot (veya CreateImage) kullanın, ardından delil zincirini korumak ve kurcalanmasını önlemek için bu snapshot’ları ayrı bir AWS hesabına veya başka bir bölgeye kopyalayın.
- Özel bir izleme EC2’sine paket yakalamaları toplamak için instance ENI’ı için VPC Traffic Mirroring’i etkinleştirin veya alın ve eş zamanlı olarak VPC Flow Logs, ELB erişim logları, CloudTrail, CloudWatch Logs ve GuardDuty bulgularını güvenli S3 arşivine aktarın.
- Toplanan tüm artefaktları AWS Security Hub’da veya bir ticket sisteminde etiketleyin ve envanterini çıkarın, S3 nesnelerinin şifrelendiğinden ve Object Lock’un ayarlandığından emin olun ve IAM erişimini küçük bir adli bilişim ekibiyle kısıtlarken tüm erişimi CloudTrail aracılığıyla kaydedin.
Gerekçe: Görüntüleri almadan önce ağ erişimini izole etmek daha fazla bulaşmayı önlerken, SSM kullanmak yeni ağ vektörleri açmaktan kaçınır; önce geçici belleği yakalamak ve ardından değiştirilemez EBS snapshot’ları ve güvenli S3 arşivleri oluşturmak, AWS olay müdahalesi en iyi uygulamalarına uygun olarak delil bütünlüğünü ve delil zincirini korur.
# ssm-document: capture-volatile.yml
schemaVersion: '2.2'
description: Collect volatile artifacts from a suspect Linux host
mainSteps:
- action: aws:runShellScript
name: volatileCapture
inputs:
runCommand:
- TS=$(date +%s)
- mkdir -p /var/ir/$TS && cd /var/ir/$TS
- ps auxfww > processes.txt
- ss -tanp > sockets.txt
- lsof -n > openfiles.txt
- cat /proc/mounts > mounts.txt
- lsmod > modules.txt
- dd if=/dev/mem of=mem.raw bs=1M 2>/dev/null || true
- aws s3 cp . s3://ir-evidence-bucket/$INSTANCE_ID/$TS/ --recursive
Geçici delillerin toplanmasından hemen sonra, bağlı her EBS volume’ünün snapshot’ını alın. Snapshot’ları olay tanımlayıcısı ile etiketleyin, böylece şüpheye yer bırakmayacak şekilde vakayla ilişkilendirilirler.
aws ec2 create-snapshot \
--volume-id vol-0def456 \
--description "IR-2024-0917 root volume i-0abc123" \
--tag-specifications 'ResourceType=snapshot,Tags=[
{Key=IncidentId,Value=IR-2024-0917},
{Key=SourceInstance,Value=i-0abc123},
{Key=Handler,Value=jdoe}]'
Instance’ın kendisini aynı olay ticket’ı, araştırmacının adı ve Karantina gibi bir durum etiketi ile etiketleyin. Tutarlı metaveri etiketlemesi, delil zinciri için AWS’e özgü bir mekanizmadır — sorgulanabilir, IAM condition key’leri aracılığıyla değiştirilemez ve kaynakla ilgili her CloudTrail olayında görünür.
Session Manager ve Run Command ile Canlı Müdahale
İnce ama sınav için kritik bir nokta: mevcut SSH oturumları, güvenlik grubu kuralının kaldırılmasından etkilenmez. Güvenlik grupları durum bilgilidir (stateful) ve kuralları bağlantı kurulurken değerlendirir; önceden kurulmuş bir TCP oturumu, ona izin veren gelen (ingress) kuralı silindikten sonra bile akmaya devam eder. Eğer müdahale eden bir kişi, erişim için kendi SSH oturumuna güvenirken bir instance’ı SG kurallarını kaldırarak izole ederse, bu oturum çalışmaya devam eder — ta ki bağlantı kopana kadar. Bu noktada erişimini kaybeder ve herhangi bir bastion veya anahtar tabanlı yeniden giriş imkansız hale gelir.
Doğru yöntem, adli bilişim ekibine SSM Session Manager üzerinden erişim vermektir; bu yöntem herhangi bir gelen (inbound) portun açık olmasını gerektirmez. Session Manager, SSM Agent’ın SSM, EC2 Messages ve SSM Messages uç noktalarına (endpoints) yaptığı giden (outbound) bağlantı üzerinden çalışır (ideal olarak VPC arayüz uç noktaları aracılığıyla, böylece izole edilen instance’ın internet rotasına ihtiyacı kalmaz). ssm:UpdateInstanceInformation ve mesajlaşma API’lerine izin veren bir instance profili ekleyin ve müdahale edenlere, karantinaya alınmış instance için etikete göre kapsamlandırılmış ssm:StartSession izni verin.
Session Manager oturumlarına SSM kontrol düzlemi (control plane) aracılık ettiği için, güvenlik grubunun gelen (ingress) kurallarını sıkılaştırmak veya tamamen boşaltmak bu oturumları etkilemez ve her tuş vuruşu S3 veya CloudWatch Logs’a kaydedilebilir — bu da onu bir kara kutu değil, denetlenebilir bir interaktif oturum yapar.
Hesaplar Arası Şifreli Snapshot Kurtarma
Olgunlaşmış ortamlarda, adli bilişim snapshot’ları, güvenliği ihlal edilmiş iş yükü hesabından izole edilmiş, özel bir adli bilişim hesabına yönlendirilir. Snapshot’ları hesaplar arasında paylaşmak iki şey gerektirir: snapshot hedef hesapla paylaşılmalıdır (modify-snapshot-attribute --create-volume-permission) ve eğer snapshot müşteri tarafından yönetilen bir KMS anahtarı (CMK) ile şifrelenmişse, KMS anahtar politikası adli bilişim hesabındaki principal’lara kms:Decrypt, kms:CreateGrant ve kms:DescribeKey izinlerini vermelidir. AWS tarafından yönetilen aws/ebs anahtarıyla şifrelenmiş snapshot’lar hesaplar arasında paylaşılamaz — önce bir kopyalama işlemi aracılığıyla bir CMK ile yeniden şifrelemeniz gerekir. Adli bilişim hesabında, paylaşılan snapshot’ı kopyalayın ve yerel bir adli bilişim CMK’sı altında yeniden şifreleyin; böylece sonraki volume oluşturma işlemleri kaynak hesaba bağımlı kalmaz.
Müdahale Planı (Playbook) Tasarımı ve Ek Yükü Azaltma
Sınırlama adımlarını, EventBridge aracılığıyla GuardDuty veya Security Hub bulguları tarafından tetiklenen bir SSM Automation dokümanı veya Step Functions iş akışı olarak kod haline getirin. Tek bir otomasyon şunları yapmalıdır: (1) Run Command aracılığıyla geçici (volatile) verileri yakalamak, (2) volume’lerin olay etiketleriyle snapshot’ını almak, (3) sonlandırma korumasını (termination protection) etkinleştirmek, (4) ASG’den ayırmak ve ELB hedeflerinden kaydını silmek, (5) mevcut SG’yi karantina SG’si ile değiştirmek ve (6) instance’ı talep (ticket) ID’si ile etiketlemek. Instance’ı çalışır durumda tutmak, canlı kanıtları korur ve Session Manager aracılığıyla interaktif incelemeye olanak tanır — kapatma işlemi, otomatik sınırlamanın bir parçası olmamalı, bilinçli olarak daha sonraki bir adım olmalıdır, çünkü kapatma işlemi geçici kanıtları sıfırlar ve kötü amaçlı yazılıma gömülü temizleme mantığını tetikleyebilir.
İçselleştirilmesi gereken tuzaklar şunlardır: mevcut bir SSH oturumuna güvenirken SG kurallarını kaldırmak, müdahale eden kişiyi kör bırakır ve izolasyon konusunda yanlış bir güven hissi verir; snapshot almadan önce yerinde iyileştirme yapmak, sızıntının nasıl gerçekleştiğini yanıtlayan artefaktları yok eder; ve instance’ı ASG’sinde veya hedef grubunda bırakmak, otomatik sonlandırmaya veya daha kötüsü, olayın kapsamını gizleyen sessiz bir değiştirmeye davetiye çıkarır.
Anında Sınırlama
Bir iş yükünün güvenliğinin ihlal edildiğinden şüphelenildiğinde, verilecek ilk karar onu yerinde izole etmek mi yoksa servis dışı bırakmak mı olacağıdır. Servis dışı bırakmak — yani durdurmak veya sonlandırmak — RAM içeriği, çalışan süreçler, açık soketler gibi geçici (volatile) kanıtları ve sadece bellekte yaşayan kötü amaçlı yazılımları yok eder. Yerinde sınırlama neredeyse her zaman doğru başlangıç hamlesidir ve kontroller devreye girmeden önce bir saldırganın ek veri sızdıramayacağı veya yatay olarak yayılamayacağı kadar hızlı gerçekleşmelidir.
İki AWS’e özgü kontrol, farklı katmanlarda çalışır ve bu ayrım önemlidir. Güvenlik grupları durum bilgilidir (stateful) ve elastik ağ arayüzlerine (ENI’ler) eklenir; ağ ACL’leri (NACL’ler) ise durum bilgisi tutmaz (stateless) ve alt ağlara (subnet) eklenir. Bir instance’ın güvenlik gruplarını kilitlenmiş bir “karantina” SG’si ile değiştirmek cerrahi bir yaklaşımdır — aynı alt ağdaki diğer iş yüklerini rahatsız etmeden bir ENI’yi izole eder ve instance’ın çalışma zamanı durumunu korur. Ancak, güvenlik grubu değişiklikleri yalnızca ENI’ye ulaşan yeni akışları etkiler ve eğer güvenliği ihlal edilmiş instance halihazırda uzun ömürlü giden bağlantılara sahipse, mevcut durum devam edebilir. NACL reddetme (deny) kuralları, alt ağ sınırında derhal yürürlüğe girer ve hızın cerrahi hassasiyetten daha önemli olduğu durumlarda — örneğin, aynı alt ağdaki birkaç instance olaya karıştığında veya bir saldırganın aktif oturumunun anında kesilmesi gerektiğinde — trafiği daha da hızlı bir şekilde kapatabilir. NACL’ler ayrıca, politikaların bir instance’ı doğrudan değiştirmeyi engellediği durumlarda da kullanışlıdır.
Standart bir karantina SG’si, hiçbir gelen (inbound) trafiğe izin vermez ve giden (outbound) trafiğe yalnızca com.amazonaws.<region>.ssm, com.amazonaws.<region>.ssmmessages ve com.amazonaws.<region>.ec2messages için olan VPC arayüz uç noktalarına (interface endpoints) izin verir. Bu, C2 (Komuta ve Kontrol) kanallarını, veri sızdırmayı ve yatay hareketi engellerken Systems Manager Session Manager erişimini korur.
QuarantineSG:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Forensic quarantine - SSM only
VpcId: !Ref VpcId
SecurityGroupEgress:
- IpProtocol: tcp
FromPort: 443
ToPort: 443
DestinationPrefixListId: !Ref SsmEndpointPrefixList
SecurityGroupIngress: []
Kanıt Koruma Sırası
Adli bilişim değeri en geçiciden en kalıcıya doğru azaldığından, operasyonların sırası sabittir ve tartışılamaz:
Önce sonlandırma korumasını etkinleştirin.
DisableApiTermination=trueolarak ayarlanması, bir Auto Scaling olayının, bir operatör hatasının veya zamanlanmış bir eylemin soruşturma sırasında instance’ı yok etmesini önler. Ayrıca, ASG sağlık kontrollerinin onu değiştirememesi için instance’ı Auto Scaling grubundan ayırın.Auto Scaling’den ayırın veya koruyun. ASG’nin sağlıksız olduğu için sonlandırmaması amacıyla
EnterStandbykullanın veya instance’ı ayırın.Tüm bağlı EBS volümlerinin snapshot’ını alın.
CreateSnapshot(veya çoklu volüm atomik yakalama içinCreateSnapshots), değiştirilemez, şifrelenmiş bir adli bilişim yapıtı (artifact) oluşturur. Snapshot’ları olay ID’si, kaynak instance ID’si, zaman damgası ve analist ile etiketleyin. Hesap ele geçirilmesi durumunda korunmaları için snapshot’ları güvenlik ekibine ait özel bir adli bilişim hesabına kopyalayın.Belleği yakalayın. Bir bellek toplama aracını (Linux’ta LiME, AVML; Windows’ta WinPMEM) çağırmak ve imajı uyumluluk modunda (compliance mode) Object Lock özelliğine sahip bir S3 adli bilişim bucket’ına akışla göndermek için bir SSM
RunCommanddokümanı kullanın. Bellek, instance hala çalışır durumdayken yakalanmalıdır — durdurulmuş bir instance’ın alınacak bir RAM’i yoktur.Meta verileri toplayın. Instance ID, AMI, IAM instance profili, VPC/subnet, ENI ID’leri, etiketler, çalışan süreç listesi,
netstatçıktısı ve IMDS içeriklerini kaydedin. Aşağı yönlü otomasyonların ve insan operatörlerin durumunu tanıması için instance’ıStatus=QuarantinedveIncidentId=<id>olarak etiketleyin.Soruşturma çevrimdışı disk analizi gerektiriyorsa, ancak o zaman instance’ı durdurun. Durdurma işlemi belleği siler, bu nedenle bu her zaman son adımdır.
aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
aws autoscaling enter-standby --instance-ids i-0abc \
--auto-scaling-group-name app-asg --should-decrement-desired-capacity
aws ec2 create-snapshots --instance-specification InstanceId=i-0abc \
--description "IR-2024-071 forensic" --copy-tags-from-source volume
aws ssm send-command --instance-ids i-0abc \
--document-name "AWS-RunShellScript" \
--parameters 'commands=["avml /tmp/mem.lime && aws s3 cp /tmp/mem.lime s3://forensics-bucket/"]'
Otomatikleştirilmiş Olay Müdahale (IR) İş Akışları
GuardDuty bulguları, saatler içinde değil, saniyeler içinde kontrol altına almayı tetiklemelidir. Standart ardışık düzen (pipeline) EventBridge → Lambda → SSM Automation şeklindedir ve bildirimler için SNS kullanılır.
Bir EventBridge kuralı, source: aws.guardduty ile eşleşir, detail-type olarak GuardDuty Finding kullanır ve UnauthorizedAccess:EC2/*, Backdoor:EC2/*, Trojan:EC2/* ve CryptoCurrency:EC2/* gibi EC2 ile ilgili bulgu türlerine göre filtreleme yapan bir desen (pattern) içerir.
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": {
"type": [{"prefix": "UnauthorizedAccess:EC2/"},
{"prefix": "Backdoor:EC2/"},
{"prefix": "Trojan:EC2/"}]
}
}
Lambda hedefi, detail.resource.instanceDetails.instanceId yolundan instance ID’sini çıkarır, ardından şunları yapmak için bir SSM Automation dokümanını çağırır (veya doğrudan SDK’yı çağırır): sonlandırma korumasını etkinleştirme, ModifyNetworkInterfaceAttribute aracılığıyla ENI güvenlik gruplarını karantina SG’si ile değiştirme, tüm bağlı volümlerin snapshot’ını alma, instance’ı etiketleme ve SOC kanalına bir SNS mesajı yayınlama. Ham SDK çağrıları yerine SSM Automation kullanmak, Automation yürütme geçmişinde adım adım denetim izleri sağlar.
Veri Sızdırma ve C2 Analizi için Günlükleme
Telemetri olmadan kontrol altına alma, tahminden ibarettir. VPC Flow Logs, VPC veya subnet seviyesinde trafik türü ALL (hem ACCEPT hem de REJECT) olarak ayarlanarak etkinleştirilmelidir. REJECT kayıtları taramaları, engellenen veri sızdırma girişimlerini ve bilinen kötü IP’lere ulaşmaya çalışan C2 işaretlerini (beacon) ortaya çıkarır; ACCEPT kayıtları ise hangi akışların başarılı olduğunu gösterir. Akış günlüklerini gerçek zamanlı sorgular için CloudWatch Logs’a ve Object Lock ile uzun süreli saklama için S3’e yönlendirin. Adli bilişim S3 bucket’ı ve KMS üzerindeki veri olayları (data events) ile CloudTrail, kanıt yönetimi için denetim zincirini sağlar. Yalnızca akış günlüklerinin kaçıracağı DGA ve DNS tünellemeyi yakalamak için bunu DNS sorgu günlüklemesi (Route 53 Resolver) ile birleştirin.
Session Manager ile Kontrollü Adli Bilişim Erişimi
Session Manager, SSH anahtarlarına, bastion host’lara veya açık 22/3389 numaralı bağlantı noktalarına olan ihtiyacı ortadan kaldırır; karantina SG’sinin tüm geleneksel erişimi engelleyebilmesinin nedeni de tam olarak budur. Oturum günlüklemeyi SSE-KMS ile bir S3 bucket’ına ve CloudWatch Logs’a etkinleştirin; hiçbir oturumun TLS ve günlük şifrelemesi olmadan çalışmaması için oturum tercihlerinde EnforceEncryption=true ayarını zorunlu kılın. ssm:StartSession üzerindeki IAM politikaları, tag:Status=Quarantined etiketine sahip instance’larla sınırlandırılmalı ve yalnızca olay müdahale rolüne verilmelidir.
Yaygın Tuzaklar ve Neden Başarısız Oldukları
Önce durdurmak veya sonlandırmak. Durdurma işlemi belleği serbest bırakır, aktif bağlantıları sonlandırır ve geçici (volatile) kanıtları toplama yeteneğini ortadan kaldırır. Sonlandırma ise ek olarak,
DeleteOnTermination=falseolarak ayarlanmadığı sürece kök birimi (root volume) serbest bırakır ve bu durumda bile çalışma zamanı durumunu (runtime state) kaybedersiniz. Herhangi bir güç durumu değişikliğinden önce daima yerinde kontrol altına alın.NACL’ler daha hızlıyken yalnızca güvenlik gruplarına (security groups) güvenmek. SG değişiklikleri cerrahi hassasiyettedir ancak yalnızca bağlı oldukları ENI’yi etkiler ve yalnızca yeni akışları yönetir. Bir alt ağdaki (subnet) birden fazla sunucu etkilendiğinde veya bir saldırganın mevcut giden oturumunun derhal kesilmesi gerektiğinde, alt ağ düzeyinde bir NACL reddetme (deny) kuralı kapıyı daha hızlı kapatır çünkü NACL’ler durum bilgisi tutmaz (stateless) ve önceki durumdan bağımsız olarak her paketi engeller.
Snapshot almadan önce iyileştirme yapmak. EBS snapshot’ları oluşturmadan önce sunucuyu yeniden imajlamak, yamalamak veya değiştirmek, diskte bulunan kanıtları (kötü amaçlı yazılım ikilileri, kalıcılık mekanizmaları, loglar, zaman damgaları) yok eder. Snapshot’lar ucuzdur ve değiştirilemez (immutable); herhangi bir iyileştirme eyleminden önce bunları alın ve ele geçirilmiş bir üretim hesabının silememesi için özel bir adli bilişim (forensics) hesabına kopyalayın.
Pratik Problem: Kullanım Senaryosu
Senaryo: Meridian Financial, üretim iş yüklerinin özel bir hesapta çalıştığı çoklu hesaplı bir AWS ortamı yönetmektedir: müşteri verilerini barındıran EC2 ve EKS servisleri, arşivler için S3 bucket’ları, CloudTrail, GuardDuty, Security Hub ve Config’in etkinleştirildiği bir güvenlik hesabında merkezi loglama ve dağıtımlar için bir CI/CD ardışık düzeni (pipeline). Operasyon ekipleri, yama ve bakım için Systems Manager’ı ve genel erişim noktaları (public endpoints) için Route 53/ALB’leri kullanmaktadır.
Zorluk: Bir GuardDuty bulgusu ve beklenmedik giden trafik artışları, veri sızdırma ve şüpheli IAM API çağrıları yapan, muhtemelen ele geçirilmiş bir EC2 sunucusuna işaret etmektedir. Bu durum, adli bilişim kanıtlarını korurken ve denetlenebilir araştırmacı erişimini sürdürürken acil kontrol altına almayı gerektirir.
Önerilen Yaklaşım:
- GuardDuty bulgusu üzerine EventBridge aracılığıyla anında kontrol altına almayı tetikleyin. Bu, karantina amaçlı bir güvenlik grubunu (security group) eklemek, genel IP’leri kaldırmak veya ENI’yi ayırmak ve ilgili IAM kimlik bilgilerini IAM aracılığıyla iptal etmek/değiştirmek için bir Lambda/SSM Automation kullanan bir Step Functions iş akışını çağırır.
- Sunucunun bir EBS snapshot’ını ve AMI’sini oluşturmak, snapshot’ları özel bir adli bilişim (forensics) AWS hesabına kopyalamak ve dışa aktarılan kanıtları S3 Object Lock (uyumluluk modu) ve KMS şifrelemesi ile bir S3 bucket’ında saklamak için bir SSM Automation dokümanı çalıştırarak geçici (volatile) ve kalıcı kanıtları koruyun.
- CloudTrail yönetim ve veri olaylarının (S3, Lambda) etkinleştirildiğinden emin olarak, VPC Flow Logs, ALB/NGINX erişim logları ve Route 53 sorgu loglarını merkezi güvenlik hesabına ileterek ve zaman çizelgesi korelasyonu için bulguyu Amazon Detective’e yükselterek veri sızdırma ve C2 analizi için loglamayı yakalayın.
- Kontrol altına alma, kanıt kopyalama, olay sahiplerine SNS bildirimleri ve mevcut ITSM sisteminde bilet oluşturma işlemlerini koordine etmek için EventBridge -> Step Functions -> Lambda kullanarak orkestrasyonu ve bildirimleri otomatikleştirin.
- Canlı araştırma oturumları için, oturum loglaması CloudWatch Logs’a ve adli bilişim S3 bucket’ına yapılacak şekilde AWS Systems Manager Session Manager kullanımını zorunlu kılın. Bu erişime yalnızca MFA ve geçici kimlik bilgileri ile belirlenmiş bir adli bilişim IAM rolü için izin verin.
Gerekçe: Bu yaklaşım, tehdidi hızla izole eder, analiz için değiştirilemez (immutable) kanıtları ve merkezi logları korur, kontrol altına alma süresini azaltmak için tekrarlanabilir müdahale adımlarını otomatikleştirir ve AWS en iyi uygulamalarına göre Session Manager aracılığıyla denetlenebilir, en az ayrıcalıklı (least-privilege) adli bilişim erişimini zorunlu kılar.
← Konteyner ve Sunucusuz Güvenliği · Tüm alanlar
Bu soruları çözün → · ExamRoll.io’da süreli pratik →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Sınavınızı geçin →