Amazon SCS-C02: Şifreleme, KMS ve Sırlar — Ç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.

AWS KMS Anahtar Türleri, Politikaları ve Erişim Kontrolü

AWS KMS, üç ana anahtar kategorisini destekler ve doğru olanı seçmek, anahtar materyalini kimin kontrol ettiğini, nerede bulunduğunu ve nasıl rotate edilebileceğini belirler. AWS’in sahip olduğu anahtarlar sizin için görünmezdir, maliyeti yoktur ve SSE-S3’ü etkinleştirdiğinizde S3 gibi servisler tarafından kullanılır. AWS tarafından yönetilen anahtarlar (aws/<service> alias’ına sahiptir), bir servisin sizin adınıza şifreleme yapmasına olanak tanır, ancak anahtar politikasını değiştiremezsiniz; bu nedenle hesaplar arası erişim veya ayrıntılı yönetişim için uygun değildirler. Müşteri tarafından yönetilen anahtarlar (CMK’lar) bu işin temel aracıdır: anahtar politikasını, rotasyonu (yıllık otomatik veya isteğe bağlı), grant’leri, alias’ları ve silme penceresini siz kontrol edersiniz.

İki özel varyant önemlidir. İçe aktarılan anahtar materyali, yasal düzenlemeler veya BYOK gereksinimleri sizi anahtar materyalini AWS dışında oluşturup bir KMS anahtarına içe aktarmaya zorladığında kullanılır. İçe aktarılan materyal, anahtar materyali için açık bir son kullanma tarihi yapılandırmanın tek yoludur—AWS tarafından oluşturulan CMK’ların süresi asla dolmaz. İçe aktarılan anahtarlarda AWS’in yıllık otomatik rotasyonunu etkinleştiremezsiniz; materyali kendiniz yeniden içe aktarmanız gerekir. Çok Bölgeli anahtarlar, replika anahtarlar aracılığıyla Bölgeler arasında aynı anahtar kimliğini ve materyalini paylaşır, böylece us-east-1‘de üretilen bir şifreli metin, us-west-1‘de yeniden şifrelemeye gerek kalmadan çözülebilir. Her replikanın kendi bağımsız anahtar politikası ve alias’ları vardır, ancak kriptografik materyal senkronize edilir.

En çok yanlış anlaşılan tek kontrol KMS anahtar politikasıdır. Yalnızca IAM politikalarının erişim sağladığı çoğu AWS kaynağının aksine, KMS anahtarları kendi anahtar politikalarını kök yetkilendirme olarak kullanır. Bir anahtar üzerinde kms:Decrypt izni veren bir IAM politikası, anahtar politikası da IAM’e erişim yetkisi devretmedikçe (hesap kökünün bir Principal‘ı ve uygun bir ifade aracılığıyla veya principal’ı doğrudan adlandırarak) etkisizdir. Bu nedenle, AdministratorAccess yetkisine sahip bir mühendis, politikası hesaba güvenmeyen bir CMK üzerinde Decrypt çağrısı yaptığında hala AccessDenied hatası alabilir. Standart yetki devri ifadesi şöyledir:

{
  "Sid": "EnableIAMPermissions",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Grant’ler ve ViaService koşulları, katmanlı kısıtlamalar ekler—örneğin, bir anahtarın yalnızca belirli bir Bölgedeki S3 aracılığıyla kms:ViaService: s3.us-east-1.amazonaws.com ile kullanılmasını zorlamak gibi.

Sunucu Tarafı ve İstemci Tarafı Şifreleme

S3 için, yaygın olan iki sunucu tarafı seçeneği temel olarak kontrol ve denetlenebilirlik açısından farklılık gösterir:

• SSE-S3 (AES-256): S3 anahtarları tamamen yönetir; müşterinin görebileceği bir anahtar politikası, anahtar başına CloudTrail şifre çözme olayları ve hesaplar arası yönetişim yoktur. Bekleme durumunda temel düzeyde şifreleme için yeterlidir, ancak uyumluluğun veriyi kimin çözdüğünün kanıtlanmasını gerektirdiği durumlarda yetersizdir.
• SSE-KMS: Sizin kontrol ettiğiniz bir CMK kullanır; her şifre çözme çağrısı günlüğe kaydedilir, anahtar politikası erişimi zorunlu kılar ve şifreleme bağlamına göre kısıtlama yapabilirsiniz. İstek başına daha maliyetlidir ve KMS TPS kotalarını tüketir, bu nedenle KMS çağrılarını önemli ölçüde azaltmak için bucket anahtarları (BucketKeyEnabled: true) etkinleştirilmelidir.

AWS Encryption SDK kullanılarak yapılan istemci tarafı şifreleme, verilerin uygulamadan çıkmadan önce şifrelenmesi gerektiğinde veya depolama servisinin düz metni asla görmemesi gerektiğinde uygundur. Yüksek verimli iş yükleri, SDK’yı, yapılandırılabilir bayt, mesaj ve TTL limitleri dahilinde birçok mesaj arasında veri anahtarlarını yeniden kullanan önbelleğe alan kriptografik materyal yöneticisi (CachingCryptoMaterialsManager) ile sarmalıdır. Önbellekleme olmadan, her encrypt çağrısı bir GenerateDataKey isteğini tetikler, bu da KMS istek kotalarını hızla doldurur ve maliyeti artırır.

from aws_encryption_sdk import CachingCryptoMaterialsManager, LocalCryptoMaterialsCache
cache = LocalCryptoMaterialsCache(capacity=100)
ccmm = CachingCryptoMaterialsManager(
    master_key_provider=mkp, cache=cache,
    max_age=600.0, max_messages_encrypted=10000)

Secrets Manager ve Parameter Store

Secrets Manager, kimlik bilgilerini bir KMS CMK ile şifrelenmiş olarak saklar ve bir Lambda fonksiyonu aracılığıyla otomatik rotasyonu destekler—AWS, RDS, Redshift ve DocumentDB için şablonlar sunar ve özel Lambda’lar diğer her şeyi halleder. Rotasyon, yeni kimlik bilgilerini AWSCURRENT‘a yükseltmeden önce AWSPENDING etiketi altında hazırlayan dört adımlı bir durum makinesi (createSecret, setSecret, testSecret, finishSecret) çalıştırır. Uygulamalar, kimlik doğrulama hatalarını yakalamalı, secret’ı yenilemeli ve yeniden denemelidir—bu model, önceki kimlik bilgisi AWSPREVIOUS aracılığıyla kısa bir süre için geçerli kaldığından kesinti süresini ortadan kaldırır.

Rotasyon Lambda’sı bir VPC içinde çalıştığında (özel bir RDS örneğine ulaşmak için tipik bir durumdur), Secrets Manager servis uç noktasına giden ağ erişimine ihtiyaç duyar. NAT olmayan özel bir VPC’de, bir arayüz VPC uç noktası (com.amazonaws.<region>.secretsmanager) dağıtmalı ve Lambda’nın güvenlik grubunun uç noktaya 443 numaralı port üzerinden ulaşmasına izin vermelisiniz. Bunu unutmak klasik bir başarısızlık nedenidir: rotasyon yapılandırılmış gibi görünür ancak her çağrı zaman aşımına uğrar.

Bölgeler arası dayanıklılık için, çok Bölgeli bir KMS anahtarı ve Secrets Manager’ın replika-secret özelliğini kullanın. us-east-1‘deki birincil secret, birincil CMK ile şifrelenir; us-west-1‘deki replika, replika CMK’yı kullanarak şifreyi çözer. alias/prod-db gibi alias’lar, uygulama kodunu değiştirmeden hızlı anahtar rotasyonu için isteğe bağlı olarak yeni bir anahtar kimliğine yönlendirilebilir.

Parameter Store’un SecureString türü, rotasyona ihtiyaç duymadığınızda hafif bir alternatiftir. Her iki servis de CloudFormation’da dinamik referanslar ({{resolve:secretsmanager:MySecret:SecretString:password}}) sunar, böylece yığın şablonları asla düz metin içermez.

EBS, RDS, Aurora ve Snapshot Şifrelemesi

Bekleme durumunda şifreleme, oluşturma sırasında birim veya örnek başına etkinleştirilir ve yerinde değiştirilemez. Uyumsuz, şifrelenmemiş bir kaynak için düzeltme modeli, şifreleme ile bir snapshot kopyası oluşturmaktır:

aws ec2 copy-snapshot --source-snapshot-id snap-abc \
  --source-region us-east-1 --encrypted \
  --kms-key-id alias/prod-ebs
aws ec2 create-volume --snapshot-id snap-newEncrypted ...

RDS ve Aurora için, şifrelenmiş snapshot’ı yeni bir örneğe geri yükleyin ve geçiş yapın. Hesaplar arası kurtarma, snapshot’ı paylaşmayı ve anahtar politikası aracılığıyla hedef hesaba CMK üzerinde kms:CreateGrant ve kms:Decrypt izinlerini vermeyi gerektirir—sadece snapshot’ı paylaşmak başarısız olur çünkü hedef, veri anahtarının şifresini çözemez. Hesap düzeyinde varsayılan EBS şifrelemesi etkinleştirilmelidir, böylece yeni oluşturulan birimler, çağıranın davranışından bağımsız olarak her zaman şifrelenir.

TLS: ACM ve ALB Politikaları

ACM, entegre hizmetlere (ALB, CloudFront, API Gateway) bağlandığında genel sertifikaları ücretsiz olarak yayınlar ve otomatik olarak yeniler. Sertifikalar dışa aktarılamaz, bu nedenle EC2’de sonlandırılan TLS, ya ACM Private CA (dışa aktarabileceğiniz özel sertifikalar için) ya da içe aktarılmış bir sertifika gerektirir. Pragmatik bir yaklaşım: Genel TLS’i ALB’de bir ACM sertifikası ile sonlandırın ve uçtan uca şifreleme gerekiyorsa ALB’den EC2’ye olan bağlantı için kendinden imzalı veya özel CA sertifikası kullanın. TLS 1.0/1.1’i ve zayıf şifre paketlerini devre dışı bırakan ELBSecurityPolicy-TLS13-1-2-2021-06 gibi bir güvenlik politikasıyla istemcileri modern şifreleri kullanmaya zorlayın.

Sık Karşılaşılan Tuzaklar

Anahtar politikası olmayan IAM. Bir IAM politikasında kms:Decrypt izni verilirken CMK’nin anahtar politikasında hesap principal’ının atlanması AccessDenied hatasına neden olur. KMS, anahtar politikasını yetkili olarak kabul eder; IAM izinleri, anahtar politikasının izin verdiklerini yalnızca daha da kısıtlayabilir.

VPC endpoint’i olmayan rotasyon Lambda’sı. Lambda özel alt ağlarda çalışıyorsa ve VPC’de NAT ile secretsmanager arayüz endpoint’i yoksa, secretsmanager.<region>.amazonaws.com adresine yapılan rotasyon çağrısı çözümlenemez veya bağlanamaz. Endpoint üzerindeki güvenlik grubu ayrıca Lambda’nın SG’sinden gelen 443 portuna izin vermelidir.

SSE-S3’ün SSE-KMS ile bir tutulması. SSE-S3, müşterinin düzenleyemediği bir politikaya sahip, CloudTrail’de nesne başına şifre çözme günlüğü tutmayan ve hesaplar arası anahtar paylaşımına izin vermeyen, AWS’in sahip olduğu bir anahtar kullanır. Bu, “beklemedeki veriyi şifrele” gereksinimini karşılar ancak hangi principal’ların belirli nesnelerin şifresini çözeceğini zorunlu kılamaz—bu yönetişimi yalnızca bir CMK ile SSE-KMS sağlar.

Pratik Problem: Kullanım Senaryosu

Senaryo: Meridian Financial, bir Güvenlik hesabına, ayrı Prod/NonProd hesaplarına, ECS/EKS’te ALB arkasında çalışan mikro hizmetlere, RDS/Aurora kümelerine, EBS destekli EC2 örneklerine ve S3 veri göllerine sahip çok hesaplı bir AWS Organization yapısı işletmektedir. Geliştiriciler ve otomasyon şu anda AWS tarafından yönetilen anahtarların, düz metin SSM parametrelerinin ve hesaplar arasında ara sıra yapılan manuel snapshot paylaşımlarının bir karışımını kullanmaktadır.

Zorluk: Bir mühendis yanlışlıkla şifrelenmemiş bir RDS snapshot’ını üçüncü taraf bir hesapla paylaştı ve birkaç API kimlik bilgisinin düz metin SecureString parametreleri olarak saklandığı keşfedildi. Bu durum, veri sızdırma ve yetkisiz geri yükleme erişimi riski oluşturdu.

Önerilen Yaklaşım:

1. Güvenlik hesabında, üye hesaplara aws:PrincipalOrgID aracılığıyla kullanım izni veren bir anahtar politikasıyla organizasyon kapsamlı, müşteri tarafından yönetilen bir AWS KMS simetrik CMK oluşturun ve otomatik rotasyonu etkinleştirin; kısa süreli hesaplar arası işlemler için grant’leri kullanın.
2. Şifrelenmiş kopyalar üretmek için yeni CMK’yi seçerek şifrelenmemiş RDS snapshot’ını ve tüm EBS snapshot’larını kopyalayarak mevcut varlıkları düzeltin, ardından orijinal şifrelenmemiş snapshot’ları silin; yeni RDS ve EBS’nin varsayılan olarak şifrelenmiş kaynaklar oluşturması için hesap varsayılanlarını ayarlayın.
3. Gizli bilgileri CMK ile şifrelenmiş şekilde AWS Secrets Manager’a (veya SSM Parameter Store SecureString’e) taşıyın, Lambda aracılığıyla veritabanı kimlik bilgileri için Secrets Manager otomatik rotasyonunu etkinleştirin ve kaynak tabanlı politikalar ve en az ayrıcalıklı IAM rolleri kullanarak erişimi kısıtlayın.
4. ACM tarafından yönetilen TLS sertifikaları sağlayarak ve bunları modern bir TLS politikası (TLS 1.2/1.3) ile ALB’lere ekleyerek aktarım sırasında şifrelemeyi zorunlu kılın ve veritabanlarını ve istemcileri TLS bağlantıları gerektirecek şekilde yapılandırın.
5. Koruma mekanizmalarıyla tekrarı önleyin: Şifrelenmemiş snapshot’ların oluşturulmasını/paylaşılmasını ve şifrelenmemiş S3 put işlemlerini reddetmek için Service Control Policies uygulayın, şifrelenmiş kaynaklar için AWS Config kurallarını etkinleştirin ve CloudTrail ve CloudWatch Alarms aracılığıyla KMS ve Secrets Manager kullanımını izleyin.

Gerekçe: Organizasyon düzeyinde politikalara sahip merkezi CMK’ler, otomatik yeniden şifreleme, gizli bilgi yaşam döngüsü için Secrets Manager, TLS zorlaması ve önleyici koruma mekanizmaları, düz metin gizli bilgileri ve yetkisiz snapshot erişimini ortadan kaldırmak için AWS’nin en az ayrıcalık ve derinlemesine savunma en iyi uygulamalarını takip eder.

Müşteri Tarafından Yönetilen CMK’lar: Çok Bölgeli, İçe Aktarılan Materyal ve Anahtar İlkeleri

Müşteri tarafından yönetilen bir CMK (Customer Managed CMK), AWS’de sahip olduğunuz veriler üzerindeki her kriptografik işlemin kontrol düzlemidir. Bir tasarımın başarılı olup olmayacağını veya bir kesintiye yol açıp açmayacağını en sık belirleyen üç özellik; anahtarın Bölge topolojisi, anahtar materyalinin kökeni ve ona ekli olan ilkedir.

Çok Bölgeli anahtarlar, farklı Bölgelerde bulunan, aynı anahtar kimliğini ve en önemlisi aynı temel anahtar materyalini paylaşan bir KMS anahtar setidir. DynamoDB global tabloları gibi otomatik olarak çoğaltılmazlar — birincil bir anahtardan replikaları ReplicateKey kullanarak açıkça oluşturursunuz. Anahtar materyali replikalar arasında aynı olduğundan, us-east-1‘de üretilen şifreli metin, Bölgeler arası KMS çağrıları yapılmadan us-west-1‘de deşifre edilebilir. Bu, bir Secrets Manager sırrını Bölgeler arasında çoğaltırken gereken özelliğin ta kendisidir: yük devretme Bölgesindeki replika sırrın, hem her GetSecretValue çağrısındaki Bölgeler arası gecikmeyi ortadan kaldırmak hem de birincil Bölgenin kesintiye uğraması durumunda ayakta kalabilmek için yerel olarak deşifre edilebilir olması gerekir. Tek Bölgeli bir CMK, başka bir Bölgedeki bir Secrets Manager replikasını destekleyemez. Bu nedenle doğru desen, birincil sırrı çok Bölgeli bir CMK ile şifrelemek, anahtarı hedef Bölgeye çoğaltmak ve ardından replika CMK’yı işaret ederek sırrı çoğaltmaktır.

aws kms create-key --multi-region --region us-east-1
aws kms replicate-key --key-id mrk-abc123 \
  --replica-region us-west-1
aws secretsmanager replicate-secret-to-regions \
  --secret-id prod/db \
  --add-replica-regions Region=us-west-1,KmsKeyId=mrk-abc123

İçe aktarılan anahtar materyali (harici köken, Origin=EXTERNAL), ham AES-256 materyalini AWS dışında oluşturup bir KMS anahtar kabuğuna aktardığınızda mevcuttur. AWS, bu materyalin HSM’in korumalı belleği dışında hiçbir zaman bir kopyasına sahip olmaz ve yedeği yoktur. İçe aktarılan materyali silerseniz — ister DeleteImportedKeyMaterial aracılığıyla ister son kullanma tarihi geçtiği için — anahtar PendingImport durumuna geçer ve bu anahtar altında üretilen tüm şifreli metinler, tam olarak aynı baytları yeniden içe aktarmadığınız sürece kurtarılamaz. Bu, örneğin şifrelenmiş veri anahtarı deşifre edilemediği için bir EBS biriminin bağlanamadığı durumlarda kurtarma yoludur: çevrimdışı emanetinizden (escrow) birebir aynı anahtar materyalini yeniden içe aktarın ve birim tekrar kullanılabilir hale gelir. Silinen içe aktarılmış materyali kurtaracak AWS tarafında bir geri yükleme, bir rotasyon hilesi veya bir destek talebi yoktur. Çevrimdışı kopyayı sıfırıncı katman (tier-zero) altyapı olarak kabul edin.

Anahtar ilkeleri, her KMS anahtarı için güvenin köküdür. Yalnızca IAM’in aksine, KMS, anahtar ilkesinin kendisinde açık bir izne ihtiyaç duyar; kms:Decrypt izni veren bir IAM ilkesi, anahtar ilkesi IAM’e yetki devretmedikçe ("Principal": {"AWS": "arn:aws:iam::111122223333:root"} ve koşullu bir ifadenin birleşimi) etkisizdir. Hesaplar arası kullanım için, anahtarın ilkesi harici hesabı veya principal’ı açıkça belirtmelidir ve harici hesap da kendi kullanıcılarına IAM aracılığıyla izin vermelidir. Anahtar ilkesi tarafını unutmak, hesaplar arası Secrets Manager hatalarının en yaygın tek nedenidir — Secrets Manager kaynak ilkesi, harici principal’ın GetSecretValue çağırmasına izin verir, ancak temeldeki Decrypt işlemi, CMK çağrıyı reddetmeye devam ettiği için başarısız olur.

Secrets Manager ve Parameter Store SecureString Desenleri

Secrets Manager ve SSM Parameter Store SecureStrings, her ikisi de şifrelemeyi KMS’e devreder, ancak maliyet, rotasyon semantiği ve Bölgeler arası davranış açısından farklılık gösterir. Secrets Manager, yerel çok Bölgeli çoğaltmayı, hazırlık etiketleriyle (AWSCURRENT, AWSPENDING) sürüm oluşturmayı ve Lambda destekli rotasyonu destekler. Parameter Store SecureString daha ucuzdur, hiyerarşik yollarla entegre olur ve seyrek olarak değiştirilen yapılandırma tarzı sırlar için iyi çalışır.

Hesaplar arası erişim için, hem sır üzerindeki kaynak ilkesini (veya Parameter Store’u kullanan hesaptaki IAM ilkesini) hem de şifrelemeyi yapan CMK üzerindeki KMS anahtar ilkesini güncellemelisiniz. Yalnızca Secrets Manager izinlerinin yeterli olduğunu varsaymak yanlıştır, çünkü erişim iş akışı her zaman CMK’ya karşı örtük bir kms:Decrypt işlemi gerçekleştirir; harici hesap için anahtar ilkesinde bir izin olmadan, sırrın kendi ilkesi karşılansa bile çağrı yapan taraf Decrypt adımında AccessDeniedException alır.

• Secrets Manager: yönetilen rotasyon, JSON yapısı, sır başına ayda ~$0.40, yerleşik çok Bölgeli çoğaltma
• Parameter Store SecureString (Advanced): çok sayıda değer için daha ucuz, parametre başına 8 KB, yerleşik Bölgeler arası çoğaltma yok
• Parameter Store SecureString (Standard): 4 KB’a kadar KMS ile şifrelenmiş parametreler için ücretsiz kullanım hakkı, rotasyon çerçevesi yok

Zarf Şifrelemesi, Bucket Anahtarları ve Grant Token’ları

Zarf şifrelemesi, KMS’in toplu verilerinize asla dokunmaması anlamına gelir. GenerateDataKey çağrısı yaptığınızda, bu çağrı hem (yükünüzü yerel olarak AES-GCM ile şifrelemek için kullanılan) düz metin bir veri anahtarı hem de (şifreli metinle birlikte saklanan) bu veri anahtarının şifrelenmiş bir kopyasını döndürür. Şifreyi çözmek için, sarmalanmış veri anahtarı üzerinde Decrypt çağrısı yapar ve düz metin anahtarını yerel olarak yeniden türetirsiniz. Bu desen çok önemlidir çünkü KMS’in (Bölge başına, anahtar başına) istek kotaları ve API çağrısı başına fiyatlandırması vardır. Her 4 KB’lık kaydı doğrudan bir Encrypt çağrısıyla şifrelerseniz, kısıtlama (throttling) ve maliyet engelleriyle karşılaşırsınız; eğer her bir yığın (batch) veya dosya için bir veri anahtarı oluşturursanız, verim (throughput) yerel kripto kütüphanenizle doğrusal olarak ölçeklenir.

S3 Bucket Keys, SSE-KMS için S3 içinde aynı prensibi uygular. Bir bucket anahtarı olmadan, bir SSE-KMS nesnesine yapılan her PUT ve GET işlemi, bir GenerateDataKey veya Decrypt çağrısı oluşturur. Saniyede binlerce nesne alan bir bucket’ta bu durum, hem KMS kısıtlamasına (throttling) hem de şaşırtıcı bir KMS faturasına yol açar. Bir bucket anahtarını etkinleştirmek, S3’ün bucket seviyesinde kısa ömürlü bir anahtar oluşturmasına ve bunu birçok nesne için yeniden kullanmasına neden olarak KMS istek hacmini kat kat azaltır:

aws s3api put-bucket-encryption --bucket app-data \
  --server-side-encryption-configuration '{
    "Rules":[{
      "ApplyServerSideEncryptionByDefault":{
        "SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/app"},
      "BucketKeyEnabled":true}]}'

