Amazon SCS-C02: Yönetişim, Yapılandırma ve Otomasyon — Ç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.

Service Control Policy’ler ve Organizasyon Düzeyinde Koruma Mekanizmaları

Service Control Policy’ler (SCP’ler), bir AWS Organization içindeki herhangi bir principal’ın yapabileceklerinin en dış sınırını oluşturur. Bir SCP, bir IAM politikası değildir — hiçbir şey vermez, yalnızca bir OU (Organizational Unit) altındaki veya tüm organizasyondaki hesaplar için mevcut olan maksimum izinleri tanımlar. Bir IAM politikasında, kaynak politikasında veya izin sınırında (permissions boundary) yer alan bir Allow ifadesi, eğer bir SCP eylemi reddediyorsa tamamen etkisizdir. Bu asimetri, SCP’lerin organizasyon çapında koruma mekanizmaları (guardrails) için doğru araç olmasının nedenidir: Bölge (Region) kısıtlamaları, yasaklanmış servisler, merkezi olarak yönetilen IAM rollerinin korunması ve kaynak oluşturma sırasında şifrelemenin zorunlu kılınması.

Şifrelenmemiş DynamoDB tablolarının ve S3 bucket’larının oluşturulmasını reddeden standart bir SCP şöyle görünür:

Version: "2012-10-17"
Statement:
  - Sid: DenyUnencryptedS3
    Effect: Deny
    Action: s3:CreateBucket
    Resource: "*"
    Condition:
      StringNotEquals:
        s3:x-amz-server-side-encryption-aws-kms-key-id: !Ref CmkArn
  - Sid: DenyUnencryptedDdb
    Effect: Deny
    Action: dynamodb:CreateTable
    Resource: "*"
    Condition:
      "Null":
        dynamodb:SSESpecificationEnabled: "true"

Sık düşülen bir tuzak, “organizasyondaki hiç kimse us-east-2’yi kullanamaz” veya “hiç kimse CloudTrail’i devre dışı bırakamaz” gibi kuralları her hesaba eklenmiş IAM politikaları aracılığıyla zorlamaya çalışmaktır. Bir izin sınırı (permissions boundary) ve kimlik politikası uyumu olsa bile, yerel bir yönetici kendisine bir kaçış yolu sağlayabilir. Yalnızca kök (root) veya OU düzeyinde uygulanan bir SCP’ye güvenilebilir, çünkü bu, üye hesapların root kullanıcısını bile kısıtlar (kısıtlanamayan bir avuç eylemin dar istisnası dışında).

SCP’ler ayrıca acil durum (break-glass) ve delege edilmiş yönetim rollerini de korumalıdır: OrganizationAccountAccessRole veya SecurityAudit gibi bir rolü hedefleyen herhangi bir eylem için, çağıranın aws:PrincipalArn değeri onaylanmış bir listeyle eşleşmediği sürece açık bir Deny ekleyin.

AWS Config, Uygunluk Paketleri ve Çoklu Hesapta Uygulama

AWS Config, SCP’leri (önleyen) tamamlayan sürekli değerlendirme katmanını, tespit (sapmayı gözlemleyen ve raporlayan) ile sağlar. Bir uygunluk paketi (conformance pack), hem s3-bucket-server-side-encryption-enabled gibi yönetilen kuralları hem de Lambda veya Guard tarafından desteklenen özel kuralları içeren bir Config kuralları demetidir ve isteğe bağlı düzeltme eylemleriyle birlikte tek bir dağıtılabilir YAML yapıtı olarak paketlenir.

Standart bir temel çizgiyi organizasyon çapında yaymak için iki mekanizma birleştirilir:

• Yönetim hesabından (management account) CloudFormation StackSets kullanımı: Servis tarafından yönetilen izinler (service-managed permissions) ve AutoDeployment: Enabled ayarı ile, organizasyona katılan her yeni hesabın Config kaydedicisini (recorder) ve teslimat kanalını (delivery channel) açan bir stack’i otomatik olarak alması sağlanır. Bu, başlangıç (bootstrap) sorununu çözer: bir uygunluk paketi, Config’in etkinleştirilmediği bir hesabı değerlendiremez.

