Kurumsal cloud mimarilerinde kimlik, log, ağ ve otomasyon katmanları büyüdükçe kritik bir soru ortaya çıkar: yönetim düzlemini üretim kaynaklarından gerçekten ne kadar ayırdık? Birçok kurum “management account” açtığını düşünür; fakat bu hesap aynı CI anahtarlarını, aynı IAM rollerini ve aynı ağ çıkış kurallarını paylaşıyorsa ayrım büyük ölçüde teorik kalır. Daha güvenli yaklaşım, yönetim düzlemi için kontrollü ve sıkılaştırılmış bir karantina hesabı tasarlamaktır.
Karantina hesabı neyi amaçlar?
Amaç yönetim servislerini merkezileştirmek değildir; onların patlama yarıçapını küçültmektir. Özellikle şu bileşenler bu hesaba adaydır:
- IAM otomasyonu
- Merkezi denetim logları
- Policy as code yürütücüleri
- Güvenlik tarama orkestrasyonu
- Break-glass ve acil erişim kasaları
Bu bileşenler doğrudan üretim hesaplarında çalıştığında tek bir anahtar sızıntısı veya yanlış rol zinciri, tüm platform üzerinde kontrol kaybına yol açabilir.
Neden mevcut shared services hesabı yetmeyebilir?
Çünkü shared services hesabı genelde kolaylık odaklı büyür. CI, artefact repo, gözlemlenebilirlik ajanları ve platform servisleri aynı yerde toplanır. Bu yaklaşım operasyonu hızlandırabilir; ancak güven sınırı açısından sorunludur. Karantina hesabı ise tersine şu prensiple kurulur:
- Daha az insan erişimi
- Daha kısa ömürlü oturum
- Daha dar ağ çıkışı
- Daha güçlü denetim kayıtları
- Daha yavaş ama kontrollü değişiklik akışı
Yani amaç konfor değil, güvenli kontrol noktası oluşturmaktır.
Temel tasarım kararları neler?
Ben bu mimaride dört kararın kritik olduğunu görüyorum:
- Tek yönlü yönetim akışı: Yönetim hesabı üretim hesaplarına komut gönderebilir; ters yön sınırlı olmalıdır.
- Ayrı kimlik yolu: İnsan erişimi ile makine erişimi aynı role zincirlenmemelidir.
- Bölgesel kayıt koruması: Audit log’lar yalnızca tek bölgeye bağlı kalmamalıdır.
- Acil durum istisnası: Break-glass erişim normal akıştan ayrı kasada tutulmalıdır.
Bu kararlar alınmadan açılan her “management account”, güvenli görünse de pratikte başka bir shared account’a dönüşür.
Ağ ve erişim sınırı nasıl kurulmalı?
Karantina hesabının internet çıkışı, artefact erişimi ve üretim hesaplarıyla konuşma kuralları olabildiğince dar olmalıdır. Özellikle şu kontroller faydalıdır:
- Sadece onaylı egress hedefleri
- Ayrı DNS çözümleme politikası
- Yönetim araçları için kısa ömürlü erişim oturumları
- İnteraktif erişim yerine kayıtlı otomasyon akışı
- Her role için zorunlu gerekçe veya ticket bağlamı
Bu yaklaşım operasyonu biraz yavaşlatır, fakat yanlışlıkla tüm organizasyona yayılan etkiyi ciddi biçimde azaltır.
Platform ekipleri için bedeli nedir?
Her güvenli mimarinin operasyon maliyeti vardır. Karantina hesabı da istisna değildir. Daha fazla rol ayrımı, daha fazla onay akışı ve daha sıkı ağ kuralı gerektirir. Fakat bu maliyet özellikle çok hesaplı veya regülasyon baskısı altındaki yapılarda mantıklıdır. Çünkü yönetim düzleminin ele geçirilmesi, tek uygulama hesabı ihlalinden çok daha geniş etki üretir.
Burada önemli olan, karantina hesabını her şeyi içine alan yeni bir merkez değil, sadece kritik kontrol fonksiyonlarının yaşadığı sınırlı bir alan olarak tutmaktır.
Sonuç
Kurumsal bulutta yönetim düzlemi karantina hesabı, güvenlik ekibi için ekstra bir katılık değil; platform riskini mühendislik seviyesinde sınırlandırma yöntemidir. Yönetim servisleri ayrı kimlik, ayrı ağ ve ayrı denetim varsayımlarıyla işletildiğinde; üretim hesaplarında oluşan hatalar veya sızıntılar doğrudan tüm organizasyon kontrolüne sıçramaz. Modern cloud mimarisinde gerçek olgunluk bazen daha fazla servis eklemekten değil, en kritik servisleri daha az güven varsayımıyla çalıştırmaktan geçer.