AWS IAM meistern: Zugriffsverweigerungsfehler effektiv beheben

AWS IAM AccessDenied-Fehler bedeuten, dass AWS Ihre Anfrage ausgewertet hat und keinen effektiven Berechtigungspfad gefunden hat. Der schnellste Weg zur Behebung ist nicht, eine breitere Richtlinie zu erraten, sondern die genaue Aktion, Ressource, den Prinzipal und den Bedingungskontext zu identifizieren, die AWS ausgewertet hat.

Die meisten IAM-Fehler haben eine von vier Ursachen: keine passende Allow-Anweisung, eine explizite Deny-Anweisung, eine Berechtigungsgrenze oder eine Service Control Policy, die die Identität einschränkt, oder eine Bedingung, die nicht mit der Anfrage übereinstimmt.

Beginnen Sie mit der IAM-Evaluierungslogik

AWS beginnt mit einer standardmäßigen Verweigerung. Eine Anfrage wird nur dann erlaubt, wenn eine anwendbare Richtlinie sie erlaubt und keine anwendbare Richtlinie sie verweigert.

Eine explizite Deny-Anweisung hat Vorrang vor jeder Allow-Anweisung. Diese Verweigerung kann aus einer Identitätsrichtlinie, Ressourcenrichtlinie, Berechtigungsgrenze, Sitzungsrichtlinie, Service Control Policy oder einem anderen anwendbaren Richtlinientyp stammen.

Bei Zugriffen innerhalb desselben Kontos arbeiten Identitätsrichtlinien und Ressourcenrichtlinien oft zusammen. Bei kontenübergreifenden Zugriffen benötigen Sie in der Regel Berechtigungen auf beiden Seiten: Die Identität des Aufrufers muss zur Ausführung der Anfrage berechtigt sein, und die Zielressource oder das Zielkonto muss diesen Aufrufer vertrauen oder ihm die Berechtigung erteilen.

Erfassen Sie die genaue fehlgeschlagene Anfrage

Bevor Sie Richtlinien bearbeiten, erfassen Sie diese Details:

• Prinzipal: Benutzer, Rolle, Sitzung einer angenommenen Rolle oder AWS-Serviceprinzipal.
• Aktion: Der API-Vorgang, z. B. s3:GetObject oder ec2:RunInstances.
• Ressource: Die ARN oder Ressourcen-ID.
• Region und Konto.
• Bedingungen: Quell-IP, VPC-Endpunkt, MFA, Tags, Verschlüsselungskontext oder angeforderte Region.

CloudTrail ist in der Regel die beste Quelle. Suchen Sie nach dem fehlgeschlagenen Ereignis um den Zeitpunkt des Fehlers und überprüfen Sie eventName, userIdentity, resources, errorCode und errorMessage.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances \
  --max-results 10

CloudTrail erklärt nicht jede Autorisierungsentscheidung bis ins letzte Detail, liefert aber oft die fehlende Aktion und den tatsächlichen Prinzipal. Das allein deckt viele Verwechslungen mit angenommenen Rollen und Sitzungsnamen auf.

Verwenden Sie Simulations- und Zugriffsanalysetools

Der IAM Policy Simulator kann viele identitätsbasierte Richtlinienfragen testen, bevor Sie Produktionsberechtigungen ändern. Wählen Sie den Benutzer oder die Rolle, wählen Sie die Serviceaktion, geben Sie nach Möglichkeit die Ressourcen-ARN an und fügen Sie relevante Bedingungsschlüssel hinzu.

Überprüfen Sie bei neueren AWS-Konten und -Services auch die Zugriffsverweigerungsmeldung selbst. Einige Services geben eine codierte Autorisierungsfehlermeldung zurück. Wenn Sie die Berechtigung haben, decodieren Sie sie mit STS:

aws sts decode-authorization-message \
  --encoded-message '<encoded-message-from-error>'

Diese decodierte Nachricht kann anzeigen, welcher Richtlinientyp zur Verweigerung beigetragen hat.

IAM Access Analyzer ist nützlich für Fragen zu Ressourcenrichtlinien und kontenübergreifenden Zugriffen. Es kann helfen, unbeabsichtigten externen Zugriff zu erkennen und einige Richtlinien vor der Bereitstellung zu validieren.

Überprüfen Sie jede Richtlinienebene

Identitätsbasierte Richtlinien werden an Benutzer, Gruppen und Rollen angehängt. Sie legen fest, was die Identität tun kann.

Ressourcenbasierte Richtlinien werden an Ressourcen wie S3-Buckets, KMS-Schlüssel, SQS-Warteschlangen, Lambda-Funktionen und Rollenvertrauensrichtlinien angehängt. Sie legen fest, wer diese Ressource nutzen oder diese Rolle annehmen kann.

Berechtigungsgrenzen legen die maximalen Berechtigungen für einen Benutzer oder eine Rolle fest. Sie gewähren selbst keinen Zugriff. Die effektiven Berechtigungen sind die Schnittmenge aus Identitätsrichtlinie und Grenze.

Service Control Policies in AWS Organizations legen maximale Berechtigungen für Konten oder Organisationseinheiten fest. SCPs gewähren selbst ebenfalls keinen Zugriff. Sie können eine Aktion blockieren, selbst wenn eine IAM-Richtlinie sie erlaubt.

Sitzungsrichtlinien und Berechtigungs-Tags können den Zugriff für Sitzungen angenommener Rollen ebenfalls einschränken. Wenn eine Rolle in einem Pfad funktioniert, aber fehlschlägt, wenn sie von einem CI-Job angenommen wird, vergleichen Sie die Sitzungsrichtlinie, Sitzungs-Tags und Bedingungen der Vertrauensrichtlinie.

Häufige AccessDenied-Muster

Fehlende abhängige Aktionen

Einige AWS-Operationen erfordern mehr als die offensichtliche Aktion. Zum Beispiel kann das Starten einer verschlüsselten EC2-Instanz EC2-Berechtigungen sowie KMS-Berechtigungen für den Schlüssel erfordern. CloudTrail und die Servicedokumentation sind Ihre besten Referenzen für abhängige Aktionen.

Falsche Ressourcen-ARN

S3-Bucket-Ebene und Objekt-Ebene ARNs sind unterschiedlich:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

arn:aws:s3:::my-bucket deckt den Bucket ab. arn:aws:s3:::my-bucket/* deckt Objekte im Bucket ab. Viele S3-Fehler entstehen dadurch, dass eine ARN gewährt wird, während der API-Aufruf die andere benötigt.

Bedingungskonflikt

Bedingungen müssen exakt mit dem Anforderungskontext übereinstimmen. Eine Richtlinie, die den Zugriff nur über einen VPC-Endpunkt erlaubt, verweigert Anfragen von einem anderen Endpunkt, vom öffentlichen AWS-Endpunkt oder von einer anderen Region, wenn die Bedingung diese Region prüft.

{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-sensitive-data",
    "arn:aws:s3:::my-sensitive-data/*"
  ],
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "false"
    }
  }
}

Diese Anweisung verweigert HTTP-Anfragen und erlaubt HTTPS-Anfragen, die durch die restliche Richtlinienauswertung fortgesetzt werden. Sie gewährt selbst keinen Zugriff.

Lücken in der KMS-Schlüsselrichtlinie

KMS ist eine häufige Quelle für verwirrende Zugriffsfehler. Eine IAM-Richtlinie erlaubt möglicherweise kms:Decrypt, aber die Schlüsselrichtlinie muss den Prinzipal auch direkt erlauben oder dem Konto erlauben, den Zugriff über IAM-Richtlinien zu delegieren.

Überprüfen Sie die Schlüsselrichtlinie, Grants, Verschlüsselungskontextbedingungen und den Service, der den Schlüssel verwendet.

Ein praktischer Fehlerbehebungsablauf

Reproduzieren oder erfassen Sie zunächst den fehlschlagenden Aufruf. Ermitteln Sie die genaue API-Aktion und den Prinzipal aus CloudTrail.

Suchen Sie als Nächstes nach expliziten Verweigerungen in SCPs, Ressourcenrichtlinien, Berechtigungsgrenzen und Identitätsrichtlinien. Explizite Verweigerungen sparen Zeit, da sie alles andere überschreiben.

Bestätigen Sie dann, dass es eine passende Erlaubnis für die genaue Aktion und Ressource gibt. Fügen Sie abhängige Aktionen und zugehörige Ressourcen wie KMS-Schlüssel, an Services übergebene IAM-Rollen, Netzwerkschnittstellen oder Log-Gruppen hinzu.

Testen Sie schließlich mit der kleinstmöglichen Richtlinienänderung. Vermeiden Sie es, eine unbekannte Verweigerung mit Action: "*" oder Resource: "*" zu beheben; das verbirgt das Problem und schafft ein neues Sicherheitsrisiko.

Die nützliche Gewohnheit ist, jeden AccessDenied als ein Evidenzproblem zu behandeln. Sobald Sie den Prinzipal, die Aktion, die Ressource und die Richtlinienebene kennen, ist die Behebung in der Regel klein und klar.