AWS Control Tower Çoklu Hesap Stratejisi: Landing Zone'dan Kurumsal Governance'a

AWS Control Tower, iyi governance'a sahip bir çoklu hesap AWS ortamının temelini oluşturur. Bu yazı, OU yapısı tasarımı, koruma mekanizması seçimi, Account Factory otomasyonu ve hesaplar arası erişim kalıpları için pratik karar verme süreçlerini ele alır. AWS dokümantasyonunu tekrarlamak yerine, hangi yaklaşımın ne zaman kullanılacağına ve pratik ödünleşimlere odaklanır.

AWS Control Tower Landing Zone 4.0 ve AFT v1.18.x'e göre son doğrulama: Mart 2026. AWS servisleri hızla gelişir; en son değişiklikler için her zaman resmi dokümantasyonu kontrol et.

Çoklu Hesap Stratejisi Neden Önemli#

Tek bir AWS hesabıyla başlamak küçük takımlar için gayet iyi çalışır. Sorunlar organizasyon büyüdükçe ortaya çıkar. Governance'ı olan bir çoklu hesap stratejisi olmadan genellikle şunlar yaşanır:

• Güvenlik dağınıklığı: Takımlar herhangi bir temel kontrol olmadan gelişigüzel hesap oluşturur. Şifrelenmemiş S3 bucket'ları, herkese açık kaynaklar ve eksik CloudTrail logları standart hale gelir.
• Uyumluluk kayması: Manuel koruma mekanizmaları zamanla bozulur. Kontroller devre dışı bırakılır, yapılandırmalar değiştirilir ve denetim zamanına kadar kimse fark etmez.
• Erişim yönetimi kaosu: Hesaplara dağılmış IAM kullanıcıları, paylaşılan root kimlik bilgileri, merkezi kimlik yönetimi yok.
• Maliyet atıf körlüğü: Düzinelerce hesap genelinde hangi takımın, projenin veya ortamın maliyetleri artırdığına dair görünürlük yok.
• Yavaş hesap sağlama: Yeni bir proje için hesap mı lazım? Manuel kurulum, güvenlik incelemesi ve yapılandırma haftalar sürer.
• Tutarsız ortamlar: Dev, staging ve prod hesapları farklı yapılandırılmış, bu da yalnızca production'da ortaya çıkan deployment sorunlarına yol açar.

Çoklu hesap stratejisi, iş yüklerini izole ederek, organizasyon düzeyinde koruma mekanizmaları uygulayarak ve hesap sağlamayı otomatikleştirerek bu sorunları çözer. Control Tower, üzerine inşa edebileceğin iyi mimarili bir temel sağlar.

Organizasyonel Birim (OU) Yapısı Tasarımı#

OU yapısı governance modelinin omurgasıdır. OU'ları organizasyon şemasına göre değil, politika sınırlarına göre tasarla (hangi kontrollerin nerede uygulanacağı).

Önerilen OU Hiyerarşisi#

Control Tower geleneksel olarak Log Archive ve Audit hesaplarıyla birlikte Security OU'yu otomatik olarak oluşturur. Landing Zone 4.0'dan (2025 sonu) itibaren bu artık zorunlu değil; hub hesapları (Log Archive, Audit) aynı üst OU'da olduğu sürece tamamen özel OU yapıları tanımlayabilirsin. Security OU yeni kurulumlar için hâlâ varsayılan ve yaygın olarak kullanılan bir kalıptır. Geri kalanını governance ihtiyaçlarına göre sen eklersin.

Note: Landing Zone 3.x'ten yükseltme yapıyorsan, Security OU geçişi otomatik değildir. OU yapısında değişiklik yapmadan önce Landing Zone 4.0 geçiş rehberini incele. Mevcut özel OU'lar artık yeniden yapılandırma olmadan doğrudan hub OU hedefleri olarak belirlenebilir.

Düz vs İç İçe OU'lar#

