Amazon SCS-C02: Kimlik ve Erişim Yönetimi — Ç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.

Kimlikler, Prensipaller ve Politika Değerlendirmesi

IAM, kimlikler (kullanıcılar, gruplar, roller) ile prensipaller (istekte bulunan doğrulanmış varlık) arasında ayrım yapar. Kullanıcılar, statik kimlik bilgileriyle uzun ömürlüdür; rollerin kendi kimlik bilgileri yoktur ve kısa ömürlü STS token’ları üretmek için üstlenilirler (assume edilirler). Gruplar, kullanıcılara politika eklemek için kullanılan kapsayıcılardır — asla prensipal değildirler ve üstlenilemezler.

Her API çağrısı deterministik bir değerlendirme zincirinden geçer: herhangi bir yerdeki açık bir Deny (Reddetme) her zaman kazanır, ardından organizasyon seviyesindeki SCP’lerin izin vermesi gerekir, ardından izin sınırlarının (permissions boundaries) izin vermesi gerekir, ardından oturum politikalarının (varsa) izin vermesi gerekir ve son olarak en az bir kimlik veya kaynak tabanlı politikanın bir Allow (İzin) içermesi gerekir. Herhangi bir Allow katmanının eksik olması, örtük bir reddetme (implicit deny) ile sonuçlanır. Katmanlamanın önemli olmasının nedeni budur: s3:* izni veren bir kimlik politikası, bir SCP s3:DeleteBucket eylemini reddederse veya bir izin sınırı S3’ü tamamen dışarıda bırakırsa anlamsızdır.

Kaynak tabanlı politikalar (S3 bucket politikaları, KMS anahtar politikaları, SNS topic politikaları, Lambda fonksiyon politikaları), çağıran tarafında herhangi bir kimlik politikası olmaksızın doğrudan bir prensipale erişim verebilir — aynı hesap içinde. Hesaplar arası erişim için, hem kaynak hesaptaki kimlik politikası hem de hedef hesaptaki kaynak politikası eyleme izin vermelidir.

Roller, Güven Politikaları (Trust Policies) ve AssumeRole

Bir rolün iki politika belgesi vardır: güven politikası (trust policy) (rolü kimin üstlenebileceği) ve bir veya daha fazla izin politikası (permissions policies) (rol üstlenildikten sonra ne yapabilecekleri). Güven politikası, sts:AssumeRole eylemini kullanarak rolün kendisi üzerinde bulunan kaynak tabanlı bir politikadır. Eşleşen bir güven politikası olmadan, çağıranın kimlik politikasında sts:AssumeRole izni olsa bile AssumeRole çağrısı AccessDenied hatasıyla başarısız olur.

Hesaplar arası yetki devri (delegation) için, güven politikası güvenilen hesabı veya o hesaptaki belirli bir rol/kullanıcı ARN’sini belirtir ve — üçüncü taraf erişimi için kritik olarak — bir ExternalId zorunlu kılar:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-shared-secret-9271" }
    }
  }]
}

ExternalId, confused deputy (şaşkın vekil) sorununa karşı koruma sağlar: bu olmadan, birçok müşteri hesabında roller üstlenen üçüncü taraf bir SaaS sağlayıcısı, yanlış müşterinin rolü üzerinde işlem yapması için kandırılabilir. Koşulda sts:ExternalId‘yi atlamak veya sts:AssumeRole sırasında yanlış değeri geçmek, rolü üstlenirken AccessDenied hatası üretir — bu, izleme veya CSPM araçları gibi satıcıları sisteme dahil ederken (onboarding) sık karşılaşılan bir yanlış yapılandırmadır.

AWS servisleri (Lambda, EC2, ECS görevleri) için, güven politikası bir hizmet prensipali (service principal) belirtir, örn. "Service": "lambda.amazonaws.com". S3 erişimine ihtiyaç duyan bir Lambda fonksiyonu, izin politikası bucket üzerinde s3:GetObject ve s3:PutObject izni veren bir yürütme rolünü (execution role) üstlenmelidir; buna eşdeğer olarak, bir S3 bucket politikası, fonksiyonun rol ARN’sini prensipal olarak belirtebilir. Her iki mekanizma da tek bir hesap içinde tek başına çalışır.

