Birden çok geliştirme ekibi, paylaşılan bir üretim AWS hesabına üretim iş yükleri dağıtır. Yakın zamanda, bir geliştirme ekibinin üyeleri, başka bir ekibe ait bir EC2 instance'ı sonlandırdı. Geliştiriciler, rolleri üstlenmek için AWS Organizations aracılığıyla SAML federasyonunu kullanır. Geliştiricilerin kendi instance'larını yönetmelerine izin verirken, diğer ekiplere ait instance'ları yönetmelerini engellemeniz gerekmektedir. Hangi strateji bu gereksinimleri karşılar?

Doğru cevap, geliştiricilerin kendi birimlerine ait EC2 örneklerini yönetmelerine izin verirken, diğer birimlere ait örnekleri yönetmelerini engellemek için en etkili ve esnek yolu sunar. SAML federasyonu sırasında bir oturum etiketi (DevelopmentUnit) geçirmek, geliştiricinin kimliğini AWS'ye taşır. IAM politikasına eklenen bir deny (reddetme) kuralı, geliştiricinin oturum etiketi (aws:PrincipalTag/DevelopmentUnit) ile EC2 örneğinin kaynak etiketi (DevelopmentUnit) eşleşmediğinde sonlandırma gibi eylemleri engeller. Bu, geliştiricilerin yalnızca kendi birimlerinin etiketine sahip kaynaklar üzerinde işlem yapabilmesini sağlar. Diğer seçenekler neden doğru değil: Ayrı OU'lar ve SCP'ler oluşturmak, kaynak etiketlerine dayalı ayrıntılı kontrol sağlamaz ve her birim için ayrı OU'lar oluşturmak yönetim yükünü artırır. SCP'ler genellikle daha geniş, üst düzey izin kontrolleri için kullanılır. SCP'yi root OU'ya atamak ve bir allow (izin verme) eylemi kullanmak, belirli birimlerin kaynaklarını yönetme esnekliğini kısıtlar ve diğer birimlerin kaynaklarına yanlışlıkla erişimi engelleyemez. Her geliştirme birimi için ayrı IAM politikaları oluşturmak ve bunları SAML federasyonu sırasında atamak, yönetim karmaşıklığını artırır ve mevcut senaryoda istenen deny mantığını doğrudan uygulamaz.