Bulut Mimarisi Seçenekleri Nasıl Karşılaştırılır?

Bulut seçimi yalnız sağlayıcı fiyatı değildir

Bulut mimarisi seçerken “hangi sağlayıcı daha ucuz?” sorusu yeterli değildir. NIST SP 800-145 bulut bilişimi talep üzerine erişilebilen ve hızla sağlanabilen paylaşımlı bilgi işlem kaynakları modeli olarak tanımlar. İşletme yalnız sunucu kiralamaz; işlem, depolama, ağ, yazılım, geliştirme platformu ve yönetim sorumluluğu arasında seçim yapar. SaaS’ta uygulamanın önemli bölümünü sağlayıcı işletir; kurum kullanıcıyı, veriyi, ayarı ve kullanım kuralını yönetmeye devam eder. PaaS altyapı operasyonunun bir bölümünü azaltırken uygulama kodu ve veri tasarımı sorumluluğunu korur. IaaS daha fazla kontrol sağlar fakat ağ, işletim sistemi, yama, izleme ve yapılandırma sorumluluğunu genişletebilir. Hibrit yapı her zaman daha gelişmiş değildir; eski sistem, veri yerleşimi veya operasyon ihtiyacı nedeniyle seçilebilir. CISA’nın referans mimarisi sağlayıcı ile müşteri arasındaki sorumluluğun hizmete göre değiştiğini gösterir. Karar model adına değil, iş yükünün ihtiyacına dayanır.

Kimler için uygundur?

Yeni dijital ürün geliştiren ekipler, mevcut sistemi buluta taşıyan işletmeler, SaaS satın alan kurumlar, teknik liderler, ürün yöneticileri ve bilgi işlem yatırımını yöneten karar vericiler için uygundur.

Mimari değerlendirmenin kapsamı

İş yükü sınıflandırma, bağımlılık, hizmet seviyesi, maliyet varsayımı, sorumluluk matrisi, veri yerleşimi ve temel risk ele alınabilir. Nihai güvenlik denetimi, hukuki veri aktarımı, sözleşme ve düzenlemeye tabi sektör kararı ilgili uzmanların alanıdır.

Seçenekleri ayıran sorular

Aynı soruları her mimari seçeneğe uygulamak karşılaştırmayı tutarlı kılar.

• İş yükünün kesinti toleransı, performans ihtiyacı ve veri hassasiyeti nedir?
• Uygulama, işletim sistemi veya ağ katmanında ne kadar kontrol gerekir?
• Sağlayıcı ile kurum sorumluluğu nerede ayrılıyor?
• Yedek, geri yükleme, kayıt ve olay müdahalesini kim yürütecek?
• Ekip bu mimariyi güvenli işletmek için yeterli deneyime sahip mi?
• Çıkış stratejisi, veri taşınabilirliği ve sağlayıcı bağımlılığı nedir?

Uygulama örneği: eğitim platformu

Bir eğitim kurumu kayıt, video, ödeme ve içerik yönetimini tek uygulamada toplamak ister. İlk öneri bütün sistemi sanal sunucularda kurmaktır. İncelemede video işleme yükünün dönemsel arttığı, ödemenin ayrı sağlayıcıda olduğu ve içerik ekibinin operasyon deneyiminin sınırlı kaldığı görülür. Ekip uygulama için PaaS, medya için yönetilen depolama, eski öğrenci kaydı için geçici hibrit bağlantıyı karşılaştırır. Yalnız aylık sunucu bedeline bakmaz; yedek, olay kaydı, erişim, veri aktarımı ve destek kapasitesini matrise ekler. Daha az altyapı işi üstlenilen yapı seçilir; fakat kullanıcı yetkisi, veri silme ve üçüncü taraf erişimi kurumun sorumluluğunda kalır.

İş yükü bazlı seçenek matrisi ve çıkış planı

Bulut kararı kurum genelinde tek bir “taşıyalım veya kalalım” sorusuna indirgenmemelidir. NIST’in bulut tanımındaki hizmet ve kurulum modelleri, sorumluluğun kullanılan modele göre değiştiğini gösterir. Bu nedenle matris uygulama adına değil iş yüküne göre kurulur. Kamuya açık web, hassas belge deposu, raporlama, gerçek zamanlı görüşme, geliştirme ortamı ve yedekleme ayrı satırlardır. Her satır için veri sınıfı, erişilebilirlik hedefi, gecikme toleransı, trafik deseni, bağımlılıklar, yönetim becerisi ve mevzuat kısıtı yazılır. Aynı sağlayıcı bir iş yükünde uygun, başka birinde gereksiz maliyetli olabilir. Seçenekler yalnız aylık liste fiyatıyla karşılaştırılmaz. Veri çıkışı, yedek, gözlemleme, güvenlik araçları, destek, lisans, taşıma emeği ve olay müdahalesi toplam maliyete eklenir. CISA’nın bulut güvenliği referans mimarisinden yararlanarak kimlik, ağ, veri, günlük ve yönetim düzlemi ayrı değerlendirilir. Sağlayıcının altyapıyı koruması, kurumun kullanıcı yetkisini, depolama ayarını veya uygulama açığını otomatik olarak güvenli yapmaz. Her kontrolün kurumda mı, sağlayıcıda mı, yoksa paylaşımlı mı olduğu sahibine ve kanıtına kadar yazılır. Matrisin zorunlu sütunlarından biri çıkış senaryosudur. Verinin standart biçimde dışa alınması, anahtarların devri, alan adı ve sertifika kontrolü, altyapı tanımları, yedeklerin okunması ve eski ortamın güvenli kapatılması denenmeden taşınabilirlik yalnız sözleşme cümlesi olarak kalır. Küçük bir pilotta üretim benzeri trafik, hata durumunda geri dönüş, maliyet alarmı ve yedekten kurtarma birlikte test edilir. Sonuçlar “bulut hızlıdır” gibi genel yargılarla değil, belirlenen iş yükünün hedefleriyle karşılaştırılır. Karar tek sağlayıcı, hibrit veya mevcut ortamda iyileştirme olabilir. Güvenli mimari, modaya uyan değil; sorumluluğu, maliyeti, kurtarma yolunu ve çıkış hakkını kurumun anlayabildiği seçenektir. Seçimin gerekçesi bir mimari karar kaydında saklanır. Kayıt, değerlendirilen alternatifleri, kabul edilen tavizi, ölçüm sonucunu ve kararı yeniden açacak koşulu belirtir. Veri hacmi, yasal gereklilik, fiyat modeli veya ekip becerisi değiştiğinde eski puanlar sessizce kullanılmaz; etkilenen iş yükü yeniden değerlendirilir. Bu iz, sağlayıcı tercihinin kişisel kanaat gibi aktarılmasını önler ve sonraki teknik ekibe sınanabilir bir başlangıç bırakır.

Sık sorulan sorular

Bulut hizmet modeli sorumluluğun tamamını tek tarafa devretmez.

• SaaS’ta güvenlik tamamen sağlayıcıda mı? — Hayır; kullanıcı erişimi, ayar, veri paylaşımı ve kurum içi kurallar müşteride kalabilir.
• Hibrit her zaman daha güvenli mi? — Hayır; ek bağlantı ve operasyon karmaşıklığı yaratabilir.
• Maliyete neler eklenir? — İşlem ve depolamanın yanında veri transferi, lisans, yedek, izleme, destek ve ekip zamanı eklenir.
• Sağlayıcı değiştirilebilir mi? — Mümkün olabilir; veri biçimi, özel servis bağımlılığı, sözleşme ve geçiş maliyeti baştan planlanır.