İzin Sınırları (Permissions Boundaries)

Bir izin sınırı (permissions boundary), bir kullanıcıya veya role eklenen ve kimlik tabanlı politikaların ne verdiğine bakılmaksızın o kimliğin sahip olabileceği maksimum izinleri sınırlayan gelişmiş bir kontroldür. Etkin izinler, kimlik politikası ile sınırın kesişimidir. Bir grup politikası ec2:* izni verse bile sınır yalnızca ec2:Describe* eylemlerine izin veriyorsa, kullanıcı yalnızca describe (açıklama) işlemleri yapabilir.

Sınırlar genellikle izin delegasyonu için kullanılır: geliştiricilerin uygulamaları için IAM rolleri oluşturmalarına izin verilir, ancak oluşturdukları her rolün belirli bir sınırı taşıması zorunlu kılınır. Geliştirici için olan IAM politikası, iam:CreateRole ve iam:PutRolePolicy eylemleri üzerinde "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary" gibi bir koşul içerir. Bu, self-servis imkanı sunmaya devam ederken ayrıcalık yükseltmesini (privilege escalation) önler.

Sık karşılaşılan bir yanılgı, grup üyeliğinin veya eklenen ek politikaların bir sınırı veya SCP’yi “geçersiz kılabileceği” yönündedir. Kılamazlar — sınır ve SCP tavanlardır, tabanlar değil.

Koşullar Aracılığıyla MFA Zorlaması

İki koşul anahtarı (condition key) MFA politikasını yönlendirir: aws:MultiFactorAuthPresent (Boolean, oturum MFA kullanılarak elde edildiyse true) ve aws:MultiFactorAuthAge (sayısal, MFA doğrulamasından bu yana geçen saniye). Hassas API’ler için MFA’yı zorunlu kılmak ve oturum ömrünü sınırlamak şöyle görünür:

{
  "Effect": "Allow",
  "Action": ["rds:DeleteDBInstance", "kms:ScheduleKeyDeletion"],
  "Resource": "*",
  "Condition": {
    "Bool":            { "aws:MultiFactorAuthPresent": "true" },
    "NumericLessThan": { "aws:MultiFactorAuthAge": "7200" }
  }
}

İki saat 7.200 saniyedir. Bool yerine BoolIfExists kullanmak, bu anahtarı asla taşımayan hizmet prensipali (service-principal) çağrıları için ustaca bir tehlike oluşturur — bu durumda ifade ’true’ olarak değerlendirilir ve bu çağrılar için denetimi etkili bir şekilde atlar. Bu nedenle, amaç insan kullanıcı zorlaması olduğunda Bool tercih edilmelidir.

Uzun süreli erişim anahtarları kullanan CLI ve SDK istekleri MFA bağlamı taşımadığı için, kullanıcıların MFA bağlamını içeren geçici kimlik bilgilerini elde etmek üzere önce sts:GetSessionToken (--serial-number ve --token-code ile) veya sts:AssumeRole (--serial-number/--token-code ile) komutunu çağırmaları gerekir. Bu kısa ömürlü kimlik bilgileri daha sonra MultiFactorAuthPresent koşulunu karşılar:

aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 7200

IAM Identity Center ve Federasyon

IAM Identity Center (eski adıyla AWS SSO), bir AWS Organization genelinde iş gücü erişimini merkezileştirir. İzin setleri, bir kullanıcı veya grup atandığında Identity Center’ın her bir hedef hesap içinde IAM rolleri olarak somutlaştırdığı şablonlardır. Atamalar üç şeyi birbirine bağlar: bir principal (Identity Center dizininden veya Okta/Entra ID gibi harici bir IdP’den bir kullanıcı veya grup), bir izin seti ve bir veya daha fazla hesap.

İzin setleri, AWS tarafından yönetilen ilkeleri, müşteri tarafından yönetilen ilkeleri (her hedef hesapta bulunmaları gerektiği için adlarıyla referans verilir), satır içi ilkeleri ve bir izin sınırını taşıyabilir. Bir izin setini düzenlediğinizde, Identity Center temelindeki rolleri yeniden sağlar — bu rolleri asla doğrudan düzenlemezsiniz.

Identity Center dışındaki SAML federasyonu için AWS, iddianın (assertion) imzasını IAM SAML sağlayıcı nesnesine kaydedilmiş IdP meta verilerine göre doğrular. IdP imzalama sertifikasını rotasyona uğrattığında, güncellenmiş meta veri XML’ini yüklemek gerekir; aksi takdirde STS, InvalidIdentityToken / Response Signature Invalid hatası döndürür. Meta verileri aws iam update-saml-provider --saml-metadata-document file://metadata.xml --saml-provider-arn ... komutuyla güncellemek, en az ek yük getiren çözümdür — sağlayıcıyı yeniden oluşturmaya veya güven ilişkilerini yeniden yapılandırmaya gerek yoktur.

Kök Hesap, Kimlik Bilgisi Raporları ve En Az Ayrıcalık

Kök kullanıcı, kaldırılamayan tam erişime sahiptir ve bir “break-glass” (acil durum) kimliği olarak ele alınmalıdır: donanım veya sanal bir MFA cihazı etkinleştirin, tüm kök erişim anahtarlarını silin, günlük işler için kullanmayın ve kimlik bilgilerini çevrimdışı saklayın. Üye hesaplardaki yöneticilerin bile GuardDuty’yi devre dışı bırakmasını, CloudTrail’i silmesini veya belirli bölgelerden ayrılmasını önlemek için kuruluş kökünde veya OU düzeyinde SCP’ler kullanın. SCP’ler asla izin vermez — yalnızca üye hesaptaki IAM’in verebileceği izinleri filtrelerler.

En az ayrıcalık ilkesi, sezgiler yerine araçlarla operasyonel hale getirilir. Kullanılmayan kullanıcıları, eskiyen erişim anahtarlarını ve MFA’sı olmayan kullanıcıları bulmak için IAM kimlik bilgisi raporunu (aws iam generate-credential-report ve ardından get-credential-report) oluşturun. Hesaplar arası veri sızdıran kaynak ilkelerini belirlemek ve CloudTrail etkinliğinden doğru boyutlandırılmış ilkeler oluşturmak için IAM Access Analyzer‘ı kullanın. Rollerden kullanılmayan hizmet izinlerini temizlemek için son erişim verilerini (aws iam get-service-last-accessed-details) kullanın.

Açıkça belirtilmesi gereken son bir tuzak: bir kimliğe İzin (Allow) eklemenin yeterli olduğunu varsaymak. Bir KMS anahtar ilkesi rolünüzü adlandırmıyorsa, bir SCP eylemi reddediyorsa veya bir izin sınırı bunu kapsamıyorsa, çağrı yine de başarısız olur. AccessDenied sorununu giderirken her zaman tüm yığını — SCP, sınır, kimlik ilkesi, kaynak ilkesi ve oturum ilkesi — denetleyin.

Pratik Problem: Kullanım Senaryosu

Senaryo: Meridian Financial, yönetim, üretim ve geliştirme iş yükleri için üç hesaplı bir AWS Organization işletmektedir ve hassas alım-satım ve müşteri verileri üretim (prod) hesabında bulunmaktadır. Şu anda eski, uzun ömürlü IAM kullanıcıları, yüklenici hesapları ve bir Okta SAML kimlik sağlayıcısının bir karışımına sahipler; bu durum tutarsız erişim kontrollerine ve hesaplar arasında dağınık rol yapılandırmalarına neden olmaktadır.

Zorluk: Yakın zamanda yaşanan bir olayda, bir yüklenicinin ele geçirilen kimlik bilgileri, MFA olmadan hesaplar arası bir rol üstlenmiş ve izin sınırları veya merkezi izin setleri olmadığı için aşırı yetkili eylemler gerçekleştirmiştir. Meridian’ın federasyonu, rol güvenini sağlamlaştırması ve hesaplar genelinde MFA ile en az ayrıcalık ilkesini zorunlu kılması gerekmektedir.

