Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Steuerung des Konsolenzugriffs mit ressourcenbasierten Richtlinien und Richtlinien zur Ressourcensteuerung

AWS Sign-In unterstützt ressourcenbasierte Richtlinien und Ressourcenkontrollrichtlinien (RCPs) zur Steuerung des Zugriffs auf. AWS Sign-In Verwenden Sie diese Richtlinien, um die Benutzeridentität und den Netzwerkstandort während des gesamten AWS-Managementkonsole Zugriffs zu überprüfen — vor, während und nach der Authentifizierung. Für Root-Benutzer überprüfen diese Richtlinien den Netzwerkstandort und die Benutzeridentität, bevor mit der Erfassung der Anmeldeinformationen begonnen wird. Anmeldeinformationen können nur eingegeben werden, wenn der Zugriff über erwartete Netzwerke erfolgt.

AWS Sign-In ressourcenbasierte Richtlinien:

Richtlinien zur Ressourcenkontrolle (RCPs):

Beide Richtlinientypen überprüfen den Zugriff vor der Authentifizierung. Dadurch wird verhindert, dass Principals von unerwarteten Netzwerken aus auf die Anmeldeseite zugreifen.

Diese Richtlinien ersetzen nicht die identitätsbasierten IAM-Richtlinien, die weiterhin gelten.

AWS Sign-In ressourcenbasierte Richtlinien und RCPs gelten für die folgenden Authentifizierungsmethoden:

Diese Kontrollen gelten nicht für den programmatischen Zugriff mithilfe von Zugriffsschlüsseln (AWS SDKs oder API-Aufrufen, die mit Sigv4 signiert sind).

Wie AWS Sign-In bewertet ressourcenbasierte Richtlinien

AWS Sign-In bewertet die geltenden ressourcenbasierten Richtlinien oder Resource Control Policies (RCPs) zu zwei Zeitpunkten während des Konsolenzugriffs: vor der Authentifizierung (die Phase vor der Authentifizierung) und nach der erfolgreichen Authentifizierung (die Phase nach der Authentifizierung). Bei jeder Evaluierung werden die in Ihrer Richtlinie definierten Bedingungsschlüssel überprüft. Die verfügbaren Schlüssel hängen von der Phase und der Aktion ab. Details hierzu finden Sie unter Unterstützte Bedingungsschlüssel.

Nach der Authentifizierung werden bei der Bewertung auch die identitätsbasierten Richtlinien des Auftraggebers berücksichtigt. Eine IAM-Richtlinie, die die entsprechende Anmeldeaktion verweigert, kann verhindern, dass die Konsolensitzung gewährt wird, selbst wenn die Netzwerkbedingungen erfüllt sind.

Unterstützte Aktionen

AWS Sign-In Ressourcenrichtlinien (ressourcenbasierte Richtlinien und RCPs) unterstützen die folgenden Aktionen:

Unterstützte Bedingungsschlüssel

AWS Sign-In unterstützt die folgenden Bedingungsschlüssel in ressourcenbasierten Richtlinien und Ressourcenkontrollrichtlinien (RCPs). Verwenden Sie diese Tasten, um den Konsolenzugriff auf Grundlage des Netzwerkstandorts und der Prinzidentität zu steuern:

Ausführliche Nutzungsregeln, Operatorkompatibilität, Kombinationseinschränkungen und die Verfügbarkeitsmatrix nach Aktion finden Sie unterAWS Sign-In Referenz zu den Bedingungsschlüsseln.

Erste Schritte mit der Konsolenzugriffskontrolle mithilfe von Ressourcenrichtlinien

Voraussetzungen

Geben Sie dies --region us-east-1 für alle Schreibvorgänge an Richtlinien an. AWS Sign-In AWS repliziert weltweit Richtlinien aus dieser Region. Lesevorgänge können auf jede Region abzielen.

Schritt 1: Erstellen Sie Ressourcenberechtigungserklärungen

Erstellen Sie Berechtigungserklärungen, die Ihre Zugriffskontrollen definieren. Alle Schreibvorgänge erfordern --region us-east-1 (der AWS Sign-In Dienst akzeptiert Richtlinienänderungen nur in dieser Region). Die übrigen Parameter (--source-vpc,--source-ip,--requested-region,--excluded-principal) definieren die Bedingungen in Ihrer Richtlinie. --requested-region us-west-2Fügt beispielsweise eine Bedingung hinzu, die die Anmeldung auf den regionalen Anmeldeendpunkt us-west-2 einschränkt.

Beispiel — Beschränken Sie den Zugriff auf die Unternehmens-VPC:

aws signin put-resource-permission-statement \
  --source-vpc vpc-0abc123def456789 \
  --requested-region us-west-2 \
  --excluded-principal "arn:aws:iam::123456789012:user/EmergencyAdmin" \
  --client-token unique-request-id-12345 \
  --region us-east-1

Beispiel — Beschränken Sie den Zugriff auf einen bestimmten IP-Bereich:

aws signin put-resource-permission-statement \
  --source-ip "IP_ADDRESS" \
  --excluded-principal "arn:aws:iam::123456789012:role/BreakGlassRole" \
  --region us-east-1

Schritt 2: Aktivieren Sie die Konfiguration der Konsolenautorisierung

Der folgende Schritt aktiviert die Richtliniendurchsetzung für den Konsolenanmeldevorgang in Ihrem Konto oder Ihrer Organisation. Ressourcenberechtigungserklärungen können jederzeit erstellt werden, sie werden jedoch erst ausgewertet, wenn die Konsolenautorisierung aktiviert ist.

Für eigenständige Konten:

aws signin put-console-authorization-configuration \
  --target-id <your-aws-account-id> \
  --region us-east-1

Für AWS Organizations:

aws signin put-console-authorization-configuration \
  --target-id <your-aws-organization-id> \
  --region us-east-1

Überprüfen Sie die Konfiguration:

aws signin get-console-authorization-configuration \
  --target-id <your-target-id> \
  --region <your-region>

Löschen Sie die Autorisierungskonfiguration für die Konsole:

aws signin delete-console-authorization-configuration \
  --target-id <your-target-id> \
  --region us-east-1

Schritt 3: Überprüfen Sie Ihre Richtlinie

Alle Genehmigungserklärungen auflisten:

aws signin list-resource-permission-statements \
  --max-results 50 \
  --region <your-region>

Rufen Sie die vollständige konsolidierte Richtlinie ab:

aws signin get-resource-policy \
  --region <your-region>

Der get-resource-policy Befehl gibt die vollständige ressourcenbasierte Richtlinie zurück, die sich aus all Ihren Berechtigungsanweisungen zusammensetzt. Überprüfen Sie diese Richtlinie, um sicherzustellen, dass sie Ihren beabsichtigten Zugriffskontrollen entspricht, bevor Sie den Konsolenzugriff testen.

Regionale Verfügbarkeit

APIs zur Konsolenautorisierung sind in allen AWS kommerziellen Regionen verfügbar. Sie können diese APIs von jeder Region aus aufrufen, in der Sie tätig sind.

Die Richtlinienstruktur verstehen

AWS Sign-In Richtlinien enthalten zwei Aussagen, die verschiedene Phasen des Anmeldevorgangs auf der Konsole schützen:

Beide Anweisungen sind erforderlich, da bei der Konsolenanmeldung OAuth 2.0 verwendet wird, bei dem alle drei Aktionen nacheinander ausgeführt werden. Eine Richtlinie mit nur einer Anweisung lässt die andere Phase ungeschützt. signin:PrincipalArnunterstützt Root-Benutzer-, IAM-Benutzer- und Rollenprinzipaltypen. aws:PrincipalArnunterstützt alle Prinzipaltypen (Root-Benutzer, IAM-Benutzer, Verbundbenutzer, Rolle).

