Come si risolvono i messaggi di errore di negazione esplicita quando si richiedono chiamate API utilizzando ruoli o utenti IAM?

Ultimo aggiornamento: 31/05/2022

Ho ricevuto un messaggio di errore di negazione esplicita quando richiedevo una chiamata API utilizzando un ruolo o un utente AWS Identity and Access Management (IAM). Come posso risolvere i messaggi di errore di negazione esplicita?

Breve descrizione

Affinché un'entità IAM (ruolo o utente) possa effettuare una chiamata API riuscita, l'entità deve soddisfare le seguenti condizioni:

  • Il ruolo o l'utente dispone delle autorizzazioni corrette per richiedere una chiamata API.
  • L'autorizzazione non viene negata da alcuna dichiarazione in tutte le policy applicabili al contesto della richiesta.

Se la tua entità IAM non soddisfa queste condizioni, la chiamata API va a buon fine e genera un errore (AccessDenied) simile al seguente:

  • Utente o ruolo IAM che ha riscontrato il problema: arn:XXXXXXXX:iam::XXXXXXXX:role/TestReadOnly

    Errore: si è verificato un errore (AccessDenied) durante la chiamata dell'operazione RunInstances: l'utente: arn:aws:iam::XXXXXXXX:user/tester non è autorizzato a eseguire: ec2:RunInstances sulla risorsa: role TestReadOnly con una negazione esplicita

Nota: i passaggi per la risoluzione dei problemi in questo articolo riguardano specificamente gli errori di negazione esplicita e non gli errori di negazione implicita. Per ulteriori informazioni sugli errori di negazione implicita, consulta La differenza tra negazioni implicite ed esplicite.

Risoluzione

Gli errori di negazione esplicita si verificano a causa di problemi in uno o più dei seguenti criteri:

  • Policy basate su identità
  • Policy basate sulle risorse
  • Limite delle autorizzazioni
  • Policy di controllo dei servizi
  • Policy della sessione

Policy basate su identità

La policy basata sull'identità controlla l'azione consentita/negata di un'entità. Utilizza questi passaggi di risoluzione dei problemi per identificare i problemi con le policy basate sull'identità.

Nota: in alcune condizioni è consigliabile utilizzare Deny con StringNotLike per impedire l'accesso privilegiato accidentale.

1.    Verifica che non vi sia alcuna istruzione di negazione nella policy basata sull'identità. Questo esempio contiene un'istruzione di negazione:

{
  "Effect": "Deny",
  "Action": "iam:DeleteRole"
  "Resource": "*"
}

2.    Verifica se l'autenticazione a più fattori (MFA) è applicata alla tua policy. Se l'entità IAM esegue l'autenticazione senza utilizzare un altro fattore di autenticazione quando viene applicata la MFA, l'autorizzazione sarà negata. Ad esempio, se l'entità esegue l'autenticazione utilizzando l'interfaccia a riga di comando di AWS senza MFA, la chiamata API sarà negata. Guarda questo esempio di applicazione della MFA:

{
  "Sid": "DenyAllExceptListedIfNoMFA",
  "Effect": "Deny",
  "NotAction": [
    "iam:CreateVirtualMFADevice",
    "iam:EnableMFADevice",
    "iam:GetUser",
    "iam:ListMFADevices",
    "iam:ListVirtualMFADevices",
    "iam:ResyncMFADevice",
    "sts:GetSessionToken"
  ],
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
  }
}

questa policy nega esplicitamente tutte le chiamate API, ad eccezione di quelle menzionate nell'elemento di policy NotAction.

3.    Assicurati che la policy soddisfi tutte le condizioni richieste. Se la policy ha più operatori di condizione o più chiavi, le condizioni vengono valutate utilizzando la logica AND. Ogni chiave RequestTag deve essere utilizzata in istruzioni separate per ottenere la stessa logica AND. Questo è un esempio di un problema comune che causa il fallimento della chiamata API:

{
  "Sid": "AllowRunInstancesWithRestrictions2",
  "Effect": "Deny",
  "Action": [
    "ec2:CreateVolume",
    "ec2:RunInstances"
  ],
  "Resource": [
    "arn:aws:ec2:*:*:volume/*",
    "arn:aws:ec2:*:*:instance/*"
  ],
  "Condition": {
    "ForAllValues:StringNotLike": {
      "aws:TagKeys": "Production"
    },
    "StringEquals": {
      "ec2:InstanceType": "t2.micro"
    }
  }
}

per evitare un errore esplicito di accesso rifiutato per queste chiamate API, assicurati che la condizione precedente sia soddisfatta.

Nota: la condizione aws:TagKeys fa distinzione tra maiuscole e minuscole.

Policy basate sulle risorse

La policy basata sulle risorse consente o nega l'accesso a una risorsa. A differenza delle policy basate sull'identità IAM che sono unificate, le policy basate sulle risorse sono progettate dai servizi. I seguenti passaggi per la risoluzione dei problemi utilizzano le policy basate sulle risorse del Servizio di archiviazione semplice Amazon (Amazon S3) e una policy degli endpoint VPC come esempi.

Valutazione delle policy dei bucket S3

La valutazione delle policy del bucket Amazon S3 funziona come segue:

Nota: questo presuppone che l'ACL del bucket sia impostato come predefinito.

  • Per accedere a un bucket nello stesso account, un'entità IAM necessita delle autorizzazioni nella policy del bucket OR basata sull'identità IAM.
  • Per accedere a un bucket in un account diverso, un'entità IAM ha bisogno delle autorizzazioni nella policy del bucket AND basata sull'identità IAM per ottenere l'accesso.

1.    Verifica la presenza di dichiarazioni di rifiuto nella policy basata sulle risorse. Questo esempio mostra una dichiarazione di negazione nella policy del bucket:

{
  "Effect": "deny",
  "Principal": {
    "AWS": "arn:aws:iam::111111111111:role/ROLENAME"
  },
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::MyExampleBucket"
}

2.    Verifica che gli ARN descritti nella policy siano corretti.

3.    La policy del bucket nega l'accesso se aws:userid dell'utente corrente non è uguale a quanto definito nella policy. Guarda questo esempio:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::MyExampleBucket",
        "arn:aws:s3:::MyExampleBucket/*"
      ],
      "Condition": {
        "StringNotLike": {
          "aws:userId": [
            "AROAEXAMPLEID:*",
            "AIDAEXAMPLEID",
            "111111111111"
          ]
        }
      }
    }
  ]
}

Endpoint VPC

Una policy dell'endpoint VPC è una policy delle risorse IAM collegata a un endpoint. Questa policy non sovrascrive né sostituisce le policy dell'utente IAM o le policy specifiche del servizio (come le policy dei bucket S3).

Esistono due modi per controllare l'accesso ai dati di Amazon S3 quando si utilizza un endpoint di interfaccia per connettersi ad Amazon S3:

  • puoi controllare i principali AWS (account AWS, utenti IAM e ruoli IAM) che possono utilizzare l'endpoint VPC per accedere al servizio di endpoint;
  • puoi controllare i VPC o gli endpoint VPC che hanno accesso ai bucket utilizzando le policy dei bucket di Amazon S3.

Questo esempio di seguito è una policy dei bucket di Amazon S3. La policy limita l'accesso a un bucket specifico, denominato examplebucket, dall'endpoint VPC con ID vpce-11111. Se l'endpoint specificato non viene utilizzato, la policy nega tutti gli accessi al bucket. La condizione aws:SourceVpce viene utilizzata per specificare l'endpoint.

{
   "Version": "2012-10-17",
   "Id": "Policy123456789”,
   "Statement": [
     {
       "Sid": "AccessSpecificVPCEOnly",
       "Principal": "*",
       "Action": "s3:*",
       "Effect": "Deny",
       "Resource": ["arn:aws:s3:::examplebucket",
                    "arn:aws:s3:::examplebucket/*"],
       "Condition": {
         "StringNotEqualsIfExists": {
           "aws:SourceVpce": "vpce-11111”
         }
       }
     }
   ]
}

Controlla sempre che l'endpoint VPC non stia negando esplicitamente l'accesso alla risorsa.

Limite delle autorizzazioni

Il limite delle autorizzazioni è una policy gestita che imposta il numero massimo di autorizzazioni che una policy basata su identità può concedere a un'entità IAM. Queste policy gestite possono limitare le autorizzazioni alle entità: ciò potrebbe generare messaggi di errore di negazione esplicita.

Questo esempio mostra un'azione consentita nella policy IAM, ma esplicitamente negata nel limite delle autorizzazioni. Consulta il limite delle autorizzazioni di seguito:

{
  "Version": "2012-10-17",

  "Statement": [

    {
      "Effect": "Deny",
      "Action": "ec2:*"

      "Resource": "*"
    }
  ]
}

L'utente dispone delle seguenti autorizzazioni:

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

Sebbene l'utente disponga dell'autorizzazione RunInstances, riceve un messaggio di negazione esplicita quando la richiede. Per risolvere questo errore, assicurati che il limite delle autorizzazioni e IAM consentano esplicitamente questa azione.

Policy di controllo dei servizi

Una policy di controllo dei servizi (SCP) consente di gestire le autorizzazioni nella propria organizzazione. L'esempio seguente mostra una dichiarazione di negazione nella SCP. In questo esempio, la SCP è collegata a un account membro o a una particolare unità organizzativa (OU). Nega esplicitamente l'accesso all'azione RunInstances:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:RunInstances"

      "Resource": "*"
    }
  ]
}

Per risolvere errori di negazione esplicita, esegui una delle seguenti azioni:

  • scollega la SCP dall'account;
  • modifica la dichiarazione di negazione aggiungendo una condizione che escluda alcuni casi d'uso. Ad esempio, questa SCP in questo esempio NON nega ec2:RunInstances, se il principale IAM utilizza il ruolo CloudOps:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:RunInstances"     
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/CloudOps"
        }
      }
    }
  ]
}

Policy di sessione

Le policy di sessione sono policy avanzate che vengono passate come parametri quando a livello di programmazione si crea una sessione temporanea per un ruolo o un utente. È possibile creare una sessione di ruolo e passare policy di sessione utilizzando le operazioni API AssumeRole, AssumeRoleWithSAML o AssumeRoleWithWebIdentity.

Ad esempio, questa policy genera l'errore di negazione esplicita quando l'utente tenta di effettuare una chiamata all'API RunInstances. Controlla sempre le dichiarazioni di rifiuto nella policy di sessione:

{
  "Version": "2012-10-17",
  
  "Statement": {
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    
    "Resource": "*"
  }
}