Amazon SAA-C03: Güvenlik, IAM, KMS ve Yönetişim — Çalışma kılavuzu

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SAA-C03 — Eksiksiz ç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.

Kimlik Temelleri: Kullanıcılar, Root, Gruplar ve Roller

Identity and Access Management, her iş yükünün geçtiği kontrol düzlemidir ve temel prensibi en az ayrıcalıktır: yalnızca ihtiyaç duyulanı, yalnızca ihtiyaç duyulduğu sürece verin ve statik sırları tutan kimlikler yerine kısa ömürlü kimlik bilgileri üreten kimlikleri tercih edin.

Root kullanıcısı hesabın sahibidir, sınırsız izinlere sahiptir ve IAM politikaları veya SCP’ler tarafından kısıtlanamaz. Bu durum, onu ortamdaki en hassas kimlik bilgisi yapar ve acil durumlar için kullanılmalıdır. Yeni bir hesapta: root üzerinde donanım veya sanal bir MFA cihazı etkinleştirin, uzun ve benzersiz bir parola belirleyin, geçmişteki tüm root erişim anahtarlarını kaldırın ve kurtarmanın mümkün olması için alternatif faturalandırma/operasyon/güvenlik irtibat kişilerini kaydedin. İlk kurulumdan sonra — bir IAM yönetici kimliği oluşturma, faturalandırmayı yapılandırma ve hesap takma adını ayarlama — root, AWS’in açıkça gerektirdiği dar görevler (hesabı kapatma, hesap adını değiştirme, silinen IAM izinlerini geri yükleme, MFA Delete’i etkinleştirme ve bir avuç S3/CloudFront root imzalı işlem) dışında tekrar kullanılmaz. Günlük işler için root kullanmak yanlıştır çünkü politikalarla kapsamı daraltılamaz, paylaşıldığında CloudTrail’de kimin kullandığını belirlemek zordur ve tek bir ele geçirilme durumu geri alınamaz bir kontrol sağlar.

İnsanların günlük erişimi, en az ayrıcalık politikalarıyla kapsamı belirlenmiş IAM kimlikleri aracılığıyla sağlanır. Yönetilen politikaları bireysel kullanıcılara değil, gruplara ekleyin: AdministratorAccess eklenmiş bir Administrators grubu ve içine yerleştirilmiş adlandırılmış kullanıcılar, tek bir değişiklik noktası sağlar ve her kullanıcıya aynı politikaları yapıştırma anti-desenini önler. Kaynakların kapsamını * yerine açık ARN’ler ile belirleyin.

Roller ise tamamen farklı bir amaca hizmet eder. Principaller — servisler, EC2 instanceları, Lambda fonksiyonları, federe kullanıcılar, hesaplar arası arayanlar — tarafından üstlenilirler ve otomatik olarak yenilenen geçici STS kimlik bilgileri üretirler. Bu kimlik bilgileri bir Git commit’inde sızdırılamadığı ve manuel olarak yenilenene kadar kalıcı olmak yerine dakikalar veya saatler içinde sona erdiği için, roller insan dışı her şey için varsayılan kimliktir.

Her Rol İçin İki Politika: İzinler ve Güven

Her rol, birbirinden bağımsız iki belge tarafından yönetilir ve bunlardan birini unutmak klasik bir başarısızlık modudur.

İzin politikası (kimlik tabanlı), rol üstlenildikten sonra neler yapabileceğini beyan eder. Güven politikası (kaynak tabanlı, rolün kendisine eklenir), kimin onu üstlenebileceğini beyan eder. Bir role AmazonS3ReadOnlyAccess eklemek, hiçbir principal’in o rol üzerinde sts:AssumeRole çağırmasına izin verilmiyorsa hiçbir işe yaramaz; tersine, izin politikası olmayan geniş kapsamlı bir güven politikası, üstlenilebilen ancak faydalı hiçbir şey yapamayan bir rol üretir.

Bir Lambda execution rolü, servis-principal desenini gösterir — arayan, hesap sahibi değil, servisin kendisidir:

AssumeRolePolicyDocument:              # trust policy
  Version: "2012-10-17"
  Statement:
    - Effect: Allow
      Principal: { Service: lambda.amazonaws.com }
      Action: sts:AssumeRole
Policies:                              # permissions
  - PolicyName: ReadOrders
    PolicyDocument:
      Statement:
        - Effect: Allow
          Action: dynamodb:GetItem
          Resource: arn:aws:dynamodb:*:*:table/Orders

İş Yükü Kimliği: Instance Profilleri, Task Rolleri, IRSA, Roles Anywhere

Bir şablonda, ortam değişkeninde veya bir dizüstü bilgisayarda yaşayan her kimlik bilgisi, gelecekteki bir ihlalin habercisidir. Kanonik AWS deseni, statik erişim anahtarlarını roller aracılığıyla sunulan kısa ömürlü, otomatik olarak yenilenen kimlik bilgileriyle değiştirir.

