SEC09-BP03 Authentifizieren der Netzwerkkommunikation - AWS Well-Architected Framework
ImplementierungsleitfadenRessourcen

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), 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 und Amazon API Gateway 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 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 und AWS App Mesh verwenden, um die mTLS-Authentifizierung für die Kommunikation zwischen oder innerhalb einer Workload bereitzustellen. 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, 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 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, um den Datenfluss zwischen Ressourcen zu definieren und einzuschränken.

    • Erwägen Sie die Verwendung von AWS PrivateLink, 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 in Betracht, um die Kommunikation zwischen Services zu schützen. VPC Lattice kann SigV4-Authentifizierung in Kombination mit Authentifizierungsrichtlinien verwenden, um den Zugriff zwischen Services zu steuern.

    • Ziehen Sie für die Kommunikation zwischen Services mit mTLS API Gateway oder App Mesh in Betracht. AWS Private CA 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 in Betracht ziehen.

    • Für die Kommunikation zwischen Ihrer Workload und IoT-Geräten sollten Sie die Verwendung von AWS IoT Core 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 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, 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 und im Abschnitt Vorfallreaktion der Säule „Sicherheit“ des AWS-Well-Architected-Framework.

Ressourcen

Zugehörige bewährte Methoden:

Zugehörige Dokumente:

Zugehörige Videos:

Zugehörige Beispiele: