Esempi di policy per la delega dell'accesso

Gli esempi seguenti mostrano come è possibile consentire o concedere un Account AWS accesso alle risorse di un altro Account AWS. Per informazioni su come creare una IAM politica utilizzando questi documenti di esempioJSON, vedereCreazione di politiche utilizzando l'JSONeditor.

Utilizzo dei ruoli per delegare l'accesso alle risorse di un altro Account AWS risorse

Per un tutorial che mostra come utilizzare IAM i ruoli per concedere agli utenti di un account l'accesso a AWS risorse che si trovano in un altro account, vediIAMtutorial: delega l'accesso attraverso AWS account che utilizzano ruoli IAM.

Importante

È possibile includere le informazioni ARN relative a un ruolo o a un utente specifico nell'Principalelemento di una politica di attendibilità dei ruoli. Quando salvi la policy, AWS lo trasforma in ARN un ID principale univoco. Ciò aiuta a mitigare il rischio che qualcuno aumenti i propri privilegi rimuovendo e ricreando il ruolo o l'utente. Normalmente non si vede questo ID nella console, perché c'è anche una trasformazione inversa al momento in ARN cui viene visualizzata la politica di attendibilità. Tuttavia, se si elimina il ruolo o l'utente, la relazione viene interrotta. La policy non è più applicabile, anche se si ricrea l'utente o il ruolo perché non corrisponde all'ID principale archiviato nella policy di attendibilità. Quando ciò accade, l'ID principale viene visualizzato nella console perché AWS non posso più mapparlo su unARN. Il risultato è che se si elimina e si ricrea un utente o un ruolo a cui si fa riferimento in un Principal elemento di una politica di fiducia, è necessario modificare il ruolo per sostituire il. ARN L'utente o il ruolo viene trasformato nel nuovo ID principale quando si salva la policy.

Utilizzo di una policy per delegare l'accesso ai servizi

L'esempio seguente mostra una policy che può essere collegata a un ruolo. La policy abilita due servizi, Amazon EMR e AWS Data Pipeline, per assumere il ruolo. I servizi possono eseguire qualsiasi attività concesse da una policy di autorizzazioni assegnata al ruolo (non visualizzato). Per specificare più principali del servizio, non si specificano due elementi Service, è possibile averne solo uno. Utilizzare invece una serie di principali del servizio come il valore di un elemento singolo Service.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "elasticmapreduce.amazonaws.com",
          "datapipeline.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Utilizzo di una policy basata sulle risorse per delegare l'accesso a un bucket Amazon S3 in un altro account

In questo esempio, l'account A utilizza una policy basata sulle risorse (una policy del bucket Amazon S3) per concedere all'account B l'accesso completo al bucket S3 dell'account A. Quindi l'account B crea una politica IAM utente per delegare l'accesso al bucket dell'account A a uno degli utenti dell'account B.

La policy del bucket S3 nell'account A potrebbe essere simile alla policy seguente. In questo esempio, il bucket S3 dell'account A è denominato amzn-s3-demo-bucket e il numero di account B è 111122223333. Non specifica alcun utente o gruppo nell'account B, ma solo l'account stesso.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AccountBAccess1",
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}

In alternativa, l'account A può utilizzare Amazon S3 Access Control Lists (ACLs) per concedere all'account B l'accesso a un bucket S3 o a un singolo oggetto all'interno di un bucket. In tal caso, l'unica cosa che cambia è il modo in cui l'account A concede l'accesso all'account B. L'account B utilizza ancora una politica per delegare l'accesso a un IAM gruppo nell'account B, come descritto nella parte successiva di questo esempio. Per maggiori informazioni sul controllo dell'accesso a bucket e oggetti S3, passa a Controllo accessi nella Guida per l’utente di Amazon Simple Storage Service.

L'amministratore dell'account B potrebbe creare le seguenti policy di esempio. La policy permette l'accesso in lettura a un gruppo o un utente nell'account B. La policy precedente concede l'accesso all'account B. Tuttavia, i singoli gruppi e gli utenti dell'account B non possono accedere alla risorsa finché una policy utente o di gruppo non concede esplicitamente le autorizzazioni alla risorsa. Le autorizzazioni in questa policy possono essere solo un subset di quelli nella precedente policy multiaccount. L'account B non può concedere più autorizzazioni ai propri gruppi e utenti rispetto a quanti concessi dall'account A all'account B nella prima policy. In questa policy, l'elemento Action è esplicitamente definito per permettere solo operazioni List e l'elemento Resource di questa policy corrisponde all'elemento Resource per la policy del bucket implementata dall'account A.

Per implementare questa politica, l'account B utilizza IAM la connessione all'utente (o gruppo) appropriato nell'account B.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:List*",
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}

Utilizzo di una policy basata sulle risorse per delegare l'accesso a una coda Amazon in un altro account SQS

Nell'esempio seguente, l'account A dispone di una SQS coda Amazon che utilizza una politica basata sulle risorse allegata alla coda per concedere l'accesso alla coda all'account B. Quindi l'account B utilizza una politica di gruppo per delegare l'accesso a un IAM gruppo nell'account B.

La seguente policy di coda di esempio fornisce all'account B l'autorizzazione per eseguire le operazioni SendMessage e ReceiveMessage sulla coda dell'account A denominata queue1, ma solo tra mezzogiorno e le 15:00 del 30 novembre 2014. Il numero dell'account B è 1111-2222-3333. L'account A utilizza Amazon SQS per implementare questa politica.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": [
      "sqs:SendMessage",
      "sqs:ReceiveMessage"
    ],
    "Resource": ["arn:aws:sqs:*:123456789012:queue1"],
    "Condition": {
      "DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"},
      "DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"}
    }
  }
}

La policy dell'account B per la delega dell'accesso a un gruppo nell'account B potrebbe essere simile all'esempio seguente. L'account B utilizza questa politica IAM per associare questa politica a un gruppo (o utente).

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sqs:*",
    "Resource": "arn:aws:sqs:*:123456789012:queue1"
  }
}

Nel precedente esempio di policy IAM utente, l'account B utilizza una jolly per concedere all'utente l'accesso a SQS tutte le azioni Amazon sulla coda dell'account A. Tuttavia, l'account B può delegare l'accesso solo nella misura in cui all'account B è stato concesso l'accesso. Il gruppo dell'account B con la seconda policy può accedere alla coda solo tra mezzogiorno e le 15:00 del 30 novembre 2014. L'utente può eseguire solo ReceiveMessage le azioni SendMessage e, come definito nella politica di SQS coda Amazon dell'account A.

Impossibile delegare l'accesso quando l'accesso all'account è rifiutato

Un record Account AWS non può delegare l'accesso alle risorse di un altro account se l'altro account ha negato esplicitamente l'accesso all'account principale dell'utente. Il rifiuto si propaga agli utenti di tale account indipendentemente dal fatto che gli utenti dispongano di policy esistenti che garantiscono loro l'accesso.

Ad esempio, l'account A scrive una policy bucket per il bucket S3 dell'account A che rifiuta esplicitamente l'accesso all'account B per il bucket dell'account A. Ma l'account B scrive una politica IAM utente che concede a un utente dell'account B l'accesso al bucket dell'account A. La negazione esplicita applicata al bucket S3 dell'account A si propaga agli utenti dell'account B. Ha la precedenza sulla politica IAM utente che concede l'accesso all'utente nell'account B. (per informazioni dettagliate su come vengono valutate le autorizzazioni, vedere.) Logica di valutazione delle policy

La policy del bucket dell'account A potrebbe essere simile alla policy seguente. In questo esempio, il bucket S3 dell'account A è denominato amzn-s3-demo-bucket e il numero di account B è 1111-2222-3333. L'account A usa Amazon S3 per implementare questa policy.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AccountBDeny",
    "Effect": "Deny",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
  }
}

Questo rifiuto esplicito sostituisce qualsiasi policy dell'account B che fornisce l'autorizzazione per accedere al bucket S3 nell'account A.