Amazon SCS-C02: Güvenlik Açığı, Yama ve Ana Bilgisayar 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.
Amazon Inspector: EC2, Lambda ve ECR Genelinde Gelişmiş Tarama
Amazon Inspector, EC2 sunucularında, ECR’da depolanan konteyner imajlarında ve Lambda fonksiyonlarında (hem uygulama kodu hem de bağımlılık katmanları) CVE’leri keşfeden, sürekli ve aracı (agent) destekli bir güvenlik açığı yönetimi hizmetidir. Inspector’ı hesap seviyesinde etkinleştirmek, uygun kaynakları otomatik olarak kaydeder — kaynak bazında bir katılım iş akışı yoktur — ve bulgular, standartlaştırılmış ASFF formatında AWS Security Hub’a otomatik olarak gönderilir. Merkezi bir güvenlik duruşu panosu gerektiğinde doğru entegrasyon modeli budur.
EC2 için Inspector, hibrit bir tarama modeli kullanır. SSM Agent (AWS tarafından sağlanan ilişkilendirme ile), aracısız (agentless) tarzda ağ erişilebilirliği ve paket değerlendirmesi için kullanılan bir yazılım envanteri toplarken, derin ana makine (host) değerlendirmesi, aracının çalışıyor olmasını ve sunucunun SSM üzerinden erişilebilir olmasını gerektirir. “Sadece aracısız” yaklaşımının bir tuzak olmasının nedeni budur: SSM Agent yolu (veya gerektiğinde Inspector’ın aracı tabanlı derin denetimi) olmadan, yüzeysel bulgular — ağ maruziyeti ve manifest dosyasından türetilen CVE’ler — elde edersiniz, ancak çalışma zamanı (runtime) kütüphane envanterlerini, yönetilmeyen paketleri ve yapılandırmaları kaçırırsınız. Hibrit mod, çoğu üretim ortamının ihtiyaç duyduğu şeydir.
Lambda için Inspector iki tür tarama gerçekleştirir: standart (katmanlardaki ve fonksiyon bağımlılıklarındaki paket güvenlik açıkları) ve kod taraması (injection kusurları, kod içine gömülmüş gizli bilgiler (secrets) ve güvensiz API’ler için fonksiyon kodunun statik analizi). Kritik bir uygunluk kuralı: Bir Lambda fonksiyonunun taranabilmesi için son 90 gün içinde en az bir kez çağrılmış olması gerekir. Boşta duran veya arşivlenmiş fonksiyonlar sessizce Inspector’ın kapsamından çıkar. “Inspector etkin, dolayısıyla her fonksiyon kapsanıyor” diye varsayan ekipler, denetçiler nadiren yürütülen fonksiyonlar hakkında kanıt istediğinde zor durumda kalır. Çözüm, fonksiyonları bir zamanlamayla (EventBridge) çağırmak veya bu istisnayı kabul edip belgelemektir.
ECR için, gelişmiş tarama (Inspector tarafından desteklenen), Clair tabanlı eski temel taramanın yerini alır. Gelişmiş tarama, hem yüklemede taramayı (scan on push) hem de kayıt defterinde (registry) zaten bulunan imajların sürekli taranmasını destekler. Böylece, daha önce yüklenmiş imajları etkileyen yeni açıklanan CVE’ler, yeniden yükleme gerektirmeden yeni bulgular oluşturur. Maliyeti kontrol etmek için gelişmiş taramayı kayıt defteri seviyesinde etkinleştirin ve depo başına filtreler (örneğin, prod/* sürekli, sandbox/* sadece yüklemede tara) yapılandırın.
Yetkilendirilmiş Yönetim ve Gizleme (Suppression)
Çoklu hesaplı bir AWS Organizations kurulumunda, yönetim hesabından Inspector için bir yetkilendirilmiş yönetici (delegated administrator) hesabı belirleyin. Yetkilendirilmiş yönetici, üye hesaplardaki birleştirilmiş bulguları görür ve kuruluş genelindeki tarama yapılandırmasını kontrol eder. Bu, bulguları almak için hesaplar arası IAM rolleri verme ihtiyacını ortadan kaldırır ve Inspector’ı her hesap için parça parça etkinleştirme şeklindeki anti-modeli (anti-pattern) önler.
Gizleme kuralları (Suppression rules), bir güvenlik ekibinin bulguları silmeden gürültüyü filtrelemesine olanak tanır. Bir kural, kaynak etiketi, önem derecesi, CVE ID’si veya ECR deposu gibi niteliklere göre eşleşir. Geliştirme/test (dev/test) Lambda bulgularını üretim panosundan uzak tutmak için, Environment=dev etiketine dayalı bir gizleme kuralı uygulayın — bulgular denetim için altta yatan veri deposunda var olmaya devam eder, ancak varsayılan görünümlerden ve yapılandırılmışsa Security Hub’dan hariç tutulur. Bunu, geliştirme hesapları için Inspector’ı devre dışı bırakarak yapmayın; güvenlik açığı içeren bir yapının (artifact) geliştirme ortamından üretime taşınmasını yakalama yeteneğinizi kaybedersiniz.
İmaj Yükseltme için CI/CD Kontrol Kapısı (Gating)
Gelişmiş ECR taraması, bir pipeline’ın sorgulaması gereken imaj özetine (digest) (sadece etikete değil) bağlı bulgular üretir. Standart model şöyledir: imajı oluştur → ECR’a yükle (yüklemede taramayı tetikler) → taramanın tamamlanmasını yokla veya bekle → Yüksek veya Kritik seviyede bulgular varsa derlemeyi (build) başarısız yap → aksi takdirde ECS/EKS görevini/dağıtımını (task/deployment) güncelle.
buildspec.yml içinde minimal bir CodeBuild adımı:
post_build:
commands:
DIGEST=$(aws ecr describe-images --repository-name $REPO \
--image-ids imageTag=$TAG --query 'imageDetails[0].imageDigest' -o text)
aws inspector2 list-findings \
--filter-criteria "{\"ecrImageHash\":[{\"comparison\":\"EQUALS\",\"value\":\"$DIGEST\"}],\"severity\":[{\"comparison\":\"EQUALS\",\"value\":\"HIGH\"},{\"comparison\":\"EQUALS\",\"value\":\"CRITICAL\"}]}" \
--query 'findings[].findingArn' --output text > findings.txt
- if [ -s findings.txt ]; then echo "Blocking - CVEs found"; exit 1; fi
Bu aşamada bir kontrol kapısı koymamak - “Inspector bizi uyarır” diye güvenmek - klasik bir hatadır: uyarılar asenkron olarak ve güvenlik açığı içeren imaj zaten çalışmaya başladıktan sonra gelir. Kontrol kapısı, yükseltme işlemiyle senkron olmalıdır. Benzer şekilde, özet yerine sadece etikete göre kontrol kapısı koymak güvenli değildir çünkü etiketler değiştirilebilir (mutable); aynı etiketle yapılan iki yükleme, tarama sonuçlarını karıştıracaktır.
Patch Manager, Temel Çizgiler (Baselines) ve Yama Grupları (Patch Groups)
SSM Patch Manager üç temel bileşen üzerinde çalışır:
Yama temel çizgisi (Patch baseline): otomatik onaylama kurallarını, onaylanmış yamaları, reddedilmiş yamaları ve önem/sınıflandırma başına uyumluluk seviyesini tanımlar.
Yama grubu (Patch group): anahtarı tam olarak
Patch Groupolan ve değeri, sunucuları belirli bir temel çizgiye kaydeden bir etikettir.Bakım penceresi (Maintenance window):
AWS-RunPatchBaselinekomutunun Tarama (Scan) veya Yükleme (Install) görevlerini yürüttüğü zamanlamadır.
Geliştirme (Dev) ortamının tüm güvenlik yamalarını derhal otomatik olarak onaylamasını, Üretim (Prod) ortamının ise yalnızca Kritik/Önemli yamaları 7 günlük bir bekleme süresinden sonra otomatik olarak onaylarken çekirdek (kernel) paketlerini reddetmesini gerektiren bir ortam için iki temel çizgi oluşturursunuz. Dev temel çizgisi, tüm güvenlik sınıflandırmalarını kapsayan ApproveAfterDays: 0 ile bir onay kuralı kullanır. Prod temel çizgisi, ApproveAfterDays: 7, ComplianceLevel: CRITICAL kullanır, Classification=Security ve Severity in [Critical, Important] filtrelerini uygular ve BlockAllPatchesFromRejectedList ile reddedilen yamalar listesine kernel* ekler. Sunucular Patch Group=Dev veya Patch Group=Prod olarak etiketlenir ve her yama grubu ilgili temel çizgiye kaydedilir. Uyumluluk durumu Yama Uyumluluk raporları (Patch Compliance reports) aracılığıyla toplanır ve merkezi denetim için S3’e aktarılabilir.
Tek bir temel çizgi “mantıkla” Dev ve Prod arasındaki farkları ifade edemez — temel çizgiler, kaydedildikleri grup başına statiktir. Bu davranışı taklit etmek için farklı Bakım Pencereleri kullanmaya çalışmayın; pencere, yamaların ne zaman çalışacağını kontrol eder, hangi yamaların onaylanacağını değil.
Gerçek Zamanlı Bildirim İş Hattı
Yeni bulgularla ilgili Slack veya Microsoft Teams uyarıları için operasyonel olarak verimli zincir şöyledir:
Inspector,
aws.inspector2olay kaynağında EventBridge’e bulguları yayar.EventBridge kuralı, önem derecesine göre (ör.
HIGH,CRITICAL) filtreler ve bir SNS topic’ini hedefler.SNS topic’i, Slack kanalına veya Teams çalışma alanına eşlenmiş bir AWS Chatbot aboneliğine sahiptir.
Chatbot doğrudan SNS’e abone olur — mesajları yeniden biçimlendirmek için araya bir Lambda koymayın, çünkü Chatbot Inspector bulgularını yerel olarak işler. Örnek bir EventBridge deseni:
{
"source": ["aws.inspector2"],
"detail-type": ["Inspector2 Finding"],
"detail": { "severity": ["HIGH", "CRITICAL"] }
}
Burada kaçınılması gereken iki tuzak vardır: Security Hub üzerinden yönlendirme gecikme ekler ve özel içgörüler yanlış yapılandırılırsa önem derecesi ayrıntısını düşürebilir; SES veya özel bir webhook Lambda kullanmak ise Chatbot’un zaten yerel olarak sağladığı bir yetenek eklemeden operasyonel yükü artırır.
Pratik Problem: Kullanım Senaryosu
Senaryo: Meridian Financial, müşteriye yönelik web servislerini, toplu analizleri ve sunucusuz olay işlemcilerini destekleyen çok hesaplı bir AWS organizasyonu işletmektedir. CI/CD iş hatları konteyner imajlarını Amazon ECR’a gönderir, eski (legacy) iş yükleri için EC2 filoları barındırır ve daha yeni servisler için Lambda kullanır; bir güvenlik hesabındaki merkezi bir güvenlik ekibi, hesaplar genelinde zayıflık görünürlüğünü ve yama yönetimini yönetmelidir.
Zorluk: Yüksek önem dereceli bir kütüphane içeren yeni bir imaj, CI/CD’de taramalar zorunlu kılınmadığı için üretim ortamına terfi ettirildi ve EC2 örneklerinin yamalanması ortamlar arasında tutarsız, bu da riske maruz kalma pencereleri ve ekibi bunaltan gürültülü bulgular bırakıyor.
Önerilen Yaklaşım:
- Taramaların, bulguların ve bastırma kurallarının merkezi olarak yönetilebilmesi için AWS Organizations’da yetkilendirilmiş yönetimi (delegated administration) yapılandırarak güvenlik hesabından EC2, Lambda ve ECR genelinde Amazon Inspector Gelişmiş Taramasını (Enhanced Scanning) etkinleştirin.
- Push işleminde ECR imaj taramasını yapılandırın ve tarama kapılarını CodePipeline/CodeBuild’e entegre edin: Inspector/ECR tarama sonuçları önem derecesi eşiklerini karşılayana kadar imaj terfisini engelleyin ve bulguları derleme adımı aracılığıyla yüzeye çıkarın.
- Ortam başına tanımlanmış yama temelleri (patch baselines) ve yama grupları (patch groups) ile AWS Systems Manager Patch Manager’ı uygulayın, önce üretim dışı ortamlarda dağıtım için Bakım Pencereleri (Maintenance Windows) planlayın ve SSM Automation dokümanlarını kullanarak kritik CVE düzeltmeleri için onayı otomatikleştirin.
- Inspector bulgularını ve SSM uyumluluk olaylarını yakalamak için Amazon EventBridge kullanarak gerçek zamanlı bir bildirim iş hattı oluşturun, bunları Amazon SNS’e ve zenginleştiren, tekilleştiren ve önceliklendirilmiş uyarıları Slack’e gönderip takip biletleri oluşturan hafif bir AWS Lambda’ya yönlendirin.
- Sınırlama ve iyileştirmeyi otomatikleştirin: Etkilenen EC2/Lambda sürümlerini izole etmek veya imajların yeniden oluşturulmasını tetiklemek için EventBridge tarafından tetiklenen SSM Automation veya Lambda runbook’larını kullanın ve gürültüyü azaltmak için yetkilendirilmiş yönetici hesabı aracılığıyla Inspector bastırmasını yalnızca takip edilen yanlış pozitifler (false positives) için uygulayın.
Gerekçe: Merkezi Inspector yönetimi, CI/CD kapıları, Patch Manager temelleri ve EventBridge güdümlü bir iş hattı, otomatik önlemeyi zorunlu kılarak, tutarlı yama yönetimi ve önceliklendirilmiş, denetlenebilir müdahale sağlayarak ve aynı zamanda uyarı yorgunluğunu azaltarak AWS en iyi uygulamalarını takip eder.
Amazon Inspector ile Zayıflık Keşfi
Amazon Inspector, AWS’deki birincil yönetilen zayıflık değerlendirme hizmetidir ve ana makine (host) güvenliğiyle ilgili üç yüzeyde çalışır: EC2 örnekleri, Amazon ECR’daki konteyner imajları ve Lambda fonksiyonları. Hesap veya Organizations düzeyinde (Inspector konsolunda yetkilendirilmiş yönetici aracılığıyla) etkinleştirildiğinde, zamanlanmış anlık taramalar yerine sürekli, ajansız veya SSM tabanlı tarama gerçekleştirir. Bu sürekli duruş önemlidir çünkü CVE beslemeleri günlük olarak değişir; geçen haftadan bir anlık görüntü çoktan eskimiş olabilir.
EC2 için Inspector, yüklü paketleri ve çekirdek sürümlerini listelemek için SSM Agent’a dayanır, ardından bunları satıcı tavsiyeleri ve Ulusal Zayıflık Veritabanı (National Vulnerability Database) ile ilişkilendirir. Bulgular arasında CVE tanımlayıcısı, CVSS puanı, etkilenen paket, düzeltilmiş sürüm ve ağ erişilebilirlik bağlamı (ağ erişilebilirlik kuralları, ENI’lar, güvenlik grupları, NACL’ler ve yönlendirme tabloları aracılığıyla internete açık portları tanımlar) bulunur. Tarama SSM’e bağlı olduğu için, örnek profilinde (instance profile) AmazonSSMManagedInstanceCore yönetilen ilkesi bulunmayan bir EC2 örneği Inspector sonuçlarında görünmeyecektir — bu, hatırlanmaya değer sessiz bir başarısızlıktır.
ECR için Inspector iki tarama modunu destekler:
Temel tarama (Basic scanning): ücretsizdir, açık kaynaklı Clair motorunu kullanır, yalnızca push işleminde veya isteğe bağlı olarak çalışır.
Gelişmiş tarama (Enhanced scanning): Inspector desteklidir, yeni CVE’ler yayınlandıkça, push olayından çok sonra bile imajları (hem işletim sistemi paketlerini hem de Python, Node, Java gibi uygulama dili paketlerini) sürekli olarak yeniden tarar.
Yaygın bir tuzak, ECR’ın push anında tarama özelliğini yeterli ana makine güvenliği olarak görmektir. Bu doğru değildir. Push anında tarama, imajı derleme zamanında doğrular, ancak çalışan konteyner, imajı ve zamanla oluşan herhangi bir sapmayı devralır ve altında yatan EC2 veya Fargate ana makinesinin kendi çekirdek ve işletim sistemi paketleri vardır ve bunlar bağımsız olarak yamalanmalıdır. Gelişmiş tarama, EC2 ana makine taramasıyla birleştirildiğinde bu boşluğu kapatır. Tüm Inspector bulguları AWS Security Hub’a yönlendirilmelidir; bu servis, onları ASFF formatına normalleştirir ve EventBridge aracılığıyla hesaplar arası birleştirme, tekilleştirme ve aşağı yönlü otomasyonu mümkün kılar.
Patch Manager ve Filo Çapında Düzeltme
AWS Systems Manager Patch Manager, Inspector’ın keşfettiği sorunları fiilen düzelterek onu tamamlar. Inspector “hangi CVE’ler beni etkiliyor?” sorusunu yanıtlarken, Patch Manager “hangi yamalar eksik ve bunları nasıl güvenli bir şekilde kurarım?” sorusunu yanıtlar.
Patch Manager, sınıflandırma (Güvenlik, Kritik, Hata Düzeltme), önem derecesi ve otomatik onay gecikmesine (örneğin, satıcı kararlılığına zaman tanımak için Güvenlik yamalarını yayınlandıktan yedi gün sonra onayla) dayalı olarak hangi yamaların onaylandığını tanımlayan bildirimsel kurallar olan yama temelleri (patch baselines) aracılığıyla çalışır. AWS, her işletim sistemi için varsayılan temeller (AWS-AmazonLinux2DefaultPatchBaseline, AWS-WindowsPredefinedPatchBaseline, vb.) sağlar, ancak üretim filoları genellikle sunuculardaki Patch Group etiketi aracılığıyla yama gruplarına (patch groups) bağlı özel temeller kullanır.
Tipik bir tarama ve yama uygulama iş akışı iki işlem kullanır:
Tara (Scan): herhangi bir şey yüklemeden uyumluluğu raporlar; sonuçlar Patch Manager uyumluluk panosunda ve Config’de görünür.
Yükle (Install): onaylanmış yamaları uygular ve birçok işletim sistemi için yeniden başlatır.
Bu işlemler genellikle bir AWS-RunPatchBaseline doküman hedefi ile bakım pencereleri (maintenance windows) aracılığıyla zamanlanır. Acil sıfırıncı gün senaryoları için Patch Manager, bakım penceresi takvimini atlayan isteğe bağlı bir eylem olan Şimdi Yamala (Patch Now) özelliğini sunar. Önerilen model, yalnızca zafiyeti düzelten belirli KB’yi veya paketi onaylayan dar kapsamlı bir yama temeli oluşturmak, etkilenen yama grubunu hedeflemek, Şimdi Yamala’yı çalıştırmak ve yürütme çıktısını merkezi bir S3 bucket’ına ve CloudWatch Logs grubuna akıtmaktır. Bu merkezi günlük, denetçiler veya olay müdahalesi için düzeltme kanıtı olan denetim kanıtınız (audit artifact) haline gelir.
Pratik Problem: Kullanım Senaryosu
Senaryo: Meridian Financial, müşteri odaklı hizmetleri destekleyen birkaç yüz EC2 sunucusu (Windows ve Amazon Linux) ve küçük bir EKS kümesi ile çoklu hesaplı bir AWS ortamı işletmektedir. Operasyonel araçlar için AWS Organizations ve AWS Systems Manager kullanmakta ve paylaşılan bir imaj hesabında AMI’ları muhafaza etmektedirler, ancak hesaplar arasında tutarlı otomatik zafiyet taraması veya koordine edilmiş yama dağıtımları bulunmamaktadır.
Zorluk: OpenSSL’i etkileyen halka açık bir CVE yayınlanır ve Amazon Inspector birden fazla sunucuda yüksek seviyeli bulgular raporlar, ancak yama uygulaması düzensiz olmuştur ve bir üretim hizmeti, gecikmiş düzeltme nedeniyle kısa bir istismar girişimine maruz kalmıştır.
Önerilen Yaklaşım:
- Hem imaj hem de çalışan sunucu zafiyet taramaları yapmak için Amazon Inspector’ı tüm hesaplarda ve bölgelerde etkinleştirin ve yüksek önem dereceli bulguları AWS Security Hub’a ve bir EventBridge özel olay yoluna (custom event bus) iletin.
- Etkilenen sunucuları belirlemek ve kritikliklerine göre etiketlemek için AWS Systems Manager Inventory’yi kullanın; gerekli OpenSSL düzeltmelerini içeren bir Patch Manager temeli oluşturun ve Windows/Linux kurallarını hedefleyin.
- Inspector bulguları tanımlanmış bir önem derecesine ulaştığında bir SSM Otomasyon dokümanını tetikleyen bir EventBridge kuralı oluşturun; bu kural, yamaları uygulamak ve gerektiğinde yeniden başlatmak için Patch Manager veya Run Command’i çağıran bir Otomasyon runbook’una sunucu ID’lerinin listesini geçirir.
- Durum bilgisi olan (stateful) veya yüksek riskli hizmetler için, yamalı AMI’lar oluşturmak (bake) üzere EC2 Image Builder kullanarak sıralı güncellemeleri (rolling updates) yönetin, Auto Scaling gruplarını veya EKS düğüm gruplarını kontrollü bir mavi/yeşil veya sıralı dağıtımla güncelleyin ve Route 53/ALB sağlık kontrolleri ile hizmet sağlığını doğrulayın.
- Düzeltmeden sonra, bulguların çözüldüğünü doğrulamak için Amazon Inspector’ı yeniden çalıştırın, SSM Uyumluluk raporlamasını güncelleyin ve SNS aracılığıyla güvenlik ekibine bir özet gönderin; tekrarlanabilir filo çapında müdahale için Otomasyon runbook’unu bir Systems Manager Otomasyon kütüphanesinde saklayın.
Gerekçe: Bu yaklaşım, sürekli keşif için Amazon Inspector’ı, kontrollü, otomatik düzeltme için Systems Manager Patch Manager ve Otomasyon’u ve değişmez altyapı (immutable infrastructure) için imaj tabanlı yeniden oluşturmaları kullanarak, AWS’nin tespit, otomatik müdahale ve minimum etki alanı (blast radius) için en iyi uygulamalarıyla uyumludur.
# Example: focused baseline for an urgent CVE
Name: emergency-openssl-cve
OperatingSystem: AMAZON_LINUX_2
ApprovalRules:
PatchRules:
- PatchFilterGroup:
PatchFilters:
- Key: PRODUCT
Values: [AmazonLinux2]
- Key: CVE_ID
Values: [CVE-2024-XXXXX]
ApproveAfterDays: 0
ComplianceLevel: CRITICAL
Merkezi uyumluluk, Systems Manager Explorer’da delege edilmiş yönetici hesabını yapılandırarak ve her hesaptaki yama uyumluluk durumunu tek bir S3 bucket’ında toplamak için kaynak verisi senkronizasyonunu (resource data sync) etkinleştirerek sağlanır. Bu veriler daha sonra Athena ile sorgulanabilir veya QuickSight’ta görselleştirilebilir.
Denetlenebilir Yönetim için Session Manager
Geleneksel SSH tabanlı erişimin üç yapısal zayıflığı vardır: uzun ömürlü anahtar materyali operatörlerin dizüstü bilgisayarlarında durur, 22 numaralı portun (sadece bir bastion üzerinden bile olsa) erişilebilir olması gerekir ve kabuk aktivitesi ek araçlar olmadan merkezi olarak kaydedilmez. Session Manager bu üçünü de ortadan kaldırır.
Session Manager, SSM Agent’ın SSM uç noktalarına yaptığı giden HTTPS bağlantısı üzerinden etkileşimli bir kabuk tüneller. Gelen bir port, SSH anahtar çifti ve bastion sunucusu yoktur. Erişim, IAM politikaları (ssm:StartSession kapsamı sunucu etiketi veya ARN ile belirlenir) ile yetkilendirilir ve her oturum, isteğe bağlı olarak KMS şifrelemesi ile CloudWatch Logs’a veya S3’e kaydedilebilir. Linux’ta oturumlar varsayılan olarak ssm-user olarak çalışır; sudo davranışı IAM tarafından değil, sunucunun sudoers yapılandırması tarafından kontrol edilir.
Yeni filolar için doğru sıkılaştırma deseni şudur: sunucuları bir EC2 anahtar çifti olmadan başlatın, AmazonSSMManagedInstanceCore içeren bir örnek profili (instance profile) ekleyin, sunucuları ssm, ssmmessages ve ec2messages için VPC uç noktaları olan özel alt ağlara yerleştirin ve Session Manager tercihleri seviyesinde oturum kaydını zorunlu kılın. Session Manager’ın yanında SSH anahtarlarını dağıtmaya devam etmek bir tuzaktır: bu, Session Manager’ın ortadan kaldırmak için benimsendiği saldırı yüzeyini korur ve kaydedilmeyen bir erişim kanalı bırakır. AMI oluşturma (bake) sürecinizden authorized_keys hazırlığını kaldırın.
CloudWatch Agent ile Sunucu Telemetrisi
Birleşik CloudWatch agent, EC2 hipervizörünün göremediği işletim sistemi seviyesindeki metrikleri (bellek, disk, işlem başına CPU) ve günlük dosyalarını toplar. Genellikle Parameter Store’da saklanan bir JSON dosyası aracılığıyla yapılandırılır ve ardından amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-linux komutuyla uygulanır.
Agent ile ilgili en yaygın operasyonel hata, instance profilinde IAM izinlerinin eksik olmasıdır. Agent’ın en azından şunlara ihtiyacı vardır:
logs:CreateLogGroup (grup önceden oluşturulmamışsa)
logs:CreateLogStream
logs:PutLogEvents
logs:DescribeLogStreams
cloudwatch:PutMetricData (özel metrikler için)
ssm:GetParameter (yapılandırmayı Parameter Store’dan çekmek için)
CloudWatchAgentServerPolicy yönetilen politikası bunları bir araya toplar. İzinler eksik olduğunda, agent başarıyla başlar ve systemctl status komutunda sağlıklı görünür, ancak günlükler CloudWatch’a asla ulaşmaz — hatalar yalnızca /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log dosyasında görülebilir. Merkezi günlükleri varsayan herhangi bir sunucu güvenlik tasarımı, yalnızca agent durumunu değil, günlüklerin teslimatını da doğrulamalıdır.
Bütünün Parçalarını Birleştirmek
Savunma döngüsü şöyledir: Inspector, sunucularda ve konteyner imajlarında CVE’leri keşfeder, bulgular toplanmak üzere Security Hub’a akar, Patch Manager zamanlanmış bakım pencereleri aracılığıyla veya acil durumlar için “Patch Now” (Şimdi Yamala) ile iyileştirme yapar, Session Manager tek idari erişim yolunu sağlar ve CloudWatch agent hem yamalama kanıtlarını hem de çalışma zamanı günlüklerini merkezi bir hesaba akıtır. Her kontrol diğerini varsayar: Patch Manager olmadan Inspector, kimsenin dikkate almadığı raporlar üretir; merkezi günlük kaydı olmadan Patch Manager, denetim izi oluşturmaz; uygun IAM olmadan Session Manager, ya çok fazla ya da çok az erişim bırakır; ve doğru günlük izinleri olmadan CloudWatch agent, bir görünürlük yanılsaması yaratır.
← Yönetişim · Tüm alanlar · Konteyner ve Sunucusuz Güvenliği →
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 →