Machine-to-machine Identitätsmanagement

Machine-to-machine Die (M2M) -Authentifizierung ermöglicht es Services und Anwendungen, die auf AWS ausgeführt werden, sicher miteinander zu kommunizieren, um auf Ressourcen und Daten zuzugreifen. Anstatt langfristige statische Anmeldeinformationen zu verwenden, geben Maschinenauthentifizierungssysteme temporäre Anmeldeinformationen oder Token aus, um vertrauenswürdige Computer zu identifizieren. Sie ermöglichen eine präzise Kontrolle darüber, welche Maschinen ohne menschliches Eingreifen auf bestimmte Teile der Umgebung zugreifen können. Eine gut durchdachte Maschinenauthentifizierung trägt zur Verbesserung Ihrer Sicherheitslage bei, indem sie die breite Offenlegung von Anmeldeinformationen begrenzt, den dynamischen Widerruf von Berechtigungen ermöglicht und die Rotation von Anmeldeinformationen vereinfacht. Zu den typischen Methoden für die maschinelle Authentifizierung gehören EC2 Instanzprofile, die Gewährung von Amazon Cognito Cognito-Client-Anmeldeinformationen, gegenseitig authentifizierte TLS (mTLS) -Verbindungen und IAM Roles Anywhere. Dieser Abschnitt enthält Anleitungen zur Implementierung sicherer und skalierbarer M2M-Authentifizierungsabläufe auf AWS.

EC2 Instanzprofile

Für Szenarien, in denen eine Anwendung oder ein Service auf Amazon Elastic Compute Cloud (Amazon EC2) läuft und AWS APIs aufrufen muss, sollten Sie die Verwendung von EC2 Instanzprofilen in Betracht ziehen. Instance-Profile ermöglichen Anwendungen, die auf EC2 Instances ausgeführt werden, den sicheren Zugriff auf andere AWS-Services, ohne dass statische, langlebige IAM-Zugriffsschlüssel erforderlich sind. Stattdessen sollten Sie Ihrer Instance eine IAM-Rolle zuweisen, um die erforderlichen Berechtigungen über das Instance-Profil bereitzustellen. Die EC2 Instance kann dann automatisch temporäre Sicherheitsanmeldedaten aus dem Instance-Profil abrufen, um auf andere AWS-Services zuzugreifen. 

Das folgende Diagramm veranschaulicht dieses Szenario.

1. Eine Anwendung auf der EC2 Instance, die eine AWS-API aufrufen muss, ruft die von der Rolle bereitgestellten Sicherheitsanmeldedaten aus dem Instance-Metadatenelement iam/security-credentials/<role-name> ab. 

2. Die Anwendung erhält das AccessKeyIdSecretAccessKey, und ein geheimes Token, das zum Signieren von AWS-API-Anfragen verwendet werden kann.

3. Die Anwendung ruft eine AWS-API auf. Wenn die Rolle die API-Aktion zulässt, ist die Anfrage erfolgreich.

Weitere Informationen zur Verwendung temporärer Anmeldeinformationen mit AWS-Ressourcen finden Sie in der IAM-Dokumentation unter Verwenden temporärer Anmeldeinformationen mit AWS-Ressourcen.

Vorteile

• Verbesserte Sicherheit. Diese Methode vermeidet die Verteilung langfristiger Anmeldeinformationen an EC2 Instanzen. Anmeldeinformationen werden vorübergehend über das Instanzprofil bereitgestellt. 

• Einfache Integration. Anwendungen, die auf der Instanz ausgeführt werden, können ohne zusätzliche Codierung oder Konfiguration automatisch Anmeldeinformationen abrufen. AWS verwendet SDKs automatisch die Anmeldeinformationen für das Instance-Profil.

• Dynamische Berechtigungen. Sie können die für die Instance verfügbaren Berechtigungen ändern, indem Sie die IAM-Rolle aktualisieren, die dem Instanzprofil zugewiesen ist. Neue Anmeldeinformationen, die die aktualisierten Berechtigungen widerspiegeln, werden automatisch abgerufen. 

• Rotation. AWS rotiert die temporären Anmeldeinformationen automatisch, um das Risiko kompromittierter Anmeldeinformationen zu verringern. 

• Widerruf. Sie können die Anmeldeinformationen sofort widerrufen, indem Sie die Rollenzuweisung aus dem Instanzprofil entfernen.

Designüberlegungen

• Einer EC2 Instanz kann nur ein angehängtes Instanzprofil zugeordnet sein.

