Amazon SCS-C02: Konteyner ve Sunucusuz 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.

SSH Olmadan ECS Exec ve Çalışma Zamanı Denetimi

ECS Exec, SSH, bastion sunucuları veya genel IP’leri açığa çıkarmadan, Fargate görevleri de dahil olmak üzere, çalışan bir konteynere interaktif bir kabuk erişimi sağlar. Bu, AWS’nin görevin sidecar yürütme ortamına enjekte ettiği SSM ajanı üzerinden çalışır. Güvenli hale getirilecek bir SSH daemon’u, anahtar materyali ve gelen ağ yolu olmadığından, operasyonel yük minimum düzeydedir ve her oturum CloudTrail aracılığıyla denetlenebilir ve (isteğe bağlı olarak) S3 veya CloudWatch Logs’a kaydedilebilir.

ECS Exec’in çalışması için üç gereksinimin de karşılanması gerekir:

Görev rolü izinleri: görev rolünün (yürütme rolünün değil) ssmmessages:CreateControlChannel, ssmmessages:CreateDataChannel, ssmmessages:OpenControlChannel ve ssmmessages:OpenDataChannel izinlerine ihtiyacı vardır. Yürütme rolü yalnızca imajları çeker ve logları yazar; çalışma zamanı SSM trafiği görev rolü üzerinden akar çünkü konteyner sürecinin üstlendiği kimlik budur.
Servis veya görev yapılandırması: servis --enable-execute-command ile oluşturulmalı veya güncellenmelidir. Bu bayrak, yeni görevlerde enableExecuteCommand özelliğini etkinleştirir; mevcut görevlerin değiştirilmesi gerekir.
Konteyner imajı desteği: konteynerin imajında bir kabuk (/bin/sh veya /bin/bash) bulunması gerekir.

Tipik bir inceleme akışı şu şekildedir:

aws ecs update-service --cluster prod --service api \
  --enable-execute-command --force-new-deployment

aws ecs execute-command --cluster prod \
  --task 5f8c...c2 --container api \
  --interactive --command "/bin/sh"

Bu kabuktan bir mühendis, logları S3’e kopyalayabilir, bir heap dump tetikleyebilir veya adli analiz için /proc dizinini okuyabilir. Alternatif olarak — konteynere SSH üzerinden ulaşmaya çalışmak veya bir hata ayıklama ajanını etkinleştirmek için görevi yeniden başlatmak — Fargate’te ya başarısız olur ya da toplamaya çalıştığınız kanıtları yok eder.

EC2 Üzerindeki Konteynerlerden IMDS Erişimini Engelleme

Yaygın bir yanılgı, EC2 örneğindeki IMDSv2 hop-limit ayarlarının o örnekteki konteynerleri koruduğudur. En azından varsayılan olarak bridge veya host ağ modunda korumazlar: konteynerler, ana makinenin ağ ad alanını veya bir NAT köprüsünü paylaşır ve 169.254.169.254 adresine ulaşıp, genellikle görev rolünden çok daha ayrıcalıklı olan örnek profili kimlik bilgilerini alabilirler. Bu, en az ayrıcalık ilkesini tamamen boşa çıkarır.

Fargate’e geçişin mümkün olmadığı durumlarda çözüm iki bölümden oluşur:

Görevler için awsvpc ağ modunu kullanın. Her görev kendi ENI’sine ve ağ ad alanına sahip olur. IMDS trafiği artık ana makinenin link-local uç noktasına şeffaf bir şekilde ulaşamaz.
Konteyner örneğindeki /etc/ecs/ecs.config dosyasında ECS_AWSVPC_BLOCK_IMDS=true olarak ayarlayın. Bu, ECS ajanına, awsvpc görevlerinden 169.254.169.254 hedefine giden paketleri düşüren bir iptables kuralı yüklemesini söyler.

echo 'ECS_AWSVPC_BLOCK_IMDS=true' >> /etc/ecs/ecs.config
systemctl restart ecs

