Elementi delle policy JSON AWS: NotPrincipal

Puoi utilizzare l'elemento NotPrincipal per rifiutare l'accesso a tutti i principali ad eccezione dell'utente IAM, l'utente federato, il ruolo IAM, l'Account AWS, il servizio AWS o un altro principale specificato nell'elemento NotPrincipal.

Puoi usarlo nelle policy basate sulle risorse per alcuni servizi AWS, tra cui gli endpoint VPC. Le policy basate su risorse sono policy che vengono incorporate direttamente in una risorsa. Non puoi utilizzare l'elemento NotPrincipal in una policy basata sull'identità IAM o in una policy di attendibilità del ruolo IAM.

NotPrincipal deve essere usato con "Effect":"Deny". L'uso con "Effect":"Allow" non è supportato.

Importante

Pochissimi scenari richiedono l'utilizzo di NotPrincipal. Si consiglia di esplorare altre opzioni di autorizzazione prima di decidere di utilizzare NotPrincipal. Quando utilizzi NotPrincipal, la risoluzione dei problemi legati agli effetti di più tipi di policy può essere difficile. Con gli operatori di condizione ARN, si consiglia invece di utilizzare la chiave di contesto aws:PrincipalArn. Per ulteriori informazioni, consulta Tutti i principali.

Specifica di NotPrincipal con Deny

Quando si utilizza NotPrincipal con Deny, è necessario specificare anche l'ARN dell'account del principale non rifiutato. In caso contrario, la policy potrebbe rifiutare l'accesso all'intero account contenente il principale. A seconda del servizio che si include nella policy, AWS potrebbe convalidare prima l'account e poi l'utente. Se un utente con ruolo assunto (qualcuno che utilizza un ruolo) viene valutato, AWS potrebbe convalidare prima l'account, quindi il ruolo e infine l'utente con ruolo assunto. L'utente con ruolo assunto viene identificato tramite il nome della sessione del ruolo specificato quando l'utente ha assunto il ruolo. Pertanto, è fortemente consigliabile includere esplicitamente l'ARN di un account utente oppure includere sia l'ARN di un ruolo sia l'ARN dell'account che contiene quel ruolo.

Importante

Non utilizzare istruzioni di policy basate sulle risorse che includono un elemento di policy NotPrincipal con effetto Deny per gli utenti o i ruoli IAM ai quali è collegata una policy con limite delle autorizzazioni. L'elemento NotPrincipal con effetto Deny rifiuterà sempre qualsiasi principale IAM al quale è collegata una policy con limite delle autorizzazioni, indipendentemente dai valori specificati nell'elemento NotPrincipal. Ciò fa sì che alcuni utenti o ruoli IAM che altrimenti avrebbero accesso alla risorsa perdano l'accesso. Ti consigliamo di modificare le istruzioni di policy basate sulle risorse di modo che, per limitare l'accesso, utilizzino l'operatore di condizione ArnNotEquals con la chiave di contesto aws:PrincipalArn anziché l'elemento NotPrincipal. Per ulteriori informazioni sui limiti delle autorizzazioni, consulta la pagina Limiti delle autorizzazioni per le entità IAM.

Nota

Come best practice, si dovrebbero includere gli ARN per l'account nella policy. Alcuni servizi richiedono l'ARN dell'account, anche se questo non è obbligatorio in tutti i casi. Le policy esistenti senza l'ARN richiesto continueranno a funzionare, ma le nuove policy che includono tali servizi devono soddisfare questo requisito. IAM non tiene traccia di questi servizi e pertanto consiglia di includere sempre l'ARN dell'account.

I seguenti esempi mostrano come utilizzare NotPrincipal e "Effect": "Deny" nella stessa istruzione della policy in modo efficiente.

Esempio di utente IAM nello stesso account o in un account differente

