Logica di valutazione delle policy - AWS Identity and Access Management

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Logica di valutazione delle policy

Quando un'entità principale cerca di utilizzare la AWS Management Console, l'API AWS o l'AWS CLI, invia una richiesta ad AWS. Quando un servizio AWS riceve una richiesta, AWS completa diversi passi per determinare se consentire o negare la richiesta.

  1. Autenticazione: AWS autentica prima il principale che effettua la richiesta, se necessario. Questo passaggio non è necessario per alcuni servizi, ad esempio Amazon S3, che consentono alcune richieste da parte di utenti anonimi.

  2. Elaborazione del contesto della richiesta: AWS elabora le informazioni raccolte nella richiesta per determinare quali policy applicare alla richiesta.

  3. Valutazione delle policy in un singolo account: AWS valuta tutti i tipi di policy e questo influisce sull'ordine con cui le policy vengono valutate.

  4. Determinazione se una richiesta è consentita o rifiutata in un account: AWS elabora quindi le policy in base al contesto della richiesta per determinare se consentire o rifiutare la richiesta.

Elaborazione del contesto della richiesta

AWS elabora la richiesta per raccogliere le informazioni seguenti in un contesto della richiesta:

  • Azioni o operazioni: le azioni o le operazioni che il principale vuole eseguire.

  • Risorse: l'oggetto risorsa AWS su cui vengono eseguite le azioni o le operazioni.

  • Principale: l'utente, il ruolo, l'utente federato o l'applicazione che ha inviato la richiesta. Le informazioni sull'entità principale includono le policy associate a tale entità principale.

  • Dati di ambiente: informazioni sull'indirizzo IP, l'agente utente, lo stato SSL abilitato o l'ora del giorno.

  • Dati sulla risorsa – I dati correlati alla risorsa che viene richiesta. Possono essere incluse informazioni quali un nome di tabella di DynamoDB o un tag su un'istanza Amazon EC2.

AWS utilizza quindi queste informazioni per trovare policy applicabili al contesto della richiesta.

Valutazione delle policy in un singolo account

Il modo in cui AWS valuta le policy dipende dal tipo di policy applicabile al contesto della richiesta. I tipi di policy elencati di seguito in ordine di frequenza possono essere utilizzati in un singolo Account AWS. Per ulteriori informazioni su questi tipi di policy, consulta Policy e autorizzazioni in IAM. Per informazioni su come AWS valuta le policy per l'accesso tra account, consulta Logica di valutazione della policy multiaccount.

  1. Policy basate su identità: le policy basate su identità sono collegate a un'identità IAM (utente, gruppo di utenti o ruolo) e concede le autorizzazioni per entità IAM (utenti e ruoli). Se a una richiesta si applicano solo le policy basate su identità, AWS verifica tutte queste policy per almeno un Allow.

  2. Policy basate sulle risorse - Le policy basate sulle risorse concedono autorizzazioni al principale (account, utente, ruolo e principali di sessione come sessioni di ruolo e utenti federati IAM) specificato come principale. Le autorizzazioni definiscono ciò che l'entità principale può fare con la risorsa a cui è collegata la policy. Se a una richiesta si applicano sia policy basate su risorse che policy basate su identità, AWS verifica tutte le policy per almeno un Allow. Quando vengono valutate le policy sulle risorse, l'ARN del principale specificato nella policy determina se le negazioni implicite in altri tipi di policy sono applicabili alla decisione finale.

  3. Limiti delle autorizzazioni IAM: i limiti delle autorizzazioni sono una funzione avanzata nella quale si imposta il numero massimo di autorizzazioni che una policy basata su identità può concedere a un'entità IAM (utente o ruolo). Quando si imposta un limite delle autorizzazioni per un'entità, l'entità può eseguire solo le operazioni consentite dalle sue policy basate su identità e dai suoi limiti delle autorizzazioni. In alcuni casi, un rifiuto implicito in un limite delle autorizzazioni può limitare le autorizzazioni concesse da una policy basata sulle risorse. Per ulteriori informazioni, consulta Determinazione se una richiesta è consentita o rifiutata in un account più avanti in questo argomento.

  4. Policy di controllo dei servizi (SCP) AWS Organizations: le SCP di Organizations specificano il numero massimo di autorizzazioni per un'organizzazione o unità organizzativa (OU). Il numero massimo di SCP si applica alle entità negli account membri, compreso ogni Utente root dell'account AWS. Se una SCP è presente, le policy basate su identità e le policy basate su risorse concedono autorizzazioni alle entità negli account dei membri solo se tali policy e l'SCP consentono l'operazione. Se sono presenti sia un limite delle autorizzazioni sia una SCP, il limite, l'SCP e la policy basata su identità devono tutti consentire l'operazione.

  5. Policy di sessione: le policy di sessione sono policy avanzate che si inviano come parametro quando si crea in modo programmatico una sessione temporanea per un ruolo o un utente federato. Per creare una sessione del ruolo in modo programmatico, è possibile utilizzare una delle operazioni API AssumeRole*. Quando esegui questa operazione e passi le policy di sessione, le autorizzazioni della sessione risultante sono l'intersezione della policy basata su identità dell'utente dell'entità IAM e delle policy di sessione. Per creare una sessione per l'utente federato, si utilizzano le chiavi di accesso dell'utente IAM per chiamare in modo programmatico l'operazione API GetFederationToken. Una policy basata sulle risorse ha un effetto diverso sulla valutazione delle autorizzazioni della policy di sessione. La differenza dipende dal fatto che l'ARN dell'utente o del ruolo o l'ARN della sessione sia elencato come il principale nella policy basata sulle risorse. Per ulteriori informazioni, consulta Policy di sessione.

Occorre ricordare che un rifiuto esplicito in una qualsiasi di queste policy sostituisce l'autorizzazione.

Valutazione delle policy basate su identità con policy basate su risorse

Le policy basate su identità e le policy basate su risorse concedono autorizzazioni alle identità o alle risorse a cui sono collegate. Quando un'entità IAM (utente o ruolo) richiede accesso a una risorsa all'interno dello stesso account, AWS valuta tutte le autorizzazioni concesse dalle policy basate su identità e sulle risorse. Le autorizzazioni risultanti sono le autorizzazioni totali dei due tipi. Se un'azione è consentita da una policy basata su identità, da una policy basata su risorse o da entrambe, AWS consente l'operazione. Un rifiuto esplicito in una di queste policy sostituisce l'autorizzazione.


          Valutazione delle policy basate su identità e delle policy basate su risorse

Valutazione delle policy basate su identità con i limiti delle autorizzazioni

Quando AWS valuta le policy basate su identità e i limiti delle autorizzazioni per un utente, le autorizzazioni risultanti sono la combinazione delle due categorie. Ciò significa che quando aggiungi un limite delle autorizzazioni a un utente con policy basate su identità esistenti, potresti ridurre il numero di operazioni che l'utente può eseguire. Di contro, quando rimuovi un limite delle autorizzazioni da un utente, potresti aumentare il numero di operazioni che può eseguire. Un rifiuto esplicito in una di queste policy sostituisce l'autorizzazione. Per informazioni su come altri tipi di policy vengono valutati con i limiti delle autorizzazioni, consulta Valutazione delle autorizzazioni valide con i limiti.


          Valutazione delle policy basate su identità e dei limiti delle autorizzazioni

Valutazione delle policy basate su identità con le SCP di Organizations

Quando un utente appartiene a un account che è un membro di un'organizzazione, le autorizzazioni risultanti sono l'intersezione delle policy dell'utente e dell'SCP. Ciò significa che un'operazione deve essere consentita sia dalla policy basata su identità sia dall'SCP. Un rifiuto esplicito in una di queste policy sostituisce l'autorizzazione.


          Valutazione delle policy basate su identità e delle SCP

Puoi scoprire se il tuo account è un membro di un'organizzazione in AWS Organizations. I membri dell'organizzazione potrebbero essere influenzati da una SCP. Per visualizzare questi dati utilizzando il comando AWS CLI o l'operazione API AWS, è necessario disporre delle autorizzazioni per l'operazione organizations:DescribeOrganization per l'entità di Organizations. È necessario disporre delle autorizzazioni aggiuntive per eseguire l'operazione nella console Organizations. Per scoprire se una SCP nega l'accesso a una richiesta specifica o per modificare le autorizzazioni effettive, contatta il tuo amministratore AWS Organizations.

Determinazione se una richiesta è consentita o rifiutata in un account

Supponiamo che un principale invii una richiesta ad AWS per accedere a una risorsa nello stesso account dell'entità principale. Il codice di attuazione AWS decide se la richiesta deve essere consentita o rifiutata. AWS valute tutte le policy applicabili al contesto della richiesta. Di seguito è riportato un riepilogo della logica di valutazione di AWS per le policy all'interno di un singolo account.

  • Per impostazione predefinita, tutte le richieste vengono negate implicitamente con l'eccezione dell'Utente root dell'account AWS, che ha accesso completo.

  • Un'autorizzazione esplicita in una policy basata su identità o basata su risorse sostituisce questa impostazione predefinita.

  • Se è presente un limite delle autorizzazioni, una SCP di Organizations oppure una policy di sessione, potrebbe sovrascrivere l'autorizzazione con un rifiuto implicito.

  • Un rifiuto esplicito in una policy sostituisce qualsiasi permesso.

Il seguente diagramma di flusso fornisce i dettagli su come la decisione viene presa. Questo diagramma di flusso non copre l'impatto delle policy basate sulle risorse e le negazioni implicite in altri tipi di policy.


        Diagramma di flusso della valutazione
  1. Rifiuta valutazione: per impostazione predefinita, tutte le richieste vengono rifiutate. Si tratta del cosiddetto rifiuto implicito. Il codice di attuazione AWS valuta tutte le policy all'interno dell'account applicabili alla richiesta. Sono inclusi le SCP AWS Organizations, le policy basate sulle risorse, le policy basate sulle identità, i limiti delle autorizzazioni IAM e le policy di sessione. In tutte le policy, il codice di attuazione cerca un'istruzione Deny applicabile alla richiesta. Questa azione si chiama rifiuto esplicito. Se il codice di attuazione trova anche un solo rifiuto esplicito applicabile, restituisce Deny (Rifiuta) come decisione finale. Se non c'è un rifiuto esplicito, la valutazione del codice di attuazione continua.

  2. SCP di Organizations: quindi il codice di attuazione valuta le policy di controllo dei servizi (SCP) AWS Organizations che si applicano alla richiesta. Le SCP si applicano alle entità dell'account in cui sono collegate le SCP. Se il codice di attuazione non trova istruzioni Allow applicabili nelle SCP, la richiesta viene rifiutata esplicitamente, anche se il rifiuto è implicito. Il codice di attuazione restituisce Deny (Rifiuta) come decisione finale. Se non c'è alcuna SCP oppure se l'SCP consente l'operazione richiesta, la valutazione del codice di attuazione continua.

  3. Policy basate sulle risorse: all'interno dello stesso account, le policy basate sulle risorse influiscono sulla valutazione delle policy in modo diverso a seconda del tipo di principale che accede alla risorsa e al principale consentito nella policy basata sulle risorse. A seconda del tipo di principale, un Allow in una policy basata sulle risorse può comportare una decisione definitiva di Allow, anche se è presente un rifiuto implicito in una policy basata su identità, un limite delle autorizzazioni o una policy di sessione.

    Per la maggior parte delle risorse, è necessario solo un permesso esplicito per il principale in una policy basata sulle identità o una policy basata sulle risorse per concedere l'accesso. Le policy di affidabilità dei ruoli IAM e le policy delle chiavi KMS sono eccezioni a questa logica, perché devono consentire esplicitamente l'accesso per i principali.

    La policy basata sulle risorse differisce dagli altri tipi di policy se il principale specificato è un utente IAM, un ruolo IAM o un principale di sessione. I principi della sessione includono sessioni come ruolo IAM o una sessione come utente federato IAM. Se una policy basata sulle risorse concede l'autorizzazione direttamente all'utente IAM o al principale di sessione che sta effettuando la richiesta, un rifiuto implicito in una policy basata sull'identità, un limite di autorizzazioni o una policy di sessione non influiscono sulla decisione finale.

    La seguente tabella consente di comprendere l'impatto delle policy basate sulle risorse per diversi tipi di principali quando i rifiuti impliciti sono presenti nelle policy basate su identità, nei limiti delle autorizzazioni e nelle policy di sessione.

    Policy basate sulle risorse e rifiuti impliciti in altri tipi di policy (stesso account)
    Principale che effettua la richiesta Policy basata su risorse Policy basata su identità Limite delle autorizzazioni Policy di sessione Risultato Motivo
    Ruolo IAM Non applicabile Non applicabile Non applicabile Non applicabile Non applicabile Un ruolo di per sé non può effettuare una richiesta. Le richieste vengono effettuate con la sessione come ruolo dopo l'assunzione di un ruolo.
    Sessione come ruolo IAM Consente il ruolo ARN Rifiuto implicito Rifiuto implicito Rifiuto implicito DENY Il limite delle autorizzazioni e le policy di sessione vengono valutati come parte della decisione finale. Una negazione implicita in entrambe le policy si traduce in una decisione DENY.
    Sessione come ruolo IAM Consente l'ARN della sessione come ruolo Rifiuto implicito Rifiuto implicito Rifiuto implicito PERMETTI Le autorizzazioni sono concesse direttamente alla sessione. Altri tipi di policy non influiscono sulla decisione.
    Utente IAM Consente l'ARN dell'utente IAM Rifiuto implicito Rifiuto implicito Non applicabile PERMETTI Le autorizzazioni vengono concesse direttamente all'utente. Altri tipi di policy non influiscono sulla decisione.
    Utente federato IAM (GetFederationToken) Consente l'ARN dell'utente IAM Rifiuto implicito Rifiuto implicito Rifiuto implicito DENY Un rifiuto implicito nel limite delle autorizzazioni o nella policy di sessione determina un RIFIUTA.
    Utente federato IAM (GetFederationToken) Consente l'ARN della sessione come utente federato IAM Rifiuto implicito Rifiuto implicito Rifiuto implicito PERMETTI Le autorizzazioni sono concesse direttamente alla sessione. Altri tipi di policy non influiscono sulla decisione.
    utente root Consente l'ARN dell'utente root Non applicabile Non applicabile Non applicabile PERMETTI L'utente root dispone di accesso completo e illimitato a tutte le risorse nell'Account AWS. Per informazioni su come controllare l'accesso dell'utente root per gli account in AWS Organizations, consultare le Policy di controllo dei servizi (SCP) nella Guida per l'utente di Organizations.
    Principale del servizio AWS Consente un principale di servizio AWS Non applicabile Non applicabile Non applicabile PERMETTI Quando una policy basata sulle risorse concede le autorizzazioni direttamente a un principale di servizio AWS, altri tipi di policy non influiscono sulla decisione.
    • Ruolo IAM: i criteri basati sulle risorse che concedono le autorizzazioni a un ARN del ruolo IAM sono limitati da un rifiuto implicito in un limite delle autorizzazioni o in una policy di sessione.

      Esempio di ARN di ruolo

      arn:aws:iam::111122223333:role/examplerole
    • Sessione come ruolo IAM: all'interno dello stesso account, le policy basate sulle risorse che concedono le autorizzazioni all'ARN della sessione come ruolo IAM concedono le autorizzazioni direttamente alla sessione come ruolo assunto. Le autorizzazioni concesse direttamente a una sessione non sono limitate da un rifiuto implicito in una policy basata su identità, da un limite delle autorizzazioni o da una policy di sessione. Quando si assume un ruolo e si effettua una richiesta, il principale che effettua la richiesta è l'ARN della sessione come ruolo IAM e non l'ARN del ruolo stesso.

      Esempio di ARN della sessione come ruolo

      arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname
    • Utente IAM: all'interno dello stesso account, le politiche basate sulle risorse che concedono autorizzazioni all'ARN di un utente IAM (ovvero, non una sessione come utente federato) non sono limitate da un rifiuto implicito in una policy basata su identità o in un limite delle autorizzazioni.

      Esempio di ARN dell'utente IAM

      arn:aws:iam::111122223333:user/exampleuser
    • Sessioni come utente federato IAM: una sessione come utente federato IAM è una sessione creata chiamando GetFederationToken. Quando un utente federato effettua una richiesta, il principale che effettua la richiesta è l'ARN dell'utente federato e non l'ARN dell'utente IAM che ha eseguito la federazione. All'interno dello stesso account, le policy basate sulle risorse che concedono le autorizzazioni all'ARN dell'utente federato concedono le autorizzazioni direttamente alla sessione. Le autorizzazioni concesse direttamente a una sessione non sono limitate da un rifiuto implicito in una policy basata su identità, da un limite delle autorizzazioni o da una policy di sessione.

      Tuttavia, se una policy basata sulle risorse concede l'autorizzazione all'ARN dell'utente IAM che ha eseguito la federazione, le richieste fatte dall'utente federato durante la sessione sono limitate da un rifiuto implicito in un limite di autorizzazione o in una policy di sessione.

      Esempio di ARN della sessione come utente federato IAM

      arn:aws:sts::111122223333:federated-user/exampleuser
  4. Policy basate su identità: il codice verifica quindi le policy basate su identità per il principale. Per un utente IAM, queste includono le policy utente e le policy dei gruppi a cui appartiene l'utente. Se non ci sono policy basate su identità o istruzioni nelle policy basata su identità che consentono l'operazione richiesta, la richiesta viene rifiutata implicitamente e il codice restituisce Deny (Rifiuta) come decisione finale. Se un'istruzione in qualsiasi policy basata su identità applicabile consente l'operazione richiesta, il codice continua.

  5. Limiti delle autorizzazioni IAM: il codice controlla quindi se l'entità IAM utilizzata dall'entità ha un limite di autorizzazioni. Se la policy utilizzata per impostare il limite delle autorizzazioni non consente l'operazione richiesta, la richiesta viene rifiutata implicitamente. Il codice restituisce Deny (Rifiuta) come decisione finale. Se non c'è alcun limite delle autorizzazioni oppure se il limite delle autorizzazioni consente l'operazione richiesta, il codice continua.

  6. Policy di sessione: il codice verifica quindi se il principale è un principale di sessione. I principali di sessione includono una sessione come ruolo IAM o una sessione come utente federato IAM. Se il principale non è un principale di sessione, il codice di attuazione restituisce Allow (Consenti) come decisione finale.

    Per i principali di sessione, il codice verifica se una policy di sessione è passata nella richiesta. Puoi passare una policy di sessione utilizzando l'AWS CLI o l'API AWS per ottenere le credenziali temporanee per un ruolo o un utente federato IAM.

    • Se una policy di sessione è presente e non consente l'operazione richiesta, la richiesta viene rifiutata implicitamente. Il codice restituisce Deny (Rifiuta) come decisione finale.

    • Se non esiste una policy di sessione, il codice verifica se il principale è una sessione come ruolo. Se il principale è una sessione come ruolo, la richiesta è autorizzata. In caso contrario, la richiesta viene negata implicitamente e iI codice restituisce Rifiuta come decisione finale.

    • Se una policy di sessione è presente e consente l'operazione richiesta, il codice di attuazione restituisce Consenti come decisione finale.

  7. Errori: se il codice di attuazione AWS rileva un errore in qualsiasi momento durante la valutazione, genera un'eccezione e viene chiuso.

Esempio di valutazione delle policy basate su identità e delle policy basate su risorse

I tipi di policy più comuni sono quelle basate su identità e quelle basate su risorse. Quando viene richiesto l'accesso a una risorsa, AWS valuta tutte le autorizzazioni concesse dalle policy per almeno un permesso all'interno dello stesso account. Un rifiuto esplicito in una qualsiasi di queste policy sostituisce l'autorizzazione.

Importante

Se la policy basata sull'identità o la policy basata sulle risorse all'interno dello stesso account consente la richiesta e l'altra no, la richiesta è comunque consentita.

Supponiamo che Carlos, con il nome utente carlossalazar, voglia salvare un file nel bucket carlossalazar-logs di Amazon S3.

Supponi inoltre che la policy seguente sia collegata all'utente IAM carlossalazar.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetAccountPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowS3Self", "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::carlossalazar/*", "arn:aws:s3:::carlossalazar" ] }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::*log*" } ] }

L'istruzione AllowS3ListRead in questa policy consente a Carlos di visualizzare un elenco di tutti i bucket nell'account. L'istruzione AllowS3Self consente a Carlos l'accesso completo al bucket con lo stesso nome usato per il nome utente. L'istruzione DenyS3Logs nega a Carlos l'accesso a qualsiasi bucket di S3 il cui nome includa log.

Inoltre, la seguente policy basata su risorse (detta policy del bucket) viene collegata al bucket carlossalazar.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/carlossalazar" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::carlossalazar/*", "arn:aws:s3:::carlossalazar" ] } ] }

Questa policy specifica che solo l'utente carlossalazar può accedere al bucket carlossalazar.

Quando Carlos esegue la richiesta di salvataggio di un file nel bucket carlossalazar-logs, AWS determina quali siano le policy applicabili alla richiesta. In questo caso, sono applicabili solo la policy basata su identità e la policy basata su risorse. Entrambe sono policy di autorizzazione. Poiché non ci sono limiti di autorizzazione applicabili, la logica di valutazione viene ridotta a quanto segue.


        Diagramma di flusso della valutazione

AWS cerca prima di tutto un'istruzione Deny applicabile al contesto della richiesta. Ne trova una, perché la policy basata su identità rifiuta esplicitamente a Carlos l'accesso a qualsiasi bucket di S3 utilizzato per la creazione di log. A Carlos viene negato l'accesso.

Supponi che Carlos si renda poi conto dell'errore e tenti di salvare il file nel bucket carlossalazar. AWS cerca un'istruzione Deny e non la trova. Verifica quindi le policy di autorizzazione. Sia la policy basata sull'identità che la policy basata sulle risorse consentono la richiesta. Pertanto, anche AWS accetta la richiesta. Se uno dei due avesse rifiutato esplicitamente l'istruzione, la richiesta sarebbe stata negata. Se uno dei tipi di policy consente la richiesta e l'altro no, la richiesta è comunque consentita.

