Einheit 3.2: Netzwerksicherheit: Firewall und Security Groups

Einführung

Die Segmentierung in Einheit 3.1 hat FinCorp drei LANs bereitgestellt: einen öffentlichen Rand, eine private Anwendungsschicht und eine ausschließlich private Datenschicht. Die Topologie allein erzwingt nicht, wer mit wem kommunizieren darf. Die Erzwingungsschicht befindet sich an den Server-NICs und ist die nächste Entscheidung im Netzwerkdesign: Ein Firewall pro NIC und Network Security Groups sind beide an die Netzwerkschnittstellen virtueller Maschinen gebunden und verweigern standardmäßig alles, sobald sie aktiviert werden.

Diese Einheit schließt mit dem Aufbau dieser Erzwingung im Data Center Designer für die FinCorp-Umgebung ab: Firewall-Regeln, die nur die zwischen den Schichten verlaufenden Datenströme zulassen, die die Architektur erfordert, sowie ein Flow-Log, das in einen Object Storage-Bucket geschrieben wird, damit das Sicherheitsteam nachträglich genau überprüfen kann, welche Verbindungen akzeptiert und welche abgelehnt wurden. Vor dem Aufbau müssen zwei Dinge klar sein: wie die Firewall den Verkehr auswertet und wo die Firewall-Konstrukte nicht mehr greifen.

1. Funktionsweise der NIC-Firewall und der Verweigerungsstandardvertrag

Die IONOS CLOUD-Firewall ist eine Eigenschaft einer einzelnen Server-NIC, nicht eines Subnets, eines LANs oder des gesamten VDC. Eine NIC ohne Firewall lässt den gesamten Datenverkehr durch. Sobald Sie die Firewall auf dieser NIC aktivieren, kehrt sich der Vertrag um: Bei aktivierter Firewall und ohne definierte Regeln wird der gesamte eingehende Datenverkehr blockiert. Jede Verbindung, die Sie zulassen möchten, ist dann eine explizite Erlaubnisregel. Es gibt keine separate „Verweigerungsregel“, die Sie schreiben müssen, und das Prinzip der geringsten Berechtigung wird einfach dadurch erreicht, dass Sie keine Regel hinzufügen, was der Zugriffssteuerungsposition entspricht, die Sie in der Governance gesehen haben.

Die Firewall ist zustandsbehaftet. Wenn eine Regel eine ausgehende Verbindung zulässt, werden die entsprechenden Antwortpakete automatisch zurückgelassen; Sie schreiben keine gespiegelte Regel für den Antwortdatenverkehr. Dies ist für die Anwendungsschicht der FinCorp-Anwendung von Bedeutung: Eine Regel, die den App-Servern den Zugriff auf den PostgreSQL-Endpunkt in der Datenschicht erlaubt, erlaubt auch, dass die Abfrageergebnisse zurückfließen, ohne eine zweite eingehende Regel auf der App-NIC für die Antwort der Datenbank.

Regeln können pro Richtung angewendet werden. Bei der Aktivierung der Firewall wählen Sie Ingress, Egress oder Bidirectional, und jede Regel selbst trägt eine Richtung von Ingress oder Egress. Eine Regel wird anhand des Protokolls und der relevanten Felder für dieses Protokoll abgeglichen. Die unterstützten Protokolle sind TCP, UDP, ICMP, ICMPv6, VRRP, GRE, AH und ESP, plus die Option „Jedes Protokoll“. 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 Quell-MAC, Quell-IP/CIDR und Ziel-IP/CIDR einschränken, wobei das Zielfeld 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 Regelvorlagen. Die folgenden Vorlagen sind verfügbar und befüllen einen typischen Regelsatz vorab:

Eine Vorlage ist ein Ausgangspunkt, keine fertige Richtlinie. Die Generic Webserver-Vorlage erlaubt beispielsweise HTTP und HTTPS von allen Quellen, was für eine internetzugewandte Edge-NIC angemessen ist, aber für eine private Schicht falsch ist. Regeln können auch von einer anderen NIC kopiert werden, was eine Flotte identischer Server konsistent hält. Der Firewall-Datenpfad ist laut Faktenmatrix für bis zu 6 Gbps Durchsatz pro NIC ausgelegt, was für die Filterung zwischen Schichten ausreichend ist, aber eine Zahl, die man für NICs mit sehr hoher Bandbreite im Hinterkopf behalten sollte.

2. NSGs im Vergleich zur NIC-Firewall und die Grenze, an der keine der beiden greift

Die Firewall pro NIC ist lokal: Ihre Regeln befinden sich auf einer einzelnen NIC und werden dort verwaltet. Network Security Groups lösen das Skalierungsproblem. Eine NSG ist ein benanntes, wiederverwendbares Regelset, das auf VDC-Ebene erstellt und anschließend an Server oder NICs angehängt wird. So kann eine einzige Richtlinie viele Schnittstellen steuern, und eine Änderung an der Gruppe wird auf jedes angehängte Mitglied übertragen. NSGs können über den DCD, die Cloud API, die Go Cloud SDK und Terraform verwaltet werden.

Jede neu erstellte VM in einem VDC wird automatisch der Default NSG hinzugefügt, die mit vier vordefinierten Regeln ausgeliefert wird: Erlaubnis aller IPv4-Ausgangsdaten, Erlaubnis aller IPv6-Ausgangsdaten, Erlaubnis von IPv4-Eingangsdaten nur aus dem Bereich 10.0.0.0/24 des VDC und Erlaubnis von IPv6-Eingangsdaten nur aus dem dem Rechenzentrum zugewiesenen /56 IPv6 CIDR. Diese Voreinstellung ist bei Ausgangsdaten und Ost-West-Verkehr absichtlich permissiv. Ein regulierter Tenant wie FinCorp ersetzt sie daher in der Regel durch benutzerdefinierte Gruppen, die nur die erforderlichen Datenflüsse gewähren. Benutzerdefinierte NSGs sind standardmäßig deny-all, ähnlich wie die NIC-Firewall. Jeder erlaubte Datenfluss ist daher erneut eine explizite Regel.

NSGs sind zustandsbehaftet, unterstützen sowohl INGRESS- als auch EGRESS-Regeln und akzeptieren den Protokollsatz 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. Das Anhängen ist granular: Eine Gruppe kann auf VM-Ebene angehängt werden, wo sie alle NICs dieser VM abdeckt, oder auf der Ebene der einzelnen NIC für eine engere Steuerung. Wenn eine VM Mitglied einer NSG ist, erben alle NICs dieser VM implizit die Regeln.

Die folgende Tabelle stellt die beiden Konzepte gegenüber, um zu verdeutlichen, wo jeweils der richtige Einsatzort ist:

Ein häufiges Designmuster ist es, beide Ebenen für eine vertiefte Verteidigung zu kombinieren. Seien Sie hier bewusst: Die Faktenmatrix dokumentiert, dass die parallele Nutzung von NSGs und der NIC-Firewall nicht das empfohlene Muster ist. Wählen Sie daher ein Durchsetzungsmodell pro Umgebung, anstatt sich überlappende Regelsätze zu betreiben, die schwer nachvollziehbar sind. Für FinCorp sind NSGs die bessere Wahl, da die Sicherheitsrichtlinie pro Ebene definiert und über viele identische Server hinweg wiederverwendet wird.

Es gibt eine explizite Grenze, die den Rest von Modul 3 bestimmt. NSGs und NIC-Firewalls binden ausschließlich an Netzwerkschnittstellen von VMs. Sie gelten NICHT für die verwalteten Load Balancer (den Managed Application Load Balancer und den Managed Network Load Balancer) und sie gelten NICHT für die Managed Kubernetes Cluster-Abstraktion. Konkret können Sie Knoten aus Managed Kubernetes Node-Pools (oder pausierten Cubes) nicht einer NSG hinzufügen. Aus diesem Grund isoliert die geschichtete Architektur die Datenebene über die Topologie und platziert die Filterung auf den Zielen hinter einem Load Balancer, nicht auf dem Load Balancer selbst: Der Managed ALB verfügt über keine eigene dedizierte Firewall, und der Managed NLB trägt nur grundlegende, unveränderliche Firewall-Regeln, die automatisch aus seinen Weiterleitungsregeln generiert werden. Alle vom Kunden konfigurierbaren Erlaubnisregeln befinden sich daher auf den NICs der Backend-VMs oder deren NSGs. Betrachten Sie dies als Eingabe für das Design, nicht als Lücke: Das native Muster ist Filterung auf der Zielseite plus standardmäßig private Platzierung.

Ein betrieblicher Hinweis zur Zugriffskontrolle: Das Deaktivieren des NSG-Privilegs für einen Sub-Benutzer schließt diesen nicht vollständig aus. Ein Benutzer, der weiterhin Zugriff auf das relevante Rechenzentrum hat, kann bestehende NSGs weiterhin verwalten. Das Privileg steuert das Erstellen und Verwenden von NSGs, nicht die Verwaltung bereits existierender Gruppen. Planen Sie die Gruppenbesitzverhältnisse und den Rechenzentrumszugriff gemeinsam.

Durchführungsanleitung zur DCD-Implementierung

Sie wenden Firewall-Regeln zwischen den Ebenen auf die Anwendungsserver von FinCorp an und aktivieren anschließend ein Flow Log auf einer NIC, damit das Sicherheitsteam überprüfen kann, welche Datenpakete von der Firewall akzeptiert und welche abgelehnt werden. Damit wird die Durchsetzungsebene über der Topologie mit drei LANs aus Einheit 3.1 umgesetzt. Voraussetzungen: Das VDC und seine Server-NICs aus Einheit 3.1 müssen bereits existieren, und ein vom Nutzer gehaltener Object Storage-Bucket muss vorhanden sein, bevor das Flow Log diesen als Ziel verwenden kann (nur Vertragsverwalter und Eigentümer können Object Storage aktivieren, und der Ersteller des Flow Logs benötigt das Berechtigungsfeld Create Flow logs).

Ziel der Umsetzung: Firewall-Regeln zwischen den Ebenen anwenden; ein Flow Log zu einem Object Storage-Bucket aktivieren.

Schritte (im Data Center Designer):

1. Öffnen Sie das VDC und wählen Sie im Workspace einen Server der Anwendungsebene aus, der eine NIC auf dem privaten Anwendungs-LAN besitzt.
2. Öffnen Sie im Inspector-Bereich den Tab Netzwerk und anschließend die Eigenschaften der NIC, die Sie schützen möchten.
3. Aktivieren Sie die Firewall auf dieser NIC, indem Sie den durchzusetzenden Datenfluss-Typ wählen: Ingress, Egress oder Bidirectional. Ist die Firewall aktiv, aber noch keine Regeln definiert, blockiert die NIC den gesamten eingehenden Verkehr. Definieren Sie daher Regeln, bevor Sie sich auf die Firewall verlassen.
4. Klicken Sie auf Manage Rules, dann auf Create Firewall Rule und wählen Sie das Protokoll für die Regel (TCP, UDP, ICMP, ICMPv6, VRRP, GRE, AH, ESP oder Any Protocol). Für den Datenfluss von der Anwendung zur Datenbank erstellen Sie eine TCP-Regel.
5. Füllen Sie die Felder der Regel aus: einen Namen; Richtung (Egress für den Anwendungsserver, der die Datenbank erreicht); Quell-IP/CIDR und Ziel-IP/CIDR, eingeschränkt auf die privaten Bereiche; sowie den Zielport der Datenbank. Lassen Sie IP Version auf Auto, es sei denn, Sie möchten eine bestimmte IP-Familie festlegen. Die zustandsbehaftete Firewall erlaubt den Rückkehrverkehr automatisch, sodass keine eingehende Antwortregel erforderlich ist.
6. Für rollenbasierte Server können Sie optional Rules from Template (Generic Webserver, Mailserver, Remote Access Linux, Remote Access Windows) als Ausgangspunkt verwenden und die Quellen anschließend einschränken; oder verwenden Sie Clone Rules von einer anderen NIC, um identische Server konsistent zu halten. Klicken Sie auf Save.
7. Um ein Flow Log auf derselben NIC zu aktivieren, öffnen Sie das Dropdown-Menü Flow Log in den Eigenschaften der NIC (für einen Managed NLB oder Managed NAT Gateway würden Sie stattdessen den Tab Einstellungen des Elements verwenden) und geben Sie einen Namen ein. Dieser Name wird zum ersten Teil des Objekt-Namenspräfixes im Bucket.
8. Setzen Sie Richtung (Ingress, Egress oder Bidirectional), Aktion (Rejected, um nur blockierten Verkehr aufzunehmen; Accepted, um nur erlaubten Verkehr aufzunehmen; oder Any) sowie den Ziel-Object Storage-Bucket: einen gültigen, vorhandenen, vom Nutzer gehaltenen Bucket-Namen plus ein optionales Objekt-Namenspräfix. Wählen Sie Add flow log.
9. Ein grünes Licht in den Eigenschaften der NIC bestätigt, dass die Konfiguration validiert wurde. Wählen Sie PROVISION CHANGES. Nach Abschluss der Bereitstellung sind sowohl die Firewall-Regeln als auch das Flow Log aktiv, und die Aufzeichnungen pro Datenfluss beginnen als gzip-komprimierte .log.gz-Dateien im Bucket zu landen.

Jede Aufzeichnung ist pro Datenfluss, aggregiert über ein festes Intervall von 10 Minuten, ohne Stichprobenbildung (alle Datenflüsse im Intervall werden erfasst), und Intervalle ohne Verkehr werden übersprungen. Jede Aufzeichnung enthält Felder wie Quell- und Zieladresse und -Port, IANA-Protokollnummer, Paket- und Byteanzahl, Start- und Endzeitstempel sowie ein action-Feld mit dem Wert ACCEPT oder REJECT. Das action-Feld ist genau das Verifikationssignal: Setzen Sie die Aktion des Flow Logs auf Rejected, wenn Sie nur sehen möchten, was die Firewall verwirft, was der schnellste Weg ist, eine fehlende Erlaubnisregel zu finden, oder auf Accepted, um zu bestätigen, dass nur die beabsichtigten Datenflüsse durchkommen.

Häufige Fehler:

• Die Firewall auf einer NIC aktivieren und dann nicht weiter vorgehen. Ist die Firewall aktiv und keine Regeln definiert, blockiert die NIC den gesamten eingehenden Verkehr; definieren Sie die Erlaubnisregeln in derselben Änderung.
• Eine Regel für den Rückkehrverkehr schreiben. Die Firewall und die NSGs sind zustandsbehaftet, sodass die Antworten zu einer erlaubten ausgehenden Verbindung automatisch erlaubt werden. Eine spiegelnde eingehende Regel ist redundant und unübersichtlich.
• NSGs und die NIC-Firewall parallel für dieselben NICs betreiben. Parallelbetrieb ist nicht das empfohlene Muster; wählen Sie pro Umgebung ein Durchsetzungsmodell.
• Die Standard-NSG für eine regulierte Ebene beibehalten. Sie erlaubt allen ausgehenden und Ost-West-Verkehr innerhalb des VDC; ersetzen Sie sie durch benutzerdefinierte Gruppen, die alles verweigern und nur die erforderlichen Datenflüsse erlauben.
• Zu erwarten, dass eine Firewall oder eine NSG einen verwalteten Load Balancer oder Kubernetes-Knoten schützt. Weder Konstruktion ist dort gebunden. Legen Sie die Erlaubnisregeln auf den Backend-VM-NICs an und verwenden Sie In-Cluster-Netzwerkrichtlinien für Kubernetes.
• Ein Flow Log auf einen Bucket zeigen, der noch nicht existiert oder dem nicht von Ihrem Vertrag zugeordnet ist. Das Ziel muss ein vorhandener, vom Nutzer gehaltener Object Storage-Bucket sein; erstellen Sie ihn zuerst.
• Annahmen zu treffen, dass das Löschen der Flow-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 auch deren Richtlinien oder ACLs nicht.
• Flow Logs als verwalteten Aufbewahrungsdienst zu betrachten. Es gibt ein Flow Log pro Ressource, das Aufzeichnungsformat und die Konfiguration sind nach der Erstellung unveränderlich, und die Aufbewahrung liegt vollständig in der Verantwortung des Kunden: Richten Sie eine Object Storage-Lebenszyklusrichtlinie auf dem Ziel-Bucket ein (oder löschen Sie manuell). Nichts läuft automatisch ab, es sei denn, Sie konfigurieren es.

Eine kurze ionosctl-Prüfung nach der Bereitstellung bestätigt die an die NIC gebundenen Firewall-Regeln, was in einem Audit-Skript nützlich ist:

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

Der architektonische Aspekt besteht darin, dass der Regelwerk abfragbar und somit als Konfiguration auditierbar ist; die Durchsetzungsentscheidung verbleibt jedoch im oben beschriebenen Design und nicht im Befehl.

Zusammenfassung

Die dreistufige Topologie von FinCorp wird erst dann zu einer Sicherheitsgrenze, wenn die Durchsetzung auf der Ebene der Server-NICs erfolgt. Sowohl die Firewall pro NIC als auch Network Security Groups sind an VM-Schnittstellen gebunden, zustandsbehaftet und verweigern standardmäßig den Zugriff, sobald sie aktiv sind (mit der bemerkenswerten Ausnahme der permissiven Standard-NSG). NSGs sind vorteilhaft, wenn eine einzige Richtlinie viele Schnittstellen regeln muss; die Firewall pro NIC eignet sich für einmalige Ausnahmen. Entscheidend ist, dass weder Konstrukt auf die verwalteten Load Balancer oder die Managed Kubernetes Cluster-Abstraktion zugreift, was die Filterung auf die Zielsysteme verlagert und die standardmäßig private Platzierung verstärkt. Flow Logs schließen den Kreis: Sie schreiben unveränderliche, pro Flow erstellte ACCEPT/REJECT-Einträge in einen vom Kunden verwalteten Object Storage Bucket und verwandeln „Was tut die Firewall tatsächlich?“ von einer Annahme in einen Nachweis.

Wichtige Punkte:

• Die NIC-Firewall und benutzerdefinierte NSGs verweigern standardmäßig den Zugriff, sobald sie aktiv sind; jeder erlaubte Flow ist eine explizite Regel, und das Prinzip der geringsten Berechtigung wird erreicht, indem Berechtigungen nicht erteilt werden.
• Beide sind zustandsbehaftet, sodass Rückkehrverkehr für eine erlaubte Verbindung automatisch zugelassen wird; Spiegelregeln sollten nicht erstellt werden.
• NSGs sind wiederverwendbare Richtlinien auf VDC-Ebene (bis zu 10 pro NIC/VM, 100 Regeln je NSG, 200 pro VDC); die NIC-Firewall ist lokal. Die parallele Nutzung beider Mechanismen wird nicht empfohlen.
• NSGs und NIC-Firewalls gelten nicht für verwaltete Load Balancer oder für Knoten in Managed Kubernetes Node Pools; die Filterung verlagert sich auf die Zielsysteme und auf Netzwerkrichtlinien innerhalb des Clusters.
• Flow Logs veröffentlichen pro-Flow-Einträge (Aggregation über 10 Minuten, keine Stichprobenziehung) mit einem ACCEPT/REJECT-Aktionsfeld in einem vom Benutzer verwalteten Object Storage Bucket; es gibt einen Flow Log pro Ressource, das Format ist unveränderlich, und die Aufbewahrungsdauer wird vom Kunden über eine Lifecycle-Richtlinie verwaltet.