Bulut Landing Zone Tasarımı: Hesap Yapısı, Kimlik ve Ağ Kontrolleri

Buluta taşınan ilk iş yükleri çoğu zaman hızla oluşturulan tek bir hesapta başlar. Geliştirme, test ve üretim kaynakları aynı yönetim alanında büyüdükçe yetkiler, ağ bağlantıları, günlükler ve maliyet sahipliği birbirine karışabilir. Daha sonra eklenen her ekip bu ilk tercihleri miras alır. Düzeltme, çalışan iş yüklerini yeni yapıya taşımayı gerektirdiği için başlangıçta kurulacak temel önemlidir.

Landing zone, bulut iş yüklerinin yerleşeceği yönetilen başlangıç ortamıdır. Hesap ya da abonelik hiyerarşisini, kimlik modelini, ağ topolojisini, güvenlik politikalarını, günlükleri, maliyet etiketlerini ve otomasyon yaklaşımını birlikte tanımlar. Tek seferlik bir şablon değil, yeni iş yükleri geldikçe genişleyen ve sürüm kontrollü biçimde güncellenen bir platform ürünüdür.

Landing zone kapsamı

İyi bir landing zone, her uygulamanın aynı altyapıyı kullanmasını zorunlu kılmaz. Ortak kuralları ve paylaşılan hizmetleri sağlar; iş yükü ekiplerine bu sınırlar içinde hareket edebilecekleri ayrı alanlar verir. Merkezî kimlik, temel ağ bağlantısı, denetim günlükleri, güvenlik ilkeleri ve maliyet görünürlüğü platform seviyesinde yönetilir. Uygulama kaynakları ise üretim yaşam döngüsüne uygun ayrı alanlarda bulunur.

Kapsam belirlenirken ilk soru hangi bulut hizmetinin seçileceği değil, hangi risklerin merkezî yönetileceğidir. Kimlik ve ayrıcalıklı erişim, dış bağlantılar, veri konumu, şifreleme, günlük saklama ve olay müdahalesi ortak karar gerektirir. Uygulamaya özgü ölçekleme veya çalışma zamanı seçimi ise iş yükü ekibinde kalabilir. Bu ayrım, merkezî ekibin darboğaza dönüşmesini önler.

Hesap ve kaynak hiyerarşisi

Tek bir hesap altında çok sayıda iş yükü çalıştırmak erişim sınırlarını, faturalamayı ve olay etkisini belirsizleştirir. Hesap, abonelik ya da proje gibi sağlayıcıya özgü yönetim birimleri güvenlik ve sahiplik sınırı olarak kullanılmalıdır. Üretim ile üretim dışı ortamlar ayrılmalı; kritik veriler ve yüksek ayrıcalıklı platform hizmetleri gerektiğinde ayrıca bölünmelidir.

Hiyerarşi doğrudan organizasyon şemasını kopyalamamalıdır. Birimler değişebilir, ancak güvenlik ve işletim gereksinimleri daha kalıcıdır. Platform, güvenlik, bağlantı, günlükleme ve iş yükü alanları gibi işlevsel bir yapı çoğu durumda daha dayanıklıdır. Her alanın sahibi, bütçe sorumluluğu, izin verilen bölgeler ve yaşam döngüsü tanımlanmalıdır.

Yeni alan oluşturma işlemi elle yapılan bilet sürecine bırakılmamalıdır. Onaylı bir talep, gerekli etiketleri, bütçe eşiklerini, günlük hedeflerini, temel politikaları ve ağ bağlantısını otomatik olarak üretmelidir. Böylece her yeni iş yükü aynı asgari korumayla başlar. İstisnalar ayrı kayıt, süre ve onay gerektirmelidir.

Kimlik ve ayrıcalıklı erişim

Bulut yerel hesapları yerine merkezî kimlik kaynağı kullanılmalı, çalışan yaşam döngüsü ile erişim yaşam döngüsü bağlanmalıdır. İşe başlayan, görev değiştiren veya ayrılan bir kişinin hakları gecikmeden güncellenebilmelidir. Roller doğrudan kişilere değil, yönetilen gruplara ve işlevlere atanmalıdır. Kalıcı geniş yetkiler yerine görev süresi kadar verilen ayrıcalıklar tercih edilmelidir.