Nell'esempio seguente, l'accesso a una risorsa viene rifiutato esplicitamente a tutti gli elementi principali eccetto all'utente di nome Bob nell'Account AWS 444455556666. Come best practice, l'elemento NotPrincipal contiene l'ARN dell'utente Bob e dell'Account AWS a cui Bob appartiene (arn:aws:iam::444455556666:root). Se l'elemento NotPrincipal contenesse solo l'ARN di Bob, l'effetto della policy potrebbe essere di rifiutare esplicitamente l'accesso all'Account AWS che contiene l'utente Bob. In alcuni casi, un utente non può avere più autorizzazioni rispetto al rispettivo account padre, quindi se all'account di Bob viene esplicitamente rifiutato l'accesso, Bob potrebbe non essere in grado di accedere alla risorsa.

Questo esempio funziona come previsto quando è parte di un'istruzione di policy in una policy basata sulle risorse collegata a una risorsa nello stesso Account AWS o in uno diverso (non 444455556666). Questo esempio di per sé non concede l'accesso a Bob, omette solo Bob dall'elenco di principali esplicitamente rifiutati. Per consentire a Bob di accedere alla risorsa, un'altra istruzione della policy deve permettere esplicitamente l'accesso tramite "Effect": "Allow".

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Deny",
        "NotPrincipal": {"AWS": [
            "arn:aws:iam::444455556666:user/Bob",
            "arn:aws:iam::444455556666:root"
        ]},
        "Action": "s3:*",
        "Resource": [
            "arn:aws:s3:::BUCKETNAME",
            "arn:aws:s3:::BUCKETNAME/*"
        ]
    }]
}

Esempio di ruolo IAM nello stesso account o in un account differente

Nell'esempio seguente, l'accesso a una risorsa viene rifiutato esplicitamente a tutti i principali eccetto all'utente con ruolo assunto denominato cross-account-audit-app nell'Account AWS 444455556666. Come best practice, l'elemento NotPrincipal contiene l'ARN dell'utente con ruolo assunto (cross-account-audit-app), il ruolo (cross-account-read-only-role) e l'Account AWS a cui il ruolo appartiene (444455556666). Se nell'elemento NotPrincipal mancasse l'ARN del ruolo, l'effetto della policy potrebbe essere di rifiutare esplicitamente l'accesso al ruolo. Analogamente, se nell'elemento NotPrincipal mancasse l'ARN dell'Account AWS a cui appartiene il ruolo, l'effetto della policy potrebbe essere di rifiutare esplicitamente l'accesso all'Account AWS e a tutte le entità in tale account. In alcuni casi, gli utenti con ruolo assunto non possono disporre di più autorizzazioni rispetto al loro ruolo padre e i ruoli non possono avere più autorizzazioni rispetto all'Account AWS padre, quindi quando al ruolo o all'account viene rifiutato esplicitamente l'accesso, l'utente con ruolo assunto potrebbe non essere in grado di accedere alla risorsa.

Questo esempio funziona come previsto quando è parte di un'istruzione di policy in una policy basata sulle risorse collegata a una risorsa in un Account AWS diverso (non 444455556666). Questo esempio di per sé non permette l'accesso all'account con ruolo assunto cross-account-audit-app, ma omette solo cross-account-audit-app dall'elenco di principali che sono rifiutati esplicitamente. Per consentire l'accesso alla risorsa a cross-account-audit-app, un'altra istruzione della policy deve permettere esplicitamente l'accesso tramite "Effect": "Allow".

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Deny",
        "NotPrincipal": {"AWS": [
            "arn:aws:sts::444455556666:assumed-role/cross-account-read-only-role/cross-account-audit-app",
            "arn:aws:iam::444455556666:role/cross-account-read-only-role",
            "arn:aws:iam::444455556666:root"
        ]},
        "Action": "s3:*",
        "Resource": [
            "arn:aws:s3:::Bucket_AccountAudit",
            "arn:aws:s3:::Bucket_AccountAudit/*"
        ]
    }]
}

Quando si specifica una sessione con assunzione di ruolo in un elemento NotPrincipal, non è possibile utilizzare un carattere jolly (*) per indicare "tutte le sessioni". Le entità devono sempre fare riferimento a una sessione specifica.