Kurumsal bulut temeli: landing zone tasarımı ve çoklu hesap yönetimi

Landing zone nedir, neden gerekir?

Landing zone (bulut iniş bölgesi), bir kurumun buluta iş yükü taşımadan önce hazırladığı yönetilen, güvenli ve ölçeklenebilir temel ortamdır. Hesap ya da abonelik yapısını, kimlik ve erişim düzenini, ağ topolojisini, güvenlik kontrollerini, günlük ve izleme altyapısını, maliyet yönetimini ve politikaları kapsar. Uygulamalar bu temelin üzerine kurulur ve kurallara baştan uyar.

Landing zone olmadan başlanan bulut yolculuğunda tipik tablo şudur: her ekip kendi hesabını açar, kendi ağını kurar, erişimi kendi anlayışıyla verir. Birkaç ay sonra yüzlerce kaynak, tutarsız güvenlik ayarı, kontrol edilemeyen maliyet ve kimin neye erişebildiği belirsiz bir ortam ortaya çıkar. Sonradan düzeltmek, baştan doğru kurmaktan çok daha pahalıdır.

Landing zone bir ürün değil, bir tasarım ve işletim yaklaşımıdır. Bulut sağlayıcılar (Azure, AWS ve diğerleri) kendi öneri çerçevelerini ve otomasyon araçlarını sunar; ancak kurumun gereksinimlerine uyarlamak yine tasarımcının sorumluluğundadır.

Tasarım alanları: nelerden oluşur?

Her sağlayıcının ayrıntısı farklıdır, ama landing zone tasarımı benzer alanları kapsar: • Kaynak organizasyonu: hesap ya da abonelik hiyerarşisi. Üretim, test, geliştirme, paylaşılan servisler ve güvenlik gibi ortamların ayrılması. • Kimlik ve erişim: merkezi kimlik sistemi, rol tabanlı yetkilendirme, ayrıcalıklı erişimin kontrolü. • Ağ: merkez-uç topolojisi, şirket içi ağla bağlantı, ortam içi ve ortamlar arası trafik kuralları, çıkış ve giriş kontrolü. • Güvenlik: koruma politikaları, şifreleme, tehdit tespiti, güvenlik duruşunun izlenmesi. • Günlük ve izleme: merkezi günlük toplama, denetim kayıtları, uyarılar. • Yönetişim ve uyum: politikalar, standartlar, denetim, düzenleyici gereksinimlerin karşılanması. • Maliyet yönetimi: etiketleme, bütçe, harcama görünürlüğü ve sorumluluk dağılımı. • Otomasyon: tüm bu yapının kod olarak tanımlanması ve tekrarlanabilir dağıtılması.

Bu alanlar birbirine bağlıdır: ağ tasarımı güvenliği, hesap yapısı maliyeti ve yetkilendirmeyi etkiler.

Çoklu hesap/abonelik yapısı: temelden başlamak

Landing zone'un omurgası hesap hiyerarşisidir. Azure'da yönetim grupları ve abonelikler, AWS'de ise AWS Organizations ile organizasyon birimleri ve hesaplar bu rolü üstlenir. Hesap ayrımı, hem güvenlik hem maliyet hem de yönetim sınırı oluşturur: bir hesaptaki hata ya da güvenlik ihlali diğerlerini aynı ölçüde etkilemez.

Hiyerarşi tasarımında şu sorular sorulur: • Hangi iş yükleri aynı güvenlik ve uyum gereksinimini paylaşıyor? • Üretim ile geliştirme ortamı nasıl ayrılacak? • Paylaşılan servisler (ağ, kimlik, günlük) nerede duracak? • Politikalar hangi seviyede uygulanacak ve hangi seviyede istisna tanınacak?

Politika kontrolleri hiyerarşinin üst seviyelerinde uygulanırsa alt seviyedeki tüm hesaplar miras alır. Azure Policy ve AWS'de servis kontrol politikaları bu amaçla kullanılır. Koruma bantları (guardrails) kavramı burada devreye girer: ekipler özgürce çalışır ama güvensiz yapılandırmaya sınır konur, kritik ayarlar kapatılamaz.

Kimlik, ağ ve güvenlik temeli

Kimlik, buluttaki yeni çevredir. Tüm kullanıcılar merkezi kimlik sağlayıcıyla yönetilmeli, çoklu doğrulama zorunlu tutulmalı, yetkiler rol tabanlı ve asgari ayrıcalık ilkesine göre verilmelidir. Ayrıcalıklı hesaplar için süreli ve onaylı erişim modeli düşünülür. Servis hesapları ve makine kimlikleri de aynı disiplinle yönetilir.

