Cloud Computing’de Güvenliğin Esasları

Bulut bilişim üzerine konuşurken sorulan ilk soru çoğu zaman fiyatla ilgili oluyor: “Şirket içi sunucuya göre ne kadar tasarruf ettirir?” İkinci soru ise neredeyse her zaman güvenlikle ilgili: “Verilerim güvende mi?” Bu yazıda bu ikinci soruya hakkını vermeye, Cloud Security Alliance (CSA) ve NIST’in bugünkü çalışmaları ışığında bulut güvenliğinin gerçek esaslarını sıralamaya çalışacağım.

Yazıyı uzun tutuyorum çünkü güvenlik, “alıp koşmak” yerine “oturup tasarlamak” gereken bir alan; kısa bir özetle geçilmesi haksızlık olur.

Önce zihinsel çerçeve: Paylaşılan sorumluluk

Bulut güvenliğindeki en yaygın yanlış anlama şu cümlede gizli: “Buluta geçtim, artık güvenlik benim sorunum değil.” Bu yanlış. Sağlayıcı sizinle birlikte sorumluluğu paylaşıyor:

Sağlayıcının sorumluluğu: Fiziksel veri merkezi güvenliği, donanım, hipervizör, ağ omurgası, depolama altyapısı, temel servislerin operasyonel güvenliği.
Sizin sorumluluğunuz: İşletim sistemi seviyesi ve üstündeki her şey, yamalar, uygulama güvenliği, kullanıcı hesapları, anahtar yönetimi, yedekleme stratejisi, veri sınıflandırması.

Sorumluluk dağılımı servis modeline göre değişir:

IaaS (Amazon EC2, Rackspace Cloud Servers, Terremark Enterprise Cloud): Sağlayıcı, donanım ve hipervizöre kadar; üstü size kalıyor.
PaaS (Google App Engine, Windows Azure, Force.com): Sağlayıcı işletim sistemi ve çalışma zamanını da yönetiyor; siz uygulamadan ve veri katmanından sorumlusunuz.
SaaS (Salesforce, Google Apps, Microsoft BPOS): Çoğu şey sağlayıcıda; sizin asıl sorumluluğunuz veri sınıflandırması, kullanıcı yönetimi ve uçtan kullanım güvenliği.

Bu çerçeveyi kurmadan ne kontrol matrisini hatasız işleyebilirsiniz, ne de bir bulut sağlayıcısıyla doğru sözleşme imzalayabilirsiniz.

CSA’nın Top Threats v1.0, Bulutun yedi büyük tehdidi

Cloud Security Alliance, Mart 2010’da yayımladığı Top Threats to Cloud Computing v1.0 belgesinde bulut bilişimin yedi büyük tehdidini sıralamıştı. Hâlâ bu listenin geçerliliği yüksek; her birini Türkiye’deki kurumsal alıcının diliyle açıklayayım:

1. Abuse and Nefarious Use of Cloud Computing

Bulutun self-service ve kredi kartı ile saniyeler içinde sağlama kolaylığı, kötü niyetli aktörler için de geçerli. Spam botnet’ler, parola kırma çiftlikleri ve DDoS başlatma noktaları zaman zaman bulut altyapılarında konuşlanıyor. Sağlayıcının kayıt süreci ne kadar zayıfsa risk o kadar yüksek.

Ne yapmalı? Sağlayıcının kötüye kullanım izleme, IP itibar yönetimi ve hesap doğrulama süreçlerini sorgulayın.

2. Insecure Interfaces and APIs

Bulutun her şeyi API üzerinden yapılıyor: sunucu başlatma, depolama, ağ ayarları. Bu API’ler ne kadar güvenliyse buluttaki konumunuz o kadar güvenli. Zayıf kimlik doğrulama, anonim erişim, şifrelenmemiş çağrılar bu kategoride.

Ne yapmalı? TLS zorunluluğu, anahtarların güvenli saklanması, API çağrılarının audit log’u, çağrı imzası (request signing) ve çok faktörlü doğrulama.

3. Malicious Insiders

Sağlayıcının çalışanlarından biri kötü niyetliyse, fiziksel ve mantıksal erişim avantajı nedeniyle ciddi bir tehdit oluşturuyor. Bu, klasik on-premise dünyada da olan bir tehdit, ama bulutta görünürlüğünüz daha az.

