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.