# Schützen von Daten während der Übertragung
Unter *Daten während der Übertragung* verstehen wir alle Daten, die von einem System an ein anderes gesendet werden. Hierzu zählt auch die Kommunikation zwischen Ressourcen innerhalb Ihrer Workload sowie zwischen anderen Services und Ihren Endbenutzern. Durch geeigneten Schutz Ihrer Daten während der Übertragung stellen Sie die Integrität und Vertraulichkeit der Daten Ihrer Anwendungen sicher.
**Sichern von Daten zwischen VPC oder On-Premises-Standorten:** Sie können [AWS PrivateLink](https://aws.amazon.com/privatelink/) verwenden, um eine sichere und private Netzwerkverbindung zwischen Amazon Virtual Private Cloud (Amazon VPC) oder einer On-Premises-Verbindung zu Services zu schaffen, die in AWS gehostet werden. Sie können auf AWS-Services, Services von Drittanbietern und Services in anderen AWS-Konten so zugreifen, als befänden sie sich in Ihrem privaten Netzwerk. Mit AWS PrivateLink können Sie auf Services über Konten mit sich überschneidenden IP-CIDRs zugreifen, ohne ein Internet-Gateway oder NAT zu benötigen. Sie müssen auch keine Firewall-Regeln, Pfaddefinitionen oder Routing-Tabellen konfigurieren. Der Datenverkehr verbleibt auf dem Amazon-Backbone und wird nicht über das Internet geleitet, so dass Ihre Daten geschützt sind. Sie können branchenspezifische Compliance-Vorschriften wie HIPAA und EU/US Privacy Shield einhalten. AWS PrivateLink arbeitet nahtlos mit Lösungen von Drittanbietern zusammen, um ein vereinfachtes globales Netzwerk zu schaffen, das es Ihnen ermöglicht, Ihre Migration in die Cloud zu beschleunigen und die verfügbaren AWS-Services zu nutzen.
**Topics**
+ [SEC09-BP01 Implementieren einer sicheren Schlüssel- und Zertifikatverwaltung](sec_protect_data_transit_key_cert_mgmt.md)
+ [SEC09-BP02 Erzwingen von Verschlüsselung bei der Übertragung](sec_protect_data_transit_encrypt.md)
+ [SEC09-BP03 Authentifizieren der Netzwerkkommunikation](sec_protect_data_transit_authentication.md)
# SEC09-BP01 Implementieren einer sicheren Schlüssel- und Zertifikatverwaltung
Transport Layer Security (TLS)-Zertifikate werden verwendet, um die Netzwerkkommunikation zu schützen und die Identität von Websites, Ressourcen und Workloads über das Internet sowie in privaten Netzwerken zu bestimmen.
**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 Zertifikatverwaltungsmechanismus verhindert die Offenlegung von Zertifikatdaten mit privaten Schlüsseln und erneuert das Zertifikat automatisch in regelmäßigen Abständen. Er lässt sich auch in andere Services integrieren, um eine sichere Netzwerkkommunikation und Identität für Computerressourcen innerhalb Ihrer Workload 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 Entwerfen 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 mit TLS-Zertifikaten wird gefördert.
+ Sicherheit und Überprüfbarkeit der von der Zertifizierungsstelle ausgeführten Zertifikataktionen werden gesteigert.
+ Verwaltungsaufgaben werden auf verschiedenen Ebenen der CA-Hierarchie strukturiert.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Moderne Workloads nutzen verschlüsselte Netzwerkkommunikation mithilfe von PKI-Protokollen wie TLS in großem Umfang. Die Verwaltung von PKI-Zertifikaten kann komplex sein. Eine automatisierte Bereitstellung und Verlängerung von Zertifikaten kann jedoch zu einer reibungsloseren Zertifikatverwaltung beitragen.
AWS bietet zwei Services zur Verwaltung universeller PKI-Zertifikate: [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 mithilfe von AWS Private CA private Zertifikate aus und kann in viele andere verwaltete AWS-Services [integriert](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) werden, um sichere TLS-Zertifikate für Workloads bereitzustellen. ACM kann auch über [Amazon Trust Services](https://www.amazontrust.com/repository/) öffentlich vertrauenswürdige Zertifikate ausstellen. Öffentliche AVM-Zertifikate können für öffentlich zugängliche Workloads verwendet werden, da moderne Browser und Betriebssysteme diesen Zertifikaten standardmäßig vertrauen.
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 steuern 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 [Onboarding von IoT-Geräten](https://docs.aws.amazon.com/whitepapers/latest/device-manufacturing-provisioning/device-manufacturing-provisioning.html) in Ihre Public-Key-Infrastruktur in großem Umfang.
Einige AWS-Services, wie [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) und [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html), bieten eigene Funktionen für die Verwendung von Zertifikaten zum Schutz von Anwendungsverbindungen. Sowohl API Gateway als auch Application Load Balancer (ALB) unterstützen beispielsweise Mutual TLS (mTLS) über Client-Zertifikate, die Sie über die AWS-Managementkonsole, die CLI oder APIs erstellen und exportieren.
**Ü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 [Planen Ihrer AWS Private CA-Bereitstellung](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html).
### Implementierungsschritte
1. Ermitteln Sie die relevanten AWS-Services, die für Ihren Anwendungsfall erforderlich sind:
+ In vielen Anwendungsfällen kann die bestehende Public-Key-Infrastruktur von AWS mithilfe von [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) genutzt werden. 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.
+ Ziehen Sie die Verwendung von [AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) in Betracht, 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) unter Verwendung der AWS Private CA ausgegeben werden.
+ Für Anwendungsfälle, in denen in großem Umfang Zertifikate für eingebettete IoT-Geräte (Internet of Things, Internet der Dinge) bereitgestellt werden müssen, empfiehlt sich gegebenenfalls die Verwendung von [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html).
+ Ziehen Sie die Verwendung nativer mTLS-Funktionen in Services wie [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) oder [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) in Betracht.
1. Implementieren Sie nach Möglichkeit eine automatisierte Zertifikatverlängerung:
+ Verwenden Sie die [von ACM verwaltete Verlängerung](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) für von ACM ausgestellte Zertifikate zusammen mit integrierten verwalteten AWS-Services.
1. Richten Sie Protokollierung und Audit Trails ein:
+ Aktivieren Sie [CloudTrail-Protokolle](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html), um Zugriffe 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, Zertifikatsperrliste) zu speichern. Anleitungen zur Konfiguration dieses S3-Buckets basierend auf den Anforderungen Ihrer Workload finden Sie unter [Planung einer Zertifikatsperrliste (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html).
## Ressourcen
**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-BP03 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 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 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 von Verschlüsselung bei der Übertragung
Erzwingen Sie Ihre definierten Verschlüsselungsanforderungen basierend auf den Richtlinien, regulatorischen Verpflichtungen und Standards Ihrer Organisation, damit Sie Ihre Organisations-, 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 trägt auch dann zur Wahrung der Datenvertraulichkeit bei, wenn die Daten nicht vertrauenswürdige Netzwerke durchqueren.
**Gewünschtes Ergebnis:** Sie verschlüsseln den Netzwerkdatenverkehr zwischen Ihren Ressourcen und dem Internet, um nicht autorisierten Zugriff auf die Daten zu verhindern. Sie verschlüsseln den Netzwerkverkehr in Ihrer internen AWS-Umgebung entsprechend Ihren Sicherheitsanforderungen. Sie verschlüsseln Daten während der Übertragung mit sicheren TLS-Protokollen und Cipher Suites.
**Typische Anti-Muster:**
+ Verwendung veralteter Versionen von SSL, TLS und Komponenten von Verschlüsselungssammlungen (zum Beispiel SSL v3.0, RSA-Schlüssel mit 1024 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 selbstsignierter X.509-Zertifikate für TLS
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
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 HTTP-Protokolle können in einer Virtual Private Cloud (VPC) durch die Verwendung von Sicherheitsgruppen überprüft und blockiert werden. HTTP-Anforderungen können auch [automatisch an HTTPS umgeleitet werden](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html) (in Amazon CloudFront oder in einem [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#redirect-actions)). Sie können eine [Bucket-Richtlinie von Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/blogs/storage/enforcing-encryption-in-transit-with-tls1-2-or-higher-with-amazon-s3/) verwenden, um die Fähigkeit zum Hochladen von Objekten über HTTP einzuschränken und so die Verwendung von HTTPS für Objekt-Uploads in Ihren Buckets durchzusetzen. Sie haben uneingeschränkte Kontrolle über Ihre Datenverarbeitungsressourcen und können die Verschlüsselung während der Übertragung in allen Ihren Services implementieren. Darüber hinaus können Sie die VPN-Konnektivität mit Ihrer VPC von einem externen Netzwerk oder von [AWS Direct Connect](https://aws.amazon.com/directconnect/) aus verwenden, um die Verschlüsselung des Datenverkehrs zu erleichtern. Vergewissern Sie sich, dass Ihre Clients bei Aufruffen von AWS-APIs mindestens TLS 1.2 verwenden, da [AWS die Verwendung älterer TLS-Versionen im Februar 2024 eingestellt hat](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/). Wir empfehlen Ihnen, TLS 1.3 zu verwenden. Wenn Sie besondere Anforderungen an die Verschlüsselung während der Übertragung stellen, finden Sie im AWS Marketplace Informationen zu verfügbaren Lösungen von Drittanbietern.
### 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 in 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 externe Konnektivität](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html):** Verwenden Sie gegebenenfalls ein IPsec-VPN, um Punkt-zu-Punkt- oder Netzwerk-zu-Netzwerk-Verbindungen zu schützen und so Datenschutz und 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 bei Amazon Redshift:** Konfigurieren Sie Ihren Cluster so, dass eine [Verbindung über Secure Socket Layer (SSL) oder Transport Layer Security (TLS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) verwendet werden muss.
+ **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 Richtliniensteuerung für Amazon-S3-Buckets, um [sicheren Zugriff auf Daten zu erzwingen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html).
+ **Erwägen der Verwendung von [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/):** ACM ermöglicht die Bereitstellung und Verwaltung öffentlicher TLS-Zertifikate für die 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 die Erstellung privater Zertifizierungsstellenhierarchien, um X.509-Endentitätszertifikate auszustellen, die zum Erstellen verschlüsselter TLS-Kanäle verwendet werden können.
## Ressourcen
**Zugehörige Dokumente:**
+ [ 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)
+ [ Erstellen eines HTTPS-Listeners für Ihren Application Load Balancer ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)
+ [ 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 Authentifizieren der Netzwerkkommunikation
Überprüfen Sie die Kommunikationsidentität mithilfe von Protokollen mit Authentifizierungsunterstützung – beispielsweise Transport Layer Security (TLS) oder IPsec.
Gestalten Sie Ihre 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, ermöglicht eine bessere Kontrolle des Netzwerkflusses und reduziert die Auswirkungen von nicht autorisiertem Zugriff.
**Gewünschtes Ergebnis:** Eine Workload mit klar definierten Datenflüssen auf Daten- und Steuerebene zwischen 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 Ihrer Workload
+ Wiederverwendung von Authentifizierungsdaten für mehrere Benutzer oder Entitäten
+ alleinige Verwendung von Netzwerkkontrollen als Zugriffskontrolle
+ Erstellung eines benutzerdefinierten Authentifizierungsmechanismus, anstatt sich auf branchenübliche Standard-Authentifizierungsmechanismen zu verlassen
+ Übermäßig freizügige Datenflüsse zwischen Service-Komponenten 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 Services, indem die vorgesehenen Schnittstellen für die Datenübertragung klar definiert und erzwungen werden.
+ Verbessert die Überwachung und Protokollierung sowie die Reaktion auf Vorfälle durch Zuordnung von Anforderungen sowie durch klar 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
Die Netzwerkdatenverkehrsmuster Ihrer Workload lassen sich in zwei Kategorien einteilen:
+ Der *Ost-West-Verkehr* steht für Datenflüsse zwischen Services, die eine Workload ausmachen.
+ Der *Nord-Süd-Verkehr* stellt die Datenflüsse zwischen Ihrer Workload und den Consumern dar.
Während es üblich ist, den Nord-Süd-Verkehr zu verschlüsseln, ist der Schutz des Ost-West-Verkehrs mit authentifizierten Protokollen weniger verbreitet. In modernen Sicherheitspraktiken wird darauf hingewiesen, 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 Anforderung 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 und zu bestimmen, ob die Aktion zugelassen werden soll.
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) für die AWS-fremde Ressource verwenden, um temporäre AWS-Anmeldeinformationen zu erhalten. Diese Anmeldeinformationen können verwendet werden, um Anforderungen für Services zu signieren, die Zugriff mithilfe von SigV4 autorisieren.
Ein weiterer gängiger Mechanismus zur Authentifizierung des Ost-West-Verkehrs ist die gegenseitige TLS-Authentifizierung (mTLS). Viele IoT-Anwendungen (Internet of Things, Internet der Dinge) 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) verwenden, um die mTLS-Authentifizierung für die Kommunikation zwischen oder innerhalb eines Workloads bereitzustellen. [Application Load Balancer unterstützt mTLS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html) auch für interne oder externe Workloads. mTLS stellt zwar Authentifizierungsinformationen für beide Seiten einer TLS-Kommunikation bereit, bietet aber keinen Mechanismus zur Autorisierung.
Und zu guter Letzt: OAuth 2.0 und OpenID Connect (OIDC) sind zwei Protokolle, die in der Regel für die Steuerung des Zugriffs von Benutzern auf Services verwendet werden. Inzwischen werden sie jedoch auch für Datenverkehr zwischen Services immer beliebter. API Gateway bietet einen [JSON Web Token (JWT) Authorizer](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html), der es Workloads ermöglicht, den Zugriff auf API-Routen mithilfe von JWTs zu beschränken, die von OIDC- oder OAuth-2.0-Identitätsanbietern ausgestellt wurden. 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
+ **Definieren und Dokumentieren der Netzwerkflüsse Ihrer Workload:** Der erste Schritt bei der Implementierung einer umfassenden Verteidigungsstrategie ist die Definition der Datenflüsse Ihrer Workload.
+ Erstellen Sie ein Datenflussdiagramm, das klar definiert, wie Daten zwischen den verschiedenen Services, aus denen sich Ihre Workload zusammensetzt, übertragen werden. Dieses Diagramm ist der erste Schritt zur Erzwingung 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 unter [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) beschrieben.
+ **Einrichten von Netzwerkkontrollen:** Erwägen Sie die Verwendung von AWS-Funktionen, um Netzwerkkontrollen einzurichten, die auf Ihre Datenflüsse abgestimmt sind. Netzwerkgrenzen sollten zwar nicht die einzige Sicherheitskontrolle sein, aber sie stellen eine Schicht der umfassenden Verteidigungsstrategie zum Schutz Ihrer Workload 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.
+ Erwägen Sie die Verwendung von [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html), um sowohl mit AWS als auch mit Drittanbieter-Services 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 Ihrer Workload:** Wählen Sie die AWS-Services aus, die am besten geeignet sind, um authentifizierte, verschlüsselte Datenflüsse in Ihrer Workload bereitzustellen.
+ Ziehen Sie die Verwendung von [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html) in Betracht, um die Kommunikation zwischen Services zu schützen. VPC Lattice kann [SigV4-Authentifizierung in Kombination mit Authentifizierungsrichtlinien](https://docs.aws.amazon.com/vpc-lattice/latest/ug/auth-policies.html) verwenden, um den Zugriff zwischen Services zu steuern.
+ Ziehen Sie für die Kommunikation zwischen Services mit mTLS [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) oder [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html) in Betracht. [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.
+ Im Falle einer Integration in Services, die OAuth 2.0 oder OIDC verwenden, sollten Sie die Verwendung von [API Gateway mit dem JWT-Genehmiger](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html) in Betracht ziehen.
+ Für die Kommunikation zwischen Ihrer Workload und IoT-Geräten sollten Sie die Verwendung von [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html) in Betracht ziehen. Dadurch stehen Ihnen mehrere Optionen für die Verschlüsselung und Authentifizierung des Netzwerkverkehrs zur Verfügung.
+ **Überwachung auf nicht autorisierten Zugriff:** Überwachen Sie kontinuierlich unbeabsichtigte Kommunikationskanäle, nicht autorisierte Prinzipale, die versuchen, auf geschützte Ressourcen zuzugreifen, und andere unzulässige Zugriffsmuster.
+ Wenn Sie VPC Lattice zur Verwaltung des Zugriffs auf Ihre Services verwenden, empfiehlt es sich gegebenenfalls, die [Zugriffsprotokolle von VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-access-logs.html) zu aktivieren und zu überwachen. Diese Zugriffsprotokolle enthalten Informationen über die anfordernde Entität, Netzwerkinformationen einschließlich Quell- und Ziel-VPC sowie Metadaten der Anforderung.
+ 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 im [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) und im Abschnitt [Vorfallreaktion](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) der Säule „Sicherheit“ des AWS-Well-Architected-Framework.
## Ressourcen
**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:**
+ [ Auswerten von Zugriffskontrollmethoden zum Schutz von Amazon-API-Gateway-APIs](https://aws.amazon.com/blogs/compute/evaluating-access-control-methods-to-secure-amazon-api-gateway-apis/)
+ [ Konfigurieren der gegenseitigen TLS-Authentifizierung für eine REST-API ](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html)
+ [ Schützen von API-Gateway-HTTP-Endpunkten mit JWT-Genehmiger ](https://aws.amazon.com/blogs/security/how-to-secure-api-gateway-http-endpoints-with-jwt-authorizer/)
+ [ Autorisieren von direkten Aufrufen von AWS-Services mithilfe des AWS IoT Core-Anmeldeinformationsanbieters ](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)
+ [ Leitfaden zur Reaktion auf Sicherheitsvorfälle in AWS](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 – Vorstellung von VPC Lattice ](https://www.youtube.com/watch?v=fRjD1JI0H5w)
+ [AWS re:invent 2020 – Serverlose API-Authentifizierung für HTTP-APIs in AWS](https://www.youtube.com/watch?v=AW4kvUkUKZ0)
**Zugehörige Beispiele:**
+ [ Workshop zu Amazon VPC Lattice](https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US)
+ [ Zero-Trust, Episode 1: Der Phantom-Service-Perimeter-Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/dc413216-deab-4371-9e4a-879a4f14233d/en-US)