Bunu minimal bir örnek profili (temelde sadece ECS ajanının ihtiyaç duyduğu: AmazonEC2ContainerServiceforEC2Role) ve uygulama izinleri için görev başına IAM rolleri ile birleştirin. Örneğin IMDS hop limitini 1’e ayarlamak ve IMDSv2’yi zorunlu kılmak faydalı bir derinlemesine savunma önlemidir, ancak bir alternatif değildir — bridge modundaki konteynerler, istek ana makineden kaynaklandığı için IMDS’ye 1 hop’ta hala ulaşabilir.

GuardDuty Çalışma Zamanı İzlemesi, EKS Koruması ve Kontrol Düzlemi Logları

GuardDuty, katmanlı konteyner tespiti sunar:

EKS Protection, şüpheli Kubernetes API aktivitelerini (anonim erişim, ayrıcalıklı pod oluşturma, sistem podlarına exec yapma gibi) tespit etmek için EKS denetim loglarını analiz eder.
Runtime Monitoring, konteynerler içindeki süreç, dosya ve ağ aktivitelerini gözlemleyen eBPF tabanlı bir sensör (EKS için yönetilen bir eklenti veya ECS/Fargate için SSM tarafından yönetilen bir ajan olarak) dağıtır. Bir Pod veya görev içinden ters kabuklar, kripto madenciliği ikili dosyaları ve kimlik bilgisi sızdırma gibi bulguları ortaya çıkarır.

EKS kontrol düzlemi denetim logu fiilen CloudWatch Logs’a gönderilmedikçe EKS Protection’ın hiçbir değeri yoktur. Kümede en azından audit ve authenticator log türlerini etkinleştirin:

aws eks update-cluster-config --name prod \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

Bu olmadan, GuardDuty’nin EKS Protection bulguları için inceleyeceği bir veri düzlemi olmaz — bu, operatörlerin GuardDuty özelliğini etkinleştirmesine rağmen kümenin loglama yapılandırmasını kapalı bırakması ve ardından neden hiçbir Kubernetes bulgusunun görünmediğini merak etmesi nedeniyle sıkça karşılaşılan bir tuzaktır.

ECR Gelişmiş Tarama ile İmaj Taraması

ECR Enhanced Scanning, Amazon Inspector tarafından desteklenir ve konteyner imajlarını işletim sistemi ve dil paketi CVE’leri (Python, Node, Java, Go, Ruby) için sürekli olarak tarar. Temel tarama, push anında tek seferliktir ve yalnızca işletim sistemi paketlerini kapsar; gelişmiş tarama ise süreklidir ve çoğu modern güvenlik açığının bulunduğu uygulama bağımlılıklarını içerir.

Her iki servis de etkinleştirildiğinde bulgular otomatik olarak Security Hub’a akar, bu da uyumluluk için tek bir birleşik görünüm sağlar ve CI/CD build’lerini başarısız kılan EventBridge kuralları yazmanıza olanak tanır. Tipik bir zorlama modeli:

Pratik Problem: Uygulama Senaryosu

Senaryo: NovaTech Corp, karma bir işlem (compute) ortamında müşteriye yönelik mikroservisler çalıştırmaktadır: EC2 üzerinde birkaç ECS kümesi, veri işleme için bir EKS kümesi ve olay işleme için sunucusuz Lambda’lar. İmajlar ECR’da saklanmakta, operasyonlar host erişimi için SSM kullanmakta ve GuardDuty/CloudWatch etkinleştirilmiş olmasına rağmen container’lar ve kontrol düzlemi bileşenleri genelinde görünürlük tutarsızdır.

Zorluk: Üretimdeki bir container’da şüpheli giden bağlantılar tespit edildi ve bir mühendis, bir pod’un EC2 instance metadata servisine erişebildiğini keşfetti; bu durum kimlik bilgisi sızdırılma riskini doğurdu. İmaj zafiyetleri ve yetersiz kontrol düzlemi loglaması, kök nedeni gizliyor olabilir.

Önerilen Yaklaşım:

