Sicherer API-Zugriff mit MFA - AWS Identity and Access Management
ÜbersichtSzenario: MFA-Schutz für kontoübergreifende DelegierungSzenario: MFA-Schutz für Zugriff auf API-Operationen im aktuellen KontoSzenario: MFA-Schutz für Ressourcen mit ressourcenbasierten Richtlinien

Sicherer API-Zugriff mit MFA

Mit IAM-Richtlinien können Sie angeben, welche API-Operationen ein Benutzer aufrufen darf. Sie können für zusätzliche Sicherheit sorgen, indem Sie von Benutzern eine Authentifizierung mit Multi-Faktor-Authentifizierung (MFA) verlangen, bevor Sie ihnen erlauben, besonders vertrauliche Aktionen auszuführen.

Sie verfügen beispielsweise über eine Richtlinie, die dem Benutzer gestattet, die Amazon EC2 Aktionen RunInstances, DescribeInstances und StopInstances auszuführen. Aber Sie möchten endgültige, nicht rückgängig machbare Aktionen einschränken, wie z. B. TerminateInstances, und sicherstellen, dass der Benutzer diese Aktionen nur ausführen kann, wenn er sich mit einem AWS-MFA-Gerät authentifiziert.

Übersicht

Um den MFA-Schutz zu API-Operationen hinzuzufügen, sind folgende Schritte auszuführen:

  1. Der Administrator konfiguriert ein AWS-MFA-Gerät für jeden Benutzer, der API-Anfragen stellen muss, die eine MFA-Authentifizierung erfordern. Weitere Informationen finden Sie unter AWS-Multi-Faktor-Authentifizierung in IAM.

  2. Der Administrator erstellt Richtlinien für die Benutzer mit einem Condition-Element, das prüft, ob der Benutzer sich mit einem AWS-MFA-Gerät authentifiziert hat.

  3. Der Benutzer ruft eine der AWS STS-API-Operationen auf, die die MFA-Parameter unterstützen: AssumeRole oder GetSessionToken. Als Teil des Aufrufs schließt der Benutzer die mit dem Benutzer verknüpfte Gerät-ID für das Gerät ein. Der Benutzer schließt außerdem das zeitbasierte Einmalpasswort (Time-based One-Time Password, TOTP) ein. In beiden Fällen erhält der Benutzer temporäre Sicherheitsanmeldeinformationen zurück, die der Benutzer für zusätzliche Anfragen an benutzen kann AWS.

    Anmerkung

    MFA-Schutz für die API-Operationen eines Service ist nur dann verfügbar, wenn der Service temporäre Sicherheitsanmeldeinformationen unterstützt. Eine Liste dieser Services finden Sie unter Verwendung temporärer Sicherheitscodes für den Zugriff aufAWS.

Wenn die Autorisierung fehlschlägt, gibt AWS die Fehlermeldung "Zugriff verweigert" (wie bei jedem unbefugten Zugriff) zurück. Wenn MFA-geschützte API-Richtlinien vorhanden sind, verweigert AWS den Zugriff auf die in den Richtlinien angegebenen API-Operationen, wenn der Benutzer versucht, eine API-Operation ohne gültige MFA-Authentifizierung aufzurufen. Die Operation wird auch verweigert, wenn der Zeitstempel der Anforderung für die API-Operation sich außerhalb des in der Richtlinie festgelegten zulässigen Bereichs befindet. Der Benutzer muss sich erneut mit MFA authentifizieren, indem neue temporäre Sicherheitsanmeldeinformationen mit einem MFA-Code und einer Geräte-Seriennummer angefordert werden.

IAM-Richtlinien mit MFA-Bedingungen

Richtlinien mit MFA-Bedingungen können folgenden Elementen angefügt werden:

  • Einem IAM-Benutzer oder einer IAM-Gruppe

  • Einer Ressource, wie zum Beispiel ein Amazon S3-Bucket, eine Amazon SQS-Warteschlange oder ein Amazon SNS-Thema

  • Die Vertrauensrichtlinie einer IAM-Rolle, die von einem Benutzer übernommen werden kann

Sie können eine MFA-Bedingung in einer Richtlinie zum Überprüfen der folgenden Eigenschaften verwenden:

  • Vorhanden – Um mit MFA lediglich zu überprüfen, ob sich der Benutzer mit MFA authentifiziert hat, prüfen Sie, dass der aws:MultiFactorAuthPresent-Schlüssel auf True gesetzt ist, und zwar einer Bool-Bedingung. Der Schlüssel ist nur vorhanden, wenn sich der Benutzer mit kurzfristigen Anmeldeinformationen authentifiziert. Langfristige Anmeldeinformationen wie Zugriffsschlüssel enthalten diesen Schlüssel nicht.

  • Dauer – Wenn Sie den Zugriff nur innerhalb einer bestimmten Zeit nach der MFA-Authentifizierung gewähren möchten, verwenden Sie einen numerischen Bedingungstyp, um das Alter des aws:MultiFactorAuthAge-Schlüssels mit einem Wert (wie 3.600 Sekunden) zu vergleichen. Beachten Sie, dass der aws:MultiFactorAuthAge-Schlüssel nicht vorhanden ist, wenn keine MFA verwendet wurde.

Das folgende Beispiel zeigt die Vertrauensrichtlinie einer IAM-Rolle, die eine MFA-Bedingung enthält, um die Existenz der MFA-Authentifizierung festzustellen. Mit dieser Richtlinie können die im Principal-Element angegebenen Benutzer des AWS-Konto (ersetzen Sie ACCOUNT-B-ID durch eine gültige AWS-Konto-ID) die Rolle, der diese Richtlinie angefügt worden ist, übernehmen. Solche Benutzer können die Rolle jedoch nur annehmen, wenn sie sich mit MFA authentifizieren.

JSON
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "ACCOUNT-B-ID"},
    "Action": "sts:AssumeRole",
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }
}

Weitere Informationen über die Bedingungstypen für MFA finden Sie unter AWS Globale Bedingungskontextschlüssel, Numerische Bedingungsoperatoren und Bedingungsoperator zur Prüfung der Existenz von Bedingungsoperatoren .

Auswählen zwischen GetSessionToken und AssumeRole

AWS STS stellt zwei API-Operationen zur Verfügung, mit denen Benutzer MFA-Informationen übergeben können: GetSessionToken und AssumeRole. Die vom Benutzer zur Erlangung temporärer Sicherheitsanmeldeinformationen aufgerufene API-Operation wird durch eines der folgenden Szenarien bestimmt.

Verwenden Sie GetSessionToken für die folgenden Szenarien:

  • Aufrufen von API-Operationen, die auf Ressourcen in demselben AWS-Konto zugreifen, wie der IAM-Benutzer, der die Anforderung gestellt hat. Beachten Sie, dass temporäre Berechtigungsnachweise aus einer GetSessionToken-Anforderung nur dann auf IAM- und AWS STS-API-Vorgänge zugreifen können, wenn Sie MFA-Informationen in die Anforderung von Berechtigungsnachweisen aufnehmen. Da von GetSessionToken zurückgegebene temporäre Anmeldeinformationen MFA-Informationen enthalten, können Sie mit den Anmeldeinformationen ausgeführte einzelne API-Operationen auf MFA prüfen.

  • Zugriff auf Ressourcen, die über ressourcenbasierte Richtlinien geschützt sind, die eine MFA-Bedingung enthalten.

Der Zweck der Operation GetSessionToken besteht darin, den Benutzer mithilfe von MFA zu authentifizieren. Richtlinien können nicht dazu verwendet werden, Authentifizierungsoperationen zu steuern.

Verwenden Sie AssumeRole für die folgenden Szenarien:

  • Aufrufe von API-Operationen, die auf die Ressourcen in demselben oder einem anderen AWS-Konto zugreifen. Die API-Aufrufe können beliebige IAM- oder AWS STS-API-Operationen enthalten. Beachten Sie, dass MFA zu dem Zeitpunkt, zu dem der Benutzer die Rolle übernimmt, aktiviert ist. Die von AssumeRole zurückgegebenen temporären Anmeldeinformationen enthalten keine MFA-Informationen im Kontext, sodass einzelne API-Operationen nicht auf MFA geprüft werden können. Daher müssen Sie GetSessionToken verwenden, um den Zugriff auf die von ressourcenbasierten Richtlinien geschützten Ressourcen einzuschränken.

Anmerkung

AWS CloudTrail-Protokolle enthalten MFA-Informationen, wenn sich der IAM-Benutzer mit MFA anmeldet. Wenn der IAM-Benutzer eine IAM-Rolle annimmt, protokolliert CloudTrail auch mfaAuthenticated: true in den sessionContext-Attributen für Aktionen, die mit der angenommenen Rolle ausgeführt wurden. Die CloudTrail-Protokollierung unterscheidet sich jedoch von den Anforderungen von IAM, wenn API-Aufrufe mit den Anmeldeinformationen der angenommenen Rolle getätigt werden. Weitere Informationen finden Sie unter CloudTrail „userIdentity”-Element.

Weitere Informationen zur Implementierung dieser Szenarien finden Sie weiter unten in diesem Dokument.

Wichtige Punkte für den MFA-geschützten API-Zugriff

Beachten Sie die folgenden Aspekte in Bezug auf den MFA-Schutz für API-Operationen:

  • MFA-Schutz steht nur mit temporären Sicherheitsanmeldeinformationen zur Verfügung, die mit AssumeRole oder GetSessionToken eingeholt werden müssen.

  • Sie können den MFA-geschützten API-Zugriff nicht mit Root-Benutzer des AWS-Kontos-Anmeldeinformationen verwenden.

  • Sie können den MFA-geschützten API-Zugriff nicht mit U2F-Sicherheitsschlüsseln verwenden.

  • Verbundbenutzern kann kein MFA-Gerät zur Verwendung mit AWS-Services zugewiesen werden, sodass sie nicht auf mithilfe von MFA kontrollierte AWS-Ressourcen zugreifen können. (Siehe nächster Punkt.)

  • Andere AWS STS-API-Operationen, die temporäre Anmeldeinformationen zurückgeben, unterstützen nicht MFA. Für AssumeRoleWithWebIdentity und AssumeRoleWithSAML wird der Benutzer durch externe Anbieter authentifiziert und AWS kann nicht feststellen, ob von diesem Anbieter MFA gefordert wurde. Für GetFederationToken wird MFA nicht notwendigerweise mit einem spezifischen Benutzer verknüpft.

  • Langfristige Anmeldeinformationen (IAM-Benutzer-Zugriffsschlüssel und Stammbenutzer-Zugriffsschlüssel) können für den MFA-geschützten API-Zugriff ebenfalls nicht verwendet werden, da sie zeitlich unbegrenzt sind.

  • AssumeRole und GetSessionToken können auch ohne MFA-Informationen aufgerufen werden. In diesem Fall erhält der Aufrufer temporäre Sicherheitsanmeldeinformationen, aber die Sitzungsinformationen dieser Anmeldeinformationen enthalten keine Angaben darüber, ob der Benutzer sich mit MFA authentifiziert hat.

  • Um MFA-Schutz für API-Operationen einzurichten, fügen Sie den Richtlinien MFA-Bedingungen hinzu. In einer Richtlinie muss der aws:MultiFactorAuthPresent-Bedingungsschlüssel enthalten sein, damit die Verwendung von MFA durchgesetzt wird. Bei der kontoübergreifenden Delegierung muss die Vertrauensrichtlinie der Rolle den Bedingungsschlüssel enthalten.

  • Wenn Sie einem anderen AWS-Konto den Zugriff auf die Ressourcen in Ihrem Konto erlauben, hängt die Sicherheit Ihrer Ressourcen von der Konfiguration des vertrauenswürdigen Kontos, also des anderen Kontos, ab (nicht von Ihrem Konto). Dies gilt auch, wenn Sie eine Multi-Factor Authentication verlangen. Jede Identität im vertrauenswürdigen Konto mit Berechtigung zum Erstellen von virtuellen MFA-Geräten kann einen MFA-Anspruch erstellen, um den entsprechenden Teil der Vertrauensrichtlinie Ihrer Rolle zu erfüllen. Bevor Sie Mitgliedern von einem anderen Konto den Zugriff auf Ihre AWS-Ressourcen gewähren, für die eine Multi-Factor Authentication erforderlich ist, sollten Sie sicherstellen, dass der Eigentümer des vertrauenswürdigen Kontos bewährte Sicherheitsmethoden anwendet. Beispiel: Das vertrauenswürdige Konto sollte den Zugriff auf sensible API-Operationen, z. B. API-Operationen zur MFA-Geräteverwaltung, auf spezifische, vertrauenswürdige Identitäten beschränken.

  • Wenn eine Richtlinie eine MFA-Bedingung enthält, wird eine Anfrage abgelehnt, falls die Benutzer nicht mit MFA authentifiziert worden sind oder die MFA-Geräte-ID oder das zeitlich begrenzte, einmalige Passwort ungültig ist.

Szenario: MFA-Schutz für kontoübergreifende Delegierung

In diesem Szenario können Sie den Zugriff auf IAM-Benutzer in einem anderen Konto delegieren, sofern der Benutzer sich mit einem AWS MFA-Gerät authentifiziert. Weitere Informationen über die kontoübergreifende Delegierung finden Sie unter Rollenbegriffe und -konzepte.

Angenommen, Sie haben ein Konto A (das vertrauende Konto, das die zu gewünschten Ressourcen enthält) mit der IAM-Benutzerin Anaya, die über Administratorberechtigungen verfügt. Sie möchten dem Benutzer Richard im Konto B (dem vertrauenswürdigen Konto) Zugriff gewähren, dabei aber sicherstellen, dass sich Richard mit MFA authentifiziert, bevor er die Rolle übernimmt.

  1. Anaya erstellt im vertrauenden Konto A eine IAM-Rolle mit dem Namen CrossAccountRole und gibt für den Auftraggeber in der Vertrauensrichtlinie der Rolle die Konto-ID des Kontos B an. Die Vertrauensrichtlinie erteilt die Erlaubnis für die Aktion AWS STS AssumeRole. Darüber hinaus fügt Anaya der Vertrauensrichtlinie eine MFA-Bedingung hinzu, wie im folgenden Beispiel dargestellt.

    JSON
    {
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "ACCOUNT-B-ID"},
    "Action": "sts:AssumeRole",
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }
}

  2. Anaya fügt der Rolle eine Berechtigungsrichtlinie hinzu, die die Ausführungsberechtigungen enthält. Die Berechtigungsrichtlinie für eine Rolle mit MFA-Schutz unterscheidet sich nicht von anderen Berechtigungsrichtlinien für Rollen. Das folgende Beispiel zeigt die Richtlinie, die Anaya zur Rolle hinzufügt. Sie gestattet einem Benutzer, der diese Richtlinie übernimmt, beliebige Amazon-DynamoDB-Aktionen in der Tabelle Books in Konto A durchzuführen. Diese Richtlinie gestattet auch die dynamodb:ListTables-Aktion, die zum Ausführen der Aktionen in der Konsole erforderlich ist.

    Anmerkung

    Die Berechtigungsrichtlinie enthält keine MFA-Bedingung. Beachten Sie dabei, dass die MFA-Authentifizierung nur verwendet wird, um zu ermitteln, ob ein Benutzer die Rolle übernehmen kann. Sobald der Benutzer die Rolle übernommen hat, werden keine weiteren MFA-Kontrollen durchgeführt.

    JSON
    {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "TableActions",
            "Effect": "Allow",
            "Action": "dynamodb:*",
            "Resource": "arn:aws:dynamodb:*:111122223333:table/Books"
        },
        {
            "Sid": "ListTables",
            "Effect": "Allow",
            "Action": "dynamodb:ListTables",
            "Resource": "*"
        }
    ]
}

  3. Im vertrauenswürdigen Konto B stellt der Administrator sicher, dass für den IAM-Benutzer Richard ein AWS-MFA-Gerät konfiguriert ist und er die Geräte-ID kennt. Die Gerät-ID ist bei einem physischen MFA-Gerät die Seriennummer oder bei einem virtuellen MFA-Gerät der Geräte-ARN.

  4. In Konto B fügt der Administrator die folgenden Richtlinien dem Benutzer Richard an (oder einer Gruppe, deren Mitglied Bob ist), die ihm das Aufrufen der Aktion AssumeRole gestatten. Die Ressource ist auf den ARN der von Anaya in Schritt 1 erstellten Rolle festgelegt. Beachten Sie, dass diese Richtlinie keine MFA-Bedingung enthält.

    JSON
    {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::111122223333:role/CrossAccountRole"
            ]
        }
    ]
}

  5. Richard (oder eine von Richard ausgeführte Anwendung) ruft im Konto B auf AssumeRole. Der API-Aufruf enthält den ARN der zu übernehmenden Rolle (arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole), die MFA-Geräte-ID und das aktuelle TOTP, das Richard von seinem Gerät erhält.

    Wenn Richard AssumeRole aufruft, bestimmt AWS, ob er über gültige Anmeldeinformationen verfügt (einschließlich der MFA-Anforderung). Wenn dies der Fall ist, übernimmt Richard die Rolle und kann beliebige DynamoDB-Aktionen in der Tabelle mit dem Namen Books im Konto A ausführen, sofern er die temporären Anmeldeinformationen der Rolle verwendet.

    Ein Beispiel für ein Programm, das AssumeRole aufruft, finden Sie unter Aufrufen von AssumeRole mit MFA-Authentifizierung.

Szenario: MFA-Schutz für Zugriff auf API-Operationen im aktuellen Konto

In diesem Szenario sollten Sie sicherstellen, dass einem Benutzer in Ihrem AWS-Konto nur dann Zugriff auf sensible API-Operationen gewährt wird, wenn sich der Benutzer mithilfe eines AWS-MFA-Geräts authentifiziert.

Angenommen, Sie haben ein Konto A mit einer Gruppe von Entwicklern, die mit EC2-Instances arbeiten müssen. Normale Entwickler können mit den Instances arbeiten, aber sie haben keine Berechtigungen für die Aktion ec2:StopInstances oder ec2:TerminateInstances. Sie möchten diese besonderen, "destruktiven" Aktionen auf nur einige wenige vertrauenswürdige Benutzer beschränken. Daher fügen Sie einen MFA-Schutz der Richtlinie hinzu, der diese sensiblen Amazon EC2-Aktionen zulässt.

In diesem Szenario ist Sofía einer dieser vertrauenswürdigen Benutzer. Die Benutzerin Anaya ist eine Administratorin in Konto A.

  1. Anaya stellt sicher, dass für Sofía ein AWS-MFA-Gerät konfiguriert ist und dass Sofía die Geräte-ID kennt. Die Gerät-ID ist bei einem physischen MFA-Gerät die Seriennummer oder bei einem virtuellen MFA-Gerät der Geräte-ARN.

  2. Anaya erstellt eine Gruppe mit dem Namen EC2-Admins und fügt Sofía dieser Gruppe hinzu.

  3. Anaya fügt die folgende Richtlinie an die Gruppe EC2-Admins an. Diese Richtlinie gewährt Benutzern die Berechtigung zum Aufrufen der Amazon EC2-Aktionen StopInstances und TerminateInstances nur dann, wenn sich der Benutzer mit MFA authentifiziert hat.

    JSON
    {
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "ec2:StopInstances",
      "ec2:TerminateInstances"
    ],
    "Resource": ["*"],
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }]
}
  4. Anmerkung

    Damit diese Richtlinie wirksam wird, müssen sich Benutzer zuerst abmelden und dann wieder anmelden.

    Wenn Benutzer Sofía eine Amazon EC2-Instance anhalten oder beenden muss, ruft sie (oder eine von ihr ausgeführte Anwendung) auf GetSessionToken. Diese API-Operation übergibt die ID des MFA-Geräts und das aktuelle TOTP, das Sofía von ihrem Gerät erhält.

  5. Die Benutzerin Sofía (oder eine von Sofía verwendete Anwendung) verwendet die von GetSessionToken bereitgestellten Anmeldeinformationen, um die Amazon EC2-Aktion StopInstances oder TerminateInstances aufzurufen.

    Ein Beispiel für ein Programm, das GetSessionToken aufruft, finden Sie unter Aufrufen von GetSessionToken mit MFA-Authentifizierung weiter unten in diesem Dokument.

Szenario: MFA-Schutz für Ressourcen mit ressourcenbasierten Richtlinien