• Delege edilmiş yönetici hesabından (delegated administrator account) dağıtılan uygunluk paketleri (örneğin security-01), PutOrganizationConformancePack kullanılarak. Bu, her bir hesaba manuel olarak dokunmaya gerek kalmadan, mevcut ve gelecekteki tüm hesaplara tutarlı bir kural setini yayar.

Delege edilmiş yönetici + toplayıcı (aggregator) modeli önemlidir: bu model, güvenlik ekibinin tüm hesapların uyumluluğunu tek bir yerden görmesine olanak tanırken, uygulama ekiplerinin yerel olarak kendi kurallarını eklemesine de izin verir. Aynı kuralları doğrudan yönetim hesabından dağıtmak işe yarasa da, en az ayrıcalık (least privilege) ilkesini ihlal eder ve görevler ayrılığı (separation-of-duties) denetimlerini engeller.

CloudFormation Guard, StackSets ve Service Catalog

Önleme, sürecin daha erken aşamalarına kaydırılmalıdır (shift left). CloudFormation Guard (cfn-guard), CloudFormation şablonlarını (veya herhangi bir JSON/YAML’ı) ayrıştıran ve dağıtımdan önce bildirimsel (declarative) kurallara göre değerlendiren bir kod olarak politika (policy-as-code) motorudur. Bir Guard kuralı şöyle görünür:

rule s3_encrypted {
  Resources.*[ Type == "AWS::S3::Bucket" ] {
    Properties.BucketEncryption exists
    Properties.BucketEncryption.ServerSideEncryptionConfiguration[*] {
      ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
    }
  }
}

Bunu bir CI/CD aşamasına bağlamak — genellikle cfn-guard validate -r rules.guard -d template.yaml komutunu çalıştıran bir Docker container adımı olarak — uyumsuz herhangi bir kaynak oluşturulmadan önce pipeline’ın başarısız olmasına neden olur. İhlal durumunda pipeline, güvenlik ekibinin abone olduğu bir SNS konusuna (topic) yayın yapar, bu da onlara manuel bir onay darboğazı haline gelmeden görünürlük sağlar. Güvenlik ekibini bilgilendirmek için yalnızca StackSets’e veya CloudFormation değişiklik seti (change-set) incelemesine güvenmek bir tuzaktır: her iki servis de kaynak başına uyumluluk bulguları yayınlamaz ve bir stack oluşturulduğunda kaynak zaten hesapta mevcuttur.

Service Catalog, son aşamada (last mile) Guard’ı tamamlar. Geliştiricilerin rastgele CloudFormation yazmasına izin vermek yerine, platform ekibi onaylanmış ürünleri (VPC temelleri, RDS kalıpları, EKS kümeleri) AWS RAM aracılığıyla hesaplar arasında paylaşılan Service Catalog portfolyoları olarak yayınlar. Geliştiriciler bunları kısıtlanmış parametrelerle başlatır ve bir başlatma kısıtlaması (launch constraint) IAM rolü, geliştiricinin kişisel olarak sahip olmadığı yükseltilmiş izinlerle kaynakları sağlar. Bu, temelindeki şablonun Guard kontrollerinden zaten geçtiği, denetlenebilir, self-servis bir dağıtım modeli sunar.

StackSets’in kendisi doğru bir altyapı kurulumu gerektirir: organizasyon yönetim hesabından dağıtım yaparken SERVICE_MANAGED izin modelini kullanın, Organizations’da CloudFormation için güvenilir erişimi (trusted access) etkinleştirin ve yürütme rollerini (execution roles) dikkatlice yapılandırın. AdministrationRoleARN/ExecutionRoleName çifti (kendi kendine yönetilen modda - self-managed mode) veya servis bağlantılı roller (servis tarafından yönetilen modda - service-managed mode), kaynakları fiilen oluşturan CloudFormation servis rolüne iam:PassRole iznine sahip olmalıdır. Bir CloudFormation servis rolü eklemeyi unutup bunun yerine dağıtımı yapan kullanıcının kimlik bilgilerine güvenmek, iam:PassRole üzerinde aralıklı AccessDenied hatalarına yol açar — bu, başarısız StackSet operasyonlarının yaygın bir nedenidir. Doğru model, her stack için yalnızca beyan edilen kaynak türlerini oluşturmak için gereken izinlere sahip, adanmış bir servis rolü kullanmaktır.

Otomatik Düzeltme İş Hatları

Config, uyumsuzluk tespit ettiğinde, güvenli bir şekilde kendi kendini onarabilecek her şey için düzeltme otomatik olmalıdır. Olay akışı şöyledir:

• Config, varsayılan olay veriyoluna (event bus) bir Compliance Change olayı yayınlar.

• Bir EventBridge kuralı, belirli kurallardaki NON_COMPLIANT bulguları için filtreleme yapar ve ya bir Systems Manager Automation dokümanını (S3 şifrelemesini etkinleştirmek gibi basit, idempotent düzeltmeler için), bir Lambda fonksiyonunu (API seviyesindeki düzeltmeler için) ya da bir Step Functions durum makinesini (onaylar, yeniden denemeler veya hizmetler arası orkestrasyon gerektiren çok adımlı iş akışları için) hedefler.

Örneğin, s3-bucket-public-read-prohibited kuralı tetiklenirse, bir SSM Automation runbook’u olan AWS-DisableS3BucketPublicReadWrite bunu düzeltir. Daha karmaşık akışlar için — örneğin, zamanla değişen ve sahip ekibe bildirimde bulunularak yeniden düzenlenmesi gereken bir KMS anahtar politikası — Step Functions koordinasyonu sağlar: mevcut politikayı oku, “golden” (ideal) sürümle karşılaştır, kms:PutKeyPolicy çağrısı yap, ardından SNS’e gönder. Düzeltme mantığını tek bir Lambda yerine Step Functions’ta saklamak, her adıma yönelik gözlemlenebilirlik ve temiz yeniden deneme semantiği sağlar.

IAM Access Analyzer ve Politika Doğrulama

IAM Access Analyzer iki farklı soruyu yanıtlar. İlk olarak, harici erişim analizörleri (external access analyzers), politikaları tanımlanmış bir güven bölgesi — hesap veya organizasyon — dışındaki principal’lara erişim izni veren kaynakları (S3, KMS, IAM rolleri, Lambda, SQS, Secrets Manager) tanımlar. Bulguların merkezi olarak toplanması için analizörü, delege edilmiş yönetici hesabından organizasyon seviyesinde etkinleştirin.

İkinci olarak, Access Analyzer politika doğrulama (policy validation) ve politika oluşturma (policy generation) özellikleri yazım sırasında çalışır. aws accessanalyzer validate-policy komutu güvenlik uyarıları, hatalar ve öneriler döndürür (örneğin, hassas eylemlerle birleştirilmiş çok geniş kapsamlı Resource: "*" gibi durumları işaretler). CloudFormation’a gömülü IAM politikalarının dağıtımdan önce kontrol edilmesi için bunu cfn-guard ile aynı CI/CD aşamasına entegre edin. Access Analyzer ayrıca CloudTrail geçmişinden en az ayrıcalık (least-privilege) ilkesine uygun bir politika oluşturabilir; bu, joker karakterli bir politikayı bir rolün gerçekte kullandığı eylemlerle değiştirir. Bu, “veri erişimi için en az ayrıcalığı zorunlu kıl” ilkesinin mekanik yanıtıdır ve kms:ViaService koşulları aracılığıyla çağıran hizmet S3, DynamoDB, Lambda veya EKS olduğunda yalnızca kms:Decrypt izni veren kapsamlı bir KMS anahtar politikasıyla birlikte kullanılır.

Pratik Problem: Kullanım Senaryosu

Senaryo: Meridian Financial, üretim, hazırlık (staging), deneme (sandbox) ve merkezi bir güvenlik hesabını içeren çoklu hesaplı bir AWS Organization’ı yönetmektedir. İş yüklerini, sandbox ortamında CloudFormation şablonları ve geliştirici odaklı şablonların bir karışımıyla dağıtmaktadırlar; sahiplik ekipler arasında federasyonludur ve veri şifrelemesi ile en az ayrıcalıklı erişim için iç yönetişim kurallarına uymak zorundadırlar.

Zorluk: Sandbox’taki geliştiriciler yanlışlıkla halka açık S3 bucket’ları ve diğer hesaplara yayılan aşırı izinli IAM politikaları oluşturmuşlardır ve güvenlik ekibi, Organizasyon genelinde tutarlı, otomatik bir zorlama ve şablon doğrulama mekanizmasından yoksundur.

Önerilen Yaklaşım:

1. Önleyici koruma sağlamak amacıyla halka açık S3’ü reddetmek, bucket şifrelemesini zorunlu kılmak ve ayrıcalıklı IAM eylemlerini kısıtlamak için Organizasyon kök düzeyinde Servis Kontrol Politikaları (SCP’ler) oluşturun.
2. Merkezi güvenlik hesabından, S3’ün halka açık erişimini, IAM politika ekleme desenlerini ve şifreleme uyumluluğunu sürekli olarak değerlendirmek için CloudFormation StackSets kullanarak her hesaba ve bölgeye bir AWS Config toplayıcısı (aggregator) ve Uygunluk Paketleri (Conformance Packs) dağıtın.
3. Şablonların doğrulanması ve yalnızca uyumlu yığınların (stack) sağlanabilmesi için CloudFormation Guard (cfn-guard) kurallarını CI/CD iş hattına (CodePipeline/CodeBuild) entegre edin ve onaylanmış altyapı için Service Catalog ürünlerinin kullanılmasını zorunlu kılın.
4. Yüksek öncelikli bulgular (halka açık S3’ü otomatik engelleme, aşırı geniş IAM politikalarını düzeltme) için SSM Automation dokümanları veya Lambda runbook’ları ile AWS Config otomatik düzeltmesini etkinleştirin ve EventBridge aracılığıyla ek iş akışlarını tetikleyin.
5. IAM Access Analyzer ve politika doğrulamasını merkezi olarak çalıştırın, bulguları Security Hub’a aktarın ve keşfedilen hesaplar arası veya aşırı izinli politikalar için bilet oluşturma veya düzeltme playbook’larını otomatikleştirin.

Gerekçe: Bu yaklaşım, en az ayrıcalık ilkesini uygulamak ve AWS en iyi pratiklerine göre tutarlı çoklu hesap yönetişimi sağlamak için önleyici organizasyon çapında korumaları (SCP’ler), sürekli tespiti (Config/Conformance Packs), sola kaydırma (shift-left) şablon doğrulamasını (cfn-guard/Service Catalog) ve IAM Access Analyzer ile otomatik düzeltmeyi birleştirir.

AWS Config: Kuruluş Kuralları, Toplayıcılar ve Yetkilendirilmiş Yönetim

AWS Config, AWS üzerindeki tespit edici uyumluluğun temelidir. Kaynak yapılandırmalarını sürekli olarak kaydeder ve bunları AWS tarafından yönetilen (restricted-ssh, vpc-flow-logs-enabled, encrypted-volumes gibi) veya özel (Lambda ya da Guard tarafından desteklenen) kurallara göre değerlendirir. Kurumsal ölçekte, üç mimari karar kuralların kendisinden daha önemlidir: kuralların nasıl dağıtıldığı, bulguların nasıl toplandığı ve araçların sahipliğinin kimde olduğu.

AWS Organizations altındaki çoklu hesap, çoklu Bölge dağıtımları için doğru desen, aws organizations register-delegated-administrator --service-principal=config-multiaccountsetup.amazonaws.com aracılığıyla bir yetkilendirilmiş yönetici hesabı (genellikle yönetim hesabı değil, güvenlik veya denetim hesabı) belirlemektir. Bu hesaptan, kuralları her bir üye hesaba ve Bölge’ye dağıtmak için PutOrganizationConfigRule veya PutOrganizationConformancePack kullanın. Yetkilendirilmiş yönetimi atlamak, sizi her hesapta Config’i manuel olarak etkinleştirmeye veya her şeyi yönetim hesabından çalıştırmaya zorlar; ikinci seçenek görevler ayrılığını ihlal ederken, ilki birkaç hesaptan fazlası için ölçeklenemez.

Kuruluş kuralları tek bir kural tanımını gönderir; toplayıcılar ise ortaya çıkan değerlendirmeleri toplar. Yetkilendirilmiş yönetici hesabında, tüm hesapları ve Bölgeleri kapsayan bir OrganizationAggregationSource ile bir toplayıcı oluşturun. Toplayıcı panosu daha sonra “200 hesap genelinde hangi VPC’lerde Flow Logs eksik?” gibi soruları, hesaplar arası rollerle uğraşmaya gerek kalmadan yanıtlar. Unutmayın ki toplayıcılar salt okunurdur: uyumluluk durumunu ortaya çıkarırlar ancak kendileri düzeltme yapmazlar.

Taban Çizgisi Uygulaması için Uygunluk Paketleri

Bir uygunluk paketi, Config kurallarını ve bunların düzeltme eylemlerini tek bir YAML şablonunda bir araya getirir. AWS, PCI DSS, HIPAA, NIST 800-53 ve CIS gibi çerçevelerle eşleştirilmiş paketler sunar. Yetkilendirilmiş yöneticiden bir kuruluş uygunluk paketi dağıtmak, belirli OU’ları hedefler; örneğin, Prod OU’suna Sandbox OU’sundan daha katı bir paket uygulamak gibi. Bu, yüzlerce hesapta tutarlı bir taban çizgisini zorunlu kılmanın en verimli yoludur, çünkü tek bir API çağrısı, kural setini ve düzeltme bağlantılarını her yere aynı anda yayar.

Resources:
  EncryptedVolumesRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: encrypted-volumes
      Source:
        Owner: AWS
        SourceIdentifier: ENCRYPTED_VOLUMES
  EncryptedVolumesRemediation:
    Type: AWS::Config::RemediationConfiguration
    Properties:
      ConfigRuleName: encrypted-volumes
      TargetType: SSM_DOCUMENT
      TargetId: AWSConfigRemediation-EncryptS3BucketVolume
      Automatic: true
      MaximumAutomaticAttempts: 3
      RetryAttemptSeconds: 60

Otomatik Düzeltme Desenleri

İki temel düzeltme yolu vardır ve aralarındaki seçim, gecikme ve karmaşıklık gereksinimlerine bağlıdır.

Config’in yerel düzeltme yolu, bir kural NON_COMPLIANT olarak raporladığında bir SSM Otomasyon runbook’unu çağırmak için AWS::Config::RemediationConfiguration kullanır. AWS, AWS-EnableVPCFlowLogs, AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules ve AWSConfigRemediation-EncryptSNSTopic gibi önceden oluşturulmuş runbook’lar sağlar. Bu yol bildirimseldir, uygunluk paketleriyle sorunsuz bir şekilde entegre olur ve birkaç dakikalık bir gecikmenin kabul edilebilir olduğu durumlar için idealdir.

EventBridge güdümlü yol, gecikmenin önemli olduğu veya özel bir orkestrasyon gerektiğinde gereklidir. Config, her durum geçişinde bir Config Rules Compliance Change olayı yayınlar. Bir EventBridge kuralı, detail.newEvaluationResult.complianceType = NON_COMPLIANT ifadesine göre filtreleme yapar ve bir Lambda fonksiyonunu (veya Step Function’ı ya da doğrudan bir SSM runbook’unu) hedefler. EventBridge, değerlendirmeden sonraki saniyeler içinde tetiklendiği için, bir dakikanın altındaki düzeltme pencereleri mümkün hale gelir.

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

Lambda handler’ı daha sonra ihlale neden olan SG üzerinde RevokeSecurityGroupIngress çağrısı yapar. Hangi yolu seçerseniz seçin, otomasyonun hedef kaynağı değiştirmek için minimum izinlere sahip bir IAM rolünü üstlenmesi gerekir. Sık karşılaşılan bir hata senaryosu, düzeltme runbook’unun AccessDenied hatası alması nedeniyle uyumluluk durumunun süresiz olarak NON_COMPLIANT ve COMPLIANT arasında gidip geldiğini gösteren bir Config kuralıdır; Config çağrıyı kaydeder ancak sessizce devam eder. Her zaman SSM Otomasyon yürütme geçmişini inceleyin ve runbook rolüne ihtiyaç duyduğu belirli değişiklik yapma izinlerini verin (örneğin, ec2:CreateFlowLogs, flow-log teslim rolü için iam:PassRole ve logs:CreateLogGroup).

Systems Manager Automation ve Patch Manager

