SEC05-BP01 Netzwerkschichten erstellen - AWS Well-Architected Framework

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

SEC05-BP01 Netzwerkschichten erstellen

Segmentieren Sie Ihre Netzwerktopologie in verschiedene Ebenen, die auf logischen Gruppierungen Ihrer Workload-Komponenten entsprechend ihrer Datensensibilität und Zugriffsanforderungen basieren. Unterscheiden Sie zwischen Komponenten, auf die vom Internet aus zugegriffen werden muss, wie z. B. öffentliche Web-Endpunkte, und solchen, die nur intern erreichbar sein müssen, wie z. B. Datenbanken.

Gewünschtes Ergebnis: Die Schichten Ihres Netzwerks sind Teil eines ganzheitlichen defense-in-depth Sicherheitsansatzes, der die Identitätsauthentifizierungs- und Autorisierungsstrategie Ihrer Workloads ergänzt. Je nach Sensibilität der Daten und den Zugriffsanforderungen werden Ebenen mit entsprechenden Verkehrsfluss- und Kontrollmechanismen eingerichtet.

Typische Anti-Muster:

  • Sie erstellen alle Ressourcen in einem einzigen VPC oder Subnetz.

  • Sie erstellen Ihre Netzwerkebenen ohne Rücksicht auf die Anforderungen an die Datensensibilität, das Verhalten der Komponenten oder die Funktionalität.

  • Sie verwenden VPCs Subnetze als Standardwerte für alle Überlegungen zur Netzwerkschicht, und Sie berücksichtigen nicht, wie AWS verwaltete Dienste Ihre Topologie beeinflussen.

Vorteile der Nutzung dieser bewährten Methode: Die Einrichtung von Netzwerkebenen ist der erste Schritt, um unnötige Pfade durch das Netzwerk einzuschränken, insbesondere solche, die zu kritischen Systemen und Daten führen. Dadurch wird es für Unbefugte schwieriger, sich Zugriff auf Ihr Netzwerk zu verschaffen und zu weiteren Ressourcen darin zu navigieren. Diskrete Netzwerkebenen reduzieren den Umfang der Analyse für Inspektionssysteme, z. B. für die Erkennung von Eindringlingen oder die Verhinderung von Malware, vorteilhaft. Dadurch wird das Potenzial für Fehlalarme und unnötigen Verarbeitungsaufwand reduziert.

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

Implementierungsleitfaden

Beim Entwurf einer Workload-Architektur ist es üblich, die Komponenten je nach ihrer Verantwortlichkeit in verschiedene Ebenen aufzuteilen. Eine Webanwendung kann zum Beispiel eine Präsentationsebene, eine Anwendungsebene und eine Datenebene haben. Bei der Gestaltung Ihrer Netzwerktopologie können Sie einen ähnlichen Ansatz wählen. Die zugrunde liegenden Netzwerkkontrollen können dazu beitragen, die Anforderungen Ihres Workloads an den Datenzugriff durchzusetzen. In einer dreistufigen Webanwendungsarchitektur können Sie beispielsweise Ihre statischen Presentation-Layer-Dateien auf Amazon S3 speichern und sie über ein Content Delivery Network (CDN) wie Amazon CloudFront bereitstellen. Die Anwendungsschicht kann über öffentliche Endpunkte verfügen, die ein Application Load Balancer (ALB) in einem VPC öffentlichen Amazon-Subnetz (ähnlich einer demilitarisierten Zone oderDMZ) bedient, wobei Back-End-Dienste in privaten Subnetzen bereitgestellt werden. Die Datenebene, die Ressourcen wie Datenbanken und gemeinsam genutzte Dateisysteme hostet, kann sich in anderen privaten Subnetzen befinden als die Ressourcen Ihrer Anwendungsebene. An jeder dieser Ebenengrenzen (öffentliches SubnetzCDN, privates Subnetz) können Sie Kontrollen einrichten, die es nur autorisierten Datenverkehr ermöglichen, diese Grenzen zu überschreiten.

Ähnlich wie bei der Modellierung von Netzwerkebenen auf der Grundlage des funktionalen Zwecks der Komponenten Ihres Workloads sollten Sie auch die Sensibilität der verarbeiteten Daten berücksichtigen. Wenn Sie das Beispiel der Webanwendung verwenden, kann es sein, dass alle Ihre Workload-Services innerhalb der Anwendungsebene angesiedelt sind, während verschiedene Services Daten mit unterschiedlichen Sensibilitätsstufen verarbeiten. In diesem Fall kann es je nach Ihren Kontrollanforderungen angemessen sein, die Anwendungsebene mithilfe mehrerer privater Subnetze zu unterteilen AWS-Konto, die sich VPCs in demselben oder sogar in unterschiedlicher Weise AWS-Konten für jede Ebene der Datensensitivität unterscheiden. VPCs

Eine weitere Überlegung für Netzwerkebenen ist die Verhaltenskonsistenz der Komponenten Ihres Workloads. Um das Beispiel fortzusetzen: In der Anwendungsebene haben Sie möglicherweise Services, die Eingaben von Endbenutzern oder externen Systemintegrationen akzeptieren, die von Natur aus risikoreicher sind als die Eingaben für andere Services. Beispiele sind das Hochladen von Dateien, das Ausführen von Skripten, das Scannen von E-Mails und so weiter. Die Unterbringung dieser Services in einer eigenen Netzwerkebene hilft dabei, eine stärkere Isolationsgrenze um sie herum zu schaffen, und kann verhindern, dass ihr einzigartiges Verhalten falsche positive Alarme in Inspektionssystemen erzeugt.

Berücksichtigen Sie im Rahmen Ihres Entwurfs, wie sich die Verwendung von AWS Managed Services auf Ihre Netzwerktopologie auswirkt. Erfahren Sie, wie Services wie Amazon VPC Lattice dazu beitragen können, die Interoperabilität Ihrer Workload-Komponenten über Netzwerkschichten hinweg zu vereinfachen. Verwenden Sie die Lösung in Ihren VPC Subnetzen AWS Lambda, es sei denn, es gibt bestimmte Gründe, dies nicht zu tun. Ermitteln Sie, wo sich VPC Endpunkte befinden, und AWS PrivateLinkkönnen Sie die Einhaltung von Sicherheitsrichtlinien, die den Zugriff auf Internet-Gateways einschränken, vereinfachen.

Implementierungsschritte

  1. Überprüfen Sie Ihre Workload-Architektur. Gruppieren Sie Komponenten und Services logisch nach den Funktionen, die sie erfüllen, nach der Sensibilität der verarbeiteten Daten und nach ihrem Verhalten.

  2. Für Komponenten, die auf Anfragen aus dem Internet reagieren, sollten Sie Load Balancer oder andere Proxys verwenden, um öffentliche Endpunkte bereitzustellen. Erkunden Sie die sich ändernden Sicherheitskontrollen, indem Sie Managed Services wie CloudFront Amazon API Gateway und Elastic Load Balancing nutzen und AWS Amplifyöffentliche Endgeräte hosten.

  3. Für Komponenten, die in Rechenumgebungen ausgeführt werden, wie EC2 Amazon-Instances, AWS FargateContainer oder Lambda-Funktionen, stellen Sie diese vom ersten Schritt an in privaten Subnetzen bereit, die auf Ihren Gruppen basieren.

  4. Für vollständig verwaltete AWS Dienste wie Amazon DynamoDB, Amazon Kinesis oder Amazon SQS sollten Sie die Verwendung von VPC Endpunkten als Standard für den Zugriff über private IP-Adressen in Betracht ziehen.

Ressourcen

Zugehörige bewährte Methoden:

Zugehörige Videos:

Zugehörige Beispiele: