Überwachen und Steuern von Aktionen mit übernommenen Rollen

Eine IAM-Rolle ist ein Objekt in IAM, dem Berechtigungen zugewiesen sind. Wenn Sie diese Rolle mit einer IAM-Identität oder einer Identität von außerhalb übernehmen AWS, erhalten Sie eine Sitzung mit den Berechtigungen, die der Rolle zugewiesen sind.

Wenn Sie Aktionen in ausführen AWS, können die Informationen über Ihre Sitzung protokolliert werden, AWS CloudTrail sodass Ihr Kontoadministrator sie überwachen kann. Administratoren können Rollen so konfigurieren, dass Identitäten eine benutzerdefinierte Zeichenfolge übergeben müssen, die die Person oder Anwendung identifiziert, die Aktionen in AWS durchführt. Diese Identitätsinformation wird als Quellidentität in AWS CloudTrail gespeichert. Wenn der Administrator die Aktivitäten in überprüft CloudTrail, kann er anhand der Informationen zur Quellenidentität feststellen, wer oder was Aktionen in Sitzungen mit angenommenen Rollen ausgeführt hat.

Nachdem eine Quellidentität festgelegt wurde, ist sie in Anfragen für alle AWS Aktionen enthalten, die während der Rollensitzung ausgeführt wurden. Der festgelegte Wert bleibt bestehen, wenn eine Rolle verwendet wird, um über die AWS CLI AWS OR-API eine andere Rolle anzunehmen, was als Rollenverkettung bezeichnet wird. Der festgelegte Wert kann während der Rollensitzung nicht geändert werden. Administratoren können detaillierte Berechtigungen auf der Grundlage des Vorhandenseins oder des Werts der Quellidentität konfigurieren, um die AWS Aktionen, die mit gemeinsam genutzten Rollen ausgeführt werden, weiter zu kontrollieren. Sie können entscheiden, ob das Quellidentitätsattribut verwendet werden kann, ob es erforderlich ist und welcher Wert verwendet werden kann.

Die Art und Weise, wie Sie die Quellidentität verwenden, unterscheidet sich von Rollensitzungsnamen und Sitzungs-Tags auf wichtige Weise. Der Quellidentitätswert kann nicht geändert werden, nachdem er festgelegt wurde, und er bleibt für alle zusätzlichen Aktionen bestehen, die mit der Rollensitzung ausgeführt werden. So können Sie Sitzungs-Tags und Rollensitzungsnamen verwenden:

• Sitzungs-Tags – Sie können Sitzungs-Tags übergeben, wenn Sie eine Rolle übernehmen oder einen Benutzer föderieren. Sitzungs-Tags sind vorhanden, wenn eine Rolle angenommen wird. Sie können Richtlinien definieren, die Tag-Bedingungsschlüssel verwenden, um Ihren Auftraggeber basierend auf ihren Tags Berechtigungen zu erteilen. Anschließend können Sie die Anfragen CloudTrail zur Übernahme von Rollen oder zur Zusammenführung von Benutzern anzeigen. Weitere Informationen zu Sitzungs-Tags finden Sie unter Sitzungs-Tags übergeben AWS STS.

• Rollensitzungsname – Sie können den sts:RoleSessionName-Bedingungsschlüssel in einer Rollenvertrauensrichtlinie verwenden, um zu verlangen, dass Ihre Benutzer einen bestimmten Sitzungsnamen angeben, wenn sie eine Rolle übernehmen. Rollensitzungsname kann verwendet werden, um Rollensitzungen zu unterscheiden, wenn eine Rolle von verschiedenen Auftraggeber verwendet wird. Weitere Informationen zum Namen der Rollensitzung finden Sie unter sts: RoleSessionName.

Es wird empfohlen, die Quellidentität zu verwenden, wenn Sie die Identität steuern möchten, die eine Rolle übernimmt. Die Quellenidentität ist auch nützlich für das CloudTrail Miningprotokoll, um festzustellen, wer die Rolle zur Ausführung von Aktionen verwendet hat.

Einrichten für die Verwendung der Quellidentität

Die Art und Weise, wie Sie die Quellidentität verwenden, hängt von der Methode ab, die verwendet wird, wenn Ihre Rollen angenommen werden. Beispielsweise können Ihre IAM-Benutzer Rollen direkt übernehmen, indem sie die AssumeRole verwenden. Wenn Sie über Unternehmensidentitäten, auch Personalidentitäten genannt, verfügen, greifen diese möglicherweise mithilfe von auf Ihre AWS Ressourcen zu. AssumeRoleWithSAML Wenn Endbenutzer auf Ihre mobilen oder Webanwendungen zugreifen, tun sie dies möglicherweise über AssumeRoleWithWebIdentity. Im Folgenden finden Sie einen Überblick über den Workflow auf hoher Ebene, mit dem Sie verstehen, wie Sie die Verwendung von Quellidentitätsinformationen in Ihrer vorhandenen Umgebung einrichten können.

1. Konfigurieren von Testbenutzern und -rollen – Konfigurieren Sie mithilfe einer Vorproduktionsumgebung Testbenutzer und -rollen und konfigurieren Sie ihre Richtlinien so, dass eine Quellidentität festgelegt werden kann.

   Wenn Sie einen Identitätsanbieter (IdP) für Ihre Verbundidentitäten verwenden, konfigurieren Sie Ihren IdP so, dass ein Benutzerattribut Ihrer Wahl für die Quellidentität in der Assertion oder Token übergeben wird.

2. Nehmen Sie die Rolle an. – Testen Sie das Annehmen von Rollen und Übergeben einer Quellidentität mit den Benutzern und Rollen, die Sie zum Testen eingerichtet haben.

3. Überprüfung CloudTrail — Überprüfen Sie die Quellidentitätsinformationen für Ihre Testrollen in Ihren CloudTrail Protokollen.

4. Trainieren von Benutzern – Stellen Sie nach dem Test in Ihrer Vorproduktionsumgebung sicher, dass Ihre Benutzer wissen, wie sie die Quellidentitätsinformationen eingeben, falls erforderlich. Legen Sie einen Stichtag fest, an dem Ihre Benutzer eine Quellidentität in Ihrer Produktionsumgebung angeben müssen.

5. Konfigurieren von Produktionsrichtlinien – Konfigurieren Sie Ihre Richtlinien für Ihre Produktionsumgebung und fügen Sie sie dann Ihren Produktionsbenutzern und -rollen hinzu.

6. Aktivität überwachen — Überwachen Sie die Aktivitäten Ihrer Produktionsrollen mithilfe von CloudTrail Protokollen.

Wissenswertes über die Quellidentität

Beachten Sie bei der Arbeit mit der Quellenidentität folgende Punkte.

• Bei der Verwendung von Sitzungs-Tags müssen die Rollenvertrauensrichtlinien für alle Rollen, die mit einem Identitätsanbieter (IdP) verbunden sind, über die sts:SetSourceIdentity-Berechtigung verfügen. Bei Rollen, die diese Berechtigung in der Vertrauensrichtlinie nicht haben, schlägt der AssumeRole*-Vorgang fehl. Wenn Sie die Vertrauensrichtlinie für Rollen nicht für jede Rolle aktualisieren möchten, können Sie eine separate IdP-Instance zum Übergeben von Sitzungs-Tags verwenden. Fügen Sie dann die sts:SetSourceIdentity-Berechtigung nur den Rollen hinzu, die mit dem separaten IdP verbunden sind.

• Wenn eine Identität eine Quellidentität festlegt, wird die sts:SourceIdentity-Schlüssel in der Anforderung. Für nachfolgende Aktionen, die während der Rollensitzung ausgeführt werden, ist der Schlüssel aws:SourceIdentity in der Anfrage vorhanden. AWS kontrolliert den Wert der Quellidentität weder in den Schlüsseln sts:SourceIdentity noch aws:SourceIdentity. Wenn Sie eine Quellidentität benötigen, müssen Sie ein Attribut auswählen, das Ihre Benutzer oder IdP bereitstellen sollen. Aus Sicherheitsgründen müssen Sie sicherstellen, dass Sie steuern können, wie diese Werte bereitgestellt werden.

• Der Wert der Quell-Identität muss zwischen 2 und 64 Zeichen lang sein und darf nur alphanumerische Zeichen, Unterstriche und die folgenden Zeichen enthalten:., + = @ -(Bindestrich). Sie können keinen Tag-Schlüssel oder -Wert erstellen, der mit dem Text aws: beginnt. Dieses Präfix ist für den AWS internen Gebrauch reserviert.

• Die Quellidentitätsinformationen werden nicht erfasst, CloudTrail wenn ein AWS Dienst oder eine dienstbezogene Rolle eine Aktion im Namen einer föderierten Identität oder einer Belegschaftsidentität ausführt.

Wichtig

Sie können nicht zu einer Rolle in der wechseln, für AWS Management Console die eine Quellidentität festgelegt werden muss, wenn die Rolle übernommen wird. Um eine solche Rolle anzunehmen, können Sie die AWS CLI AWS OR-API verwenden, um den AssumeRole Vorgang aufzurufen und den Quellidentitätsparameter anzugeben.

Zum Festlegen der Quellidentität erforderliche Berechtigungen

Zusätzlich zu der Aktion, die der API-Operation entspricht, muss in Ihrer Richtlinie die folgende reine Berechtigungsaktion enthalten sein:

sts:SetSourceIdentity

• Um eine Quellidentität anzugeben, müssen Auftraggeber (IAM-Benutzer und IAM-Rollen) über Berechtigungen für sts:SetSourceIdentity haben. Als Administrator können Sie dies in der Rollenvertrauensrichtlinie und in der Berechtigungsrichtlinie des Auftraggebers konfigurieren.

• Wenn Sie eine Rolle mit einer anderen Rolle übernehmen, was als Rollenverkettung bezeichnet wird, sind Berechtigungen für sts:SetSourceIdentity sowohl in der Berechtigungsrichtlinie des Auftraggebers, der die Rolle übernimmt, als auch in der Rollenvertrauensrichtlinie der Zielrolle erforderlich. Andernfalls schlägt die Operation fehl.

• Bei der Verwendung von Sitzungs-Tags müssen die Rollenvertrauensrichtlinien für alle Rollen, die mit einem Identitätsanbieter (IdP) verbunden sind, über die sts:SetSourceIdentity-Berechtigung verfügen. Der AssumeRole*-Vorgang schlägt für jede Rolle fehl, die mit einem IdP verbunden ist, der Sitzungs-Tags ohne diese Berechtigung übergibt. Wenn Sie die Vertrauensrichtlinie für Rollen nicht für jede Rolle aktualisieren möchten, können Sie eine separate IdP Instance zum Übergeben der Quell-Identität verwenden und die sts:SetSourceIdentity-Berechtigung nur die Rollen, die mit dem separaten IdP verbunden sind.

• Um eine Quellidentität über Kontogrenzen hinweg festzulegen, müssen Sie die Berechtigung sts:SetSourceIdentity an zwei Stellen einfügen. Sie muss sich in der Berechtigungsrichtlinie des Auftraggebers im Ursprungskonto und in der Rollenvertrauensrichtlinie der Rolle im Zielkonto befinden. Dies kann z. B. erforderlich sein, wenn eine Rolle verwendet wird, um eine Rolle in einem anderen Konto mit Rollenverkettung zu übernehmen.

Stellen Sie sich als Kontoadministrator vor, Sie möchten den IAM-Benutzer DevUser in Ihrem Konto, um die Developer_Role auf demselben Konto zu übernehmen. Sie möchten diese Aktion jedoch nur zulassen, wenn der Benutzer die Quellidentität auf seinen IAM-Benutzernamen festgelegt hat. Sie können dazu diesem Benutzer die folgende IAM-Richtlinie zuweisen.

