Amazon DVA-C02: Güvenlik, IAM, KMS ve Sır Yönetimi (Cognito, Secrets Manager, SSM) — Çalışma kılavuzu

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS Developer Associate DVA-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.

IAM, Roller, İlkeler ve Hesaplar Arası Erişim

Kimlik ve erişim yönetimi, en az ayrıcalık ilkesi, kısa ömürlü kimlik bilgileri ve servis ile insan kimlikleri arasında net bir ayrım etrafında tasarlanmalıdır. EC2, ECS veya Lambda üzerinde çalışan uygulamalar için erişim anahtarlarını (access key) gömmek yerine instance/task/function rollerini tercih edin; AWS SDK’ları, ortam tarafından sağlanan kimlik bilgisi sağlayıcı zincirini (credential provider chain) otomatik olarak kullanır ve geçici kimlik bilgilerini yeniler. Hesaplar arası erişim, hedef hesapta açık bir rol güven ilkesi (role trust policy) ve çağıran hesapta hangi rol ARN’lerinin üstlenilebileceğini sınırlayan bir IAM ilkesi ile AWS STS AssumeRole (API: sts:AssumeRole) kullanmalıdır. Hassas operasyonlar için MFA gerektiğinde, bunu rol veya kaynak ilkesinde aws:MultiFactorAuthPresent koşulunu kullanarak zorunlu kılın veya insan kullanıcılar için sts:GetSessionToken’ı şart koşun. Web veya mobil istemciler için, uzun ömürlü kimlik bilgilerinden kaçınmak amacıyla Cognito Identity veya federe sağlayıcılar aracılığıyla AssumeRoleWithWebIdentity (sts:AssumeRoleWithWebIdentity) kullanın. Yaygın tuzaklara dikkat edin: aşırı izin veren joker (wildcard) eylemler/kaynaklar, eşleşen principal koşulları olmadan kaynak tabanlı ilkelere güvenmek ve hesaplar arası S3 veya KMS erişimi için SourceAccount veya aws:SourceVpc koşullarını eklemeyi unutmak. Hata ayıklamak için IAM policy simulator ve sts:GetCallerIdentity kullanın. Organizasyon seviyesinde koruma mekanizmaları (guardrail’ler) uygulamak ve uygun yerlerde kms:CreateGrant veya iam:CreateAccessKey gibi riskli eylemler için açıkça reddetme (explicit deny) kuralı koymak için hizmet kontrol ilkelerini (SCP’ler) kullanmayı düşünün.

KMS, Şifreleme Desenleri ve Anahtar Erişim Kontrolü

Zarf şifrelemesi (envelope encryption) için AWS KMS kullanın: İstemci taraflı veya sunucu taraflı şifreleme için bir veri anahtarı (data key) üretmek üzere GenerateDataKey/GenerateDataKeyWithoutPlaintext kullanın, ardından küçük boyutlu veriler (payload) için Encrypt/Decrypt çağırın veya toplu şifreleme için veri anahtarını kullanın. Doğru CMK’yı seçin: Kolaylık için AWS’in sahibi olduğu (AWS owned), servis entegrasyonu için AWS tarafından yönetilen (AWS managed - aws/*) veya tam kontrol ve rotasyon için müşteri tarafından yönetilen (customer-managed). Anahtar ilkeleri (Key policy’ler), KMS için birincil kontrol mekanizmasıdır; kms:Decrypt, kms:Encrypt izinlerini veren IAM ilkeleri ekleyin ve CloudHSM destekli operasyonlar veya hesaplar arası Lambda çağrımı gibi hizmetler için geçici, delege edilmiş anahtar kullanımına ihtiyaç duyduğunuzda grant’leri kullanın. Şifreli metni kullanım bağlamına bağlamak için bir EncryptionContext ekleyin ve daha yüksek güvence için bunu bir kms:EncryptionContextEquals koşulu aracılığıyla zorunlu kılın. Hesaplar arası KMS kullanımı, harici principal veya role izin veren açık anahtar ilkesi (key policy) girişleri ve bazı durumlarda CreateGrant/RetireGrant izinleri gerektirir. Denetim ve adli analiz için, GenerateDataKey ve Decrypt çağrılarını yakalamak üzere KMS ve S3 için CloudTrail veri olaylarını (data events) etkinleştirin; CloudTrail logları arn:aws:kms’i ve anahtarı hangi principal’ın kullandığına dair ayrıntıları içerecektir. Sık yapılan hatalar arasında, arka planda grant’leri kullanan hizmetler için kms:CreateGrant iznini vermeyi unutmak, müşteri tarafından yönetilen anahtarları (customer-managed key) rote etmemek ve uygun anahtar ilkesi (key policy) girişleri olmadan yalnızca IAM ilkelerinin KMS operasyonlarına yetki verebileceğini varsaymak yer alır.

Gizli Bilgi Yönetimi: Secrets Manager vs Parameter Store

Secrets Manager ve Systems Manager Parameter Store, her ikisi de şifreli gizli bilgi depolama sağlar ancak özellikler ve maliyet profili açısından farklılık gösterir: Secrets Manager otomatik rotasyonu (Lambda rotasyon şablonları ile), dahili sürüm oluşturmayı ve entegre replikasyonu destekler ve gizli bilgi başına ücretlendirilir; Parameter Store (SecureString) ise birçok parametre için ücretsiz kullanım katmanındadır (free-tier) ve basit yapılandırmalar için daha iyidir. Erişim, secretsmanager:GetSecretValue veya WithDecryption=true ile ssm:GetParameter izni veren IAM ilkeleriyle kontrol edilir ve altında yatan KMS anahtarı, principal için şifre çözmeye (decrypt) izin vermelidir. Hesaplar arası gizli bilgiler için Secrets Manager üzerinde kaynak tabanlı ilkeler kullanın veya gizli bilgi replikasyonu ile replikasyon yapın. SDK’ları kullanırken,

undefined

veya

undefined

çağırın ve gizli bilgi değerlerini loglamaktan kaçının; CloudFormation veya SAM’de dinamik çözümleme ile Secrets Manager veya Parameter Store’a referanslar kullanmak için Lambda ortam değişkenlerini ayarlayın veya başlangıçta SDK ile çekme (fetch) yöntemini kullanın. Yaygın geliştirici hataları arasında, gizli bilgileri kaynak kontrolünde düz metin (plaintext) olarak saklamak, çok hassas veriler için KMS koruması olmadan Lambda ortam değişkenlerine güvenmek ve geniş kapsamlı rollere secretsmanager:* gibi aşırı izin veren IAM ilkeleri atamak yer alır. Rotasyon için, rotasyonu yapan Lambda’nın doğru secretsmanager:RotateSecret ve kms:GenerateDataKey izinlerine sahip olduğundan ve kimlik bilgileri değiştiğinde uygulama kodunun bağlantıları sorunsuz bir şekilde yeniden başlatabildiğinden emin olun.

Cognito Kimlik Doğrulama, Yetkilendirme ve API Entegrasyonu

Amazon Cognito, kimlik doğrulama için kullanıcı havuzları (user pools) ve geçici AWS kimlik bilgileri için kimlik havuzları (identity pools) sağlar. Kayıt olma, çok faktörlü kimlik doğrulama ve JWT (ID, erişim, yenileme token’ları) düzenleme işlemlerini yönetmek için Cognito User Pools’u kullanın. Tarayıcı tabanlı tek sayfa uygulamaları, client secret olmadan uygulama istemcileri (app clients) kullanmalı ve parolaların açığa çıkmasını önlemek için SRP akışını uygulayan barındırılan arayüzü (hosted UI) veya Amazon Cognito SDK’sını (amazon-cognito-identity-js) kullanmalıdır. Sunucuda veya API Gateway’de JWT’leri, kullanıcı havuzundan JWKS URI’sini alarak ve imza, düzenleyici (issuer), hedef kitle (aud) ve token geçerlilik süresini doğrulayarak kontrol edin; API Gateway JWT yetkilendiricileri veya Lambda özel yetkilendiricileri (custom authorizers) bu doğrulamayı yapabilir. Sunucudan sunucuya kimlik doğrulama için, kullanıcı havuzu token’ını sts:AssumeRoleWithWebIdentity ile Cognito Identity Pool aracılığıyla geçici kimlik bilgileriyle değiştirin. Sık yapılan hatalar arasında yanlış yapılandırılmış geri arama (callback) veya oturum kapatma (sign-out) URL’leri, token kapsamlarının (scopes) veya gruplarının doğrulanmaması ve ID token’larının doğrudan AWS API çağrıları için kullanılabileceğini varsaymak (bunları kimlik havuzu aracılığıyla değiştirmeniz gerekir) yer alır. Detaylı yetkilendirme için grupları veya özel talepleri (custom claims) kullanın ve kimliği AWS rollerine eşlerken Cognito’yu kaynak tabanlı politikalar (resource-based policies) ve aws:userid veya cognito-identity.amazonaws.com:sub gibi IAM koşul anahtarlarıyla (condition keys) birleştirin. Oturum açma ve yönetici eylemlerini CloudTrail aracılığıyla denetleyin ve ele geçirilmiş kimlik bilgilerinin tespiti için Cognito’daki gelişmiş güvenlik özelliklerini etkinleştirin.

Pratik Problem: Kullanım Senaryosu

Senaryo: Bir oyun stüdyosu olan PixelForge, tek bir AWS hesabında Lambda, API Gateway, S3, DynamoDB ve Cognito kullanıcı havuzları ile sunucusuz bir arka uç (backend) çalıştırmaktadır. Hassas API anahtarları ve veritabanı kimlik bilgileri birden fazla dağıtım aşaması (deployment stage) için saklanmaktadır ve üçüncü taraf bir denetim ekibinin 1-24 saatliğine S3’teki üretim (production) imajlarının alt kümelerine erişmesi gerekmektedir.

Zorluk: Harici denetçilere üretim imajlarına güvenli, kısa ömürlü ve denetlenebilir erişim sağlamak, uygulama sırlarının (secrets) Lambda tarafından güvenli bir şekilde döndürülmesini ve erişilmesini sağlamak ve yönetici (admin) hesaplar arası erişim için MFA’yı zorunlu kılmak.

Önerilen Yaklaşım:

1. PixelForge hesabı için şifre çözmeye (decrypt) izin veren bir anahtar politikası (key policy) ve denetçi IAM rolü için yetkiler (grants) içeren müşteri tarafından yönetilen bir KMS anahtarı (customer-managed KMS key) oluşturun; anahtar rotasyonunu etkinleştirin ve şifre çözme işlemleri sırasında EncryptionContext kullanılmasını zorunlu kılın.
2. Kimlik bilgilerini Secrets Manager’da saklayın (her aşama için ayrı sırlar) ve Lambda’lara minimum secretsmanager:GetSecretValue izni ve KMS anahtarı için kms:Decrypt izni olan bir IAM rolü ekleyin; AWS SDK kullanarak secretsmanager.getSecretValue({ SecretId }) çağrısı yapan Lambda başlangıç kodunu uygulayın.
3. Denetçi erişimi için ayrı bir denetçi AWS hesabı rolü oluşturun ve kaynak tabanlı bir S3 bucket politikasında (resource-based S3 bucket policy) denetçi hesabından sts:AssumeRole‘e izin verin; bu izni aws:PrincipalArn ve zaman sınırlı, önceden yapılandırılmış bir rol eşlemesi ile kısıtlayın; sts:AssumeRole aracılığıyla kısa ömürlü kimlik bilgileri oluşturun ve rolü üstlenirken aws:MultiFactorAuthPresent koşulu ile MFA’yı zorunlu kılın.
4. Tüm erişimi CloudTrail ile (S3 ve KMS için yönetim ve veri olayları) kaydedin ve ek adli analiz (forensics) için S3 nesne düzeyinde günlük kaydını (object-level logging) ve Amazon Macie veya S3 Erişim Günlüklerini (S3 Access Logs) etkinleştirin; geçici denetçi oturumlarının belirli bir EncryptionContext kullanmasını ve izlenebilirlik için nesneleri/istekleri etiketlemesini zorunlu kılın.

Gerekçe: Secrets Manager’ı KMS ve kısa ömürlü STS kimlik bilgileriyle kullanmak, en az ayrıcalık ilkesini (least privilege) uygular, otomatik rotasyonu mümkün kılar ve sırların koda gömülmesini önler. MFA ve CloudTrail veri olayları (data events) ile birlikte zaman sınırlı assume-role kalıpları, görevler ayrılığını (separation of duties) korurken üçüncü taraflar için denetlenebilir ve iptal edilebilir erişim sağlar.

← Dağıtım ve CI · Tüm alanlar · İzleme →

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

Amazon'a göz atın →