Eine Firewall zwischen Ports ist keine Hostgrenze

Die Website antwortet auf 443, das VPN antwortet auf 1194, die Firewall erlaubt genau diese beiden, und die Prüfung besteht. Nichts in dieser Abfolge fragte, was der Web-Worker lesen oder welche Dateien er überschreiben kann. Ein kompromittierter Worker braucht keinen offenen Port, wenn er einen Steuerungs-Socket oder ein beschreibbares Konfigurationsverzeichnis erreichen kann. Die Grenze ist Befugnis, und Listener sind nur der leicht sichtbare Teil.

Ein eigener Dienstname ist ein Etikett; eine eigene Identität ist eine Sicherheitseigenschaft.

Zählen Sie die Befugnisse des Workers, nicht die Ports

Beginnen Sie beim Laufzeitbenutzer, seinen Gruppen, seinen Fähigkeiten und seiner Dateisystemsicht. Ein Dienstkonto, das zufällig zu einer VPN-Gruppe gehört, kann Schlüsselmaterial lesen, ohne dass ein Port offen ist. Beschreibbare Mounts sind die andere Hälfte: Uploads und Caches sollten weit von Richtliniendateien und Geheimnissen liegen, und ein unnötig geteiltes beschreibbares Verzeichnis macht eine saubere Benennung zunichte. Prüfen Sie den Prozess, der die Operation ausführen würde, denn ein privilegierter Elternprozess und unprivilegierte Worker teilen sich keine Befugnis.

Dass ein VPN-Schlüssel beim Start des Daemons lesbar ist, heißt nicht, dass der Web-Worker ihn braucht. Trennen Sie das Lesen des Daemons vom Zugriff, den die Anwendung erhält.

Sockets, die mehr gewähren, als sie scheinen

Manche Endpunkte sind administrative APIs im Kostüm eines Metrik-Feeds. Die Verwaltungsschnittstelle des VPN kann Sitzungen ändern, Clients trennen und Zustand lesen. Ein Container-Runtime-Socket ist noch weiter: Zugriff darauf ist praktisch Host-Kontrolle, weit über das hinaus, was eine Webanwendung braucht. Keines von beiden gehört in den Mount-Satz einer gewöhnlichen Anwendung, und keines erscheint, wenn man lauschende Ports zählt.

Einen Verwaltungs-Listener an eine lokale Adresse zu binden ist ein Anfang, keine vollständige Einschränkung, denn jeder Eingangsweg zu dieser Adresse bleibt wichtig. Erlauben Sie nur die vorgesehenen Quellen und Schnittstellen.

Container teilen einen Kernel

Container fügen Prozess-, Dateisystem- und Netzwerkgrenzen hinzu und teilen einen Kernel mit dem Host. Das macht Fähigkeitsentscheidungen, Host-Mounts und Daemon-Zugriff entscheidend: Host-Geheimnisse zu mounten oder privilegierte Laufzeitkontrolle zu gewähren löscht die Grenze, die das Container-Etikett suggeriert. Getrennte VMs geben tatsächlich getrennte Gast-Kernel, während Hypervisor, administrative Identitäten, Speicher und Backups geteilt bleiben. Wählen Sie die Grenze, deren Konfiguration und Updates einen benannten Eigentümer haben.

Eine aufwendigere Anordnung, die niemand pflegt, ist schlechter als eine einfache, die tatsächlich geprüft wird.

Prüfen Sie die Verweigerung, dann den Dienst

Bestätigen Sie mit genehmigten Prüfungen im realen Kontext des Workers, dass er die VPN-Richtlinie nicht ändern, keine unnötigen Geheimnisse lesen und die Verwaltungsschnittstelle nicht berühren kann. Ein erfolgreiches Lesen als Administrator prüft nichts über diese Verweigerung. Prüfen Sie dann die Website, eine gewöhnliche erlaubte VPN-Operation und was bei einem Neustart mit beidem geschieht. Bewahren Sie einen Wiederherstellungspfad, der nicht davon abhängt, dass das VPN repariert wird, damit ein Fehler behebbar bleibt.

Beide Rollen teilen weiterhin CPU, Speicher, Uplink-Kapazität und Wartungsereignisse. Diese geteilten Ressourcen gehören in den Plan, auch wenn die Befugnisgrenze sauber ist.

Halten Sie fest, was jeder Prozess tun kann, was ausfällt, wenn er stoppt, und welche Grenze geteilt bleibt. Portzahlen sind nicht dieser Nachweis.