• Verwenden Sie IAM-Rollen mit den geringsten Rechten. Weisen Sie der IAM-Rolle für das Instanzprofil nur die Berechtigungen zu, die Ihre Anwendung benötigt. Beginnen Sie mit Mindestberechtigungen und fügen Sie später bei Bedarf weitere Berechtigungen hinzu. 

• Verwenden Sie die IAM-Bedingungen in der Rollenrichtlinie, um Berechtigungen auf der Grundlage von Tags, IP-Adressbereichen, Tageszeit usw. einzuschränken. Dadurch werden die Dienste und Ressourcen eingeschränkt, auf die die Anwendung zugreifen kann.

• Überlegen Sie, wie viele Instanzprofile Sie benötigen. Alle Anwendungen, die auf einer EC2 Instance ausgeführt werden, haben dasselbe Profil und dieselben AWS-Berechtigungen. Sie können dasselbe Instance-Profil auf mehrere EC2 Instances anwenden, sodass Sie den Verwaltungsaufwand reduzieren können, indem Sie Instance-Profile gegebenenfalls wiederverwenden.

• Überwachen Sie die Aktivität. Verwenden Sie Tools wie AWS CloudTrail , um API-Aufrufe zu überwachen, die die Anmeldeinformationen des Instance-Profils verwenden. Achten Sie auf ungewöhnliche Aktivitäten, die auf kompromittierte Anmeldeinformationen hinweisen könnten. 

• Löschen Sie nicht benötigte Anmeldeinformationen. Entfernen Sie Rollenzuweisungen aus ungenutzten Instanzprofilen, um die Verwendung von Anmeldeinformationen zu verhindern. Sie können den IAM Access Advisor verwenden, um ungenutzte Rollen zu identifizieren. 

• Verwenden Sie die PassRole Berechtigung, um einzuschränken, welche Rolle ein Benutzer einer EC2 Instance übergeben kann, wenn er die Instance startet. Dadurch wird verhindert, dass der Benutzer Anwendungen ausführt, die über mehr Berechtigungen verfügen, als dem Benutzer gewährt wurden.

• Wenn Ihre Architektur mehrere AWS-Konten umfasst, sollten Sie sich überlegen, wie EC2 Instances in einem Konto möglicherweise auf Ressourcen in einem anderen Konto zugreifen müssen. Verwenden Sie kontenübergreifende Rollen angemessen, um einen sicheren Zugriff zu gewährleisten, ohne langfristige AWS-Sicherheitsanmeldedaten einbetten zu müssen.

• Um Instance-Profile in großem Umfang zu verwalten, können Sie eine der folgenden Optionen verwenden:

  • Verwenden Sie AWS Systems Manager Automation Automation-Runbooks, um die Zuordnung von Instance-Profilen zu EC2 Instances zu automatisieren. Dies kann beim Start oder nach der Ausführung einer Instance erfolgen.

  • Verwenden Sie AWS CloudFormation , um Instanzprofile bei der Erstellung programmgesteuert auf EC2 Instances anzuwenden, anstatt sie über die AWS-Konsole zu konfigurieren.

• Es hat sich bewährt, VPC-Endpunkte zu verwenden, um von Anwendungen aus, die auf Instances ausgeführt werden, privat eine Verbindung zu unterstützten AWS-Services wie Amazon S3 und Amazon DynamoDB herzustellen. EC2 

Gewährung Amazon Cognito Cognito-Kundenanmeldedaten

Amazon Cognito ist ein verwalteter Kundenidentitäts- und Zugriffsverwaltungsservice. Amazon Cognito bietet OAuth konforme Authentifizierungsabläufe, einschließlich der Möglichkeit, Maschinen oder Anwendungen anstelle von Benutzern über den Grant-Typ für Client-Anmeldeinformationen zu authentifizieren. Dieser Zuschuss ermöglicht es einer Anwendung, temporäre AWS-Anmeldeinformationen für den Zugriff auf AWS-Services direkt abzurufen. Amazon Cognito Cognito-Kundenanmeldedaten sind eine sichere Methode, AWS-Berechtigungen für Anwendungen ohne menschliche Benutzerinteraktion bereitzustellen. Anwendungen präsentieren ihre Client-ID und ihr Client-Geheimnis dem Amazon Cognito-Token-Endpunkt. Im Gegenzug erhalten sie ein Zugriffstoken, mit dem sie nachfolgende Anfragen an verschiedene Ressourcen und Dienste authentifizieren können. Der Umfang dieses Zugriffs wird durch die Berechtigungen bestimmt, die der Client-ID zugeordnet sind. Die Anwendung, die die Anforderung empfängt, muss das Token anhand seiner Signatur, seines Ablaufzeitstempels und seiner Zielgruppe validieren. Nach diesen Prüfungen überprüft die Anwendung, ob die angeforderte Aktion zulässig ist, indem sie die Ansprüche im Token validiert.

