Amazon SCS-C02: Uç ve Uygulama Güvenliği — Ç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.
CloudFront Coğrafi Kısıtlama ve Ülke Düzeyinde Engelleme
CloudFront, trafiği ülkeye göre engellemek için iki mekanizma sunar ve bunlar arasında seçim yapmak maliyet ve işlevsellik açısından önemlidir. Yerleşik coğrafi kısıtlama (geo restriction) özelliği (coğrafi engelleme veya geoblocking olarak da adlandırılır) doğrudan dağıtım üzerinde yapılandırılır ve istekleri edge’de, izleyicinin IP’sinden türetilen bir ülke izin listesi veya engelleme listesine göre değerlendirir. Ücretsizdir, kural değerlendirmesi gerektirmez ve herhangi bir origin getirme işlemi gerçekleşmeden önce HTTP 403 döndürür. “X ülkesinden gelen ziyaretçileri engelle” gibi basit uyumluluk senaryoları için bu en ucuz ve en basit seçenektir.
Alternatif ise daha esnek olan bir WAF coğrafi eşleştirme ifadesidir (geo match statement): ülke eşleşmelerini URI yolları, başlıklar, hız limitleri ile birleştirebilir veya bunları tersine çevirebilirsiniz (“A ülkesine yalnızca /admin için izin ver”). Mantık koşullu olduğunda WAF gereklidir; tek başına coğrafi kısıtlama “X ülkesini yalnızca belirli bir yol için engelle” ifadesini karşılayamaz. Gereksinim düz bir ülke engellemesi olduğunda ve WAF’ın istek başına maliyetinden kaçınmak istediğinizde yerel coğrafi kısıtlamayı seçin.
Özel İçerik için Signed URL’ler ve Signed Cookie’ler Karşılaştırması
CloudFront, origin’i (S3 bucket, ALB veya Media origin) bir origin access control veya özel başlık (custom header) arkasında gizli tutarken yetkilendirilmiş özel içeriği sunmak için iki yolu destekler:
Signed URL’ler: her URL bir imza ve politika taşır. Tek dosyalık bir indirme veya dosya başına erişim kontrolüne ihtiyaç duyduğunuz durumlar için (örneğin, tek seferlik bir yazılım yükleyici bağlantısı) idealdir.
Signed cookie’ler: istemci, kimlik doğrulama hizmetiniz tarafından bir kez olmak üzere
CloudFront-Policy,CloudFront-SignatureveCloudFront-Key-Pair-Idcookie setini alır. Eşleşen yol desenlerine yapılan sonraki tüm istekler, URL’leri yeniden yazmaya gerek kalmadan otomatik olarak yetkilendirilir.
Tek bir oynatma oturumunun bir manifest tarafından referans verilen binlerce .ts segmentini getirdiği HLS video akışı için, signed cookie’ler çok daha basittir. Manifest’teki her segment URL’sini ayrı bir signed URL ile yeniden yazmak mümkündür, ancak bu gecikme ve karmaşıklık ekler. Abone, dahili kullanıcı deponuzda kimlik doğruladıktan sonra, akış yolu desenine göre kapsamlandırılmış cookie’yi ayarlayın.
Joker karakterli (wildcard) bir signed cookie için standart bir politika şuna benzer:
{
"Statement": [{
"Resource": "https://d123.cloudfront.net/videos/*",
"Condition": {
"DateLessThan": {"AWS:EpochTime": 1735689600},
"IpAddress": {"AWS:SourceIp": "203.0.113.0/24"}
}
}]
}
Kullanıcıların CloudFront’u atlayıp doğrudan origin’e erişememesi için bunu bir origin access control (OAC) veya origin’de WAF tarafından doğrulanan gizli bir özel başlık ile eşleştirin.
AWS WAF: Yönetilen Kurallar, ATP ve Hız Tabanlı Kurallar
İş yükü CloudFront’un arkasındaysa, Web ACL’yi bölgesel bir ALB yerine CloudFront dağıtımına ekleyin. Edge’e ekleme, kötü niyetli istekleri yüzlerce POP’tan (Point of Presence) birinde, yani saldırgana daha yakın bir noktada, sonlandırır. Bu, DDoS sırasında origin yükünü azaltır ve engellenen trafik VPC’nizden asla geçmediği için origin’den çıkan trafiği (egress) düşürür. WAF’ı yalnızca ALB’ye eklemek, hacimsel saldırının yine de Bölgesel load balancer’a ulaşacağı, LCU’ları tüketeceği ve Bölgeler arası saldırıların küresel edge ağı yerine tek bir Bölge tarafından ele alınacağı anlamına gelir.
Birleştirilecek temel kural grupları:
AWS tarafından yönetilen kural setleri:
AWSManagedRulesCommonRuleSet(OWASP top-10 tarzı),AWSManagedRulesKnownBadInputsRuleSetveAWSManagedRulesAmazonIpReputationList, neredeyse sıfır ayarlama ile geniş bir kapsama alanı sağlar.Hesap Ele Geçirme Önleme (ATP):
AWSManagedRulesATPRuleSet, belirttiğiniz giriş uç noktasını (login endpoint) denetler, kimlik bilgisi doldurma (credential stuffing) kalıplarını izler, gönderilen kimlik bilgilerini ele geçirilmiş kimlik bilgileri veritabanıyla karşılaştırır ve sızdırılmış şifreleri yeniden kullanan botları engeller. Bunu, kullanıcı adı ve şifre için tam giriş yolu ve JSON gövdesi alan adlarıyla yapılandırın.Hız tabanlı kurallar (Rate-based rules): 5 dakikalık bir pencerede herhangi bir tek IP’den gelen istek sayısını sınırlar (örneğin 2.000 istek). Bunları URI veya metoda göre kapsamlandırın; böylece
/searchyolunun kazınması (scraping),/yolundaki anonim gezinmeyi etkilemez. Hız kuralları, Katman 7 hacimsel saldırılarını ve kaba kuvvetle listeleme (brute-force enumeration) denemelerini azaltır.
Kısaltılmış bir WAF kural bloğu:
Rules:
- Name: RateLimitLogin
Priority: 1
Action: { Block: {} }
Statement:
RateBasedStatement:
Limit: 500
AggregateKeyType: IP
ScopeDownStatement:
ByteMatchStatement:
SearchString: /api/login
FieldToMatch: { UriPath: {} }
PositionalConstraint: STARTS_WITH
TextTransformations: [{ Priority: 0, Type: LOWERCASE }]
ACM Sertifikaları, DNS Doğrulaması ve CloudFront
CloudFront için sertifika, origin’inizin nerede bulunduğuna bakılmaksızın ACM’de us-east-1 (N. Virginia) bölgesinde sağlanmalıdır — bu kesin bir gerekliliktir çünkü CloudFront, sertifikaları o Bölgeden okuyan küresel bir hizmettir. ALB gibi bölgesel hizmetler, ALB’nin kendi Bölgesinden okuma yapar.
Otomatik olarak yenilemek istediğiniz herhangi bir genel sertifika için her zaman Route 53’te bir CNAME kaydı ile DNS doğrulaması kullanın. ACM, doğrulama CNAME’i yayınlandığı sürece DNS ile doğrulanmış sertifikaları otomatik olarak yeniler; Route 53 bunu çok kolaylaştırır (konsol, istek sırasında “Route 53’te kayıt oluştur” seçeneğini sunar). Buna karşılık, e-posta doğrulaması, alan adındaki beş adrese (admin@, administrator@, hostmaster@, postmaster@, webmaster@) artı WHOIS iletişim bilgisine onay gönderir. Bu posta kutuları genellikle mevcut değildir veya kurumsal posta filtreleri tarafından karantinaya alınır, bu nedenle yenilemeler sürenin dolmasından 60 gün önce başarısız olur ve önlenebilir kesintilere neden olur. E-posta doğrulama tıklamalarını otomatikleştirmenin bir yolu yoktur.
Çok Bölgeli (multi-Region) ALB’ler için doğru yenileme modeli şudur: her Bölge için DNS ile doğrulanmış bir ACM sertifikası isteyin, doğrulama CNAME’ini Route 53’te bir kez yayınlayın, sertifikayı ALB dinleyicisine (listener) ekleyin ve yenileme ile yeniden dağıtımı ACM’nin halletmesine izin verin. İnsan müdahalesi, sertifikanın düzenlenmesiyle sona erer.
DNSSEC ve Route 53
Alan adınıza yönelik DNS sahtekarlığını (spoofing) ve önbellek zehirlenmesini (cache poisoning) önlemek için Route 53 barındırılan bölgesinde (hosted zone) DNSSEC imzalamasını etkinleştirin. Route 53, KSK’yı KMS’de (us-east-1’de asimetrik bir ECC anahtarı) yönetir; DS kaydını alan adı kayıt kuruluşunda (registrar) yayınlamanız gerekir. DNSSEC imzalamanın bölgenizin çözümlenmesini koruduğunu, ancak DNS trafiğini şifrelemediğini (bu işi DoH/DoT yapar) ve CloudFront’un TLS’ini etkilemediğini unutmayın.
Yanıt Başlıkları: Politikalar ve Lambda@Edge Karşılaştırması
CloudFront, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options veya Content-Security-Policy gibi güvenlik başlıklarını otomatik olarak eklemez. Eğer origin’iniz değiştirilemiyorsa (eski bir S3 sitesi, üçüncü taraf bir origin), iki seçeneğiniz vardır:
Yanıt başlıkları politikası: yerel, bildirimsel bir CloudFront özelliğidir. HSTS, CORS, güvenlik ve özel başlıklar eklemek için bir önbellek davranışına (cache behavior) yönetilen veya özel bir politika ekleyin. Bu, varsayılan tercih olmalıdır — kod yok, soğuk başlatma (cold start) yok, çağrı başına maliyet yok.
Lambda@Edge (izleyici yanıtı veya origin yanıtı): istek başına değişen CSP nonce’ları veya istek niteliklerine göre başlıkları yeniden yazma gibi dinamik mantığa ihtiyaç duyduğunuzda kullanın. Basitlikten ödün vererek esneklik kazanır ve istek başına maliyet ekler.
Yönetilen yanıt başlıkları politikası SecurityHeadersPolicy, yaygın temel güvenlik ayarlarını tek bir eklemeyle kapsar.
Sık Karşılaşılan Hatalar ve Açıklamaları
Herkese açık ACM sertifikalarını e-posta ile doğrulama kullanarak talep etmek kırılgandır, çünkü yenileme işlemi, çoğu kuruluşun izlemediği veya spam olarak yönlendirdiği genel adreslere gönderilen postaları okuyan insanlara bağlıdır. Route 53 ile DNS ile doğrulama, insan faktörünü tamamen ortadan kaldırır.
WAF’ı sadece ALB’ye eklemek kağıt üzerinde eşdeğer görünse de saldırı trafiğini Bölgenize (Region) girmeye zorlar ve ALB kapasitesini tüketir. CloudFront üzerinde Edge’e eklenmiş WAF, yüzlerce POP’ta (varlık noktası) engelleme yapar, böylece dağıtık bir sel saldırısı küresel olarak emilir ve origin çıkış trafiği (egress) düşük kalır — bu, bir DDoS saldırısı sırasında kritik öneme sahiptir.
CloudFront’un otomatik olarak güvenlik başlıkları eklediğini varsaymak, başarısız sızma testlerine yol açar. Dağıtım, origin’in gönderdiği başlıkları aynen vekil sunucu olarak iletir; X-Frame-Options: DENY, HSTS ve CSP eklemek için açıkça bir yanıt başlıkları politikası veya Lambda@Edge fonksiyonu eklemeniz gerekir.
Pratik Problem: Kullanım Senaryosu
Senaryo: Meridian Financial, AWS üzerinde küresel olarak dağıtılmış bir müşteri portalı ve bir dahili raporlar portalı işletmektedir. Genel trafik, dinamik API’ler için Application Load Balancer’lara ve özel raporlar için S3 origin’lerine Amazon CloudFront üzerinden yönlendirilir; DNS Route 53’te, TLS sertifikaları ise AWS Certificate Manager (ACM) tarafından verilir.
Zorluk: Saldırganlar, çeşitli ülkelerden hesapları veri kazıma (scraping) ve kimlik bilgisi doldurma (credential stuffing) yöntemleriyle ele geçirmekte, özel raporları indirmek için origin uç noktalarına doğrudan erişerek CloudFront’u atlamakta ve bu durum origin’in aşırı yüklenmesine ve veri sızıntısına neden olmaktadır.
Önerilen Yaklaşım:
- CloudFront’u tek genel giriş noktası olarak yapılandırın ve sorunlu ülkeleri engellemek için CloudFront Coğrafi Kısıtlama (Geo Restriction) uygulayın; Origin Access Control (OAC) özelliğini etkinleştirin ve S3/ALB origin politikalarını kilitleyerek yalnızca CloudFront’un origin içeriğini çekebilmesini sağlayın.
- Her indirme işleminin tek tek yetkilendirilmiş ve denetlenebilir olması için, kullanıcı başına özel raporları imzalı çerezler (signed cookies) yerine CloudFront imzalı URL’ler (kısa TTL ile) kullanarak sunun.
- AWS Yönetilen Kurallarını (AWS Managed Rules) kullanarak AWS WAF’ı CloudFront dağıtımına ekleyin, AWS WAF Bot Control’ü (gelişmiş tehdit koruması) etkinleştirin ve veri kazıma ile kimlik bilgisi doldurmayı azaltmak için oran tabanlı kurallar ve CAPTCHA doğrulamaları oluşturun.
- ACM’de (CloudFront dağıtımları için us-east-1) Route 53 aracılığıyla DNS ile doğrulama kullanarak TLS sertifikaları sağlayın ve CloudFront dağıtımına Route 53 Alias kayıtları yayınlayın.
- Route 53 barındırılan bölgesinde (hosted zone) DNSSEC’i etkinleştirin, CloudFront ve WAF erişim günlüklerini S3’e kaydedecek şekilde ayarlayın ve DDoS görünürlüğü ve uyarısı için CloudWatch alarmları ve isteğe bağlı olarak AWS Shield Advanced oluşturun.
Gerekçe: Tüm trafiği OAC ve WAF ile CloudFront üzerinden geçmeye zorlamak, en az ayrıcalıkla origin erişimini sağlar; Coğrafi Kısıtlama ve oran tabanlı/WAF korumaları kötü niyetli trafiği durdurur; imzalı URL’ler nesne başına yetkilendirme sağlar ve DNSSEC ile ACM+DNS doğrulaması, AWS en iyi uygulamalarına göre güvenilir TLS ve DNS bütünlüğünü temin eder.
AWS WAF Kuralları ve ALB ile CloudFront Entegrasyonu
AWS WAF, HTTP(S) isteklerini sıralı kurallardan oluşan bir Web ACL’e göre değerlendiren bir Katman 7 güvenlik duvarıdır. Her kural, istek niteliklerini (URI, başlıklar, gövde, sorgu dizesi, kaynak IP) inceler ve sonlandırıcı bir eylem (İzin Ver, Engelle, Meydan Oku, CAPTCHA) veya sonlandırıcı olmayan bir eylem (Say) döndürür. Web ACL’ler CloudFront dağıtımlarına, Application Load Balancer’lara, API Gateway’e, AppSync’e, Cognito kullanıcı havuzlarına ve App Runner servislerine eklenir. CloudFront’a eklendiğinde ACL, edge’de çalışır ve us-east-1 (Global) kapsamında oluşturulmalıdır; ALB için ise load balancer ile aynı Bölge’de (Region) olmalıdır.
Oran tabanlı kurallar, kayan beş dakikalık bir pencere içinde tek bir IP’den (veya yönlendirilmiş bir IP başlığından ya da URI + IP kombinasyonu gibi bir toplu anahtardan) gelen istek sayısını izler. Sayı, yapılandırılan eşiği aştığında, oran tekrar limitin altına düşene kadar kural eylemi tetiklenir. AWS WAF, ihlalci listesini saniyeler içinde sürekli güncellediği için, oran tabanlı kurallar, küçük ve dönen bir IP setinden gelen yüksek hacimli kötüye kullanım için standart çözümdür — manuel olarak bir IP seti oluşturmak zorunda kalmazsınız ve ilk kural dağıtıldıktan sonra operasyonel yük neredeyse sıfırdır.
{
"Name": "RateLimitPerIP",
"Priority": 10,
"Statement": {
"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP"
}
},
"Action": { "Block": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitPerIP"
}
}
IP setleri, kurallar tarafından bir IPSetReferenceStatement ile referans gösterilen, yeniden kullanılabilir CIDR aralıkları listeleridir. Belirlenimci bir engelleme/izin verme listeniz olduğunda — örneğin, coğrafi olarak kısıtlanmış yönetici uç noktaları veya tehdit istihbaratı akışlarından gelen bilinen kötü amaçlı aralıklar — doğru temel yapı taşıdırlar. Özel kurallar, birden çok ifadeyi mantıksal AndStatement, OrStatement ve NotStatement operatörleriyle birleştirerek, “ABD dışındaki ülkelerden /login adresine yapılan ve aynı zamanda belirli bir başlığa sahip olmayan istekleri engelle” gibi koşulları ifade etmenizi sağlar.
Bir DDoS Azaltma Katmanı ve Origin Koruması Olarak CloudFront
CloudFront, trafik ALB veya EC2 filonuza ulaşmadan çok önce, hacimsel (volumetric) ve durum tüketme (state-exhaustion) saldırılarını AWS edge’de emer. Her edge lokasyonu, SYN flood ve yansıtma (reflection) saldırılarına karşı ücretsiz azaltma sağlayan AWS Shield Standard’ı otomatik olarak çalıştırır. Bir ALB’nin önüne CloudFront koymak, saldırı yüzeyini edge ağına küçültür ve edge kapsamlı WAF, coğrafi kısıtlama (geo-restriction) ve TLS sonlandırmayı (termination) mümkün kılar.
Bu azaltma, yalnızca saldırganlar doğrudan ALB DNS adına erişerek CloudFront’u atlayamazsa etkilidir. İki mekanizma bu yolu daha güvenli hale getirir. İlk olarak, CloudFront’u gizli bir özel origin başlığı (örneğin X-Origin-Verify: <random-value>) ekleyecek şekilde yapılandırın ve bu başlık değerini içermeyen herhangi bir istek için 403 döndüren bir ALB dinleyici (listener) kuralı ayarlayın. Bu gizli değeri AWS Secrets Manager aracılığıyla periyodik olarak değiştirin (rotate). İkinci olarak, ALB güvenlik grubunu, CloudFront edge IP aralıklarını içeren AWS tarafından yönetilen com.amazonaws.global.cloudfront.origin-facing ön ek listesiyle (prefix list) kısıtlayın.
ALBListenerRule:
Type: AWS::ElasticLoadBalancingV2::ListenerRule
Properties:
Actions:
- Type: fixed-response
FixedResponseConfig: { StatusCode: "403", ContentType: text/plain }
Conditions:
- Field: http-header
HttpHeaderConfig:
HttpHeaderName: X-Origin-Verify
Values: ["!Ref OriginSecret"]
- Field: http-header
HttpHeaderConfig: { HttpHeaderName: X-Origin-Verify, Values: ["*"] }
Priority: 1
Trafiği CloudFront üzerinden geçmeye zorlamadan doğrudan ALB’ye bir WAF ACL eklemek, ALB uç noktasını (endpoint) herkese açık olarak çözümlenebilir bırakır. DNS adını (sertifika şeffaflık günlükleri, geçmiş DNS kayıtları veya alt alan adı taraması yoluyla) keşfeden saldırganlar, tüm edge korumalarını atlayarak doğrudan saldırabilirler. Bu, “CloudFront + ALB” tasarımlarında yapılan en yaygın mimari hatadır.
Shield Advanced Metrikleri, Alarmları ve Bildirimleri
Shield Advanced; gelişmiş tespit, Shield Müdahale Ekibine (Shield Response Team) 7/24 erişim, saldırılar sırasında ölçeklenmeye karşı maliyet koruması ve uygulama katmanı saldırı görünürlüğü ekler. Ancak, bir saldırı meydana geldiğinde otomatik olarak e-posta veya SMS göndermez. Bildirimlerin CloudWatch aracılığıyla açıkça yapılandırılması gerekir.
Shield Advanced, AWS/DDoSProtection ad alanında (namespace) korunan her kaynak için DDoSDetected metriğini (saldırı devam ederken değeri 1 olur) ve DDoSAttackBitsPerSecond, DDoSAttackPacketsPerSecond ve DDoSAttackRequestsPerSecond metriklerini yayınlar. DDoSDetected >= 1 için bir CloudWatch alarmı oluşturun ve alarm eylemi olarak bir SNS konusu (topic) belirleyin; SNS daha sonra e-posta, SMS, sohbet (chat) veya bir Lambda yanıtlayıcısına (responder) bildirimleri dağıtır (fan out).
aws cloudwatch put-metric-alarm \
--alarm-name ShieldDDoSDetected \
--namespace AWS/DDoSProtection \
--metric-name DDoSDetected \
--statistic Maximum --period 60 --threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:111122223333:secops-alerts
Shield Advanced’in “size e-posta göndereceğini” varsaymak sık yapılan bir yanılgıdır — CloudWatch alarmı ve SNS aboneliği olmadan, tek sinyal Shield konsolu ve AWS Health Dashboard etkinliğidir.
Otomatik Lambda Engellemesi ile AWS Network Firewall
Network Firewall, alt ağ (subnet) yönlendirme tablolarından (route table) geçen trafiği denetleyen, durumsal (stateful), VPC’ye bağlı bir Katman 3–7 güvenlik duvarıdır. Politikası, durum bilgisi olmayan (stateless) ve durumsal (stateful) kural gruplarından oluşur; durumsal kural grupları Suricata uyumlu sözdizimi kullanır. Kural grupları API ile yönetildiği için, olay güdümlü (event-driven) otomasyon için ideal hedeflerdir.
Yaygın bir model, GuardDuty bulgularına (örneğin UnauthorizedAccess:EC2/RDPBruteForce veya Backdoor:EC2/C&CActivity) yanıt verir. Security Hub bulguyu toplar, EventBridge bir olay deseniyle (event pattern) eşleşir ve bir Lambda fonksiyonunu çağırır, Lambda ise saldırgan IP’yi veya güvenliği ihlal edilmiş sunucunun ENI’sini hedefleyen bir engelleme (drop) kuralı eklemek için UpdateRuleGroup‘u çağırır.
def handler(event, _):
ip = event["detail"]["findings"][0]["ProductFields"]["aws/guardduty/service/action/networkConnectionAction/remoteIpDetails/ipAddressV4"]
new_rule = f'drop ip {ip} any -> any any (msg:"GD-block"; sid:{sid()}; rev:1;)'
rg = nfw.describe_rule_group(RuleGroupArn=RG_ARN)
rules = rg["RuleGroup"]["RulesSource"]["RulesString"] + "\n" + new_rule
nfw.update_rule_group(
RuleGroupArn=RG_ARN,
UpdateToken=rg["UpdateToken"],
RulesSource={"RulesString": rules})
VPC sınırında (edge) bir EC2 sunucusuna/sunucusundan veya bir CIDR’a çift yönlü trafiği engellemeniz gerektiğinde Network Firewall doğru seçimdir — WAF yalnızca desteklenen Katman 7 uç noktalarına (endpoint) yönelik HTTP isteklerini denetler, bu nedenle giden C2 trafiğini veya HTTP olmayan protokolleri durduramaz.
Count ile Günlükleme, İzleme ve Güvenli Dağıtım
Her Web ACL’de WAF günlüklemesini etkinleştirin ve CloudWatch Logs, S3 veya Kinesis Data Firehose’a akış sağlayın. Günlükler; eşleşen kuralı, eylemi, istek başlıklarını ve (redaksiyon kurallarıyla) temizlenmiş gövdeleri içerir. Konsoldaki örneklenmiş istekler hızlı bir görünüm sunar ancak yalnızca son 3 saati ve kural başına 100 örneği saklar; denetim ve adli analiz için tam günlükler gereklidir.
Count eylemi, kuralların güvenli bir şekilde dağıtılması için elzemdir. Yeni yönetilen kural gruplarını (örneğin AWSManagedRulesCommonRuleSet veya Bot Control grubu) dağıtırken, kural eylemi geçersiz kılmalarını (rule action overrides) ilk olarak Count olarak ayarlayın. CountedRequests CloudWatch metriğini ve günlük girdilerini, yanlış pozitifler (false positives) — yani engellenecek olan meşru trafik — açısından izleyin. Yalnızca istisnaları ayarladıktan sonra eylemleri Block olarak değiştirin. Yönetilen kuralları bir Count aşaması olmadan doğrudan Block modunda dağıtmak, SizeRestrictions_BODY gibi bir kuralın meşru bir büyük yükleme uç noktasını engellemesi veya CrossSiteScripting_BODY kuralının bir zengin metin düzenleyici (rich-text editor) yükünde tetiklenmesi gibi durumlarda rutin olarak kesintilere neden olur. Çözüm, tüm grubu devre dışı bırakmak değil, hatalı tetiklenen belirli kural için bir kapsam daraltma ifadesi (scope-down statement) veya bir kural eylemi geçersiz kılması (rule action override) eklemektir.
WAF metriklerini (BlockedRequests, AllowedRequests, CountedRequests) CloudWatch alarmlarıyla eşleştirin. Böylece engellemelerdeki ani bir artış veya izin verilen trafikteki ani bir düşüş, nöbetçi mühendise bildirim göndererek uç nokta koruması ile operasyonel farkındalık arasındaki döngüyü tamamlar.
Pratik Problem: Kullanım Senaryosu
Senaryo: Meridian Financial, Application Load Balancer’ların (ALB) ECS servislerinin önünde yer aldığı çoklu AZ’li (multi-AZ) bir VPC’de müşteriye yönelik bir web uygulaması çalıştırmakta ve statik ile dinamik içeriği CloudFront aracılığıyla dağıtmaktadır. Ekip AWS WAF kullanıyor ancak ağ katmanı tehditleri için otomasyonları sınırlı ve servisler arasında tutarsız günlükleme mevcut.
Zorluk: Yakın zamanda gerçekleşen hacimsel ve uygulama katmanı trafik artışı, giriş (login) uç noktalarını hedef alarak kimlik bilgisi doldurma (credential stuffing) denemeleri yaparken ALB CPU’sunun tükenmesine neden oldu. Güvenlik ekibinin hızlı DDoS azaltma, tutarlı origin koruması, kötü amaçlı IP’lerin otomatik olarak engellenmesi ve daha katı kuralların güvenli bir şekilde dağıtılmasına ihtiyacı var.
Önerilen Yaklaşım:
- Küresel uç nokta (edge) koruması için ALB’nin önüne CloudFront’u etkinleştirin. Özel bir origin başlığını (custom origin header) doğrulayarak ve CloudFront tarafından yönetilen bir ön ek listesi (prefix list) veya bilinen IP aralıkları ile gelen erişimi kısıtlayarak ALB’yi yalnızca CloudFront’tan gelen trafiği kabul edecek şekilde yapılandırın.
- Yönetilen AWS kural setleri ile özel, oran tabanlı (rate-based) ve bot tespit kurallarını içeren AWS WAFv2’yi dağıtın; WAF’ı hem CloudFront dağıtımına hem de ALB’ye ekleyin. Başlangıçta, telemetri toplamak için yeni özel kuralları COUNT moduna ayarlayın.
- Hesabı AWS Shield Advanced’e kaydedin ve CloudFront dağıtımı ile ALB’yi ilişkilendirin; Shield/DDoS metriklerini kullanarak CloudWatch metrik alarmları oluşturun ve alarmları, nöbetçi bildirimleri ve runbook tetikleyicileri için bir SNS konusuna (topic) iletin.
- Günlükleri merkezileştirin: CloudFront, ALB, WAF ve AWS Network Firewall günlüklerini Kinesis Data Firehose → S3’e akıtın ve COUNT modundan gelen kural eşleşme sayılarını izlemek için CloudWatch metriklerini/panolarını etkinleştirin.
- VPC’de durumsal (stateful) kural gruplarıyla AWS Network Firewall’u dağıtın ve günlüklemesini etkinleştirin; şüpheli desenler için CloudWatch metrik filtreleri ve alarmlar tarafından tetiklenerek saldırgan IP’leri bir reddetme listesine (deny list) eklemek üzere Network Firewall kural grubunu otomatik olarak güncelleyen bir Lambda oluşturun.
- Üzerinde anlaşılan bir gözlem penceresi boyunca trafiği COUNT modunda ve panolarda gözlemledikten sonra, yüksek güvenilirlikli WAF kurallarını BLOCK moduna alın ve kural gruplarının güvenli geri alma (rollback) ve sürümlemesi ile otomatikleştirilmiş Network Firewall güncellemelerini sürdürün.
Gerekçe: CloudFront’u WAF ve Shield Advanced ile birlikte uç katman (edge layer) olarak kullanmak katmanlı DDoS koruması sağlarken; merkezileştirilmiş günlükleme, COUNT modunda kural doğrulaması ve Lambda tabanlı otomatik Network Firewall güncellemeleri, AWS en iyi uygulamalarıyla tutarlı, güvenli, gözlemlenebilir ve otomatik bir ağ savunması sunar.
← Ağ ve VPC Güvenliği · Tüm alanlar · Yönetişim →
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 →