Organizations, OU'lar ve SCP Stratejisi

AWS Organizations, birçok AWS hesabını tek bir yapı olarak merkezi biçimde yönetmenizi sağlar. Bu yapı içinde Service Control Policies (SCPs) izin tavanlarını belirler ve Organizational Units (OUs) politika hedeflemesi için hesapları gruplandırır. Bu hiyerarşiyi iyi tasarlamak, SCS-C02 sınavının yönetişim alanı için temel bir beceridir.

Bir kuruluşun en üstünde bir yönetim hesabı (eski adıyla ana hesap), bir kök kapsayıcı ve üye hesapları gruplamak için iç içe yerleştirilebilen OU'lar bulunur. Herhangi bir düzeye eklenen politikalar, o düzeyin altındaki her şeye aktarılır. Bu ağaç yapısı, tek bir eklemeyle denetimleri geniş veya dar kapsamda uygulamanızı sağlar.

Organizational Unit (OU), yönetişim gereksinimleri ortak olan hesapları gruplandırır; örneğin bir "Production" OU'su, bir "Sandbox" OU'su ve bir "Security" OU'su. Bir OU'ya SCP eklemek, bu politikayı içindeki her hesaba uygular; böylece hesapları devralmaları gereken politikalara göre düzenlersiniz.

SCP'ler ağaç boyunca devralınır: bir hesap; kökte, üst OU'larında ve kendisinde bulunan SCP'lerin birleşimi tarafından yönetilir. Bir eyleme izin verilebilmesi için her düzeyde izin verilmiş olması gerekir. Zincirin herhangi bir yerindeki ret, eylemi engeller. Bu birikimli etki, SCP tasarımının temelidir.

İki strateji vardır. Ret listesi, varsayılan FullAWSAccess ile başlar ve CloudTrail'ı devre dışı bırakmak gibi hiçbir zaman istemediğiniz işlemler için açık retler ekler. İzin listesi FullAWSAccess'i kaldırır ve yalnızca izin verilen hizmetleri açıkça listeler; bu çok daha katı bir yaklaşımdır. Çoğu kuruluş esneklik için ret listesiyle başlar.

Bu SCP, herhangi bir kişinin CloudTrail günlük kaydını durdurmasını engeller. Bu, hiçbir üye hesabın denetim izini körleştirememesi için kuruluş genelinde uygulanan yaygın bir güvenlik korumasıdır.

Hayati bir kural: SCP'ler asla izin vermez; yalnızca üst sınırı belirler. Bir eyleme, hesapta hem bir SCP hem de bir IAM ilkesi tarafından izin verilmelidir. Yalnızca izin verilenler listesini kullanan bir SCP, hizmetlerin verilebilmesini sağlar; bunlara yine IAM tarafından izin verilmesi gerekir.

SCP'ler yönetim hesabına uygulanmaz ve hizmete bağlı rolleri etkilemez. Ayrıca bazı durumlarda kuruluş dışından gelen kaynak tabanlı ilke izinlerine dokunmazlar. Bu istisnaları bilmek, bir senaryoda SCP'nin aslında engelleyemeyeceği bir şeyi engellemesi beklendiğinde yanlış yanıt vermenizi önler.

İki klasik koruyucu SCP, kuruluştan ayrılmayı (organizations:LeaveOrganization) ve üye hesapların GuardDuty, Security Hub, Yapılandırma ve CloudTrail gibi güvenlik hizmetlerini devre dışı bırakmasını reddeder. Kök düzeyinde uygulandıklarında bunlar, hiçbir üye hesabın kendisini yönetişimden ayıramamasını veya kuruluşun tehdit algılama yeteneğini körleştirememesini sağlar; bu, önemle önerilen bir temel yapılandırmadır.

Yaygın bir tasarım şöyledir: kök düzeyinde temel bir reddetme listesi SCP'si (CloudTrail'i korur, kuruluştan ayrılmayı reddeder, bölgeleri kısıtlar), Üretim OU'sunda daha katı SCP'ler ve bir Deneme Ortamı OU'sunda daha esnek SCP'ler. Hesapları risk profillerine göre OU'larda gruplamak, ilke karmaşasını en aza indirerek yönetişimi hassas biçimde ayarlamanızı sağlar.

Kuruluşlar, hesapları bir kök ve yönetim hesabı altındaki OU'larda yapılandırır. SCP'ler ağaç boyunca miras alınır ve bir eylem için her düzeyde izin gerekir. Reddetme listesi (esnek) veya izin verilenler listesi (katı) stratejisini seçin; SCP'lerin yalnızca üst sınır belirlediğini, asla izin vermediğini ve yönetim hesabına veya hizmete bağlı rollere uygulanmadığını unutmayın.

AWS Kuruluşları, hesapları bir kök ve yönetim hesabı altındaki OU'larda gruplar. SCP'ler ağaç boyunca miras alınır ve her düzeyde izin gerektirir; herhangi bir ret işlemi erişimi engeller. Reddetme listesi (esnek) veya izin verilenler listesi (katı) stratejisini kullanın. SCP'ler yalnızca üst sınır belirler, asla izin vermez ve yönetim hesabına veya hizmete bağlı rollere uygulanmaz.