Amazon DOP-C02: Güvenlik, Uyumluluk ve Yönetişim — Çalışma kılavuzu

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS DevOps Engineer Professional DOP-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.

Genel Bakış

AWS’te güvenlik, uyumluluk ve yönetişim; teslimatı yavaşlatmadan hesaplar ve Region’lar arasında ölçeklenen belirleyici kontrollere dayanır. Sağlam bir tasarım; kimlik kontrolleri (IAM, izin sınırları ve hizmet kontrol politikaları), çoklu hesap yönetişimi (AWS Organizations ve Control Tower), sürekli değerlendirme ve iyileştirme (AWS Config), tehdit tespiti (Security Hub, GuardDuty, Inspector), gizli bilgi hijyeni, AWS KMS ile şifreleme ve ağ izolasyonu (VPC güvenlik grupları, NACL’ler, endpoint’ler ve PrivateLink) gibi katmanlardan oluşur. Amaç, en az ayrıcalık ilkesini ve geliştirici özerkliğini korurken patlama yarıçapını en aza indirmek, uyumluluğu sürekli olarak kanıtlamak ve önleme ile iyileştirmeyi otomatikleştirmektir.

Kimlik, Politika ve Çoklu Hesap Yönetişimi

IAM rolleri, politikaları, izin sınırları ve SCP’ler, etkin izin kümesini oluşturmak için birlikte çalışır. Bir IAM rolünün kimlik tabanlı politikaları, izin verilen eylemleri tanımlar; rolün güven politikası ise rolü kimin üstlenebileceğini tanımlar. İzin sınırları, kimlik politikalarının ne söylediğine bakılmaksızın bir principal’ın yapabileceklerini sınırlar. AWS Organizations’daki SCP’ler, bir üye hesaptaki herhangi bir principal (root kullanıcısı dahil) için mutlak maksimumu belirler. Kaynak tabanlı politikalar (S3, KMS, Secrets Manager vb. için) hesaplar arası erişime izin verebilir, ancak bunlar da SCP’ler veya izin sınırları tarafından dayatılan sınırları aşamaz. Etkin izin, şunların kesişimidir: kimlik politikaları ∩ izin sınırı ∩ oturum politikaları (varsa) ∩ kaynak politikası (uygulanabilirse) ∩ SCP’ler; herhangi bir açık Deny ifadesi önceliklidir.

Tek bir hesapta güvenli self-servis sağlamak için izin sınırlarını kullanın. Örneğin, bir geliştirici sağlama ardışık düzeni, yalnızca belirli kalıplar dışında iam:PassRole eylemini reddeden, hassas anahtarlarda kms:Decrypt eylemini reddeden ve EC2 instance türlerini sınırlayan bir sınır eklemesi koşuluyla roller oluşturabilir. Sınırlar, yalnızca halihazırda iam:PutRolePermissionsBoundary iznine sahip olan principal’lar tarafından eklenebilir; bu hakkı sıkı bir şekilde koruyun.

SCP’ler, kuruluş çapında koruma raylarıdır. Yaygın koruma rayları arasında AWS Config veya CloudTrail’in devre dışı bırakılmasını yasaklamak, Kuruluş dışından davetleri engellemek, IAM Identity Center’ın yetkilendirilmiş yöneticisine yönelik değişiklikleri reddetmek ve Region’ları kısıtlamak yer alır. Sürtünmeyi en aza indirmek için, koşullarla birlikte istisna ile açıkça izin verme kalıplarını (örneğin, merkezi bir yönetici rolü tarafından yapılan değişikliklere izin vermek) tercih edin. Her zaman gerekli hizmete bağlı rollerin (örneğin, GuardDuty, Inspector, Config için) oluşturulmasına ve kullanılmasına izin verin, aksi takdirde SCP’leriniz yanlışlıkla hizmet kurulumlarını engeller.