Önerilen Yaklaşım:

1. Okta SAML ile entegre edilmiş AWS IAM Identity Center’ı tek bir birleşik kimlik düzlemi olarak dağıtın ve tüm insan kullanıcıları ve yüklenicileri uzun ömürlü IAM kullanıcılarından Identity Center tabanlı hesaplara taşıyın, eski IAM kullanıcıları için konsol/anahtar erişimini devre dışı bırakın.
2. IAM Identity Center’da üye hesaplardaki IAM rollerine eşlenen merkezi izin setleri oluşturun ve tüm roller için IAM izin sınırları (IAM ilkeleri olarak tanımlanır) uygulayın; bu sınırları ve rol şablonlarını AWS CloudFormation StackSets kullanarak hesaplar arasında dağıtın.
3. Hesaplar arası rol güven ilkelerini, yalnızca Identity Center principal ARN’lerinden sts:AssumeRole’e izin verecek şekilde güncelleyin ve MFA gerektiren (ör. aws:MultiFactorAuthPresent) koşulları ve kaynak hesap kısıtlamalarını ekleyin; oturum etiketlerinin kimlik niteliklerini taşımasını zorunlu kılın.
4. IdP’de (Okta) MFA’yı zorunlu kılın ve bu zorunluluğu rol oturumlarında MFA koşulları talep ederek AWS’e yansıtın; AWS Organizations’da Hizmet Kontrol İlkeleri (SCP’ler) uygulayarak konsol erişimi veya yeni IAM kullanıcısı oluşturulmasını engelleyin.
5. Sürekli izleme ve ilke doğrulaması için AWS CloudTrail, AWS Config ve IAM Access Analyzer’ı etkinleştirin ve bulguları uyarı ve otomatik düzeltme iş akışları için CloudWatch/GuardDuty’ye gönderin.

Gerekçe: Federasyonu IAM Identity Center aracılığıyla merkezileştirmek, izin setleri ve sınırlarla en az ayrıcalık ilkesini uygulamak, güven ilkelerinde MFA’yı zorunlu kılmak ve kuruluş düzeyinde SCP’ler ile izleme uygulamak, etki alanını (blast radius) azaltmak, ayrıcalık yükseltmeyi önlemek ve denetlenebilirlik sağlamak için AWS en iyi uygulamalarıyla uyumludur.

IAM Rolleri ve Güven Politikaları: PassRole ve AssumeRole

Bir IAM rolünün iki ayrı politika yüzeyi vardır ve bunları karıştırmak, hesaplar arası yetkilendirme hatalarının çoğunun temel nedenidir. Güven politikası (AssumeRolePolicyDocument), rolü kimin ve hangi koşullar altında üstlenebileceği sorusunu yanıtlar. İzin politikası ise rol üstlenildikten sonra neler yapabileceğini yanıtlar. Her ikisi de eyleme izin vermelidir; güven politikası tek başına S3, KMS veya başka herhangi bir şeye erişim izni vermez.

Bir principal sts:AssumeRole çağrısı yaptığında, STS hedef rolün güven politikasını, çağıran kimliğe ve oturum bağlamına (kaynak IP, MFA durumu, oturum etiketleri, harici ID) göre değerlendirir. Çağıran principal’ın ayrıca o rolün ARN’si üzerinde sts:AssumeRole için kimlik tabanlı bir Allow iznine sahip olması gerekir. Bu ikili gereklilik, rol üstlenmeyi hesap sınırları boyunca güvenli kılan şeydir.

MFA ve harici bir ID gerektiren standart bir hesaplar arası güven politikası şu şekildedir:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" },
      "StringEquals": { "sts:ExternalId": "unique-partner-id-8842" }
    }
  }]
}

