Limiti delle autorizzazioni per le entità IAM - AWS Identity and Access Management
Valutazione delle autorizzazioni valide con i limitiDelega di responsabilità ad altri mediante i limiti delle autorizzazioni

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à.

Limiti delle autorizzazioni per le entità IAM

AWS supporta i limiti delle autorizzazioni per le entità IAM (utenti o ruoli). Un limite delle autorizzazioni è una funzione avanzata per l'utilizzo di una policy gestita per impostare il numero massimo di autorizzazioni che una policy basata su identità può concedere a un'entità IAM. Il limite delle autorizzazioni di un'entità consente di eseguire solo le operazioni consentite dalle sue policy basate su identità e dai suoi limiti delle autorizzazioni.

Per ulteriori informazioni sui tipi di policy, consulta Tipi di policy.

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 sull'elemento NotPrincipal, consulta la pagina AWS Elementi della policy JSON: NotPrincipal.

Puoi utilizzare una policy gestita da AWS o dal cliente per impostare il limite per un'entità IAM (utente o ruolo). La policy limita il numero massimo di autorizzazioni per l'utente o il ruolo.

Ad esempio, si supponga che l'utente IAM denominato ShirleyRodriguez debba essere autorizzato a gestire solo Amazon S3, Amazon CloudWatch e Amazon EC2. Per applicare la regola, puoi utilizzare la policy seguente per impostare il limite delle autorizzazioni per l'utente ShirleyRodriguez:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "cloudwatch:*",
                "ec2:*"
            ],
            "Resource": "*"
        }
    ]
}

Quando utilizzi una policy per impostare il limite delle autorizzazioni per un utente, questa limita le autorizzazioni dell'utente, ma non le fornisce di per sé. In questo esempio, la policy imposta le autorizzazioni massime di ShirleyRodriguez come tutte le operazioni in Amazon S3, CloudWatch e Amazon EC2. Shirley non può eseguire operazioni negli altri servizi, incluso IAM, anche se dispone di una policy di autorizzazione che lo consente. Ad esempio, prova ad aggiungere la policy seguente all'utente ShirleyRodriguez:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "iam:CreateUser",
    "Resource": "*"
  }
}

Questa policy consente la creazione di un utente in IAM. Se colleghi questa policy di autorizzazione all'utente ShirleyRodriguez e Shirley tenta di creare un utente, l'operazione ha esito negativo. Non riesce perché il limite delle autorizzazioni non consente l'operazione iam:CreateUser. Date queste due policy, Shirley non ha il permesso di eseguire alcuna operazione in AWS. È necessario aggiungere una policy di autorizzazioni diversa per consentire operazioni in altri servizi, ad esempio Amazon S3. In alternativa, è possibile aggiornare il limite delle autorizzazioni per consentirle di creare un utente in IAM.

Valutazione delle autorizzazioni valide con i limiti

Il limite delle autorizzazioni per un'entità IAM (utente o ruolo) imposta il numero massimo di autorizzazioni che è possibile concedere all'entità. Questo può influire sulle autorizzazioni valide per l'utente o il ruolo. Le autorizzazioni valide per un'entità sono quelle concesse da tutte le policy che interessano l'utente o il ruolo. In un account, le autorizzazioni per un'entità possono essere influenzate da policy basate su identità, policy basate su risorse, limiti delle autorizzazioni, SCP di Organizations o policy di sessione. Per ulteriori informazioni sui diversi tipi di policy, consulta Policy e autorizzazioni in AWS Identity and Access Management.

Se uno di questi tipi di policy rifiuta esplicitamente l'accesso per un'operazione, la richiesta viene rifiutata. Le autorizzazioni concesse a un'entità in base a diversi tipi di autorizzazioni sono più complesse. Per ulteriori dettagli su come AWS valuta le policy, consulta Logica di valutazione delle policy.

Policy basate su identità con limiti: le policy basate su identità sono policy in linea o gestite collegate a un utente, un gruppo di utenti o un ruolo. Le policy basate su identità concedono autorizzazioni all'entità e i limiti delle autorizzazioni limitano tali autorizzazioni. Le autorizzazioni effettive sono l'intersezione di entrambi i tipi di policy. Un rifiuto esplicito in una di queste policy sostituisce l'autorizzazione.

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

Policy basate su risorse: le policy basate su risorse controllano il modo in cui l'entità principale specificata può accedere alla risorsa a cui la policy è collegata.

Policy basate su risorse per utenti 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.

Valutazione di una policy basata su risorse, di un limite delle autorizzazioni e di una policy basata su identità
Policy basate sulle risorse per ruoli IAM

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.

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.

Policy basate sulle risorse per le sessioni di ruoli IAM e utenti federati

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.

SCP di Organizations: le SCP vengono applicate a un intero Account AWS. Limitano le autorizzazioni per ogni richiesta effettuata da un'entità principale all'interno dell'account. Un'entità IAM (utente o ruolo) può effettuare una richiesta che è influenzata da una SCP, un limite delle autorizzazioni e una policy basata su identità. In questo caso, la richiesta è consentita solo se tutti e tre i tipi di policy la consentono. Le autorizzazioni effettive sono l'intersezione di tutti e tre i tipi di policy. Un rifiuto esplicito in una qualsiasi di queste policy sostituisce l'autorizzazione.

Valutazione di un'SCP, di un limite delle autorizzazioni e di una policy basata su identità

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.

Policy di sessione: le policy di sessione sono policy avanzate che vengono trasmesse come parametro quando si crea in modo programmatico una sessione temporanea per un ruolo o un utente federato. Le autorizzazioni per una sessione provengono dall'entità IAM (utente o ruolo) utilizzata per creare la sessione e dalla policy di sessione. Le autorizzazioni della policy basata su identità dell'entità sono limitate dalla policy di sessione e dal limite delle autorizzazioni. Le autorizzazioni effettive per questo set di tipi di policy sono l'intersezione di tutti e tre i tipi di policy. Un rifiuto esplicito in una qualsiasi di queste policy sostituisce l'autorizzazione. Per ulteriori informazioni sulle policy di sessione, consulta la sezione relativa alle policy di sessione.

Valutazione di una policy di sessione, di un limite delle autorizzazioni e di una policy basata su identità

Delega di responsabilità ad altri mediante i limiti delle autorizzazioni

Puoi utilizzare il limiti delle autorizzazioni per delegare le attività di gestione delle autorizzazioni, ad esempio la creazione di utenti, agli utenti IAM nel tuo account. Questo consente ad altri di eseguire operazioni a tuo nome all'interno di un limite specifico di autorizzazioni.

Supponi, ad esempio, che María sia l'amministratrice dell'Account AWS X-Company. María vuole delegare l'attività di creazione di utenti a Zhang. Tuttavia, deve accertarsi che gli utenti creati da Zhang siano conformi alle seguenti regole aziendali:

  • Gli utenti non possono utilizzare IAM per creare o gestire utenti, gruppi, ruoli o policy.

  • Agli utenti viene rifiutato l'accesso al bucket logs di Amazon S3 e all'istanza i-1234567890abcdef0 di Amazon EC2.

  • Gli utenti non possono rimuovere le proprie policy limite.

Per applicare queste regole, María completa le attività seguenti, i cui dettagli sono riportati di seguito:

  1. María crea la policy gestita XCompanyBoundaries da utilizzare come limite delle autorizzazioni per tutti i nuovi utenti nell'account.

  2. María crea la policy gestita DelegatedUserBoundary e la assegna come limite delle autorizzazioni per Zhang. Maria prende nota dell'ARN del suo utente amministratore e lo usa nel criterio per impedire a Zhang di accedervi.

  3. María crea la policy gestita DelegatedUserPermissions e la collega alla policy di autorizzazione per Zhang.

  4. María comunica a Zhang le sue nuove responsabilità e limitazioni.

Attività 1: María deve prima creare una policy gestita per definire il limite per i nuovi utenti. María deve consentire a Zhang di concedere agli utenti le policy di autorizzazione necessarie, ma vuole che tali utenti abbiano delle limitazioni. A tale scopo, crea questa policy gestita dal cliente, denominata XCompanyBoundaries. Questa policy esegue le seguenti operazioni:

  • Consente agli utenti l'accesso completo a diversi servizi

  • Consente l'accesso autonomo limitato alla console IAM. Ciò significa che è possibile modificare la password dopo aver effettuato l'accesso alla console. Non è possibile impostare la password iniziale. Per consentire questa operazione, aggiungere l'operazione "*LoginProfile" all'istruzione AllowManageOwnPasswordAndAccessKeys.

  • Rifiuta agli utenti l'accesso al bucket di log Amazon S3 o all'istanza Amazon EC2 i-1234567890abcdef0

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ServiceBoundaries",
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "cloudwatch:*",
                "ec2:*",
                "dynamodb:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowIAMConsoleForCredentials",
            "Effect": "Allow",
            "Action": [
                "iam:ListUsers",
                "iam:GetAccountPasswordPolicy"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowManageOwnPasswordAndAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:*AccessKey*",
                "iam:ChangePassword",
                "iam:GetUser",
                "iam:*ServiceSpecificCredential*",
                "iam:*SigningCertificate*"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "DenyS3Logs",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::logs",
                "arn:aws:s3:::logs/*"
            ]
        },
        {
            "Sid": "DenyEC2Production",
            "Effect": "Deny",
            "Action": "ec2:*",
            "Resource": "arn:aws:ec2:*:*:instance/i-1234567890abcdef0"
        }
    ]
}

Ogni istruzione svolge una funzione diversa:

  1. L'istruzione ServiceBoundaries di questa policy consente l'accesso completo a servizi AWS specificati. Ciò significa che le operazioni di un nuovo utente in questi servizi sono limitate solo dalle policy di autorizzazione collegate all'utente.

  2. La dichiarazione AllowIAMConsoleForCredentials consente l'accesso per elencare tutti gli utenti IAM. Questo accesso è necessario per navigare nella pagina Users (Utenti) nella AWS Management Console. Inoltre, consente di visualizzare i requisiti associati alle password per l'account, necessari per modificare la password.

  3. L'istruzione AllowManageOwnPasswordAndAccessKeys consente agli utenti di gestire solo le proprie chiavi di accesso a livello di programmazione e le password della console. Questo è importante se Zhang o un altro amministratore concede a un nuovo utente una policy di autorizzazione con accesso IAM completo. In tal caso, l'utente può modificare le proprie autorizzazioni o quelle di altri utenti. Questa istruzione impedisce che ciò si verifichi.

  4. L'istruzione DenyS3Logs nega esplicitamente l'accesso al bucket logs.

  5. L'istruzione DenyEC2Production nega esplicitamente l'accesso all'istanza i-1234567890abcdef0.

Attività 2: María vuole consentire a Zhang di creare tutti gli utenti X-Company, ma solo con il limite delle autorizzazioni XCompanyBoundaries. A tale scopo, crea questa policy gestita dal cliente, denominata DelegatedUserBoundary. Questa policy definisce il numero massimo di autorizzazioni di cui Zhang può disporre.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CreateOrChangeOnlyWithBoundary",
            "Effect": "Allow",
            "Action": [
                "iam:AttachUserPolicy",
                "iam:CreateUser",
                "iam:DeleteUserPolicy",
                "iam:DetachUserPolicy",
                "iam:PutUserPermissionsBoundary",
                "iam:PutUserPolicy"
            ],
            "Resource": "*",
            "Condition": {
               "StringEquals": {
                 "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/XCompanyBoundaries"
                }
            }
        },
        {
            "Sid": "CloudWatchAndOtherIAMTasks",
            "Effect": "Allow",
            "Action": [
              "cloudwatch:*",
              "iam:CreateAccessKey",
              "iam:CreateGroup",
              "iam:CreateLoginProfile",
              "iam:CreatePolicy",
              "iam:DeleteGroup",
              "iam:DeletePolicy",
              "iam:DeletePolicyVersion",
              "iam:DeleteUser",
              "iam:GetAccountPasswordPolicy",
              "iam:GetGroup",
              "iam:GetLoginProfile",
              "iam:GetPolicy",
              "iam:GetPolicyVersion",
              "iam:GetRolePolicy",
              "iam:GetUser",
              "iam:GetUserPolicy",
              "iam:ListAccessKeys",
              "iam:ListAttachedRolePolicies",
              "iam:ListAttachedUserPolicies",
              "iam:ListEntitiesForPolicy",
              "iam:ListGroups",
              "iam:ListGroupsForUser",
              "iam:ListMFADevices",
              "iam:ListPolicies",
              "iam:ListPolicyVersions",
              "iam:ListRolePolicies",
              "iam:ListSSHPublicKeys",
              "iam:ListServiceSpecificCredentials",
              "iam:ListSigningCertificates",
              "iam:ListUserPolicies",
              "iam:ListUsers",
              "iam:SetDefaultPolicyVersion",
              "iam:SimulateCustomPolicy",
              "iam:SimulatePrincipalPolicy",
              "iam:UpdateGroup",
              "iam:UpdateLoginProfile",
              "iam:UpdateUser"
            ],
            "NotResource": "arn:aws:iam::123456789012:user/Maria"
        },
        {
            "Sid": "NoBoundaryPolicyEdit",
            "Effect": "Deny",
            "Action": [
                "iam:CreatePolicyVersion",
                "iam:DeletePolicy",
                "iam:DeletePolicyVersion",
                "iam:SetDefaultPolicyVersion"
            ],
            "Resource": [
                "arn:aws:iam::123456789012:policy/XCompanyBoundaries",
                "arn:aws:iam::123456789012:policy/DelegatedUserBoundary"
            ]
        },
        {
            "Sid": "NoBoundaryUserDelete",
            "Effect": "Deny",
            "Action": "iam:DeleteUserPermissionsBoundary",
            "Resource": "*"
        }
    ]
}

Ogni istruzione svolge una funzione diversa:

  1. L'istruzione CreateOrChangeOnlyWithBoundary consente a Zhang di creare utenti IAM ma solo se utilizza la policy XCompanyBoundaries per impostare il limite delle autorizzazioni. L'istruzione gli consente inoltre di impostare il limite delle autorizzazioni per gli utenti esistenti, ma solo utilizzando la stessa policy. Infine, consente a Zhang di gestire le policy di autorizzazione per gli utenti per i quali è stato impostato questo limite delle autorizzazioni.

  2. L'istruzione CloudWatchAndOtherIAMTasks consente a Zhang di completare altre attività di gestione di utenti, gruppi e policy. Ha le autorizzazioni per reimpostare le password e creare chiavi di accesso per qualsiasi utente IAM non elencato nell'elemento della policy NotResource. Questo gli consente di aiutare gli utenti con problemi di accesso.

  3. L'istruzione NoBoundaryPolicyEdit nega a Zhang l'accesso per aggiornare la policy XCompanyBoundaries. Zhang non può modificare alcuna policy utilizzata per impostare il limite delle autorizzazioni per sé o per altri utenti.

  4. L'istruzione NoBoundaryUserDelete nega a Zhang l'accesso per eliminare il limite delle autorizzazioni per sé o per altri utenti.

María assegna quindi la policy DelegatedUserBoundary come limite delle autorizzazioni per l'utente Zhang.

Attività 3: poiché il limite delle autorizzazioni controlla il numero massimo di autorizzazioni, ma non concede l'accesso di per sé, María deve creare una policy di autorizzazione per Zhang. A tale scopo, crea questa policy, denominata DelegatedUserPermissions. Questa policy definisce le operazioni che Zhang può eseguire, entro il limite definito.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "IAM",
            "Effect": "Allow",
            "Action": "iam:*",
            "Resource": "*"
        },
        {
            "Sid": "CloudWatchLimited",
            "Effect": "Allow",
            "Action": [
                "cloudwatch:GetDashboard",
                "cloudwatch:GetMetricData",
                "cloudwatch:ListDashboards",
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:ListMetrics"
            ],
            "Resource": "*"
        },
        {
            "Sid": "S3BucketContents",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::ZhangBucket"
        }
    ]
}

