Hintergrund und Zielsetzung
Das Stammdaten-Portal läuft derzeit ausschließlich im internen Netz (srv-dms:5026). Kunden und Lieferanten erhalten per E-Mail einen personalisierten Link zum Prüfen und Korrigieren ihrer Stammdaten — dieser Link funktioniert nur, solange sie Zugang zum internen Netz haben.
Ziel ist es, das Kundenportal über das öffentliche Internet erreichbar zu machen, ohne dass Datenbank, KHK-Anbindung oder Verwaltungsoberfläche nach außen exponiert werden. Die vorliegende Vorlage beschreibt fünf Architektur-Varianten und bewertet sie, damit eine fundierte Entscheidung getroffen werden kann.
Kunden sollen einen Link per E-Mail erhalten und diesen direkt im Browser öffnen können — ohne VPN, ohne IT-Einrichtung, von jedem Gerät.
Ist-Zustand
Alle Komponenten laufen in einem einzigen Prozess auf dem internen Windows-Server:
Was bleibt in jedem Fall intern?
Unabhängig von der gewählten Variante müssen folgende Komponenten auf dem internen Server verbleiben:
- SQL Server Datenbank (Tokens, Kampagnen, ChangeSets)
- KHK / Sage-Anbindung (Kunden- und Lieferantenstammdaten)
- Admin-Oberfläche (Kampagne-Editor, Auswertung, Mailing)
- Graph API Monitor (Posteingang-Überwachung, NDR-Erkennung)
- Opt-out- und ChangeSet-Verarbeitung durch Sachbearbeiter
Was öffentlich erreichbar sein soll:
- Kundenportal-Seiten (
/portal/*) — Stammdateneingabe - Abmeldeseite (
/abmelden/*) — Kein-Mailing-Anforderung
Architektur-Varianten
V1 — Status quo: VPN-Zugang für Kunden
Das Portal bleibt unverändert intern. Kunden erhalten statt eines Web-Links einen VPN-Zugang zum internen Netz.
- Kein Entwicklungsaufwand, keine Architekturänderung
- Maximale Sicherheit — kein interner Dienst nach außen exponiert
- Kunden müssen VPN-Software installieren und konfigurieren — sehr schlechte Nutzerfreundlichkeit
- IT-Aufwand pro Kunde: Zertifikat ausstellen, VPN einrichten, widerrufen
- Nicht skalierbar bei vielen Kunden
- Mobilgeräte / Kunden-IT oft nicht VPN-fähig
Keine realistische Option für das beschriebene Ziel. VPN für Endkunden ist in der Praxis nicht durchsetzbar.
V2 — Gesamtanwendung auf öffentlichem Server
Die komplette Blazor-Anwendung (inklusive Admin) wird auf einem öffentlichen Server deployed. Die Datenbankverbindung läuft über einen verschlüsselten Tunnel (VPN oder SSH) zum internen SQL Server.
- Einfachstes Deployment — ein Prozess, kein API-Umbau nötig
- Keine Code-Änderungen erforderlich
- Admin-Oberfläche öffentlich erreichbar — erhebliches Sicherheitsrisiko
- Alle Secrets (DB-Passwort, Graph-API-Tokens, KHK-Zugangsdaten) auf öffentlichem Server gespeichert
- Datenbankverbindung über öffentliche Netzstrecke (auch wenn VPN-verschlüsselt: Tunnel muss stabil sein)
- Latenz: jede DB-Abfrage läuft über VPN → spürbar langsamer
- Bei Kompromittierung des öffentlichen Servers: voller Datenbankzugriff
Aus Sicherheitssicht nicht empfehlenswert. Der Gewinn an Einfachheit wird durch das Risikoprofil mehr als aufgewogen.
V3 — Zwei-Modul-Split + direkte Port-Freigabe
Das Projekt wird in zwei separate Anwendungen aufgeteilt. Das interne Modul stellt eine REST-API bereit, die über eine Firewall-Regel direkt aus dem Internet erreichbar ist.
- Einfachste Zwei-Modul-Lösung — kein VPN, kein Cloud-Dienst
- Admin-Oberfläche bleibt intern und unsichtbar
- Datenbankzugriff bleibt intern
- Firewall-Port zum internen Server wird nach außen geöffnet — internes Netz direkt erreichbar
- DDoS- oder Brute-Force-Angriffe treffen direkt den internen Server
- API-Key muss gesichert werden; bei Kompromittierung direkter Zugriff auf interne API
- Abhängigkeit von stabiler öffentlicher IP / DynDNS
Technisch funktional, aber das Öffnen eines internen Ports ins Internet ist operativ riskant. Nur geeignet wenn das Netzwerk hinter einer gemanagten Firewall mit IDS/Rate-Limiting liegt.
V4 — Zwei-Modul-Split + VPN-Tunnel ★ Empfehlung
Das Projekt wird aufgeteilt. Der externe Server baut eine VPN-Verbindung (WireGuard) zum internen Netz auf und ruft die interne REST-API darüber auf. Der interne Server öffnet keinen eingehenden Port ins Internet.
- Interner Server öffnet keinen eingehenden Port — Angriffsfläche minimal
- VPN-Verbindung ist verschlüsselt und authentifiziert (Public-Key-Verfahren)
- Admin-UI und DB vollständig intern und unerreichbar von außen
- WireGuard: kostenlos, sehr geringe Angriffsfläche, stabil
- Kein Cloud-Dienst nötig, keine laufenden Cloud-Kosten
- VPN-Verbindung ist ein zusätzlicher Ausfallpunkt (Tunnelabbruch → Portal unerreichbar)
- Einmalige VPN-Konfiguration auf beiden Servern erforderlich
- Code-Umbau nötig: REST-API intern, API-Client extern (~3–4 Tage)
V5 — Zwei-Modul-Split + Azure Relay / Service Bus
Der interne Server verbindet sich ausgehend zu Azure. Der externe Server kommuniziert über Azure mit dem internen. Keine direkte Verbindung zwischen den Servern.
- Interner Server nur ausgehende Verbindungen — beste mögliche Isolation
- Azure SLA: 99,9 % Verfügbarkeit des Relay-Dienstes
- Kein VPN zu verwalten
- Azure-Abhängigkeit: Ausfall von Azure = Portal unerreichbar
- Laufende Azure-Kosten (~10–40 €/Monat je nach Traffic)
- Höchster Implementierungsaufwand: Azure konfigurieren, SDK einbinden
- Höchste Komplexität im Betrieb (Azure-Portal, Zugriffsrechte, Monitoring)
V6 — Zwei-Modul-Split + Datensynchronisation über externen SQL Server ★★ Provider-kompatibel
Der interne Server schreibt beim Kampagnenversand einen Daten-Snapshot (Tokens + Adressdaten) direkt auf einen SQL Server beim Provider (enmatek.de). Das externe Portal-Modul liest und schreibt ausschließlich auf diesen lokalen SQL Server — ohne jede Verbindung ins interne Netz. Der interne Server holt neue Kundenänderungen per Hintergrundjob ab.
- Kein VPN auf Provider-Server — funktioniert mit Standard-Webhosting
- Portal und Website (
enmatek.de) auf demselben Server — DNS-Eintrag reicht - Interner Server nur ausgehende TCP-1433-Verbindung (in den meisten Firmennetzen erlaubt)
- Portal nutzt lokalen SQL Server → sehr geringe Latenz für Kunden
- Unabhängige Verfügbarkeit: Portal läuft auch wenn interner Server kurz offline ist
- Gleicher Sync-Mechanismus ermöglicht spätere Erweiterungen: Belege, Bestellportal
- SQL Server Express kostenlos — kein zusätzlicher Lizenzkauf nötig
- Adress-Snapshots liegen auf externem Server → Datenschutzprüfung erforderlich
- Synchronisationslogik im internen Modul nötig (Hintergrundjob mit Intervall)
- Snapshot kann veralten (KHK-Daten ändern sich nach Token-Erstellung)
- Externer SQL Server muss per Firewall abgesichert sein: nur interner Server + Portal-Server haben Zugriff, nicht öffentlich
- Komplexester Code-Umbau: zwei separate Datenbankschemas koordinieren
Die bevorzugte Variante wenn VPN auf dem Provider-Server nicht möglich ist. Gut erweiterbar für Belegbereitstellung und Bestellportal. Datenschutz-Aspekt (Snapshots extern) muss intern geklärt werden — die Daten sind nur so sensitiv wie die Adressdaten, die im E-Mail-Versand ohnehin genutzt werden.
Vergleichsmatrix
| Kriterium | V1 VPN für Kunden |
V2 Komplett extern |
V3 Split + Port |
V4 ★ Split + VPN |
V5 Split + Azure |
V6 ★★ Split + ext. SQL |
|---|---|---|---|---|---|---|
| SicherheitAngriffsfläche intern | Sehr gut | Schlecht | Mittel | Sehr gut | Gut | GutSnapshots extern |
| ImplementierungsaufwandEinmaliger Entwicklungsaufwand | Keiner | Gering | Mittel~3 Tage | Mittel~4 Tage | Hoch~6–7 Tage | Hoch~5–6 Tage |
| BetriebsaufwandLaufende Administration | HochVPN pro Kunde | Gering | Gering | GeringVPN wartungsfrei | MittelAzure-Verwaltung | GeringSync-Job läuft autom. |
| Laufende KostenPro Monat (zusätzlich) | Keine | ~5–20 €VPS | ~5–20 €VPS | ~5–20 €VPS, VPN kostenlos | ~20–60 €VPS + Azure | ggf. 0 €Provider-Server vorhanden |
| Verfügbarkeit für KundenErreichbarkeit ohne Hürden | SchlechtVPN-Pflicht | Sehr gut | Gut | Gut | Sehr gutAzure SLA | Sehr gutunabhängig vom internen Server |
| Datenschutz / ComplianceDatenwege und -ablageorte | Sehr gut | KritischSecrets extern | Gut | Sehr gutDaten nur intern | MittelDaten über Azure | MittelSnapshots auf Provider |
| Kundenerfahrung (UX)Einfachheit aus Kundensicht | Schlecht | Sehr gut | Sehr gut | Sehr gut | Sehr gut | Sehr gut |
| Cloud-AbhängigkeitAbhängigkeit von Drittdiensten | Keine | Keine | Keine | Keine | Azure Pflicht | Keine |
| Provider-KompatibilitätFunktioniert mit Standard-Hosting | Ja | Ja | EingeschränktPort-Freigabe nötig | NeinVPN-Client nötig | Janur Azure nötig | JaSQL Server Express reicht |
| ErweiterbarkeitBelege, Bestellportal | Schlecht | Mittel | Gut | Gut | Gut | Sehr gutPush-Muster wiederverwendbar |
Empfehlung
V4 — Zwei-Modul-Split mit WireGuard-VPN
Beste Wahl wenn ein separater VPS (z. B. Hetzner, netcup) als Portal-Server eingesetzt wird. Kein interner Port nach außen offen, keine Cloud-Abhängigkeit, Adressdaten bleiben vollständig intern. WireGuard ist im Betrieb nahezu wartungsfrei.
V6 — Zwei-Modul-Split mit externem SQL Server
Beste Wahl wenn das Portal direkt auf dem bestehenden Provider-Server von enmatek.de gehostet wird und dort kein VPN-Client installiert werden kann. Der interne Server baut eine ausgehende SQL-Verbindung auf — keine Firewall-Öffnung intern nötig. Portal und Unternehmenswebsite laufen auf derselben Infrastruktur. Gut erweiterbar für Belegbereitstellung und Bestellportal.
Beide Empfehlungen schließen sich nicht aus — die Code-Basis (internes Modul mit REST-API + externes Modul) ist identisch. Der einzige Unterschied liegt im Kommunikationsweg und darin, wer die Datenbank hostet. Eine spätere Migration von V6 auf V4 (oder umgekehrt) ist möglich ohne Umbau der Anwendungslogik.
Bei V6 liegen Adress-Snapshots auf dem Provider-Server. Diese enthalten dieselben Daten, die im E-Mail-Versand ohnehin übermittelt werden. Intern prüfen: Darf ein Auftragsverarbeiter (Hosting-Provider) diese Daten speichern? Ein Auftragsverarbeitungsvertrag (AVV) mit dem Provider ist empfehlenswert.
Technischer Umsetzungsplan
Die folgende Reihenfolge gilt bei Umsetzung von Variante V4. Alle Schritte sind unabhängig voneinander testbar.
Program.cs: Token validieren, Adressdaten lesen, ChangeSet speichern. Authentifizierung per API-Key (X-Portal-Key im Header, konfiguriert in appsettings.json). Kein Zugriff ohne gültigen Key.StammdatenPortal.PortalWeb. Enthält nur die Seiten unter Pages/Portal/ und Pages/Abmelden/. Direkten DbContext-Zugriff durch einen typisierten HttpClient (PortalApiClient) ersetzen.srv-dms:5027 erreichen kann. Keine Firewall-Öffnung nach außen nötig.certbot). Domain auf externen Server zeigen lassen (portal.enmatek.de o. ä.).appsettings.json des internen Moduls: PortalBaseUrl auf die neue öffentliche URL setzen. Die Kampagne-Mailer-Logik liest diesen Wert bereits — keine Code-Änderung nötig.Neue API-Endpunkte (intern, V4)
| Methode | Pfad | Zweck |
|---|---|---|
GET |
/api/portal/token/{guid} |
Token prüfen; gibt Token-Metadaten + AdressId zurück |
GET |
/api/portal/adresse/{id}/{mandant} |
KHK-Kunden- und/oder Lieferantendaten lesen |
POST |
/api/portal/changes |
PendingChangeSet speichern |
POST |
/api/portal/optout |
Kein-Mailing-Anforderung registrieren |
Aufwandschätzung (Variante V4)
| Aufgabe | Tage |
|---|---|
| REST-API intern (4 Endpunkte + Auth) | 1,0 |
| PortalApiClient + Umbau Portal-Seiten | 1,5 |
| WireGuard-Konfiguration (beide Server) | 0,5 |
| Deployment + SSL + Domain | 0,5 |
| Test, Fehlerkorrektur, Abnahme | 0,5 |
| Gesamt | 4,0 |
Laufende Kosten: VPS ~5–15 €/Monat (Hetzner CX11 o. ä. reicht für diese Last). WireGuard: kostenlos. SSL: kostenlos (Let's Encrypt).
Ausblick: Mögliche Erweiterungen
Die Zwei-Modul-Architektur (besonders V6) ist von Anfang an so ausgelegt, dass weitere Portalfunktionen denselben Kommunikationsweg nutzen können. Zwei naheliegende Erweiterungen sind bereits identifiziert:
Belegbereitstellung (Kundenportal)
Kunden könnten im Portal ihre aktuellen Belege aus KHK einsehen — Rechnungen, Lieferscheine, Gutschriften. Der interne Server liest die relevanten Belege aus den KHK-Belegtabellen (KHKVKBelege, KHKVKBelegePositionen) und schreibt Metadaten (Belegnummer, Datum, Betrag, Status) in den externen SQL Server (V6) bzw. stellt sie über die interne API bereit (V4).
- Kunden haben jederzeit Überblick über offene Posten ohne Telefonanfragen beim Sachbearbeiter
- Kein manueller Versand von Rechnungs-PDFs mehr nötig
- Technisch: neuer Push-Schritt im bestehenden Sync-Job (V6) oder neuer API-Endpunkt (V4)
- Datenschutz: Belegdaten (Rechnungsbeträge, Positionen) sind sensitiver als Adressdaten — AVV mit Provider essenziell bei V6
- PDF-Generierung aus KHK-Daten erfordert zusätzliche Entwicklungsarbeit (kein fertiger Export vorhanden)
Bestellportal
Kunden könnten Bestellungen direkt im Portal aufgeben, die dann in KHK als Auftrag gebucht werden. Das externe Portal nimmt die Bestellung entgegen und schreibt sie in den externen SQL Server (V6) oder direkt über die interne API (V4). Ein interner Sachbearbeiter prüft und bucht den Auftrag in KHK — analog zur bestehenden Freigabe-Logik für Stammdatenänderungen.
- Direkter Bestelleingang ohne manuelle Datenerfassung in KHK
- Freigabe-Workflow bereits im System vorhanden — wiederverwendbar
- Artikel-Katalog muss aus KHK synchronisiert werden (Preise, Verfügbarkeiten)
- Erheblich mehr Entwicklungsaufwand als Belegbereitstellung
- Anforderungs- und Berechtigungskonzept muss separat definiert werden (Wer darf was bestellen?)
Beide Erweiterungen sind mit der gewählten Zwei-Modul-Architektur grundsätzlich umsetzbar. V6 hat dabei einen Vorteil: der Push-Mechanismus (intern schreibt auf extern) ist für Artikel-Kataloge und Belegdaten direkt wiederverwendbar, ohne dass am Portal-Code etwas geändert werden muss — es kommen nur neue Tabellen im externen SQL Server hinzu.
Offene Fragen vor der Entscheidung
- Variante V4 oder V6: Kann auf dem Provider-Server (enmatek.de) ein VPN-Client (WireGuard) installiert werden? Falls nein → V6. Falls ja → V4 mit besserem Datenschutzprofil.
- Provider-Infrastruktur (V6): Ist SQL Server Express auf dem Provider-Server installierbar? Kann TCP-Port 1433 per Firewall auf die IP von srv-dms beschränkt werden (kein öffentlicher Zugriff)?
- Domain / DNS: Das Portal soll unter
enmatek.deerreichbar sein — welche Subdomain? (portal.enmatek.de,stammdaten.enmatek.de?). SSL-Zertifikat über Provider oder Let's Encrypt? - Datenschutz / AVV (V6): Besteht ein Auftragsverarbeitungsvertrag mit dem Hosting-Provider? Falls nicht: vor Go-Live abschließen, da Adress-Snapshots auf dem Provider-Server gespeichert werden.
- Servertyp: Welches Betriebssystem läuft auf dem Provider-Server (Windows Server oder Linux)? Beeinflusst Deployment-Methode und ggf. VPN-Client-Wahl.
- Verfügbarkeitsanforderung: Wie kritisch ist ein mehrstündiger Portal-Ausfall? Bei V4 fällt das Portal bei VPN-Ausfall aus; V6 ist unabhängig vom internen Server.
- Erweiterungen: Sind Belegbereitstellung oder Bestellportal in 1–2 Jahren geplant? Falls ja, ist V6 klar vorzuziehen — der Sync-Mechanismus ist direkt wiederverwendbar.
Entscheidungsprotokoll
Dieser Abschnitt wird nach Abschluss der Entscheidung ausgefüllt und dient als Referenz für die spätere Umsetzung.