AWS Paylaşılan Sorumluluk Modeli kapsamında AWS, "Bulutun Güvenliğini" (fiziksel veri merkezleri, ana bilgisayar donanımı, hipervizörler) yönetirken; müşteri, "Bulut İçi Güvenlik"—özellikle kimlik yönetimi, kimlik bilgisi hijyeni ve erişim kontrolü—konusunda bölünmez sorumluluğu taşır. Kısıtlanmamış bir AWS Root hesabının veya ayrıcalıklı bir IAM kimlik bilgisinin ele geçirilmesi, saldırganların yasadışı GPU kripto madenciliği örnekleri için binlerce dolar harcamasına, özel S3 veri göllerini sızdırmasına veya yıkıcı fidye silme işlemleri gerçekleştirmesine olanak tanır.
MFA, tüm yönetim konsolu kullanıcıları için zorunludur ve AWS Root hesabı için tartışılamaz bir gerekliliktir.
AWS, tek hata noktalarını ortadan kaldırmak için hesap başına 8 adede kadar farklı FIDO2 ve sanal TOTP belirtecinin kaydedilmesine izin verir.
Genel IAM koşullu reddetme politikası, etkin MFA doğrulaması sağlanana kadar tüm yetkisiz API çağrılarını engeller.
Bulut Uyumluluk Temelleri: CIS Benchmark ve Düzenleyici Çerçeveler
Mühendislik organizasyonunuz ister SOC 2 Type II onayını, ister ISO 27001 sertifikasını, ister PCI DSS 4.0 doğrulamasını hedeflesin veya AWS Well-Architected Güvenlik Sütunu ile uyum sağlasın, IAM kimlikleri genelinde MFA uygulaması temel bir zorunlu gereksinimdir:
| Standart / Uyumluluk Standardı | Kontrol Belirtimi | Önem Derecesi / Zorunluluk | Denetim Doğrulama Mekanizması |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | Seviye 1 (Zorunlu) | AWS Security Hub / Prowler otomatik değerlendirmesi |
| PCI DSS 4.0 | Gereksinim 8.4.2 | Zorunlu | Kart Sahibi Veri Ortamı (CDE) konsol ve API denetimi |
| SOC 2 Type II (Güven Kriterleri) | CC6.1 / CC6.2 | Temel Kontrol | IAM Kimlik Bilgisi Raporlarının bağımsız CPA denetimi |
| AWS Zorunlu MFA Yayılımı | AWS 2024–2026 Politikası | Platform Zorunluluğu | MFA kaydı tamamlanana kadar Root giriş ağ geçidi engellemesi |
AWS Root Hesabını Güvene Almanın Mutlak Zorunluluğu
Bir AWS hesap sınırı içinde Root hesabı, başlangıçta oluşturulan mutlak yetkili kimliği temsil eder. IAM rollerinin veya kullanıcılarının aksine, Root hesabının eylemleri bağımsız hesaplarda IAM kimlik tabanlı politikalarıyla veya Hizmet Kontrol Politikalarıyla (SCP) sınırlandırılamaz.
Güvenliği İhlal Edilmiş Bir Root Hesabının Yıkıcı Etki Alanı:
- Geri Alınamaz Hesap Kapatma: Tehdit aktörleri "Hesabı Kapat" butonuna tıklayarak kalıcı altyapı imhasını planlayabilir.
- Faturalandırma ve Finansal Ele Geçirme: Faturaların yönünü değiştirme, kurumsal ödeme kartlarını değiştirme ve yasadışı kripto para madenciliği için 30'dan fazla AWS bölgesinde yüzlerce GPU spot örneği dağıtma.
- AWS Organizations Yapısını Parçalama: Üye hesapları yönetim ağacından çıkararak kurumsal uyumluluk izlemesini devre dışı bırakma.
- Birincil Güvenlik İletişim Bilgilerini Değiştirme: Root e-posta ve telefon kayıtlarının değiştirilmesi, resmi AWS destek müdahale kanallarını kalıcı olarak keser.
- Sıfır Root Access Keys: Root hesabı için erişim anahtarlarının bulunmadığını doğrulamak amacıyla IAM Kimlik Bilgisi Raporlarını denetleyin. Varsa derhal silin.
- Çift Gözetimli Parola Kasası: 32'den fazla karakterden oluşan rastgele bir parola oluşturun, parolayı CISO ile Genel Hukuk Müşaviri arasında bölün ve parçaları fiziksel yanmaz kasalarda kilitleyin.
- Çoklu Cihaz Yedekliliği (8 Cihaza Kadar): En az iki fiziksel FIDO2 donanım anahtarı (YubiKey) ve çevrimdışı, soğuk depolanan bir Sanal TOTP yedek cihazı kaydedin.
MFA Seçim Matrisi: Sanal TOTP ve Donanım FIDO2 (YubiKey)
AWS üç temel MFA cihaz sınıfını destekler. Bulut mimarları, tehdit modellerine ve yönetimsel ayrıcalık düzeylerine göre seçim yapmalıdır:
Sanal TOTP Uygulamaları
Standart RFC 6238 belirteçleri (Google Authenticator, 1Password, 2FA-Tool). Hızlı kurulum, donanım tedarik engeli yok. Standart geliştiriciler için idealdir.
YubiKey 5 Serisi
Oltalama Dirençli (Phishing-Resistant) kriptografi. Alan adına bağlı genel anahtar onayları, ters proxy oltalama kitlerini boşa çıkarır. Root ve Yöneticiler için zorunludur.
Gemalto / Thales Kartları
LCD ekranlı, kendi piliyle çalışan, hava boşluklu (air-gapped) TOTP kartı. Akıllı telefon ve USB anahtarların yasak olduğu yüksek güvenlikli tesisler (SCIF) için gereklidir.
Kurumsal Donanım MFA FIPS 140-2 Level 3 ve Çift Gözetimli Kasa Protokolleri:
Fortune 500 şirketleri ve savunma yüklenicileri için Root hesabı güvenliği, FIPS 140-2 Level 3 altında onaylanmış özel donanım anahtarlıklarını (ör. SafeNet/Gemalto IDPrime fobs) zorunlu kılar. Akıllı telefon uygulamalarının aksine bu fiziksel anahtarlıklar kablosuz arabirimlere veya bluetooth vericilerine sahip değildir ve mobil casus yazılımlarla ele geçirilemez.
Fiziksel Çift Gözetim Yönetişimi: Kurumsal veri merkezi protokollerinde Root erişimi iki ayrı kişi gerektirir: bir yetkili ana e-posta kimlik bilgilerini elinde tutarken, bağımsız bir güvenlik görevlisi Root donanım belirtecini içeren kasanın fiziksel anahtarına sahiptir. Hiçbir taraf AWS Root hesabına tek taraflı erişemez.
IAM Politikalarıyla MFA Zorunluluğu (JSON Uygulaması)
Güvenlik temelleri çalışanların gönüllü eylemlerine bırakılamaz. Bulut yönetişimi politika düzeyinde zorunluluk gerektirir: etkin MFA doğrulaması bulunmayan kullanıcıların, kendi MFA cihazlarını kaydetme yeteneği hariç, tüm AWS API ve Konsol işlemleri sistematik olarak engellenmelidir.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:ListVirtualMFADevices"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:DeleteVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/${aws:username}"
},
{
"Sid": "AllowManageOwnUserMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "BlockAllAccessUnlessMFAAuthenticated",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"iam:GetUser"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
4. İfade, genel koşul anahtarı olan "aws:MultiFactorAuthPresent": "false" değerini açık bir Deny ile değerlendirir. Açık Reddetme kuralı tüm İzin Verme ifadelerini geçersiz kıldığından, MFA kullanılmayan oturumlar tüm AWS API'lerinde anında engellenir ve kullanıcı doğrudan cihaz kayıt ekranına yönlendirilir.
AWS CLI ve SDK MFA Kimlik Doğrulaması: STS Geçici Oturum Belirteçleri
IAM politikaları MFA'yı zorunlu kıldığında, aws s3 ls gibi komutları çalıştıran veya Terraform kodu yürüten geliştiriciler AccessDenied hatalarıyla karşılaşır. Uzun vadeli erişim anahtarları etkileşimli olarak OTP isteyemez.
Mühendisler, uzun vadeli anahtarları + 6 haneli TOTP kodunu geçici kimlik bilgileriyle takas etmek için AWS STS (Security Token Service) kullanmalıdır:
Otomasyon Komut Dosyası (aws-mfa-session.sh):
Belirteç edinimini otomatikleştirmek için bu yardımcı betiği yerel ortamınıza (~/.aws/aws-mfa-session.sh) yerleştirin:
# Exchange AWS Long-Term Keys + MFA Code for STS Session Token
MFA_ARN="arn:aws:iam::123456789012:mfa/alex-dev"
echo -n "Enter 6-digit 2FA OTP Code: "
read -r TOKEN_CODE
SESSION_JSON=$(aws sts get-session-token \
--serial-number "$MFA_ARN" \
--token-code "$TOKEN_CODE" \
--duration-seconds 43200 \
--output json)
if [ $? -eq 0 ]; then
export AWS_ACCESS_KEY_ID=$(echo "$SESSION_JSON" | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo "$SESSION_JSON" | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo "$SESSION_JSON" | jq -r '.Credentials.SessionToken')
echo "✅ Authenticated! Temporary session exported (Valid for 12 hours)."
else
echo "❌ Authentication failed. Check token code or device time drift."
fi
MFA Kısıtlamalarıyla Hesaplar Arası AssumeRole
Kurumsal çok hesaplı mimarilerde ayrıcalıklı mühendisler genellikle merkezi bir Kimlik hesabında kimlik doğrulaması yapar ve sts:AssumeRole aracılığıyla hedef hesaplara (Üretim, Hazırlık) geçiş yapar. Sızdırılan kimlik bilgileriyle yükseltilmiş üretim izinlerinin ele geçirilmesini önlemek için, üretim rolünün güven ilişkisi mutlaka bir MFA koşulu içermelidir:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Bu mimari model, saldırgan merkezi Kimlik hesabındaki kimlik bilgilerini ele geçirse bile, MFA doğrulaması olmadan hedef rolü üstlenmeye çalıştığında güvenlik belirteci sınırında derhal bir AccessDenied hatası tetikler.
CloudTrail Denetimi ve EventBridge Gerçek Zamanlı Uyarıları
Otomatik uyumluluk doğrulaması, herhangi bir kullanıcı çok faktörlü kimlik doğrulaması olmadan AWS Yönetim Konsolu'na eriştiğinde anında tespit gerektirir. AWS CloudTrail olaylarını yakalayarak ve bunları Amazon EventBridge üzerinden yönlendirerek SecOps ekipleri gerçek zamanlı uyarılar elde eder:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
Olay alındığında EventBridge, Güvenlik Operasyonları Merkezi (SOC) nöbetçi çağrı cihazına bir Amazon SNS bildirimi tetikler veya etkin IAM kullanıcı oturumunu anında iptal eden bir AWS Lambda işlevini çağırır.
Çok Hesaplı Yönetişim: AWS Organizations ve IAM Identity Center
Açılış Alanları (Landing Zones) genelinde onlarca veya yüzlerce AWS hesabını yöneten kurumsal ortamlarda, her hesapta bağımsız IAM kullanıcıları oluşturmak hatalı bir mimari yaklaşımdır (anti-pattern).
Merkezi Kimlik Birleşimi (Federation):
Belirlenen Yönetim Hesabınızda AWS IAM Identity Center (eski adıyla AWS SSO) uygulayın. Kurumsal IdP'ler (Okta, Microsoft Entra ID, PingFederate) ile kimlikleri birleştirin. IdP katmanında kurumsal MFA'yı zorunlu kılarken, üye hesap root işlemlerini engellemek için Kuruluş köküne Hizmet Kontrol Politikaları (SCP) ekleyin:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
Üretim Düzeyinde SCP: Tüm Üye Hesaplarda MFA Kısıtlamalarını Zorunlu Kılma
Büyük kuruluşlarda bireysel hesap yöneticileri yanlışlıkla aşırı ayrıcalıklar tanıyabilir. Bulut yönetişim ekibi, Kuruluş Kökü veya Kuruluş Birimi (OU) düzeyinde bir Hizmet Kontrol Politikası (SCP) ekleyerek sarsılmaz bir güvenlik kalkanı oluşturur: Yüksek etkili API çağrıları, etkin bir MFA oturumuyla yetkilendirilmedikçe koşulsuz olarak reddedilir:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCriticalActionsWithoutMFA",
"Effect": "Deny",
"Action": [
"iam:CreateAccessKey",
"iam:CreateLoginProfile",
"s3:DeleteBucket",
"kms:ScheduleKeyDeletion",
"ec2:TerminateInstances"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
Rol Zincirleme ve STS Belirteç Ömrü Kısıtlamaları:
IAM kimlikleri ara rolleri üstlendiğinde ve ardından ikincil rolleri üstlendiğinde ("rol zincirleme"), AWS STS orijinal aws:MultiFactorAuthPresent bağlamını sonraki oturum belirtecinden çıkarır! Hesaplar arası işlem hatlarında uçtan uca sıkı uyumluluğu sürdürmek için, birden fazla ara IAM rolünü zincirlemek yerine doğrudan kimliği doğrulanmış IAM Identity Center oturumundan rol üstlenme grafikleri tasarlayın.
Felaket Kurtarma: Kayıp Root MFA Cihaz Protokolü
Kayıtlı tüm Root MFA donanım belirteçleri ve sanal cihazları bir felakette imha olursa ne olur?
Resmi Bant Dışı Kurtarma Sırası:
- Root Girişini Başlatın: AWS Konsolunda Root hesabı e-postasını ve ana parolasını girin.
- MFA Sorununu Giderin: MFA isteminde "Troubleshoot MFA" bağlantısına tıklayın.
- Birincil E-posta Doğrulaması: AWS, birincil Root e-posta adresine zaman sınırlı bir doğrulama bağlantısı gönderir. E-posta sınamasını onaylayın.
- Otomatik Sesli Arama Doğrulaması: "Call me now" butonuna tıklayın. Otomatik AWS doğrulama sistemi kayıtlı birincil hesap telefon numarasını arar ve 6 haneli bir onay PIN'i okur.
Kuruluşunuz telefon numaralarını değiştirdiyse veya ilgili kişi AWS Hesap Ayarlarını güncellemeden işten ayrıldıysa, otomatik kurtarma başarısız olur. Manuel çözüm, kurumsal noter tasdikli tescil belgelerinin AWS Güven ve Güvenlik birimine sunulmasını gerektirir ve inceleme süresi 3–7 iş günü sürer.
Kurumsal Bulut Mimarı SSS
AWS Root MFA belirteçleri bir DevOps ekibi arasında paylaşılabilir mi? ▼
Kesinlikle yasaktır. Root MFA kimlik bilgilerinin paylaşılması tüm uyumluluk denetimlerinde (SOC 2, ISO 27001) başarısızlığa neden olur. Rutin yönetim, bireysel hesap verebilirlik sağlayan IAM Identity Center rolleri üzerinden yürütülmelidir. Root kimlik bilgileri, yalnızca felaket anındaki acil durumlar için fiziksel çift gözetimli kasalarda kilitli tutulmalıdır.
aws:MultiFactorAuthAge koşul anahtarı güvenliği nasıl artırır? ▼
Bu anahtar oturum tazeliğini zorunlu kılar. "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} yapılandırması, MFA belirtecinin son 3.600 saniye (1 saat) içinde girilmiş olmasını gerektirir. Oturum daha eskiyse yüksek riskli işlemler (ör. RDS kümelerini sonlandırma) engellenir ve uzun ömürlü oturum ele geçirmelerine karşı koruma sağlanır.
AWS Sanal MFA sağlamak için 2FA-Tool çevrimiçi kimlik doğrulayıcısını kullanabilir miyim? ▼
Evet. AWS Sanal MFA, RFC 6238 TOTP belirtimlerine (HMAC-SHA1, 30 saniyelik aralık, 6 hane) sıkı bir şekilde uyar. Kayıt için gerekli olan iki ardışık kimlik doğrulama kodunu doğrudan tarayıcınızda %100 yerel olarak üretmek için Base32 gizli anahtarını 2FA-Tool.com adresine girebilirsiniz.
Kurumsal TOTP Belirteçlerini Güvenle Test Edin
W3C Web Crypto API ile standart RFC 6238 TOTP doğrulama kodlarını anında oluşturun. Sunucu çağrısı yok, mutlak bellek yalıtımı, sıfır sızıntı.