AWS Organizations, ortamları (örneğin, Sandbox, Dev, Prod), iş yükü türlerini ve istisna yollarını ayırmak için hiyerarşik OU’lar sağlar. Politika sapmasını önlemek için SCP’leri üst OU’lardan devralın. Hesap kurulumunu standartlaştırmak için hesap sağlama (account vending) kullanın: CI/CD’ye entegre etmek için AWS Control Tower’ın Account Factory’sini (konsol) veya Account Factory for Terraform’u (AFT) kullanın. AFT, GitOps tarzı iş akışları, sapma tespiti ve özellik bayrakları (örneğin, Enterprise Support sağlama) ekler ve yüzlerce hesaba tutarlı temel koruma rayları ile ölçeklenir.

AWS Control Tower, kuralcı koruma rayları ile bir landing zone’u otomatikleştirir. Önleyici koruma rayları, Control Tower’ın yönettiği SCP’lerdir; tespit edici koruma rayları ise dağıttığı AWS Config kurallarıdır. Control Tower, SSO ve izin kümeleri için IAM Identity Center’ı entegre eder. Eylemlerin kapsamını aws:PrincipalTag veya kimlik niteliklerine göre belirlemek için erişim kontrolü amacıyla niteliklere sahip ABAC tabanlı izin kümeleri kullanın. CloudFormation, SCP’ler ve Config paketlerini OU/hesap başına otomatik olarak dağıtmak için temel yapıyı Customizations for AWS Control Tower (CfCT) ile genişletin. Küresel koruma raylarını zayıflatmadan özel hazırlanmış politikalara ihtiyaç duyan iş yüklerini barındırmak için istisna OU’larını tutun.

Sürekli Uyumluluk ve Otomatik İyileştirme

AWS Config’i yetkilendirilmiş bir yönetici hesabından kuruluş çapında etkinleştirin. Tüm Region’lardaki tüm kaynaklar için kaydı açın ve bir kuruluş toplayıcısı ile Kuruluş genelindeki yapılandırmayı toplayın. Yaygın kontroller (örneğin, ebs-encryption-by-default, restricted-ssh, s3-bucket-level-public-access-prohibited) için yönetilen kuralları kullanın ve özel mantık (örneğin, KMS rotasyon sıklığını 90 günlük bir politikaya göre doğrulamak veya varsayılan etiketleri ve değerleri zorunlu kılmak) için özel Lambda destekli kurallar yazın. Uygunluk paketleri (Conformance packs), kuralları, parametreleri ve iyileştirmeyi OU başına sürümlenmiş, dağıtılabilir paketler halinde gruplandırır; tutarlılık ve denetlenebilirlik için bunları sürüm kontrolünde tutun ve StackSets veya CfCT aracılığıyla dağıtın.

Otomatik iyileştirme döngüyü tamamlar. Her kuralın uyumsuz değerlendirmesini, temel yapıyı zorunlu kılan bir SSM Automation runbook’una eşleyin: varsayılan bir instance profili ekleyin, varsayılan bir değere sahip bir etiket uygulayın, S3 Genel Erişimi Engelle’yi açıp kapatın veya bakım için bir EC2 instance’ını yeniden başlatın. Runbook’ları genel tutmak için parametreli dokümanlar ve dinamik girdi (örneğin, Config bulgusundan gelen) kullanın. Yüksek riskli kaynaklar için iyileştirmeyi otomatik olarak yürütülecek şekilde yapılandırın; hassas eylemler için EventBridge ve ChatOps aracılığıyla bir değişiklik onayı veya manuel tetikleme gerektirin. Kaydediciyi durdurmayı veya teslimat kanallarını silmeyi merkezi bir yönetici dışında reddeden SCP’lerle Config’in kendisini koruyun.

Firewall Manager, Kuruluşları kullanarak hesaplar arasında hizmet olarak politika (policy-as-a-service) için bu katmanı tamamlar. Merkezi bir yönetici atayın ve internete açık ALB’ler/API Gateway üzerindeki WAF web ACL ilişkilendirmeleri, VPC güvenlik grubu denetimi ve temizliği veya DNS Firewall kuralı yayılımı için politikalar yazın. Bu, gelecekteki zorlamayı tespit/iyileştirmeden önlemeye kaydırır.

Tehdit Tespiti, Gizli Bilgi Hijyeni ve Güvenlik Açığı Yönetimi

Security Hub, hesaplar ve Bölgeler (Region) arasındaki bulgular için merkezi bir tek birleşik görünüm (central pane of glass) görevi görür. Yetkilendirilmiş bir yönetici (delegated admin) ile etkinleştirin, bulguları birleştirin ve ilgili standartları (AWS Foundational Security Best Practices, CIS, geçerli olduğu yerlerde PCI DSS) etkinleştirin. Bulgular, AWS Security Finding Format’ına (ASFF) akar ve GuardDuty, Inspector, IAM Access Analyzer, Config, Macie ve iş ortağı araçlarından gelen girdileri normalleştirir. Kritik bulguları düzeltme otomasyonlarına (SSM Automation, Lambda) ve bildirimlere (SNS, sohbet) yönlendirmek için EventBridge desenlerini (pattern) yapılandırın.

GuardDuty, veri düzlemi (data-plane) log işlem hatlarını (pipeline) yönetmenizi gerektirmeden yönetilen tehdit tespiti sağlar. Anormal davranışları, kimlik bilgisi sızdırmayı, kripto para madenciliğini, DNS üzerinden veri sızdırmayı ve daha fazlasını tespit etmek için CloudTrail yönetim ve veri olaylarını, VPC Akış Günlüklerini (VPC Flow Logs), Route 53 Resolver DNS sorgu günlüklerini ve EKS denetim günlüklerini analiz eder. Şüpheli etkinliklerde S3 ve EC2/EBS taraması için Kötü Amaçlı Yazılımdan Koruma’yı (Malware Protection) etkinleştirin. Eyleme geçirilebilirliğe odaklanmak için kuruluş genelinde otomatik etkinleştirmeyi kullanın ve bastırma kurallarıyla (suppression rules) düşük sinyalli bulguları sistematik olarak arşivleyin.

Amazon Inspector, paket CVE’leri için EC2’yi (SSM agent aracılığıyla), dağıtım öncesi güvenlik açıkları için ECR container imajlarını ve kod paketi CVE’leri için Lambda fonksiyonlarını sürekli olarak değerlendirir. Inspector, EC2 örneklerinde SSM Agent’ın kurulu olmasını, örnek profilinin (instance profile) SSM izinlerine sahip olmasını ve (internet kısıtlıysa VPC uç noktaları aracılığıyla) SSM/KMS uç noktalarına (endpoint) giden trafiğe (egress) izin verilmesini gerektirir. Bulguları Security Hub’a göndermek ve Systems Manager Patch Manager veya runbook tabanlı düzeltme ile yama iş akışlarını tetiklemek için Inspector’ı yapılandırın. Hangi kaynakların tarama kapsamında olacağını belirlemek ve sandbox ortamlarını düzenlemeye tabi (regulated) iş yüklerinden ayırmak için etiketleri (tag) kullanın.

Secrets Manager, güçlü denetlenebilirlik ile gizli bilgilerin depolanmasını, rotasyonunu ve hesaplar arası erişimini merkezileştirir. Rotasyon gerektiren kimlik bilgileri için parametre depoları yerine Secrets Manager’ı tercih edin; RDS/Aurora için yerleşik rotasyonu veya harici sistemler için Lambda tabanlı rotasyonu kullanın. Hazırlık etiketleri (staging labels) (AWSCURRENT, AWSPREVIOUS), sıfır kesintiyle (zero-downtime) rotasyona olanak tanır. Rotasyon Lambda’larını gerekli uç noktalara (Secrets Manager, RDS, KMS) sahip VPC’lerde çalıştırın ve giden trafiği (egress) kısıtlayın. Hesaplar arası kullanım için, diğer hesaplardaki kimliklere (principal) GetSecretValue izni veren kaynak tabanlı bir ilke (policy) ekleyin; gizli bilginin CMK’sı için KMS anahtar ilkesinin, tüketen kimliklerin şifreyi çözmesine ve gerekirse grant oluşturmasına izin verdiğinden emin olun. Felaket kurtarma (disaster recovery) veya yerellik kontrolleri için gizli bilgileri Bölgeler (Region) arasında çoğaltın (replicate) ve rotasyon pencerelerini hizalayın.

Veri Koruma ve Ağ Güvenliği

Açık anahtar politikalarıyla KMS kullanarak şifreleme tasarlayın. Bir CMK üzerindeki kriptografik işlemler için sorumluları (principal) nihai olarak yetkilendiren, yalnızca IAM politikaları değil, anahtar politikalarıdır. En az ayrıcalık ilkesine dayalı, rol tabanlı bir anahtar politikası modeli benimseyin: yönetimi merkezi bir KMS yönetici rolüne devredin; kullanım haklarını dar bir kapsamda iş yükü rollerine verin; yanlışlıkla yetki yükseltmeyi önlemek için joker karakterli kms:* kullanımına izin vermeyin. Şifre çözme işlemini beklenen bağlamlara bağlamak için koşul anahtarlarını (kms:EncryptionContext:*) kullanın. Çok Bölgeli (Multi-Region) anahtarlar, verilerin Bölgeler arası çoğaltıldığı aktif-aktif şifrelemeyi mümkün kılar.

Grant’ler, anahtar politikasını düzenlemeden geçici veya dar kapsamlı anahtar kullanımını devretmek için doğru araçtır ve bazı hizmet akışları için gereklidirler (örneğin, şifreli başlatma şablonları kullanan EC2 Auto Scaling, hesaplar arası AMI kullanımı). Başka bir hesabın grant oluşturmasına izin vermek için, anahtar politikası o hesabın sorumlularına kms:CreateGrant izni vermelidir; grant alan taraf (grantee), aynı çağrı yolunda anında kullanım için bir grant token’ı sağlamalıdır. Hesaplar arası şifreli AMI’ler için, AMI’yi bir CMK ile kopyalayıp şifreleyin, AMI’yi paylaşın, hedef hesabın CMK üzerinde grant oluşturmasına izin verin ve hedef hizmet bağlantılı rolün (service-linked role) bir grant almasını sağlayın.

Zarf şifrelemesi (envelope encryption) varsayılan modeldir: KMS ile bir veri anahtarı oluşturun, veriyi yerel olarak düz metin (plaintext) veri anahtarıyla şifreleyin, ardından yalnızca şifreli metni (ciphertext) ve şifrelenmiş veri anahtarını saklayın. Okuma sırasında, düz metin veri anahtarını belleğe geri yüklemek için KMS Decrypt’i çağırın. Bu, büyük yükler için KMS çağrılarını en aza indirir ve düz metin anahtarının açığa çıkmasını sınırlar. Desteklendiği yerlerde, operasyonel basitlik için hizmet tarafından yönetilen SSE-KMS’i (S3, EBS, RDS) kullanın, ancak yine de hesaplar arası üreticiler/tüketiciler için anahtar politikalarını uyumlu hale getirin.

VPC güvenliği, en az ayrıcalık ilkesine sahip güvenlik gruplarıyla (security groups) başlar. Güvenlik grupları durum bilgisi tutar (stateful); dönüş trafiğine zımnen izin verilir. Kırılgan IP izin listelerinden kaçınmak ve altyapı kodundaki amacı korumak için CIDR tabanlı kurallar yerine güvenlik grubu referanslarını tercih edin. Varsayılan giden (outbound) izinler risklidir; dışa çıkış (egress) trafiğini yalnızca gerekli hedeflerle açıkça kısıtlayın ve AWS hizmet erişimi için VPC endpoint’lerini kullanın. NACL’ler durum bilgisi tutmaz (stateless) ve ilk olarak değerlendirilir; bunları yalnızca ek bir sınır uygulamanız veya yasal gereklilikleri karşılamanız gerektiğinde geçici (ephemeral) portlar için açık dönüş kuralları olan kaba, alt ağ düzeyinde kontroller olarak tutun; aksi takdirde, yönetilebilirlik için güvenlik gruplarını tercih edin.

VPC endpoint’lerini kullanarak internet bağımlılıklarını ortadan kaldırın. Gateway endpoint’leri (S3, DynamoDB) trafiği özel olarak AWS ağı üzerinden yönlendirir; erişilebilir bucket’ları veya tabloları kısıtlamak için bir endpoint politikası ilişkilendirin. Interface endpoint’leri (AWS PrivateLink), AWS hizmetlerini (Secrets Manager, KMS, SSM, ECR, CloudWatch) özel IP’ler aracılığıyla kullanıma sunar; bunları doğru güvenlik gruplarına sahip alt ağlarda dağıtın ve standart hizmet adlarının özel adreslere çözümlenmesi için Private DNS’i etkinleştirin. Hesaplar/VPC’ler arası üretici-tüketici mikroservisleri için, NLB destekli bir endpoint hizmeti yayınlayın ve tüketicilerin PrivateLink aracılığıyla bu hizmete interface endpoint’leri oluşturmasını sağlayın; böylece peering veya transit gateway’lerden kaçınılır ve trafik genel internetten uzak tutulur. Bu kontrolleri, NAT’sız, IGW’siz alt ağlar ve internet erişiminin gerekli olduğu durumlarda merkezi dışa çıkış (egress) denetimi ile birleştirin.

Pratik Problem Senaryosu

Expedia Group, birden fazla Bölge’de yüzlerce AWS hesabına genişliyor ve katı bir güvenlik temeli (baseline) uygulamak zorunda: iş yükleri için internete çıkış olmaması, yanlış yapılandırmaların otomatik olarak düzeltilmesi, merkezi tehdit tespiti, gizli bilgilerin (secrets) rotasyonu ve standartlaştırılmış “golden image"lar için şifreli AMI’lerin kontrollü hesaplar arası paylaşımı.

AWS Organizations ve AWS Control Tower ile çoklu hesap yönetişimi kurun

Eylem: Sandbox, Dev, Prod ve Security için OU’lar (Organizational Units) oluşturun. Landing zone’u kurmak, zorunlu koruma raylarını (guardrails) etkinleştirmek ve IAM Identity Center’ı entegre etmek için Control Tower’ı dağıtın. GitOps aracılığıyla hesapları sağlamak için Account Factory for Terraform (AFT) kullanın.
Neden: Control Tower, anahtar teslimi, sürekli olarak uygulanan koruma rayları (SCP’ler ve Config kuralları) sağlar. AFT, büyük ölçekte hesap tedarikini standartlaştırır ve temelleri (baseline) sürüm kontrolünde kodlaştırır.

İstisnalarla birlikte küresel koruma raylarını uygulamak için SCP’ler yazın

Eylem: CloudTrail ve AWS Config’in devre dışı bırakılmasını reddeden, Bölgeleri kısıtlayan ve genel S3 ACL’lerini önleyen SCP’ler ekleyin. Security OU’sundaki bir güvenlik yöneticisi (security-admin) rolü için koşul tabanlı istisnalar ekleyin. Gerekli hizmet bağlantılı rollerin (service-linked roles) oluşturulmasına/kullanılmasına izin verin.
Neden: SCP’ler, root dahil tüm sorumluların (principal) ayrıcalıklarını sınırlar, böylece merkezi operasyonlar için kontrollü istisnalara izin verirken yapılandırma sapmasını (drift) önler.

Otomatik düzeltme ile Config uygunluk paketlerini (conformance packs) dağıtın

Eylem: Security yetkilendirilmiş yönetici (delegated admin) hesabından, AWS Config’i kuruluş genelinde etkinleştirin ve bir toplayıcı (aggregator) oluşturun. Varsayılan olarak EBS şifrelemesini, kısıtlı SSH’ı, varsayılan değerlere sahip zorunlu etiketleri ve genel giriş noktalarında zorunlu WAF’ı uygulayan bir uygunluk paketi (conformance pack) dağıtın. Her kuralı otomatik düzeltmeler için SSM Automation belgeleriyle eşleştirin (örneğin, varsayılan instance profile’ı ekle, eksik etiketleri haftalık olarak ayarla).
Neden: Uygunluk paketleri, ortamları sürekli bilet (ticket) oluşturma karmaşası olmadan uyumlu bir durumda tutan otomatik düzeltme özelliğiyle birlikte, tutarlı, denetlenebilir kod olarak politika (policy-as-code) sunar.

Security Hub, GuardDuty ve Inspector ile tespiti merkezileştirin

Eylem: Yetkilendirilmiş bir yönetici (delegated admin) ile GuardDuty ve Inspector’ı kuruluş genelinde etkinleştirin. Security Hub standartlarını (AWS FSBP ve CIS) etkinleştirin ve bulguları toplayın (aggregate). Yüksek önem dereceli bulguları SSM Automation runbook’larına ve nöbetçi (on-call) ekip için bir SNS konusuna (topic) yönlendirmek üzere EventBridge kuralları oluşturun.
Neden: Yönetilen tespit ve güvenlik açığı değerlendirmesi, minimum operasyonel yük ile sürekli kapsama sağlar ve Security Hub, daha hızlı triyaj ve müdahale için sinyalleri birleştirir.

İzin sınırları (permission boundaries) ve ABAC ile en az ayrıcalık ilkesine sahip IAM’i uygulayın

Eylem: AFT ile sağlanan hesaplarda, geliştirici tarafından oluşturulan rollerin, özel olarak seçilmiş roller (curated roles) dışında iam:PassRole iznini reddeden ve yüksek etkili API’leri sınırlayan bir izin sınırı (permission boundary) eklemesini zorunlu kılın. Eylemleri ekip etiketlerine göre kapsamlandırmak için ABAC ile IAM Identity Center izin setlerini (permission sets) kullanın.
Neden: İzin sınırları, yetki yükseltmeyi önlerken güvenli self-servis imkanı tanır; ABAC, politika karmaşasını (sprawl) azaltır ve kimlik nitelikleriyle uyumlu kalır.

VPC endpoint’leri ve PrivateLink ile ağ yollarını güçlendirin

Eylem: Uygulama alt ağlarından IGW’leri/NAT’ları kaldırın. Kısıtlayıcı endpoint politikalarıyla KMS, Secrets Manager, SSM, ECR, CloudWatch için interface endpoint’leri ve S3/DynamoDB için gateway endpoint’leri oluşturun. Hesaplar arası tüketim için dahili platform hizmetlerini PrivateLink destekli NLB’ler aracılığıyla yayınlayın.
Neden: Özel bağlantı, internete maruz kalmayı ortadan kaldırır ve hizmetlerin kilitli ortamlarda erişilebilir kalmasını sağlar.

Hesaplar arası AMI’ler için grant’leri içeren bir KMS anahtar stratejisi uygulayın

Eylem: Her ortam için rol kapsamlı anahtar politikalarına sahip CMK’ler oluşturun. İmaj oluşturma hesabında, golden AMI’leri şifreleyin ve paylaşın. Hedef hesapların grant oluşturmasına izin vermek için CMK politikasını güncelleyin, ardından bu hedef hesaplardaki hizmet bağlantılı rollere (service-linked roles) grant’ler oluşturun.
Neden: Grant’ler, her tüketici için anahtar politikalarını düzenlemeden kapsamlı, denetlenebilir bir yetki devri sağlar ve Auto Scaling’in hesaplar arasında şifreli AMI’lerden örnek başlatmasını mümkün kılar.

Gizli bilgilerin (secrets) rotasyonunu ve hesaplar arası erişimi standartlaştırın

Eylem: Veritabanı ve API kimlik bilgilerini Secrets Manager’da saklayın. RDS olmayan hedefler için Lambda rotasyonunu uygulayın ve RDS için yerleşik rotasyonu etkinleştirin. Paylaşılan platform gizli bilgileri için, diğer hesaplardaki tüketici rollerine GetSecretValue izni veren kaynak tabanlı politikalar ekleyin ve CMK politikalarının şifre çözmeye (decrypt) izin verdiğinden emin olun. Rotasyon Lambda’larını gerekli endpoint’lere sahip VPC’lere yerleştirin.
Neden: Otomatik rotasyon, kimlik bilgisi riskini azaltır; KMS uyumlu kaynak politikaları, en az ayrıcalık ilkesini ve denetim izlerini korurken güvenli hesaplar arası tüketimi mümkün kılar.

Bu mimari, Expedia Group’a uygulanabilir koruma rayları, kanıtlanabilir uyumluluk, otomatik düzeltmeler ve sıkı bir şekilde kontrol edilen veri erişim yolları sunarken, aynı zamanda güvenli self-servis ve özel bağlantı yoluyla geliştirici hızını korur.

← İzleme · Tüm alanlar · Konteynerler ve Sunucusuz Operasyonlar →

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