Das folgende Diagramm veranschaulicht diese Methode.

1. Die Anwendung (App Client), die Ressourcen von einem Server (Resource Server) anfordern möchte, fordert ein Token von Amazon Cognito an.

2. Amazon Cognito Cognito-Benutzerpools geben ein Zugriffstoken zurück.

3. Der App Client sendet eine Anfrage an den Resource Server und enthält das Zugriffstoken.

4. Resource Server validiert das Token mit Amazon Cognito.

5. Wenn die Validierung erfolgreich ist und die angeforderte Aktion zulässig ist, antwortet Resource Server mit der angeforderten Ressource.

Vorteile

• Maschinenauthentifizierung. Für diese Methode sind weder Benutzerkontext noch Anmeldungen erforderlich. Die Anwendung authentifiziert sich direkt mit Tokens.

• Kurzfristige Referenzen. Anwendungen können zuerst ein Zugriffstoken von Amazon Cognito erhalten und dann das zeitgebundene Zugriffstoken verwenden, um auf Daten vom Ressourcenserver zuzugreifen.

• OAuth2 Unterstützung. Diese Methode reduziert Inkonsistenzen und hilft bei der Anwendungsentwicklung, da sie dem etablierten OAuth2 Standard folgt.

• Verbesserte Sicherheit. Die Verwendung der Zuweisung von Client-Anmeldeinformationen bietet mehr Sicherheit, da die Client-ID und der geheime Client-Schlüssel im Gegensatz zu einem API-Schlüssel-Autorisierungsmechanismus nicht an den Ressourcenserver übertragen werden. Die Client-ID und der geheime Schlüssel werden geteilt und nur verwendet, wenn Amazon Cognito aufgerufen wird, um zeitgebundene Zugriffstoken zu erhalten.

• Präzise Zugriffskontrolle anhand von Bereichen. Die Anwendung kann Bereiche und zusätzliche Ansprüche definieren und anfordern, um den Zugriff nur auf bestimmte Ressourcen zu beschränken.

• Prüfprotokoll. Sie können die von gesammelten Informationen verwenden, CloudTrail um die Anfrage, die an Amazon Cognito gestellt wurde, die IP-Adresse, von der aus die Anfrage gestellt wurde, wer die Anfrage gestellt hat, wann sie gestellt wurde, und weitere Details zu ermitteln. 

Designüberlegungen

• Definieren Sie sorgfältig den Zugriffsumfang für jede Client-ID und beschränken Sie ihn auf das erforderliche Minimum. Enge Bereiche tragen dazu bei, potenzielle Sicherheitslücken zu reduzieren und sicherzustellen, dass Dienste nur auf die erforderlichen Ressourcen zugreifen können. 

• Schützen Sie Kunden IDs und Geheimnisse, indem Sie sichere Speicherdienste wie AWS Secrets Manager zum Speichern von Anmeldeinformationen verwenden. Checken Sie die Anmeldeinformationen nicht in den Quellcode ein.

• Überwachen und prüfen Sie Token-Anfragen und deren Verwendung mit Tools wie CloudTrail und CloudWatch. Achten Sie auf unerwartete Aktivitätsmuster, die auf Probleme hinweisen könnten. 

• Automatisieren Sie die regelmäßige Rotation von Kundengeheimnissen. Erstellen Sie bei jeder Rotation einen neuen Anwendungsclient, löschen Sie den alten Client und aktualisieren Sie die Client-ID und den geheimen Schlüssel. Erleichtern Sie diese Rotationen, ohne die Dienstkommunikation zu unterbrechen. 

• Setzen Sie Ratenbegrenzungen für Token-Endpunktanfragen durch, um Missbrauch und Denial-of-Service (DoS) -Angriffe zu verhindern. 

• Halten Sie eine Strategie für den Widerruf von Token im Falle einer Sicherheitsverletzung bereit. Obwohl Token kurzlebig sind, sollten kompromittierte Token sofort für ungültig erklärt werden.

• Verwenden Sie AWS CloudFormation , um programmgesteuert Amazon Cognito Cognito-Benutzerpools und Anwendungsclients zu erstellen, die die Maschinen darstellen, die sich bei anderen Services authentifizieren müssen.

• Gegebenenfalls Cache-Token, um Leistungseffizienz und Kostenoptimierung zu gewährleisten.

• Stellen Sie sicher, dass der Ablauf von Zugriffstoken der Sicherheitslage Ihres Unternehmens entspricht.

• Wenn Sie einen benutzerdefinierten Ressourcenserver verwenden, überprüfen Sie immer das Zugriffstoken, um sicherzustellen, dass die Signatur gültig ist, das Token nicht abgelaufen ist und die richtigen Gültigkeitsbereiche vorhanden sind. Überprüfen Sie bei Bedarf alle zusätzlichen Ansprüche.

• Um Kundenanmeldedaten in großem Umfang zu verwalten, können Sie eine der folgenden Optionen verwenden:

  • Zentralisieren Sie die Verwaltung aller Kundenanmeldedaten in einer einzigen zentralen Amazon Cognito Cognito-Instanz. Dies kann den Verwaltungsaufwand mehrerer Amazon Cognito Cognito-Instanzen reduzieren und die Konfiguration und Prüfung vereinfachen. Achten Sie jedoch darauf, die Skalierung zu planen und die Amazon Cognito-Servicekontingente zu berücksichtigen.

  • Bündeln Sie die Verantwortung für Kundenanmeldedaten mit Workload-Konten und lassen Sie mehrere Amazon Cognito Cognito-Instances zu. Diese Option fördert die Flexibilität, kann aber im Vergleich zur zentralisierten Option den Overhead und die Gesamtkomplexität erhöhen.

mTLS-Verbindungen

Die gegenseitige TLS-Authentifizierung (mTLS) ist ein Mechanismus, der es sowohl dem Client als auch dem Server ermöglicht, sich gegenseitig zu authentifizieren, bevor sie mithilfe von TLS-Zertifikaten kommunizieren. Zu den häufigsten Anwendungsfällen für mTLs gehören Branchen mit hohen Vorschriften, Internet of Things (IoT) -Anwendungen und business-to-business (B2B) -Anwendungen. Amazon API Gateway unterstützt derzeit zusätzlich zu seinen bestehenden Autorisierungsoptionen mTLS. Sie können mTLS auf benutzerdefinierten Domains aktivieren, um sich gegen regionales REST und HTTP zu authentifizieren. APIs Anfragen können mithilfe von Bearer, JSON Web Tokens (JWTs) autorisiert oder Anfragen mit IAM-basierter Autorisierung signiert werden. 

Das folgende Diagramm zeigt den mTLS-Authentifizierungsablauf für eine Anwendung, die auf einer EC2 Instance ausgeführt wird, und für eine API, die auf Amazon API Gateway eingerichtet ist.

1. API Gateway fordert ein öffentlich vertrauenswürdiges Zertifikat direkt von AWS Certificate Manager (ACM) an.

2. ACM generiert das Zertifikat von seiner Zertifizierungsstelle (CA).

3. Der Client, der die API aufruft, legt zusammen mit der API-Anforderung ein Zertifikat vor.

4. API Gateway überprüft den Amazon S3-Trust-Store-Bucket, den Sie erstellt haben. Dieser Bucket enthält die X.509-Zertifikate, denen Sie beim Zugriff auf Ihre API vertrauen. Damit API Gateway mit der Anfrage fortfahren kann, müssen sich der Aussteller des Zertifikats und die gesamte Vertrauenskette bis hin zum Root-CA-Zertifikat in Ihrem Trust Store befinden.

5. Wenn das Zertifikat des Clients vertrauenswürdig ist, genehmigt API Gateway die Anfrage und ruft die Methode auf.

6. Die zugehörige API-Aktion (in diesem Fall eine AWS Lambda Lambda-Funktion) verarbeitet die Anfrage und gibt eine Antwort zurück, die an den Anforderer gesendet wird.

Vorteile

• M2M-Authentifizierung. Dienste authentifizieren sich gegenseitig direkt, anstatt gemeinsame Geheimnisse oder Token zu verwenden. Dadurch entfällt die Notwendigkeit, statische Anmeldeinformationen zu speichern und zu verwalten.

• Schutz vor Manipulation. Die TLS-Verschlüsselung schützt Daten bei der Übertragung zwischen Diensten. Mitteilungen können nicht von Dritten gelesen oder verändert werden. 

• Einfache Integration. Die mTLS-Unterstützung ist in die wichtigsten Programmiersprachen und Frameworks integriert. Dienste können mTLS mit minimalen Codeänderungen aktivieren. 

• Granulare Berechtigungen. Dienste vertrauen nur bestimmten Zertifikaten, was eine genaue Kontrolle über die erlaubten Anrufer ermöglicht. 

• Widerruf. Kompromittierte Zertifikate können sofort gesperrt werden, sodass sie nicht mehr vertrauenswürdig sind, wodurch weiterer Zugriff verhindert wird. 

Designüberlegungen

• Wenn Sie API Gateway verwenden:

  • Standardmäßig können Clients Ihre API aufrufen, indem sie den execute-api Endpunkt verwenden, den API Gateway für Ihre API generiert. Um sicherzustellen, dass Clients nur über einen benutzerdefinierten Domainnamen mit mTLS auf Ihre API zugreifen können, deaktivieren Sie diesen Standardendpunkt. Weitere Informationen finden Sie unter Deaktivieren des Standardendpunkts für eine REST-API in der API Gateway Gateway-Dokumentation.

  • API Gateway überprüft nicht, ob Zertifikate gesperrt wurden.

  • Um mTLS für eine REST-API zu konfigurieren, müssen Sie einen regionalen benutzerdefinierten Domainnamen für Ihre API mit einer TLS-Mindestversion von 1.2 verwenden. mTLS wird für private Anwendungen nicht unterstützt. APIs

• Sie können Zertifikate für API Gateway von Ihrer eigenen CA ausstellen oder sie von der AWS Private Certificate Authority importieren.

• Erstellen Sie Prozesse, um Servicezertifikate sicher auszustellen, zu verteilen, zu erneuern und zu widerrufen. Automatisieren Sie die Ausstellung und Verlängerung, wo immer dies möglich ist. Wenn eine Seite Ihrer M2M-Kommunikation ein API-Gateway ist, können Sie eine Integration mit AWS Private CA vornehmen.

• Schützen Sie den Zugriff auf die private CA. Wenn die CA kompromittiert wird, wird das Vertrauen in alle von ihr ausgestellten Zertifikate beeinträchtigt.

• Speichern Sie private Schlüssel sicher und getrennt von Zertifikaten. Wechseln Sie die Schlüssel regelmäßig, um die Auswirkungen zu begrenzen, falls sie kompromittiert werden.

• Widerrufen Sie Zertifikate sofort, wenn sie nicht mehr benötigt werden oder wenn sie gefährdet sind. Verteilen Sie Zertifikatssperrlisten an Dienste. 

• Stellen Sie nach Möglichkeit Zertifikate aus, die nur für bestimmte Zwecke oder Ressourcen bestimmt sind, um ihren Nutzen einzuschränken, falls sie gefährdet sind.

• Halten Sie Notfallpläne für den Ablauf von Zertifikaten und für Ausfälle der CA- oder CRL-Infrastruktur (Certificate Revocation List) bereit. 

• Überwachen Sie Ihr System auf Fehler und Ausfälle von Zertifikaten. Achten Sie auf Spitzenausfälle, die auf Probleme hinweisen könnten.

• Wenn Sie AWS Certificate Manager (ACM) mit AWS Private CA verwenden, können Sie AWS verwenden, CloudFormation um öffentliche und private Zertifikate programmgesteuert anzufordern.

• Wenn Sie ACM verwenden, verwenden Sie AWS Resource Access Manager (AWS RAM), um das Zertifikat von einem Sicherheitskonto für das Workload-Konto freizugeben.

IAM Roles Anywhere

Wir empfehlen, IAM Roles Anywhere für das M2M-Identitätsmanagement zu verwenden, wenn Maschinen oder Systeme eine Verbindung zu AWS-Services herstellen müssen, diese aber keine IAM-Rollen unterstützen. IAM Roles Anywhere ist eine Erweiterung von IAM, die eine Public-Key-Infrastruktur (PKI) verwendet, um mithilfe temporärer Sicherheitsanmeldeinformationen Zugriff auf Workloads zu gewähren. Sie können X.509-Zertifikate verwenden, die entweder von einer CA oder von AWS Private CA ausgestellt werden können, um einen Vertrauensanker zwischen der CA und IAM Roles Anywhere einzurichten. Wie bei IAM-Rollen kann der Workload auf Grundlage seiner Berechtigungsrichtlinie, die der Rolle zugewiesen ist, auf AWS-Services zugreifen. 

Das folgende Diagramm zeigt, wie Sie IAM Roles Anywhere verwenden können, um AWS mit externen Ressourcen zu verbinden.

1. Sie erstellen einen Vertrauensanker, um Vertrauen zwischen Ihrem AWS-Konto und der Zertifizierungsstelle herzustellen, die Zertifikate für Ihre lokalen Workloads ausstellt. Die Zertifikate werden von einer Zertifizierungsstelle ausgestellt, die Sie als Vertrauensanker (Vertrauensbasis) in IAM Roles Anywhere registrieren. Die CA kann Teil Ihres bestehenden Public Key Infrastructure (PKI) -Systems sein, oder es kann sich um eine CA handeln, die Sie mit AWS Private Certificate Authority erstellt und mit ACM verwaltet haben. In diesem Beispiel verwenden wir ACM.

2. Ihre Anwendung stellt eine Authentifizierungsanfrage an IAM Roles Anywhere und sendet ihren öffentlichen Schlüssel (in einem Zertifikat kodiert) sowie eine Signatur, die mit dem entsprechenden privaten Schlüssel signiert ist. Ihre Anwendung spezifiziert auch die Rolle, die in der Anfrage übernommen werden soll.

3. Wenn IAM Roles Anywhere die Anfrage empfängt, validiert es zuerst die Signatur mit dem öffentlichen Schlüssel und überprüft dann, ob das Zertifikat von einem Vertrauensanker ausgestellt wurde. Nachdem beide Validierungen erfolgreich waren, wird Ihre Anwendung authentifiziert und IAM Roles Anywhere erstellt eine neue Rollensitzung für die in der Anfrage angegebene Rolle, indem AWS Security Token Service (AWS STS) aufgerufen wird.

4. Sie verwenden das Credential Helper-Tool, das IAM Roles Anywhere bereitstellt, um den Prozess der Erstellung einer Signatur mit dem Zertifikat zu verwalten und den Endpunkt aufzurufen, um die Anmeldeinformationen für die Sitzung abzurufen. Das Tool gibt die Anmeldeinformationen in einem Standard-JSON-Format an den aufrufenden Prozess zurück.

5. Durch die Verwendung dieses Bridged-Trust-Modells zwischen IAM und PKI verwenden lokale Workloads diese temporären Anmeldeinformationen (Zugriffsschlüssel, geheimer Schlüssel und Sitzungstoken), um die IAM-Rolle für die Interaktion mit AWS-Ressourcen zu übernehmen, ohne dass langfristige Anmeldeinformationen erforderlich sind. Sie können diese Anmeldeinformationen auch mithilfe der AWS-CLI oder AWS konfigurieren SDKs.

Vorteile

• Keine dauerhaften Anmeldeinformationen. Anwendungen benötigen keine langfristigen AWS-Zugriffsschlüssel mit umfassenden Berechtigungen. 

• Fein abgestufter Zugriff. Richtlinien legen fest, welche IAM-Rolle für eine bestimmte Entität übernommen werden kann. 

• Kontextsensitive Rollen. Die Rolle kann auf der Grundlage der Details der authentifizierten Entität angepasst werden.

• Widerruf. Durch den Widerruf von Vertrauensberechtigungen wird eine Entität sofort daran gehindert, eine Rolle zu übernehmen.

Designüberlegungen

• Server müssen in der Lage sein, die zertifikatsbasierte Authentifizierung zu unterstützen. 

• Es empfiehlt sich, die zu aws:SourceArn verwendende Vertrauensrichtlinie für das Konto, aws:SourceAccount für das der Vertrauensanker konfiguriert wurde, zu sperren. 

• Principal-Tags werden aus den Zertifikatsdetails übernommen. Dazu gehören der allgemeine Name (CN), der alternative Name des Antragstellers (SAN), der Betreff und der Aussteller.

• Wenn Sie ACM verwenden, verwenden Sie AWS RAM, um das Zertifikat von einem Sicherheitskonto für das Workload-Konto freizugeben.

• Verwenden Sie die Dateisystemberechtigungen des Betriebssystems (OS), um den Lesezugriff auf den Besitzer zu beschränken.

• Checken Sie niemals Schlüssel in die Quellcodeverwaltung ein. Speichern Sie sie getrennt vom Quellcode, um das Risiko zu verringern, dass sie versehentlich in einen Änderungssatz aufgenommen werden. Erwägen Sie nach Möglichkeit die Verwendung eines sicheren Speichermechanismus.

• Stellen Sie sicher, dass Sie über ein Verfahren verfügen, mit dem Sie Zertifikate rotieren und widerrufen können.