Sicherer API Zugriff mit MFA

Mithilfe von IAM Richtlinien können Sie festlegen, welche API Operationen ein Benutzer aufrufen darf. Sie können zusätzliche Sicherheit bieten, indem Sie von Benutzern verlangen, sich mit der Multi-Faktor-Authentifizierung (MFA) zu authentifizieren, bevor Sie ihnen erlauben, besonders sensible 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

Das Hinzufügen von MFA Schutz zu API Vorgängen umfasst die folgenden Aufgaben:

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 gibt auch das zeitbasierte Einmalkennwort (TOTP) an, das das Gerät generiert. 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

   MFADer Schutz für den API Betrieb eines Dienstes ist nur verfügbar, wenn der Dienst 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, einen API Vorgang ohne gültige MFA Authentifizierung aufzurufen. Der Vorgang wird auch verweigert, wenn der Zeitstempel der Anforderung für den API Vorgang außerhalb des in der Richtlinie angegebenen zulässigen Bereichs liegt. Der Benutzer muss erneut authentifiziert werden, MFA indem neue temporäre Sicherheitsanmeldedaten mit einem MFA Code und einer Geräteseriennummer angefordert werden.

IAMRichtlinien mit Bedingungen MFA

Richtlinien mit MFA Bedingungen können an Folgendes angehängt werden:

• Einem IAM-Benutzer oder einer -Gruppe

• Eine Ressource wie ein Amazon S3 S3-Bucket, eine SQS Amazon-Warteschlange oder ein SNS Amazon-Thema

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

Sie können eine MFA Bedingung in einer Richtlinie verwenden, um die folgenden Eigenschaften zu überprüfen:

• Existenz — Um einfach zu überprüfen, ob der Benutzer sich authentifiziert hatMFA, überprüfen Sie, ob sich der aws:MultiFactorAuthPresent Schlüssel in einem Zustand befindet. True Bool 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 (z. B. 3600 Sekunden) zu vergleichen. Beachten Sie, dass der aws:MultiFactorAuthAge Schlüssel nicht vorhanden ist, wenn MFA er nicht verwendet wurde.

Das folgende Beispiel zeigt die Vertrauensrichtlinie einer IAM Rolle, die eine MFA Bedingung zum Testen des Vorhandenseins einer MFA Authentifizierung enthält. 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 übernehmen, wenn der Benutzer über MFA authentifiziert ist.

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

Weitere Informationen zu den Bedingungstypen für finden Sie unter MFA AWS Kontextschlüssel für globale BedingungenNumerische Bedingungsoperatoren, undBedingungsoperator zur Prüfung der Existenz von Bedingungsoperatoren .

Wählen Sie zwischen GetSessionToken und AssumeRole

AWS STS bietet zwei API Operationen, mit denen Benutzer MFA Informationen weitergeben können: GetSessionToken undAssumeRole. Der API Vorgang, den der Benutzer aufruft, um temporäre Sicherheitsanmeldeinformationen abzurufen, hängt davon ab, welches der folgenden Szenarien zutrifft.

Verwenden Sie GetSessionToken für die folgenden Szenarien:

• Rufen Sie API Operationen auf, die auf Ressourcen zugreifen, AWS-Konto genauso wie der IAM Benutzer, der die Anfrage stellt. Beachten Sie, dass temporäre Anmeldeinformationen aus einer GetSessionToken Anforderung nur dann auf AWS STS API Vorgänge zugreifen IAM können, wenn Sie MFA Informationen in die Anforderung von Anmeldeinformationen aufnehmen. Da temporäre Anmeldeinformationen, die von GetSessionToken MFA Include zurückgegeben werden, Informationen enthalten, können Sie MFA bei einzelnen API Vorgängen anhand der Anmeldeinformationen nach Informationen suchen.

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

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

Verwenden Sie AssumeRole für die folgenden Szenarien:

• Rufen Sie API Operationen auf, die auf Ressourcen in derselben oder einer anderen AWS-Konto Umgebung zugreifen. Die API Aufrufe können ein beliebiges IAM oder beinhalten AWS STS API. Beachten Sie, dass Sie den Zugriff zu dem MFA Zeitpunkt erzwingen, zu dem der Benutzer die Rolle übernimmt, um den Zugriff zu schützen. Die von zurückgegebenen temporären Anmeldeinformationen enthalten AssumeRole keine MFA Informationen im Kontext, sodass Sie bei einzelnen API Vorgängen nicht überprüfen könnenMFA. Daher müssen Sie GetSessionToken verwenden, um den Zugriff auf die von ressourcenbasierten Richtlinien geschützten Ressourcen einzuschränken.

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

