Arztpraxen sind im IT-Sicherheits-Kontext eine besondere Branche: Sie verarbeiten besonders schutzwürdige personenbezogene Daten (Gesundheitsdaten nach Art. 9 DSGVO), sind über die Telematikinfrastruktur (TI) mit dem Gesundheitsnetz verbunden, und unterliegen den Anforderungen der KBV an die IT-Sicherheit in der Praxis. Wer als IT-Dienstleister Praxen betreut, kennt die Spannung zwischen “Wir wollen es einfach” und “Es muss konform sein”.
OPNsense ist in diesem Umfeld eine pragmatische Wahl: Open Source, gute Dokumentation, alle nötigen Features (VLAN-Trennung, stateful Firewall mit Logging, IDS/IPS) — ohne die Lizenzkosten einer Sophos/Fortinet/SonicWall-Lösung. Was OPNsense nicht ersetzt: die TI-Konnektor-Hardware bzw. den TI-Konnektor selbst. OPNsense ergänzt die TI-Sicherheit — sie ist nicht Teil der gematik-Zertifizierung.
Dieser Artikel beschreibt, was die KBV-Anforderungen vom Praxisnetz verlangen, wie OPNsense das umsetzt und wo die Grenze zwischen OPNsense-Verantwortung und TI-Verantwortung verläuft.
Was die KBV vorschreibt — kurz
Die IT-Sicherheitsrichtlinie der KBV (nach § 75b SGB V) ist seit 2021 verbindlich. Sie listet Anforderungen in Stufen — je nach Praxisgröße — und enthält für die Netz-Seite mehrere konkrete Punkte. Im Kern:
- Trennung zwischen Praxis-LAN, TI-Anbindung und WLAN-Gästenetzen
- Firewall mit Protokollierung der Verbindungen
- Verschlüsselung sensibler Datenübertragungen (Mail, Praxisverwaltungssystem-Updates etc.)
- Sicheres Patch-Management der Geräte im Praxisnetz
- Definierte Verbindungen zur TI — nur erforderliche Verbindungen erlaubt
Wichtig: Die Richtlinie ist technologieneutral. Sie sagt nicht “ihr braucht OPNsense”, sondern “ihr braucht eine Firewall, die folgende Eigenschaften hat”. OPNsense erfüllt diese Eigenschaften vollständig.
Die typische Praxis-Topologie
Wir empfehlen für eine Standard-Arztpraxis eine 4-Zonen-Architektur:
| Zone | VLAN | Geräte | Internet | Andere Zonen |
|---|---|---|---|---|
| TI-Netz | VLAN 10 | TI-Konnektor, Kartenlesegeräte | Nur zu TI-Aggregator | Nur via Konnektor |
| Praxis-LAN | VLAN 20 | PVS-Server, Arzt-PCs, Drucker | Definiert (PVS-Updates, gematik-CMS, KBV-Portale) | Zu Konnektor |
| Diagnose-VLAN | VLAN 30 | Röntgen, Ultraschall, EKG | Nur Hersteller-Updates | Zu PVS-Server (lesend) |
| Gäste-WLAN | VLAN 99 | Patient-Wartezimmer-WLAN | Frei | Keine |
Die TI-Komponenten müssen in einem eigenen Netz sein. Das ist nicht Geschmackssache — gematik verlangt das, und die KBV unterstreicht es.
Umsetzung in OPNsense: VLAN-Konfiguration
OPNsense kennt VLANs als ganz normale Interfaces. Auf einem managebaren Switch werden die VLANs getaggt, die OPNsense bekommt sie als logische Interfaces:
Interface: igb0 (physisch)
- VLAN 10 (TI)
- VLAN 20 (Praxis-LAN)
- VLAN 30 (Diagnose)
- VLAN 99 (Gast-WLAN)
Jedem VLAN-Interface wird ein eigenes Subnetz zugeordnet — z.B.:
- TI: 192.168.10.0/24
- Praxis: 192.168.20.0/24
- Diagnose: 192.168.30.0/24
- Gast: 192.168.99.0/24
DHCP pro Subnetz, mit eigenen Lease-Ranges. Der TI-Konnektor bekommt typischerweise eine statische IP — das vereinfacht später die Firewall-Regel-Pflege.
Firewall-Regeln, die wir empfehlen
Die KBV-Richtlinie verlangt konkret protokollierte Verbindungen. In OPNsense heißt das: Jede explizite Regel aktiviert “Log packets that are handled by this rule”.
Regelsatz Praxis-LAN
# Aus Praxis-LAN raus
ALLOW Praxis-LAN -> TI-Konnektor: Konnektor-Ports (gematik-Spec)
ALLOW Praxis-LAN -> Internet: PVS-Update-Server (PVS-Hersteller dokumentiert)
ALLOW Praxis-LAN -> Internet: HTTPS auf KBV-Portale, Microsoft-Update, AV-Update
DENY Praxis-LAN -> Diagnose-VLAN: (alles)
DENY Praxis-LAN -> Gast-WLAN: (alles)
DENY Praxis-LAN -> Internet: (Default)
Regelsatz TI-Netz
# Aus TI raus
ALLOW TI -> Internet: nur gematik-Aggregator-Adressen (TI-Konnektor-Hersteller dokumentiert)
DENY TI -> Praxis-LAN: (alles außer eingehende vom Konnektor)
DENY TI -> Diagnose-VLAN: (alles)
DENY TI -> Gast-WLAN: (alles)
Regelsatz Gast-WLAN
ALLOW Gast -> Internet: HTTPS, HTTP, DNS (zu OPNsense oder externer DNS)
DENY Gast -> alles andere
# Optional: Captive Portal mit Tagespasswort
Jede DENY-Regel mit Logging. Damit hat man bei einem Vorfall nachweisbar protokolliert, welche Verbindungen versucht wurden — Voraussetzung für Forensik und für eine KBV-/Datenschutz-Prüfung.
IDS/IPS mit Suricata
OPNsense bringt Suricata als IDS/IPS mit. Auf den Schnittstellen Praxis-LAN und Diagnose-VLAN lohnt der Einsatz:
- ET Open Rules (Proofpoint Emerging Threats) als Basis-Regelset
- PT Research für medizinische Spezialitäten (Praxisverwaltungssystem-Angriffe sind dokumentiert)
- Initial im IDS-Modus (nur Alarmierung, kein Blocken) — sonst riskiert man falsch-positiv-bedingte Praxis-Ausfälle
- Nach ein bis zwei Monaten Tuning Übergang auf IPS-Modus für ausgewählte High-Confidence-Regeln
Die Logs gehen an einen externen Log-Server (z.B. Wazuh, Graylog oder die DATAZONE-Control-Plattform), nicht nur lokal auf OPNsense — bei einem Vorfall müssen die Logs außerhalb des kompromittierten Hosts liegen.
DNS-Filterung als ergänzende Schicht
Auf der OPNsense kann Unbound DNS mit DNS-Blocklist-Plugin (z.B. via dnsbl_unbound) konfiguriert werden. Damit lässt sich:
- Malware-Domains blockieren (Blocklists wie OISD, StevenBlack, NextDNS)
- Phishing-Domains filtern
- Werbenetzwerke auf den Praxis-Workstations reduzieren (Wartezimmer-Wartezeit-Wirkung)
Wichtig: DNS-Filter ersetzt kein Endpoint-Antivirus oder EDR — sondern reduziert die Wahrscheinlichkeit, dass eine Phishing-URL den Browser überhaupt erreicht.
VPN-Zugang für Praxis-Inhaber
Niedergelassene Ärztinnen und Ärzte arbeiten oft auch von zu Hause — und greifen auf das Praxisverwaltungssystem zu. Dafür empfehlen wir:
- WireGuard als VPN-Lösung (in OPNsense seit 24.x integriert)
- MFA über TOTP mit eingebautem OPNsense-Modul oder externem Authenticator
- VPN-Endpunkt im Praxis-LAN-VLAN mit eingeschränkten Zielen (PVS-Server, ja; Diagnose-VLAN, nein)
- VPN-User-Zertifikate statt Username/Passwort — bei kompromittiertem Endgerät einfacher zu sperren
Die KBV-Richtlinie verlangt für Fernzugriff eine “angemessene Authentifizierung” — MFA-WireGuard erfüllt das mit ordentlicher Marge.
Wo OPNsense aufhört: die TI-Grenze
Hier kommt der entscheidende Hinweis: Die Sicherheit der TI-Verbindung selbst ist gematik-zertifiziert und nicht Sache der Firewall. Der TI-Konnektor (Hardware-Box oder zukünftig “TI-Konnektor as a Service”) verschlüsselt und authentifiziert die Verbindung zur Telematikinfrastruktur. OPNsense routet die Konnektor-Pakete — sie kann die TI-Verbindung nicht inspizieren, nicht entschlüsseln und nicht zertifikatsbasiert prüfen.
Was OPNsense zur TI-Sicherheit beiträgt:
- Isolation des TI-Netzes vom Praxis-LAN — verhindert Lateral Movement von einem kompromittierten Praxis-PC zum Konnektor
- Firewall-Regeln am TI-Übergang — nur die vom Konnektor-Hersteller dokumentierten Ports zur TI-Aggregator-Plattform
- Protokollierung aller Verbindungen vom und zum Konnektor — wichtig für Audit-Trails
- Anomalie-Erkennung über Suricata — ungewöhnliche Volumen oder Protokolle auf der TI-Strecke
Was OPNsense nicht leistet:
- Keine Zertifikatsprüfung der TI-Kommunikation (das macht der Konnektor)
- Keine Authentifizierung der Heilberufsausweise (das ist die SMC-B / HBA-Domäne)
- Kein Ersatz für die gematik-Zulassung des Konnektors
Wer eine “alles in einem”-Box sucht: Das gibt es im TI-Umfeld nicht. Der TI-Konnektor ist Pflicht und muss zugelassen sein; OPNsense kommt vor und um den Konnektor herum.
Hardware-Empfehlung
Für eine Standard-Arztpraxis mit 5–20 Mitarbeitenden reicht in der Regel:
- Kleine Hardware-Appliance (z.B. Deciso DEC600 oder ähnlich) mit 4–6 physischen Ports
- Managebarer Switch (z.B. Mikrotik CRS, Netgear M4250, Ubiquiti USW-Pro) für VLAN-Tagging
- WLAN-Access-Points mit Multi-SSID-Support (z.B. Ubiquiti, TP-Link Omada, Aruba Instant)
Wer mehr Performance braucht (z.B. größere Praxen mit mehreren Standorten), nimmt eine größere Deciso-Appliance oder baut auf Intel-Hardware mit OPNsense selbst auf. Bei DATAZONE planen wir das pro Praxis im Beratungsgespräch — auch weil die Switch- und WLAN-Wahl von der baulichen Situation abhängt.
Was wir bei DATAZONE empfehlen
Für eine typische niedergelassene Praxis ergibt sich folgendes Setup-Paket:
- OPNsense-Appliance mit 4-Zonen-VLAN-Trennung
- Switch mit VLAN-Tagging und PoE für WLAN-APs
- Multi-SSID-WLAN: ein SSID für Praxis-Geräte (im Praxis-VLAN), ein SSID für Gäste (im Gast-VLAN)
- Suricata im IDS-Modus, monatlicher Bericht ans Praxis-Management
- Unbound DNS mit Malware/Phishing-Blocklist
- WireGuard-VPN mit MFA für Praxis-Inhaber-Fernzugriff
- Externes Logging (Wazuh, Graylog oder DATAZONE Control) — Logs nicht nur lokal
- Verfahrensdoku zur KBV-Konformität — Beweis-Dokument für Datenschutz-/Aufsichtsprüfungen
Verwandte DATAZONE-Artikel:
- OPNsense vs. pfSense: Vergleich
- OPNsense WireGuard VPN einrichten
- Ransomware 2026: Schutzmaßnahmen
- Sophos / Fortinet zu OPNsense wechseln
Fazit
OPNsense ist eine ausgereifte Firewall-Plattform, mit der Arztpraxen die KBV-IT-Sicherheitsrichtlinie auf der Netz-Seite erfüllbar machen — ohne Hochpreis-Lizenz und mit allen modernen Features (VLAN-Trennung, Suricata, WireGuard, DNS-Filter). Sie ist kein Ersatz für den TI-Konnektor und übernimmt keine gematik-zertifizierten Aufgaben — aber sie schließt die Lücke, in der ein kompromittiertes Praxis-LAN sonst direkt zur TI durchgreifen könnte.
Wer sein Praxisnetz heute mit einem einfachen DSL-Router fährt, hat in der Regel keine VLAN-Trennung, kein Logging und keine konkrete Möglichkeit, eine Prüfung mit Belegen zu bestehen. Genau das ändert OPNsense — und das ist es, was die KBV-Richtlinie fordert.
Quellen
Mehr zu diesen Themen:
Weitere Artikel
Home-Office-IT: Mitarbeiter sicher anbinden
Sicheres Home-Office im KMU: VPN mit OPNsense, MDM, RDP-Gateway, Vaultwarden, MFA mit Yubikey. Konfigurations-Blueprint vom Notebook über VPN bis zur Terminal-Session.
AdGuard Home: DNS-Filterung im Unternehmen
AdGuard Home als zentraler DNS-Resolver mit Blocklists in OPNsense-Umgebungen. Werbung, Tracker und Malware-Domains blockieren — Vergleich zu Pi-hole und OPNsense Unbound, mit klaren Empfehlungen für KMU.
TrueNAS für Steuerberater: GoBD-konforme Datenhaltung
Die GoBD verlangen Unveränderbarkeit, Vollständigkeit, Nachvollziehbarkeit und 10 Jahre Aufbewahrungsdauer. TrueNAS bringt mit ZFS-Snapshots, Replikation und Integritäts-Checks technische Bausteine — ist aber allein nicht GoBD-konform. Wir zeigen die Architektur, die in Kanzleien funktioniert.