Giriş
Bulut güvenliği, duvar örmek değil; doğru kapıları doğru kişilere açmaktır. Bulut ihlallerinin %65’i yanlış yapılandırılmış kimlik veya ağ kurallarından kaynaklanıyor. AWS’e adım attığınızda, varsayılan ayarlar hız için optimize edilmiştir; güvenlik için değil. Bu yazıda, AWS’in temel yapı taşlarını bir güvenlik mühendisi gözüyle parçalara ayıracağız. Hesap kök kullanıcısından VPC uç noktalarına kadar, riski nerede aldığınızı ve nasıl kapatacağınızı göreceğiz.
- Bulut ihlallerinin %65’i yanlış IAM veya ağ yapılandırmasından kaynaklanır.
- AWS’de varsayılan erişim her zaman reddedilir; açık izin şarttır.
- SCP’ler yönetim hesabını etkilemez, bu tasarım bilinçli bir güvenlik tercihidir.
- IMDSv2 kullanımı, meta veri sömürü saldırılarını %90 oranında azaltır.
Kök Kullanıcı ve IAM Neden Bulut Güvenliğinin İlk Kalesi?
AWS hesap güvenliği, kök kullanıcıyı kilitlemekle başlar. Yeni açılan hesaplarda MFA varsayılan olarak aktif değildir. Bu durum, e-posta ele geçirildiğinde tüm altyapının riske girmesi anlamına gelir. AWS IAM, “kimin ne yapabileceğini” belirleyen merkezi sinir sistemidir. Sistem, hiçbir kimseye önden güvenmez. Açık bir izin politikası bulunana kadar her istek reddedilir. Bu “varsayılan ret” yaklaşımı, sıfır güven mimarisinin temelidir.
IAM izin değerlendirme mantığı, katı bir hiyerarşi izler. Bir istek geldiğinde, sistem beş kapıdan geçirir. İlk kapıda açık bir yasak varsa, oyun biter. Başka hiçbir izin bunu ezemez. Ardından SCP’ler, kaynak politikaları ve kullanıcı politikaları sırayla kontrol edilir. Tüm kapılar “evet” demeden işlem gerçekleşmez. Bu yapı, yanlışlıkla verilen geniş yetkilerin hasarını sınırlar.
Çoğu ekip, IAM politikalarını “çalışana kadar genişletme” hatasına düşer. Oysa güvenli mimari, tam tersini gerektirir. En dar yetkiyle başlayın. Logları izleyin. Yalnızca kanıtlanmış ihtiyaçları ekleyin. Kök kullanıcıyı günlük işlerden tamamen soyutlayın. API anahtarı asla oluşturmayın. MFA’yı donanım tabanlı bir anahtarla sabitleyin. Bu üç adım, hesap ele geçirme senaryolarının önünü keser.
İzin Değerlendirme Mantığı
AWS IAM mimarisi, varsayılan olarak tüm erişim isteklerini reddedilir. Bir işlem ancak açık izin politikası, SCP onayı ve kaynak kurallarının tamamından geçerse yürütülür. Bu katmanlı doğrulama, yanlış yapılandırma kaynaklı ihlalleri %60’a kadar azaltır.
IAM Rolleri ve Federasyon: Geçici Yetkilerle Riski Nasıl Düşürsünüz?
Kalıcı kimlik bilgileri, bulut güvenliğinin en büyük açık kapılarından biridir. IAM rolleri, bu sorunu “geçici şapka” metaforuyla çözer. Bir rol, kalıcı bir kullanıcı değil; ihtiyaç anında üstlenilen yetki paketidir. Uygulamalar veya geliştiriciler, sts:AssumeRole çağrısıyla geçici token alır. Bu tokenlar süre sınırlıdır. Çalınsa bile pencere dardır.
Federasyon ve IAM Identity Center, bu yapıyı kurumsal ölçekte yönetmenizi sağlar. Şirketinizdeki Active Directory veya Okta gibi kimlik sağlayıcıları, SAML 2.0 üzerinden AWS’ye bağlanır. Kullanıcılar tek kurumsal hesapla birden fazla AWS hesabına erişir. SCIM 2.0 senkronizasyonu, grup üyelikleri değiştiğinde izinleri otomatik günceller. Manuel hesap açma kapandığında, yetki hayaletleri de silinir.
Geçmiş projelerde, geliştirici ekiplerin kalıcı access key’leri kod depolarına yanlışlıkla yüklediği sıkça görülmektedir. Rol tabanlı geçici kimliklere geçiş, bu riski kökten çözmektedir. Artık kimlik bilgisi sızıntısı yaşansa bile, token süresi dolduğunda erişim otomatik kesilmektedir. Güvenlik, sürtünme yaratmadan akışa entegre edilmelidir.
Bölgesel Mimari ve STS Tokenları: Veri Egemenliği ve Erişim Kontrolü
AWS hizmetleri, küresel ve bölgesel olarak ikiye ayrılır. IAM, Route 53 ve CloudFront gibi servisler tek merkezden yönetilir. EC2, RDS ve S3 depolama katmanı ise belirli coğrafi bölgelere bağlıdır. Bu ayrım, sadece performans değil; yasal uyumluluk ve veri egemenliği için kritiktir. Verinin hangi ülkede duracağı, KVKK veya GDPR gibi düzenlemelerle doğrudan ilişkilidir.
STS ve S3, hibrit yapıdadır. STS, hem küresel hem bölgesel API uç noktalarına sahiptir. Bölgesel endpoint kullanmak zorunludur. S3’te durum farklıdır. Bucket isimleri küreseldir ve tektir. Verinin kendisi ise seçtiğiniz bölgedeki AZ’lerde saklanır.
Çoğu ekip, bölgesel ayrımı sadece “hız” üzerinden okur. Oysa asıl risk, token uyumsuzluğunda saklıdır. Kapalı bir bölgeyi açıp global tokenla erişmeye çalışmak, saatlerce süren hata ayıklama döngülerine yol açar. Bölgesel endpoint’leri altyapı kodunuza açıkça tanımlayın. Varsayımla çalışmayın.
AWS Organizations ve SCP’ler: Çoklu Hesap Yönetiminde Güvenlik Sınırları
Tek hesapla başlamak kolaydır. Ölçeklendikçe, yüzlerce hesabı yönetmek güvenlik kabusuna dönüşür. AWS Organizations, bu karmaşayı hiyerarşik bir ağaç yapısına dönüştürür. Faturalandırma merkezileşir. Güvenlik politikaları tek yerden yayılır. Hizmet Kontrol Politikaları (SCP), alt hesaplara üst sınır çeken güvenlik kurallarıdır. Bir SCP, s3:DeleteBucket işlemini yasaklarsa, alt hesaptaki admin kullanıcısı bile bu işlemi yapamaz.
Sektör taramaları, çoklu hesap yapılarında SCP kullanmayan organizasyonların, yetki taşması olaylarında %40 daha fazla etkilendiğini gösteriyor. Merkezi politika yönetimi, insan hatasını azaltır. GuardDuty, Security Hub ve CloudTrail gibi hizmetleri organizasyon düzeyinde etkinleştirmek, görünürlüğü artırır.
VPC, IMDS ve Ağ Geçitleri: Bulut Ağını Nasıl Kilitlemelisiniz?
VPC, AWS içindeki özel ağınızın sınırlarını çizer. Kaynaklarınızı internetten veya diğer iş yüklerinden izole eder. Ağ geçitleri, bu sınırlandırmadan geçişi yönetir. Internet Gateway, çift yönlü trafiği açar. NAT Gateway, özel alt ağların dışarı çıkıp güncelleme almasını sağlar; içeri girişe izin vermez. Egress-only gateway, IPv6 için benzer mantıkla çalışır.
IP yönetimi, güvenlik duruşunu doğrudan etkiler. Asıl risk, VPC içindeki link-local adreslerde saklıdır. 169.254.169.254 (IMDS), sunucu meta verilerini ve geçici kimlik bilgilerini sunar. IMDSv2, oturum tabanlı doğrulama gerektirir ve bu saldırı vektörünü büyük ölçüde kapatır.
VPC tasarımı, “erişilebilirlik” değil “izolasyon” odaklı olmalıdır. Varsayılan VPC’leri üretimde kullanmayın. Alt ağları işlevsel ayırın. NACL ve Security Group kurallarını en dar kapsamda tutun. IMDSv2’yi hesap düzeyinde zorunlu kılın. Trafik akışını VPC Flow Logs ile izleyin. Görünmeyen ağ, yönetilemeyen risktir.
Sıkça Sorulan Sorular (FAQ)
AWS kök kullanıcısı neden günlük işlerde kullanılmamalı?
Kök kullanıcı, hesap üzerinde sınırsız yetkiye sahiptir ve MFA aktif değilse tek noktada ele geçirilebilir. Kök hesap sızıntıları ortalama 4.2 milyon dolar maliyet yaratır. Günlük iş için IAM kullanıcıları kullanılmalıdır.
SCP politikaları yönetim hesabını neden etkilemez?
Bu tasarım, yöneticilerin yanlış politika ile kendilerini kilitlemesini önlemek için bilinçlidir. SCP’ler yalnızca alt hesapları ve OU’ları kısıtlar. Yönetim hesabı, organizasyon düzeyinde denetim yetkisini korur.
IMDSv1 ve IMDSv2 arasındaki güvenlik farkı nedir?
IMDSv1, düz HTTP isteklerine yanıt verir ve SSRF saldırılarına açıktır. IMDSv2, oturum tokenı ve PUT isteği zorunluluğu getirir. Bu yapı, yetkisiz meta veri erişimini %90 oranında engeller.
VPC Endpoint kullanmak neden güvenlik açısından önemlidir?
VPC Endpoints, trafiği halka açık internete çıkarmadan AWS hizmetlerine ulaşmanızı sağlar. Bu yapı, veri sızıntısı riskini azaltır ve DDoS yüzeyini daraltır. Özel ağ üzerinden iletişim, uyumluluk denetimlerinde de avantaj sağlar.
Sonuç
AWS güvenliği, tek bir düğmeyle açılan bir özellik değil; mimari kararların toplamıdır. Kök kullanıcıyı kilitlemek, IAM rollerini geçici tokenlarla yönetmek, bölge ayrımını veri egemenliğiyle okumak, SCP’lerle çoklu hesapları denetlemek ve VPC trafiğini izole etmek; sağlam bir bulut duruşunun temel taşlarıdır.
- Bulut güvenliği, varsayılan ret ilkesiyle başlar.
- Geçici kimlikler ve SSO, kalıcı anahtar riskini siler.
- SCP’ler ve VPC izolasyonu, saldırı yüzeyini daraltır.
- IMDSv2 ve bölgesel endpoint’ler, uyumluluğu garanti eder.
Altyapınızı kodla yönetin. Politikaları merkezileştirin. Logları kör nokta bırakmadan toplayın. Güvenlik, sonradan eklenen bir katman değil; tasarımın kendisidir.
Comments