Creazione di una policy di accesso per concedere l'accesso ad account di proprietà

Nello scenario 1, come utente amministrativo nell'account A, disponi del controllo completo sul bucket Amazon S3 in cui CloudTrail scrive i file di log per gli account B e C. Vuoi condividere i file di log di ciascuna business unit con la business unit che ha creato tali file. Tuttavia, non vuoi che una business unit sia in grado di leggere i file di log di tutte le altre.

Ad esempio, per condividere i file di log dell'account B con l'account B ma non con l'account C, nell'account A devi creare un nuovo ruolo IAM che specifichi che l'account B è un account attendibile. Questa policy di attendibilità del ruolo specifica che l'account B può essere considerato attendibile per l'assunzione del ruolo creato dall'account A. La policy dovrebbe essere simile all'esempio seguente. La policy di attendibilità viene creata automaticamente se crei il ruolo utilizzando la console. Se utilizzi l'SDK per creare il ruolo, devi specificare la policy di attendibilità come parametro nell'API CreateRole. Se utilizzi la CLI per creare il ruolo, devi specificare la policy di attendibilità nel comando CLI create-role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::account-B-id:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}    

Devi inoltre creare una policy di accesso per specificare che l'account B può leggere solo dalla posizione in cui l'account B scrive i propri file di log. La policy di accesso sarà simile all'esempio seguente. Nota che l'ARN del parametro Resource include l'ID account a dodici cifre per l'account B e l'eventuale prefisso specificato quando è stato attivato CloudTrail per l'account B durante il processo di aggregazione. Per ulteriori informazioni sulla specifica di un prefisso, consulta Attivazione di CloudTrail in account aggiuntivi.

Importante

Devi verificare che il prefisso nella policy di accesso sia identico al prefisso utilizzato quando hai attivato CloudTrail per l'account B. Se non è uguale, devi modificare la policy di accesso del ruolo IAM nell'account A in modo da includere il prefisso effettivo per l'account B. Se il prefisso nella policy di accesso del ruolo non è esattamente identico al prefisso specificato quando hai attivato CloudTrail nell'account B, l'account B non potrà accedere ai relativi file di log.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "arn:aws:s3:::bucket-name/prefix/AWSLogs/account-B-id/*"
    }, 
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "arn:aws:s3:::bucket-name"
    }
  ]
}
  

Il ruolo creato per l'account C sarà quasi identico a quello creato per l'account B. La policy di accesso per ciascun ruolo deve includere l'ID account e il prefisso appropriati, in modo che ogni account sia in grado di leggere solo nel percorso in cui CloudTrail ha scritto i file di log dell'account.

Dopo aver creato i ruoli per ogni account e aver specificato le policy di attendibilità e accesso appropriati, nonché dopo che a un utente IAM in ogni account è stato concesso l'accesso dall'amministratore di tale account, un utente IAM nell'account B o C potrà assumere il ruolo a livello di programmazione.

Dopo aver creato i ruoli per ciascun account e specificato le policy di attendibilità e accesso corrette, un utente IAM in uno dei nuovi account attendibili (B o C) deve assumere il ruolo a livello di programmazione per poter leggere i file di log dal bucket Amazon S3.

Per ulteriori informazioni, consulta . Assunzione di un ruolo.