Acil durum hesapları günlük kullanım için uygun değildir. Bu hesaplar güçlü biçimde korunmalı, normal kimlik altyapısından bağımsız çalışabilmeli ve her kullanımları alarm üretmelidir. Erişim anahtarları, uygulama parolaları ve sertifikalar merkezî sır yönetiminde tutulmalı; kaynak koduna veya kullanıcı cihazına bırakılmamalıdır.

İş yükü kimlikleri de insan kimliklerinden ayrı ele alınmalıdır. Uygulamalar mümkün olduğunda kısa ömürlü belirteçlerle ve kaynak rolüyle çalışmalı, sabit anahtar kullanmamalıdır. Bir hizmetin başka bir hizmete erişimi, bulunduğu ağdan çok doğrulanmış iş yükü kimliği ve gerekli işlem kapsamına göre verilmelidir. NIST SP 800-210, bulut hizmet modellerinde erişim kontrolünün bileşen ve hizmet katmanlarına göre ele alınmasını önerir.

Ağ DNS ve dış bağlantılar

Landing zone ağ tasarımı, bütün trafiği tek merkezden geçirmek ile her ekibi tamamen serbest bırakmak arasında dengeli olmalıdır. Paylaşılan bağlantı, güvenlik duvarı, özel ad çözümleme ve kurum içi ağ geçitleri platform alanında yönetilebilir. İş yükü ağları risk, ortam ve bağlantı gereksinimine göre ayrılmalı; aralarındaki bağlantılar varsayılan olarak kısıtlanmalı ve yalnızca tanımlı akışlara göre açılmalıdır.

IP adres planı, bulut hesabı açılmadan önce hazırlanmalıdır. Çakışan adresler, daha sonra kurulacak özel bağlantıları ve şirket içi ağ bütünleştirmesini zorlaştırır. Ad çözümleme de aynı planda yer almalıdır. Özel bölgelerin sahibi, ileri ve geri sorguların yolu, kayıt yaşam döngüsü ve farklı ortamlar arasındaki görünürlük belirlenmelidir.

İnternete giden trafik için açık bir çıkış politikası gerekir. İş yüklerinin doğrudan dış IP alması yerine denetlenen çıkış noktaları, alan adı ya da hedef kısıtları ve akış günlükleri kullanılabilir. Ancak merkezî çıkış katmanı tek hata noktası olmamalıdır. Bölgesel arıza, kapasite ve bağımlılık senaryoları test edilmelidir.

Politika kod ve gözlemlenebilirlik

Temel kurallar mümkün olduğunca politika olarak kodlanmalıdır. İzin verilmeyen bölgeler, genel erişime açık depolama, şifreleme zorunluluğu, günlükleme ve etiketler otomatik denetlenebilir. Önleyici kontrol, risk kesin ve etkisi anlaşılır olduğunda uygundur. Bazı kontroller önce yalnızca raporlayarak çalıştırılmalı, mevcut iş yükleri üzerindeki etkisi görüldükten sonra zorunlu hâle getirilmelidir.

Altyapı kodu landing zone değişikliklerini gözden geçirilebilir ve tekrarlanabilir kılar. Ağ, politika, hesap üretimi ve günlük hedefleri sürüm kontrolünde tutulur. Değişiklikler önce test ortamında doğrulanır; başarısızlık durumunda geri dönüş yolu bulunur. Yönetim arayüzünden yapılan doğrudan değişiklikler ya engellenmeli ya da yapı sapması olarak tespit edilmelidir.

Denetim günlükleri kaynak hesabında tek başına tutulmamalıdır. Ayrı ve kısıtlı bir günlük alanına gönderilmeli, kaynak yöneticilerinin geçmişi silememesi sağlanmalıdır. Kimlik olayları, yönetim işlemleri, ağ akışları ve politika ihlalleri ortak zaman çizelgesinde aranabilmelidir. Saklama süresi, olay araştırması ve mevzuat ihtiyacına göre tanımlanmalıdır.

Veri güvenliği ve iş yükü sınırları

Veri sınıflandırması, landing zone politikasına çevrilmelidir. Hassas verinin izin verilen bölgesi, şifreleme anahtarının sahibi, yedek konumu ve dışa aktarım koşulları belirlenir. Anahtar yönetimi uygulama hesabından ayrılabilir; anahtar kullanımı ve politika değişiklikleri ayrıca günlüğe alınabilir. Şifreleme tek başına erişim kontrolünün yerini tutmaz.

Üretim, test ve geliştirme ortamları yalnızca adlandırma etiketiyle ayrılmamalıdır. Ayrı yönetim alanları, ayrı yetki grupları ve kontrollü veri akışı kullanılmalıdır. Gerçek üretim verisinin test ortamına kopyalanması sınırlandırılmalı; gerekiyorsa maskeleme veya sentetik veri uygulanmalıdır. Bir ortamdaki ele geçirilmenin diğerine sıçramasını önleyen sınırlar açıkça test edilmelidir.

İşletim modeli ve değişiklik yönetimi

Landing zone yalnızca kurulum projesi olarak görülürse kısa sürede eski kalır. Bulut hizmetleri, tehditler ve iç gereksinimler değiştikçe platform ekibi temel modülleri güncellemelidir. Her sürüm için etki analizi, test sonucu, geçiş notu ve geri dönüş adımı bulunmalıdır. İş yükü ekipleri güncellemenin ne zaman zorunlu olduğunu ve hangi hazırlığı yapacağını bilmelidir.

Platform ekibi ölçülebilir hizmet seviyeleri tanımlayabilir. Yeni hesap oluşturma süresi, politika ihlalini tespit etme süresi, günlük teslimat başarısı, ayrıcalıklı erişim süresi ve yapı sapması sayısı izlenebilir. Yalnızca kaynak sayısı veya bulut harcaması, yönetişim kalitesini göstermez.

Maliyet yönetimi de temel tasarıma eklenmelidir. Zorunlu etiketler, bütçe eşikleri, beklenmeyen harcama alarmı ve kullanılmayan kaynak raporu her alanda çalışmalıdır. Ortak platform maliyetinin iş yüklerine nasıl dağıtılacağı baştan açıklanırsa sahiplik tartışmaları azalır.

Sık yapılan hatalar

İlk hata, landing zone tamamlanana kadar hiçbir iş yükünü taşımamaktır. Aşırı kapsamlı tasarım aylar sürebilir ve gerçek kullanım bilgisi olmadan yanlış varsayımlar üretir. Asgari güvenli temel, temsilî bir iş yüküyle doğrulanmalı ve aşamalı genişletilmelidir. İkinci hata, her kontrolü merkezî ekibin manuel onayına bağlamaktır. Açık politikalar ve otomatik koruma sınırları ekiplerin güvenli biçimde kendi işini yapmasını sağlamalıdır.

Diğer hatalar; üretim ve geliştirmeyi aynı hesapta tutmak, yönetici haklarını kalıcı vermek, günlükleri kaynak yöneticisinin silebildiği yerde saklamak, ağ ve DNS sahipliğini belirsiz bırakmak, altyapı kodu dışında değişiklik yapmak ve istisnaları süresiz açık tutmaktır. Landing zone bir güvenlik ürünü satın almakla tamamlanmaz; kimlik, ağ, politika ve işletim kararlarının birlikte çalışması gerekir.

Aşamalı uygulama planı

İlk aşamada mevcut hesaplar, kimlik kaynakları, ağ bağlantıları ve mevzuat gereksinimleri çıkarılır. İkinci aşamada asgari yönetim hiyerarşisi, merkezî günlükleme, kimlik federasyonu ve temel politika seti kurulur. Üçüncü aşamada düşük riskli bir iş yükü yeni alana alınır; erişim, ağ, yedekleme ve maliyet görünürlüğü uçtan uca test edilir.

Dördüncü aşamada hesap üretimi ve politika dağıtımı altyapı koduyla otomatikleştirilir. Beşinci aşamada üretim, veri ve ayrıcalıklı yönetim sınırları güçlendirilir; mevcut iş yükleri planlı dalgalarla taşınır. Son aşamada yapı sapması, istisna süresi ve kontrol etkinliği düzenli olarak gözden geçirilir.