AWS Bulut Güvenliğine Giriş: "Başkasının Bilgisayarı"nı Nasıl Korursunuz?

Bulut bilişim denince aklınıza gelen ilk şey muhtemelen "ölçeklenebilirlik" veya "maliyet tasarrufu"dur. Peki ya güvenlik? Çoğu kişi buluta geçerken şunu sorar: "Verilerim başkasının sunucusunda, bu güvenli mi?"

Cevap hem evet hem hayır. Çünkü bulutta güvenlik, tek başına AWS'nin sorumluluğu değil; sizinle paylaşılan bir görevdir.

Bu yazıda, bulut mimarisinin her katmanında güvenlik perspektifini nasıl kurmanız gerektiğini anlatacağım. Teknik jargona boğulmadan, gerçek dünya senaryolarıyla ilerleyeceğiz.

On-Premise'den Buluta Geçişte Güvenlik Paradigması Değişiyor mu?

Eski modelde (On-Premise), güvenlik fizikseldi. Sunucu odasının kapısını kilitler, kameralar takar, ağ donanımlarını kendi ekibinizle yapılandırırdınız. Bu, tam kontrol demekti ama aynı zamanda tüm yükün omuzlarınızda olması anlamına geliyordu.

Bulut modelinde ise oyunun kuralları değişir. AWS, fiziksel güvenliği (veri merkezi erişimi, elektrik, soğutma) sağlar. Siz ise işletim sistemi yamalarını, uygulama kodunu ve en önemlisi kimlik yönetimini (IAM) sağlarsınız.

Güvenlik İçin Ne Anlama Geliyor? Artık "sunucuyu kim hackledi?" sorusu yerine, "bu API anahtarını kim kullandı?" veya "bu S3 bucket'ı neden herkese açık?" sorularını sormalısınız. Bulutta güvenlik, duvar örmek değil, doğru izinleri vermek demektir.

Region ve Availability Zone Seçimi: Veri Egemenliği ve Yedeklilik

AWS dünyasında coğrafya sadece hız değil, hukuk ve güvenlik meselesidir. Bir bölge (Region), fiziksel bir konumdur (örneğin eu-central-1 Frankfurt). Her bölge, birbirinden bağımsız Availability Zone'lardan (AZ) oluşur.

Neden bu kadar önemli?

1. Veri Egemenliği (Data Sovereignty): Avrupa'daki müşterilerinizin verilerinin AB sınırları içinde kalmasını istiyorsanız, Frankfurt (eu-central-1) veya Paris (eu-west-3) bölgelerini seçmelisiniz. ABD'deki GovCloud gibi özel bölgeler, hassas devlet verileri için izole edilmiştir.
2. Yüksek Erişilebilirlik (High Availability): Bir AZ'de yangın çıksa bile, diğer AZ'ler etkilenmez. Güvenlik açısından bu, felaket kurtarma (Disaster Recovery) planınızın temelidir.

Güvenlik İpucu: Multi-AZ mimarisi kullanmak, sadece uptime'ı artırmaz; aynı zamanda tek bir noktadaki güvenlik ihlalinin tüm sistemi çökertmesini engeller. Verilerinizi farklı AZ'lere çoğaltarak (replication), fidye yazılımı (ransomware) saldırılarına karşı direncinizi artırabilirsiniz.

Otomatik Ölçeklendirme (Auto-Scaling): DDoS'a Karşı Savunma Hattı

Black Friday'de trafiğiniz 10 katına çıkıyor. Manuel olarak sunucu eklerseniz, hem geç kalırsınız hem de hata yapma ihtimaliniz artar. Auto-scaling, talebe göre otomatik olarak kaynak ekler veya çıkarır.

Peki bunun güvenlikle ne alakası var?

DDoS (Dağıtık Hizmet Reddi) saldırıları, sisteminizi aşırı yükleterek çökertmeyi amaçlar. Auto-scaling grupları, Elastic Load Balancer (ELB) ile birlikte çalıştığında, ani trafik artışlarını absorbe edebilir. Ancak dikkat: Auto-scaling tek başına bir güvenlik çözümü değildir. Kötü niyetli botların trafiğini ayırt etmek için AWS WAF (Web Application Firewall) ile entegre etmelisiniz.

API Zorunluluğu ve IAM: Kapıyı Kilitlemek Yetmez, Anahtarı Da Kontrol Et

Jeff Bezos'un 2002'deki meşhur "API Emri", AWS'nin bugün olduğu gibi modüler ve güvenli olmasının temelidir. Tüm servisler API üzerinden konuşur. Bu, otomasyon için harikadır ama güvenlik açığı da olabilir.

Her API çağrısı bir kimlik doğrulaması gerektirir. İşte burada IAM (Identity and Access Management) devreye girer.

• Root Account: Asla günlük işlerde kullanmayın. MFA (Çok Faktörlü Kimlik Doğrulama) mutlaka aktif olsun.
• IAM Users/Roles: İnsanlar ve servisler için ayrı roller tanımlayın.
• Least Privilege: Bir servisin ihtiyacı olan minimum izni verin. Örneğin, bir Lambda fonksiyonu sadece okuma yapacaksa, ona s3:PutObject izni vermeyin.

Güvenlik Best Practice'i: Sabit API anahtarları (Access Keys) kullanmak yerine, IAM Rolleri ve geçici kimlik bilgilerini (temporary credentials) tercih edin. Anahtarlar sızdırılabilir, roller ise sürelidir ve izlenebilir.

Serverless ve Low-Code: Saldırı Yüzeyini Küçültmek

Geleneksel sunucularda (EC2), işletim sistemini yamalamanız, portları kapatmanız, SSH anahtarlarını yönetmeniz gerekir. Her açık port, potansiyel bir giriş kapısıdır.

Serverless (Lambda, DynamoDB, API Gateway) bu yükü ortadan kaldırır. AWS, altyapıyı yönetir. Siz sadece kodunuzu yazarsınız.

• Avantaj: İşletim sistemi seviyesindeki güvenlik açıklarından (CVE'ler) etkilenmezsiniz.
• Risk: Kodunuzdaki mantık hataları veya yanlış yapılandırılmış IAM izinleri.

Low-code araçlar (Amplify, Honeycode) ise geliştiricilerin hızlı çözüm üretmesini sağlar. Ancak, "kolay kurulum" bazen "varsayılan güvenlik ayarlarının gözden kaçırılması" anlamına gelebilir. Amplify ile bir web uygulaması kurarken, arka planda oluşturulan Cognito (kimlik yönetimi) ve S3 bucket'larının izinlerini mutlaka kontrol edin.

CapEx'ten OpEx'e Geçiş: Güvenlik Araçlarının Esnek Maliyeti

Geleneksel modelde, güvenlik duvarı (Firewall) veya SIEM (Security Information and Event Management) araçları için büyük sermaye yatırımı (CapEx) yapardınız. Kullanmasanız da parasını öderdiniz.

Bulutta ise OpEx (İşletme Gideri) modeli geçerlidir. AWS GuardDuty, Security Hub veya Macie gibi güvenlik servislerini, kullandığınız kadar ödersiniz. Bu, küçük ekiplerin bile enterprise-seviye güvenlik izleme araçlarına erişebilmesini sağlar.

• GuardDuty: Anomali tespiti için makine öğrenimi kullanır.
• Security Hub: Farklı güvenlik araçlarından gelen uyarıları tek merkezde toplar.
• Macie: S3 bucket'larında hassas veri (PII) olup olmadığını tarar.

Bu araçları açmak, bir düğmeye basmak kadar kolaydır. Ancak, uyarıları (alerts) yönetmek için bir süreç kurmazsanız, "alert fatigue" (uyarı yorgunluğu) yaşarsınız.

Sonuç: Bulut Güvenliği Bir Ürün Değil, Süreçtir

Bulut mimarisinin temellerini attık: Region'lar, AZ'ler, Auto-scaling, API'ler ve Serverless. Ancak bunların her biri, doğru güvenlik pratikleriyle anlam kazanır.

Unutmayın:

1. Kimlik yeni sınırdır. IAM politikalarınızı sıkı tutun.
2. Veri nerede duruyor? Bölge seçimlerinizi yasalara göre yapın.
3. Otomasyon güvenliği artırır. Manuel müdahaleyi azaltın, IaC (Infrastructure as Code) kullanın.
4. İzleyin ve Tepki Verin. GuardDuty ve CloudTrail gibi araçlarla ortamınızı görünür kılın.

Bulut, size güç verir. Ama bu gücü nasıl kullandığınız, güvenliğinizi belirler.

Sıkça Sorulan Sorular (FAQ)

AWS'de verilerim şifrelenmiş mi? Varsayılan olarak birçok servis (S3, EBS, RDS) verileri dinlenme halinde (at rest) şifreler. Ancak, transit haldeki (in transit) veriler için TLS/SSL sertifikalarını siz yapılandırmalısınız. AWS KMS (Key Management Service) ile kendi anahtarlarınızı yönetebilirsiniz (AWS Documentation, 2024).

Multi-AZ kullanmak güvenliği artırır mı? Evet, dolaylı olarak. Multi-AZ, tek bir veri merkezindeki fiziksel arıza veya saldırının hizmet kesintisine yol açmasını engeller. Bu, yüksek erişilebilirlik (HA) ve felaket kurtarma (DR) stratejisinin bir parçasıdır.

Serverless mimari tamamen güvenli midir? Hayır. Altyapı güvenliği AWS'ye ait olsa da, uygulama kodu güvenliği, bağımlılık yönetimi (dependency scanning) ve IAM izinleri sizin sorumluluğunuzdadır. Yanlış yapılandırılmış bir Lambda rolü, tüm VPC'nize erişim sağlayabilir.

CloudFront güvenlik için nasıl kullanılır? CloudFront, bir CDN olmanın ötesinde, AWS WAF ile entegre çalışarak SQL Injection, XSS gibi yaygın web saldırılarını engeller. Ayrıca, origin (kaynak) sunucularınızın IP adreslerini gizleyerek doğrudan saldırıları önler.