EC2 için teslimat mekanizması instance profile‘dır — bir IAM rolünü bir instance’a bağlayan ince bir kapsayıcıdır, böylece Instance Metadata Service (IMDSv2) SDK’ya geçici kimlik bilgileri sunabilir. Varsayılan kimlik bilgisi sağlayıcı zinciri bunları yapılandırma olmadan bulur, bu nedenle boto3.client('s3') sorunsuz çalışır ve uygulama kodu hiçbir zaman bir kimlik bilgisi görmez. SSRF tabanlı kimlik bilgisi sızdırmayı önlemek için IMDSv2 (HttpTokens: required) zorunlu kılınmalıdır. Kimlik bilgileri yaklaşık altı saatte bir yenilenir ve iptal işlemi basit bir rol düzenlemesidir.

AppRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Effect: Allow
          Principal: { Service: ec2.amazonaws.com }
          Action: sts:AssumeRole
    Policies:
      - PolicyName: S3DocAccess
        PolicyDocument:
          Statement:
            - Effect: Allow
              Action: [s3:GetObject, s3:PutObject]
              Resource: arn:aws:s3:::docs-bucket/*
AppInstanceProfile:
  Type: AWS::IAM::InstanceProfile
  Properties:
    Roles: [!Ref AppRole]

ECS için bunun benzeri task role; Lambda için execution role; EKS podları için ise IRSA (IAM Roles for Service Accounts) veya EKS Pod Identity‘dir. Her durumda AWS, bir role karşı kimlik bilgilerini kendisi yönetir ve iş yükü hiçbir zaman uzun ömürlü bir sır görmez.

Erişim anahtarlarını bir AMI’ye, user-data betiğine veya .env dosyasına gömmek üç somut nedenle yanlıştır: anahtarlar asla otomatik olarak yenilenmez, kaynak VPC endpoint gibi oturum bağlamına göre kapsamlandırılamazlar ve instance ele geçirilirse veya bir AMI yanlışlıkla paylaşılırsa, kimlik bilgisi kalıcı olarak sızar.

AWS dışındaki iş yükleri için — şirket içi sunucular, diğer bulutlar, CI çalıştırıcıları — gömülü anahtarlar olmadan geçici AWS kimlik bilgilerine ihtiyaç duyanlar için, IAM Roles Anywhere güven çıpası olarak özel bir CA’dan (AWS Private CA veya kendi CA’nız) alınan X.509 sertifikalarını kullanır. İş yükü, istemci sertifikasını sunar ve kısa ömürlü STS kimlik bilgileri alır:

aws_signing_helper credential-process \
  --certificate /etc/pki/client.pem \
  --private-key /etc/pki/client.key \
  --trust-anchor-arn arn:aws:rolesanywhere:...:trust-anchor/... \
  --profile-arn arn:aws:rolesanywhere:...:profile/... \
  --role-arn arn:aws:iam::111122223333:role/OnPremWorkload

Bu, AWS içinde instance rollerinin ve Secrets Manager’ın kapattığı aynı anti-deseni kapatır.

Büyük Ölçekte İnsan Erişimi: Identity Center, SAML, Directory Service

Her hesap için IAM kullanıcısı sağlamak, herhangi bir ölçekte yönetilemez hale gelir. AWS IAM Identity Center (AWS SSO’nun halefi), iş gücü erişimi için önerilen giriş kapısıdır: bir Organization’daki her hesaba federe olan ve permission set’ler — IdP gruplarıyla eşleştirilmiş şablon IAM rolleri — aracılığıyla geçici rol tabanlı oturumlar veren tek bir dizin. Kullanıcılar Identity Center portalında bir kez kimlik doğrulaması yapar, ardından atanan herhangi bir hesaba permission set’leri üstlenirler.

Identity Center, otomatik katılım/değişiklik/ayrılma akışları için SAML 2.0 ve SCIM aracılığıyla harici IdP’lerle (Okta, Entra ID/Azure AD, Google Workspace, ADFS) ve şirket içi Active Directory ile AWS Directory Service AD Connector (bir proxy) veya AWS Managed Microsoft AD (AWS’de tam bir replika) aracılığıyla entegre olur. Kimliği doğrulanmamış veya üçüncü taraf tarafından doğrulanmış kullanıcılardan AWS’i çağırması gereken mobil veya web uygulamaları için Amazon Cognito, harici kimliği geçici STS kimlik bilgileriyle değiştirir ve yine gömülü uzun ömürlü anahtarlardan kaçınır.

Hesaplar Arası Erişim

Hesaplar arası erişim, paylaşılan kullanıcılarla değil, rollerle ifade edilir ve her iki tarafın da onaylaması gerekir. Hedef hesap (B), güven politikasında A Hesabını (veya bu hesaptaki belirli bir principal’ı) belirten bir rol oluşturur ve A’daki çağrıyı yapanın da o rolün ARN’sini hedefleyen sts:AssumeRole iznine sahip olması gerekir. Tek başına taraflardan biri yeterli değildir. Bu işlem, kısa ömürlü kimlik bilgileri ve her iki hesapta da net bir CloudTrail denetim izi oluşturur.

Rolü üstlenen principal üçüncü bir taraf (bir SaaS sağlayıcısı) olduğunda, confused deputy problemini engellemek için bir ExternalId koşulu ekleyin ve MFA gerektirmeyi düşünün:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "a1b2c3-unique-token" },
    "Bool": { "aws:MultiFactorAuthPresent": "true" }
  }
}

Servisten servise hesaplar arası çağrılar için kaynak politikaları kullanılır. A Hesabındaki bir SNS topic’inin B Hesabındaki bir Lambda’yı çağırmasına izin vermek için:

aws lambda add-permission \
  --function-name ProcessNotification \
  --statement-id AllowSNSInvoke \
  --action lambda:InvokeFunction \
  --principal sns.amazonaws.com \
  --source-arn arn:aws:sns:us-east-1:111111111111:my-topic

--principal sns.amazonaws.com bir service principal‘dır (Lambda’yı SNS servisinin kendisi çağırır) ve --source-arn ise confused deputy problemini önlemek için güven kapsamını belirli bir topic ile sınırlar.

Organizasyonlar arası S3 paylaşımı için naif yaklaşım olan her hesap ARN’sini bucket politikasına listelemek, ölçeklenmez ve yeni bir hesap eklendiğinde bozulur. Doğru desen aws:PrincipalOrgID‘dir:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/*",
  "Condition": {
    "StringEquals": { "aws:PrincipalOrgID": "o-abcd1234ef" }
  }
}

Bu organizasyondaki herhangi bir hesapta bulunan herhangi bir principal’a izin verilir; diğer herkes reddedilir. Koşul olmadan Principal: "*" kullanımının bucket’ı herkese açık yapacağına dikkat edin — kapsamı kısıtlayan şey koşul anahtarıdır. Kimlik tarafı hala önemlidir: üye hesaplardaki kullanıcıların da (hesap root’u değillerse) kendi IAM politikaları tarafından verilen s3:GetObject iznine ihtiyaçları vardır, çünkü hesaplar arası erişim, çağrıya her iki tarafın da izin vermesini gerektirir.

Özellikle S3 için, 2023’ten beri varsayılan Nesne Sahipliği (Object Ownership) ayarı olan Bucket owner enforced (Bucket sahibi zorunlu), ACL’leri tamamen devre dışı bırakarak bucket politikalarını bucket için tek yetkilendirme mekanizması haline getirir. Nesneler daha önce başka hesaplar tarafından yüklendiyse, geçmişteki nesne ACL’leri veya bucket-owner-full-control hazır ACL’i hala devrede olabilir.

Organizations ve Service Control Policies

AWS Organizations, hesapları kökte bir yönetim hesabıyla birlikte bir OU (Organizational Unit) ağacı şeklinde bir araya getirir. Service Control Policies (SCP’ler), köke, bir OU’ya veya tek bir hesaba eklenen koruma mekanizmalarıdır. Hesaptaki her IAM kullanıcısına ve rolüne — hesap root’u dahil — uygulanırlar, ancak yönetim hesabının kendisine uygulanmazlar. Bu nedenle iş yükleri asla orada çalıştırılmamalıdır.

Kritik zihinsel model: SCP’ler asla izin vermez. Bir hesapta izin verilen eylemlerin maksimum setini tanımlarlar. Bir eyleme yalnızca, bir kimlik veya kaynak politikası tarafından izin verildiyse ve hesabın yolundaki herhangi bir SCP tarafından engellenmiyorsa izin verilir. Bir geliştirici AdministratorAccess yetkisine sahip olsa bile, bir SCP ap-southeast-2 bölgesi dışında ec2:RunInstances eylemini reddediyorsa, us-east-1 bölgesinde bir sunucu başlatma denemesi başarısız olur. Tersine, s3:* eylemine izin veren bir SCP tek başına bir işe yaramaz — kullanıcının hala s3:* iznini veren bir IAM politikasına ihtiyacı vardır. SCP’ler, IAM’in zaten izin verdiklerini filtreler; bunlar tavanlardır, taban değil.

Tipik SCP kullanım alanları arasında bölge kilitleme, CloudTrail veya GuardDuty’nin devre dışı bırakılmasını yasaklama, bir acil durum rolü (break-glass role) dışında KMS anahtar silmeyi yasaklama ve şifrelemeyi zorunlu kılma yer alır. Başlatma sırasında şifreli EBS’yi zorunlu kılmak için iki mekanizmayı birleştirin: bölgede varsayılan olarak EBS şifrelemesini etkinleştirin (kullanıcıların betikleri değiştirmemesi için bölge başına bir hesap ayarıdır) ve denetlenebilir bir koruma mekanizması olarak bir SCP ekleyin:

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:volume/*",
  "Condition": { "Bool": { "ec2:Encrypted": "false" } }
}

SCP’ler tüm hesaba uygulandığından, bir üye hesaptaki yetkileri ele geçirilmiş bir yönetici tarafından aşılamazlar. Etiket politikaları (Tag policies), maliyet ataması ve ABAC’nin güvenilir bir şekilde çalışması için standartlaştırılmış etiket anahtarlarını ve büyük/küçük harf kullanımını (CostCenter, costcenter değil) zorunlu kılar. Organizations ayrıca yetkilendirilmiş yönetimi (delegated administration) destekler: güvenlik servislerini yönetim hesabından çalıştırmak yerine, GuardDuty, Security Hub, IAM Access Analyzer veya Config için bir üye (“güvenlik” veya “denetim”) hesabını yönetici olarak yetkilendirin — bu, görevler ayrılığı ilkesini korur.

KMS: Anahtarlar, Anahtar Politikaları ve Sahiplik Modelleri

KMS, anahtar materyalini sahiplik ve kontrole göre ayırır:

Bir CMK, anahtara eklenmiş kaynak tabanlı bir politika olan bir anahtar politikası tarafından yönetilir. Diğer neredeyse tüm AWS kaynaklarının aksine, anahtar politikası önce IAM’e yetki devretmedikçe, IAM politikaları tek başına bir KMS anahtarına erişim veremez:

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

Bu ifade olmadan, hiçbir IAM politikası anahtarı kullanılabilir hale getirmez. Hem anahtar politikası hem de çağıranın IAM politikası işleme izin vermelidir — bu, en sık karşılaşılan tek şifreleme hatasıdır. Bir IAM politikasında kms:Decrypt izni vermek gereklidir ancak yeterli değildir; eğer anahtar politikası IAM’e yetki devretmiyorsa veya principal’ı belirtmiyorsa, bir yönetici için bile şifre çözme işlemi AccessDenied hatasıyla başarısız olur.

Sizin adınıza KMS kullanan hizmetler (EBS, S3, RDS, Lambda) için, çağıran rol genellikle kms:GenerateDataKey, kms:Decrypt ve sıklıkla kms:CreateGrant izinlerine ihtiyaç duyar. Bir CMK ile EBS birimlerini şifreleyen bir EKS yönetilen düğüm grubu için, Auto Scaling hizmet bağlantılı rolü (service-linked role), kms:CreateGrant izniyle anahtar politikasında yer almalıdır, aksi takdirde instance başlatmaları sessizce başarısız olur.

Müşteri tarafından yönetilen CMK rotasyonu açıkça etkinleştirilmelidir — birçok uzman, tüm KMS anahtarlarının otomatik olarak döndüğünü yanlış bir şekilde varsayar:

aws kms enable-key-rotation --key-id alias/my-cmk
aws kms get-key-rotation-status --key-id alias/my-cmk

Rotasyon aynı anahtar kimliğini ve takma adını korur; arka plandaki materyal değişir ancak geçmiş şifreli metinler çözülebilir kalır çünkü KMS mevcut şifreli metinleri çözmek için eski materyali saklarken, yeni yazma işlemleri taze materyal kullanır. İçe aktarılan materyal asla otomatik olarak dönmez. KMS, zorunlu 7–30 günlük bir bekleyen silme penceresi uygular; bunu CloudTrail’de ScheduleKeyDeletion veya DisableKey ile eşleşen bir EventBridge kuralıyla ve sunucusuz, yoklama gerektirmeyen bir uyarı deseni için bir SNS konusunu hedefleyerek eşleştirin:

{
  "source": ["aws.kms"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": { "eventName": ["ScheduleKeyDeletion", "DisableKey"] }
}

Harici Anahtar Depoları (External Key Stores), düzenleyicilerin anahtar materyalinin fiziksel olarak müşteri kontrolündeki bir HSM’de bulunmasını gerektirdiği durumlarda modeli genişletir. KMS, kriptografik işlemleri şirket içi HSM ile konuşan bir XKS proxy’sine iletir; HSM çevrimdışıysa, şifre çözme başarısız olur — erişilebilirlik müşterinin sorumluluğu haline gelir.

Çok Bölgeli Anahtarlar (Multi-Region Keys - MRK’lar), Bölgeler arasında aynı anahtar kimliğini ve materyalini paylaşır, bu nedenle us-east-1‘de üretilen şifreli metin eu-west-1‘de doğrudan çözülebilir. Bu, DynamoDB Global Tables, SSE-KMS ile S3 Bölgeler Arası Çoğaltma (Cross-Region Replication) ve bir bekleme (standby) Bölgesinin şifreli yedekleri okuması gereken DR (Felaket Kurtarma) senaryoları için doğru desendir. Standart tek Bölgeli anahtarlar, çoğaltma sırasında şifre çözme ve ardından yeniden şifreleme gerektirirdi.

Hesaplar Arası Şifreli Kaynak Paylaşımı

Şifreli AMI ve EBS anlık görüntü (snapshot) paylaşımı, en yaygın hesaplar arası hata modlarından biridir çünkü dört koordineli eylem gerektirir: (1) müşteri tarafından yönetilen bir CMK kullanmak — AWS tarafından yönetilen anahtarlar paylaşılamaz; (2) hedef hesabı anahtar politikasına kms:Decrypt, kms:DescribeKey, kms:CreateGrant ve kms:ReEncrypt* izinleriyle bir principal olarak eklemek; (3) AMI veya anlık görüntünün başlatma/paylaşım izinlerini o hesabı içerecek şekilde değiştirmek; ve (4) hedef hesaptaki IAM principal’ının da bu KMS eylemlerine sahip olduğundan emin olmak. 2. adımı atlarsanız paylaşım işlemi başarılı olmuş gibi görünür, ancak alıcı hesap şifreyi çözemez. Yalnızca AMI paylaşımının yeterli olduğunu varsaymak klasik bir tuzaktır.

S3 Sunucu Tarafı Şifreleme Modları

Bir gereksinim otomatik yıllık rotasyon, CloudTrail denetlenebilirliği ve anahtar maliyetini en aza indirmeyi belirttiğinde, cevap AWS tarafından yönetilen aws/s3 anahtarı ile SSE-KMS‘dir — ücretsiz olarak yıllık döner ve her GenerateDataKey/Decrypt çağrısı günlüğe kaydedilir. SSE-S3 daha ucuzdur ancak anahtar kullanımına dair bir iz bırakmaz. Müşteri tarafından yönetilen bir CMK, aylık 1$ ek maliyet getirir ve yalnızca rotasyonu etkinleştirirseniz döner.

SSE-S3 ve SSE-KMS’i karıştırmak klasik bir PHI tuzağıdır. SSE-S3 veriyi şifreler ancak anahtar politikası, CloudTrail görünürlüğü ve bir uyumluluk ekibinin anahtarı yönetmesi için bir yol sunmaz — bu nedenle anahtarı “yönetme”, “kontrol etme”, “denetleme” veya “erişimi iptal etme” gibi ifadeler içeren herhangi bir gereksinimi karşılayamaz. Tersine, gereksinim yalnızca “minimum yönetimle durağan halde şifreleme” olduğunda SSE-KMS’i seçmek aşırı mühendisliktir (over-engineering).

SSE-KMS’i etkinleştirmek tek başına yetkisiz okumaları engellemez. Eğer bucket politikası s3:GetObject izni veriyorsa ve anahtar politikası aynı principal’a kms:Decrypt izni veriyorsa, nesne okunabilir durumdadır. Durağan halde şifreleme, fiziksel medya ihlallerine karşı koruma sağlar ve anahtar politikası aracılığıyla ikinci bir yetkilendirme kontrolü ekler — doğru şekilde kapsamlandırılmış bucket politikaları, IAM politikaları, VPC uç nokta politikaları ve aws:PrincipalOrgID koşullarının yerini tutmaz.

S3’de Şifreleme ve TLS’yi Zorunlu Kılma

Bir bucket’ı “varsayılan olarak şifreli” yapmak yeterli değildir — istemciler şifreleme başlığını atlayabilir veya geçersiz kılabilir. İki koruma katmanı uygulanmalıdır: varsayılan bucket şifrelemesi (istemci bir başlık belirtmezse başlığı doldurur) ve gerekli başlık olmadan PutObject isteklerini reddeden reddetme tabanlı bir bucket policy ile TLS olmayan erişimi engelleyen bir ifade:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnEncryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::phi-bucket/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    },
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::phi-bucket", "arn:aws:s3:::phi-bucket/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

aws:SecureTransport koşulu HTTPS’yi zorunlu kılarak “aktarım sırasında şifreleme” (encrypted in transit) gereksinimini karşılar. Uyum ekibinin sahip olduğu bir CMK kullanan SSE-KMS ile birleştirildiğinde, bu, kanonik PHI depolama modelidir.

Aktarım Sırasında ve Beklemede Şifreleme

Beklemede şifreleme (KMS ile şifrelenmiş EBS, RDS depolaması, S3 nesneleri) ve aktarım sırasında şifreleme (hattaki TLS), farklı tehditlere yönelik bağımsız kontrollerdir — disk hırsızlığına karşı ağ dinlemesi gibi. Bir RDS örneğinde KMS’i etkinleştirmek, temelindeki depolamayı korur; varsayılan olarak şifresiz olabilen istemci-veritabanı oturumu için hiçbir şey yapmaz. RDS MySQL için, aktarım sırasında koruma, RDS CA paketini indirmeyi, parameter group’ta require_secure_transport=ON ayarını yapmayı ve istemcileri --ssl-ca=rds-combined-ca-bundle.pem ile bağlamayı gerektirir. “Beklemede şifreleme açık” durumunu yeterli görmek, sık karşılaşılan bir denetim hatasıdır.

Secrets Manager ve Parameter Store

Yapılandırma dosyalarındaki, ortam değişkenlerindeki veya CloudFormation parametrelerindeki statik veritabanı parolaları, kimlik bilgisi sızıntılarının önde gelen vektörüdür. AWS Secrets Manager, gizli bilgileri (secret) KMS ile şifrelenmiş olarak saklar, bunları IAM kontrollü GetSecretValue aracılığıyla sunar ve en önemlisi, bir Lambda rotasyon fonksiyonu aracılığıyla otomatik olarak döndürür (rotate). RDS, Aurora, Redshift ve DocumentDB için AWS, veritabanına bağlanan, yeni bir parola oluşturan, hem gizli bilgiyi hem de veritabanı kullanıcısını atomik olarak güncelleyen ve tek kullanıcılı veya çok kullanıcılı stratejileri destekleyen yönetilen bir rotasyon Lambda’sı sağlar. Diğer sistemler için, dört adımlı yaşam döngüsünü uygulayan bir Lambda yazarsınız: createSecret, setSecret, testSecret, finishSecret.

import boto3, json
secret = json.loads(
    boto3.client('secretsmanager')
         .get_secret_value(SecretId='prod/aurora/app')['SecretString'])
conn = pymysql.connect(host=secret['host'],
                       user=secret['username'],
                       password=secret['password'])

Uygulamalar, değeri kısa bir süreliğine önbelleğe alır (AWS SDK önbellekleme kütüphanesini kullanarak) ve kimlik doğrulama hatasında yeniden bağlanır. Rotasyon görünmezdir ve bir parolayı değiştirmek için herhangi bir dağıtım (deployment) gerekmez.

SSM Parameter Store SecureString, rotasyon gerekmediğinde ve maliyetin öncelikli olduğu durumlarda alternatiftir:

Bir SecureString parametresini alan tarafın, anahtar üzerinde hem ssm:GetParameter hem de kms:Decrypt iznine ihtiyacı vardır. KMS iznini unutmak en yaygın yanlış yapılandırmalardan biridir — IAM policy doğru görünür ancak API çağrısı şifre çözme (decrypt) sırasında başarısız olur.

EC2, ECS, EKS ve Lambda üzerinde, kod bir IAM rolü üstlenmeli ve GetSecretValue veya GetParameter çağrısı yapmalıdır; diskte uzun ömürlü kimlik bilgileri bulunmamalıdır. IAM kullanıcı erişim anahtarlarını doğrudan uygulama koduna — şifrelenmiş olsa bile — gömmek, en az ayrıcalık ilkesini ihlal eder ve rotasyonu zorlaştırır.

Denetim ve Adli Bilişim Araçları

CloudTrail, her AWS API çağrısını kaydeder: kim, ne, ne zaman, nereden. Yönetim hesabından etkinleştirilen bir organization trail, tüm hesaplardaki olayları tek bir S3 bucket’ında toplar; ideal olarak bu, S3 Object Lock ve MFA Delete ile kilitlenmiş bir güvenlik hesabında olmalıdır. Bu, değişmez bir adli bilişim zaman çizelgesi sağlar — hangi principal bir volume’ü sildi, hangi rol bir security group’u değiştirdi, hangi erişim anahtarı 03:17 UTC’de ec2:RunInstances çağrısı yaptı. Bunu CloudWatch Logs ve alarmlar (root girişi, IAM policy değişiklikleri) ve belirli bir andaki kaynak durumu ve uyumluluk paketleri için AWS Config ile tamamlayın. cloudtrail:StopLogging ve cloudtrail:DeleteTrail eylemlerini reddeden bir SCP ile kurcalanmasını önleyin.

Bir S3 bucket üzerindeki MFA Delete, bir nesne sürümünü kalıcı olarak silmek veya sürümlemeyi devre dışı bırakmak için root kullanıcısını bir MFA token’ı sunmaya zorlar. Yalnızca root tarafından CLI aracılığıyla etkinleştirilebilir ve fidye yazılımlarına (ransomware) ve içeriden silmelere karşı güçlü koruma sağlar.

Amazon Macie, S3’teki PII, PHI, kimlik bilgileri ve finansal verileri keşfetmek için yönetilen makine öğrenimini (ML) kullanır ve önem derecesine göre sıralanmış bulgular üretir. Bu bir şifreleme aracı değil, bir keşif aracıdır.

Tehdit Tespiti: GuardDuty, Security Hub, Detective

Amazon GuardDuty, VPC Flow Logs, DNS günlükleri ve CloudTrail yönetim ve veri olaylarını sürekli olarak analiz eder; EKS denetim günlükleri, S3 veri olayları, EBS kötü amaçlı yazılım taramaları, Lambda ağ etkinliği ve RDS oturum açma olayları için özel koruma planları sunar. GuardDuty RDS Protection, Aurora ve RDS’e yönelik anormal veya kaba kuvvet (brute-force) kimlik doğrulama girişimlerini ortaya çıkarır — bu, bir security group’un yakalayamayacağı bir davranıştır çünkü bağlantı L4’te meşrudur. Bulgular EventBridge, Security Hub ve Detective panolarına akar.

Security group’lar yalnızca L3–L4’te çalışır. 443 portunda 0.0.0.0/0 adresine izin veren bir grup, bir SQL enjeksiyonu yükünü ilettiğinde kendi işini yapıyordur — WAF’ın varlık amacı da tam olarak bunu durdurmaktır. Derinlemesine savunma (defense in depth), her biri diğerlerinin göremediği bir katmanı kapsayan security group’lar artı WAF artı Shield artı GuardDuty anlamına gelir.

DDoS: Shield Standard ve Advanced

AWS Shield Standard otomatiktir ve ücretsizdir; her hesabı yaygın L3/L4 saldırılarına (SYN flood, yansıtma saldırıları) karşı korur. Görünürlük olmadan, özel azaltma tedbiri sunmadan ve insan müdahalesi yolu olmaksızın sessizce çalışır.

AWS Shield Advanced (organizasyon başına aylık 3.000$ artı veri transferi ücretleri), senaryoda proaktif müdahale, özel müdahale ekibi, DDoS kaynaklı ölçeklenmeye karşı maliyet koruması veya saldırıların neredeyse gerçek zamanlı görünürlüğü gibi ifadeler geçtiğinde gereklidir. CloudFront, Global Accelerator, ALB, CLB, Route 53 ve Elastic IP’leri kapsar ve aktif bir saldırı sırasında sizin adınıza WAF kuralları yazmak için —bir IAM rolü aracılığıyla önceden yetkilendirilmiş— Shield Müdahale Ekibi’ne (SRT) 7/24 erişim sağlar. Bir ALB ve Route 53 arkasındaki bir tasarımın yönetilen tespit ve insan müdahalesi gerektirdiği durumlarda, tek başına Shield Standard yetersiz kalır; bu, sık karşılaşılan bir tuzaktır. Advanced ayrıca saldırılar tarafından tetiklenen ölçeklenme için maliyet koruması da sağlar. “EN AZ uygulama çabası” belirtildiğinde ve mimari zaten Global Accelerator veya bir ALB içeriyorsa, cevap genellikle özel Lambda@Edge oluşturmak veya CDN’i taşımak değil, Shield Advanced’i etkinleştirmek ve AWS tarafından yönetilen WAF kural gruplarını eklemektir.

Uygulama Katmanı Koruması: AWS WAF

AWS WAF; CloudFront, Application Load Balancer, API Gateway, AppSync, App Runner ve Cognito kullanıcı havuzlarına (user pools) eklenir. Network Load Balancer’ları doğrudan korumaz (önüne CloudFront koyun). L7 trafiğini denetler ve SQL enjeksiyonu, XSS, boyut kısıtlamaları, coğrafi engelleme, IP itibarı ve hız sınırlaması için kurallar uygular. AWS Tarafından Yönetilen Kurallar (AWS Managed Rules), AWSManagedRulesCommonRuleSet ve AWSManagedRulesSQLiRuleSet gibi, regex yazmaya gerek kalmadan kullanılabilecek hazır kural grupları sunar.

Hız tabanlı kurallar (Rate-based rules), HTTP flood ve kimlik bilgisi doldurma (credential stuffing) saldırılarına karşı birincil savunmadır. Bu kurallar, kaynak IP başına (veya yönlendirilen bir başlık bilgisine göre) beş dakikalık bir penceredeki istekleri sayar ve kuralı ihlal edenleri otomatik olarak engeller:

Rules:
  - Name: RateLimitPerIP
    Priority: 1
    Statement:
      RateBasedStatement:
        Limit: 2000        # per 5-min window per IP
        AggregateKeyType: IP
    Action: { Block: {} }
    VisibilityConfig:
      CloudWatchMetricsEnabled: true
      MetricName: RateLimitPerIP
      SampledRequestsEnabled: true

WAF bir DDoS hizmeti değildir — bu Shield’in görevidir. WAF, kaynak politikalarını (TLS dışı erişimi reddeden S3 bucket politikaları, erişilebilecek bucket’ları sınırlayan VPC endpoint politikaları) ve ağ kontrollerini (security group’lar, NACL’ler) tamamlar — herhangi bir katmandaki tek bir yanlış yapılandırma verileri açığa çıkarmamalıdır.

Ağ İzolasyonu: Security Group’lar, NACL’ler, Network Firewall

Bir VPC içinde savunma katmanlıdır:

• Security group’lar stateful’dur (durum bilgisi tutar), ENI’lere uygulanır, yalnızca izin (allow) kuralı alır ve tüm kuralları birlikte değerlendirir. Dönüş trafiğine otomatik olarak izin verilir, bu nedenle geçici (ephemeral) portların açıkça açılmasına gerek yoktur.
• Network ACL’ler stateless’tir (durum bilgisi tutmaz), alt ağlara (subnet) uygulanır, hem izin (allow) hem de reddetme (deny) kurallarını destekler ve kuralları sayısal sırayla değerlendirir. Stateless oldukları için, gelen (inbound) 443’e izin verirseniz, yanıtlar için giden (outbound) geçici 1024–65535 portlarına da izin vermelisiniz. Bunu unutmak, tüm yanıtların fark edilmesi zor şekillerde düşürülmesine (drop) neden olur. Security group’larda bu sorun yoktur.
• AWS Network Firewall, derin paket denetimi (deep packet inspection), Suricata uyumlu IPS kuralları ve alan adı tabanlı giden (egress) filtreleme sağlar. Merkezi denetim için alt ağlar ile IGW/TGW’ler arasında konumlandırılır.

Yalnızca security group’ların yeterli olduğunu varsaymak, alt ağ seviyesindeki tehditleri ve etki alanı (blast-radius) kontrollerini göz ardı eder; yalnızca NACL’lerin yeterli olduğunu varsaymak ise onların stateless yapısını ve kabalığını göz ardı eder.

Tuzak Kataloğu

Trust policy’nin (güven politikası) unutulması. Bir rolün izinler politikası (permissions policy) yetenekler verir; yalnızca güven politikası rolün üstlenilebilirliğini (assumability) sağlar. Hesaplar arası veya hizmetten hizmete erişimin çalışması için her ikisinin de izin vermesi gerekir — kimlik politikasının (identity policy) ne kadar izin verici olduğuna bakılmaksızın, çağıran taraf sts:AssumeRole işleminde AccessDenied hatası alır.

Eşleşen bir anahtar politikası (key policy) olmayan IAM politikası. IAM’deki kms:Decrypt izni gereklidir ancak yeterli değildir. Anahtar politikası ya principal’ı (sorumlu) ismen belirtmeli ya da Principal: {"AWS": "arn:aws:iam::ACCOUNT:root"} ile IAM’e yetki devretmelidir. Yalnızca AMI paylaşımı yapılıp anahtar politikası güncellenmediğinde, şifrelenmiş AMI/snapshot paylaşımı başarısız olur.

SCP’lerin izin (grant) olarak görülmesi. SCP’ler asla izin vermez, yalnızca üst sınırı belirler. Eşleşen bir kimlik politikası olmadan Allow s3:* içeren bir SCP hiçbir işe yaramaz. Tersine, izin verici bir kimlik politikası, hesabın yolundaki herhangi bir SCP Deny kuralı tarafından sınırlandırılır.

KMS rotasyonunun otomatik olduğunun varsayılması. Müşteri tarafından yönetilen CMK’lar (Customer-managed CMK) etkinleştirilene kadar rotasyona uğramaz; içeri aktarılan anahtar materyali ise asla otomatik olarak rotasyona uğramaz.

Uyumluluk denetimi gerektiren veriler için SSE-S3’ün seçilmesi. SSE-S3’ün anahtar politikası, CloudTrail görünürlüğü ve anahtarı iptal etme yolu yoktur — anahtarı “yönetme”, “kontrol etme”, “denetleme” veya “iptal etme” gibi gereksinimleri karşılayamaz.

Bekleme durumundaki şifrelemenin (encryption at rest) yeterli görülmesi. Bekleme (at rest) ve aktarım (in transit) sırasındaki şifreleme birbirinden bağımsızdır. KMS kullanan bir RDS’in hala require_secure_transport=ON ayarına ve istemci CA doğrulamasına ihtiyacı vardır.

Bucket politikasında hesapların tek tek ismen belirtilmesi. Bu yöntem ölçeklenmez ve organizasyon değişikliklerinde bozulur. aws:PrincipalOrgID kullanın.

Access key’lerin herhangi bir yere hardcode edilmesi. User data, .env dosyaları, CloudFormation parametreleri, Git — her zaman yanlıştır. Instance profile’ları, task role’leri, execution role’leri, IRSA/Pod Identity veya Roles Anywhere kullanın.

Günlük işler için root kullanıcısının kullanılması veya root’a politika eklenmesi. Root kullanıcısı IAM veya SCP’ler tarafından kısıtlanamaz; root’a bir politika eklemek anlamsızdır. Bunu yapan herhangi bir cevap temelden yanlıştır.

Hesaplar arası (cross-account) erişim için IAM kullanıcılarının kullanılması. IAM kullanıcıları başka bir hesap tarafından üstlenilemez (assume edilemez); hedef hesapta bir rol oluşturun ve kaynak hesaptaki principal’ın bu rolü üstlenmesine izin verin.

WAF arkasında NLB kullanılması. WAF, NLB’lere eklenemez. L7 filtrelemesi gerekiyorsa NLB’nin önüne CloudFront koyun.

NACL’de giden (outbound) geçici (ephemeral) port kuralının eksik olması. Stateless (durum bilgisi tutmayan) NACL’ler, dönüş yolu için açık kurallara ihtiyaç duyar. Giden 1024–65535 portlarının eksik olması, gelen tüm 443 yanıtlarının sessizce bozulmasına neden olur.

Yönetilen müdahale (managed engagement) için Shield Standard kullanılması. Standard pasiftir ve SRT erişimi yoktur; yalnızca Advanced “proaktif yönetilen müdahale” veya “maliyet koruması” gereksinimlerini karşılar.

← Uygulama Entegrasyonu · Tüm alanlar · Yönetim →

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

Amazon'a göz atın →