AWS 5 seviyeye kadar iç içe geçmeyi destekler, ancak pratikte 2-3 seviye maksimum olarak kabul edilir. Daha derin iç içe geçme, SCP kalıtımını anlamayı ve hata ayıklamayı zorlaştırır.

İç içe OU kullan:

• Tek bir OU'da 20'den fazla hesap varsa
• Farklı ortamlar (prod/staging/dev) farklı politika sınırları gerektiriyorsa
• SCP'leri yalnızca iş yükü düzeyinde değil, ortam düzeyinde uygulamak istiyorsan

Düz tut:

• Organizasyonun toplamda 30'dan az hesaba sahipse
• Tüm ortamlar aynı governance gereksinimlerini paylaşıyorsa
• Daha basit SCP kalıtımı istiyorsan

Temel Tasarım Kararları#

Control Tower'ın otomatik oluşturmadığı ek OU'lar için CDK örneği:

import * as organizations from 'aws-cdk-lib/aws-organizations';
// Control Tower varsayılan olarak Security OU'yu oluşturur (2025'ten itibaren opsiyonel).// Bunlar IaC ile yönettiğin ek OU'lar.
const infraOU = new organizations.CfnOrganizationalUnit(this, 'InfraOU', {  name: 'Infrastructure',  parentId: rootId,  tags: [{ key: 'ManagedBy', value: 'control-tower' }],});
const workloadsOU = new organizations.CfnOrganizationalUnit(this, 'WorkloadsOU', {  name: 'Workloads',  parentId: rootId,});
// Ortam ayrımı için iç içe OU'larconst prodOU = new organizations.CfnOrganizationalUnit(this, 'ProdOU', {  name: 'Production',  parentId: workloadsOU.attrId,});
const stagingOU = new organizations.CfnOrganizationalUnit(this, 'StagingOU', {  name: 'Staging',  parentId: workloadsOU.attrId,});
const devOU = new organizations.CfnOrganizationalUnit(this, 'DevOU', {  name: 'Development',  parentId: workloadsOU.attrId,});
const suspendedOU = new organizations.CfnOrganizationalUnit(this, 'SuspendedOU', {  name: 'Suspended',  parentId: rootId,});

Service Control Policy'leri (SCP'ler)#

SCP'ler birincil koruma mekanizmasıdır. Bir OU içindeki hesaplara sunulan maksimum izinleri tanımlar. Derinlemesine savunma için SCP'leri farklı OU seviyelerinde katmanla.

SCP Katmanlama Stratejisi#

Region Kısıtlama#

Region kısıtlama, kullanmadığın bölgelerde yanlışlıkla kaynak oluşturulmasını önler. Bu, veri yerleşimi uyumluluğu için gereklidir.

Warning: Control Tower'ın kendi region deny kontrolü var. Control Tower'ın yerleşik region deny'ını kullanıyorsan özel region deny SCP'si oluşturma. Çakışabilirler. Bunun yerine Control Tower'ın yapılandırılabilir region deny kontrolünü kullan.

Control Tower dışında özel bir region deny'a ihtiyacın varsa, kalıp şu şekilde. Önce Control Tower'ın yerleşik yapılandırılabilir region deny kontrolünü tercih et; yalnızca yerleşik kontrolün desteklemediği daha ince taneli istisnalara ihtiyacın varsa özel SCP kullan:

{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "DenyNonApprovedRegions",      "Effect": "Deny",      "NotAction": [        "iam:*",        "organizations:*",        "sts:*",        "support:*",        "billing:*",        "budgets:*",        "health:*",        "trustedadvisor:*"      ],      "Resource": "*",      "Condition": {        "StringNotEquals": {          "aws:RequestedRegion": [            "eu-central-1",            "eu-west-1",            "us-east-1"          ]        }      }    }  ]}

NotAction listesine dikkat et. IAM, Organizations ve STS gibi global servisler, bölgesel sınırlar dışında çalıştıkları için hariç tutulmalıdır.

Güvenlik Servislerini Koruma#

Bu SCP, Control Tower yürütme rolleri dışında herkesin CloudTrail'i değiştirmesini engeller:

{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "PreventCloudTrailModification",      "Effect": "Deny",      "Action": [        "cloudtrail:StopLogging",        "cloudtrail:DeleteTrail",        "cloudtrail:UpdateTrail",        "cloudtrail:PutEventSelectors"      ],      "Resource": "*",      "Condition": {        "StringNotLike": {          "aws:PrincipalArn": [            "arn:aws:iam::*:role/AWSControlTowerExecution",            "arn:aws:iam::*:role/stacksets-exec-*"          ]        }      }    }  ]}

AWS Config, GuardDuty ve Security Hub için de benzer kalıplar uygula. Prensip aynı: denetim izini governance otomasyonu dışındaki herkesin değişikliğinden koru.

SCP'ler vs RCP'ler vs Declarative Policy'ler#

Politika ekosistemi, Resource Control Policy'ler (RCP'ler) ve Declarative Policy'ler ile önemli ölçüde genişledi. Her biri farklı bir amaca hizmet eder.

Karar Çerçevesi#

Karşılaştırma Matrisi#

Pratikte: SCP'leri geniş izin sınırları için kullan. RCP'leri veri çevresi uygulaması için kullan; özellikle harici hesaplara veri sızmasını önlemek amacıyla. Mevcut olduğunda declarative policy'leri tercih et; deny ifadelerinin karmaşıklığı olmadan yapılandırmayı zorunlu kılar.

Note: Declarative policy'ler şu anda EC2 ile ilgili servisler içindeki belirli yapılandırmalarla sınırlıdır: VPC Block Public Access, EBS Snapshot Block Public Access, EC2 AMI herkese açık paylaşım kısıtlamaları ve benzeri öznitelik düzeyinde kontroller. Diğer servisler gelecekte desteklenecek şekilde planlanmıştır.

Tip: AWS, kullanım alanın için bir declarative policy mevcutsa bunu SCP yerine kullanmanı önerir. Declarative policy'ler yönetimi daha kolaydır ve istenmeyen erişim engellemelerine neden olma olasılıkları daha düşüktür.

Account Factory for Terraform (AFT)#

AFT, GitOps odaklı iş akışlarıyla hesap sağlamayı otomatikleştirir. Organizasyonun Terraform kullanıyorsa, AFT hesap yaşam döngüsü yönetimi için production düzeyinde bir seçimdir.

AFT Mimarisi#

Modül Kurulumu#

module "aft" {  source = "github.com/aws-ia/terraform-aws-control_tower_account_factory"
  # Control Tower yonetim hesabi  ct_management_account_id    = "111111111111"  log_archive_account_id      = "222222222222"  audit_account_id            = "333333333333"  aft_management_account_id   = "444444444444"
  # Terraform dagilimi  terraform_distribution = "oss"  # veya Terraform Cloud icin "tfc"  terraform_version      = "1.9.8"  # AFT >=1.6.0 gerektirir; en son uyumlu surum icin AFT GitHub deposunu kontrol et
  # VCS yapilandirmasi  vcs_provider = "github"
  # Maliyet optimizasyonu: gerekli degilse VPC'yi devre disi birak  aft_enable_vpc = false  # NAT Gateway maliyetinden ~$32/ay tasarruf
  # Ozellik bayraklari  aft_feature_cloudtrail_data_events      = false  aft_feature_enterprise_support          = false  aft_feature_delete_default_vpcs_enabled = true
  tags = {    ManagedBy   = "aft"    Environment = "management"  }}

Note: AFT, Control Tower yönetim hesabından ayrı, kendine ait bir yönetim hesabı gerektirir. Bu ek hesap ve altyapı maliyetleri (~$32-50/ay) için bütçe ayır.

Hesap İstekleri#

Hesap istekleri, bir Git deposunda saklanan Terraform modülleridir. Her modül, parametreleri ve etiketleriyle bir hesap tanımlar:

module "product_a_production" {  source = "./modules/aft-account-request"
  control_tower_parameters = {    AccountEmail              = "[email protected]"    AccountName               = "product-a-production"    ManagedOrganizationalUnit = "Workloads/Production"    SSOUserEmail              = "[email protected]"    SSOUserFirstName          = "Cloud"    SSOUserLastName           = "Admin"  }
  account_tags = {    Environment = "production"    Product     = "product-a"    CostCenter  = "eng-product-a"    ManagedBy   = "aft"  }
  account_customizations_name = "production-baseline"
  change_management_parameters = {    change_requested_by = "platform-team"    change_reason       = "New production account for Product A"  }}

Hesap Özelleştirmeleri#

Hesap özelleştirmeleri, her yeni hesaba temel yapılandırma uygular. Güvenlik varsayılanlarını zorunlu kıldığın yer burasıdır:

# account-customizations/production-baseline/terraform/main.tf
# Varsayilan olarak EBS sifrelemeyi zorunlu kilresource "aws_ebs_encryption_by_default" "enabled" {  enabled = true}
# Hesaplar arasi CI/CD erisimi icin standart IAM rolleri olusturresource "aws_iam_role" "deployment_role" {  name = "deployment-role"  assume_role_policy = jsonencode({    Version = "2012-10-17"    Statement = [{      Effect = "Allow"      Principal = {        AWS = "arn:aws:iam::${var.cicd_account_id}:role/pipeline-role"      }      Action = "sts:AssumeRole"      Condition = {        StringEquals = {          "aws:PrincipalOrgID" = var.org_id        }      }    }]  })}
# GuardDuty'yi etkinlestir (delegated admin merkezi olarak yonetir,# ancak yerel olarak devre disi birakilmadigindan emin ol)resource "aws_guardduty_detector" "main" {  enable = true}
# Kullanim disi datasources blogu yerine ayri feature kaynaklari kullanresource "aws_guardduty_detector_feature" "s3_logs" {  detector_id = aws_guardduty_detector.main.id  name        = "S3_DATA_EVENTS"  status      = "ENABLED"}
resource "aws_guardduty_detector_feature" "eks_audit" {  detector_id = aws_guardduty_detector.main.id  name        = "EKS_AUDIT_LOGS"  status      = "ENABLED"}
resource "aws_guardduty_detector_feature" "malware" {  detector_id = aws_guardduty_detector.main.id  name        = "EBS_MALWARE_PROTECTION"  status      = "ENABLED"}

AFT vs Native Account Factory#

IAM Identity Center Hesaplar Arası Erişim#

IAM Identity Center (eski adıyla AWS SSO), hesaplara ve OU'lara eşlenen izin kümeleriyle merkezi iş gücü kimliği sağlar. Her hesapta IAM kullanıcıları oluşturma kalıbının yerini alır.

İzin Kümesi Tasarımı#

İzin kümelerini roller (Admin, PowerUser, ReadOnly) ve fonksiyonlar (DBA, SecurityAudit) etrafında tasarla. En az yetki ilkesine göre hesaplara eşle.

Geliştiricilere gizli bilgi erişimi olmadan production görünürlüğü sağlayan salt okunur izin kümesi için CDK örneği:

import * as sso from 'aws-cdk-lib/aws-sso';
const devProdReadOnly = new sso.CfnPermissionSet(this, 'DevProdReadOnly', {  instanceArn: ssoInstanceArn,  name: 'DeveloperProductionReadOnly',  description: 'Read-only access for developers in production accounts',  sessionDuration: 'PT4H', // Production icin 4 saatlik oturumlar  managedPolicies: [    'arn:aws:iam::aws:policy/ReadOnlyAccess',  ],  inlinePolicy: {    Version: '2012-10-17',    Statement: [      {        Sid: 'AllowCloudWatchInsights',        Effect: 'Allow',        Action: [          'logs:StartQuery',          'logs:GetQueryResults',          'logs:StopQuery',          'cloudwatch:GetMetricData',          'xray:GetTraceSummaries',        ],        Resource: '*',      },      {        Sid: 'DenySecretsAccess',        Effect: 'Deny',        Action: [          'secretsmanager:GetSecretValue',          'ssm:GetParameter*',        ],        Resource: '*',      },    ],  },});
// Gelistirici grubunu production hesaplarina atanew sso.CfnAssignment(this, 'DevProdAssignment', {  instanceArn: ssoInstanceArn,  permissionSetArn: devProdReadOnly.attrPermissionSetArn,  principalId: developerGroupId,  principalType: 'GROUP',  targetId: prodAccountId,  targetType: 'AWS_ACCOUNT',});

Erişim Kalıpları#

Oturum süresi stratejisi: Production için daha kısa oturumlar (4 saat), development için daha uzun oturumlar (8 saat) kullan. Bu, production kimlik bilgilerinin maruz kalma penceresini azaltır.

Harici IdP ile federasyon: Organizasyonun Okta, Microsoft Entra ID veya Google Workspace kullanıyorsa, ayrı bir dizin yönetmek yerine IAM Identity Center ile federasyon kur. Bu, kimlik için tek bir doğruluk kaynağı sağlar. SAML federasyonunda attribute mapping'i dikkatli yapılandır; IdP tarafındaki grup isimleri AWS'deki permission set eşlemelerini doğrudan etkiler.

SCIM ile otomatik provisioning: Harici IdP kullanıyorsan SCIM provisioning'i mutlaka etkinleştir. Entra ID veya Okta'dan bir kullanıcı devre dışı bırakıldığında, SCIM aracılığıyla IAM Identity Center'daki erişimi otomatik olarak kaldırılır. SCIM olmadan, IdP'den çıkarılan kullanıcıların AWS erişimi manüel temizlenene kadar açık kalır.

MFA enforcement stratejisi: MFA'yı IdP tarafında mı yoksa AWS tarafında mı zorunlu kılacağını belirle. Harici IdP kullanıyorsan MFA'yı IdP'de enforce etmek daha mantıklıdır; Entra ID'nin Conditional Access'i veya Okta'nın authentication policy'leri cihaz uyumluluğu, konum bazlı kısıtlama ve risk tabanlı MFA gibi daha granüler kontroller sunar. AWS tarafında MFA zorlamak ise çift katmanlı güvenlik sağlar ama kullanıcı deneyimini olumsuz etkiler.

Geçici yükseltilmiş erişim (just-in-time access): IAM Identity Center'ın temporary elevated access özelliğiyle geliştiricilere production'a sınırlı süreli erişim ver. Kalıcı admin erişimi yerine, onay iş akışıyla tetiklenen ve otomatik süresi dolan permission set assignment'ları kullan. Bu, "her zaman açık" erişimin riskini önemli ölçüde azaltır.

Break-glass erişimi: Donanım MFA ile güvence altına alınmış, özel bir acil durum admin rolü oluştur. Kimlik bilgilerini fiziksel bir kasada veya secrets vault'unda sakla. Break-glass prosedürünü üç ayda bir test et. Test edilmemiş acil erişim, erişim yokluğu demektir. Harici IdP kullanıyorsan bu daha da kritiktir; IdP kesintisinde AWS'ye erişimin tamamen kesilmemesi için break-glass rolleri IdP'den bağımsız olmalıdır.

IAM Access Analyzer: Hesaplar arası erişimi doğrulamak ve istenmeyen izinleri bulmak için Access Analyzer kullan. Organizasyonun dışında paylaşılan kaynakları tanımlayabilir, bu da çoklu hesap yapısında özellikle değerlidir.

Warning: Harici IdP kullanmak tek bir dış bağımlılık noktası oluşturur. IdP kesintisi durumunda hiçbir kullanıcı AWS'ye erişemez. Break-glass erişimini IdP'den bağımsız tut, SCIM senkronizasyon hatalarını izle ve IdP failover senaryolarını dokümante et.

Merkezi Loglama ve Güvenlik Mimarisi#

Control Tower varsayılan olarak merkezi bir loglama mimarisi kurar. Log Archive hesabı CloudTrail loglarını alır ve Audit hesabı güvenlik bulgularını toplar.

Temel mimari kararlar:

• Organizasyon düzeyinde CloudTrail trail: Yönetim hesabında tek bir trail, loglar Log Archive'da merkezileştirilmiş. Bu, hesap başına trail'lerin yerini alır ve önemli depolama maliyeti tasarrufu sağlar.
• Delegated admin: Audit hesabını Security Hub, GuardDuty ve Config için delegated admin olarak kullan. Yönetim hesabını temiz tut.
• S3 bucket policy'leri: Log Archive'da, erişimi yalnızca organizasyonunla kısıtlamak için aws:SourceOrgID koşulunu kullan.
• Log saklama: Zaman içinde depolama maliyetlerini optimize etmek için arşivlenmiş loglar için S3 Intelligent-Tiering kullan.
• Otomatik düzeltme: Herkese açık S3 bucket'ları veya açık güvenlik grupları gibi yaygın bulgular için Lambda fonksiyonlarını tetikleyen EventBridge kuralları kur.

Tip: Hesap düzeyinde trail'lerin VE organizasyon trail'inin varsa, yinelenen log depolama maliyeti ödersin. Hesap düzeyinde özel veri olaylarına ihtiyacın yoksa, organizasyon trail'ini etkinleştirdikten sonra hesap düzeyindeki trail'leri kaldır.

Kontrol Türleri: Preventive, Detective, Proactive#

Control Tower üç tür kontrol sunar. Her biri governance yaşam döngüsünde farklı bir amaca hizmet eder.

Uygulama Stratejisi#

Kontrollerin devreye alınması aşamalı bir yaklaşım gerektirir. Preventive kontrolleri test etmeden production'da etkinleştirmek kesintilere davetiye çıkarır.

Aşama 1: Zorunlu kontroller (otomatik). Control Tower bunları varsayılan olarak etkinleştirir. Devre dışı bırakma. Örnekler: CloudTrail etkin, log archive bucket şifrelemesi, Config etkin.

Aşama 2: Kesinlikle önerilen kontroller. Önce Production OU'da etkinleştir, sonra genişlet. Bunlar çoğunlukla detective kontrollerdir; ihlalleri işaretler ama engellemez. Örnekler: S3 bucket şifreleme, RDS şifreleme, EBS şifreleme.

Aşama 3: Özel preventive kontroller. Workloads'a uygulamadan önce Sandbox OU'da test et. Mevcut hesaplarda preventive kontrolleri etkinleştirmeden önce her zaman bilgilendir. Örnekler: region deny, root hesap kullanımını engelle, dev'de instance tiplerini kısıtla.

Aşama 4: Proactive kontroller. Kaynak sağlanmadan önce doğrulayan CloudFormation hook'ları. Sınırlama: yalnızca CloudFormation ile deploy edilen kaynaklar için çalışır (konsol, CLI veya Terraform değil). Tam kapsama için detective kontrollerle eşleştir.

Warning: Proactive kontroller yalnızca CloudFormation ile çalışır. Takımın Terraform kullanıyorsa veya CLI ile deploy ediyorsa, proactive kontroller bu kaynakları yakalamaz. Güvenlik ağı olarak detective kontrollere ihtiyacın var.

Hesaplar Arası Maliyet Yönetimi#

Governance'ın bir maliyeti var. Bunu anlamak, uygun bütçe ayırmana ve sürprizlerden kaçınmana yardımcı olur.

Governance Maliyetleri#

Control Tower'ın doğrudan bir ücreti yok. Maliyet altta yatan servislerden gelir:

Maliyet optimizasyon ipuçları:

• Mümkün olduğunda hesap başına kurallar yerine organizasyon düzeyinde Config conformance pack'leri kullan
• AFT'nin VPC erişimine ihtiyacı yoksa NAT Gateway maliyetinden tasarruf etmek için aft_enable_vpc = false ayarla
• Organizasyon trail'ini etkinleştirdikten sonra yinelenen hesap düzeyindeki CloudTrail trail'lerini kaldır
• Log archive bucket'ları için S3 Intelligent-Tiering kullan

Maliyet Etiketlerini Zorunlu Kılma#

Bu SCP, gerekli CostCenter etiketi olmadan kaynak oluşturmayı engeller. Her kaynağın bir takıma atfedilmesini sağlar:

{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "RequireCostAllocationTags",      "Effect": "Deny",      "Action": [        "ec2:RunInstances",        "rds:CreateDBInstance",        "lambda:CreateFunction",        "ecs:CreateCluster"      ],      "Resource": "*",      "Condition": {        "Null": {          "aws:RequestTag/CostCenter": "true"        }      }    }  ]}

Bunu hesap başına ve OU başına AWS Budgets ile eşleştir. Sandbox hesapları için agresif bütçe sınırları koy ve SCP'ler aracılığıyla pahalı servis türlerini kısıtla.

Yaygın Tuzaklar ve Çıkarılan Dersler#

Control Tower deployment'ları aynı tuzaklara tekrar tekrar düşme eğilimindedir. En çok sorun çıkaranlar şunlar:

1. Control Tower'ın oluşturduğu SCP'leri değiştirme. Control Tower kendi SCP'lerini yönetir. Bunları değiştirmek, kontrollerin "bilinmeyen" duruma girmesine neden olabilir ve landing zone sıfırlaması gerektirebilir. Bunun yerine yeni özel SCP'ler oluştur ve yanlarına ekle.

2. Region deny çakışmaları. Control Tower'ın region deny kontrolü zaten etkinken özel region deny SCP'leri oluşturmak çakışmalara neden olur. Bunun yerine Control Tower'ın yapılandırılabilir region deny kontrolünü kullan.

3. Yönetim hesabı SCP'lerle korunmaz. SCP'ler yönetim hesabına uygulanmaz. Bu hesap yalnızca faturalandırma ve organizasyon yönetimi için kullanılmalı; asla iş yükleri için. IAM policy'leri ve MFA ile kilitle.

4. AFT için VCS sağlayıcı seçimi. CodeCommit kullanılabilir olsa da, birçok ekip daha iyi işbirliği iş akışları için CodeConnections aracılığıyla GitHub, Bitbucket veya GitLab'ı tercih eder. Mevcut araç zincirinle uyumlu VCS sağlayıcısını seç.

5. CloudTrail yinelenen loglama maliyetleri. Hesap düzeyinde trail'ler VE organizasyon trail'i, yinelenen log depolama maliyeti demektir. Organizasyon trail'ini etkinleştirdikten sonra hesap düzeyindeki trail'leri kaldır.

6. Config kural değerlendirme maliyetleri doğrusal olmayan şekilde ölçeklenir. 20'den fazla kontrol etkinleştirilmiş ve hesap başına yüzlerce kaynakla, Config maliyetleri seni şaşırtabilir. Config servisine göre filtrelenmiş Cost Explorer ile izle.

7. Landing zone güncellemeleri tek yönlüdür. Landing zone sürümünü güncelledikten sonra geri dönemezsin. Yükseltmeden önce sürüm notlarını dikkatlice incele.

8. Proactive kontroller yalnızca CloudFormation ile çalışır. Konsol, CLI veya Terraform ile oluşturulan kaynakları yakalamaz. Her zaman detective kontrollerle eşleştir.

9. İç içe OU derinliği vs karmaşıklık. AWS 5 seviye iç içe geçmeyi destekler, ancak pratikte 2-3 seviye maksimum. Daha derin iç içe geçme, SCP kalıtımının hata ayıklamasını zorlaştırır.

10. AFT özel hesabı zorunludur. AFT kendi AWS hesabını gerektirir. Bu ek hesap ve altyapı maliyetleri için bütçe ayır.

Temel Çıkarımlar#

1. Control Tower başlangıç noktasıdır, varış noktası değil. İyi mimarili bir temel sağlar, ancak özel SCP'ler, AFT ve ek kontrollerle kapsamlı özelleştirme yaparsın.

2. OU yapısı governance modelini yansıtır. OU'ları organizasyon şemasına göre değil, politika sınırlarına göre tasarla.

3. SCP'ler, RCP'ler ve declarative policy'ler birbirini tamamlar. Eylem kısıtlamaları için SCP'leri, kaynak erişim sınırları için RCP'leri, servis yapılandırma uygulaması için declarative policy'leri kullan.

4. AFT, Terraform takımları için production düzeyinde bir seçimdir. Organizasyonun Terraform kullanıyorsa, AFT ölçeklenen GitOps odaklı hesap sağlama sunar.

5. Merkezi loglama tartışmasızdır. Organizasyon düzeyinde CloudTrail, Config toplama ve Security Hub delegasyonu ilk gün öncelikleri olmalıdır.

6. Governance'ın bir maliyeti var. Config, CloudTrail ve S3 depolama için hesap başına $3-10/ay bütçe ayır. Bu, uyumluluğun maliyetidir.

7. Detective kontrollerle başla, preventive'e geç. İhlalleri engellemeden önce işaretle. Bu, organizasyonel destek oluşturur ve aşırı agresif koruma mekanizmalarından kaynaklanan kesintileri önler.

8. Yönetim hesabı kutsaldır. İş yükü yok, minimum erişim, her yerde MFA.

Note: Bu yazıdaki birçok kalıp Landing Zone 3.x davranışını (otomatik oluşturulan Security OU, temel kontroller) varsayar. Landing Zone 4.0+ kullanıyorsan, OU yapısını ve temel kontrol davranışını en son Control Tower sürüm notlarına göre doğrula. Önemli değişiklikler arasında opsiyonel Security OU, güncellenmiş temel kontroller ve yeni özelleştirme seçenekleri yer alır.

Kaynaklar#

• AWS Control Tower Multi-Account Strategy - Control Tower ile çoklu hesap landing zone tasarımı için resmi AWS rehberi
• Organizing Your AWS Environment Using Multiple Accounts - Çoklu hesap stratejisi ve OU tasarımı hakkında kapsamlı AWS teknik raporu
• Recommended OUs and Accounts - Her OU için ayrıntılı gerekçeyle AWS önerilen OU yapısı
• AWS Control Tower Account Factory for Terraform (AFT) - Kurulum, özellikler ve gereksinimleri kapsayan resmi AFT dokümantasyonu
• AFT GitHub Repository - Account Factory for Terraform kaynak kodu ve Terraform modülü
• HashiCorp AFT Tutorial - AFT'yi deploy etme ve kullanma için adım adım rehber
• About Controls in AWS Control Tower - Tüm preventive, detective ve proactive kontroller için referans
• Service Control Policies (SCPs) - Örnekler ve sınırlamalarla resmi SCP dokümantasyonu
• Resource Control Policies (RCPs) - Kaynak düzeyinde politika türü için resmi RCP dokümantasyonu
• SCP Examples GitHub Repository - Yaygın governance senaryoları için AWS tarafından sağlanan örnek SCP deposu
• Centralized Logging and Multiple-Account Security Guardrails - Merkezi loglama mimarisi için AWS kuralcı rehberlik
• AWS Security Maturity Model - Multi-Account Management - Control Tower benimseme için AWS güvenlik olgunluk modeli rehberliği
• Organizing Your Landing Zone with Nested OUs - İç içe OU tasarım kalıpları hakkında AWS blogu
• Introducing Resource Control Policies (RCPs) - Kullanım alanları ve uygulama rehberliği ile RCP'ler hakkında AWS blogu
• AWS Control Tower Controls with Terraform - Terraform ile Control Tower kontrollerini yönetme için AWS örneği
• AWS Control Tower Release Notes - Landing zone versiyon geçmişi ve geçiş rehberliği
• Declarative Policies Supported Attributes - Declarative policy kapsamı ve desteklenen servis yapılandırmaları için resmi dokümantasyon