SSM Otomasyon runbook’ları, emredici düzeltmeler için temel araçtır. Bunlar, belirttiğiniz bir IAM rolü tarafından yürütülen adımları (API çağrıları, onaylar, dallanma) açıklayan, sürüm kontrollü YAML/JSON belgeleridir. Config tarafından tetiklenen düzeltmelerin ötesinde, zamanlanmış bakım görevlerini çalıştırırlar: erişim anahtarlarını döndürmek, takılı olmayan EBS birimlerini etiketlemek veya 30 gün sonra durdurulmuş sunucuları sonlandırmak gibi.

Patch Manager, işletim sistemlerini bir yama taban çizgisine (onaylanmış yamalar, sınıflandırmalar ve önem derecesi filtreleri seti) uygun tutan bir SSM alt sistemidir. Sunucular, Patch Group etiketi aracılığıyla yama grupları halinde gruplandırılır; bir bakım penceresi, bu gruplara karşı AWS-RunPatchBaseline belgesini zamanlar. Uyumluluk durumu, işletim sistemi düzeyindeki durum ile kurumsal raporlama arasındaki döngüyü tamamlayarak Config ve Security Hub’a geri akar.

Service Catalog, CloudFormation StackSets ve Önleyici Koruma Rayları

Tespit ve düzeltme reaktif süreçlerdir. Uyumsuzluğu önlemek için önleyici denetimler kullanın:

• Service Catalog, özenle hazırlanmış, parametreli CloudFormation şablonlarını ürün olarak yayınlar. Geliştiriciler, temel hizmetler için IAM izinlerine ihtiyaç duymadan onaylanmış kalıpları (güçlendirilmiş bir VPC, şifrelenmiş bir RDS kümesi) başlatabilir. Bu, platform ekibi ile tüketiciler arasında görevler ayrılığını zorunlu kılar.

• CloudFormation StackSets, hesaplar ve Region’lar arasında aynı stack’leri dağıtır. Hizmet tarafından yönetilen izinler ve OU hedeflemesi ile tek bir operasyon, Config kaydedicilerini, IAM rollerini veya GuardDuty dedektörlerini, otomatik dağıtım yoluyla yeni oluşturulanlar da dahil olmak üzere kuruluştaki her hesaba yerleştirir.

• Service Control Policies (SCPs), kuruluş sınırında bir API çağrısını doğrudan reddedebilen tek mekanizmadır. Config ve SSM, şifrelemesi olmayan bir RunInstances çağrısını engelleyemez; yalnızca sonrasında tespit edip düzeltebilirler. Yalnızca Config kurallarıyla (“asla herkese açık S3 bucket’ı olmasın” gibi) kesin yasaklar uygulamaya çalışmak, kaynak oluşturma ile düzeltme arasında bir zaman aralığı bırakır. Bu açığı kapatmak için bir Config tespit kuralını s3:PutBucketPublicAccessBlock reddi gibi bir SCP ile eşleştirin.

Felaket Kurtarma: Yedekleme, Şablonlar ve Kaynak Kontrolü

RPO/RTO hedeflerini karşılamak, hem verilerin hem de altyapı tanımlarının kurtarılabilir olmasını gerektirir. AWS Backup, EBS, RDS, DynamoDB, EFS ve FSx genelindeki yedekleme politikalarını merkezileştirir; kuruluş yedekleme politikaları, üye hesaplar arasında planları uygular ve Region’lar arası, hesaplar arası kopyalar, Region kaybına ve hesabın ele geçirilmesine karşı koruma sağlar. RPO, yedekleme sıklığı ile belirlenir; RTO ise geri yükleme mekaniklerine bağlıdır (bir DynamoDB PITR geri yüklemesi dakikalar sürerken, Region’lar arası bir RDS anlık görüntüsü geri yüklemesi bir saat sürebilir).

Altyapı kurtarma, tek doğruluk kaynağı olarak CodeCommit’te (veya başka bir Git sağlayıcısında) saklanan CloudFormation şablonlarına dayanır. Sürüm kontrollü şablonlardan bir StackSet’i yeniden dağıtmak, bir kurtarma Region’ında VPC’leri, IAM’i ve uygulama stack’lerini dakikalar içinde yeniden oluşturur. Şablonları yalnızca konsolda tutmak - bir repo olmadan - RTO’yu öngörülemez hale getirir çünkü tekrarlanabilir bir yapıt yoktur.

Tuzak Analizi