Ogni istruzione svolge una funzione diversa:

  1. L'istruzione IAM della policy consente a Zhang l'accesso completo a IAM. Tuttavia, poiché il limite delle autorizzazioni di Zhang consente solo alcune operazioni in IAM, le sue autorizzazioni valide in IAM sono limitate solo dal relativo limite delle autorizzazioni.

  2. L'istruzione CloudWatchLimited consente a Zhang di eseguire cinque operazioni in CloudWatch. Il limite delle autorizzazioni di Zhang consente tutte le operazioni in CloudWatch, pertanto le sue autorizzazioni valide in CloudWatch sono limitate solo dalla relativa policy di autorizzazione.

  3. L'istruzione S3BucketContents consente a Zhang di visualizzare il bucket ZhangBucket di Amazon S3. Tuttavia, il limite delle autorizzazioni di Zhang non gli consente alcuna operazione in Amazon S3, quindi non può eseguire operazioni S3, indipendentemente dalla sua policy di autorizzazione.

    Nota

    Le policy di Zhang gli permettono di creare un utente in grado di accedere alle risorse Amazon S3 a cui lui non può accedere. Delegando queste operazioni amministrative, Maria di fatto si fida dell'accesso di Zhang ad Amazon S3.

María collega quindi la policy DelegatedUserPermissions come policy di autorizzazione per l'utente Zhang.

Attività 4: María fornisce a Zhang le istruzioni per creare un nuovo utente. Zhang può creare nuovi utenti con tutte le autorizzazioni necessarie, ma deve assegnare loro la policy XCompanyBoundaries come limite delle autorizzazioni.

Zhang completa le attività seguenti:

  1. Zhang crea un utente con la AWS Management Console. Digita il nome utente Nikhil e consente l'accesso alla console a tale utente. Cancella la casella di controllo accanto a Richiede reimpostazione della password poiché le policy sopra riportate consentono agli utenti di modificare la password solo dopo aver effettuato l'accesso alla console IAM.

  2. Nella pagina Set permissions (Imposta autorizzazioni), Zhang sceglie le policy di autorizzazione IAMFullAccess e AmazonS3ReadOnlyAccess, che consentono a Nikhil di lavorare.

  3. Zhang salta la sezione Set permissions boundary (Imposta limite delle autorizzazioni), dimenticando le indicazioni di María.

  4. Zhang esamina i dettagli utente e seleziona Create user (Crea utente).

    L'operazione ha esito negativo e l'accesso viene negato. In base al limite delle autorizzazioni di Zhang, DelegatedUserBoundary, qualsiasi utente da lui creato deve includere la policy XCompanyBoundaries come limite delle autorizzazioni.

  5. Zhang torna alla pagina precedente. Nella sezione Set permissions boundary (Imposta limite delle autorizzazioni), seleziona la policy XCompanyBoundaries.

  6. Zhang esamina i dettagli utente e seleziona Create user (Crea utente).

    L'utente viene creato.

Quando Nikhil esegue l'accesso, può accedere a IAM e Amazon S3, ma non alle operazioni rifiutate dal suo limite delle autorizzazioni. Ad esempio, può modificare la propria password in IAM ma non può creare un altro utente o modificare le policy. Nikhil ha accesso in sola lettura ad Amazon S3.

Se qualcuno aggiunge una policy basata sulle risorse al bucket logs che consente a Nikhil di inserire un oggetto nel bucket, significa che non può ancora accedere al bucket. Questo perché qualsiasi operazione sul bucket logs è esplicitamente rifiutata dal suo limite delle autorizzazioni. Un rifiuto esplicito in qualsiasi tipo di policy determina il rifiuto di una richiesta. Tuttavia, se una policy basata sulle risorse collegata a un segreto di Secrets Manager consente a Nikhil di eseguire l'operazione secretsmanager:GetSecretValue, allora Nikhil potrà recuperare e decrittare il segreto. Questo perché le operazioni di Secrets Manager non sono esplicitamente rifiutate dal suo limite delle autorizzazioni e i rifiuti impliciti nei limiti delle autorizzazioni non limitano le policy basate sulle risorse.