Görevler için ECS Exec’i etkinleştirin ve host ile container çalışma zamanı denetimi için AWS Systems Manager Session Manager’ı zorunlu kılın (ECS Exec + SSM). Bu, SSH ihtiyacını ortadan kaldırır ve oturum aktivitesinin CloudTrail ve CloudWatch Logs’a kaydedilmesini sağlar.
EC2 instance’larında IMDSv2’yi zorunlu kılın (Instance Metadata Service HttpTokens=required, hop limiti=1) ve container’ların instance metadata’yı sorgulayamaması için container ağ ad alanlarından (network namespaces) 169.254.169.254 adresini engelleyen host seviyesinde ağ kuralları uygulayın.
Container’lar ve Lambda için Amazon GuardDuty çalışma zamanı izleme ve Kötü Amaçlı Yazılım Koruması’nı açın, bulguları otomatik sınırlandırma (containment) playbook’ları için Security Hub ve EventBridge’e yönlendirin.
Kontrol düzlemi loglarını (audit, authenticator, controllerManager, scheduler) CloudWatch Logs’a göndererek, IAM Roles for Service Accounts (IRSA) benimseyerek ve riskli yetenekleri sınırlamak için kabul denetimlerini (admission controls) (Pod Security veya OPA Gatekeeper) zorunlu kılarak EKS’i güçlendirin.
Push işleminde tarama (scan-on-push) ile Amazon ECR gelişmiş imaj taramasını (Inspector/ECR taraması) etkinleştirin ve bulguları, zorlama için EventBridge + Lambda aracılığıyla imajları engellemek/karantinaya almak üzere CI’a entegre edin.
Telemetriyi merkezileştirin: CloudTrail, GuardDuty bulguları, EKS kontrol düzlemi logları ve ECR tarama sonuçlarını merkezi bir S3/Lambda/Security Hub pipeline’ına gönderin ve sürekli uyumluluk için AWS Config kurallarını besleyin.

Gerekçe: Bu sıralama, SSH tabanlı erişimi ortadan kaldırır, metadata kimlik bilgisi hırsızlığını önler, çalışma zamanı tespiti ve otomatik müdahale sağlar, imaj hijyenini zorunlu kılar ve kontrol düzlemi görünürlüğü sunar — bu da AWS’in en az ayrıcalık (least privilege), derinlemesine savunma (defense in depth) ve merkezi gözlemlenebilirlik en iyi uygulamalarıyla uyumludur.

# CodeBuild buildspec fragment
post_build:
  commands:
    - aws ecr describe-image-scan-findings \
        --repository-name api --image-id imageTag=$TAG \
        --query 'imageScanFindings.findingSeverityCounts' > findings.json
      CRIT=$(jq '.CRITICAL // 0' findings.json)
      if [ "$CRIT" -gt 0 ]; then echo "Critical CVEs present"; exit 1; fi

Pipeline’a entegrasyon, tarama işlemini bir gösterge paneli egzersizi olmaktan çıkarıp gerçek bir kontrole dönüştüren şeydir.

Lambda: Yetkilendiriciler (Authorizers), Gizli Bilgiler (Secrets) ve Yürütme Rolleri (Execution Roles)

Lambda fonksiyon seviyesindeki güvenlik, sıkça birbiriyle karıştırılan üç düzleme sahiptir:

Kaynak politikası (fonksiyon politikası): Hangi principal’ların (API Gateway, EventBridge, diğer hesaplar) fonksiyonu çağırabileceğini kontrol eder. API Gateway üzerindeki Lambda Authorizer’lar, HTTP çağrıları için kimlik kapısıdır — arka uç (backend) fonksiyonunu çağırmadan önce API Gateway’in önbelleğe alıp uyguladığı bir IAM politikası döndürürler.
Yürütme rolü (Execution role): Fonksiyon kodunun çalışma zamanında üstlendiği kimliktir. Güven politikası (trust policy) lambda.amazonaws.com‘u içermeli ve CloudWatch Logs’un çalışabilmesi için logs:CreateLogGroup, logs:CreateLogStream ve logs:PutLogEvents izinlerini vermelidir. Eğer loglar eksikse, çözüm neredeyse her zaman yürütme rolündedir — sadece CloudWatch’un aldığı logları gösteren Lambda konsolunda değil. “Yalnızca konsol loglarına” güvenmek bir teşhis tuzağıdır: yürütme rolü izni olmaması, log akışı olmaması anlamına gelir ve konsol hiçbir şey göstermez.
Gizli bilgilerin alınması: Kimlik bilgilerini asla ortam değişkenlerine (environment variables) düz metin (plaintext) olarak gömmeyin. Bunları Secrets Manager veya SSM Parameter Store SecureString’de saklayın ve soğuk başlangıçta (cold start) çekin:

import boto3, os, json
_ssm = boto3.client("ssm")
_cached = None

def get_db_password():
    global _cached
    if _cached is None:
        r = _ssm.get_parameter(Name=os.environ["DB_PWD_PARAM"], WithDecryption=True)
        _cached = r["Parameter"]["Value"]
    return _cached

Yürütme rolünün CMK üzerinde ssm:GetParameter ve kms:Decrypt izinlerine ihtiyacı vardır. Sıcak çağrıların (warm invocations) API çağrısından kaçınması için modül kapsamında önbelleğe alın; daha yüksek işlem hacimli (throughput) fonksiyonlarda rotasyona duyarlı otomatik önbellekleme için Secrets Manager Lambda eklentisini kullanın.

ECR Şifrelemesi ve Depo Koruması

Amazon ECR, tüm imajları varsayılan olarak AWS tarafından yönetilen bir anahtarla AES-256 kullanarak bekleme durumunda (at rest) şifreler, ancak düzenlemeye tabi iş yükleri genellikle müşteri tarafından yönetilen bir KMS anahtarı gerektirir. Böylece anahtar rotasyonu, anahtar politikaları ve CloudTrail denetlenebilirliği müşterinin kontrolü altında olur. KMS şifrelemesi yalnızca depo oluşturma zamanında yapılandırılır; mevcut bir ECR deposu oluşturulduktan sonra AES-256’dan KMS’e dönüştürülemez. Bu nedenle taşıma işlemi, yeni bir KMS şifreli depo oluşturmayı, imajları çoğaltmayı veya yeniden push etmeyi, aşağı akış (downstream) tüketicileri güncellemeyi ve eski depoyu silmeyi gerektirir. KMS ile şifrelenmiş bir depodan imaj çeken hesaplar arası (cross-account) tüketicilere, ECR okuma izinlerine ek olarak CMK üzerinde kms:Decrypt izni verilmelidir, aksi takdirde, depo politikası principal’a izin verse bile, pull işlemi bir KMS erişim hatasıyla başarısız olur.

{
  "encryptionConfiguration": {
    "encryptionType": "KMS",
    "kmsKey": "arn:aws:kms:us-east-1:111122223333:key/abcd-...-ef01"
  },
  "imageScanningConfiguration": { "scanOnPush": true },
  "imageTagMutability": "IMMUTABLE"
}

Değişmez etiketler (Immutable tags), doğrulanmış bir v1.2.3 etiketinin, taramadan sonra kötü amaçlı bir imaj tarafından sessizce üzerine yazıldığı etiket ele geçirme (tag-hijack) saldırılarını önler.

İmaj Tarama: Basic, Enhanced ve Inspector

ECR iki tarama modu sunar. Basic tarama, açık kaynaklı Clair CVE veritabanını kullanır, yalnızca push işleminde (veya manuel tetiklemeyle) çalışır ve bulguları ECR konsolunda döndürür. Ücretsizdir, ancak sürekli yeniden tarama yapmaz, işletim sistemi + programlama dili paketlerini birlikte kapsamaz ve Security Hub ile yerel bir entegrasyonu yoktur. Enhanced tarama ise Amazon Inspector tarafından desteklenir ve hem işletim sistemi paketlerini hem de uygulama dili paketlerini (Python, Java, Node.js, Go, Ruby, .NET) kapsar. Inspector, push edilen imajları güncel güvenlik açığı istihbaratına karşı sürekli olarak izler, bu sayede imaj push edildikten bir hafta sonra açıklanan bir CVE bile yeniden derleme gerektirmeden bir bulgu oluşturur.

Enhanced tarama, registry seviyesinde (Bölge başına) etkinleştirilir ve prod-* veya team-a/* gibi joker karakter desenleri kullanan depoya özgü dahil etme filtreleri (inclusion filters) ile yapılandırılır. Bu, “çoğu depoyu tara ancak sandbox/deneme amaçlı olanları hariç tut” şeklindeki yaygın gereksinim için doğru kontroldür — bireysel repolar üzerinde negatif dışlamalar yapmak yerine, taranması gerekenleri listeleyen pozitif filtreler tanımlarsınız.

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{
    "scanFrequency": "CONTINUOUS_SCAN",
    "repositoryFilters":[{"filter":"prod-*","filterType":"WILDCARD"}]
  },{
    "scanFrequency": "SCAN_ON_PUSH",
    "repositoryFilters":[{"filter":"dev-*","filterType":"WILDCARD"}]
  }]'

Inspector Entegrasyonu ve Security Hub Toplaması

Amazon Inspector, taramanın gerekli olduğu her hesapta ve Bölgede etkinleştirilmelidir. Bir AWS Organizations kurulumunda, güvenlik araçları hesabı Inspector için delege edilmiş yönetici (delegated administrator for Inspector) olarak atanır. Bu, taramayı etkinleştirmesine, yeni üye hesaplar için otomatik kaydı (auto-enroll) ayarlamasına ve toplanan bulguları görüntülemesine olanak tanır. Delege etmeyi unutmak — veya otomatik kaydı etkinleştirmeyi unutmak — gözden kaçabilecek bir hata modudur: organizasyona katılan yeni hesaplar, ECR’a sessizce konteyner gönderir ve bunlar hiçbir zaman taranmaz, bu da herhangi bir hata yüzeyi oluşturmadan kapsam garantilerini bozar.

Her iki hizmet de etkinleştirildiğinde ve Security Hub’ın Inspector entegrasyonu açıldığında, Inspector bulguları otomatik olarak AWS Security Hub‘a akar. Security Hub daha sonra bulguları AWS Security Finding Format (ASFF) standardına göre normalleştirir, bunları GuardDuty, Macie ve Config bulgularıyla ilişkilendirir ve — delege edilmiş bir Security Hub yöneticisi ve Bölgeler arası toplama (cross-Region aggregation) ile birleştirildiğinde — tek bir merkezi görünüm (single pane of glass) sunar. Security Hub bulguları üzerindeki EventBridge kuralları, kritik CVE’leri otomatik bilet oluşturma için Lambda’ya yönlendirebilir, sorunlu imajı quarantine=true etiketiyle etiketleyebilir veya bir pipeline kapısı (pipeline gate) aracılığıyla dağıtımı engelleyebilir.

Merkezi Tarama ve Hesaplar Arası CI/CD

Çok hesaplı konteyner iş yükleri için önerilen model, merkezde güçlendirilmiş bir merkezi registry hesabını (hardened central registry account) konumlandırır:

Merkezi hesap: enhanced tarama, değiştirilemez etiketler (immutable tags) ve imaj imzalama (AWS Signer ile entegre Notation/Sigstore aracılığıyla) özelliklerine sahip, KMS ile şifrelenmiş ECR repolarını barındırır.
Build hesapları: merkezi ECR’a build edip push yapan, Inspector bulgularını bekleyen ve önem derecesi eşiklerine göre denetim yapan CodeBuild/CodePipeline job’larını çalıştırır.
İş yükü hesapları (dev/stage/prod): merkezi registry’den hesaplar arası izinler (cross-account permissions) aracılığıyla imajları çeker (pull).

Hesaplar arası okuma erişimi iki katman gerektirir: tüketen hesapta ecr:GetDownloadUrlForLayer, ecr:BatchGetImage ve ecr:GetAuthorizationToken izinlerini veren bir IAM politikası ve merkezi hesaptaki ECR reposu üzerinde belirli tüketici hesaba veya role izin veren bir repository politikası (repository policy).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowProdPull",
    "Effect": "Allow",
    "Principal": {"AWS":"arn:aws:iam::444455556666:role/EcsTaskExecutionRole"},
    "Action": ["ecr:BatchGetImage","ecr:GetDownloadUrlForLayer"]
  }]
}

ECR repository politikaları kaynak tabanlı olduğu için, erişimi kimlik ve kaynak politikasının kesişimi belirler — bu katmanlardan birinin atlanması AccessDeniedException hatasına neden olur. KMS işin içinde olduğunda, KMS anahtar politikası (key policy) ayrıca hesaplar arası principal’a kms:Decrypt iznini de vermelidir.

EKS Kontrol Düzlemi Günlüğü ve Gözlemlenebilirlik

EKS için, yönetilen kontrol düzlemine (managed control plane) doğrudan erişilemez, bu nedenle güvenlikle ilgili Kubernetes olayları yalnızca kontrol düzlemi günlüğü (control plane logging) açıkça etkinleştirildiğinde ortaya çıkar. Beş log türü mevcuttur: api, audit, authenticator, controllerManager ve scheduler. audit logu en yüksek değere sahip güvenlik artifaktıdır — IAM authenticator aracılığıyla çözümlenen çağıran kimliğiyle birlikte kümeye yapılan her API çağrısını kaydeder — ve authenticator logu ise IAM-Kubernetes RBAC eşleştirme kararlarını kaydeder. Tüm türler, bir /aws/eks/<cluster>/cluster log grubunda CloudWatch Logs‘a akış olarak gönderilir ve buradan Kinesis Data Firehose’a abone olunabilir, S3’e yönlendirilebilir veya bir SIEM’e gönderilebilir.

aws eks update-cluster-config --name prod-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator",
  "controllerManager","scheduler"],"enabled":true}]}'

Kontrol düzlemi loglarını GuardDuty EKS Protection (node’larda çalışma zamanı tehdit tespiti) ile tamamlayın ve node instance profilleri yerine IRSA (IAM Roles for Service Accounts) kullanın, böylece audit logları AWS API aktivitesini belirli pod’lara atfeder.

Sık Karşılaşılan Tuzaklar

Yalnızca push anında taramaya (scan-on-push) güvenmek: Temel push anında tarama, push anında bilinen güvenlik açıklarını yakalar ancak kayıt defterinde (registry) zaten bulunan imajlara karşı daha sonra ifşa edilen CVE’ler hakkında hiçbir şey yapmaz. PCI DSS ve FedRAMP gibi denetim çerçeveleri, CONTINUOUS_SCAN sıklığında gelişmiş tarama ve Security Hub ile entegrasyon gerektiren sürekli güvenlik açığı değerlendirmesi talep eder. Her push için tek seferlik bir anlık görüntü, bu denetimi karşılamaz.

Durağan halde şifrelemenin (encryption-at-rest) gerekli olduğu durumlarda ECR’da KMS’i atlamak: Varsayılan AES-256 şifrelemesi gerçek bir şifrelemedir, ancak müşteri tarafından yönetilen anahtarlar (customer-managed keys), anahtar rotasyon kayıtları ve principal başına kms:Decrypt denetim izleri talep eden uyumluluk rejimleri, AWS’nin sahip olduğu anahtarlarla (AWS-owned keys) karşılanamaz. Şifreleme türü depo başına değiştirilemez (immutable) olduğundan, bu durum oluşturma sırasında ele alınmalıdır — deponun yeniden oluşturulması olmadan “daha sonra açarız” demek imkansızdır.

Inspector temsilci yöneticisini (delegated admin) veya otomatik kaydı (auto-enroll) unutmak: Inspector için bir temsilci yönetici olmadan, her hesap sahibi taramayı bağımsız olarak etkinleştirmeli ve bulguları iletmelidir; bu, operasyonel olarak uygulanamaz ve kapsam boşlukları yaratır. Yeni üye hesaplar için otomatik etkinleştirme olmadan, Control Tower veya Organizations aracılığıyla oluşturulan her yeni hesap Inspector devre dışı bırakılmış olarak başlar, bu nedenle merkezi hesaptaki Security Hub hiçbir bulgu göstermese bile ECR imajları taranmaz — bu durum, bariz bir hata yerine sessiz bir yanlış negatiftir (silent false-negative).

Pratik Problem: Kullanım Senaryosu

Senaryo: Meridian Financial, prod, dev ve özel bir güvenlik hesabına yayılmış production EKS kümeleri, ECS servisleri ve çok sayıda ECR kayıt defteri (registry) ile çoklu hesaplı bir AWS ortamı işletmektedir. Güvenlik ekibi izleme ve uyumluluk için merkezi bir hesabı yönetirken, mühendislik ekipleri CI/CD işlem hatları aracılığıyla konteyner imajlarını ECR’a push’lar ve EKS/ECS’e dağıtır.

Zorluk: Yakın zamanda yapılan bir dağıtım, production ortamına geçmeden önce tespit edilemeyen yüksek önem dereceli bir güvenlik açığı içeren bir konteyner teslim etti. Araştırmacılar, sınırlı EKS kontrol düzlemi (control plane) logları ve hesaplar arasında parçalı tarama sonuçları buldular, bu da düzeltme sürecini yavaşlattı.

Önerilen Yaklaşım:

ECR depo seviyesinde korumaları etkinleştirin: imaj etiketi değişmezliğini (immutability) zorunlu kılın, belirli IAM rolleriyle push/pull işlemlerini sınırlayan depo politikaları uygulayın ve depoları özel bir AWS KMS müşteri tarafından yönetilen anahtar (CMK) ile durağan halde şifreleyin.
Güvenlik açığı bulguları üretmek için push anında imaj taramasını (temel) açın ve ECR için Amazon Inspector gelişmiş imaj taramasını etkinleştirin; hesaplar genelindeki önem derecelerinin merkezi olarak toplanması için Inspector’ı AWS Security Hub ile entegre edin.
Merkezi, hesaplar arası taramayı uygulayın: Güvenlik hesabının her imajı Inspector ve ek SCA/DAST araçlarıyla taramasını sağlamak için ECR replikasyonunu yapılandırın veya bir güvenlik hesabı CodeBuild/CodePipeline rolüne hesaplar arası pull izinleri verin. Artefaktları, güvenlik hesabı CMK’si ile şifrelenmiş merkezi bir S3 bucket’ında saklayın.
CI/CD geçiş denetimi (gating) uygulayın: Inspector/Security Hub bulgularını sorgulayan ve yüksek/kritik bulgulara sahip imajları otomatik olarak engelleyen veya onay gerektiren bir işlem hattı tarama aşaması (CodeBuild/CodePipeline veya STS assume-role ile GitHub Actions) ekleyin.
EKS gözlemlenebilirliğini iyileştirin: EKS kontrol düzlemi loglarını (API, Audit, Authenticator, ControllerManager, Scheduler) merkezi bir loglama hesabındaki CloudWatch Logs’a gönderin, EKS API olayları için CloudTrail’i etkinleştirin ve çalışma zamanı (runtime) izlemesi için Container Insights ve GuardDuty’yi kullanın.

Gerekçe: Bu yaklaşım, derinlemesine savunma (defense-in-depth) uygular: kayıt defterlerini şifrelemek ve korumak, Inspector ile gelişmiş taramayı otomatikleştirmek, tutarlı politika uygulaması için bulguları Security Hub’da merkezileştirmek, CI/CD’de dağıtımları denetlemek (gating) ve hızlı tespit ve adli analiz için EKS kontrol düzlemi loglarını etkinleştirmek. Bu yöntemler, AWS’nin en az ayrıcalık (least-privilege) ve merkezi izleme en iyi uygulamalarıyla uyumludur.

← Güvenlik Açığı · Tüm alanlar · Olay Müdahalesi ve Adli Biliş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 →

Amazon'a göz atın →