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.

Möglicherweise haben Sie eine Richtlinie, die es einem Benutzer ermöglicht, die Amazon- EC2 RunInstancesDescribeInstances, und StopInstances -Aktionen auszuführen. Möglicherweise möchten Sie jedoch eine destruktive Aktion einschränken TerminateInstances und sicherstellen, dass Benutzer diese Aktion nur ausführen können, wenn sie sich mit einem AWS MFA-Gerät authentifizieren.

Ü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, für die eine MFA-Authentifizierung erforderlich ist. Weitere Informationen finden Sie unter AWS Multi-Faktor-Authentifizierung in IAM.

2. Der Administrator erstellt Richtlinien für die Benutzer, die ein Condition Element enthalten, das überprüft, ob sich der Benutzer 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: AssumeRoleoder 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 AWS benutzen kann.

   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 auf AWS.

Schlägt die Autorisierung fehl, wird eine Fehlermeldung „Zugriff verweigert“ AWS zurückgegeben (wie bei jedem nicht autorisierten Zugriff). Wenn MFA-geschützte API-Richtlinien vorhanden sind, wird der Zugriff auf die in den Richtlinien angegebenen AWS API-Operationen verweigert, 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 Benutzer der im Principal Element AWS-Konto angegebenen Rolle (durch eine gültige AWS-Konto ID ACCOUNT-B-ID ersetzen) die Rolle übernehmen, der diese Richtlinie zugewiesen ist. Solche Benutzer können die Rolle jedoch nur annehmen, wenn sie sich mit MFA authentifizieren.

{
  "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 Kontextschlüssel für globale Bedingungen, Numerische Bedingungsoperatoren und Bedingungsoperator zur Prüfung der Existenz von Bedingungsoperatoren .

Sie haben die Wahl zwischen GetSessionToken und AssumeRole

AWS STS bietet zwei API-Operationen, mit denen Benutzer MFA-Informationen weitergeben können: GetSessionToken undAssumeRole. 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:

• Rufen Sie API-Operationen auf, die auf Ressourcen zugreifen, genauso AWS-Konto wie der IAM-Benutzer, der die Anfrage stellt. Beachten Sie, dass temporäre Anmeldeinformationen aus einer GetSessionToken Anfrage nur dann auf IAM- und AWS STS API-Operationen zugreifen können, wenn Sie MFA-Informationen in die Anforderung von Anmeldeinformationen 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 jedes IAM oder jede API beinhalten. AWS STS 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, CloudTrail werden auch die sessionContext Attribute für Aktionen protokolliertmfaAuthenticated: true, die mit der angenommenen Rolle ausgeführt wurden. Die CloudTrail Protokollierung erfolgt jedoch unabhängig von den Anforderungen von IAM, wenn API-Aufrufe mit den Anmeldeinformationen der angenommenen Rolle getätigt werden. Weitere Informationen finden Sie unter CloudTrail-Element userIdentity.

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 Diensten zugewiesen werden, sodass sie nicht auf AWS Ressourcen zugreifen können, die von MFA gesteuert werden. (Siehe nächster Punkt.)

• Andere AWS STS API-Operationen, die temporäre Anmeldeinformationen zurückgeben, unterstützen MFA nicht. Für AssumeRoleWithWebIdentity und AssumeRoleWithSAML wird der Benutzer von einem externen Anbieter authentifiziert und AWS kann nicht feststellen, ob dieser Anbieter MFA benötigt. 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 einer anderen Person AWS-Konto den Zugriff auf Ressourcen in Ihrem Konto gestatten, hängt die Sicherheit Ihrer Ressourcen von der Konfiguration des vertrauenswürdigen Kontos ab (das andere Konto, nicht Ihres). 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 eines anderen Kontos Zugriff auf Ihre AWS Ressourcen gewähren, für die eine Multi-Faktor-Authentifizierung erforderlich ist, sollten Sie sicherstellen, dass der Besitzer des vertrauenswürdigen Kontos die bewährten Sicherheitsmethoden befolgt. 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 möchten Sie den Zugriff an IAM-Benutzer in einem anderen Konto delegieren, aber nur, wenn die Benutzer mit einem AWS MFA-Gerät authentifiziert sind. Weitere Informationen zur kontoübergreifenden 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. Im vertrauenswürdigen Konto A erstellt Anaya eine IAM-Rolle mit dem Namen CrossAccountRole und legt den Principal in der Vertrauensrichtlinie der Rolle auf die Konto-ID von Konto B fest. Die Vertrauensrichtlinie erteilt die Genehmigung für die Aktion. AWS STS AssumeRole Darüber hinaus fügt Anaya der Vertrauensrichtlinie eine MFA-Bedingung hinzu, wie im folgenden Beispiel dargestellt.

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

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

3. Im vertrauenswürdigen Konto B stellt der Administrator sicher, dass der IAM-Benutzer Richard mit einem AWS MFA-Gerät konfiguriert ist und dass er die ID des Geräts 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.

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

5. Richard (oder eine von Richard ausgeführte Anwendung) ruft im Konto B AssumeRole auf. 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 anruftAssumeRole, AWS stellt er fest, ob er über gültige Anmeldeinformationen verfügt, einschließlich der Anforderungen für MFA. 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 Telefonieren AssumeRole mit MFA-Authentifizierung.

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

In diesem Szenario sollten Sie sicherstellen, dass ein Benutzer in Ihrem Konto nur dann auf sensible API-Operationen zugreifen AWS-Konto kann, wenn der Benutzer mit einem AWS MFA-Gerät authentifiziert ist.

Stellen Sie sich vor, Sie haben Konto A, das eine Gruppe von Entwicklern enthält, die mit EC2 Instanzen 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 „destruktiven“ privilegierten Aktionen auf einige wenige vertrauenswürdige Benutzer beschränken. Daher fügen Sie der Richtlinie, die diese sensiblen EC2 Amazon-Aktionen zulässt, MFA-Schutz hinzu.

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 Sofía mit einem AWS MFA-Gerät konfiguriert ist und dass Sofía die ID des Geräts 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 nur dann die Erlaubnis, Amazon EC2 StopInstances und TerminateInstances Aktionen anzurufen, wenn sich der Benutzer mit MFA authentifiziert hat.

   {
     "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 die Benutzerin Sofía eine EC2 Amazon-Instance beenden oder beenden muss, ruft GetSessionToken sie (oder eine Anwendung, die sie gerade ausführt) auf. Diese API-Operation übergibt die ID des MFA-Geräts und das aktuelle TOTP, das Sofía von ihrem Gerät erhält.

5. Der Benutzer Sofía (oder eine Anwendung, die Sofía verwendet) verwendet die von bereitgestellten temporären AnmeldeinformationenGetSessionToken, um Amazon EC2 StopInstances oder TerminateInstances Action aufzurufen.

   Ein Beispiel für ein Programm, das GetSessionToken aufruft, finden Sie unter Telefonieren 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 jeder Benutzer, der auf AWS-Konto die Ressource zugreift, von einem AWS MFA-Gerät authentifiziert wird.

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 Benutzern, die sich in mehreren verschiedenen Ländern befinden, Zugriff auf diesen Bucket gewähren AWS-Konten, aber nur, wenn diese Benutzer mit MFA authentifiziert sind.

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.

   {
     "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 GetSessionToken auf. 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 Telefonieren 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.