BEKOM MANAGEDOPNsense FirewallBSI-konform und betriebsdokumentiert
OPNsense als Managed-Firewall-Hosting bei BEKOM: dedizierte Instanz, wählbare Verfügbarkeitsstufen, BSI-konforme Betriebsdokumentation und schriftliches Angebot nach Anforderungsgespräch.
Wann OPNsense-Hosting bei BEKOM passt
Eine Firewall ist keine austauschbare Einzelkomponente – an ihr hängen Internet-Anbindung, Standort-VPN, segmentierte Netzwerk-Zonen und in vielen Fällen die Compliance-Belege gegenüber Audit, Versicherung oder Aufsichtsbehörde. Wer OPNsense als Plattform gewählt hat, Hardware-Beschaffung, 24/7-Bereitschaft und auditfähige Betriebsdokumentation aber nicht intern leisten will, braucht einen Firewall-erfahrenen Betriebspartner. BEKOM betreibt OPNsense als Firewall-as-a-Service im deutschen Rechenzentrum mit dedizierter Instanz, individualisierter Architektur und dokumentierter Eskalationskette.
Typische Auslöser für ein Managed-OPNsense
Drei Konstellationen führen Organisationen erfahrungsgemäß zum Managed-OPNsense bei einem spezialisierten Sicherheits-Betreiber statt zum reinen Hardware-Eigenbetrieb oder zur kommerziellen NGFW-Subscription.
Häufige Ausgangslagen:
Auslagerung der Perimeter-Firewall ins Rechenzentrum – Die OPNsense läuft heute on-premise; der Aufwand für Hardware-Refresh, Wartung und 24/7-Eskalation soll an einen Spezialisten abgegeben werden, ohne den Hersteller zu wechseln oder Regelwerke neu zu entwickeln.
Aufbau einer externen Sicherheitszone – Eine zusätzliche Firewall im BEKOM-Rechenzentrum ergänzt die On-Premise-Landschaft, etwa als VPN-Hub für Außenstellen, als isolierte DMZ für extern erreichbare Dienste oder als Cloud-Edge mit zentraler Richtlinien-Kontrolle.
KRITIS- oder Audit-Anforderung an Betriebsdokumentation – Eine bestehende Eigenbetrieb-Firewall erfüllt zwar funktional, doch dokumentierter Change-Prozess, Patch-Reporting und Auditspur fehlen für die nächste Prüfung nach BSI-Grundschutz, ISO 27001 oder TISAX.
Wann sich OPNsense-Hosting bei BEKOM rechnet
Wenn der NGFW-Subscription-Vertrag eines kommerziellen Herstellers neu kalkuliert wird, die Hardware-Firewall ihre Audit-Anforderungen nicht mehr abdeckt oder die interne 24/7-Bereitschaft für Sicherheits-Vorfälle fehlt, ist ein Firewall-erfahrener Betriebspartner gefragt – kein generischer Hosted-Firewall-Tarif bei IONOS, Hetzner, Strato oder Contabo, der zwar einen virtuellen Server bereitstellt, aber keine Sicherheits-Verantwortung übernimmt. BEKOM betreibt OPNsense als dedizierte Firewall-Instanz im deutschen Rechenzentrum mit klar definierten Service-Bestandteilen.
Was BEKOM im Service-Vertrag liefert:
Hardware-Klasse nach Durchsatzanforderung – Dimensionierung auf tatsächliches WAN-Profil, IDS/IPS-Last, TLS-Inspection-Bedarf und Verschlüsselungs-Durchsatz; keine generische Mittelwert-Auslegung.
IDS/IPS-Profil nach Risikolage – Signatur-Auswahl auf Branchen-Bedrohungslage abgestimmt, Inline- oder Out-of-Band-Modus, kontinuierliches False-Positive-Tuning statt einmaliger Default-Aktivierung.
Dokumentierte Change- und Patch-Prozesse für Audits – Regelwerks-Änderungen mit Genehmigungspfad, Patch-Historie mit Wartungsfenster-Bezug, Konfigurations-Versionierung mit Audit-Spur.
SIEM-Integration als Standardbestandteil – Anbindung an Wazuh, Graylog, Splunk, Sentinel oder andere SIEM-Plattformen mit definierten Event-Severity-Klassen; auf Wunsch eigenes BEKOM-SOC-Backend. Weiterführend: Managed SOC.
BEKOM klärt mit dem Kundenteam Durchsatzanforderung, Verfügbarkeitsstufe und Auditrahmen – das Ergebnis ist ein schriftliches Angebot mit dokumentiertem Leistungsumfang. Architekturhinweise zur Plattform OPNsense finden sich auf der Produkt-Seite OPNsense; für branchenspezifische KRITIS-Anforderungen siehe OPNsense für KRITIS-Betreiber.
Kostenstruktur des OPNsense-Hostings im Überblick
Ein Managed-OPNsense-Firewall-Hosting wirkt auf drei Kostenebenen, die im Assessment gegeneinander gestellt werden. Eine belastbare Aussage zur Wirtschaftlichkeit entsteht erst, wenn alle drei Ebenen gegen die heutige Bestandssituation gerechnet werden – nicht entlang eines pauschalen Einsparversprechens.
Drei Kostenebenen im Vergleich:
Bestandsseite (heute Eigenbetrieb oder kommerzielle NGFW-Subscription) – Hardware-Refresh-Zyklen, NGFW-Subscription-Bundles, USV/Klima, IDS-Signatur-Feeds und Personalanteile für 24/7-Sicherheits-Bereitschaft.
Hosting-Seite (laufender Service) – Monatliche Service-Pauschale abhängig von Hardware-Klasse, Verfügbarkeitsstufe, IDS/IPS-Profil, SIEM-Integration und Service-Modell.
Migrations-Einmalkosten – Regelwerk-Konvertierung mit Rule-Hit-Bereinigung, VPN-Migration mit Endgeräte-Reauthentifizierung, Cutover mit definiertem Rückfall-Pfad pro Standort.
Ein strukturiertes Assessment ordnet diese Ebenen gegen die bestehende Sicherheits-Architektur – das schriftliche Angebot weist die Anteile getrennt aus, sodass interne Budgetbegründungen und spätere Vergleiche sauber möglich bleiben.
Unterschied zu Hosted-Firewall-Standardanbietern
Im Hosted-Firewall-Markt gibt es zwei Modell-Klassen: standardisierte Hosted-Firewall-Tarife (oft mit fester Hardware, Standardregelwerk und Self-Service-Portal ohne Sicherheits-Beratung) und individualisiertes Firewall-Hosting bei einem spezialisierten Sicherheits-Betreiber. BEKOM steht in der zweiten Klasse: jede OPNsense-Instanz wird im Anforderungsgespräch ausgelegt, dediziert betrieben und mit auditfähiger Dokumentation begleitet.
Beratung vor Bereitstellung
Vor Aufbau der Firewall werden Eckpunkte gemeinsam geklärt – nicht im Self-Service-Portal, sondern im Anforderungsgespräch zwischen Sicherheits-Verantwortlichen aufseiten des Kunden und einem BEKOM-Architekten. Firewall-Architektur ist selten generisch: Schutzzonen, VPN-Topologie und Compliance-Anforderungen prägen die Auslegung von Anfang an.
Geklärt im Anforderungsgespräch:
Anzahl Standorte und VPN-Topologie – Hub-and-Spoke, Mesh oder Multi-Hub mit Failover-Logik abhängig von Standort-Anzahl, Verkehrsmustern und Latenz-Anforderungen.
Schutzzonen und Compliance-Anforderungen – IT-/OT-Trennung, DMZ-Design, branchenspezifische Vorgaben (KRITIS, ISO 27001, TISAX, BSI-Grundschutz) und Datenklassifizierung.
IDS/IPS-Bedarf und SIEM-Anbindung – Signatur-Auswahl, Inline- oder Out-of-Band-Modus, Anbindung an bestehendes SIEM oder neues SOC-Backend.
Reverse-Proxy-Veröffentlichungen – Welche Anwendungen extern erreichbar gemacht werden, welche TLS-Strategie greift, wie Web Application Firewall vorgeschaltet wird.
Eine Standardlösung wird nicht aktiviert, bevor Architektur und Schutzziele klar sind. Das Anforderungsgespräch ist unverbindlich.
Dedizierte Firewall-Instanz
Im Unterschied zu Multi-Tenant-Firewalls auf gemeinsam genutzter Hardware mit getrennten VRF- oder VLAN-Zonen läuft die OPNsense-Instanz dediziert. Das hat operative und regulatorische Konsequenzen: Konfigurations-Änderungen treffen ausschließlich die eigene Umgebung, und Audit-Nachweise sind ohne Verweis auf gemeinsame Plattform-Komponenten möglich.
Was dediziert hier bedeutet:
Eigene Hardware oder dedizierte VM-Ressourcen – Keine Shared-Tenancy auf Compute-Ebene; Hardware-Klasse und Performance-Profil pro Kunde wählbar.
Eigene Konfiguration und Regelwerke – Konfigurations-Änderungen treffen ausschließlich die eigene Umgebung; keine Seiteneffekte aus Multi-Tenant-Defaults.
Eigene Logs und Diagnose-Daten – Logs getrennt vorgehalten, kein gemeinsamer Pool mit anderen Kunden; Forensik nach Sicherheitsvorfall ohne Datenüberlapp.
Updates auf den Kunden abgestimmt – Patches und Major-Upgrades im vereinbarten Wartungsfenster, nicht pauschal auf einer gemeinsamen Plattform eingespielt.
Damit folgt die Firewall der eigenen Sicherheits-Linie – nicht dem kleinsten gemeinsamen Nenner einer geteilten Hardware-Plattform.
Auditfähige Betriebsdokumentation
Eine OPNsense-Instanz lässt sich mit auditfähiger Betriebsdokumentation begleiten – je nach Compliance-Profil und Vereinbarung. Welche Artefakte vorgehalten werden und mit welcher Aufbewahrungsfrist, wird im Service-Vertrag vereinbart.
Mögliche Audit-Artefakte:
Change-Prozess für Regelwerk-Änderungen – Mit Genehmigungspfad, Vier-Augen-Freigabe für kritische Änderungen, Vorher-/Nachher-Zustand und Wartungsfenster-Bezug.
Patch-Historie und Regelwerks-Versionierung – Vollständige Versions-Spur über die Vertragslaufzeit; nachvollziehbar bis zum initialen Setup-Tag.
Rule-Hit-Auswertungen – Identifikation obsoleter Regeln, Konsolidierungs-Vorschläge und Reporting für regelmäßige Policy-Reviews.
Reporting für Sicherheits-Beauftragte – Aufbereitete Übersicht für Informationssicherheit, Datenschutz oder externe Prüfer ohne tiefe Plattform-Vorbildung.
Für KRITIS-Betreiber, ISO-27001-zertifizierte Organisationen, TISAX- oder BSI-Grundschutz-Audits ist diese Dokumentations-Tiefe ein häufig dokumentierbar geforderter Bestandteil.
Deutscher Vertrags- und Operations-Rahmen
Vertrag, Service-Beschreibung, SLA und Eskalationswege sind deutsch. Datenverarbeitung erfolgt in deutschen BEKOM-Rechenzentren – damit ist die Kette von Vertrag bis zum technischen Eingriff vollständig im deutschen Rechtsraum verankert.
Deutscher Operations-Rahmen bedeutet konkret:
Vertragstexte und SLAs in Deutsch – Kein Übersetzungsabgleich nötig, kein Rechtsraum-Wechsel im Streitfall, klare Auslegungspraxis nach deutschem Recht.
Datenverarbeitung in deutschen BEKOM-Rechenzentren – Mit dokumentiertem Standort, kontrolliertem physischem Zugriff und ohne Datenweitergabe an Anbieter mit US-CLOUD-Act-Bindung.
Sicherheits-Eskalationen an deutschsprachige Fachrollen – Im Sicherheitsvorfall, bei Regelwerks-Konflikten oder zur Beratung steht ein deutschsprachiges Team ohne Zeitzonenverzug bereit.
Im Standard keine Weitergabe an internationale SOC-Tiers – Sub-Auftragsverarbeiter mit deutscher oder EU-Verortung; aktualisierte Liste abrufbar für DSGVO-Folgenabschätzungen.
Bei Sicherheitsvorfällen entstehen damit keine Sprachbarrieren oder Übersetzungsschleifen in der Kommunikation zwischen technischer Eskalation und interner Sicherheitsorganisation.
Basis-Spezifikation als Ausgangspunkt
Die folgende Beschreibung dient als Showcase einer typischen Basis-Konfiguration für OPNsense-Hosting bei BEKOM: vier Bausteine, die im Angebot durchgängig adressiert werden – Plattform und Hardware, Firewall-Funktionen, inkludierte Services und individualisierte Bereiche. Sie ist Ausgangspunkt für das Anforderungsgespräch, nicht fertiges Produktpaket – konkrete Preise stehen ausschließlich im individuellen Angebot. Schutzzonen, VPN-Topologie, IDS/IPS-Profil und SIEM-Integration werden gemeinsam mit dem Kundenteam festgelegt.
Plattform und Hardware
Die Plattform-Ebene umfasst Compute, Hardware-Klasse, Patch-Management und Konfigurations-Versionierung. Diese Bausteine werden bei jedem Setup an Durchsatz-, Inspection- und Compliance-Profil angepasst.
Typische Bausteine im Angebot:
OPNsense Business Edition – Auf dedizierter Hardware oder dedizierten VM-Ressourcen mit gehärteter FreeBSD-Basis und Long-Term-Support-Branch.
Hardware-Klasse nach Durchsatz – Auslegung auf WAN-Profil, IDS/IPS-Last und TLS-Inspection-Bedarf; CPU-, Speicher- und NIC-Dimensionierung pro Setup.
Patch-Management mit Change-Prozess – Sicherheits-Updates innerhalb definierter Fristen, größere Updates in geplanten Wartungsfenstern, kritische CVEs außerplanmäßig nach abgekürztem Verfahren.
Konfigurations-Versionierung mit Audit-Spur – Vollständige Historie über die Vertragslaufzeit; Rollback nach dokumentiertem Verfahren möglich.
Mgmt-Zugriff über VPN und MFA – Administrative Zugänge nur über VPN mit zwei-Faktor-Authentifizierung; öffentliche SSH- oder Web-GUI-Endpoints sind nicht vorgesehen.
TLS-Zertifikate für Web-Frontend – Automatische Erneuerung über interne CA oder Let's Encrypt; HSTS und aktuelle Cipher-Suite-Auswahl als Standard.
Firewall-Funktionen
OPNsense ist eine modulare Sicherheits-Plattform – welche Funktionen aktiviert werden, ergibt sich aus Schutzzonen-Modell, Bedrohungslage und Audit-Anforderung. Die Auswahl wird im Anforderungsgespräch festgelegt.
Typische Funktionen je nach Anwendungsprofil:
Stateful Paketfilter – Mit Alias-basierter Regel-Struktur; Aliases als Wartungs-Hebel für IP-, Port- und URL-Gruppen statt verstreuter Einzelregeln.
VPN-Endpunkte (IPsec, WireGuard, OpenVPN) – Für Standortvernetzung, Road-Warrior-Zugriff oder Cloud-Hub-Anbindung; Topologie nach Standortanzahl und Latenz.
IDS/IPS via Suricata – Mit kuratierten Signatur-Feeds, Inline- oder Out-of-Band-Modus; False-Positive-Tuning als laufender Service-Bestandteil.
Web- und Reverse-Proxy – Squid für ausgehende Filterung, HAProxy für eingehende Veröffentlichung mit TLS-Termination und Header-Härtung.
Hochverfügbarkeit via CARP – Ab Stufe 2 als Aktiv/Passiv-Cluster mit pfsync-Zustandsabgleich und Konfigurations-Synchronisation.
TLS-Inspection auf Wunsch – Für ausgewählte Verkehrsbereiche; Strategie und Ausschluss-Listen werden im Anforderungsgespräch geklärt.
Inkludierte Services
Im Unterschied zu Self-Service-Tarifen sind operative Services bereits enthalten – als Bestandteil des Service-Vertrags. Damit liegt der laufende Plattform-Betrieb bei BEKOM, nicht in einer Grauzone zwischen Plattform-Anbieter und interner IT.
Typisch im Service-Vertrag enthalten:
Plattform-Monitoring mit Alarmierung – Überwachung auf Hardware-, OS- und Anwendungs-Ebene; Alarmierung bei Plattform-Events, Failover-Auslösung oder kritischen IDS-Erkennungen.
SIEM-Anbindung als Standardintegration – Wazuh, Graylog, Splunk, Sentinel oder andere; Logs strukturiert per Syslog oder JSON mit definierten Event-Severity-Klassen.
Regelwerks-Reviews in vereinbartem Turnus – Mit Rule-Hit-Analyse, Identifikation obsoleter Regeln und Empfehlungen zur Konsolidierung.
Incident-Response mit Eskalationskette – Definierte Rollen (1st-/2nd-/3rd-Level), Reaktionspfade und Kommunikationswege; auf Wunsch ergänzt um Reporting für Datenschutz oder Geschäftsleitung.
Was BEKOM mit Ihnen individualisiert
Über die typischen Bausteine hinaus gibt es Bereiche, die erst aus konkreten Anforderungen heraus festgelegt werden. Diese sechs Felder sind im Anforderungsgespräch der eigentliche Hebel: Sie entscheiden über Wirtschaftlichkeit, Auditfähigkeit, Sicherheits-Tiefe und Verantwortungsschnitt.
Individuell pro Setup ausgelegt:
Schutzzonen-Architektur – IT-/OT-Trennung, DMZ-Design, Standort-Vernetzung mit angepasster Zonen-Matrix für die konkrete Anwendungslandschaft.
VPN-Topologie – Hub-and-Spoke, Mesh, Multi-Hub mit Failover-Logik abhängig von Standortanzahl, Verkehrsmustern und Latenz-Anforderungen.
IDS/IPS-Profil – Signatur-Auswahl, Inline- oder Out-of-Band-Modus, False-Positive-Tuning und kontinuierliche Anpassung an branchenspezifische Bedrohungslagen.
TLS-Inspection-Strategie – Welche Zonen inspiziert werden, welche Domains ausgeschlossen werden (Banking, Gesundheit), wie Zertifikate verteilt werden.
Compliance-Profil – BSI-Grundschutz, ISO 27001, TISAX, KRITIS oder branchenspezifisch; mit dokumentierter Zuordnung der Maßnahmen zu Anforderungen.
Reporting-Tiefe – Standardberichte, kundenspezifische Reports oder direkte SIEM-Anbindung mit eigenen Dashboards für die Informationssicherheit.
Verfügbarkeit und Failover
Eine Firewall ist die Komponente, deren Ausfall sofort sichtbar wird – Internet-Anbindung, Standort-VPN und veröffentlichte Dienste sind unmittelbar betroffen. Die drei Verfügbarkeitsstufen orientieren sich an der Geschäftsbedeutung der Perimeter-Sicherheit und am tolerierbaren Wiederanlauf-Zeitfenster. Konkrete Verfügbarkeits-Werte werden ausschließlich im individuellen Service-Vertrag dokumentiert und für jede Konstellation einzeln vereinbart.
Stufe 1: Einfache Verfügbarkeit
Eine OPNsense-Instanz mit dokumentiertem Wiederanlauf-Verfahren bei Hardware-Defekt, Konfigurations-Backup mit getrennter Speicherung und definierter Reaktionskette. Geeignet, wenn ein toleranzfähiges Ausfallzeitfenster akzeptabel ist.
Architektur – Single-Instanz mit Konfigurations-Backup auf getrennt gespeichertes Ziel; Backup-Test in vereinbartem Turnus.
Typische Workloads – Sekundäre Standorte, isolierte Sicherheitszonen, Test- und Vorproduktions-Umgebungen ohne 24/7-Geschäftskritikalität.
Ausfallverhalten – Bei Hardware-Defekt erfolgt Wiederanlauf nach dokumentiertem Verfahren mit definierter Reaktionskette und protokolliertem Restore-Pfad.
Wartung – Updates im vereinbarten Wartungsfenster mit kurzem geplantem Ausfallfenster für Major-Updates.
Stufe 2: HA-Cluster
Zwei OPNsense-Instanzen im CARP-Cluster mit pfsync-Zustandsabgleich und Konfigurations-Synchronisation. Standardstufe für produktive Perimeter und kritische Standorte.
Architektur – Aktiv/Passiv-Cluster mit pfsync-Zustandsabgleich; Konfigurations-Synchronisation und Quorum-Auslegung gegen Split-Brain.
Ausfallverhalten – Bei Ausfall einer Instanz übernimmt die andere ohne manuellen Eingriff; bestehende Verbindungen bleiben durch Zustandsabgleich erhalten.
Wartung – Wartungen erfolgen rolling über die Cluster-Knoten, ohne Service-Unterbrechung; Patches werden je Knoten validiert.
Typische Workloads – Produktive Perimeter-Firewalls, Standort-Hubs mit täglicher Geschäftskritikalität und VPN-Konzentratoren mit Mehr-Standort-Anbindung.
Stufe 3: Multi-Site-Redundanz
Firewall-Plattform über zwei räumlich getrennte BEKOM-Standorte. Geeignet für KRITIS-Betreiber, hochverfügbare Service-Anbieter und Organisationen mit strenger BCM-Anforderung aus Konzern- oder Regulatorik-Vorgaben.
Architektur – Konfigurations-Replikation zwischen Standorten mit konsistenter Anwendungs-Stage; getrennte Strom-, Klima- und Netzdomänen je Standort.
Failover – Definierte Failover-Strategie mit dokumentiertem Runbook, regelmäßige Tests in vereinbartem Turnus und protokollierte Wiederanlauf-Übungen.
Schutzziel – Toleranz gegen Standort-Komplettausfall (Strom, Brand, Netz, regionale Störung) sowie gegen geplante Großwartungen am primären Standort.
Typische Einsatzfelder – KRITIS-Plattformen, Konzern-Perimeter mit BCM-Auflagen und Service-Anbieter mit dokumentierten Erreichbarkeits-Zusagen.
BEKOM-Ansatz und Kostenstruktur
Über die technischen Eigenschaften hinaus entscheidet das Betriebsmodell, wie eine OPNsense-Plattform langfristig wirkt. Der BEKOM-Ansatz setzt auf einen festen Ansprechpartner mit Firewall-Expertise, ein Hosting in zertifizierten deutschen Rechenzentren mit deutschsprachiger Betreuung und eine Kostenstruktur, die variable Eigenbetriebs-Aufwände in eine planbare Monatspauschale überführt.
Fester Ansprechpartner mit Firewall-Expertise
Jede OPNsense-Installation wird einem festen Ansprechpartner mit Firewall- und Netzwerksicherheits-Erfahrung zugeordnet, der Regelwerks-Änderungen, VPN-Themen und IDS/IPS-Vorfälle direkt bearbeitet. Reaktionspfade und Eskalationsstufen sind je Installation im Service-Vertrag dokumentiert – statt anonymer Ticket-Queues oder rotierender Bereitschaft.
Aufgaben des festen Ansprechpartners:
Regelwerks-Änderungen mit Vier-Augen-Freigabe und dokumentiertem Change-Prozess
Pflege der IPsec-, WireGuard- und OpenVPN-Tunnel inklusive Standort-Topologie
Suricata-Regelpflege, ET-Open-Threat-Feed-Integration und False-Positive-Tuning
Wartung des CARP-Aktiv/Passiv-Clusters mit pfsync-Zustandsabgleich
Reaktionspfade und Eskalation:
- Service-Levels und Reaktionspfade je OPNsense-Installation im Vertrag fixiert
- Definierte Eskalation an 2nd- und 3rd-Level-Spezialisten im Sicherheitsvorfall
- Service-Reviews in vereinbartem Turnus mit Rule-Hit-Analyse und Kapazitäts-Hinweisen
- Reporting in Abstimmung mit Informationssicherheit, Datenschutz und Geschäftsleitung
Hosting und Betrieb im DACH-Raum
BEKOM nutzt für OPNsense-Installationen zertifizierte Rechenzentren in Deutschland. Konfigurations- und Wartungs-Tätigkeiten erfolgen durch deutschsprachige Firewall-Techniker; die Konfiguration bleibt nahe am OPNsense-Standard, sodass ein Wechsel zu anderen OPNsense-Hostern jederzeit möglich bleibt.
Betriebsumgebung:
Hosting in zertifizierten deutschen Rechenzentren (BEKOM als Nutzer)
Deutschsprachige Firewall-Techniker für Konfiguration und Incident-Response
Patch-Management entlang der offiziellen OPNsense-Release-Linie inklusive FreeBSD-Basis
Monitoring von Paketfilter, IPsec-/WireGuard-Tunneln, Suricata-Events und CARP-State
Portabilität und Exit:
- Standard-OPNsense-Konfiguration ohne proprietäre BEKOM-Anpassungen
- Export der Konfiguration als offene XML-Datei jederzeit übergebbar
- Wechsel zu anderen OPNsense-Hostern oder Rückführung in den Eigenbetrieb möglich
- Übergabe-Dokumentation mit Regelwerks-Historie als Bestandteil des Service-Vertrags
Planbare Kostenstruktur statt variabler Aufwände
Im Eigenbetrieb fallen Kostentreiber an, die in der internen Kalkulation oft unterschätzt werden – von der FreeBSD-Basis bis zur Threat-Feed-Pflege. BEKOM überführt diese Aufwände in eine monatliche Pauschale; ein vorgelagertes Assessment klärt den konkreten Betriebsumfang und die zugehörige Kostenstruktur.
Typische Kostentreiber im Eigenbetrieb:
Pflege der FreeBSD-Basis und Einspielen der OPNsense-Sicherheits-Patches
Suricata-Regelpflege mit ET-Open- und kommerziellen Threat-Feeds
Konfiguration und Wartung von IPsec-/WireGuard-Tunneln zur Standortvernetzung
Aufbau und Pflege des CARP-Clusters mit pfsync-Zustandsabgleich
Inhalte der Monatspauschale:
- OPNsense-Patches und FreeBSD-Updates entlang der offiziellen Release-Linie
- Monitoring von Paketfilter, VPN-Tunneln, Suricata-Events und HAProxy-Frontends
- Incident-Response über die im Vertrag definierten Reaktionspfade
- Service-Reviews und Reporting für Informationssicherheit und Geschäftsleitung
Häufige Fragen zum OPNsense-Hosting
Worin unterscheidet sich BEKOM-OPNsense-Hosting von Standard-Hosted-Firewall-Anbietern?
Standard-Anbieter setzen meist auf eine einheitliche Hardware-Klasse, fest definierte Regelwerks-Templates und ein Self-Service-Portal mit begrenzten Konfigurationsoptionen. BEKOM betreibt jede OPNsense-Instanz dediziert, mit individueller Hardware-Dimensionierung, freier Regelwerks-Gestaltung, Beratung zur Schutzzonen-Architektur und auditfähiger Dokumentation. Beide Modelle haben ihre Berechtigung — BEKOM ist die richtige Wahl, wenn Sicherheits-Architektur Beratung verlangt und Audit-Nachweise gegenüber Prüfern gefragt sind.
Können wir eine bestehende OPNsense-Konfiguration mitbringen, und wie wird sie übernommen?
Ja. Bestehende Konfigurationen werden über die XML-Konfigurations-Datei importiert und auf die Ziel-Hardware angepasst. Im Vorfeld erfolgt eine Regelwerks-Bereinigung mit Rule-Hit-Analyse zur Identifikation obsoleter Regeln und Konsolidierung von Aliases. Der Migrationsplan bündelt Konfigurations-Übertragung, VPN-Migrationsfenster, Endgeräte-Reauthentifizierung und Cutover mit definiertem Rollback-Pfad je Stufe, sodass auch bei größeren Regelwerken ein kontrolliertes Vorgehen mit Test-Phasen pro Zone möglich bleibt.
Wie wird die Firewall mit unseren Standorten verbunden, und welche Topologien sind möglich?
Über IPsec- oder WireGuard-Tunnel zwischen dem BEKOM-Rechenzentrum und Ihren Standorten. Pro Standort werden ein oder mehrere Tunnel mit definierten Routing- und Failover-Eigenschaften eingerichtet. Bei mehreren Standorten kommen Hub-and-Spoke- oder Mesh-Topologien zum Einsatz. Welche Topologie passt, hängt von Verkehrsmustern, Latenz-Anforderungen, Ausfallszenarien und der bestehenden WAN-Architektur ab und wird im Architektur-Gespräch festgelegt.
Lässt sich die Firewall in ein bestehendes SIEM einbinden, oder gibt es eine BEKOM-eigene Lösung?
Ja, SIEM-Anbindung ist Standardbestandteil. Logs werden via Syslog oder strukturiert per JSON an Ihr SIEM (Wazuh, Graylog, Splunk, Sentinel oder andere) mit definierten Event-Severity-Klassen übertragen. Bei Bedarf bietet BEKOM zusätzlich ein eigenes SIEM/SOC-Backend an, in das die OPNsense-Telemetrie eingebettet wird, angebunden an die Pillar BEKOM MANAGED Security mit eigener Korrelations-Logik.
Wer pflegt die Firewall-Regeln nach Inbetriebnahme, und wie ist die Verantwortung verteilt?
Drei Modelle stehen zur Wahl und werden vor Vertragsschluss schriftlich fixiert: BEKOM pflegt das Regelwerk komplett mit dokumentiertem Change-Prozess und Vier-Augen-Freigabe (Fully Managed); Kunde und BEKOM teilen sich Regelwerks-Verantwortung pro Zone oder Funktionsbereich (Co-Managed); Kunde pflegt selbst, BEKOM stellt Plattform-Betrieb und beratende Begleitung (begleiteter Eigenbetrieb). Die Rollen-Matrix ist Bestandteil des Service-Vertrags.
Ist TLS-Inspection (Decryption) möglich, und wann ist sie sinnvoll?
Ja, OPNsense unterstützt TLS-Inspection für ausgewählte Verkehrsbereiche. Die Strategie wird im Anforderungsgespräch geklärt: welche Zonen inspiziert werden, welche Domains ausgeschlossen werden (Banking-Portale, Gesundheits-Plattformen aus rechtlichen Gründen), wie Zertifikate auf den Endgeräten verteilt werden. TLS-Inspection bringt deutlich mehr Sichtbarkeit auf verschlüsseltem Verkehr, ist aber operativ aufwendig — die Entscheidung erfolgt bewusst nach Risikoabwägung.
Kann die Firewall im Rahmen einer KRITIS- oder NIS-2-Anforderung betrieben werden?
Ja. Für KRITIS-Anforderungen wird der Betrieb mit dokumentiertem Change-Prozess inklusive Vier-Augen-Freigabe für kritische Änderungen, regelmäßigen Policy-Reviews mit Rule-Hit-Analyse, SIEM-Integration und §8a-konformer Nachweisführung gegenüber Aufsichtsbehörden angeboten. Branchenspezifische Vertiefung mit Schutzbedarfsanalyse, Zonenmodell, Notfall-Vorsorge und Audit-Begleitung im Szenario OPNsense für KRITIS-Betreiber, das den vollständigen KRITIS-Kontext einschließlich Meldepflichten und Berichtswesen gegenüber der zuständigen Aufsicht beschreibt.
Was kostet das OPNsense-Hosting bei BEKOM, und wie wird kalkuliert?
Konkrete Preise stehen nicht auf der Webseite, weil Hardware-Klasse, Verfügbarkeitsstufe, Regelwerks-Komplexität, IDS/IPS-Profil, SIEM-Integration und Service-Modell stark variieren. Im Anforderungsgespräch entsteht eine Kosten-Struktur ohne Verbindlichkeit; das schriftliche Angebot enthält dann die transparente Aufschlüsselung pro Service-Bestandteil — getrennt nach Hardware-Anteil, Plattform-Pflege, Regelwerks-Service, IDS-Bestandteil und SIEM-Integration mit klar ausgewiesenen Bezugsgrößen je Komponente, sodass spätere Vergleiche möglich bleiben.
Welche Vertragslaufzeiten und Wechseloptionen gibt es?
Übliche Bandbreite reicht von 12 Monaten Mindestlaufzeit bis zu mehrjährigen Verträgen bei dedizierter Hardware oder Multi-Site-Architekturen. Eine Anpassung der Service-Stufe (z. B. Wechsel von HA auf Multi-Site, oder Erweiterung des IDS-Profils) während der Laufzeit ist im Vertrag geregelt. Bei Vertragsende erfolgt eine strukturierte Konfigurations-Übergabe — OPNsense ist Open Source, die Konfiguration ist portabel und in offenen XML-Strukturen dokumentiert.
Kann der Betrieb später wieder ins eigene Haus zurückwandern?
Ja, der Rücklauf ist vorgesehen und vertraglich dokumentiert. OPNsense-Konfiguration, Regelwerks-Historie mit Change-Log, Backup-Archive, IDS-Signatur-Konfiguration und Betriebsdokumentation werden strukturiert an das interne Team oder einen Folgedienstleister übergeben. Der Wissenstransfer wird mit dokumentierter Übergabe-Phase im Vertrag geregelt. Es gibt keine technischen Lock-ins, weil OPNsense Open Source ist und Konfigurationen in offenen XML-Strukturen gespeichert werden.
Welche Kosten entstehen beim Wechsel von On-Premise-OPNsense zu BEKOM-Hosting?
Die Wechselkosten umfassen primär die einmalige Migration der Firewall-Konfiguration ins BEKOM-Rechenzentrum und die Anpassung der Netzwerk-Anbindungen. BEKOM übernimmt die Regelwerk-Überführung und Connectivity-Tests ohne zusätzliche Migrationsgebühren. Bestehende OPNsense-Lizenzen können weiterverwendet werden. Die monatlichen Hosting-Kosten ersetzen dann die bisherigen Hardware-, Wartungs- und Betriebsaufwände der On-Premise-Installation.
Kann die Organisation bei Bedarf zum OPNsense-Eigenbetrieb zurückkehren?
Der Rückwechsel zum Eigenbetrieb ist technisch und vertraglich möglich. BEKOM dokumentiert alle Konfigurationsänderungen und Regelwerk-Anpassungen während der Hosting-Phase vollständig. Bei einer Rückführung erhalten Sie die komplette OPNsense-Konfiguration, Dokumentation der Netzwerk-Architektur und alle Compliance-Belege für den nahtlosen Übergang in den internen Betrieb. Die Vertragslaufzeit ermöglicht eine planbare Transition ohne Lock-in-Effekte.
Nächster Schritt: Hosting-Angebot anfragen
Den Einstieg bildet ein unverbindliches Anforderungsgespräch zur geplanten Firewall-Architektur. Auf Basis der Eckpunkte entsteht ein schriftliches Angebot mit individualisierter Spezifikation, Verfügbarkeitsstufe und Service-Umfang.
Das Assessment für OPNsense-Hosting verschafft Ihnen Klarheit über die aktuelle Firewall-Architektur, Regelwerk-Komplexität und Compliance-Anforderungen. BEKOM analysiert Ihre bestehende OPNsense-Konfiguration, erstellt eine detaillierte Bestandsaufnahme der Netzwerk-Segmentierung und entwickelt konkrete Empfehlungen für die Hosting-Architektur im deutschen Rechenzentrum. Sie erhalten ein Service-Design-Dokument mit transparentem Betriebsumfang und Eskalationswegen für Ihre geschäftskritische Perimeter-Security.
Sicherheits-Architektur gemeinsam strukturieren
Im Anforderungsgespräch klären BEKOM-Sicherheitsspezialisten mit Ihrem Team die Eckpunkte: Schutzzonen, VPN-Topologie, IDS-Bedarf, SIEM-Integration, Compliance-Profil. Das Gespräch ist unverbindlich und löst keine Folgeverpflichtung aus.
Spezifikation auf Ihre Anforderungen anpassen
Auf Basis des Gesprächs entsteht eine angepasste Spezifikation mit Hardware-Klasse, HA-Stufe, Regelwerks-Vorlage und Migrations-Plan, falls eine Bestandsmigration vorgesehen ist.
Schriftliches Angebot mit dokumentiertem Leistungsumfang
Das Angebot dokumentiert vollständig den Leistungsumfang, alle Migrations-Schritte, SLA-Profil, Verfügbarkeitsstufe, Vertragsbedingungen, Kündigungsregelungen und Kostenstruktur. Es bildet die transparente Grundlage für die anschließende Vertragsverhandlung – ohne versteckte Bestandteile oder nachgereichte Aufpreise nach Vertragsschluss.