Grant’ler, geçici ve ayrıntılı yetki devri için anahtar politikalarına bir alternatiftir. Operasyonel olarak önemlidirler çünkü nihai tutarlılık (eventual consistency) söz konusudur: CreateGrant çağrısı döndükten sonra, grant Bölge’deki her KMS uç noktasında (endpoint) hemen görünür olmaz. Bir istemci birkaç milisaniye sonra bir Encrypt işlemi denediğinde AccessDeniedException alabilir. CreateGrant çağrısının yanıt gövdesi (response body), sonraki KMS çağrılarında --grant-tokens parametresi aracılığıyla iletildiğinde, KMS’i yayılma durumuna bakılmaksızın grant’i derhal uygulamaya zorlayan bir GrantToken dizesi içerir.

TOKEN=$(aws kms create-grant --key-id $KEY \
  --grantee-principal arn:aws:iam::111122223333:role/worker \
  --operations Encrypt Decrypt --query GrantToken --output text)
aws kms encrypt --key-id $KEY --plaintext fileb://payload \
  --grant-tokens "$TOKEN"

Grant token yerine yeniden deneme ve bekleme (retry-with-backoff) yöntemine güvenmek geçerli ancak daha zayıf bir azaltma yöntemidir — gecikme süresini boşa harcar ve yük altında yine de başarısız olur. Standart çözüm her zaman şudur: grant’i oluşturan servisten grant token’ı döndürün ve çağıranların ilk işlemlerinde bunu sunmasını zorunlu kılın.

Pratik Problem: Kullanım Senaryosu

Senaryo: Meridian Financial, S3’te müşteri Kişisel Tanımlayıcı Bilgilerini (PII), RDS’te işlem veritabanlarını ve Lambda aracılığıyla sunucusuz işlemeyi barındıran çoklu hesaplı bir AWS ortamı işletmektedir. Bölgesel anahtar saklama kurallarına uymak için içe aktarılan anahtar materyaline sahip Müşteri Tarafından Yönetilen CMK’ları (Customer Managed CMK) kullanmakta ve felaket kurtarma (disaster recovery) için anahtarları ikinci bir bölgeye kopyalamaktadırlar.

Zorluk: Yakın zamanda yapılan bir denetimde, hesaplar arası şifre çözmeye izin veren yanlış yapılandırılmış bir KMS anahtar politikası bulundu ve harici bir denetçinin S3 nesnelerinin bir alt kümesinin şifresini çözmek için geçici erişime ihtiyacı var; Meridian’ın ayrıca KMS istek maliyetlerini kontrol etmek için güvenli gizli anahtar rotasyonu ve büyük nesneler için verimli şifrelemeye ihtiyacı var.

Önerilen Yaklaşım:

1. Yanlış yapılandırılmış CMK politikasını AWS KMS’te yalnızca gerekli IAM principal’larına ve rollerine açıkça izin veren en az ayrıcalıklı bir politikayla değiştirin ve DR için KMS çoklu Bölge anahtarlarını (multi-Region keys) kullanarak çok Bölgeli bir kopya CMK oluşturun.
2. Uyum pencerelerine göre içe aktarılan anahtar materyali için yeniden içe aktarma veya yaşam döngüsü yönetimi planlayın ve AWS Config ve EventBridge kullanarak otomatik anahtar materyali sona erme/rotasyon bildirimlerini etkinleştirin.
3. Denetçi için kısa bir TTL’ye sahip bir KMS grant’i oluşturun ve anahtar politikasını değiştirmeden geçici şifre çözme işlemlerine izin vermek için denetçinin assume-role oturumunda grant token’ı hemen kullanın.
4. Uzun ömürlü kimlik bilgilerini, temel hizmete (RDS veya API anahtarları) bağlı Lambda tabanlı rotasyon ile AWS Secrets Manager’a taşıyın ve altyapı parametrelerini, dönmeyen öğeler için Systems Manager Parameter Store SecureString olarak saklayın, CMK ile şifrelemeyi ve katı kaynak tabanlı politikaları zorunlu kılın.
5. Uygulama kodunda veya AWS SDK aracılığıyla KMS GenerateDataKey (Encrypt/Decrypt) çağrıları yaparak büyük S3 nesneleri için zarf şifrelemesini uygulayın ve büyük nesnelerin sunucu tarafı şifrelemesi için KMS isteklerini ve maliyetini azaltmak amacıyla S3 Bucket Keys’i etkinleştirin.
6. CloudTrail günlüğünü ve KMS anahtar kullanım günlüğünü etkinleştirin ve beklenmedik şifre çözme veya grant oluşturma durumlarında uyarı vermek için CloudWatch Alarms/GuardDuty kuralları oluşturun.

Gerekçe: Bu yaklaşım, en az ayrıcalıklı anahtar erişimini zorunlu kılar, içe aktarılan materyal için uyumluluğu ve çoklu Bölge sürekliliğini korur, güvenli üçüncü taraf erişimi için geçici grant’ler kullanır, gizli anahtarları rotasyonla merkezileştirir ve AWS en iyi uygulamalarına göre KMS kullanımını ve maliyetini optimize eder.

← Günlükleme · Tüm alanlar · Veri Koruma ve S3 →

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

Amazon'a göz atın →