Du brauchst noch keine vier Subnetze

Fast jede Anleitung zum sicheren Ausrollen einer Anwendung zeigt dasselbe Bild: eine VPC, private Subnetze für Compute und Datenbank, ein öffentliches für Load Balancer, ein Bastion-Host, je eine Security Group pro Schicht. Das Bild ist gut. Es ist nur für eine Firma mit Plattform-Team gezeichnet, und bekommen tun es Leute, die ihre erste Anwendung ausrollen.

Hier steht dasselbe Thema, sortiert nach Größe. Vier Stufen, und je Stufe: was sie kauft, was sie kostet, das Signal zum Weitergehen, und eine Prüfung, die du wirklich ausführen kannst.

Die Prüfung ist wichtiger als das Diagramm. An jeder Stufe hängt eine Behauptung, und eine Behauptung, die niemand testet, ist Dekoration.

Stufe 1: eine Maschine

Ein Host, ein Docker-Netz, innen erreicht jeder jeden. Hier fangen die meisten an, und hier läuft erstaunlich viel Produktion still vor sich hin.

Der Reflex sagt, diese Stufe habe keine Sicherheit. Falsch. Sie hat drei Dinge, und die wiegen schwerer als das Subnetz-Diagramm:

• Nichts lauscht öffentlich außer dem Proxy. Deine Datenbank hört auf dem internen Netz oder auf einem Socket. Nicht auf 0.0.0.0.
• Zugangsdaten je Prozess. Der Dienst, der Anfragen beantwortet, hält nicht die Zugangsdaten, mit denen man Zeilen löschen kann. Das ist die Maßnahme, die trägt, egal wie das Netz gebaut ist, und genau die wird übersprungen.
• TLS endet an einer Stelle, die dir gehört, mit Zertifikaten, die sich ohne dich erneuern.

Die Prüfung: Versuch von einer anderen Maschine aus, den Datenbank-Port direkt zu erreichen.

nc -vz dein-host 5432
# Erwartet: refused oder Timeout. Verbindet es sich,
# ist der Rest dieses Textes gegenstandslos.

Führ das von außerhalb deines eigenen Netzes aus. Eine Firewall-Regel, die dein Büro durchlässt, und eine, die die Welt durchlässt, sehen von deinem Schreibtisch aus gleich aus.

Weiter, wenn: eine zweite Person Zugriff braucht, ein Zwischenfall eine nie getestete Sicherung erfordern würde, oder ein einzelner Prozess beim Ausfall alles mitnimmt.

Stufe 2: eine Managed Platform

Eine Plattform betreibt den Host für dich: Container, TLS, Neustarts, Secrets, meist auch eine Datenbank. Was sich ändert, ist nicht das Sicherheitsmodell, sondern wer für die Teile zuständig ist, die du vergessen hast.

Was sie kauft, ist echt. Zertifikatserneuerung, gepflegte Basis-Images, eine Neustart-Regel, die funktioniert, und einen Ort für Secrets, der keine Datei auf einem Laptop ist.

Was sie kostet: Die Grenze gehört jetzt jemand anderem, und du siehst sie nicht. Zwei Dienste auf derselben Plattform teilen sich womöglich mehr, als du denkst. Lies nach, wie das Netzmodell tatsächlich aussieht, statt eine Isolation anzunehmen, die dir niemand zugesagt hat.

Die Prüfung: Roll einen Wegwerf-Dienst auf derselben Plattform aus und versuch von innen, deine echte Datenbank zu erreichen.

# Im Wegwerf-Container:
getent hosts dein-db-host
nc -vz dein-db-host 5432
# Erreicht ein gerade erstellter Container deine Produktionsdatenbank,
# ist die Plattform eine Bequemlichkeit und keine Grenze.

Diese Prüfung führt niemand aus, und sie stuft eine Plattform in etwa dreißig Sekunden von Grenze zu Bequemlichkeit herunter.

Weiter, wenn: du Daten hältst, deren Abfluss du melden müsstest, oder eine Compliance-Frage ansteht, die sich nicht mit „das macht die Plattform" beantworten lässt.

Stufe 3: ein Netz, das du selbst definierst

Jetzt verdient das Diagramm seinen Platz. Ein privates Subnetz für Compute, eines für Daten, und öffentlich steht nur, was öffentlich stehen muss.

Das kauft dir ein Fehlerbudget. Sobald die Datenbank keine Route ins Internet hat, kann ein falsch konfigurierter Dienst sie nicht versehentlich exponieren, und eine Abhängigkeit, die nach Hause telefonieren möchte, auch nicht. Das ist viel wert, und es ist die erste Stufe, auf der das Netz etwas leistet, was kein Anwendungscode leisten könnte.

Es kostet, dass jedes Problem eine Schicht mehr zum Prüfen hat. Eine Verbindung, die früher aus einem Grund scheiterte, scheitert jetzt aus vieren, und drei davon sind aus der Anwendung nicht sichtbar. Rechne damit, und schreib das gewählte Routing auf, solange du noch weißt, warum.

Zwei Dinge, bevor du zeichnest:

• Wähl die Adressbereiche bewusst. Überlappende Bereiche sind der Fehler, der erst auffällt, wenn du zwei Netze koppelst, und dann sind beide in Produktion.
• Ausgehender Verkehr ist auch eine Regel. Die meisten beschränken, was hereinkommt, und lassen hinaus alles zu. Genau in diese Richtung fließen Daten ab.

Die Prüfung: Versuch aus dem Datenbank-Subnetz heraus, das offene Internet zu erreichen.

curl -m 5 https://example.com
# Erwartet: Timeout. Eine Datenbank, die im Web surfen kann,
# kann deine Tabellen auch irgendwo hochladen.

Weiter, wenn: mehr als ein Team hier ausrollt, oder der Fehler einer Umgebung die Daten einer anderen erreichen kann.

Stufe 4: getrennte Accounts, und ein Weg hinein

Die letzte Stufe ist kein größeres Netz, sondern eine härtere Grenze: getrennte Accounts oder Subscriptions je Umgebung, damit Produktion nicht einen Tippfehler von Staging entfernt ist. Ein Bastion, oder besser ein Vermittler, der gar keinen offenen Port braucht, ist der Weg, auf dem Menschen an Privates kommen.

Deutlich gesagt: Ein Bastion-Host ist eine Maschine mit öffentlichem SSH-Port, deren ganze Aufgabe darin besteht, vertrauenswürdig zu sein. Bietet dein Anbieter sitzungsbasierten Zugriff über seine eigene Steuerebene, oder kannst du ein Mesh-Netz betreiben, bekommst du dieselbe Erreichbarkeit, ohne einen Port zu veröffentlichen. Nimm das. Der klassische Bastion steht in jedem Diagramm, weil die Diagramme älter sind als die Alternativen.

Die Prüfung: Nimm die Zugangsdaten des Nicht-Produktions-Accounts und versuch, Produktionsressourcen aufzulisten.

aws sts get-caller-identity          # welche Identitaet bin ich gerade
aws s3 ls --profile staging          # dann nach etwas in prod greifen
# Erwartet: AccessDenied. Nicht "leere Liste", denn die kann auch heissen,
# dass du am falschen Ort suchst, und wuerde eine echte Berechtigung verdecken.

Dieser Unterschied ist der ganze Grund, es auszuführen. Ein Berechtigungstest, der „verweigert" nicht von „da ist nichts" unterscheiden kann, hat nichts getestet.

Was ich jemandem am Anfang wirklich sagen würde

Nimm die Stufe, auf der deine Lage ist, nicht die aus dem Diagramm. Vorauszuspringen ist keine Vorsicht, sondern Komplexität, die du um drei Uhr nachts nicht debuggen kannst, und Komplexität, die du nicht debuggen kannst, ist selbst ein Ausfall.

Was über alle vier Stufen trägt, ist nicht das Netz. Es ist, dass ein Dienst nur die Zugangsdaten hält, die er braucht. Das funktioniert auf einer Kiste, auf einer Plattform, in einer VPC und über Accounts hinweg, und es ist die einzige Maßnahme hier, die auch dann noch wirkt, wenn das Netz schlecht gebaut ist.

Und führ die Prüfungen aus. Jede Stufe hat eine, sie dauern Minuten, und jede kann fehlschlagen. Eine Maßnahme, die du nie hast fehlschlagen sehen, ist ein Kommentar, keine Maßnahme.

Wenn du den Rest willst: fünf Terraform-Antipattern zeigt, wie der Code drumherum meistens aussieht, was deine Infrastruktur wirklich ausführt, wenn du SST benutzt geht eine Abstraktion tiefer bis zum Provider, CDKTF ist archiviert handelt davon, was zu tun ist, wenn ein Werkzeug in dieser Kette stehenbleibt, elf Projekte hinter einer Oberfläche ist die Migration, wenn die Plattform nicht mehr passt, und drei Listen sind von ihrem Register abgedriftet ist der Fehlermodus, den das alles teilt.

Next

Was hier fehlt, ist die Kostenspalte. An jeder Stufe hängt eine reale monatliche Zahl, und ich habe bewusst keine geraten, weil sie vom Anbieter, von der Region und davon abhängt, wie viel davon leerläuft. Dafür bräuchte es einen Vergleich mit echten Rechnungen statt einer Tabelle, die ich mir ausgedacht habe.

Auf welcher Stufe bist du, und was hat dich dorthin gebracht? Am meisten interessieren mich die Schritte, die sich als verfrüht herausgestellt haben, denn die schreibt niemand auf.