AWS'de çoklu hesap yapısı nasıl kurulur ve yönetilir

Neden tek hesap yerine çoklu hesap?

AWS dokümantasyonu, hesapları izin, güvenlik, maliyet ve iş yükü açısından doğal sınırlar olarak tanımlar. Tek bir hesapta geliştirme, test ve üretim ortamını bir arada tutarsanız bir yazılımcının yanlış bir silme komutu üretimi etkileyebilir, maliyet kalemleri birbirine karışır, denetçiye "kim neye erişebiliyor" sorusunu yanıtlamak zorlaşır.

Çoklu hesap yapısında her ortam ve her iş yükü kendi hesabında yaşar. Bir hesaptaki hata ya da güvenlik ihlali diğerlerine yayılmaz; maliyet doğrudan hesaba bakılarak ayrıştırılır; erişim, hesap bazında verilir. Bu yapıyı elle yönetmek birkaç hesaptan sonra zorlaşır. İşte AWS Organizations hesapları bir arada örgütlemek ve politika uygulamak için, AWS Control Tower ise bu yapıyı önerilen en iyi uygulamalarla hazır kurmak ve sürekli denetlemek için vardır.

Organizations'ın yapı taşları

AWS Organizations'ı kavramak için önce parçaları ayırmak gerekir:

• Yönetim hesabı (management account): organizasyonu oluşturan ve faturayı ödeyen hesap. Üzerinde iş yükü çalıştırılmaz; yetkisi geniş olduğu için erişimi sıkı tutulur.
• Üye hesaplar: iş yüklerinin yaşadığı hesaplar. Programatik olarak AWS CLI, SDK veya API ile açılabilir.
• Organizasyon birimi (OU): hesapları gruplayan hiyerarşik kap. Örneğin güvenlik, altyapı, iş yükleri, korumalı alan (sandbox) ve askıya alınmış hesaplar için ayrı birimler kurulabilir.
• Politikalar: hizmet kontrol politikaları (SCP), kaynak kontrol politikaları (RCP), etiket politikaları ve yedekleme politikaları gibi türler vardır. Politika OU'ya bağlandığında altındaki tüm hesaplara iner.
• Birleşik fatura: tüm hesaplar tek ödeme yöntemiyle tek faturada toplanır, kullanım Cost Explorer ile hesap bazında izlenir.

SCP bir izin vermez; yalnızca hesabın kullanabileceği eylemlerin üst sınırını belirler. Bir kullanıcının gerçekten bir eylemi yapabilmesi için hem SCP'nin hem de kendi IAM yetkisinin buna izin vermesi gerekir.

OU hiyerarşisi nasıl tasarlanır

OU yapısını şirketin organizasyon şemasına göre değil, politika ihtiyacına göre kurun. Aynı güvenlik kurallarına tabi hesaplar aynı OU'da olmalıdır. Sık görülen bir başlangıç iskeleti şöyledir:

• Güvenlik OU'su: merkezi log arşivi ve güvenlik denetim hesapları.
• Altyapı OU'su: ortak ağ, kimlik ve paylaşılan servis hesapları.
• İş yükleri OU'su: altında üretim ve üretim dışı alt birimler; her uygulama ya da ürün ekibi için ayrı hesap.
• Sandbox OU'su: geliştiricilerin serbestçe deneme yaptığı, bütçe ve bölge sınırlarıyla kısıtlanmış hesaplar.
• Askıya alınanlar OU'su: kapatılacak hesapların hiçbir şey yapamayacağı bir sınır içinde bekletildiği birim.

Derin iç içe hiyerarşi kurmaktan kaçının. Politika mirası her seviyede çarpan etkisi yaratır ve "bu hesap neden bu eylemi yapamıyor" sorusu hata ayıklaması zor bir bulmacaya dönüşür. Hesap sahiplerini ve maliyet merkezini etiketlerle kayıt altına alın.

Control Tower ile landing zone kurulumu

Control Tower, Organizations, Service Catalog ve IAM Identity Center gibi hizmetleri bir araya getirerek bir landing zone oluşturur. Landing zone, OU'ları, hesapları, kullanıcıları ve uyum denetimine tabi tüm kaynakları tutan kurumsal kaptır.

Kurulumdaki tipik akış şöyledir:

• Yönetim hesabında ana bölgeyi (home region) seçin. Bu seçim veri yerleşimini etkilediği için kurumsal politikanızla birlikte karar verin.
• Landing zone'u başlatın; Control Tower güvenlik ve log arşivi hesaplarını ve temel OU'ları sizin için oluşturur.
• Kimlik erişimini IAM Identity Center üzerinden kurumsal dizininizle bağlayın; kişiler hesaplara rol bazlı izin setleriyle girsin, hesap bazında IAM kullanıcısı açılmasın.
• Mevcut organizasyonunuz varsa OU'ları kaydedin ve mevcut hesapları Control Tower'a kayıt edin (enroll). Böylece yeni kurulum yerine kademeli geçiş yapabilirsiniz.

Her güncellemede landing zone sürümü yükseltilebilir. Yükseltmeyi üretim dışı bir OU ile deneyip sonra yaygınlaştırmak güvenli yoldur.

Kontroller: önleyici, tespit edici ve proaktif

Control Tower'ın yönetişim dili kontrollerdir (eski adıyla guardrail). Davranışlarına göre üç türe ayrılırlar:

• Önleyici kontrol: ihlale yol açacak eylemi engeller. SCP, RCP ve bildirimsel politikalarla uygulanır. Durumu zorunlu uygulanıyor (enforced) ya da etkin değil biçimindedir.
• Tespit edici kontrol: ihlali bulur ve panoda raporlar. AWS Config kurallarıyla uygulanır. Durumu temiz, ihlalde ya da etkin değil olarak görünür.
• Proaktif kontrol: kaynak oluşturulmadan önce CloudFormation hook'ları ile şablonu denetler; uyumsuz kaynak hiç oluşturulmaz.

Bunlardan bağımsız olarak kılavuz kategorisi vardır: zorunlu, güçlü önerilen ve isteğe bağlı. Güçlü önerilen ve isteğe bağlı kontroller OU düzeyinde açılır ve o OU'daki tüm hesaplara uygulanır.

Örnek senaryo: İş yükleri OU'sunda yalnızca onaylı bölgelerde kaynak oluşturulmasına izin veren bir önleyici kontrol açılır, aynı OU'da genel erişime açık depolama kovasını yakalayan bir tespit edici kontrol da çalıştırılır. İlki hatayı oluşmadan keser, ikincisi kaçak kalan durumu görünür kılar.

Account Factory ile hesap üretimi ve özelleştirme

Account Factory, yeni hesapları önceden onaylanmış yapılandırmayla açan bir şablondur ve altta Service Catalog ürünleri olarak çalışır. Ekipler hesap talebini kendileri başlatır; merkezi bulut ekibi hesabın hangi OU'ya düşeceğini, hangi ağ ve temel kaynaklarla geleceğini önceden tanımlar.

Standart bir hesabın kurulumunda genellikle şunlar otomatikleşir:

• Doğru OU'ya yerleştirme ve o OU'nun kontrollerinin devralınması
• Merkezi log hesabına denetim izlerinin akıtılması
• Temel ağ, kimlik ve alarm kaynaklarının bir şablonla kurulması
• Hesap sahibi ve maliyet merkezi etiketlerinin eklenmesi

Temel kaynakların her hesapta aynı biçimde gelmesi için özelleştirme mekanizması kullanılır; şablonlar kod olarak sürüm kontrolünde tutulur ve değişiklikler gözden geçirme sonrası yayınlanır. Böylece hesap açmak biletle haftalarca beklenen bir iş olmaktan çıkar, denetlenebilir bir otomasyona dönüşür.

Sapma yönetimi ve sık yapılan hatalar

Sapma (drift), yapının önerilen en iyi uygulamalardan ayrılmasıdır. Birisi Organizations konsolundan bir OU'yu taşırsa ya da bir SCP'yi elle değiştirirse Control Tower bunu sapma olarak işaretler. Pano, uyumsuz kaynakları hesap ve OU bazında gösterir; sapma çözülmeden landing zone güncellenemeyebilir.

Sık hatalar ve önlemleri:

• Yönetim hesabında iş yükü çalıştırmak: üretim kaynaklarını ayrı hesaba taşıyın, yönetim hesabına erişimi dar tutun.
• SCP'yi kök seviyesine tek hamlede uygulamak: önce sandbox OU'sunda deneyin, etkisini günlüklerden izleyin.
• Her takım için ayrı OU açıp hiyerarşiyi şişirmek: politika ihtiyacı farklı değilse aynı OU'da kalın.
• Konsoldan elle değişiklik yapmak: tüm değişiklikleri kod ve değişiklik kaydı üzerinden geçirin ki sapma uyarıları anlamlı kalsın.
• Hesap kapatma sürecini tanımlamamak: askıya alma OU'su ve sorumlu atamasıyla sahipsiz hesap birikmesini önleyin.

Mindset programında bu beceri

AWS Control Tower ile Bulut Hesap Yönetişimi eğitimi, bulut platform ve güvenlik ekiplerinin çoklu hesap düzenini kurma ve işletme sorumluluğuna yöneliktir. İçerik yönetişim mimarisi ve landing zone kurulumundan koruma kuralları ve politika katmanına, hesap fabrikası ve sağlama otomasyonundan sapma yönetimine ilerler.

Bu yol, birden çok iş birimi ya da bağlı şirketi aynı bulut kuruluşunda yöneten ekipler için uygundur. Kurumsal ekipler eğitimi kendi OU taslakları ve uyum gereksinimleriyle eşleştirerek ilerleyebilir; çalışma, yaygınlaştırma planı ve vaka atölyesi ile sonlanır.