Die Stärke des Minimum Viable Network

Cloud-Netzwerke zu verstehen, ist für Organisationen zu Beginn ihrer Cloud-Reise eine der größten Umstellungen. Betrachtet man das Adressierungsschema und die Komponenten, sieht es einigermaßen nach einem IP-Netzwerk aus. Und aus den meisten Blickwinkeln ist es das auch – in vielen anderen Bereichen jedoch nicht. Ein Software-defined Network (SDN) – wie es in der Cloud angeboten wird – unterliegt nicht denselben Einschränkungen wie ein physisches Netzwerk, und das kann zu Beginn ziemlich verwirrend sein.

Anstatt zu verstehen zu versuchen, worin sich SDN von Ihrem physischen Netzwerk unterscheidet, konzentrieren wir uns stärker darauf, was das Netzwerk leisten muss und – noch wichtiger – was nicht erlaubt sein sollte. Vielleicht erinnern Sie sich noch an ein Konzept namens „Default Deny“: Sofern eine Verbindung nicht ausdrücklich erlaubt wurde, war sie standardmäßig blockiert. Dann kam das Web, und es war nicht mehr möglich, Port 80 oder 443 einzuschränken, da praktisch jede Anwendung diese Ports nutzte. Zudem hat es „Default Deny“ nie wirklich über den Perimeter hinaus geschafft, und unsere internen Netzwerke waren tendenziell flach und offen und verließen sich auf eine DMZ, um den unerwünschten Datenverkehr aus der Außenwelt herauszufiltern. Wie eine Sicherheitsverletzung nach der anderen gezeigt hat, ist dieses Modell nur mäßig wirksam.

SDN erlaubt es uns jedoch, Default Deny deutlich näherzukommen – über ein Konzept, das wir „Minimum Viable Network“ nennen. Es ermöglicht den Aufbau maßgeschneiderter Netzwerke mit genau den Bestandteilen, die zur Erfüllung der Aufgabe erforderlich sind, und nicht mehr.

Ein Minimum Viable Network sollte die Anwendungsarchitektur bestimmen und anschließend AUSSCHLIESSLICH die Netzwerkstrukturen schaffen, die zur Unterstützung dieser Anwendung erforderlich sind – mit durchgesetztem Least-Privilege-Routing und entsprechenden Security Groups sowie unter Nutzung von PaaS-Komponenten wie Cloud-Load-Balancern. Dadurch wird das paketvermittelte Netzwerk faktisch zu einem leitungsvermittelten Netzwerk, da Anwendungskomponenten AUSSCHLIESSLICH mit den jeweils erlaubten anderen Komponenten kommunizieren können und niemand den dazwischenliegenden Datenverkehr mitlesen kann (mit Ausnahme, in manchen Fällen, des Cloud-Anbieters). Das Netzwerk verwirft sämtlichen übrigen Datenverkehr. Damit entfällt die Notwendigkeit von Konstrukten wie der traditionellen DMZ oder Netzwerkzonen, da das gesamte Netzwerk selbst nach Least Privilege und Default Deny arbeitet.

Machen wir das anhand eines Beispiels etwas greifbarer. Sie können einen klassischen dreistufigen Anwendungs-Stack mit einem öffentlich erreichbaren Application Load Balancer erstellen, hinter dem ein Webserver in einem privaten Subnetz steht, der AUSSCHLIESSLICH Datenverkehr vom Load Balancer annimmt. Die Webserver können sich nur mit Anwendungsservern verbinden, die Verbindungen von ihnen akzeptieren. Ebenso können die Anwendungsserver nur Datenverkehr an Datenbanken senden, die solche Verbindungen zulassen. Jede Ebene arbeitet nach Default Deny und lässt nur eingehende Verbindungen von den Load Balancern und ausgehende Verbindungen zu den Datenbanken zu. In vielen Fällen lässt sich dies ohne jegliche Internetanbindung (in privaten Subnetzen) umsetzen – abgesehen von den öffentlichen Load Balancern, die hochsichere, vom Cloud-Anbieter verwaltete PaaS-Konstrukte sind.

Statt das Netzwerk aufzubauen und Anwendungen darin unterzubringen, entwerfen Sie die Anwendungen und passen anschließend das Netzwerk an deren Anforderungen an. Das reduziert die Angriffsfläche des Anwendungs-Stacks erheblich und senkt Ihr Risiko entsprechend.

Wir haben diese Prinzipien beim Aufbau der Website securosis.com angewendet, wie Sie im nachstehenden Architekturdiagramm sehen können. Betrachten wir dieses Design mit Blick auf die Netzwerksicherheit, erkennen wir:

• Der Zugriff ist über die Cloud-WAF eingeschränkt, sodass nur sauberer Datenverkehr in die VPC gelangt.
• Die Application Load Balancer (ALBs) sind die einzigen Ressourcen in öffentlich erreichbaren Subnetzen und lassen nur Datenverkehr über 80/443 zu.
• Alle Instanzen befinden sich in privaten Subnetzen und akzeptieren nur Datenverkehr von den ALBs.
• Die „admin“-Instanz akzeptiert Anmeldungen, jedoch nur aus einem VPN, das in einer anderen Umgebung gehostet wird.
• Nicht dargestellt sind die Subnetze für die RDS-Datenbank, die ebenfalls ausschließlich privat sind und nur Datenverkehr von den Instanzen akzeptieren. Werden direkte Anmeldungen oder RDBMS-Zugriffe zur Datenaufbereitung benötigt, werden die Security-Group-Regeln für einen temporären Zugriff geändert.
• Verbindungen zu S3 erfolgen über einen Service-Endpunkt, wodurch ein NAT Gateway für den Internetzugang entfällt.
• SSH ist auf den Nicht-Admin-Instanzen deaktiviert. Diese werden automatisch skaliert, sind unveränderlich und werden ausschließlich durch Änderung des Basis-Images angepasst.
• Es gibt keine selbstreferenzierenden Security Groups (Security Groups, die internen Zugriff erlauben), um horizontale Angriffe zu verhindern. Security Groups in AWS wirken auf Ressourcenebene, nicht auf Subnetzebene, was zur Blockade von East-West-Angriffen sehr wirkungsvoll ist.
• Diese Architektur reduziert die gesamte Angriffsfläche erheblich. Das Netzwerk lässt nur die mindestens erforderliche Konnektivität zu und enthält nur die mindestens erforderlichen Subnetze und Routing-Tabellen, um den Zugriff zu ermöglichen. Wir haben das Netzwerk im Grunde auf die Anwendung zugeschnitten. Tatsächlich wurde das Netzwerk erst entworfen, nachdem der Anwendungs-Stack architektonisch festgelegt war.
• Dies ist ein sehr einfaches Beispiel einer kleinen Website, doch die Prinzipien lassen sich auf weitaus größere Architekturen mit mehr Ebenen, internen Load Balancern, API-Gateways und PaaS-Komponenten anwenden.

Wie Sie sehen, verfügen Sie beim Einsatz von Cloud-Netzwerkkonstrukten über enorme Flexibilität. Sie haben endlich die Möglichkeit, das Netzwerk zu bauen, das die Anwendung benötigt, statt die Anwendung an das vorhandene Netzwerk anzupassen. Mit dieser Flexibilität geht jedoch auch die Möglichkeit einher, Dinge falsch zu konfigurieren und weite Teile Ihrer Infrastruktur für das öffentliche Internet zu öffnen. Wir empfehlen daher stets, Ihre Cloud-Sicherheitslage zu überwachen und Best Practices mit einer Cloud-Security-Operations-Plattform (wie der von DisruptOps angebotenen) durchzusetzen.