Un'azienda desidera che gli sviluppatori acquistino software di terze parti approvato solo tramite un Private Marketplace in AWS Marketplace. L'azienda utilizza AWS Organizations con tutte le funzionalità abilitate e dispone di un account di servizi condivisi in ogni OU per i responsabili degli acquisti. L'amministrazione degli acquisti deve essere limitata a un ruolo denominato procurement-manager-role (assumibile dai responsabili degli acquisti). A tutti gli altri utenti, gruppi, ruoli IAM e amministratori di account deve essere negato l'accesso amministrativo al Private Marketplace. Qual è l'architettura PIÙ efficiente per soddisfare questi requisiti?

L'opzione corretta è la più efficiente perché utilizza gli SCP (Service Control Policies) di AWS Organizations per applicare controlli di sicurezza a livello di organizzazione. Creare il ruolo procurement-manager-role solo negli account di servizi condivisi centralizza la gestione e l'accesso. L'SCP a livello di root che nega l'amministrazione del Private Marketplace a tutti tranne il ruolo specificato garantisce che solo i responsabili degli acquisti designati possano gestire il Private Marketplace, anche gli amministratori di account. Il secondo SCP impedisce la creazione di ruoli con lo stesso nome, prevenendo escalation di privilegi. Le altre opzioni sono meno efficienti o non soddisfano tutti i requisiti: La prima opzione richiederebbe la gestione di policy inline su ogni utente/ruolo in ogni account, il che è complesso e soggetto a errori. Inoltre, PowerUserAccess non è la policy corretta per la gestione del Private Marketplace. La seconda opzione usa AdministratorAccess che è troppo permissiva e i "permissions boundary" non negherebbero l'accesso agli amministratori di account, solo limiterebbero le autorizzazioni massime per i ruoli a cui sono applicati. La quarta opzione applica l'SCP solo agli account di servizi condivisi, non a tutti gli account dell'organizzazione, e non impedisce la creazione di ruoli con lo stesso nome in altri account.