aws:MultiFactorAuthPresent anahtarı yalnızca üstlenilebilir bir rolün güven politikasında anlamlıdır, çünkü MFA bağlamı sonraki hizmet çağrılarında değil, STS çağrısı sırasında oluşturulur. S3 bucket politikasına veya rolün izin politikasına MFA koşulları eklemek sık yapılan bir hatadır: asıl kullanıcı MFA ile kimlik doğrulaması yapmış olsa bile, üstlenilen rol oturumu genellikle aws:MultiFactorAuthPresent=true değerini taşımaz, bu nedenle bu koşullar sessizce her şeyi reddeder. MFA’yı rol üstlenme anında zorunlu kılın; uzun ömürlü oturumlar için yeniden kimlik doğrulamayı zorlamak amacıyla aws:MultiFactorAuthAge kullanın.

PassRole, sınav senaryolarında zorluk çıkaran ikinci engeldir. CloudFormation, EC2, Lambda veya CodeBuild gibi bir hizmete bir rol olarak çalışmasını söylediğinizde, çağıran kimliğin `iam:PassRole

Pratik Problem: Kullanım Senaryosu

Senaryo: Meridian Financial, üretim, geliştirme ve CI/CD araçları için ayrı hesaplara sahip çoklu hesaplı bir AWS Organization yapısı işletmektedir. Hesaplar arası dağıtımlar için merkezi IAM rolleri ve altyapı değişiklikleri yapmak üzere rol üstlenen üçüncü taraf CI aracıları kullanmaktadırlar.

Zorluk: Yakın zamanda yapılan bir denetim, aşırı geniş bir iam:PassRole izninin bir CI/CD principal’ının bir EC2 instance profile’ına Administrator rolünü geçirmesine olanak tanıdığını ve bir saldırganın, hesaplar arasında aşırı ayrıcalıklar elde etmek için bir AssumeRole güven ilişkisinden yararlandığını ortaya çıkardı.

Önerilen Yaklaşım:

1. Yakın zamandaki iam:PassRole ve sts:AssumeRole API çağrılarını belirlemek için AWS CloudTrail ve Amazon EventBridge’i kullanın ve hangi principal’ların hangi Rol ARN’lerini ne zaman geçirdiğini listelemek için CloudTrail Lake veya Athena’da sorgular çalıştırın.
2. Kaynak tabanlı güven politikası açıklarını keşfetmek ve Organization dışından veya harici principal’lar tarafından üstlenilebilen rolleri listelemek için hesaplar genelinde IAM Access Analyzer’ı (IAM için) çalıştırın.
3. Geniş kapsamlı iam:PassRole politikalarını, Resource bölümünde belirli Rol ARN’lerini belirten en az ayrıcalık ilkesine uygun IAM politikalarıyla değiştirin ve rolü kimin ve neyin alabileceğini sınırlamak için aws:PassedToService veya aws:PrincipalOrgID gibi koşul anahtarları ekleyin.
4. Bilinmeyen principal’lar tarafından geniş kapsamlı AssumeRole kullanımını önlemek için rol güven politikalarını koşul gerektirecek şekilde sıkılaştırın—aws:PrincipalOrgID kullanın, üçüncü taraflar için sts:ExternalId kullanın, aws:SourceIdentity gerektirin ve maksimum oturum sürelerini zorunlu kılın.
5. iam:PassRole ve AssumeRole anormalliklerini tespit etmek için Amazon EventBridge kuralları yapılandırın, Amazon SNS’e uyarılar gönderin ve aşırı geniş politikaları iptal etmek veya düzeltmek için otomatik Lambda playbook’ları oluşturun ve sürekli uyumluluk için bulguları AWS Security Hub ve AWS Config’e kaydedin.

Gerekçe: Bu yaklaşım, PassRole hedeflerini ve güven politikalarını sıkılaştırarak en az ayrıcalık ve derinlemesine savunma ilkelerini uygular. Aynı zamanda, IAM ve federasyon için AWS en iyi uygulamalarıyla uyumlu olarak, loglama ve izleme yoluyla tespit ve otomatik düzeltmeyi mümkün kılar.

Tüm alanlar · Tehdit Tespiti ve Uyarı →

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

Amazon'a göz atın →