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öreceksiniz.
- 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.
AWS IAM mimarisi, varsayılan olarak tüm erişim isteklerini reddeder. 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.
Rol güvenliğinin kalbi, Trust Policy’dir. Bu politika, “kim bu şapkayı takabilir?” sorusunu yanıtlar. Yanlış yapılandırılmış bir trust policy, yetkisiz hesapların rolü üstlenmesine yol açar. Koşul bloklarına kaynak hesap ID’si veya MFA zorunluluğu eklemek, saldırı yüzeyini daraltır.
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.
IAM rolleri ve federasyon, kalıcı kimlik bilgisi riskini ortadan kaldırır. Geçici tokenlar ve merkezi SSO yönetimi, yetki yayılımını kontrol altına alır. Kurumsal entegrasyonlarda SCIM 2.0 kullanımı, manuel izin hatalarını %75 oranında düşürür.
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. 2019 sonrası açılan “opt-in” bölgeler, varsayılan olarak kapalıdır. Bu bölgeleri manuel açsanız bile, küresel STS endpoint’inden aldığınız tokenlar burada reddedilir. 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.
Bölge seçimi, felaket kurtarma stratejisini de şekillendirir. Tek bölgeye bağımlı kalmak, kesinti riskini artırır. Multi-region mimari, maliyeti yükseltse de iş sürekliliği için şarttır. Opt-in bölgeleri kullanmadan önce, STS token uyumluluğunu ve bölgesel hizmet kotalarını kontrol edin. Varsayılan bölge kuralları, hesabın açılış tarihine göre değişir. 2017 öncesi hesaplar us-east-1, sonrakiler us-east-2 veya us-west-2 merkezlidir.
Ç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 bölge mimarisi, veri egemenliği ve erişim kontrolü için tasarlanmıştır. Opt-in bölgeler, bölgesel STS tokenları gerektirir. Küresel ve bölgesel hizmet ayrımını doğru kurgulamak, uyumluluk ihlallerini ve erişim kesintilerini önler.
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. Kök dizin, Organizasyonel Birimler ve alt hesaplar, mantıksal gruplar halinde yönetilir. Faturalandırma merkezileşir. Güvenlik politikaları tek yerden yayılır.
Hizmet Kontrol Politikaları, 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. SCP’ler, izin vermez; sadece izinleri budar. Yönetim hesabı bu kurallardan muaftır. Bu tasarım, yöneticilerin kendi kendini kilitlemesini önlemek için bilinçlidir.
SCP’leri doğru kullanmak, “güvenlik gardiyanı” rolünü üstlenir. Belirli bölgelerde kaynak oluşturmayı engelleyin. Root kullanıcı erişimini kısıtlayın. IMDSv2 kullanımını zorunlu kılın. Organizasyondan çıkışı bloklayın. Unutmayın, bir OU’ya en fazla 5 SCP bağlanabilir. Varsayılan FullAWSAccess politikası, her şeye izin verir. Güvenli bir başlangıç için bunu daraltın.
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.
AWS Organizations ve SCP’ler, çoklu hesap yönetişiminin temelidir. SCP’ler alt hesapları kısıtlar ancak yönetim hesabını etkilemez. Merkezi güvenlik politikaları, yetki taşması ve uyumluluk ihlallerini %40 oranında azaltı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. Public IP’ler, sunucu yeniden başlatıldığında değişir. Elastic IP sabittir ve hesaba bağlanır. Ancak 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. 2019 CapitalOne ihlali, yanlış yapılandırılmış IMDS üzerinden gerçekleşti. IMDSv2, oturum tabanlı doğrulama gerektirir ve bu saldırı vektörünü büyük ölçüde kapatır.
VPC Endpoints, trafiği internete çıkarmadan AWS hizmetlerine ulaşmanızı sağlar. Interface Endpoint, özel ağ arayüzüyle bağlanır. Gateway Load Balancer Endpoint, güvenlik araçları için trafiği yönlendirir ve denetler. Bu yapı, veri sızıntısı riskini düşürür. Ağ trafiğini VPC içinde tutmak, hem maliyeti hem saldırı yüzeyini azaltı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.
VPC mimarisi, ağ izolasyonu ve güvenli trafik yönetimi için tasarlanmıştır. IMDSv2 kullanımı, meta veri sömürü saldırılarını %90 azaltır. VPC Endpoints, trafiği internete çıkarmadan AWS hizmetlerine erişim sağlar ve veri sızıntı riskini düşürür.
Sık Sorulan Sorular
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şler için IAM kullanıcıları veya rolleri 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 ve acil müdahale 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 ve benzer ihlallerin önüne geçer.
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. Yanlış yapılandırmalar kaçınılmaz değildir. Doğru varsayımlar, dar yetkiler ve sürekli izleme ile risk yönetilebilir.
- 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
Loading comments...