Differenza tra rifiuto esplicito e implicito

Una richiesta genera un rifiuto esplicito se policy applicabile include un'istruzione Deny. Se le policy applicabili a una richiesta includono un'istruzione Allow e un'istruzione Deny, l'istruzione Deny prevale sull'istruzione Allow. La richiesta viene rifiutata esplicitamente.

Una rifiuto implicito si verifica quando non c'è un'istruzione Deny applicabile ma non c'è neanche un'istruzione Allow applicabile. Poiché a un principale IAM viene rifiutato l'accesso per impostazione predefinita, questo deve essere autorizzato esplicitamente a eseguire un'operazione. In caso contrario, l'accesso viene negato implicitamente.

Quando progetti una strategia di autorizzazione, devi creare policy con istruzioni Allow per consentire alle entità principali di eseguire richieste. Tuttavia, puoi scegliere qualsiasi combinazione di rifiuti espliciti e impliciti.

Ad esempio, è possibile creare la seguente policy che include operazioni consentite, operazioni rifiutate implicitamente e operazioni rifiutate esplicitamente. La dichiarazione AllowGetList permette l'accesso in sola lettura alle operazioni IAM che iniziano con i prefissi Get e List. Tutte le altre azioni in IAM, come iam:CreatePolicy, sono rifiutate implicitamente. La dichiarazione DenyReports impedisce esplicitamente l'accesso ai report IAM impedendo l'accesso alle operazioni che includono il suffisso Report, come iam:GetOrganizationsAccessReport. Se qualcuno aggiunge un'altra policy a questo principale per concedere l'accesso ai report IAM, come iam:GenerateCredentialReport, le richieste relative ai report vengono ancora rifiutate a causa di questo rifiuto esplicito.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowGetList", "Effect": "Allow", "Action": [ "iam:Get*", "iam:List*" ], "Resource": "*" }, { "Sid": "DenyReports", "Effect": "Deny", "Action": "iam:*Report", "Resource": "*" } ] }