Design öffentlicher und privater Subnetze

Eine Virtual Private Cloud (VPC) ist Ihr logisch isoliertes Netzwerk in AWS. Darin legen Sie Subnetze an – IP-Adressbereiche, die jeweils an eine einzelne Availability Zone gebunden sind. Wie Sie eine VPC in Subnetze aufteilen, ist die erste und wichtigste Sicherheitsentscheidung, da dadurch festgelegt wird, was auf was zugreifen kann.

Ein öffentliches Subnetz verfügt über eine Route zu einem Internet-Gateway. Ressourcen darin können daher aus dem Internet erreicht werden und das Internet erreichen. Ein privates Subnetz besitzt keine direkte Internetroute. Die Unterscheidung wird ausschließlich durch die Routing-Tabelle festgelegt, nicht durch eine Eigenschaft des Subnetzes selbst.

Nur Ressourcen, die dem Internet ausgesetzt sein müssen, gehören in öffentliche Subnetze: Load Balancer, NAT-Gateways und Bastion-Alternativen. Wenn diese Schicht möglichst klein bleibt, wird die Angriffsfläche reduziert. Anwendungsserver und Datenbanken sollten niemals in einem öffentlichen Subnetz liegen, in dem das Internet sie direkt erreichen könnte.

Platzieren Sie Anwendungsserver, Datenbanken und interne Dienste in privaten Subnetzen. Sie können weiterhin über einen Load Balancer im öffentlichen Subnetz Datenverkehr bedienen und über NAT für Aktualisierungen das Internet erreichen, sind aber von außen niemals direkt adressierbar. Dadurch wird die Angriffsfläche drastisch reduziert.

Ein gängiges sicheres Layout verwendet drei Schichten: ein öffentliches Subnetz für Load Balancer, ein privates App-Subnetz für Compute-Ressourcen und ein privates Daten-Subnetz für Datenbanken. Der Datenverkehr fließt Schicht für Schicht nach innen, und jede Schicht akzeptiert nur Verbindungen von der jeweils vorgelagerten Schicht.

Replizieren Sie Subnetze für mehr Ausfallsicherheit über mehrere Availability Zones (AZs). Ein Paar aus öffentlichem und privatem Subnetz in jeder AZ ermöglicht es Load Balancern und Workloads, den Ausfall einer Zone zu überstehen. Dies ist eine Praxis für hohe Verfügbarkeit und unterstützt zugleich sichere, redundante Designs.

Planen Sie Ihre CIDR-Blöcke so, dass sich Subnetze nicht überschneiden und Raum für zukünftiges Wachstum bleibt. Durchdachte, nicht überlappende Bereiche vereinfachen Routing, Peering und Verweise in Sicherheitsregeln. Überlappende CIDRs in verschiedenen VPCs verhindern später Peering und erschweren die Konnektivität. Planen Sie den Adressraum daher von Anfang an bewusst.

Das Subnetzdesign ist ein Sicherheitskontrollmechanismus, da Sie damit vertrauliche Workloads isolieren können. Ein Daten-Subnetz ohne Internetroute und ohne eingehenden Pfad außer von der App-Schicht ist strukturell geschützt, noch bevor Sie Sicherheitsgruppen hinzufügen. Die Architektur – nicht nur die Regeln – setzt diese Grenze durch.

Subnetze legen fest, wo Netzwerk-ACLs gelten, da NACLs an der Subnetzgrenze angebunden werden. Wenn Sie gut entworfene Subnetze mit NACLs auf Subnetzebene und Sicherheitsgruppen auf Ressourcenebene kombinieren, erhalten Sie das geschichtete Netzwerkmodell nach dem Prinzip der Tiefenverteidigung, das die SCS-C02-Prüfung erwartet.

Der klassische Fehler besteht darin, eine Datenbank in einem öffentlichen Subnetz zu platzieren oder privaten Instanzen aus Bequemlichkeit öffentliche IP-Adressen zu geben. Beides setzt Ressourcen dem Internet aus, die intern bleiben sollten. Setzen Sie standardmäßig auf eine private Platzierung und begründen Sie jede Ressource in einem öffentlichen Subnetz ausdrücklich.

Ein durchdachtes Subnetzdesign bildet das Rückgrat einer sicheren VPC. Indem Sie internetseitig zugängliche und interne Ressourcen trennen und AZs überspannen, integrieren Sie Isolation und Ausfallsicherheit direkt in das Netzwerk. Darauf bauen Gateways, Routing-Tabellen und Firewalls auf.

Wenden Sie Ihr Wissen zur Subnetzplanung an.

Eine VPC wird in Subnetze aufgeteilt, die an Availability Zones gebunden sind. Ein Subnetz ist nur dann öffentlich, wenn seine Routing-Tabelle ein Internet-Gateway erreicht; andernfalls ist es privat. Platzieren Sie nur Load Balancer und NAT in öffentlichen Subnetzen und halten Sie App- und Datenschichten privat. Verwenden Sie ein Multi-Tier-Muster über mehrere AZs mit geplanten, nicht überlappenden CIDRs, damit die Isolation bereits in der Architektur verankert ist.