In diesem Szenario sind Sie der Besitzer eines S3-Buckets, einer SQS-Warteschlange oder eines SNS-Themas. Sie möchten sicherstellen, dass alle Benutzer von allen AWS-Konto, die auf die Ressource zugreifen, sich mit einem AWS-MFA-Gerät authentifizieren.

Dieses Szenario zeigt eine Möglichkeit, den kontoübergreifenden MFA-Schutz herzustellen, ohne dass die Benutzer eine Rolle übernehmen müssen. In diesem Fall kann der Benutzer auf die Ressource zugreifen, wenn drei Bedingungen erfüllt sind: Der Benutzer muss sich mithilfe von MFA authentifizieren, muss in der Lage sein, temporäre Sicherheitsanmeldeinformationen über GetSessionToken abzurufen, und muss über ein Konto verfügen, das von der Ressourcenrichtlinie als vertrauenswürdig eingestuft wird.

Angenommen, Sie befinden sich im Konto A und erstellen einen S3-Bucket. Sie möchten den Benutzern in den verschiedenen AWS-Konten den Zugriff auf diesen Bucket gewähren, sofern diese Benutzer mit MFA authentifiziert werden.

In diesem Szenario ist Anaya eine Administratorin im Konto A und Benutzer Nikhil ist ein IAM-Benutzer im Konto C.

  1. Anaya erstellt im Konto A einen Bucket mit dem Namen Account-A-bucket.

  2. Anaya fügt die Bucket-Richtlinie dem Bucket hinzu. Die Richtlinie gestattet jedem Benutzer in Konto A, Konto B und Konto C, die Amazon S3-Aktionen PutObject und DeleteObject im S3-Bucket auszuführen. Die Richtlinie enthält eine MFA-Bedingung.

    JSON
    {
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": [
      "ACCOUNT-A-ID",
      "ACCOUNT-B-ID",
      "ACCOUNT-C-ID"
    ]},
    "Action": [
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": ["arn:aws:s3:::ACCOUNT-A-BUCKET-NAME/*"],
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }]
}
    Anmerkung

    Amazon S3; bietet eine MFA Delete-Funktion (nur) für den Stamm-Kontozugriff. Sie können Amazon S3 MFA Delete aktivieren, wenn Sie den Versionierungsstatus des Buckets festlegen. Amazon S3 MFA Delete kann nicht auf einen IAM-Benutzer angewendet werden und wird unabhängig von MFA-geschützten API-Zugriffen verwaltet. Ein IAM-Benutzer mit Berechtigungen zum Löschen eines Buckets kann keinen Bucket löschen, für den Amazon S3 MFA Delete aktiviert ist. Weitere Informationen zu Amazon S3 MFA Delete finden Sie unter MFA Delete.

  3. Im Konto C stellt ein Administrator sicher, dass für den Benutzer Nikhil ein AWS-MFA-Gerät konfiguriert ist und er die Geräte-ID kennt. Die Gerät-ID ist bei einem physischen MFA-Gerät die Seriennummer oder bei einem virtuellen MFA-Gerät der Geräte-ARN.

  4. Nikhil (oder eine von Nikhil ausgeführte Anwendung) ruft im Konto C auf GetSessionToken. Der Aufruf enthält die ID oder den ARN des MFA-Geräts und das aktuelle TOTP, das Nikhil von seinem Gerät erhält.

  5. Nikhil (oder eine von Nikhil verwendete Anwendung) benutzt die von GetSessionToken bereitgestellten Anmeldeinformationen, um die Amazon S3–PutObjectAktion zum Hochladen einer Datei nach Account-A-bucket aufzurufen.

    Ein Beispiel für ein Programm, das GetSessionToken aufruft, finden Sie unter Aufrufen von GetSessionToken mit MFA-Authentifizierung weiter unten in diesem Dokument.

    Anmerkung

    Die von AssumeRole zurückgegebenen temporären Anmeldeinformationen funktionieren in diesem Fall nicht. Obwohl der Benutzer MFA-Informationen bereitstellen kann, um eine Rolle zu übernehmen, enthalten die von AssumeRole zurückgegebenen temporären Anmeldeinformationen nicht die MFA-Informationen. Diese Informationen sind zur Erfüllung der MFA-Bedingung in der Richtlinie erforderlich.