

# SEC 9. Wie schützen Sie Ihre Daten bei der Übertragung?
<a name="sec-09"></a>

Schützen Sie Ihre Daten während der Übertragung, indem Sie mehrere Kontrollen implementieren, um das Risiko eines unbefugten Zugriffs oder Verlusts zu reduzieren.

**Topics**
+ [SEC09-BP01 Implementieren einer sicheren Schlüssel- und Zertifikatverwaltung](sec_protect_data_transit_key_cert_mgmt.md)
+ [SEC09-BP02 Erzwingen einer Verschlüsselung bei der Übertragung](sec_protect_data_transit_encrypt.md)
+ [SEC09-BP03 Automatisieren der Erkennung von unbeabsichtigtem Datenzugriff](sec_protect_data_transit_auto_unintended_access.md)
+ [SEC09-BP04 Authentifizieren der Netzwerkkommunikation](sec_protect_data_transit_authentication.md)

# SEC09-BP01 Implementieren einer sicheren Schlüssel- und Zertifikatverwaltung
<a name="sec_protect_data_transit_key_cert_mgmt"></a>

 Transport Layer Security-Zertifikate (TLS) werden verwendet, um die Netzwerkkommunikation zu sichern und die Identität von Websites, Ressourcen und Workloads über das Internet sowie in privaten Netzwerken festzulegen. 

 **Gewünschtes Ergebnis:** Ein sicheres Zertifikatverwaltungssystem, das Zertifikate in einer Public-Key-Infrastruktur (PKI) bereitstellen, speichern und verlängern kann. Ein sicherer Schlüssel- und Zertifikatsverwaltungsmechanismus verhindert die Offenlegung von Zertifikatsmaterial mit privaten Schlüsseln und erneuert das Zertifikat automatisch in regelmäßigen Abständen. Es lässt sich auch in andere Services integrieren, um eine sichere Netzwerkkommunikation und Identität für Maschinenressourcen innerhalb Ihres Workloads zu gewährleisten. Schlüsseldaten sollten niemals für menschliche Identitäten zugänglich sein. 

 **Typische Anti-Muster:** 
+  Während der Bereitstellung oder Verlängerung von Zertifikaten werden manuelle Schritte ausgeführt. 
+  Beim Entwurf einer privaten Zertifizierungsstelle (Certificate Authority, CA) wird die Hierarchie der Zertifizierungsstelle nicht ausreichend beachtet. 
+  Für öffentliche Ressourcen werden selbstsignierte Zertifikate verwendet. 

 **Vorteile der Nutzung dieser bewährten Methode: **
+  Die Zertifikatverwaltung wird durch automatisierte Bereitstellung und Verlängerung vereinfacht. 
+  Die Verschlüsselung von Daten während der Übertragung wird mithilfe von TLS-Zertifikaten gefördert. 
+  Sicherheit und Überprüfbarkeit der von der Zertifizierungsstelle ausgeführten Zertifikataktionen werden gesteigert. 
+  Verwaltungsaufgaben werden auf verschiedenen Ebenen der CA-Hierarchie angeordnet. 

 **Risikostufe bei fehlender Befolgung dieser Best Practice:** Hoch

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Moderne Workloads nutzen verschlüsselte Netzwerkkommunikation mithilfe von PKI-Protokollen wie TLS in großem Umfang. Die Verwaltung von PKI-Zertifikaten kann komplex sein, durch automatisierte Bereitstellung und Verlängerung von Zertifikaten können aber Reibungsverluste im Zusammenhang mit der Zertifikatverwaltung verringert werden. 

 AWS bietet zwei Services zur Verwaltung von allgemeinen PKI-Zertifikaten: [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) und [AWS Private Certificate Authority (AWS Private CA)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html). ACM ist der primäre Service, den Kunden für die Bereitstellung und Verwaltung von Zertifikaten sowohl für öffentliche als auch für private AWS-Workloads verwenden. ACM stellt Zertifikate mithilfe von AWS Private CA aus und [lässt sich](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) in viele andere verwaltete AWS-Services zur Bereitstellung sicherer TLS-Zertifikate für Workloads integrieren. 

 AWS Private CA ermöglicht es Ihnen, Ihre eigene Stamm- oder untergeordnete Zertifizierungsstelle einzurichten und TLS-Zertifikate über eine API auszustellen. Sie können diese Art von Zertifikaten in Szenarien verwenden, in denen Sie die Vertrauenskette auf der Clientseite der TLS-Verbindung kontrollieren und verwalten. Zusätzlich zu TLS-Anwendungsfällen kann AWS Private CA für die Ausstellung von Zertifikaten für Kubernetes-Pods, Matter-Geräteproduktbescheinigungen, Codesignaturen und andere Anwendungsfälle verwendet werden, und zwar mit einer [benutzerdefinierten Vorlage](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html). Sie können auch [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) verwenden, um temporäre IAM-Anmeldeinformationen für On-Premises-Workloads bereitzustellen, für die von Ihrer privaten CA signierte X.509-Zertifikate ausgestellt wurden. 

 Zusätzlich zu ACM und AWS Private CA bietet [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html) spezielle Unterstützung für die Bereitstellung und Verwaltung von PKI-Zertifikaten für IoT-Geräte. AWS IoT Core bietet spezielle Mechanismen für das [das groß angelegte Onboarding von IoT-Geräten](https://docs.aws.amazon.com/whitepapers/latest/device-manufacturing-provisioning/device-manufacturing-provisioning.html) in Ihre Public-Key-Infrastruktur. 

**Überlegungen zur Einrichtung einer privaten CA-Hierarchie **

 Wenn Sie eine private Zertifizierungsstelle einrichten müssen, ist es wichtig, dass Sie besonders darauf achten, die CA-Hierarchie im Voraus richtig zu entwerfen. Es hat sich bewährt, beim Erstellen einer privaten CA-Hierarchie jede Ebene der Hierarchie in separaten AWS-Konten bereitzustellen. Dieser gezielte Schritt reduziert die Oberfläche für jede Ebene in der CA-Hierarchie, wodurch es einfacher wird, Anomalien in CloudTrail-Protokolldaten zu erkennen und den Umfang des Zugriffs oder die Auswirkungen eines unbefugten Zugriffs auf eines der Konten zu reduzieren. Die Stammzertifizierungsstelle sollte sich in einem eigenen separaten Konto befinden und nur zur Ausstellung eines oder mehrerer Zertifikate für eine Zwischenzertifizierungsstelle verwendet werden. 

 Erstellen Sie dann eine oder mehrere Zwischenzertifizierungsstellen in Konten, die vom Konto der Stammzertifizierungsstelle getrennt sind, um Zertifikate für Endbenutzer, Geräte oder andere Workloads auszustellen. Stellen Sie abschließend Zertifikate von Ihrer Stammzertifizierungsstelle an die Zwischenzertifizierungsstellen aus, die wiederum Zertifikate für die Endbenutzer oder Geräte ausstellen. Weitere Informationen zur Planung Ihrer CA-Bereitstellung und zum Entwerfen einer CA-Hierarchie, einschließlich Planung von Ausfallsicherheit, regionsübergreifender Replikation, gemeinsamer Nutzung von Zertifizierungsstellen in Ihrer Organisation und mehr, finden Sie unter [Planung Ihrer AWS Private CA-Bereitstellung ](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html). 

### Implementierungsschritte
<a name="implementation-steps"></a>

1.  Ermitteln Sie die relevanten AWS-Services, die für Ihren Anwendungsfall erforderlich sind: 
   +  Viele Anwendungsfälle können die bestehende Public-Key-Infrastruktur von AWS mithilfe von [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)nutzen. ACM kann zur Bereitstellung von TLS-Zertifikaten für Webserver, Load Balancer oder für andere Zwecke für öffentlich vertrauenswürdige Zertifikate verwendet werden. 
   +  Erwägen Sie die [AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) , wenn Sie Ihre eigene private Zertifizierungsstellenhierarchie einrichten müssen oder Zugriff auf exportierbare Zertifikate benötigen. Mit ACM können dann [viele Arten von Endentitätszertifikaten](https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html) mit dem AWS Private CA ausgegeben werden. 
   +  Für Anwendungsfälle, in denen Zertifikate für eingebettete Geräte des Internet der Dinge (IoT) in großem Umfang bereitgestellt werden müssen, erwägen Sie den Einsatz von [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html). 

1.  Implementieren Sie nach Möglichkeit eine automatische Zertifikatsverlängerung: 
   +  Verwenden Sie [ACM verwaltete Verlängerung](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) für Zertifikate, die von ACM zusammen mit integrierten AWS Managed Services ausgestellt wurden. 

1.  Richten Sie die Sie Protokollierung und Prüfpfade ein: 
   +  Aktivieren Sie [CloudTrail-Protokolle,](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html) um Zugriff auf die Konten zu verfolgen, die Zertifizierungsstellen enthalten. Erwägen Sie, die Integritätsprüfung der Protokolldatei in CloudTrail zu konfigurieren, um die Authentizität der Protokolldaten zu überprüfen. 
   +  Generieren und überprüfen Sie regelmäßig [Auditberichte,](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html) in denen die Zertifikate aufgeführt werden, die Ihre private CA ausgestellt oder widerrufen hat. Diese Berichte können in einen S3-Bucket exportiert werden. 
   +  Wenn Sie eine private CA bereitstellen, müssen Sie auch einen S3-Bucket einrichten, um die CRL (Certificate Revocation List, Zertifikatssperrliste) zu speichern. Anleitungen zur Konfiguration dieses S3-Buckets basierend auf den Anforderungen Ihres Workloads finden Sie unter [Planung einer Zertifikatssperrliste (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html). 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+  [SEC02-BP02 Verwenden von temporären Anmeldeinformationen](sec_identities_unique.md) 
+ [SEC08-BP01: Implementieren einer sicheren Schlüsselverwaltung](sec_protect_data_rest_key_mgmt.md)
+  [SEC09-BP04 Authentifizieren der Netzwerkkommunikation](sec_protect_data_transit_authentication.md) 

 **Zugehörige Dokumente:** 
+  [Hosten und Verwalten einer ganzen privaten Zertifikatinfrastruktur in AWS](https://aws.amazon.com/blogs/security/how-to-host-and-manage-an-entire-private-certificate-infrastructure-in-aws/) 
+  [Sichern einer ACM Private CA-Hierarchie auf Unternehmensebene für die Automobil- und Produktionsbranche](https://aws.amazon.com/blogs/security/how-to-secure-an-enterprise-scale-acm-private-ca-hierarchy-for-automotive-and-manufacturing/) 
+  [Bewährte Private-CA-Methoden](https://docs.aws.amazon.com/privateca/latest/userguide/ca-best-practices.html) 
+  [So verwenden Sie AWS RAM, um Ihre ACM Private CA kontoübergreifend zu teilen](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/) 

 **Zugehörige Videos:** 
+  [Aktivieren von AWS Certificate Manager Certificate Manager Private CA (Workshop)](https://www.youtube.com/watch?v=XrrdyplT3PE) 

 **Zugehörige Beispiele:** 
+  [Private CA-Workshop](https://catalog.workshops.aws/certificatemanager/en-US/introduction) 
+  [Workshop zur IOT-Geräteverwaltung](https://iot-device-management.workshop.aws/en/) (einschließlich der Gerätebereitstellung) 

 **Zugehörige Tools:** 
+  [Plugin für Kubernetes-Zertifikatmanager für die Verwendung von AWS Private CA](https://github.com/cert-manager/aws-privateca-issuer) 

# SEC09-BP02 Erzwingen einer Verschlüsselung bei der Übertragung
<a name="sec_protect_data_transit_encrypt"></a>

Erzwingen Sie Ihre definierten Verschlüsselungsanforderungen basierend auf den Richtlinien, regulatorischen Verpflichtungen und Standards Ihrer Organisation, damit Sie Ihre Unternehmens-, Rechts- und Compliance-Anforderungen erfüllen können. Verwenden Sie nur Protokolle mit Verschlüsselung, wenn Sie vertrauliche Daten außerhalb Ihrer Virtual Private Cloud (VPC) übertragen. Verschlüsselung hilft bei der Wahrung der Datenvertraulichkeit auch dann, wenn die Daten nicht vertrauenswürdige Netzwerke durchqueren.

 **Gewünschtes Ergebnis:** Alle Daten sollten während der Übertragung mithilfe von sicheren TLS-Protokollen und Verschlüsselungssammlungen verschlüsselt werden. Der Netzwerkverkehr zwischen Ihren Ressourcen und dem Internet muss verschlüsselt werden, um nicht autorisierten Zugriff auf die Daten zu verhindern. Nur der Netzwerkverkehr in Ihrer internen AWS-Umgebung sollte wenn möglich mit TLS verschlüsselt werden. Das interne AWS-Netzwerk ist standardmäßig verschlüsselt und der Netzwerkverkehr innerhalb einer VPC kann nicht manipuliert oder analysiert werden, es sei denn, eine unbefugte Partei hat sich Zugang zu der Ressource verschafft, die den Datenverkehr generiert (wie beispielsweise Amazon EC2-Instances und Amazon ECS-Container). Überlegen Sie, ob Sie den Netzwerk-zu-Netzwerk-Datenverkehr mit einem IPsec Virtual Private Network (VPN) schützen sollten. 

 **Typische Anti-Muster:** 
+  Verwendung veralteter Versionen von SSL, TLS und Komponenten von Verschlüsselungssammlungen (z. B. SSL v3.0, RSA-Schlüssel mit 1 024 Bit und RC4-Verschlüsselung) 
+  Zulassen von unverschlüsseltem (HTTP-)Datenverkehr zu oder von öffentlich zugänglichen Ressourcen 
+  keine Überwachung und kein Ersatz von X.509-Zertifikaten, bevor sie ablaufen 
+  Verwendung von selbstsignierten X.509-Zertifikaten für TLS 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** hoch 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 AWS-Services bieten HTTPS-Endpunkte, die für die Kommunikation TLS nutzen. Dadurch werden die Daten bei der Kommunikation mit den AWS-APIs während der Übertragung verschlüsselt. Unsichere Protokolle wie HTTP können in einer VPC durch die Verwendung von Sicherheitsgruppen überprüft und blockiert werden. HTTP-Anfragen können in Amazon CloudFront oder einem [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#redirect-actions) auch [automatisch an HTTPS umgeleitet](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html) werden. Sie haben uneingeschränkte Kontrolle über Ihre Datenverarbeitungsressourcen und können die Verschlüsselung während der Übertragung in alle Ihre Services implementieren. Darüber hinaus können Sie die VPN-Konnektivität mit Ihrer VPC von einem externen Netzwerk oder [AWS Direct Connect](https://aws.amazon.com/directconnect/) aus verwenden, um die Verschlüsselung des Datenverkehrs zu erleichtern. Stellen Sie sicher, dass Ihre Kunden AWS-API-Aufrufe mindestens mit TLS 1.2 tätigen, da [AWS die Verwendung von TLS 1.0 und 1.1 im Juni 2023 einstellt](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/). Sollten Sie besondere Anforderungen haben, finden Sie Lösungen von Drittanbietern im AWS Marketplace. 

 **Implementierungsschritte** 
+  **Erzwingen der Verschlüsselung bei der Übertragung:** Die definierten Verschlüsselungsanforderungen sollten sich nach den neuesten Standards und bewährten Methoden richten und nur sichere Protokolle zulassen. Konfigurieren Sie beispielsweise eine Sicherheitsgruppe, die nur das HTTPS-Protokoll für einen Application Load Balancer oder eine Amazon EC2-Instance zulässt. 
+  **Konfigurieren von sicheren Protokollen bei Edge-Services:** [Konfigurieren Sie HTTPS mit Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html) und verwenden Sie ein [für Ihren Sicherheitsstatus und Ihren Anwendungsfall geeignetes Sicherheitsprofil](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html#secure-connections-supported-ciphers). 
+  **Verwenden eines [VPN für die externe Konnektivität](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html):** Ziehen Sie ein IPsec-VPN in Betracht, um Punkt-zu-Punkt- oder Netzwerk-zu-Netzwerk-Verbindungen zu sichern und so den Datenschutz und die Datenintegrität zu gewährleisten. 
+  **Konfigurieren von sicheren Protokollen bei Load Balancern:** Wählen Sie eine Sicherheitsrichtlinie aus, die die stärksten Verschlüsselungssammlungen bereitstellt, die von den Clients unterstützt werden, die eine Verbindung mit dem Listener herstellen. [Erstellen Sie einen HTTPS-Listener für Ihren Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html). 
+  **Konfigurieren von sicheren Protokollen in Amazon Redshift:** Konfigurieren Sie Ihren Cluster so, dass eine [Verbindung über Secure Socket Layer (SSL) or Transport Layer Security (TLS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) vorgeschrieben ist. 
+  **Konfigurieren von sicheren Protokollen:** Sehen Sie sich die AWS-Servicedokumentation an, um die Funktionen zur Verschlüsselung während der Übertragung zu bestimmen. 
+  **Konfigurieren von sicherem Zugriff beim Hochladen in Amazon S3-Buckets:** Verwenden Sie die Richtlinienkontrolle für Amazon S3-Buckets, um [sicheren Zugriff](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) auf Daten zu erzwingen. 
+  **Erwägen der Verwendung von [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/):** ACM ermöglicht das Bereitstellen und Verwalten von öffentlichen TLS-Zertifikaten zur Verwendung mit AWS-Services. 
+  **Erwägen der Verwendung von [AWS Private Certificate Authority](https://aws.amazon.com/private-ca/) für private PKI-Anforderungen:** AWS Private CA ermöglicht das Erstellen privater Zertifizierungsstellenhierarchien, um X.509-Endentitätszertifikate auszustellen, die zum Erstellen verschlüsselter TLS-Kanäle verwendet werden können. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige Dokumente:** 
+ [ Dokumentation zu AWS](https://docs.aws.amazon.com/index.html)
+ [ Verwenden von HTTPS mit CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html)
+ [ Verbinden Ihrer VPC mit Remote-Netzwerken über AWS Virtual Private Network](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html)
+ [ Create an HTTPS listener for your Application Load Balancer ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)(Erstellen eines HTTPS-Listeners für Ihren Application Load Balancer)
+ [ Tutorial: SSL/TLS unter Amazon Linux 2 konfigurieren ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html)
+ [Verwenden von SSL/TLS für die Verschlüsselung einer Verbindung zu einer DB-Instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html)
+ [Konfigurieren von Sicherheitsoptionen für Verbindungen ](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html)

# SEC09-BP03 Automatisieren der Erkennung von unbeabsichtigtem Datenzugriff
<a name="sec_protect_data_transit_auto_unintended_access"></a>

 Verwenden Sie Tools wie Amazon GuardDuty zum automatischen Erkennen von verdächtigen Aktivitäten oder Versuchen, Daten außerhalb definierter Grenzen zu verschieben. GuardDuty kann beispielsweise ungewöhnliche Amazon Simple Storage Service (Amazon S3)-Leseaktivitäten erkennen. Verwendet wird dafür [Exfiltration:S3/AnomalousBehavior](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-s3.html#exfiltration-s3-objectreadunusual). Zusätzlich zu GuardDuty können auch [Amazon VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html), die die Netzwerkverkehrsinformationen erfassen, zusammen mit Amazon EventBridge verwendet werden, um die Erkennung anormaler Verbindungen – sowohl erfolgreich als auch abgelehnt – zu berichten. [Mit Amazon S3 Access Analyzer](http://aws.amazon.com/blogs/storage/protect-amazon-s3-buckets-using-access-analyzer-for-s3) können Sie ermitteln, welche Daten für wen in Ihren Amazon S3-Buckets zugänglich sind. 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>
+  Automatisieren der Erkennung von unbefugtem Datenzugriff: Setzen Sie Tools oder Erkennungsmechanismen ein, die automatisch erkennen, wenn versucht wird, Daten außerhalb festgelegter Grenzen zu verschieben. Damit lässt sich beispielsweise ein Datenbanksystem erkennen, das Daten auf einen unbekannten Host kopiert. 
  + [ VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 
+  Erwägen von Amazon Macie: Amazon Macie ist ein vollständig verwalteter Service für Datensicherheit und Datenschutz, der mithilfe von Machine Learning und Mustervergleichen Ihre sensiblen Daten in AWS erkennt und schützt. 
  + [ Amazon Macie ](https://aws.amazon.com/macie/)

## Ressourcen
<a name="resources"></a>

 **Ähnliche Dokumente:** 
+ [ VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 
+ [ Amazon Macie ](https://aws.amazon.com/macie/)

# SEC09-BP04 Authentifizieren der Netzwerkkommunikation
<a name="sec_protect_data_transit_authentication"></a>

 Überprüfen Sie die Identität der Kommunikation mithilfe von Protokollen, die die Authentifizierung unterstützen, wie Transport Layer Security (TLS) oder IPsec. 

 Entwerfen Sie Ihren Workload so, dass bei der Kommunikation zwischen Services, Anwendungen oder Benutzern sichere, authentifizierte Netzwerkprotokolle verwendet werden. Die Verwendung von Netzwerkprotokollen, die Authentifizierung und Autorisierung unterstützen, bietet eine strengere Kontrolle über den Netzwerkfluss und reduziert die Auswirkungen von nicht autorisiertem Zugriff. 

 **Gewünschtes Ergebnis: ** Ein Workload mit klar definierten Datenflüssen auf der Daten- und Steuerebene zwischen den Services. Die Datenflüsse verwenden authentifizierte und verschlüsselte Netzwerkprotokolle, sofern dies technisch möglich ist. 

 **Typische Anti-Muster:** 
+  Unverschlüsselte oder unauthentifizierte Datenflüsse innerhalb Ihres Workloads 
+  Wiederverwendung von Authentifizierungsdaten für mehrere Benutzer oder Entitäten 
+  Die alleinige Verwendung von Netzwerkkontrollen als Zugriffskontrolle 
+  Erstellen eines benutzerdefinierten Authentifizierungsmechanismus, anstatt sich auf die Standard-Authentifizierungsmechanismen der Branche zu verlassen 
+  Übermäßig freizügige Datenflüsse zwischen Servicekomponenten oder anderen Ressourcen in der VPC 

 **Vorteile der Nutzung dieser bewährten Methode:** 
+  Schränkt den Umfang der Auswirkungen eines unberechtigten Zugriffs auf einen Teil des Workloads ein 
+  Bietet ein höheres Maß an Sicherheit, dass Aktionen nur von authentifizierten Personen durchgeführt werden können 
+  Verbessert die Entkopplung von Diensten, indem die vorgesehenen Schnittstellen für die Datenübertragung klar definiert und durchgesetzt werden 
+  Verbessert die Überwachung, Protokollierung und Reaktion auf Vorfälle durch die Zuordnung von Anfragen und gut definierte Kommunikationsschnittstellen 
+  Bietet durch die Kombination von Netzwerkkontrollen mit Authentifizierungs- und Autorisierungskontrollen einen umfassenden Schutz für Ihre Workloads 

 **Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** niedrig 

## Implementierungsleitfaden
<a name="implementation-guidance"></a>

 Die Netzwerkverkehrsmuster Ihres Workloads lassen sich in zwei Kategorien einteilen: 
+  Der *Ost-West-Verkehr* steht für Datenflüsse zwischen Services, die einen Workload ausmachen. 
+  Der *Nord-Süd-Verkehr* stellt die Datenflüsse zwischen Ihrem Workload und den Verbrauchern dar. 

 Während es üblich ist, den Nord-Süd-Verkehr zu verschlüsseln, ist die Sicherung des Ost-West-Verkehrs mit authentifizierten Protokollen weniger verbreitet. Moderne Sicherheitspraktiken empfehlen, dass das Netzwerkdesign allein noch keine vertrauenswürdige Beziehung zwischen zwei Entitäten gewährleistet. Auch wenn sich zwei Services innerhalb einer gemeinsamen Netzwerkgrenze befinden, ist es immer noch die beste Methode, die Kommunikation zwischen diesen Services zu verschlüsseln, zu authentifizieren und zu autorisieren. 

 Beispielsweise verwenden AWS-Service-APIs das Signaturprotokoll [AWS Signature Version 4 (SigV4)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html), um den Anforderer zu authentifizieren, unabhängig davon, aus welchem Netzwerk die Anfrage stammt. Diese Authentifizierung stellt sicher, dass AWS-APIs die Identität des Anforderers der Aktion überprüfen können. Diese Identität kann dann mit Richtlinien kombiniert werden, um eine Autorisierungsentscheidung zu treffen, ob die Aktion erlaubt werden soll oder nicht. 

 Mit Services wie [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/access-management-overview.html) und [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) können Sie das gleiche SigV4-Signaturprotokoll verwenden, um den Ost-West-Verkehr in Ihren eigenen Workloads zu authentifizieren und zu autorisieren. Wenn Ressourcen außerhalb Ihrer AWS-Umgebung mit Services kommunizieren müssen, die eine SigV4-basierte Authentifizierung und Autorisierung erfordern, können Sie [AWS Identity and Access Management (IAM) Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) auf der AWS-fremden Ressource verwenden, um temporäre AWS-Anmeldeinformationen zu erhalten. Diese Anmeldeinformationen können verwendet werden, um Anfragen an Services zu signieren, die mit SigV4 den Zugriff autorisieren. 

 Ein weiterer gängiger Mechanismus zur Authentifizierung des Ost-West-Verkehrs ist die gegenseitige TLS-Authentifizierung (mTLS). Viele Internet der Dinge (IoT)- und Business-to-Business-Anwendungen sowie Microservices verwenden mTLS, um die Identität beider Seiten einer TLS-Kommunikation durch die Verwendung von X.509-Zertifikaten auf Client- und Server-Seite zu validieren. Diese Zertifikate können von AWS Private Certificate Authority (AWS Private CA) ausgestellt werden. Sie können Services wie [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) und [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html) verwenden, um die mTLS-Authentifizierung für die Kommunikation zwischen oder innerhalb eines Workloads bereitzustellen. Während mTLS Authentifizierungsinformationen für beide Seiten einer TLS-Kommunikation bereitstellt, bietet es keinen Mechanismus zur Autorisierung. 

 Die Protokolle OAuth 2.0 und OpenID Connect (OIDC) schließlich werden in der Regel für die Kontrolle des Zugriffs von Benutzern auf Services verwendet, erfreuen sich aber inzwischen auch für den Datenverkehr zwischen Services zunehmender Beliebtheit. API Gateway bietet einen [JSON Web Token (JWT)-Genehmiger](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html), mit dem Workloads den Zugriff auf API-Routen mithilfe von JWTs beschränken können, die von OIDC- oder OAuth 2.0-Identitätsanbietern ausgestellt werden. OAuth2-Bereiche können als Quelle für grundlegende Autorisierungsentscheidungen verwendet werden, aber die Autorisierungsprüfungen müssen immer noch in der Anwendungsschicht implementiert werden. Und OAuth2-Bereiche allein können komplexere Autorisierungsanforderungen nicht unterstützen. 

### Implementierungsschritte
<a name="implementation-steps"></a>
+  **Definieren und Dokumentieren der Netzwerkflüsse Ihres Workloads:** Der erste Schritt bei der Implementierung einer umfassenden Verteidigungsstrategie ist die Definition der Datenflüsse Ihres Workloads. 
  +  Erstellen Sie ein Datenflussdiagramm, das klar definiert, wie Daten zwischen den verschiedenen Services, aus denen Ihr Workload besteht, übertragen werden. Dieses Diagramm ist der erste Schritt zur Durchsetzung dieser Datenflüsse über authentifizierte Netzwerkkanäle. 
  +  Nutzen Sie Ihre Workloads in der Entwicklungs- und Testphase, um zu überprüfen, ob das Datenflussdiagramm das Verhalten der Workloads zur Laufzeit korrekt wiedergibt. 
  +  Ein Datenflussdiagramm kann auch bei der Durchführung einer Bedrohungsmodellierung nützlich sein, wie in [SEC01-BP07 Identifizierung von Bedrohungen und Priorisierung von Abhilfemaßnahmen unter Verwendung eines Bedrohungsmodells](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html) beschrieben. 
+  **Einrichten von Netzwerkkontrollen:** Erwägen Sie AWS-Funktionen, um Netzwerkkontrollen einzurichten, die auf Ihre Datenflüsse abgestimmt sind. Netzwerkgrenzen sollten zwar nicht die einzige Sicherheitskontrolle sein, aber sie stellen eine Stufe der umfassenden Verteidigungsstrategie zum Schutz Ihres Workloads dar. 
  +  Verwenden Sie [Sicherheitsgruppen](https://docs.aws.amazon.com/vpc/latest/userguide/security-groups.html), um den Datenfluss zwischen Ressourcen zu definieren und einzuschränken. 
  +  Verwenden Sie [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html), um sowohl mit AWS als auch mit Drittanbieterservices zu kommunizieren, die AWS PrivateLink unterstützen. Daten, die über einen AWS PrivateLink-Schnittstellen-Endpunkt gesendet werden, bleiben innerhalb des AWS-Netzwerk-Backbones und durchlaufen nicht das öffentliche Internet. 
+  **Implementieren von Authentifizierung und Autorisierung für alle Services in Ihrem Workload:** Wählen Sie die AWS-Services aus, die am besten geeignet sind, um authentifizierte, verschlüsselte Datenflüsse in Ihrem Workload bereitzustellen. 
  +  Erwägen Sie [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html), um die serviceübergreifende Kommunikation zu sichern. VPC Lattice kann die [SigV4-Authentifizierung in Kombination mit Authentifizierungsrichtlinien](https://docs.aws.amazon.com/vpc-lattice/latest/ug/auth-policies.html) verwenden, um den Zugriff von Service zu Service zu kontrollieren. 
  +  Für die serviceübergreifende Kommunikation mit mTLS sollten Sie [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) oder [App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html) in Betracht ziehen. [AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) kann verwendet werden, um eine private CA-Hierarchie einzurichten, die Zertifikate für die Verwendung mit mTLS ausstellen kann. 
  +  Bei der Integration mit Services, die OAuth 2.0 oder OIDC verwenden, sollten Sie den [API GatewayJWT-Genehmiger](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html) verwenden. 
  +  Für die Kommunikation zwischen Ihrem Workload und IoT-Geräten sollten Sie [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html) in Betracht ziehen, das mehrere Optionen für die Verschlüsselung und Authentifizierung des Netzwerkverkehrs bietet. 
+  **Überwachung auf nicht autorisierten Zugriff:** Überwachen Sie kontinuierlich unbeabsichtigte Kommunikationskanäle, nicht autorisierte Auftraggeber, die versuchen, auf geschützte Ressourcen zuzugreifen, und andere unzulässige Zugriffsmuster. 
  +  Wenn Sie VPC Lattice zur Verwaltung des Zugriffs auf Ihre Services verwenden, sollten Sie die Zugriffsprotokolle von [VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-access-logs.html) aktivieren und überwachen. Diese Zugriffsprotokolle enthalten Informationen über die anfragende Entität, Netzwerkinformationen einschließlich Quell- und Ziel-VPC und Metadaten der Anfrage. 
  +  Erwägen Sie die Aktivierung von [VPC Flow-Protokollen](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html), um Metadaten zu Netzwerkflüssen zu erfassen und regelmäßig auf Anomalien zu überprüfen. 
  +  Weitere Hinweise zum Planen, Simulieren und Reagieren auf Sicherheitsvorfälle finden Sie in der [AWS-Sicherheits- und Vorfallreaktionsanleitung](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) und im [Vorfallreaktionsabschnitt](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) der Sicherheitssäule des AWS-Well-Architected-Framework. 

## Ressourcen
<a name="resources"></a>

 **Zugehörige bewährte Methoden:** 
+ [SEC03-BP07 Analysieren des öffentlichen und kontoübergreifenden Zugriffs](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC02-BP02 Verwenden von temporären Anmeldeinformationen](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC01-BP07 Identifizieren von Bedrohungen und Priorisieren von Abhilfemaßnahmen unter Verwendung eines Bedrohungsmodells](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)

 **Zugehörige Dokumente:** 
+ [ Evaluating access control methods to secure Amazon API Gateway APIs ](https://aws.amazon.com/blogs/compute/evaluating-access-control-methods-to-secure-amazon-api-gateway-apis/)(Evaluierung von Zugriffskontrollmethoden zur Sicherung von Amazon API Gateway-APIs)
+ [ Konfiguration der gegenseitigen TLS-Authentifizierung für eine REST-API ](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html)
+ [ How to secure API Gateway HTTP endpoints with JWT authorizer ](https://aws.amazon.com/blogs/security/how-to-secure-api-gateway-http-endpoints-with-jwt-authorizer/)(So sichern Sie API Gateway-HTTP-Endpunkte mit dem JWT-Genehmiger)
+ [ Authorizing direct calls to AWS services using AWS IoT Core credential provider ](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)(Autorisieren von direkten Aufrufen von AWS-Services mithilfe des AWS IoT Core-Anbieters von Anmeldeinformationen)
+ [AWS-Sicherheits- und Vorfallreaktionsanleitung ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)

 **Zugehörige Videos:** 
+ [AWS re:invent 2022: Introducing VPC Lattice ](https://www.youtube.com/watch?v=fRjD1JI0H5w)(AWS re:invent 2022: Einführung in VPC Lattice)
+ [AWS re:invent 2020: Serverless API authentication for HTTP APIs on AWS](https://www.youtube.com/watch?v=AW4kvUkUKZ0)(Serverless-API-Authentifizierung für HTTP-APIs in AWS)

 **Zugehörige Beispiele:** 
+ [ Amazon VPC Lattice-Workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US)
+ [ Zero-Trust Episode 1 – The Phantom Service Perimeter workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/dc413216-deab-4371-9e4a-879a4f14233d/en-US)(Workshop zum Phantomdienst „Perimeter“)