Ne yapmalı? Sağlayıcının çalışan tarama (background check), ayrıcalıklı erişim yönetimi (PAM), four-eyes prensibi ve denetim raporlarını isteyin. SAS 70 Tip II raporu, ki SSAE 16’ya geçiş Haziran 2011’de başlayacak, dolayısıyla bugün hâlâ SAS 70 referans, bu konuda asgari beklenti.

4. Shared Technology Issues

Multi-tenant bulut, fiziksel donanımın paylaşıldığı bir model. Hipervizör seviyesinde bir zafiyet (VM escape) ya da yan kanal saldırıları (side-channel attacks; örn. paylaşılan L2 cache üzerinden anahtar sızıntısı çalışmaları), aynı donanımı paylaşan kiracılar arasında tehlike yaratabilir.

Ne yapmalı? Yüksek hassasiyetli iş yükleri için dedicated instance seçenekleri, sağlayıcının hipervizör yamalama disiplini, mümkünse fiziksel izolasyon.

5. Data Loss or Leakage

Buluttaki en korkulan senaryolardan biri: verinin kalıcı olarak kaybolması ya da yetkisiz ellere geçmesi. Yetersiz yedekleme, hatalı silme, şifre kaybı, sağlayıcı iflası…

Ne yapmalı? Veriyi siz şifreleyin, anahtar sizde kalsın. En azından kritik veri için. Kullandığınız sağlayıcının yedek tutumunu, replikasyon politikasını ve veri taşınabilirliği (export) imkânını sözleşme aşamasında netleştirin.

6. Account or Service Hijacking

Tek bir parolanın çalınması, bütün bulut hesabınızın ele geçirilmesi demek olabilir. Phishing, parola tekrar kullanımı, brute force…

Ne yapmalı? Çok faktörlü doğrulama (MFA) her yönetici hesabı için zorunlu. API anahtarları role-based çalıştırılsın, kök hesap günlük işlerde kullanılmasın. Hesap erişim logları düzenli izlensin.

7. Unknown Risk Profile

Belki en sinsi tehdit bu: bulutu kullanırken hangi riske maruz kaldığınızı bilmemek. Sağlayıcının yaması, sürümü, alt yüklenicisi, veri merkezinin gerçek konumu… Bilmediğinizi yönetemezsiniz.

Ne yapmalı? Şeffaflık talep edin. Sertifikasyonları (ISO 27001, SAS 70 Tip II, PCI DSS Seviye 1) okuyun, uyumluluk durumunu sözleşmeye işleyin.

Veri güvenliği: Şifreleme ve anahtar yönetimi

Veriyi üç durumda korumak gerekiyor:

In transit (yolda): Kullanıcı-uygulama ve uygulama-arka uç trafiği için TLS zorunlu. Bulut sağlayıcılarının çoğunda HTTPS sertifikasyonu standart, ama TLS sürüm/şifre takımı seçimi sizin sorumluluğunuzda.
At rest (depolanırken): Disk seviyesinde şifreleme (örn. dm-crypt/LUKS Linux tarafında), uygulama seviyesinde veri alanlarının şifrelenmesi (özellikle PII), nesne depolama tarafında sunucu yanında ya da istemci yanında şifreleme.
In use (kullanılırken): Bu, hâlâ açık araştırma konusu; homomorfik şifreleme akademik düzlemde olgunlaşmadı.

Anahtar yönetimi, şifrelemenin kendisinden daha kritik. Anahtarı sağlayıcının kasasına bırakırsanız aslında onunla paylaşıyorsunuz demektir. HSM (Hardware Security Module) tabanlı çözümler, daha yüksek hassasiyet için tercih edilmeli. AWS gibi sağlayıcıların müşterinin kendi anahtarını saklayabilmesi için yeni servisler üzerinde çalıştığı söyleniyor, yakın takipte.

Kimlik ve Erişim Yönetimi (IAM)

Bulut hesabınızın kök kullanıcısı, kelimenin tam anlamıyla şirketinizin kalbi. IAM tarafında uygulamanız gereken disiplin:

Kök hesap yalnızca acil durumda ve MFA ile.
Günlük operasyon için sınırlı yetkili IAM kullanıcıları/rolleri.
Federation mümkünse: SAML 2.0 ile şirket içi Active Directory’nizden tek tıkla bulut hesabına erişim.
API anahtarlarının döngüsel yenilenmesi (90 günde bir rotasyon).
Servis hesapları ile insan hesaplarının ayrılması.

