Einheit 3.2: Netzwerksicherheit: Firewall und Sicherheitsgruppen

Einführung

Die Segmentierung in Einheit 3.1 hat FinCorp drei LANs gegeben: eine öffentliche Kante, eine private Anwendungsebene und eine private Daten-Ebene. Die Topologie allein zwängt nicht, wer mit wem sprechen darf. Die Durchsetzungsschicht sitzt auf den Server-Netzwerkkarten, und es ist die nächste Entscheidung im Netzwerkdesign: Ein per-Netzwerkkarte-Firewall und Network Security Groups binden beide an virtuelle Maschinennetzwerkschnittstellen, und beide verweigern standardmäßig alles, sobald Sie sie aktivieren.

Diese Einheit endet mit dem Aufbau dieser Durchsetzung in der Data Center Designer für die FinCorp-Umgebung: Firewall-Regeln, die nur die Inter-Tier-Flüsse zulassen, die die Architektur erfordert, plus ein Fluss-Log, das in einen Object Storage-Bucket geschrieben wird, damit das Sicherheitsteam überprüfen kann, nachträglich genau, welche Verbindungen akzeptiert und welche abgelehnt wurden. Bevor der Aufbau beginnt, müssen zwei Dinge klar sein: Wie die Firewall den Datenverkehr auswertet und wo die Firewall-Konstrukte aufhören, anzuwenden.

1. NIC Firewall-Mechanik und der deny-by-default-Vertrag

Der IONOS Firewall ist eine Eigenschaft einer einzelnen Server-NIC und nicht einer Subnetz, eines LAN oder des VDC als Ganzes. Eine NIC ohne Firewall lässt alle Datenverkehr passieren. Sobald Sie den Firewall auf dieser NIC aktivieren, invertiert sich der Vertrag: mit dem Firewall aktiviert und ohne definierte Regeln, wird aller eingehender Datenverkehr blockiert. Jede Verbindung, die Sie zulassen möchten, ist dann eine explizite Zulassungsregel. Es gibt keine separate "Ablehnungs"-Regel, die geschrieben werden muss, und das Prinzip der geringsten Rechte wird einfach durch das Nicht-Hinzufügen einer Regel erreicht, was der Zugriffskontrolle in der Governance entspricht.

Der Firewall ist zustandsbehaftet. Wenn eine Regel eine ausgehende Verbindung zulässt, werden die entsprechenden Rückpakete automatisch zugelassen; Sie müssen keine Spiegelbild-Regel für den Rückdatenverkehr schreiben. Dies ist wichtig für die Anwendungsebene von FinCorp: eine Regel, die es den Anwendungsservern ermöglicht, den PostgreSQL-Endpunkt auf der Datenebene zu erreichen, lässt auch die Abfrageergebnisse ohne eine zweite eingehende Regel auf der Anwendungsnic für die Datenbankantwort zurückfließen.

Regeln können pro Richtung angewendet werden. Wenn Sie den Firewall aktivieren, wählen Sie Eingehend, Ausgehend oder Bidirektional, und jede Regel selbst trägt eine Richtung von Eingehend oder Ausgehend. Eine Regel entspricht dem Protokoll und den relevanten Feldern für dieses Protokoll. Die unterstützten Protokolle sind TCP, UDP, ICMP, ICMPv6, VRRP, GRE, AH und ESP, sowie eine "Jedes Protokoll"-Option. Für TCP und UDP geben Sie Portbereiche an; für ICMP und ICMPv6 geben Sie Typ und Code an (zum Beispiel Typ 8 für Echo-Anfragen). Eine Regel kann auch die Quell-MAC, Quell-IP/CIDR und Ziel-IP/CIDR einschränken, wobei das Ziel-Feld nützlich ist, wenn eine NIC virtuelle IP-Adressen trägt.

Da das manuelle Schreiben von Regeln für häufige Rollen fehleranfällig ist, liefert der DCD Regelschablonen. Die folgenden Schablonen sind verfügbar und bevölkern eine typische Regelsammlung:

Eine Schablone ist ein Ausgangspunkt, keine fertige Richtlinie. Die Schablone "Allgemeiner Webserver" zum Beispiel lässt HTTP und HTTPS von allen Quellen zu, was für eine internetfacing-Edge-NIC angemessen ist, aber falsch für eine private Ebene. Regeln können auch von einer anderen NIC geklont werden, was eine Flotte identischer Server konsistent hält. Der Firewall-Datenpfad ist für bis zu 6 Gbps Durchsatz pro Faktenmatrix ausgelegt, was für die Filterung von Ebene zu Ebene ausreichend ist, aber eine Zahl ist, die man für sehr hochbandbreite NICs im Auge behalten sollte.

2. NSGs versus die NIC Firewall, und die Grenze, wo keine von beiden gilt

Die pro-NIC-Firewall-Regel ist lokal: ihre Regeln leben auf einer NIC und werden dort verwaltet. Network Security Groups lösen das Skalierungsproblem. Eine NSG ist ein benannter, wiederverwendbarer Satz von Regeln, der auf der VDC-Ebene erstellt und dann an Server oder NICs angehängt wird, sodass eine Richtlinie viele Schnittstellen regeln kann und eine Änderung der Gruppe sich auf jedes angehängte Mitglied auswirkt. NSGs können über die DCD, die Cloud-API, die Go-Cloud-SDK und die Terraform verwaltet werden.

Jedes neu erstellte VM in einem VDC wird automatisch der Standard-NSG hinzugefügt, die mit vier vordefinierten Regeln ausgeliefert wird: alle IPv4-Datenverkehr zulassen, alle IPv6-Datenverkehr zulassen, IPv4-Datenverkehr nur aus dem 10.0.0.0/24-Bereich des VDC zulassen und IPv6-Datenverkehr nur aus dem /56-IPv6-CIDR-Bereich zulassen, der dem Rechenzentrum zugewiesen ist. Diese Standard-Einstellung ist aus Gründen der Sicherheit permissiv auf Datenverkehr und Ost-West-Datenverkehr, sodass ein regulierter Mieter wie FinCorp sie normalerweise durch benutzerdefinierte Gruppen ersetzt, die nur die erforderlichen Datenströme zulassen. Benutzerdefinierte NSGs sind standardmäßig ablehnend, wie die NIC-Firewall, sodass jeder zulässige Datenverkehr wieder eine explizite Regel ist.

NSGs sind zustandsbehaftet, unterstützen sowohl INGRESS- als auch EGRESS-Regeln und akzeptieren das Protokoll-Set UDP, TCP, ICMP, ICMPv6, GRE, VRRP, ESP, AH und ANY. Die Kapazitätsgrenzen sind bei der Planung zu beachten: bis zu 10 NSGs pro NIC, bis zu 10 pro VM, bis zu 100 Regeln pro NSG und bis zu 200 NSGs pro VDC. Die Anbindung ist granular: Sie können eine Gruppe auf der VM-Ebene anbinden, wo sie alle NICs dieser VM-Instanz abdeckt, oder auf der einzelnen NIC-Ebene für eine engere Kontrolle. Wenn ein VM Mitglied einer NSG ist, erben alle NICs dieser VM-Instanz die Regeln implizit.

Die folgende Tabelle vergleicht die beiden Konstrukte, um zu zeigen, wo jedes am besten eingesetzt wird:

Ein häufiger Entwurfsimpuls ist, beide für eine Verteidigung in der Tiefe zu schichten. Seien Sie hier bewusst: die Faktenmatrix zeigt, dass die parallele Verwendung von NSGs und der NIC-Firewall nicht das empfohlene Muster ist, also wählen Sie ein Durchsetzungsmodell pro Umgebung anstelle von überlappenden Regelsätzen, die schwer zu verstehen sind. Für FinCorp sind NSGs die bessere Wahl, da die Sicherheitspostur pro Tier definiert ist und auf viele identische Server wiederverwendet wird.

Es gibt eine explizite Grenze, die die REST des Moduls 3 regelt. NSGs und NIC-Feuerwände binden nur an die Netzwerkschnittstellen von VM. Sie gelten nicht für die gemanagten Lastenausgleichsgeräte (die Managed Application Load Balancer und Managed Network Load Balancer) und sie gelten nicht für die Managed Kubernetes-Cluster-Abstraktion. Konkret können Sie keine Managed Kubernetes-Node-Poolknoten (oder suspendierte Cubes) einer NSG hinzufügen. Dies ist der Grund, warum die geschichtete Architektur die Datenebene mit der Topologie isoliert und die Filterung auf den Zielen hinter einem Ausgleichsgerät und nicht auf dem Ausgleichsgerät selbst platziert: das gemanagte ALB hat keine dedizierte Firewall-Regel seiner eigenen, und das gemanagte NLB enthält nur grundlegende, unveränderliche Firewall-Regeln, die automatisch aus seinen Weiterleitungsregeln generiert werden, sodass alle kundenkonfigurierbaren Zulassungsregeln auf den NICs der Backend-VMs oder deren NSGs leben. Behandeln Sie dies als einen Planungseingabe und nicht als eine Lücke: das native Muster ist die Filterung auf der Zielseite plus private Standardplatzierung.

Eine operative Vorsicht bei der Zugriffskontrolle: das Deaktivieren der NSG-Berechtigung für einen Subbenutzer sperrt diesen nicht vollständig aus. Ein Benutzer, der immer noch auf das relevante Rechenzentrum zugreifen kann, kann bestehende NSGs weiterhin verwalten; die Berechtigung kontrolliert die Erstellung und Verwendung von NSGs, nicht die Verwaltung von Gruppen, die bereits existieren. Planen Sie die Gruppenzugehörigkeit und den Rechenzentrumszugriff zusammen.

DCD Implementierung Schritt-für-Schritt

Sie werden Regeln von Firewall von Schicht zu Schicht auf die FinCorp-Anwendungsserver anwenden und dann einen Fluss-Log auf einer NIC aktivieren, damit das Sicherheitsteam überprüfen kann, was Firewall akzeptiert und ablehnt. Dies realisiert die Durchsetzungsschicht über die dreifache LAN-Topologie aus Einheit 3.1. Voraussetzungen: Das VDC und seine Server-NICs aus Einheit 3.1 müssen bereits existieren, und ein benutzerdefinierter Object Storage-Bucket muss vor der Fluss-Log-Zuweisung existieren (nur Vertragsadministratoren und Besitzer können Object Storage aktivieren, und der Fluss-Log-Ersteller benötigt die Berechtigung "Create Flow Logs").

Ziel: Regeln von Firewall zwischen Schichten anwenden; einen Fluss-Log auf einen Object Storage-Bucket aktivieren.

Schritte (im Data Center Designer):

1. Öffnen Sie das VDC und wählen Sie im Workspace einen Anwendungsserver-Schicht-Server, der eine NIC auf dem privaten Anwendungs-LAN hat.
2. Im Inspector-Fenster öffnen Sie den Netzwerk-Tab und dann die Eigenschaften der NIC, die Sie schützen möchten.
3. Aktivieren Sie Firewall auf dieser NIC, indem Sie den Typ des Datenverkehrsflusses auswählen, den Sie durchsetzen möchten: Eingehend, Ausgehend oder Bidirektional. Sobald aktiviert und ohne Regeln, blockiert die NIC den gesamten eingehenden Datenverkehr, daher sollten Sie Regeln definieren, bevor Sie sich darauf verlassen.
4. Klicken Sie auf "Regeln verwalten", dann auf "Firewall-Regel erstellen" und wählen Sie das Protokoll für die Regel (TCP, UDP, ICMP, ICMPv6, VRRP, GRE, AH, ESP oder beliebiges Protokoll). Für den App-zu-Datenbank-Fluss erstellen Sie eine TCP-Regel.
5. Füllen Sie die Regel-Felder: Ein Name; Richtung (Ausgehend für den App-Server, der die Datenbank erreicht); Quell-IP/CIDR und Ziel-IP/CIDR, die auf die privaten Bereiche beschränkt sind; und den Ziel-Port für die Datenbank. Lassen Sie IP-Version als "Auto", sofern Sie keine Familie festlegen. Die Zustands-Firewall ermöglicht den automatischen Rückverkehr, daher ist keine eingehende Antwortregel erforderlich.
6. Für rollenbasierte Server können Sie optional "Regeln aus Vorlage" (Allgemeiner Webserver, Mailserver, Remote-Zugriff-Linux, Remote-Zugriff-Windows) als Ausgangspunkt verwenden und die Quellen dann einschränken; oder Sie können "Regeln klonen" von einer anderen NIC verwenden, um identische Server konsistent zu halten. Klicken Sie auf "Speichern".
7. Um einen Fluss-Log auf der gleichen NIC zu aktivieren, öffnen Sie das NIC-Eigenschaften-Fluss-Log-Drop-down-Menü (für ein Managed NLB oder Managed NAT Gateway würden Sie stattdessen das Elemente-Einstellungen-Tab verwenden) und geben Sie einen Namen ein. Dieser Name wird zum ersten Teil des Objekt-Namen-Präfix im Bucket.
8. Legen Sie die Richtung (Eingehend, Ausgehend oder Bidirektional), Aktion (Abgelehnt, um nur blockierten Datenverkehr aufzuzeichnen, Akzeptiert, um nur zugelassenen Datenverkehr aufzuzeichnen, oder Beliebig) und das Ziel-Object Storage-Bucket: einen gültigen, existierenden benutzerdefinierten Bucket-Namen plus einem optionalen Objekt-Namen-Präfix. Wählen Sie "Fluss-Log hinzufügen".
9. Ein grünes Licht in den NIC-Eigenschaften bestätigt, dass die Konfiguration validiert wurde. Wählen Sie "Änderungen bereitstellen". Nachdem die Bereitstellung abgeschlossen ist, sind sowohl die Firewall-Regeln als auch der Fluss-Log aktiv, und pro-Fluss-Aufzeichnungen beginnen, im Bucket als gzip-komprimierte .log.gz-Dateien zu landen.

Jede Fluss-Aufzeichnung ist pro-Fluss, aggregiert über einen festen 10-Minuten-Intervall ohne Stichproben (alle Flüsse im Intervall werden aufgezeichnet), und Intervalle ohne Datenverkehr werden übersprungen. Jede Aufzeichnung enthält Felder, einschließlich Quell- und Ziel-Adresse und -Port, IANA-Protokoll-Nummer, Paket- und Byte-Zählungen, Start- und End-Timestamps und ein action-Feld von AKZEPTIEREN oder ABLEHNEN. Das action-Feld ist genau das Überprüfungssignal: Legen Sie die Fluss-Log-Aktion auf ABLEHNEN, wenn Sie nur sehen möchten, was Firewall ablehnt, was der schnellste Weg ist, um eine fehlende Zulassungsregel zu finden, oder AKZEPTIEREN, um zu bestätigen, dass nur die beabsichtigten Flüsse durchkommen.

Häufige Fehler:

• Aktivieren Sie Firewall auf einer NIC und gehen Sie dann weg. Mit Firewall aktiviert und ohne Regeln blockiert die NIC den gesamten eingehenden Datenverkehr; definieren Sie die Zulassungsregeln in der gleichen Änderung.
• Schreiben Sie eine Rückverkehrsregel. Firewall und NSGs sind zustandsbehaftet, daher sind die Antworten auf eine zugelassene ausgehende Verbindung automatisch zugelassen. Eine Spiegel-Regel für den eingehenden Datenverkehr ist redundant und verkompliziert die Richtlinie.
• Führen Sie NSGs und die NIC-Firewall parallel für die gleichen NICs aus. Paralleler Einsatz ist nicht das empfohlene Muster; wählen Sie ein Durchsetzungsmodell pro Umgebung.
• Lassen Sie die Standard-NSG für eine regulierte Schicht in place. Sie erlaubt den gesamten ausgehenden und ost-westlichen Datenverkehr innerhalb des VDC; ersetzen Sie sie durch benutzerdefinierte Ablehnungsgruppen, die nur die erforderlichen Flüsse gewähren.
• Erwarten Sie, dass ein Firewall oder eine NSG einen verwalteten Load Balancer oder Kubernetes-Knoten schützt. Keine dieser Konstrukte bindet dort. Legen Sie die Zulassungsregeln auf den Backend-VM-NICs und verwenden Sie In-Cluster-Netzwerkpolicies für Kubernetes.
• Zeigen Sie einen Fluss-Log auf einen Bucket, der noch nicht existiert, oder einen, der nicht von Ihrem Vertrag besessen wird. Das Ziel muss ein existierender, benutzerdefinierter Object Storage-Bucket sein; erstellen Sie ihn zuerst.
• Nehmen Sie an, dass das Löschen der Fluss-Log-Regel die Daten bereinigt. Das Löschen der Regel stoppt neue Aufzeichnungen, löscht aber keine vorhandenen Log-Objekte aus dem Bucket und ändert ihre Richtlinien oder ACLs nicht.
• Behandeln Sie Flow Logs als einen verwalteten Aufbewahrungs-Service. Es gibt einen Fluss-Log pro Ressource, das Aufzeichnungsformat und die Konfiguration sind nach der Erstellung unveränderlich, und die Aufbewahrung wird vollständig vom Kunden verwaltet: Legen Sie eine Object Storage-Lebenszyklus-Richtlinie auf dem Ziel-Bucket fest (oder löschen Sie sie manuell). Nichts läuft automatisch ab, es sei denn, Sie konfigurieren es.

Ein kurzer ionosctl-Check nach der Bereitstellung bestätigt die Firewall-Regeln, die an die NIC angehängt sind, was in einem Prüfskript nützlich ist:

ionosctl firewallrule list --datacenter-id "$DC_ID" \
  --server-id "$SRV_ID" --nic-id "$NIC_ID"

Der architektonische Punkt ist, dass die Regelsammlung abfragbar und daher überprüfbar als Konfiguration ist. Die Entscheidung zur Durchsetzung lebt jedoch immer noch im obigen Design, nicht im Befehl.

Zusammenfassung

Die dreistufige Topologie von FinCorp wird erst dann zu einer Sicherheitsgrenze, wenn die Durchsetzung an den Server-NICs angewendet wird. Sowohl die pro-NIC-Firewall als auch die Network Security Groups binden an VM-Schnittstellen, sind zustandsbehaftet und verweigern standardmäßig, sobald sie aktiv sind (mit der bemerkenswerten Ausnahme der permissiven Standard-NSG). NSGs sind vorteilhaft, wenn eine Richtlinie viele Schnittstellen regeln muss; die pro-NIC-Firewall eignet sich für Einzelfallausnahmen. Kritisch ist, dass weder die Konstruktion die gemanagten Lastverteilungs-Managed Kubernetes noch die Cluster-Abstraktion erreicht, was die Filterung auf die Ziele und die private Standardplatzierung verstärkt. Flow Logs schließen den Kreis: Sie schreiben unveränderliche, pro-Fluss-AKZEPTIEREN/ABLEHNEN-Aufzeichnungen in einen benutzerdefinierten Object Storage-Bucket, wodurch "was macht die Firewall eigentlich" von einer Annahme zu einem Beweis wird.

Wichtige Punkte:

• Die NIC-Firewall und benutzerdefinierten NSGs sind standardmäßig abgelehnt, sobald sie aktiv sind; jeder zugelassene Fluss ist eine explizite Regel, und das geringste Privileg wird durch Nicht-Zuweisung erreicht.
• Beide sind zustandsbehaftet, sodass Rückverkehr für eine zugelassene Verbindung automatisch zugelassen ist; schreiben Sie keine Spiegelregeln.
• NSGs sind wiederverwendbare VDC-Ebene-Richtlinien (bis zu 10 pro NIC/VM, 100 Regeln pro Richtlinie, 200 pro VDC); die NIC-Firewall ist lokal. Eine parallele Verwendung beider wird nicht empfohlen.
• NSGs und NIC-Feuerwände gelten nicht für gemanagte Lastverteilungs-Managed Kubernetes oder für Managed Kubernetes-Node-Poolknoten; die Filterung wird auf die Ziele und auf in-Cluster-Netzwerkpolicies verlagert.
• Flow Logs veröffentlichen pro-Fluss-Aufzeichnungen (10-Minuten-Aggregation, keine Stichproben) mit einem AKZEPTIEREN/ABLEHNEN-Aktionsfeld in einem benutzerdefinierten Object Storage-Bucket; es gibt eine Flussprotokoll pro Ressource, das Format ist unveränderlich, und die Aufbewahrung wird vom Kunden über eine Lebenszyklusrichtlinie gemanagt.