Wichtige Hinweise zum MFA -geschützten Zugriff API

Es ist wichtig, die folgenden Aspekte des API betrieblichen MFA Schutzes zu verstehen:

• MFADer Schutz ist nur mit temporären Sicherheitsanmeldedaten verfügbar, die mit AssumeRole oder abgerufen werden müssenGetSessionToken.

• Sie können den MFA -geschützten API Zugriff nicht zusammen 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 Ressourcen zugreifen AWS können, die von gesteuert werden. MFA (Siehe nächster Punkt.)

• Andere AWS STS API Operationen, die temporäre Anmeldeinformationen zurückgeben, werden nicht unterstütztMFA. Für AssumeRoleWithWebIdentity und AssumeRoleWithSAML wird der Benutzer von einem externen Anbieter authentifiziert und AWS kann nicht feststellen, ob dieser Anbieter dies erfordertMFA. ForGetFederationToken, MFA ist nicht unbedingt mit einem bestimmten Benutzer verknüpft.

• Ebenso können langfristige Anmeldeinformationen (IAMBenutzerzugriffsschlüssel und Root-Benutzerzugriffsschlüssel) nicht mit MFA -geschütztem API Zugriff verwendet werden, da sie nicht ablaufen.

• AssumeRoleund GetSessionToken kann auch ohne MFA Informationen aufgerufen werden. In diesem Fall erhält der Anrufer temporäre Sicherheitsanmeldeinformationen zurück, aber die Sitzungsinformationen für diese temporären Anmeldeinformationen weisen nicht darauf hin, dass sich der Benutzer mit authentifiziert hat. MFA

• Um den API Betrieb zu MFA schützen, fügen Sie den Richtlinien MFA Bedingungen hinzu. Eine Richtlinie muss den aws:MultiFactorAuthPresent Bedingungsschlüssel enthalten, mit dem die Verwendung von erzwungen werden sollMFA. Bei der kontoübergreifenden Delegierung muss die Vertrauensrichtlinie der Rolle den Bedingungsschlüssel enthalten.

• Wenn Sie einer anderen AWS-Konto Person 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, die berechtigt ist, virtuelle MFA Geräte zu erstellen, kann den MFA Anspruch erheben, diesen 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 mehrstufige Authentifizierung erforderlich ist, sollten Sie sicherstellen, dass der Besitzer des vertrauenswürdigen Kontos die bewährten Sicherheitsmethoden befolgt. Beispielsweise sollte das vertrauenswürdige Konto den Zugriff auf vertrauliche API Vorgänge, wie z. B. MFA API Geräteverwaltungsvorgänge, auf bestimmte, vertrauenswürdige Identitäten beschränken.

• Wenn eine Richtlinie eine MFA Bedingung enthält, wird eine Anfrage abgelehnt, wenn Benutzer nicht MFA authentifiziert wurden oder wenn sie eine ungültige oder ungültige MFA Gerätekennung angeben. TOTP

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 Gerät authentifiziert sind. AWS MFA Weitere Informationen über die kontoübergreifende Delegierung finden Sie unter Rollenbegriffe und -konzepte.

Stellen Sie sich vor, Sie haben Konto A (das vertrauenswürdige Konto, dem die Ressource gehört, auf die zugegriffen werden soll) mit dem IAM Benutzer Anaya, der über Administratorrechte verfügt. Sie möchte dem Benutzer Richard Zugriff auf Konto B (das vertrauenswürdige Konto) gewähren, möchte aber sicherstellen, dass Richard authentifiziert ist, MFA bevor er die Rolle übernimmt.

1. Im vertrauenswürdigen Konto A erstellt Anaya eine IAM Rolle mit dem Namen CrossAccountRole und legt den Prinzipal 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 Anaya fügt der Vertrauensrichtlinie außerdem eine MFA Bedingung hinzu, wie im folgenden Beispiel.

   {
     "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 geschützte Rolle unterscheidet sich nicht von anderen Rollenberechtigungsrichtlinien. MFA 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 Bedingung. MFA Es ist wichtig zu verstehen, dass die MFA Authentifizierung nur verwendet wird, um festzustellen, ob ein Benutzer die Rolle übernehmen kann. Sobald der Benutzer die Rolle übernommen hat, werden keine weiteren MFA Prüfungen mehr 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äte-ID ist die Seriennummer, wenn es sich um ein Hardwaregerät MFA handelt, oder die des Geräts, ARN wenn es sich um ein virtuelles MFA Gerät handelt.

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 die ARN Rolle festgelegt, die Anaya in Schritt 1 erstellt hat. 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 beinhaltet die ARN Rolle, die übernommen werden soll (arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole), die ID des MFA Geräts und den StromTOTP, den 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ürMFA. 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 Anruf AssumeRole mit Authentifizierung MFA.

Szenario: MFA Schutz für den Zugriff auf API Operationen im Girokonto

In diesem Szenario sollten Sie sicherstellen, dass ein Benutzer in Ihrem Konto nur dann auf vertrauliche API Vorgänge zugreifen AWS-Konto kann, wenn der Benutzer über ein AWS MFA Gerät authentifiziert wurde.

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, zusätzlichen 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äte-ID ist die Seriennummer, wenn es sich um ein Hardwaregerät handelt, oder die des MFA Geräts, ARN wenn es sich um ein virtuelles Gerät handelt. MFA

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 über 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. Bei diesem API Vorgang werden die ID des MFA Geräts und der StromTOTP, den Sofía von ihrem Gerät erhält, weitergegeben.

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 Anrufe 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 Gerät AWS MFA authentifiziert wird.

Dieses Szenario zeigt, wie kontoübergreifender MFA Schutz bereitgestellt werden kann, ohne dass Benutzer zuerst eine Rolle übernehmen müssen. In diesem Fall kann der Benutzer auf die Ressource zugreifen, wenn drei Bedingungen erfüllt sind: Der Benutzer muss authentifiziert seinMFA, temporäre Sicherheitsanmeldeinformationen von diesem abrufen können und Mitglied eines Kontos seinGetSessionToken, dem die Ressourcenrichtlinie vertraut.

Angenommen, Sie befinden sich im Konto A und erstellen einen S3-Bucket. Sie möchten Benutzern, die sich in verschiedenen Ländern befinden, Zugriff auf diesen Bucket gewähren AWS-Konten, aber nur, wenn diese Benutzer authentifiziert sind. MFA

In diesem Szenario ist der Benutzer Anaya ein Administrator in Konto A. Benutzer Nikhil ist ein IAM Benutzer in 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 beinhaltet eine Bedingung. MFA

   {
     "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 Löschfunktion für den Zugriff auf Root-Konten (nur). Sie können Amazon S3 MFA Delete aktivieren, wenn Sie den Versionsstatus des Buckets festlegen. Amazon S3 MFA Delete kann nicht auf einen IAM Benutzer angewendet werden und wird unabhängig vom MFA -geschützten API Zugriff verwaltet. Ein IAM Benutzer mit Berechtigungen zum Löschen eines Buckets kann einen Bucket nicht löschen, wenn Amazon S3 MFA Delete aktiviert ist. Weitere Informationen zu Amazon S3 MFA Delete finden Sie unter MFALöschen.

3. In Konto C stellt ein Administrator sicher, dass der Benutzer Nikhil mit einem AWS MFA Gerät konfiguriert ist und dass er die ID des Geräts kennt. Die Geräte-ID ist die Seriennummer, wenn es sich um ein MFA Hardwaregerät handelt, oder die des Geräts, ARN wenn es sich um ein virtuelles MFA Gerät handelt.

4. Nikhil (oder eine von Nikhil ausgeführte Anwendung) ruft im Konto C GetSessionToken auf. Der Anruf beinhaltet die ID oder ARN des MFA Geräts und den StromTOTP, den 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 Anrufe GetSessionToken mit MFA Authentifizierung weiter unten in diesem Dokument.

   Anmerkung

   Die von AssumeRole zurückgegebenen temporären Anmeldeinformationen funktionieren in diesem Fall nicht. Der Benutzer kann zwar MFA Informationen angeben, um eine Rolle zu übernehmen, aber die von zurückgegebenen temporären Anmeldeinformationen enthalten diese Informationen AssumeRole nicht. MFA Diese Informationen sind erforderlich, um die in der Richtlinie MFA festgelegte Bedingung zu erfüllen.