Ü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 AWS übernehmen, erhalten Sie eine Sitzung mit den Berechtigungen, die der Rolle zugewiesen sind.

Wenn Sie Aktionen in AWS durchführen, können die Informationen über Ihre Sitzung in AWS CloudTrail protokolliert werden, damit 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ät in CloudTrail überprüft, kann er die Quellidentitätsinformationen anzeigen, um zu bestimmen, wer oder was Aktionen mit angenommenen Rollensitzungen ausgeführt hat.

Nachdem eine Quellidentität festgelegt wurde, ist sie in Anfragen für jede AWS-Aktion während der Rollensitzung vorhanden. Der eingestellte Wert bleibt bestehen, wenn eine Rolle verwendet wird, um eine andere Rolle über die AWS CLI- oder AWS-API anzunehmen, was als Rollenverkettung bekannt ist. Der festgelegte Wert kann während der Rollensitzung nicht geändert werden. Administratoren können granulare Berechtigungen basierend auf der Anwesenheit oder dem Wert der Quellidentität konfigurieren, um weitere Kontrolle zu erhalten. AWS-Aktionen, die mit gemeinsam genutzten Rollen ausgeführt werden. 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:

Es wird empfohlen, die Quellidentität zu verwenden, wenn Sie die Identität steuern möchten, die eine Rolle übernimmt. Die Quellidentität ist auch nützlich für das Mining von CloudTrail -Protokollen, um festzustellen, wer die Rolle zum Ausführen 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 bekannt als Mitarbeiteridentitäten, verfügen, können diese auf Ihre AWS-Ressourcen über AssumeRoleWithSAML zugreifen. 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.

Wissenswertes über die Quellidentität

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

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

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.

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

{
  "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 DevUser versucht der Benutzer DeveloperRole mit der folgenden AWS CLI-Anfrage, den Zugang zu übernehmen.

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

Wenn AWS die Anfrage auswertet, enthält der Anfragekontext die sts:SourceIdentity von DevUser.

Angeben einer Quellidentität bei der Übernahme einer Rolle

Sie können eine Quellidentität angeben, wenn Sie einen der AWS STS AssumeRole*-API-Vorgänge verwenden, um temporäre Sicherheitsanmeldeinformationen für eine Rolle zu erhalten. 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 die AssumeRole-Operation 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 diese AssumeRoleWithWebIdentity-Operation verwenden. 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 der Quellidentität mit AssumeRole

Die AssumeRole-Operation 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. Wenn Sie während der Übernahme einer Rolle Sitzungs-Tags übergeben möchten, verwenden Sie die -–source-identity AWS CLI-Option oder den SourceIdentity-AWS-API-Parameter. Das folgende Beispiel zeigt, wie die Quellidentität mit der AWS CLI angegeben werden kann.

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

Verwenden der Quellidentität mit AssumeRoleWithSAML

Die AssumeRoleWithSAML-Operation wird mit dem SAML-basierten Verbund 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 SAML-basierten Verbunds für den AWS Management Console-Zugriff finden Sie unter Aktivieren von Zugriff auf die für SAML-2.0-Verbundbenutzer AWS Management Console. Weitere Informationen zum AWS CLI- oder AWS-API-Zugriff finden Sie unter SAML2.0 Verband. Ein Tutorial zum Einrichten eines SAML-Verbunds für Ihre Active Directory-Benutzer finden Sie unter AWS Federated Authentication with Active Directory Federation Services (ADFS) im AWS Sicherheitsblog.

Als Administrator können Sie Mitgliedern Ihres Unternehmensverzeichnisses erlauben, mit der AWS STS-Operation AssumeRoleWithSAML einen Verbund in AWS herzustellen. Hierfür müssen Sie die folgenden Aufgaben ausführen:

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.

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

Verwenden der Quellidentität mit AssumeRoleWithWebIdentity

Der Aufruf der AssumeRoleWithWebIdentity-Operation durch den Prinzipal wird mithilfe eines OpenID Connect (OIDC)-konformen 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 Informationen zur Verwendung des OIDC-Verbundes für den AWS Management Console-Zugriff finden Sie unter OIDC-Verbund.

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.

{
    "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, wird die STS:SourceIdentity-Schlüssel in der Anforderung. Nachdem eine Quellidentität festgelegt wurde, wird die AWS:QuellenIdentity-Schlüssel ist in allen nachfolgenden Anforderungen während der Rollensitzung vorhanden. Als Administrator können Sie Richtlinien schreiben, die eine bedingte Berechtigung zum Ausführen von AWS-Aktionen basierend auf der Existenz oder dem Wert des Quellidentitätsattributs.

Stellen Sie sich vor, Sie möchten von Ihren Entwicklern verlangen, dass sie eine Quellidentität so einstellen, dass sie eine kritische Rolle annimmt, die das Recht hat, auf eine produktionskritische AWS-Ressource zu schreiben. Stellen Sie sich auch vor, Sie gewähren AWS Zugang zu den Identitäten Ihrer Belegschaft mit AssumeRoleWithSAML. 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.

{
  "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 jedoch einen OIDC-Anbieter für den Verbund verwenden und Benutzer mit AssumeRoleWithWebIdentity authentifiziert werden, könnte Ihre Rollenvertrauensrichtlinie wie folgt aussehen.

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

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

{
  "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 der Rollensitzung aus, die von der Annahme von CriticalRole erhalten wurden Die Queltidentität wurde während der Annahme von CriticalRole festgelegt, sodass sie nicht explizit gesetzt 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.

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.

Anzeigen der Quellidentität in CloudTrail

Mithilfe von CloudTrail können Sie die Anforderungen anzeigen, die zur Übernahme von Rollen oder zum Verbinden von Benutzern gestellt werden. Sie können auch die Rolle oder die Benutzeranfragen zur Durchführung von Aktionen in AWS einsehen. Die CloudTrail-Protokolldatei enthält Informationen zu den Auftraggeber-Tags für die angenommene Rolle oder Sitzung des Verbundbenutzers. Weitere Informationen finden Sie unter Protokollierung IAM und AWS STS API Anrufe mit AWS CloudTrail

Nehmen wir zum Beispiel an, 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.

"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 Sitzung mit der angenommenen Rolle verwendet, um eine Aktion auszuführen, ist die Quellidentitätsinformation im Schlüssel userIdentity im CloudTrail-Protokoll enthalten.

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

Ein Beispiel für AWS STS-API-Ereignisse in CloudTrail-Protokollen finden Sie unter IAMAPIBeispielereignisse im CloudTrail Protokoll. Weitere Informationen zu den Informationen in CloudTrail-Protokolldateien finden Sie in der CloudTrail-Ereignisreferenz im AWS CloudTrailLeitfaden.