Amazon SCS-C02: Ağ ve VPC Güvenliği — Ç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.

VPC Uç Noktaları ve Uç Nokta Politikaları

VPC uç noktaları, AWS servislerine giden trafiği AWS ağında tutarak genel interneti, NAT ağ geçitlerini ve internet ağ geçitlerini atlar. Yapısal olarak farklı iki türü vardır ve bunları karıştırmak en yaygın tasarım hatalarından biridir.

Ağ geçidi uç noktaları (Gateway endpoints) yalnızca Amazon S3 ve DynamoDB için mevcuttur. Bunlar yönlendirme tablosu girişleridir — uç noktayı yönlendirme tablolarıyla ilişkilendirirsiniz ve servisin ön ek listesine (örneğin, us-east-1’deki S3 için pl-63a5400a) giden trafik sessizce uç nokta üzerinden yeniden yönlendirilir. Hiçbir maliyetleri yoktur ve bağlı oldukları VPC’nin dışından erişilemezler.

Arayüz uç noktaları (Interface endpoints) (AWS PrivateLink tarafından desteklenir), alt ağlarınıza yerleştirilen özel IP adreslerine sahip ENI’lerdir. S3 veya DynamoDB olmayan her servis için gereklidirler — Secrets Manager, KMS, STS, SSM, CloudWatch Logs, ECR API/DKR ve yüzlerce diğeri. NAT ağ geçidi olmayan özel bir alt ağdaki (private subnet) bir EC2 bulut sunucusunun Secrets Manager’dan GetSecretValue yapması gerekiyorsa, bir ağ geçidi uç noktası yardımcı olmaz; bir com.amazonaws.<region>.secretsmanager arayüz uç noktası oluşturmanız ve standart servis ana bilgisayar adının (hostname) uç noktanın özel IP’sine çözümlenmesi için Private DNS’i etkinleştirmeniz gerekir.

Uç nokta politikaları, çağrıyı yapanın IAM politikalarından bağımsız olarak, uç nokta üzerinden nelerin yapılabileceğini kısıtlar. Veri sızıntısını önlemek için en önemli iki koşul anahtarı (condition key), aws:PrincipalOrgID (çağrıyı yapan kimlik Kuruluşunuza ait olmalıdır) ve aws:ResourceOrgID‘dir (erişilen S3 bucket’ı, KMS anahtarı vb. Kuruluşunuza ait olmalıdır). Her ikisini de uygulamak, meşru S3 izinlerine sahip ele geçirilmiş bir bulut sunucusunun, kuruluşunuzun dışındaki saldırgan kontrolündeki bir bucket’a yazma yaptığı klasik veri sızıntısı yolunu kapatır — kimlik bilgileri S3’e karşı hala çalışır, ancak uç nokta isteği iletmeyi reddeder.

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "o-abc123",
        "aws:ResourceOrgID":  "o-abc123"
      }
    }
  }]
}

Varsayılan uç nokta politikası tamamen izin vericidir ("Resource":"*" üzerinde "Action":"*"), bu nedenle, yalnızca bir ağ geçidi uç noktasına ve en az ayrıcalıklı IAM’e sahip bir alt ağ, uç nokta politikasının kendisini sıkılaştırmadığınız sürece veri sızıntısı için kötüye kullanılabilir.

Hibrit Bağlantı: VPN ve Direct Connect

Site-to-Site VPN, bir sanal özel ağ geçidi (virtual private gateway) (veya Transit Gateway) ile bir müşteri ağ geçidi cihazı (customer gateway device) arasında iki IPsec tüneli kurar. Kurulumu hızlıdır, varsayılan olarak şifrelenmiştir ve genel internet üzerinden geçer — bu nedenle verim (throughput) ve gecikme (latency), ISP yolunuza bağlıdır.

AWS Direct Connect, bir Direct Connect konumu aracılığıyla özel bir fiziksel devre sağlar. Öngörülebilir düşük gecikme ve yüksek, tutarlı bant genişliği (1/10/100 Gbps) sunar; bu da yoğun iletişim kuran şirket içi (on-premises) veritabanı trafiği için önemlidir. Direct Connect kendi başına katman 3’te şifreli değildir; çerçeveler (frame’ler) özel fiber üzerinde çalışır. Hem düşük gecikme hem de IPsec gerektiren iş yükleri için standart çözüm, bir public VIF üzerinden çalışan bir Site-to-Site VPN ile birlikte Direct Connect’tir (veya daha yeni DX portlarında MACsec ile bir Transit Gateway). Yalnızca VPN, aynı zamanda birincil bir Direct Connect bağlantısı için önerilen şifreli yedektir ve devrenin arızalanması durumunda esneklik (resilience) sağlar.

• Yalnızca Direct Connect: düşük gecikme, özel, ancak IP katmanında şifresiz.
• Yalnızca VPN: şifreli, hızlı kurulum, ancak internet yolu gecikmesi ve titreşimi (jitter).
• Direct Connect + VPN: düşük gecikme ve IPsec şifrelemesi; aynı zamanda standart HA (yüksek erişilebilirlik) modelidir.

Güvenlik Grupları, NACL’ler, DHCP ve Kaynak/Hedef Kontrolleri

Güvenlik grupları (Security groups) durumludur (stateful): gelen bir isteğe izin verirseniz, yanıtın dışarı çıkmasına otomatik olarak izin verilir. Yalnızca izin verme (allow) kurallarını desteklerler ve ENI başına değerlendirilirler.

Ağ ACL’leri (Network ACLs) durumsuzdur (stateless) ve alt ağ sınırında çalışır. Her akış için iki kural gerekir — biri başlangıç yönü için, diğeri ise geçici (ephemeral) port aralığındaki dönüş trafiği için (Linux tipik olarak 32768–60999, Windows 49152–65535 ve NLB’ler/ELB’ler 1024–65535 kullanır). Gelen TCP 443’e izin veren ancak giden TCP 1024–65535’i unutan bir NACL, TLS’i sessizce bozar. ICMP, TCP/UDP değildir: dönüş “echo reply” paketlerine açıkça izin verilmelidir ve Path MTU Discovery, istemeden engellenmesi kolay olan ICMP type 3 code 4’e dayanır. NACL kuralları ayrıca sayısal sırayla değerlendirilir, ilk eşleşen kazanır ve sonunda örtük bir reddetme (deny) bulunur.

DHCP seçenek setleri (option sets), bir VPC’nin başlatma sırasında bulut sunucularına ne verdiğini kontrol eder: domain-name-servers, domain-name, NTP sunucuları, NetBIOS. Varsayılan AmazonProvidedDNS‘i özel bir şirket içi (on-premises) çözümleyiciyle (resolver) değiştirmek meşru olabilir, ancak bunun gerçek güvenlik sonuçları vardır. GuardDuty gibi servisler, DNS tabanlı bulguları (örneğin “kripto para” ve “C&C domain” tespitleri) Route 53 Resolver’dan geçen sorgulardan türetir. Bulut sunucularını üçüncü taraf bir DNS sunucusuna yönlendirdiğinizde, GuardDuty sorguları görmeyi durdurur ve bu bulgu türleri kaybolur — bu, tespiti yanlışlıkla kör etmenin kolay bir yoludur.

Kaynak/hedef kontrolü (Source/destination checking), kaynak veya hedef IP’si ENI ile eşleşmeyen herhangi bir paketi düşüren bir ENI özelliğidir. Bu varsayılan, sıradan bulut sunucuları için doğrudur ancak işi trafiği iletmek olan herhangi bir cihazı bozar — NAT bulut sunucuları, sanal güvenlik duvarları (Palo Alto, Fortinet, Check Point), transit yönlendiriciler, VPN yoğunlaştırıcılar. Bu ENI’ler için kontrolü devre dışı bırakın:

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --no-source-dest-check

VPC Peering, RAM ile Paylaşılan VPC’ler ve NAT Tasarımı

VPC peering, bire bir, geçişsiz bir katman-3 bağlantısıdır. Eğer A, B ile ve B, C ile eşleşmişse, A, C’ye ulaşamaz — A–C’yi doğrudan eşlemeniz veya bir Transit Gateway kullanmanız gerekir. Her iki taraftaki yönlendirme tabloları, eş CIDR’a giden yolları içermelidir ve güvenlik grupları, eş güvenlik grubu kimliklerine yalnızca bir Bölge içinde referans verebilir.

AWS Resource Access Manager (RAM) aracılığıyla paylaşılan VPC’ler, bir ağ hesabının bir VPC’ye sahip olmasına ve bireysel alt ağları katılımcı hesaplarla paylaşmasına olanak tanır. Katılımcılar, kaynakları paylaşılan alt ağlarda başlatır ancak VPC’yi, yönlendirme tablolarını veya uç noktaları değiştiremezler — bağlantı politikasının kontrolü sahibinde kalır. Bu genellikle birçok VPC’yi eşlemekten daha ucuz ve daha basittir.

Özel alt ağlardan giden internet trafiği için, her Kullanılabilirlik Alanı başına bir NAT ağ geçidi dağıtın ve her özel alt ağı kendi AZ’sindeki NAT’a yönlendirin. Tek bir NAT ağ geçidi, AZ’ler arası bir bağımlılık ve bir ölçek/kullanılabilirlik darboğazıdır. İş yükünüz, çıkış trafiğiniz için IP izin listesi kullanan bir üçüncü tarafı (örneğin bir ödeme işlemcisi) çağırdığında, kaydedeceğiniz IP, NAT ağ geçidinin Elastic IP’sidir. Bir Auto Scaling grubu arkasındaki tüm örnekler bu sabit EIP üzerinden çıkış yaptığından, grup ölçeklendikçe kaynak IP değişmez. EC2 örneklerini ve RDS veritabanını özel alt ağlara yerleştirmek ve yalnızca HTTP/HTTPS’yi ALB üzerinde sonlandırmak bu deseni tamamlar.

Route 53 Resolver: Yönlendirme ve Sorgu Günlüğü

Route 53 Resolver (her VPC’deki .2 adresi), hibrit DNS için bir pivot noktasıdır. Giden çözümleyici uç noktaları, koşullu yönlendirme kuralları aracılığıyla belirtilen alan adlarını AWS’ten şirket içi (on-premises) DNS sunucularına yönlendirir — örneğin, corp.example.internal sorgusunun Active Directory’nize karşı çözümlenmesi için kullanılır. Gelen çözümleyici uç noktaları ise tam tersini yapar ve şirket içi ana bilgisayarlara, *.eu-west-1.compute.internal ve Private Hosted Zone’ları çözümlemek için sorgulayabilecekleri VPC’nizde özel bir IP adresi sağlar.

Çözümleyici sorgu günlüğü, VPC’den yapılan her DNS sorgusunu CloudWatch Logs, S3 veya Kinesis Firehose’a yazar. Bu, şüpheli veri sızdırma veya kötüye kullanımı araştırmak için yetkili kayıttır ve GuardDuty’yi tamamlar — ancak onun yerini almaz. Unutmayın, eğer bir DHCP seçenek seti örnekleri Amazon dışı bir çözümleyiciye yönlendirirse, sorgular Route 53 Resolver’a hiç ulaşmadığı için hem sorgu günlüğü hem de GuardDuty DNS bulguları kararır.

Pratik Problem: Kullanım Senaryosu

Senaryo: Meridian Financial, merkez-uydu (hub-and-spoke) ağına sahip çoklu hesaplı bir AWS ortamı işletmektedir: RAM ile paylaşılan bir paylaşılan hizmetler VPC’si, merkezi NAT Gateway’leri, Route 53 Resolver uç noktalarını ve Transit Gateway eklentilerini barındırırken, birden çok uygulama VPC’si Transit Gateway’e eşlenmiş veya eklenmiştir. Şirket içi (on-premises) veri merkezleri, VPN yük devretme ile Direct Connect üzerinden bağlanır ve ekipler, hibrit DNS çözünürlüğü için merkezi DHCP seçenek setlerine ve paylaşılan çözümleyici uç noktalarına güvenir.

Zorluk: Yakın zamanda yaşanan bir olay, uydu VPC’lerin VPC uç noktaları yerine paylaşılan NAT’a yönlendirilmesi nedeniyle hassas S3 nesnelerine genel internet üzerinden erişildiğini, dahili bölgeler için yapılan DNS sorgularının genel çözümleyicilere sızdığını ve geçici (ad-hoc) bir yönlendirici olarak kullanılan bir EC2’nin (kaynak/hedef denetimi devre dışı bırakılmış) yanal harekete olanak sağladığını göstermiştir.

Önerilen Yaklaşım:

1. Paylaşılan hizmetler VPC’sinde S3 ve DynamoDB için Ağ Geçidi VPC Uç Noktaları (Gateway VPC Endpoints) ve Secrets Manager ile KMS için Arayüz Uç Noktaları (Interface Endpoints - AWS PrivateLink) dağıtın; erişimi belirtilen bucket’lara ve hizmet sorumlularına (service principals) kısıtlayan açık uç nokta politikaları ekleyin.
2. NAT tasarımını, uygulama alt ağlarının AWS API’leri ve S3 için VPC uç noktalarını kullanacağı şekilde yeniden düzenleyin; NAT Gateway’leri yalnızca gerçek internet çıkışı için, sıkı çıkış güvenlik grupları ve CloudWatch/S3’e gönderilen Flow Logs ile birlikte koruyun.
3. Belgelenmiş yönlendirme cihazları dışındaki tüm EC2 örneklerinde kaynak/hedef denetimlerini yeniden etkinleştirin; yönlendirmeyi Transit Gateway eklentilerine veya yönetilen NAT örneklerine taşıyın ve yönlendirme tablosunda en az ayrıcalık ilkesini uygulayın.
4. Güvenlik Gruplarını ve alt ağ NACL’lerini varsayılan olarak reddetme (deny-by-default) duruşuna göre sıkılaştırın ve AWS Organizations SCP’leri ve AWS Config kuralları aracılığıyla merkezi IAM+SG temellerini uygulayın.
5. Route 53 Resolver gelen/giden uç noktalarını dağıtarak, koşullu yönlendirme ve DNS Güvenlik Duvarı kurallarını yapılandırarak, CloudWatch Logs’a Çözümleyici sorgu günlüğünü etkinleştirerek ve RAM aracılığıyla paylaşılan tüm VPC’ler için dahili çözümleyicileri zorunlu kılmak üzere DHCP seçenek setlerini kullanarak hibrit DNS’i güçlendirin.

Gerekçe: Bu yaklaşım, uç nokta politikalarıyla VPC uç noktalarını kullanarak gereksiz internet çıkışını ortadan kaldırır, Transit Gateway/Direct Connect aracılığıyla yönlendirmeyi merkezileştirir ve kontrol eder, örnek düzeyindeki korumaları geri kazandırır ve Resolver uç noktaları ve günlük kaydı ile DNS sızıntısını önler — bu da AWS ağ oluşturma ve derinlemesine savunma (defense-in-depth) en iyi uygulamalarıyla uyumludur.

VPC Uç Noktaları ve Uç Nokta Politikaları

VPC uç noktaları, bir VPC içindeki iş yüklerinin genel interneti veya bir NAT ağ geçidini kullanmadan AWS hizmet API’lerine ulaşmasını sağlar. İki mimari türü vardır ve yanlış olanı seçmek, trafiğin yanlış yönlendirilmesinin yaygın bir nedenidir.

• Ağ Geçidi Uç Noktaları (Gateway endpoints): Yalnızca Amazon S3 ve DynamoDB için kullanılır. Bir yönlendirme tablosunda hedef olarak (vpce-xxxxxxxx adresini gösteren pl-xxxxxxxx ön ek listesi) uygulanırlar. ENI oluşturulmaz, DNS değişikliği gerekmez ve saatlik bir maliyeti yoktur.

• Arayüz Uç Noktaları (Interface endpoints - PrivateLink): KMS, SQS, SNS, Secrets Manager, STS, EC2 API ve diğer birçok hizmet için kullanılır. Seçilen alt ağlar içinde özel IP’lere sahip ENI’ler oluştururlar ve saatlik artı GB başına ücretlendirilirler.

B Hesabındaki EC2 örneklerinin, A Hesabındaki bir KMS anahtarıyla şifrelenmiş A Hesabındaki bir S3 bucket’ından okuma yaptığı hesaplar arası (cross-account) bir toplu iş (batch job) için doğru tasarım, S3 için bir ağ geçidi uç noktası ve KMS için bir arayüz uç noktasıdır. Ağ geçidi uç noktası s3:GetObject, s3:PutObject, s3:PutObjectAcl ve s3:ListBucket işlemlerini internetten uzak tutar; arayüz uç noktası da kms:Decrypt, kms:Encrypt ve kms:GenerateDataKey için aynısını yapar. KMS anahtarının ARN’si standart kms.<region>.amazonaws.com ana bilgisayar adını kullandığından, SDK’nın değiştirilmemiş ana bilgisayar adının genel KMS hizmeti yerine uç nokta ENI’sine çözümlenmesi için arayüz uç noktasında Özel DNS’in etkinleştirilmiş (Private DNS enabled) olması gerekir. Özel DNS olmadan (veya VPC düzeyinde hem DNS ana bilgisayar adları hem de DNS çözümlemesi etkinleştirilmeden), istemci yine de genel uç noktaya erişirdi — bu nedenle “kod değişikliği yok” gereksinimi dolaylı olarak Özel DNS’i zorunlu kılar.

Uç nokta politikaları ikinci, bağımsız bir yetkilendirme katmanıdır. Varsayılan olarak izin veren bir politika mevcuttur, ancak belirli bir bucket ve anahtar için sıkılaştırma şu şekilde görünür:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
    "Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
  }]
}

Sadece uç noktayı oluşturmak yeterli değildir. İki hata modu sıkça tekrarlanır: (1) uç nokta mevcuttur ancak özel alt ağın yönlendirme tablosunda S3 ön ek listesi için bir giriş yoktur, bu nedenle trafik yine de NAT ağ geçidi üzerinden çıkar; (2) uç nokta politikası s3:PutObjectAcl gibi bir eylemi içermez veya yanlış bucket ARN’sini hedefler, bu da IAM’in normalde izin vereceği çağrıları sessizce engeller. İsteğe hem bucket politikası hem de uç nokta politikası izin vermelidir — bu politikalar birleştirilmez (union), kesişimleri (intersection) alınır.

Güvenlik Grupları, NACL’ler ve Hızlı Sınırlama

Güvenlik grupları ve NACL’ler, farklı katmanlarda kesişen sorunları çözer ve sınavda genellikle olay müdahalesi (incident response) için aralarında bir seçim yapmanız istenir.

• Güvenlik grupları (Security groups): Durum bilgili (Stateful), ENI seviyesinde değerlendirilir. Geri dönüş trafiğine otomatik olarak izin verilir. Yalnızca izin (allow) kuralları bulunur. Ana bilgisayar düzeyindeki politikalar için idealdir (“web katmanı, uygulama katmanına 8080 portundan ulaşabilir”).

• Ağ ACL’leri (Network ACLs): Durum bilgisiz (Stateless), alt ağ sınırında değerlendirilir. Hem izin (allow) hem de reddetme (deny) kuralları bulunur ve kural numarası sırasına göre işlenir. Kaba, alt ağ genelindeki engellemeler için idealdir — özellikle bir IP aralığını kara listeye almak veya bir alt ağdaki her örnekte belirli bir portu kapatmak için.

Bir kötü amaçlı yazılım salgını, birçok örnekte bir dizi komuta-kontrol (command-and-control) IP’sine giden TCP/2905 giden trafiğini engellemenizi gerektirdiğinde, bir NACL reddetme (deny) kuralı doğru araçtır. Güvenlik grupları “reddetme” (deny) ifadesini belirtemez ve etkilenen her ENI tarafından referans alınan her SG’nin listelenip değiştirilmesini gerektirir. Düşük bir kural numarasına (ör. 90) sahip tek bir alt ağ düzeyindeki NACL reddetme kuralı, o alt ağdaki tüm örnekleri anında kapsar ve daha sonraki izin kuralları tarafından değerlendirilen ilgisiz trafiği korur.

NACL’ler durum bilgisi tutmadığı için, her iki yönde de kural gerektiğini unutmayın. 2905 portunda giden (egress) trafiği engellemek bir gelen (ingress) kuralı gerektirmez, ancak gelen yanıtları da reddetmek istiyorsanız bir gelen kuralı eklemeniz gerekir — ve meşru geri dönüş trafiğinin geçmesine izin vermek için geçici (ephemeral) portlar (1024–65535) için gelen izin kurallarının bulunması gerekir.

NAT Ağ Geçitleri, Yönlendirme ve AZ Bağımsızlığı

Bir NAT ağ geçidi, bölgesel (zonal) bir kaynaktır. Standart model, her bir özel alt ağın yönlendirme tablosunun 0.0.0.0/0 hedefini aynı AZ’deki NAT’a yönlendirdiği, Kullanılabilirlik Alanı (Availability Zone) başına bir NAT ağ geçidi olmasıdır:

PrivateRouteTable-AZ-a:  0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b:  0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c:  0.0.0.0/0 -> nat-cccc (in subnet public-az-c)

AZ’ler arasında paylaşılan tek bir NAT daha ucuz görünse de iki sorun ortaya çıkarır: her pakette AZ’ler arası veri transferi ücretleri ve katı bir erişilebilirlik bağımlılığı — eğer o AZ çökerse, her özel alt ağ internet çıkışını kaybeder. Bölgesel NAT modeli ayrıca, Transit Gateway denetimiyle (aşağıya bakınız) birleştirildiğinde asimetrik geri dönüş (asymmetric-return) garipliklerini de önler.

Araştırma için VPC Akış Günlükleri (Flow Logs)

Akış Günlükleri (Flow Logs), VPC, alt ağ veya ENI düzeyinde 5’li meta verileri (kaynak/hedef IP, port, protokol, eylem ACCEPT/REJECT, bayt, paket) yakalar. TCP/2905 üzerinden K2 (C2) ana bilgisayarlarına sinyal gönderen örnekleri bulmak için, VPC’de Akış Günlüklerini trafik türü REJECT olarak ayarlanmış şekilde etkinleştirin (çünkü NACL artık trafiği düşürüyor) ve CloudWatch Logs Insights veya Athena’da sorgulayın:

SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;

srcaddr sütunu, enfekte olmuş örneklerin IP’lerini minimum çabayla ortaya çıkarır — paket yakalamaya veya ana bilgisayar ajanlarına gerek kalmaz. “ALL” (TÜMÜ) trafiğini seçmek işe yarar ancak daha fazla veri ve maliyet üretir; yalnızca “ACCEPT” (KABUL EDİLEN) seçeneğini seçmek, tam da görmeniz gereken düşürülen denemeleri tamamen gözden kaçırmanıza neden olur.

PrivateLink, Transit Gateway ve Network Firewall

PrivateLink, arabirim uç noktası modelini kendi hizmetlerinize genişletir: bir sağlayıcı VPC, bir VPC uç nokta hizmetinin arkasında bir NLB’yi kullanıma sunar ve tüketiciler, VPC eşleştirmesi veya rota paylaşımı olmadan ona ulaşmak için arabirim uç noktaları oluşturur. Tek yönlüdür ve sağlayıcının CIDR’ını tamamen gizler.

Transit Gateway (TGW), çoktan çoğa VPC ve şirket içi bağlantılar için bir merkezdir. Yaygın bir desen, AWS Network Firewall veya üçüncü taraf cihazları çalıştıran merkezi bir denetim VPC’si kullanmak ve TGW rota tablolarıyla spoke’tan spoke’a trafiği bu denetim VPC’si üzerinden yönlendirmektir. Bu tasarım, varsayılan TGW davranışında çalışmaz çünkü TGW, farklı AZ’lerdeki attachment ENI’ları arasında akışları hash’ler ve dönüş yolu, gidiş yolundan farklı bir AZ’ye girebilir. Durum bilgili güvenlik duvarları (Stateful firewall’lar), SYN’ini hiç görmedikleri akış ortası paketlerini düşürür.

İki düzeltmenin birlikte yapılması gerekir. İlk olarak, denetim VPC’si için TGW attachment’ında Appliance Mode’u etkinleştirin; bu, her çift yönlü akışı aynı AZ ENI’sine sabitler, böylece gidiş ve dönüş trafiği aynı güvenlik duvarı uç noktasından geçer. İkinci olarak, TGW rota tablolarını, spoke attachment’larının trafiği denetim VPC’si attachment’ına göndereceği şekilde yapılandırın ve denetim VPC’sindeki ayrı bir denetim sonrası rota tablosu, trafiği doğru spoke’a geri döndürür. Bu adımlardan birini atlamak — rota tabloları olmadan yalnızca appliance mode veya appliance mode olmadan yalnızca rota tabloları — asimetrik paket düşüşlerini devam ettirir.

Network Firewall’ın kendisi Suricata uyumlu kurallar kullanır ve akış durumunu korumak için simetrik yönlendirmeye dayanır; bunu hem denetim VPC’sinde hem de spoke VPC’lerde Flow Logs ile birleştirmek, hangi spoke’un bir oturum başlattığını ve güvenlik duvarının buna izin verip vermediğini veya düşürüp düşürmediğini kanıtlamak için gereken adli izi sağlar.

Pratik Problem: Kullanım Senaryosu

Senaryo: Meridian Financial, us-east-1 bölgesinde üç Kullanılabilirlik Alanına (Availability Zone) yayılmış üretim VPC’lerini bir AWS Transit Gateway ile merkezi bir güvenlik VPC’sine bağlayan çok hesaplı bir AWS ortamı işletmektedir. Her AZ’de dışa giden trafik (egress) için NAT Gateway’ler, iş ortağı SaaS çözümleri için S3 Gateway Endpoints ve Interface Endpoints (PrivateLink) ve Security Groups ile NACL’lerin yanı sıra merkezi bir AWS Network Firewall kullanmaktadırlar; VPC Flow Logs izleme için CloudWatch’a akıtılmaktadır.

Zorluk: Bir üretim EC2 sunucusunun, harici bir IP’ye ve S3’e yönelik yatay hareket (lateral movement) ve veri sızdırma girişimlerinde bulunduğundan şüphelenilmektedir ve Meridian’ın diğer iş açısından kritik VPC’leri kesintiye uğratmadan AZ’ler arasında hızlı bir şekilde durumu kontrol altına alması gerekmektedir.

Önerilen Yaklaşım:

1. Güvenliği ihlal edilmiş sunucuyu derhal karantinaya almak için mevcut Security Group’larını, tüm giden/gelen trafiği reddeden kısıtlayıcı bir “karantina” SG’si ile değiştirin ve Systems Manager aracılığıyla otomatik düzeltme için sunucuyu etiketleyin; eş zamanlı olarak, şüpheli harici IP aralıklarına giden trafiği (egress) engellemek için alt ağ düzeyinde Network ACL kuralları uygulayın.
2. Etkilenen VPC’nin TGW rota tablosu attachment’ını kaldırarak veya bir karantina TGW rota tablosuna (diğer attachment’lara rota olmayan veya blackhole) değiştirerek VPC’yi Transit Gateway üzerinde izole edin ve böylece diğer VPC’lere yatay hareketi durdurun.
3. Denetimi zorunlu kılmak ve bilinen kötü amaçlı hedefleri engellemek için TGW/rota tablosu girişlerini güncelleyerek kalan VPC dışa giden trafiğini (egress) merkezi AWS Network Firewall üzerinden yönlendirin; dayanıklı ve denetlenmiş bir dış trafik akışı için her AZ’de NAT Gateway’leri tutarak AZ bağımsızlığını koruyun.
4. Onaylanmamış principal’lardan gelen Put/Get işlemlerini reddetmek için S3/DynamoDB Gateway Endpoints üzerinde kısıtlayıcı VPC Endpoint politikaları uygulayarak ve dahili API’lerin internet yollarından kaçınmak için Interface Endpoints (PrivateLink) kullanmasını sağlayarak veri düzlemi (data-plane) kontrollerini sıkılaştırın.
5. Adli analiz yapmak için VPC Flow Logs’u CloudWatch Logs Insights ve AWS CloudTrail ile birlikte kullanın, ardından düzeltme yapın (imajı yeniden yükleyin, anahtarları döndürün) ve sunucuyu yalnızca doğrulamadan sonra yeniden devreye alın; kuralları AWS Firewall Manager/AWS Config aracılığıyla zorunlu kılın.

Gerekçe: Bu sıralama, hem host hem de ağ katmanlarında hızlı ve en az ayrıcalık ilkesine dayalı kontrol altına alma sağlar, patlama yarıçapını en aza indirmek için Network Firewall ve Transit Gateway yönlendirmesi ile denetimi merkezileştirir, her AZ’de NAT kullanarak AZ dayanıklılığını korur ve hesap verebilir bir soruşturma için VPC Flow Logs’u kullanır. Bu yaklaşım, AWS’nin derinlemesine savunma (defense-in-depth) en iyi uygulamalarıyla uyumludur.

← Veri Koruma ve S3 · Tüm alanlar · Uç ve Uygulama Güvenliği →

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

Amazon'a göz atın →