Üç yanlış kanı sürekli olarak yanlış cevaplara yol açar. Birincisi, Config’i önleyici bir denetim olarak görmek: Config, CloudTrail değişikliği kaydettikten sonra değerlendirme yapar, bu nedenle gerçek yasaklar SCP’leri gerektirir. İkincisi, yeterli kapsama sahip bir IAM rolü olmadan düzeltme mekanizması kurmak — SSM dokümanı mevcuttur ve Config kuralı tetiklenir, ancak runbook izin hataları nedeniyle sessizce başarısız olur. Üçüncüsü, kuruluş çapındaki hizmetleri, yetkilendirilmiş bir yönetici kaydetmek yerine yönetim hesabından çalıştırmak; bu durum, hesap başına manuel etkinleştirmeyi zorunlu kılar ve kuruluş çapındaki toplayıcıların doğru çalışmasını engeller.

Pratik Problem: Kullanım Senaryosu

Senaryo: Meridian Financial, AWS Organizations altında ayrı üretim, geliştirme ve güvenlik hesaplarına sahip çoklu hesaplı bir AWS ortamı işletmektedir. Güvenlik ekibi, yüzlerce EC2 örneğini, S3 bucket’ını ve Lambda fonksiyonunu bölgeler arasında yönetirken, iç denetimlere ve düzenleyicilere karşı sürekli uyumluluğu kanıtlamalıdır.

Zorluk: Yakın zamanda yapılan bir denetimde yamalanmamış EC2 örnekleri, herkese açık S3 bucket’ları ve hesaplar arasında tutarsız temel standart uygulaması tespit edilmiştir; düzeltme manuel ve yavaştır ve önleyici denetimler tek tip uygulanmamaktadır.

Önerilen Yaklaşım:

1. Güvenlik hesabını AWS Config yetkilendirilmiş yöneticisi olarak belirleyin ve tüm hesaplardan ve bölgelerden yapılandırma ve uyumluluk verilerini toplamak için CloudFormation StackSets aracılığıyla bir AWS Config Aggregator dağıtın.
2. Temel denetimleri (S3 genel erişimi, şifreleme, etiketleme) kod haline getirmek için güvenlik hesabından (StackSets kullanarak) kuruluş düzeyinde AWS Config Conformance Pack’ler dağıtın, böylece aynı kurallar tutarlı bir şekilde uygulanır.
3. İhlallerin otomatik olarak SSM Automation veya Run Command ile düzeltilmesini tetiklemesi için, AWS Systems Manager Automation dokümanlarını (düzeltme runbook’ları olarak kaydedilmiş) çağıran yüksek riskli kurallara AWS Config otomatik düzeltme eylemleri ekleyin.
4. Yama gruplarını tanımlamak ve hesaplar arasında işletim sistemi yamalamasını otomatikleştirmek için AWS Systems Manager Patch Manager’ı SSM Patch Baselines ve State Manager ile kullanın; yama uyumluluk sonuçlarını Config Aggregator’a aktarın.
5. Onaylanmış CloudFormation şablonlarını AWS Service Catalog’da yayınlayın ve uyumlu stack’leri dağıtmak veya güncellemek için CloudFormation StackSets kullanın; izin verilmeyen kaynak oluşturmayı (örneğin, herkese açık S3 bucket’ı oluşturmayı devre dışı bırakmak) engellemek için AWS Organizations Service Control Policies ile önleyici koruma rayları uygulayın.
6. Uyumsuzluk durumunda güvenlik ekibini bilgilendirmek ve karmaşık olaylar için ek SSM Automation iş akışlarını tetiklemek üzere Amazon EventBridge (CloudWatch Events) ve SNS’i yapılandırın.

Gerekçe: Tespiti Config Aggregator ve conformance pack’ler ile merkezileştirmek, SSM aracılığıyla düzeltmeyi otomatikleştirmek ve Service Catalog/StackSets ve SCP’ler aracılığıyla önleyici koruma raylarını uygulamak; güvenlik, uyumluluk ve en az ayrıcalık için AWS en iyi uygulamalarıyla uyumlu, tutarlı, denetlenebilir kontroller ve hızlı düzeltme sağlar.

← Uç ve Uygulama Güvenliği · Tüm alanlar · Güvenlik Açığı →

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

Amazon'a göz atın →