Beispiel für eine identitätsbasierte Richtlinie, die angehängt ist DevUser

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AssumeRole",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/Developer_Role"
    },
    {
      "Sid": "SetAwsUserNameAsSourceIdentity",
      "Effect": "Allow",
      "Action": "sts:SetSourceIdentity",
      "Resource": "arn:aws:iam::123456789012:role/Developer_Role",
      "Condition": {
        "StringLike": {
          "sts:SourceIdentity": "${aws:username}"
        }
      }
    }
  ]
}

Um die zulässigen Werte für die Quellidentität zu erzwingen, können Sie die folgende Rollenvertrauensrichtlinie konfigurieren. Die Richtlinie gibt dem IAM-Benutzer DevUser die Berechtigung, die Rolle zu übernehmen und eine Quellidentität festzulegen. Der sts:SourceIdentity-Bedingungsschlüssel definiert den zulässigen Wert der Quellenidentität.

Beispiel einer Rollenvertrauensrichtlinie für Quellidentität

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowDevUserAssumeRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/DevUser"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "sts:SourceIdentity": "DevUser"
        }
      }
    }
  ]
}

Unter Verwendung der Anmeldeinformationen für den IAM-Benutzer versucht der Benutzer anzunehmenDevUser, dass er die folgende Anfrage DeveloperRole verwendet. AWS CLI

Beispiel für eine AssumeRole CLI-Anfrage

aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Developer_Role \
--role-session-name Dev-project \ 
--source-identity DevUser \

Bei der AWS Auswertung der Anfrage enthält der Anforderungskontext das sts:SourceIdentity ofDevUser.

Angeben einer Quellidentität bei der Übernahme einer Rolle

Sie können eine Quellidentität angeben, wenn Sie eine der AWS STS AssumeRole* API-Operationen verwenden, um temporäre Sicherheitsanmeldeinformationen für eine Rolle abzurufen. Die API-Operation, die Sie verwenden, unterscheidet sich je nach Anwendungsfall. Wenn Sie beispielsweise IAM-Rollen verwenden, um IAM-Benutzern Zugriff auf AWS Ressourcen zu gewähren, auf die sie normalerweise keinen Zugriff haben, können Sie den AssumeRole Vorgang verwenden. Wenn Sie zur Verwaltung Ihrer Mitarbeiter den Identitätsverbund verwenden, können Sie den Vorgang AssumeRoleWithSAML verwenden. Wenn Sie den OIDC-Verbund verwenden, um Endbenutzern den Zugriff auf Ihre Mobil- oder Webanwendungen zu ermöglichen, können Sie den Vorgang verwenden. AssumeRoleWithWebIdentity In den folgenden Abschnitten wird die Verwendung von Quellidentitäten bei jedem Vorgang erläutert. Weitere Informationen über häufige Szenarien für temporäre Berechtigungsnachweise finden Sie unter Gängige Szenarien für temporäre Anmeldeinformationen.

Verwenden Sie die Quellidentität mit AssumeRole

Der AssumeRole Vorgang gibt einen Satz temporärer Anmeldeinformationen zurück, mit denen Sie auf AWS Ressourcen zugreifen können. Sie können IAM-Benutzer- oder Rollenanmeldeinformationen verwenden, um AssumeRole aufzurufen. Verwenden Sie die -–source-identity AWS CLI Option oder den SourceIdentity AWS API-Parameter, um bei der Übernahme einer Rolle die Quellenidentität zu übergeben. Das folgende Beispiel zeigt, wie die Quellidentität mit der AWS CLI angegeben werden kann.

Beispiel für eine AssumeRole CLI-Anfrage

aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/developer \
--role-session-name Audit \ 
--source-identity Admin \
            

Verwendung der Quellidentität mit AssumeRoleWith SAML

Die AssumeRoleWithSAML-Operation wird mit dem SAML-basierten Verbund authentifiziert. Dieser Vorgang gibt einen Satz temporärer Anmeldeinformationen zurück, mit denen Sie auf AWS Ressourcen zugreifen können. Weitere Informationen zur Verwendung eines SAML-basierten Verbunds für den AWS Management Console Zugriff finden Sie unter. Aktivieren des Zugriffs von SAML 2.0-Verbundbenutzern auf AWS Management Console Einzelheiten zum AWS CLI AWS API-Zugriff finden Sie unter. SAML 2.0-Verbund Eine Anleitung zur Einrichtung eines SAML-Verbunds für Ihre Active Directory-Benutzer finden Sie unter AWS Verbundauthentifizierung mit Active Directory Federation Services (ADFS) im AWS Sicherheitsblog.

Als Administrator können Sie es Mitgliedern Ihres Unternehmensverzeichnisses ermöglichen, den Vorgang gemeinsam zu AWS nutzen. AWS STS AssumeRoleWithSAML Hierfür müssen Sie die folgenden Aufgaben ausführen:

1. Konfigurieren Sie einen SAML-Anbieter in Ihrer Organisation.

2. Erstellen eines SAML-Anbieters in IAM.

3. Konfigurieren Sie eine Rolle und ihre Berechtigungen AWS für Ihre Verbundbenutzer.

4. Abschließen der Konfiguration des SAML-Identitätsanbieters und Erstellen von Zusicherungen für die SAML-Authentifizierungsantwort.

Um ein SAML-Attribut für die Quellidentität festzulegen, schließen Sie das Attribute-Element mit dem Name-Attribut gesetzt auf https://aws.amazon.com/SAML/Attributes/SourceIdentity. Verwenden Sie das AttributeValue-Element, um den Wert der Quellidentität anzugeben. Angenommen, Sie möchten die folgenden Identitätsattribute als Sitzungs-Tags übergeben.

SourceIdentity:DiegoRamirez

Um diese Attribute zu übergeben, schließen Sie die folgenden Elemente in Ihre SAML-Zusicherung ein.

Beispielausschnitt einer SAML-Zusicherung

<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity">
<AttributeValue>DiegoRamirez</AttributeValue>
</Attribute>

Verwenden Sie die Quellidentität mit AssumeRoleWithWebIdentity

Der Principal, der den AssumeRoleWithWebIdentity Vorgang aufruft, wird mithilfe eines OpenID Connect (OIDC) -kompatiblen Verbunds authentifiziert. Diese Operation gibt einen Satz temporärer Anmeldeinformationen zurück, die Sie für den Zugriff auf AWS -Ressourcen verwenden können. Weitere Hinweise zur Verwendung des OIDC-Verbunds für den Zugriff finden Sie unter. AWS Management Console OIDC-Föderation

Um die Quellidentität von OpenID Connect (OIDC) zu übergeben, müssen Sie die Quellidentität in das JSON Web Token (JWT) einbeziehen. Fügen Sie Sitzungs-Tags in den https://aws.amazon.com/source_identity-Namespace in dem Token ein, wenn Sie die AssumeRoleWithWebIdentity-Anforderung senden. Weitere Informationen zu OIDC-Token und Ansprüchen finden Sie unter Verwenden von Token mit Benutzerpools im Amazon Cognito Developer Guide.

Der folgende entschlüsselte JWT ist beispielsweise ein Token, das zum Aufrufen von AssumeRoleWithWebIdentity mit der Quellidentität Admin verwendet wird.

Beispiel für ein dekodiertes JSON-Web-Token

{
    "sub": "johndoe",
    "aud": "ac_oic_client",
    "jti": "ZYUCeRMQVtqHypVPWAN3VB",
    "iss": "https://xyz.com",
    "iat": 1566583294,
    "exp": 1566583354,
    "auth_time": 1566583292,
    "https://aws.amazon.com/source_identity":"Admin"
}

Steuern des Zugriffs mithilfe von Informationen zur Quell

Wenn eine Quellidentität anfänglich festgelegt wird, ist der SourceIdentity Schlüssel sts: in der Anforderung vorhanden. Nachdem eine Quellidentität festgelegt wurde, ist der SourceIdentity Schlüssel aws: in allen nachfolgenden Anfragen vorhanden, die während der Rollensitzung gestellt wurden. Als Administrator können Sie Richtlinien schreiben, die eine bedingte Autorisierung zur Ausführung von AWS Aktionen gewähren, die auf der Existenz oder dem Wert des Quellidentitätsattributs basieren.

Stellen Sie sich vor, Sie möchten von Ihren Entwicklern verlangen, dass sie eine Quellidentität festlegen, damit sie eine wichtige Rolle übernehmen können, die über Schreibberechtigungen für eine produktionskritische AWS Ressource verfügt. Stellen Sie sich außerdem vor, Sie gewähren AWS Zugriff auf die Identitäten Ihrer Belegschaft mithilfe vonAssumeRoleWithSAML. Sie möchten nur, dass ältere Entwickler Saanvi und Diego Zugriff auf die Rolle haben. Daher erstellen Sie die folgende Vertrauensrichtlinie für die Rolle.

Beispiel einer Rollenvetrauensichtlinie für Quellidentität (SAML)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SAMLProviderAssumeRoleWithSAML",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
      },
      "Action": [
        "sts:AssumeRoleWithSAML"
      ],
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    },
    {
      "Sid": "SetSourceIdentitySrEngs",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
      },
      "Action": [
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringLike": {
          "sts:SourceIdentity": [
            "Saanvi",
            "Diego"
          ]
        }
      }
    }
  ]
}

Die Vertrauensrichtlinie enthält eine Bedingung für sts:SourceIdentity, die eine Quellidentität erfordert, die auf Saanvi oder Diego eingestellt ist, um die kritische Rolle anzunehmen.

Wenn Sie einen OIDC-Anbieter für den Verbund verwenden und Benutzer mit diesem authentifiziert sindAssumeRoleWithWebIdentity, könnte Ihre Rollenvertrauensrichtlinie alternativ wie folgt aussehen.

Beispiel einer Rollenvetrauensichtlinie für Quellidentität (OIDC-Anbieter)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com"
      },
      "Action": [
        "sts:AssumeRoleWithWebIdentity",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "server.example.com:aud": "oidc-audience-id"
        },
        "StringLike": {
          "sts:SourceIdentity": [
            "Saanvi",
            "Diego"
          ]
        }
      }
    }
  ]
}

Rollenverkettung und kontenübergreifende Anforderungen

Stellen Sie sich vor, Sie möchten Benutzern, die CriticalRole angenommen haben, erlauben, ein CriticalRole_2 in einem anderen Konto anzunehmen. Die Anmeldeinformationen für die Rollensitzung, die für die Annahme von CriticalRole erlangt wurden, werden für die Rollenkette einer zweiten Rolle, CriticalRole_2, in einem anderen Konto verwendet. Die Rolle wird über eine Kontengrenze hinweg übernommen. Daher muss die Berechtigung sts:SetSourceIdentity sowohl in der Berechtigungsrichtlinie für CriticalRole als auch in der Rollenvertrauensrichtlinie für CriticalRole_2 erteilt werden.

Beispiel für eine Berechtigungsrichtlinie für CriticalRole

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AssumeRoleAndSetSourceIdentity",
      "Effect": "Allow",
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Resource": "arn:aws:iam::222222222222:role/CriticalRole_2"
    }
  ]
}

Um das Festlegen der Quellidentität über die Kontengrenze hinweg zu sichern, vertraut die folgende Rollenvertrauensrichtlinie nur dem Rollenauftraggeber fürCriticalRole, um die Quellidentität festzulegen.

Beispiel für eine Vertrauensrichtlinie für eine Rolle auf CriticalRole _2

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/CriticalRole"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringLike": {
          "aws:SourceIdentity": ["Saanvi","Diego"]
        }
      }
    }
  ]
}

