Sophos Firewall auf AWS bereitstellen und betreiben

Sophos Firewall läuft in AWS als EC2-Appliance inline in einer VPC. Vor dem Deployment muss entschieden werden, ob eine einzelne Firewall oder eine dynamische Auto-Scaling-Gruppe benötigt wird. Die Varianten teilen weder Lizenzmodell noch Interface- und Trafficverhalten vollständig.

⚠️ AWS Security Groups bleiben eine zweite Firewall-Ebene. Eine erlaubende SFOS-Regel reicht nicht, wenn Security Group, NACL oder Route Table den Pfad blockiert. Umgekehrt darf ein offener AWS-Port nicht durch eine breite Sophos-Regel ergänzt werden.

Standalone oder Auto Scaling

Modell	Geeignet für	Wichtige Grenze
Standalone BYOL	Langfristige Appliance mit eigener Sophos-Lizenz	EC2-Kosten bleiben zusätzlich; Lizenz-Cores müssen zur Instanz passen.
Standalone PAYG	Stundenbasierter Betrieb und Pilot	FullGuard wird über AWS verrechnet; regionale Verfügbarkeit prüfen.
Auto Scaling PAYG	Schwankender eingehender DNAT- oder WAF-Traffic	Nur PAYG, Single-Arm über PortB und nur Inbound-Traffic. Kein normaler LAN-zu-WAN-Egress-Pfad.

AWS unterstützt für Sophos Firewall kein natives Appliance-HA. Auto Scaling und Load Balancing sind ein eigenes Cloud-Design und kein Ersatz für die SFOS-HA-Synchronisation.

Standalone mit CloudFormation bereitstellen

Im AWS Marketplace das BYOL- oder PAYG-Angebot wählen, Bedingungen akzeptieren und Region sowie aktuelle SFOS-Version festlegen.
Launch CloudFormation verwenden und entscheiden, ob eine neue oder bestehende VPC genutzt wird.
Bei einer bestehenden VPC Public Subnet, Private Subnet, VPC-ID und vorhandene oder neue Elastic IP eindeutig zuordnen.
EC2-Grösse nach Traffic und Lizenz wählen. Für BYOL darf die Instanz die lizenzierten Cores nicht überschreiten.
IAM-Erstellung im Template nur nach Review bestätigen und Stack starten.
Nach CREATE_COMPLETE die Elastic IP aus Outputs lesen und warten, bis auch die EC2-Statusprüfungen abgeschlossen sind.
WebAdmin zuerst nur aus einer festen Adminquelle über https://<EIP>:4444 öffnen, Terms akzeptieren und die normale Registrierung durchführen.
PortA, PortB, Route Tables, Source/Destination Check, Security Groups, NACLs und Rückweg mit einem definierten Testfluss prüfen.

Standardmässig öffnet das Template nur Managementzugriffe. IPsec, SSL VPN, RED, WAF oder Portale benötigen zusätzlich passende AWS-Security-Group-Regeln. Beispielsweise braucht RED TCP 3410. Die Quelle wird so eng wie möglich gesetzt, niemals vorsorglich 0.0.0.0/0 für SSH oder WebAdmin.

Auto Scaling sicher betreiben

Auto Scaling registriert Worker automatisch über einen Sophos-Central-Service-Principal in einer Firewallgruppe. Zwei Availability Zones, Minimum-, Starting- und Maximum-Capacity sowie der Warm-Pool-Refresh werden vorab festgelegt. Trusted Network CIDR enthält die öffentliche Adminadresse als /32, nicht 0.0.0.0/0. Public Network CIDR wird nach dem Deployment auf die echten Quellnetze reduziert.

Die Worker sind kurzlebig. Wenn CloudWatch aktiviert wurde, liegen Logs in Gruppen unter /sophos/xg/. Beendete EC2-Instanzen bleiben in der Central-Firewallgruppe sichtbar und müssen dort manuell entfernt werden. Ein Warm Pool synchronisiert gestoppte Instanzen in seinem Intervall, ersetzt aber nicht die Kontrolle, ob eine neue Gruppenpolicy wirklich auf allen laufenden Workern angekommen ist.

DNAT hinter dem Network Load Balancer

Für einen freigegebenen Dienst führt der AWS Network Load Balancer den Listener zu einer Target Group der Firewall-Worker. In der Central-Gruppenpolicy werden WAN-Subnetze beider Availability Zones als IP-Ranges, Zielhost und exakter Dienst angelegt. Die Firewallregel matcht WAN zu WAN auf diese Ranges; die DNAT-Regel übersetzt zum internen Server und verwendet bei diesem Design MASQ für einen symmetrischen Rückweg.

Das offizielle Beispiel verwendet RDP. Direkte RDP-Veröffentlichung ist keine Empfehlung. Wenn möglich werden VPN oder ZTNA eingesetzt. Ist DNAT unvermeidbar, werden Quelladressen am NLB, in AWS und in SFOS eingeschränkt, IPS und Logging aktiviert und ein negativer Test aus einer nicht erlaubten Quelle durchgeführt.

Abnahme und Betrieb

Die Abnahme prüft AWS-Route, Security Group, NACL, NLB-Health, SFOS Rule ID, DNAT, Rückweg, Central-Gruppenstatus und Logs gemeinsam. Danach werden Owner, Kostenalarm, Firmwareprozess, Lizenz, CloudWatch-Aufbewahrung, Central-Bereinigung und Wiederaufbau aus CloudFormation dokumentiert. Ein EC2-Snapshot ersetzt kein exportiertes SFOS-Backup.