Ağ tarafında yaygın model merkez-uç (hub-and-spoke) topolojisidir: ortak servisler (güvenlik duvarı, şirket içi bağlantı, DNS) merkezde, iş yükü ağları uçlarda yer alır. Trafik denetimi merkezden yapılır; iş yükleri arası erişim yalnızca ihtiyaç halinde açılır. Adres planlaması baştan yapılmalıdır, çünkü sonradan değiştirmek zordur.

Güvenlik temeli, varsayılan olarak şifreleme, merkezi günlük toplama, tehdit tespit servislerinin açık olması ve güvenlik duruşunun sürekli izlenmesini içerir. Bu bileşenler her yeni hesap açıldığında elle değil, otomatik uygulanmalıdır.

Otomasyon: landing zone'u kodla kurmak

Elle kurulan bir landing zone, kaçınılmaz olarak sapar. Çözüm, yapıyı kod olarak tanımlamaktır (altyapı kodu): hesap sağlama, politika atama, ağ ve günlük yapılandırması sürüm kontrolünde tutulur, değişiklikler gözden geçirme ve test sürecinden geçer.

Bu yaklaşımın yararları: • Yeni hesap ya da abonelik, standart temel ayarlarla hızla açılır. • Yapı belgelenmiş ve tekrarlanabilir olur. • Sapmalar (drift) fark edilir ve düzeltilir. • Değişiklik izi kalır; denetim kolaylaşır.

Sağlayıcıların hazır çözümleri (örneğin yönetilen landing zone hizmetleri ya da referans uygulamalar) başlangıcı hızlandırabilir. Yine de bu çözümlerin kurum gereksinimine ne kadar uyduğu değerlendirilmeli, özelleştirme kapasitesi önceden anlaşılmalıdır. Hazır çözüm, tasarım düşüncesinin yerini tutmaz.

Hesap sağlama sürecinde bir başvuru akışı kurmak da yaygındır: ekip yeni ortam ister, onay sonrası otomasyon standart temelle hesabı hazırlar.

Yönetişim ve maliyet kontrolü

Landing zone kurulduktan sonra asıl iş yönetişimdir. Politikalar ve standartlar yazılı değil, uygulanan kural olmalı. Uyumsuzluk tespiti otomatik yapılmalı: yapılandırma değişiklikleri izlenmeli, ihlaller uyarı üretmeli ve sorumluya yönlendirilmelidir.

Maliyet tarafında etiketleme standardı, hesap bazlı bütçe ve uyarılar, harcamanın birimlere atanması (gösterim ve geri yansıtma) temel yöntemlerdir. Maliyet verisi ekiplerle paylaşıldığında, sorumluluk bilinci gelişir.

Yönetişim işletim modeli de netleşmelidir: temel ortamı kim işletir, politika değişikliğini kim onaylar, istisnayı kim verir? Genellikle bir bulut merkez ekibi (platform ekibi) bu rolü alır, uygulama ekipleri ise kendi iş yüklerinden sorumlu olur. Sorumluluk paylaşımı yazılı değilse, güvenlik açıkları "benim işim değil" boşluğunda büyür.

Sık hatalar ve nereden başlanmalı?

Landing zone projelerinde tekrar eden hatalar: • Tasarımı atlayıp doğrudan kuruluma geçmek. • Bütün olasılıkları ilk günde kurmaya çalışıp projeyi geciktirmek; küçük ve genişletilebilir temelle başlamak daha sağlıklıdır. • Hesap hiyerarşisini kurumsal organizasyon şemasına birebir kopyalamak; hiyerarşi, güvenlik ve uyum gereksinimine göre düşünülmelidir. • Politikaları hepsini birden sert uygulamak; önce izleme modunda başlayıp aşamalı sıkılaştırmak ekipleri tıkamaz. • Merkez ekibi sahipsiz bırakmak. • Maliyet etiketlemesini sonraya bırakmak.

Nereden başlanır: önce hedef iş yüklerini ve düzenleyici gereksinimleri anlayın, sonra hesap hiyerarşisini ve kimlik modelini tasarlayın, ardından ağ ve güvenliği kurun, en sonunda otomasyon ve yönetişimi oturtun.

Mindset kataloğunda Azure Landing Zone ve Cloud Adoption Framework Tasarımı, AWS Organizations ve Landing Zone ile Çoklu Hesap Yönetimi ve Bulut Yönetişimi: Landing Zone, Politika ve Kontrollerin Tasarımı programları bu başlığı sağlayıcı bazında ve sağlayıcıdan bağımsız ele alır.