Der Benutzer führt den folgenden Aufruf mit den Anmeldeinformationen für die Rollensitzung durch, die er bei der Annahme abgerufen hat CriticalRole. Die Quellidentität wurde während der Annahme von festgelegt CriticalRole, sodass sie nicht erneut explizit festgelegt werden muss. Wenn der Benutzer versucht, eine Quellidentität festzulegen, die sich von dem Wert unterscheidet, der bei der Übernahme von CriticalRole festgelegt wurde, wird die Anforderung der Rollenübernahme abgelehnt.

Beispiel für eine AssumeRole CLI-Anfrage

aws sts assume-role \ 
--role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \
--role-session-name Audit \

Wenn der aufrufende Auftraggeber die Rolle übernimmt, bleibt die Quellidentität in der Anforderung ab der ersten angenommenen Rollensitzung bestehen. Daher sind sowohl der aws:SourceIdentity- als auch der sts:SourceIdentity-Schlüssel im Anfragekontext vorhanden.

Quellenidentität anzeigen in CloudTrail

Hier können Sie die Anfragen CloudTrail zur Übernahme von Rollen oder zur Zusammenführung von Benutzern anzeigen. Sie können auch die Rolle oder die Benutzeranfragen zur Durchführung von Aktionen in AWS einsehen. Die CloudTrail Protokolldatei enthält Informationen über die Quellidentität, die für die Sitzung mit übernommener Rolle oder Verbundbenutzer festgelegt wurde. Weitere Informationen finden Sie unter Protokollierung von IAM- und AWS STS API-Aufrufen mit AWS CloudTrail.

Gehen Sie beispielsweise davon aus, dass ein Benutzer eine AWS STS AssumeRole Anfrage stellt und eine Quellidentität festlegt. Sie finden die sourceIdentity Informationen im requestParameters Schlüssel in Ihrem CloudTrail Protokoll.

Beispiel für einen RequestParameter-Abschnitt in einem Protokoll AWS CloudTrail

"eventVersion": "1.05",
    "userIdentity": {
        "type": "AWSAccount",
        "principalId": "AIDAJ45Q7YFFAREXAMPLE",
        "accountId": "111122223333"
    },
    "eventTime": "2020-04-02T18:20:53Z",
    "eventSource": "sts.amazonaws.com",
    "eventName": "AssumeRole",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "203.0.113.64",
    "userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86",
    "requestParameters": {
        "roleArn": "arn:aws:iam::123456789012:role/DevRole",
        "roleSessionName": "Dev1",
        "sourceIdentity": "source-identity-value-set"
    }

Wenn der Benutzer die angenommene Rollensitzung verwendet, um eine Aktion auszuführen, sind die Informationen zur Quellidentität im userIdentity Schlüssel im CloudTrail Protokoll enthalten.

Beispiel für einen UserIdentity-Schlüssel in einem Protokoll AWS CloudTrail

{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1",
    "arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1",
    "accountId": "123456789012",
    "accessKeyId": "ASIAIOSFODNN7EXAMPLE",
    "sessionContext": {
      "sessionIssuer": {
        "type": "Role",
        "principalId": "AROAJ45Q7YFFAREXAMPLE",
        "arn": "arn:aws:iam::123456789012:role/DevRole",
        "accountId": "123456789012",
        "userName": "DevRole"
      },
      "webIdFederationData": {},
      "attributes": {
        "mfaAuthenticated": "false",
        "creationDate": "2021-02-21T23:46:28Z"
      },
      "sourceIdentity": "source-identity-value-present"
    }
  }
}

Beispiele für AWS STS API-Ereignisse in CloudTrail Protokollen finden Sie unter. Beispiel für IAM-API-Ereignisse im Protokoll CloudTrail Weitere Informationen zu den in CloudTrail Protokolldateien enthaltenen Informationen finden Sie unter CloudTrail Event Reference im AWS CloudTrail Benutzerhandbuch.