Denetim, kayıt ve görünürlük

Olmayan bir kaydı sonradan üretemezsiniz. Buluta geçerken log toplama mimarisini ilk gün kurun:

API çağrı logları (örn. AWS tarafında bu yıl içinde gelmesi beklenen denetim servisleri için planlanın),
Sistem logları (syslog → merkezî log sunucusu),
Uygulama logları,
Güvenlik olay yönetimi (SIEM) entegrasyonu.

İdeali, logların bulut dışında ya da en azından farklı bir bulut hesabında tutulması; saldırgan kendi izlerini silemesin.

Uyumluluk: Düzenleyici çerçeveler

Türkiye merkezli kurumlar için bugün karşılaşılan başlıca çerçeveler:

PCI DSS: Kredi kartı verisi işleyen herkes için zorunlu. PCI DSS 2.0 Ekim 2010’da yayımlandı, 2011 boyunca aktif geçiş yılı. Bulutta PCI uyumlu olmak isteyenler dedicated ortam, kart verisinin tokenization’ı ve katı segmentasyon ile başlamalı.
SAS 70 Tip II: ABD kökenli denetim çerçevesi. Haziran 2011’den itibaren SSAE 16 / ISAE 3402’ye devredecek. Sağlayıcı seçerken bugün hâlâ SAS 70 Tip II raporunu istemek meşru, ama önümüzdeki ay/yıl içinde SSAE 16 / ISAE 3402’ye geçişi takip etmek gerek.
ISO/IEC 27001: Genel bilgi güvenliği yönetim sistemi sertifikasyonu; ciddi bir bulut sağlayıcısının asgari beklenen referansı.
AB Veri Koruma Direktifi (95/46/EC): Avrupa müşterileri için veri ikamet (data residency) zorunluluğu yaratıyor; AB sınırları dışında veri tutmak için açık onay süreçleri gerek.

Türkiye’de Kişisel Verilerin Korunması Kanunu halen taslak halinde tartışılıyor; yasalaştığı zaman bulutta veri tutan kurumların durumunu doğrudan etkileyecek. Bunu yakından izliyorum.

Olay yönetimi ve felaket kurtarma

Bulutta da bir gün bir şey kötü gidecek. Veri merkezinde yangın, ağ kesintisi, hesabınızda yanlış silme, ya da en kötüsü güvenlik ihlali. Hazırlığın iki ayağı var:

Coğrafi olarak ayrı bölgeler arası replikasyon (örn. AWS US-East + EU-West, Rackspace US + UK).
Düzenli kurtarma tatbikatları: Felaket kurtarma planı sadece kağıt üzerinde kaldığı sürece hiçbir değeri yok. En az yılda bir kez gerçekten yedekten geri dönmeyi deneyin.

Sözleşme ve çıkış stratejisi

Son olarak, çoğunun unuttuğu nokta: sözleşme. Bulut sağlayıcısıyla imzaladığınız sözleşmede şu maddelerin net olması lazım:

Veri ikamet bölgesi (hangi ülke, hangi şehir),
Verinizin sözleşme sona erdiğinde iade edilme formatı ve süresi,
Alt yüklenici listesi ve değişiklik bildirim süresi,
Güvenlik ihlali bildirim süresi (24/48/72 saat),
Denetim hakkı (audit right),
SLA ve cezai şartlar.

Çıkış stratejisi olmadan giriş kararı vermeyin. Bir sağlayıcıdan veriyi geri çekemiyorsanız, en başta o sağlayıcıya bağlanırken iki kez düşünmek gerekir.

Sonuç

Bulutta güvenlik, eski dünyada olduğu gibi bir kontrol listesi değil; paylaşılan sorumluluk modelinde rolünüzü doğru oynama disiplinidir. CSA’nın yedi tehdidini bir kenara, NIST’in tanımını diğer kenara koyarak, sözleşme + teknik mimari + operasyonel disiplin üçgenini kurarsanız buluta makul bir güvenle geçebilirsiniz. Aksi durumda, yani sadece fiyat odaklı bir geçişte, fatura çok daha yüksek olabilir.

Önümüzdeki yazılarda anahtar yönetimi mimarileri ve hibrit bulut için ağ güvenliği üzerine daha teknik yazılar planlıyorum.