Beispiele für Richtlinien

Beispiel 1: RCP mit Netzwerkperimeter und ausgeschlossenen Principals

Die folgende Resource Control Policy (RCP) verweigert allen Konten in Ihrer Organisation die AWS-Managementkonsole Anmeldung von außerhalb Ihres Unternehmensnetzwerks. Bestimmte ausgeschlossene Hauptbenutzer sind vom Notfallzugriff ausgenommen. Da VPC-IDs nur innerhalb einer Region eindeutig sind, beinhaltet die Richtlinie eine dritte Aussage, die den VPC-based Zugriff auf die erwartete Region festlegt.

Die EnforceNetworkPerimeterPreAuth Erklärung dient signin:PrincipalArn dazu, ausgeschlossene Principals in der Phase vor der Authentifizierung auszunehmen. EnforceNetworkPerimeterPostAuthIn der Erklärung werden ausgeschlossene Hauptbenutzer aws:PrincipalArn nach der Authentifizierung ausgenommen. Die EnforceSourceVPCRegion Anweisung stellt sicher, dass die Anforderungsregion mit der VPC-Region übereinstimmt, wodurch der Zugriff auf die erwartete Region für die angegebene VPC eingeschränkt wird.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceNetworkPerimeterPreAuth",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["signin:Authenticate"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "signin:PrincipalArn": [
            "arn:aws:iam::111122223333:root",
            "arn:aws:iam::444455556666:root",
            "arn:aws:iam::777788889999:user/EmergencyUser",
            "arn:aws:iam::777788889999:role/OrgBreakGlassRole"
          ]
        },
        "NotIpAddressIfExists": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringNotEquals": {
          "aws:SourceVpc": "<my-vpc>"
        }
      }
    },
    {
      "Sid": "EnforceNetworkPerimeterPostAuth",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": [
            "arn:aws:iam::111122223333:root",
            "arn:aws:iam::444455556666:root",
            "arn:aws:iam::777788889999:user/EmergencyUser",
            "arn:aws:iam::777788889999:role/OrgBreakGlassRole"
          ]
        },
        "NotIpAddressIfExists": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringNotEquals": {
          "aws:SourceVpc": "<my-vpc>"
        }
      }
    },
    {
      "Sid": "EnforceSourceVPCRegion",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "signin:Authenticate",
        "signin:CreateOAuth2Token",
        "signin:AuthorizeOAuth2Access"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpc": "<my-vpc>"
        },
        "StringNotEqualsIfExists": {
          "aws:RequestedRegion": "<my-vpc-region>"
        }
      }
    }
  ]
}

Diese Richtlinie:

Beispiel 2: Resource-based Richtlinie für den IP-based Zugriff mit ausgeschlossenem Hauptbenutzer

Die folgende ressourcenbasierte Richtlinie verweigert allen Prinzipalen, die Anfragen von außerhalb des angegebenen IP-Bereichs stellen, den Konsolenzugriff, wobei ein ausgeschlossener Prinzipal ausgenommen ist. Die Richtlinie enthält zwei Anweisungen: eine Anweisung vor der Authentifizierung, die den dienstspezifischen signin:PrincipalArn Schlüssel verwendet, und eine Anweisung nach der Authentifizierung, die den globalen Schlüssel verwendet. aws:PrincipalArn

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": { "AWS": "*" },
      "Action": ["signin:Authenticate"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "signin:PrincipalArn": "<excluded-principal-arn>"
        },
        "NotIpAddress": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringEquals": {
          "aws:ResourceAccount": "<my-aws-account-id>"
        }
      }
    },
    {
      "Effect": "Deny",
      "Principal": { "AWS": "*" },
      "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": "<excluded-principal-arn>"
        },
        "NotIpAddress": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringEquals": {
          "aws:ResourceAccount": "<my-aws-account-id>"
        }
      }
    }
  ]
}

Diese Richtlinie:

Best Practices

Konfigurieren Sie ausgeschlossene Principals für den Zugriff auf die Notfallwiederherstellung

AWS empfiehlt, mindestens einen ausgeschlossenen Benutzer zu konfigurieren, bevor Autorisierungsrichtlinien für die Konsole in der Produktion durchgesetzt werden. In der Phase vor der Authentifizierung schließt der signin:PrincipalArn Bedingungsschlüssel Root-Benutzer, IAM-Benutzer und Rollenprinzipale aus. In der Phase nach der Authentifizierung schließt der aws:PrincipalArn Bedingungsschlüssel alle Prinzipaltypen (Root-Benutzer, IAM-Benutzer, Verbundbenutzer, Rolle) aus.

Ausgeschlossene Prinzipale sind optional, aber wenn sie weggelassen werden, erhöht sich das Risiko einer Kontosperrung, wenn sich die Netzwerkbedingungen unerwartet ändern oder wenn Richtlinien falsch konfiguriert sind.

Empfohlene Konfigurationsschritte für ausgeschlossene Prinzipale:

Pflegen Sie die Zugangswege für die Wiederherstellung

Stellen Sie zusätzlich zu dem oben beschriebenen ausgeschlossenen Hauptbenutzer sicher, dass alternative Zugriffsmethoden verfügbar sind, falls die Autorisierungsrichtlinien der Konsole die Anmeldung unerwartet blockieren:

Testen Sie vor der Bereitstellung in der Produktion

AWS empfiehlt, restriktive RCPs nicht an das Stammverzeichnis Ihrer Organisation anzuhängen, ohne die Auswirkungen der Richtlinie auf Konten gründlich zu testen. Erstellen Sie stattdessen eine Organisationseinheit, in die Sie Ihre Konten einzeln oder zumindest in geringer Anzahl verschieben können, um sicherzustellen, dass Sie Benutzer nicht versehentlich von wichtigen Konten ausschließen.

Arbeitsablauf testen:

Entwerfen Sie mit tiefgehendem Schutz

Verwenden Sie AWS Sign-In ressourcenbasierte Richtlinien und Richtlinien zur Ressourcenkontrolle als eine Ebene innerhalb einer umfassenderen Sicherheitsstrategie. AWS Sign-In Richtlinien schränken den Konsolenzugriff je nach Netzwerkstandort und Prinzidentität ein. Kombinieren Sie sie mit anderen Richtlinientypen, um umfassende Zugriffskontrollen zu erstellen:

Kontinuierliche Überwachung und Prüfung

AWS CloudTrail zeichnet automatisch alle AWS Sign-In Richtlinienbewertungen und Konfigurationsänderungen auf. Sie können sich diese Ereignisse bis zu 90 Tage lang im CloudTrail Ereignisverlauf anzeigen lassen. Für eine längere Aufbewahrung können Sie Ereignisse an Amazon S3 weiterleiten, indem Sie einen Trail erstellen (siehe Erstellen eines Trails). Für Benachrichtigungen in Echtzeit können Sie EventBridge Amazon-Regeln erstellen, die AWS Sign-In Ereignissen entsprechen, Ihren Trail so konfigurieren, dass er an eine CloudWatch Logs-Protokollgruppe für metrische filterbasierte Alarme gesendet wird, oder Ereignisse an Ihre bestehende SIEM-Lösung weiterleiten.

Anwendungsfälle

Problembehandlung bei der Konsolenzugriffskontrolle

Ich kann mich aufgrund von Netzwerkproblemen in Sign-in ressourcenbasierten Richtlinien nicht anmelden

Möglicherweise wird eine der folgenden Fehlermeldungen angezeigt, wenn der Zugriff durch eine AWS Sign-In Richtlinie verweigert wird:

Wenn Sie einen dieser Fehler sehen und der Meinung sind, dass Ihr Zugriff erlaubt sein sollte, wenden Sie sich an Ihren AWS Administrator. Sie können die CloudTrail Protokolle auf ConsoleLogin Ereignisse mit der Angabe errorMessage „Autorisierung aufgrund einer ressourcenbasierten Richtlinie verweigert“ oder „Autorisierung aufgrund einer Ressourcenkontrollrichtlinie verweigert“ überprüfen, um festzustellen, welche Richtlinienaussage den Zugriff verweigert hat.

Mögliche Ursachen:

Auflösung

Für Administratoren, die dieses Problem diagnostizieren:

Nach der Aktivierung der Konsolenautorisierung wurde mein Konto gesperrt

Wenn Sie die Konsolenautorisierung konfiguriert haben und nicht mehr auf Ihr Konto zugreifen können, haben Sie möglicherweise keine ausgeschlossenen Principals konfiguriert, bevor Sie die Richtlinie durchgesetzt haben.

Abhängig von Ihrem Kontotyp und den verfügbaren Anmeldeinformationen gibt es mehrere Wege, um den Zugriff wiederherzustellen.

Option 1: Verwenden Sie den programmatischen Zugriff (AWS CLI oder SDK)

Autorisierungsrichtlinien für Konsolen gelten nur für die interaktive Konsolenanmeldung. Sie gelten nicht für API-Anfragen, die mit Sigv4 signiert wurden. Wenn Sie programmgesteuerten Zugriff haben (z. B. vorhandene Zugriffsschlüssel, eine kontoübergreifende Rolle), verwenden Sie diesen, um die einschränkende Richtlinie aufzurufen signin:DeleteConsoleAuthorizationConfiguration und zu entfernen. Die von Ihnen verwendeten Anmeldeinformationen müssen über eine Anrufberechtigung verfügen. signin:DeleteConsoleAuthorizationConfiguration Die AWSSignInResourcePolicyManagement verwaltete Richtlinie beinhaltet diese Berechtigung. AWS empfiehlt temporäre Anmeldeinformationen gegenüber langfristigen IAM-Benutzerzugriffsschlüsseln. Bei Mitgliedskonten können Administratoren des Verwaltungskontos davon ausgehenOrganizationAccountAccessRole, dass sie temporäre Anmeldeinformationen für das Mitgliedskonto erhalten. Diese Rolle wird nicht automatisch für Konten erstellt, die eingeladen wurden, der Organisation beizutreten.

aws signin delete-console-authorization-configuration \
  --target-id <your-aws-account-id> \
  --region us-east-1

Oder löschen Sie bestimmte Berechtigungserklärungen:

# First, list statements to get the statement ID
aws signin list-resource-permission-statements \
  --region us-east-1

# Then delete the problematic statement
aws signin delete-resource-permission-statement \
  --statement-id <statement-id> \
  --region us-east-1

Option 2: AWS Support kontaktieren

Wenn Sie keinen programmatischen Zugriff haben und den OrganizationAccountAccessRole für den Kontozugriff nicht verwenden können, wenden Sie sich an den AWS Support, um den Lockout-Wiederherstellungsprozess einzuleiten.

Der Wiederherstellungsprozess funktioniert wie folgt:

Der Link zum Wiederherstellungsportal läuft 72 Stunden ab, nachdem der AWS Support ihn freigegeben hat. Wenn Sie die Wiederherstellung in diesem Fenster nicht abschließen, wenden Sie sich an den AWS Support, um den Vorgang neu zu starten.

Nach Wiedererlangung des Zugriffs:

Änderungen, die ich vornehme, sind nicht immer direkt sichtbar

Richtlinienänderungen werden global repliziert, die Replikation kann jedoch einige Minuten dauern.

Auflösung

aws signin get-resource-policy --region <your-region>

Häufige Probleme bei der Richtlinienreplikation: