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
Ä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
Implementierungsschritte
-
Ü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.
-
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. -
Für Komponenten, die in Rechenumgebungen ausgeführt werden, wie EC2 Amazon-Instances, AWS Fargate
Container oder Lambda-Funktionen, stellen Sie diese vom ersten Schritt an in privaten Subnetzen bereit, die auf Ihren Gruppen basieren. -
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: