Wie behebe ich explizite Verweigerungsfehlermeldungen beim Anfordern von API-Aufrufen mithilfe von IAM-Rollen oder -Benutzern?

Lesedauer: 7 Minute
0

Ich habe eine ausdrückliche Verweigerungsfehlermeldung erhalten, als ich einen API-Aufruf mithilfe einer AWS Identity-and-Access-Management-Rolle (IAM) oder eines Benutzers angefordert habe. Wie kann ich explizite Verweigerungsfehlermeldungen beheben?

Kurzbeschreibung

Damit eine IAM-Entität (Rolle oder Benutzer) einen erfolgreichen API-Aufruf ausführen kann, muss die Entität die folgenden Bedingungen erfüllen:

  • Die Rolle oder der Benutzer hat die richtigen Berechtigungen, um einen API-Aufruf anzufordern.
  • Die Berechtigung wird nicht durch eine Aussage in allen Richtlinien verweigert, die für den Anforderungskontext gelten.

Wenn Ihre IAM-Entität diese Bedingungen nicht erfüllt, schlägt der API-Aufruf fehl und löst einen (AccessDenied)-Fehler aus, der dem folgenden ähnelt:

  • IAM-Benutzer oder Rolle, bei dem das Problem auftritt: arn:XXXXXXXX:iam: :XXXXXXXX:role/TestReadOnly

Error: An error occurred (AccessDenied) when calling the RunInstances operation: User: arn:aws:iam::XXXXXXXX:user/tester is not authorized to perform: ec2:RunInstances on resource: role TestReadOnly with an explicit deny

Hinweis: Die Schritte zur Problembehandlung in diesem Artikel behandeln speziell explizite Verweigerungsfehler und nicht implizite Verweigerungsfehler. Weitere Hinweise zu impliziten Verweigerungsfehlern finden Sie unter Der Unterschied zwischen impliziten und expliziten Verweigerungen.

Lösung

Explizite Verweigerungsfehler treten aufgrund von Problemen in einer oder mehreren der folgenden Richtlinien auf:

  • Identitätsbasierte Richtlinien
  • Ressourcenbasierte Richtlinien
  • Grenze für Berechtigungen
  • Service-Kontrollrichtlinien
  • Richtlinie für Sitzungen

Identitätsbasierte Richtlinien

Die identitätsbasierte Richtlinie steuert die erlaubte/verweigerte Aktion einer Entität. Verwenden Sie diese Schritte zur Problembehandlung, um Probleme mit identitätsbasierten Richtlinien zu identifizieren.

Hinweis: Es empfiehlt sich, Verweigern mit StringNotLike unter Bedingungen zu verwenden, um versehentlichen privilegierten Zugriff zu verhindern.

1.    Vergewissern Sie sich, dass Ihre identitätsbasierte Richtlinie keine Verweigerungsanweisung enthält. Dieses Beispiel enthält eine Verweigerungsanweisung:

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

2.    Prüfen Sie, ob die Multi-Faktor-Authentifizierung (MFA) in Ihrer Richtlinie durchgesetzt wird. Wenn sich Ihre IAM-Entität bei der Durchsetzung der MFA ohne Verwendung eines anderen Authentifizierungsfaktors authentifiziert, wird die Berechtigung verweigert. Wenn sich Ihre Entität beispielsweise mit der AWS CLI ohne MFA authentifiziert, wird Ihr API-Aufruf verweigert. Sehen Sie sich dieses Beispiel für die Durchsetzung von MFA an:

{
  "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"}
  }
}

Diese Richtlinie lehnt ausdrücklich alle API-Aufrufe ab, mit Ausnahme derjenigen, die im NotAction-Richtlinienelement erwähnt werden.

3.    Stellen Sie sicher, dass Ihre Richtlinie alle erforderlichen Bedingungen erfüllt. Wenn Ihre Richtlinie über mehrere Bedingungsoperatoren oder mehrere Schlüssel verfügt, werden die Bedingungen mithilfe der UND-Logik ausgewertet. Jeder RequestTag-Schlüssel muss in separaten Anweisungen verwendet werden, um dieselbe UND-Logik zu erhalten. Dies ist ein Beispiel für ein häufiges Problem, das dazu führt, dass der API-Aufruf fehlschlägt:

{
  "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"
    }
  }
}

Um einen expliziten Zugriffsverweigerungsfehler für diese API-Aufrufe zu vermeiden, stellen Sie sicher, dass die vorhergehende Bedingung erfüllt ist.

Hinweis: Die aws:TagKeys-Bedingung unterscheidet zwischen Groß- und Kleinschreibung.

Ressourcenbasierte Richtlinien

Die ressourcenbasierte Richtlinie erlaubt oder verweigert den Zugriff auf eine Ressource. Im Gegensatz zu identitätsbasierten IAM-Richtlinien, die vereinheitlicht sind, werden ressourcenbasierte Richtlinien von Services erstellt. In den folgenden Schritten zur Fehlerbehebung werden ressourcenbasierte Richtlinien von Amazon Simple Storage Service (Amazon S3) und eine VPC-Endpunktrichtlinie als Beispiele verwendet.

Bewertung der S3-Bucket-Richtlinie

Die Bewertung der Amazon S3-Bucket-Richtlinie funktioniert wie folgt:

Hinweis: Dies setzt voraus, dass die Bucket-ACL als Standard festgelegt ist.

  • Um auf einen Bucket im selben Konto zuzugreifen, benötigt eine IAM-Entität Berechtigungen in der identitätsbasierten IAM-Einheit ODER der Bucket-Richtlinie.
  • Um auf einen Bucket in einem anderen Konto zuzugreifen, benötigt eine IAM-Entität Berechtigungen in der Bucket-Richtlinie UND der identitätsbasierten IAM-Einheit, um Zugriff zu erhalten.

1.    Suchen Sie in der ressourcenbasierten Richtlinie nach Verweigerungsanweisungen. Dieses Beispiel zeigt eine Verweigerungsanweisung in der Bucket-Richtlinie:

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

2.    Vergewissern Sie sich, dass die in Ihrer Richtlinie beschriebenen ARNs korrekt sind.

3.    Die Bucket-Richtlinie verweigert den Zugriff, wenn die aws:userid des aktuellen Benutzers nicht mit der Definition in der Richtlinie übereinstimmt. Werfen Sie einen Blick auf folgendes Beispiel:

{
  "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"
          ]
        }
      }
    }
  ]
}

VPC-Endpunkt

Eine VPC-Endpunktrichtlinie ist eine IAM-Ressourcenrichtlinie, die an einen Endpunkt angehängt ist. Diese Richtlinie überschreibt oder ersetzt nicht die IAM-Benutzerrichtlinien oder dienstspezifischen Richtlinien (wie S3-Bucket-Richtlinien).

Es gibt zwei Möglichkeiten, den Zugriff auf Ihre Amazon S3-Daten zu steuern, wenn Sie einen Schnittstellen-Endpunkt für die Verbindung mit Amazon S3 verwenden:

  • Sie können die AWS-Prinzipale (AWS-Konten, IAM-Benutzer und IAM-Rollen) steuern, die den VPC-Endpunkt für den Zugriff auf den Endpunktservice verwenden können.
  • Sie können die VPCs oder VPC-Endpunkte, die Zugriff auf Ihre Buckets haben, mithilfe von Amazon S3-Bucket-Richtlinien steuern.

Das folgende Beispiel ist eine Amazon S3-Bucket-Richtlinie. Die Richtlinie schränkt den Zugriff auf einen bestimmten Bucket, genannt examplebucket, vom VPC-Endpunkt mit der ID vpce-11111 aus ein. Die Richtlinie verweigert jeglichen Zugriff auf den Bucket, wenn der angegebene Endpunkt nicht verwendet wird. Die aws:SourceVpce-Bedingung wird verwendet, um den Endpunkt anzugeben.

{
   "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”
         }
       }
     }
   ]
}

Vergewissern Sie sich immer, dass der VPC-Endpunkt den Zugriff auf die Ressource nicht explizit verweigert.

Grenze für Berechtigungen

Die Berechtigungsgrenze ist eine verwaltete Richtlinie. Sie legt die maximalen Berechtigungen fest, die mit einer identitätsbasierten Richtlinie einer IAM-Entität erteilt werden kann. Diese verwaltete Richtlinie kann Berechtigungen auf Entitäten beschränken, was zu expliziten Verweigerungsfehlermeldungen führen kann.

Dieses Beispiel zeigt eine Aktion, die in der IAM-Richtlinie zulässig ist, aber in der Berechtigungsgrenze explizit verweigert wird. Werfen Sie einen Blick auf die folgenden Berechtigungsgrenzen:

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

  "Statement": [

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

      "Resource": "*"
    }
  ]
}

Der Benutzer hat die folgenden Berechtigungen:

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

Obwohl der Benutzer über die RunInstances-Berechtigung verfügt, erhält er eine explizite Verweigerungs-Nachricht, wenn er sie anfordert. Um diesen Fehler zu beheben, stellen Sie sicher, dass Ihre Berechtigungsgrenze und Ihr IAM diese Aktion ausdrücklich zulassen.

Service-Kontrollrichtlinien

Eine Service-Kontrollrichtlinie (SCP) ermöglicht es Ihnen, Berechtigungen in Ihrer Organisation zu verwalten. Das folgende Beispiel zeigt eine Verweigerungsanweisung im SCP. In diesem Beispiel ist die SCP mit einem Mitgliedskonto oder einer bestimmten Organisationseinheit (OU) verknüpft. Sie verweigert ausdrücklich den Zugriff auf die RunInstances-Aktion:

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

      "Resource": "*"
    }
  ]
}

Führen Sie eine der folgenden Aktionen aus, um explizite Verweigerungsfehler zu beheben:

  • Trennen Sie die SCP vom Konto.
  • Ändern Sie die Verweigerungsanweisung, indem Sie eine Bedingung hinzufügen, die einige Anwendungsfälle ausschließt. Beispielsweise verweigert diese SCP in diesem Beispiel NICHT ec2:RunInstances, wenn der IAM-Prinzipal die Rolle CloudOps verwendet:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:RunInstances"     
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/CloudOps"
        }
      }
    }
  ]
}

Session-Richtlinien

Session-Richtlinien sind erweiterte Richtlinien, die Sie als Parameter übergeben, wenn Sie programmgesteuert eine temporäre Sitzung für eine Rolle oder einen Benutzer erstellen. Sie können eine Rollensitzung erstellen und Session-Richtlinien übergeben, indem Sie die API-Vorgänge AssumeRole, AssumeRoleWithSAML oder AssumeRoleWithWebIdentity verwenden.

Diese Richtlinie generiert beispielsweise den expliziten Verweigerungsfehler, wenn der Benutzer versucht, einen RunInstances-API-Aufruf durchzuführen. Überprüfen Sie die Sitzungsrichtlinie immer auf Verweigerungsanweisungen:

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

Relevante Informationen

Zugriffsmanagement für AWS-Ressourcen

Verwenden von Service-Kontrollrichtlinien zum Festlegen eines kontenübergreifenden Integritätsschutzes für Berechtigungen in AWS Organizations

Berechtigungsgrenzen für IAM-Entitäten

So schränken Sie den Amazon S3-Bucket-Zugriff auf eine bestimmte IAM-Rolle ein

Steuern des Zugriffs von VPC-Endpunkten mit Bucket-Richtlinien

AWS OFFICIAL
AWS OFFICIALAktualisiert vor 2 Jahren