--- title: DMZ-Betrieb für KuferWEB description: "Die KuferWEB-DMZ-Architektur erklärt: Wie KuferSQL, KuferTransfer, BAS_DMZ, Webserver und Teilnehmer zusammenspielen, welche Ports an welcher Stelle offen sein müssen, und wie Online-Anmeldungen in Echtzeit in KuferSQL ankommen." --- [Zu Content springen](https://cs.kufer.de/de-de/kb/kuferweb/dmz-betrieb-fuer-kuferweb#main-content) [![logo](https://cs.kufer.de/hubfs/CI/logo.svg)](https://cs.kufer.de/kufer-wissensdatenbanken?hsLang=de-de) - [Website](https://www.kufer.de/) Hauptnavigation öffnen Hauptnavigation schließen - [Website](https://www.kufer.de/) Wie können wir Ihnen helfen? - Es gibt keine Vorschläge, da das Suchfeld leer ist. 1. [KuferWEB](https://cs.kufer.de/de-de/kb/kuferweb?hsLang=de-de) 2. [KuferWEB-Betrieb](https://cs.kufer.de/de-de/kb/kuferweb/kuferweb-betrieb?hsLang=de-de) 9\. Oktober 2026 # DMZ-Betrieb für KuferWEB ## Architektur und Datenfluss zwischen KuferSQL, KuferTransfer, BAS\_DMZ, Webserver und Teilnehmer — Ports, Reihenfolge und Aufgaben der einzelnen Komponenten KuferWEB stellt Ihren Veranstaltungskatalog im Internet bereit — der eigentliche Datenbestand bleibt aber in Ihrer Einrichtung in KuferSQL. Damit Teilnehmer Kurse in Echtzeit buchen können, ohne dass Ihre interne Datenbank direkt aus dem Internet erreichbar wäre, sitzt der **BAS\_DMZ-Dienst** als sichere Brücke dazwischen. Dieser Artikel erklärt das Zusammenspiel von KuferSQL, KuferTransfer, BAS\_DMZ, Webserver und Teilnehmer — inklusive aller relevanten Ports. ℹ️ **Voraussetzung:** Eine eingerichtete KuferWEB-Instanz mit aktivem KuferTransfer und BAS\_DMZ sowie Firewall-Freigaben, die vor der Auslieferung mit Hoster und Kufer abgestimmt wurden — welche Grundsätze dabei gelten und wo die verbindlichen Angaben gepflegt werden, führen die [Systemvoraussetzungen für KuferSQL, KuferWEB und KuferTools](https://cs.kufer.de/de-de/kb/uebergreifend/systemvoraussetzungen-kufersql-kuferweb-kufertools?hsLang=de-de). ⚠️ **Achtung:** Die hier beschriebene Architektur ist der **empfohlene Standard-Betrieb**. Abweichende Setups (z. B. BAS\_DMZ ohne KuferTransfer, Mailversand ausschließlich über BAS\_DMZ) sind möglich — sprechen Sie diese vor Inbetriebnahme mit Kufer-Support ab, damit Ports und Verbindungen passen. ## Warum eine DMZ? Eine **DMZ** (demilitarisierte Zone) ist eine Netzwerk-Trennung, die öffentliche und interne Systeme entkoppelt. Wo diese DMZ-Architektur im Gesamtgefüge der Kufer-Systeme einzuordnen ist, zeigt der [Überblick zu Betrieb und Systemarchitektur](https://cs.kufer.de/de-de/kb/uebergreifend/hub-betrieb-und-systemarchitektur-im-ueberblick?hsLang=de-de). Bei KuferWEB heißt das: Der **Webserver im Internet** und die **KuferSQL-Datenbank in Ihrer Einrichtung** kommunizieren niemals direkt. Stattdessen vermittelt der **BAS\_DMZ-Dienst** zwischen beiden: BAS\_DMZ **horcht auf einem eigenen Port**, der Web-Baustein **baut die Verbindung dorthin auf** und übergibt die verschlüsselten Daten. BAS\_DMZ nimmt sie entgegen, entschlüsselt sie, schreibt sie in die KuferSQL-Datenbank und meldet das Ergebnis an den Web-Baustein zurück. Der **BAS\_DMZ-Dienst muss dafür aus dem Internet kontaktierbar sein** — über einen offenen Port bzw. eine Portweiterleitung oder alternativ über einen Reverse Proxy. Die **KuferSQL-Datenbank selbst** bleibt dagegen im internen Netz und muss nie aus dem Internet erreichbar sein. Diese Trennung bringt drei Vorteile: - **Sicherheit:** KuferSQL bleibt im internen Netz, ohne öffentliche Ports — aus dem Internet ist ausschließlich der vorgelagerte BAS\_DMZ-Dienst ansprechbar, und auch der nur verschlüsselt. - **Aktualität:** Online-Anmeldungen erreichen KuferSQL in Echtzeit über den BAS\_DMZ-Kanal — nicht erst beim nächsten Datentransfer. - **Performance-Entkopplung:** Veranstaltungs-Katalog und Platzstatus laufen über die **MySQL-Datenbank** auf dem Webserver, also entkoppelt vom KuferSQL-Live-Betrieb. Lastspitzen im Web bremsen Ihre interne Verwaltung nicht aus. ## Die fünf beteiligten Komponenten In der KuferWEB-DMZ-Architektur arbeiten fünf Komponenten zusammen — drei davon im Netz der Einrichtung, zwei auf dem Webserver im Internet: - **KuferSQL-Datenbank (Einrichtung):** MS-SQL (Port 1433) oder Oracle (Port 1521). Hier liegen alle Stammdaten — Kurse, Teilnehmer, Anmeldungen, Finanzen. - **KuferTransfer (Einrichtung):** Überträgt regelmäßig Kurs- und Stammdaten von KuferSQL in die MySQL-Datenbank auf dem Webserver. Diese Datenbank ist nicht öffentlich erreichbar — sie wird ausschließlich serverintern von KuferWEB gelesen. - **BAS\_DMZ (Einrichtung):** Horcht auf einem eigenen Port und nimmt die Anfragen entgegen, die der Web-Baustein dorthin schickt — z. B. Online-Anmeldungen. Er schreibt sie unmittelbar in die KuferSQL-Datenbank. - **MySQL-Datenbank (Webserver):** Datenbank für die öffentliche Veranstaltungsanzeige und für die Platzreservierung. - **KuferWEB (Webserver):** Frontend, das Teilnehmer im Browser sehen — Kursübersicht, Kursdetail, Anmeldeformular, Bestätigungsmail. ## Datenfluss: Kursanzeige bis Anmeldebestätigung Das folgende Diagramm zeigt den vollständigen Datenfluss vom Stammdaten-Pflegevorgang in KuferSQL bis zur Bestätigungs-E-Mail im Postfach des Teilnehmers. ![Architektur-Diagramm „Einrichtung” (linke Hälfte mit Anwender, KuferSQL, BAS\_DMZ und Datentransfer-Antenne) und „Webserver im Internet” (rechte Hälfte mit Teilnehmer, KuferWEB, MySQL-Datenbank, Mailserver), mit Pfeilen für die nummerierten Schritte 1–4 und beschrifteten Ports zwischen den Komponenten](https://cs.kufer.de/hubfs/kb-content/kuferweb/kuferweb-betrieb/dmz-betrieb-fuer-kuferweb/01-dmz-architektur-datenfluss.png) *KuferWEB-DMZ-Architektur — Datenfluss zwischen Einrichtung und Webserver mit allen Ports und nummerierten Schritten 1 bis 4* Der Ablauf in vier Schritten: 1. **Anzeige + Platzreservierung (Kursstatus, Port 3306):** Dem Teilnehmer stehen verschiedene Möglichkeiten zur Verfügung, passende Veranstaltungen zu finden und deren Details einzusehen. KuferWEB liest die Kursdaten und den aktuellen Status aus der **MySQL-Datenbank** auf dem Webserver. 2. **Buchen der Kurse (HTTPS, Port 443):** Diese Veranstaltungen können vom Teilnehmer online gebucht werden. Die Anmeldung erfolgt im Browser ausschließlich verschlüsselt über HTTPS. 3. **Statusabfrage und Übermittlung der Anmeldung (Port 8999, verschlüsselt, HTTPS möglich):** Die Anmeldungen werden direkt in die KuferSQL-Datenbank geschrieben — in der Regel in die Einbuchungsroutine bei gleichzeitiger Platzreservierung. Diese Übertragung läuft über den **BAS\_DMZ-Kanal** auf einem frei definierbaren Port (Standard `8999`), verschlüsselt und ohne dass die KuferSQL-Datenbank selbst aus dem Internet erreichbar sein muss — angesprochen wird ausschließlich der BAS\_DMZ-Dienst. 4. **Bestätigung (Mailversand Port 25, 587 oder 465):** Der Teilnehmer erhält eine Bestätigungs-E-Mail, in der der Status der Anmeldung anhand des Live-Datenbestands berechnet wurde. Bei den entsprechenden Veranstaltungen wird zeitgleich in der MySQL-Datenbank eine Platzreservierung eingetragen, um den Platz bis zum nächsten Datentransfer zu belegen. ℹ️ **Mailversand-Varianten:** E-Mails können auch per BAS\_DMZ versendet werden. Der SMTP-Server muss in diesem Fall aus dem Netzwerk der Einrichtung erreichbar sein. Mailversand per oAuth: E-Mails aus KuferWEB können mit dem Plugin „oauth” auch per oAuth versendet werden. Die Einrichtung beschreibt „E-Mail-Versand per OAuth2 für KuferSQL und KuferWEB einrichten”. ## Aufgaben des KuferTransfer **KuferTransfer** ist der Datentransfer-Dienst von KuferSQL in die MySQL-Datenbank auf dem Webserver. Er läuft als Windows-Dienst auf einem Server in Ihrer Einrichtung und überträgt die einzelnen Datengruppen in einstellbaren Intervallen. Den Aufbau (Dienst, Konfigurator, Plugins) beschreibt [Was ist KuferTransfer?](https://cs.kufer.de/de-de/kb/uebergreifend/kufertransfer-verstehen-und-voraussetzungen?hsLang=de-de), die Voraussetzungen stehen in [KuferTransfer installieren](https://cs.kufer.de/de-de/kb/uebergreifend/kufertransfer-installieren?hsLang=de-de). Was KuferTransfer tut: - Liest neue und geänderte Kurs- und Stammdaten aus KuferSQL. - Schreibt diese Daten über **HTTPS** (Port 443) in die MySQL-Datenbank auf dem Webserver. - Aktualisiert den Datenbestand, den KuferWEB den Teilnehmern anzeigt. 💡 **MySQLoverHTTP:** Der Schreibzugriff läuft über **MySQLoverHTTP** — ein PHP-Skript im KuferWEB-Verzeichnis auf dem Webserver. Der direkte MySQL-Port muss dafür nicht nach außen freigegeben werden. KuferTransfer spricht das Skript unter **MySQLoverHTTP → Adresse des Skripts** an. ## Aufgaben des BAS\_DMZ **BAS\_DMZ** ist der Echtzeit-Brückendienst zwischen KuferWEB und KuferSQL. Anders als KuferTransfer läuft er **permanent als Dienst**, nicht im Zeit-Takt, und sorgt dafür, dass Online-Anmeldungen sofort in KuferSQL ankommen. Bei jedem KuferWEB-Update wird auch BAS\_DMZ mit aktualisiert — wie das abläuft, beschreibt der [KuferWEB-Update-Prozess](https://cs.kufer.de/de-de/kb/kuferweb/kuferweb-update-prozess?hsLang=de-de). Was BAS\_DMZ tut: - Horcht auf einem frei definierbaren Port (Standard `8999`, verschlüsselt) auf eingehende Anfragen — die Verbindung baut jeweils der Web-Baustein auf, nicht BAS\_DMZ. - Entschlüsselt die übergebenen Daten, wertet sie aus, schreibt sie direkt in die KuferSQL-Datenbank und gibt eine Rückmeldung an den Web-Baustein zurück. - Trägt im Protokoll der KuferSQL-Datenbank den Vorgang ein. Datenänderung und Protokollierung laufen in **einer Transaktion**: Tritt ein Fehler auf, wird für diese Aktion kein Eintrag geschrieben. - Optional: Versendet Bestätigungs-Mails über den SMTP-Server der Einrichtung. - Optional: Lädt Dokumente (z. B. Ermäßigungsnachweise) zwischen Webserver und File-Server der Einrichtung hoch/herunter. 💡 **Übermittlungsart aktivieren:** Damit Anmeldungen tatsächlich über BAS\_DMZ geschrieben werden, muss das im KuferWEB-Webadmin bei der Übermittlungsart unter **Übermittlung der Anmeldungen** aktiviert sein. Die Verbindungsdaten (Adresse, Port, Protokoll) stehen unter **Einstellungen \> System \> Einstellungen DMZ**. ⚠️ **Dienst muss laufen:** Läuft der BAS\_DMZ-Dienst nicht — oder ist die Verbindung zu ihm unterbrochen, etwa während eines Updates —, **kommen in der KuferSQL-Datenbank keine Anmeldungen an**, sofern Ihre Anmeldungen über BAS\_DMZ laufen. Setzen Sie den Dienst deshalb auf den Start-Typ **„Automatisch (verzögerter Start)”** und hinterlegen Sie auf dem Reiter **Wiederherstellung** für alle Fehlerfälle **„Dienst neu starten”**. Prüfen Sie nach Server-Updates oder Neustarts immer den Status — im KuferWEB-Webadmin lässt sich unter **Einstellungen \> System \> Einstellungen DMZ** testen, ob eine Verbindung aufgebaut werden kann. Wie BAS\_DMZ-Stände bei einem Update gesichert und im Notfall zurückgespielt werden, behandelt der Artikel [KuferWEB-Versionen und Rollback](https://cs.kufer.de/de-de/kb/kuferweb/kuferweb-versionen-und-rollback?hsLang=de-de). ## Ports im Überblick Die Ports der KuferWEB-DMZ-Architektur zusammengefasst: - **KuferSQL-Datenbank:** MS-SQL Port **1433**, Oracle Port **1521** (nur intern). - **MySQL-Datenbank (Webserver):** Port **3306** (serverintern für KuferWEB). - **Webserver:** HTTPS Port **443**, SFTP Port **22**, FTP Port **21**. - **KuferTransfer → Webserver:** MySQLoverHTTP über HTTPS Port **443**. - **Webserver → BAS\_DMZ:** frei definierbarer Port (Standard `8999`), verschlüsselt — HTTPS möglich. Die Verbindung geht vom Webserver zum BAS\_DMZ-Dienst. - **Mailversand:** SMTP Port **25**, **587** oder **465**. ℹ️ **Firewall-Hinweis:** Der **BAS\_DMZ-Dienst muss aus dem Internet kontaktierbar sein** — dafür braucht es einen offenen Port bzw. eine Portweiterleitung auf den BAS\_DMZ-Server (z. B. Port `8999`). Alternativ läuft der Zugriff im HTTPS-Betrieb über einen **Reverse Proxy**; dann muss nur der Reverse Proxy aus dem Internet erreichbar sein, und BAS\_DMZ wird von ihm intern angesprochen. Die **KuferSQL-Datenbank selbst** braucht dagegen keine Erreichbarkeit aus dem Internet — sie bleibt im internen Netz. 💡 **Adresse im Webadmin:** Die DMZ muss durchgängig unter einer Adresse mit dem eingestellten Port erreichbar sein. Dies kann eine feste IP-Adresse oder eine Proxy-Domain sein. Ist BAS\_DMZ nicht direkt erreichbar, tragen Sie im Webadmin die Adresse des Proxy-Servers bzw. der Firewall ein, auf der die Weiterleitung eingerichtet wurde. Sind mehrere Firewalls hintereinandergeschaltet, gilt die Adresse der **äußersten** Station — also derjenigen, die der Web-Baustein direkt anspricht. ## Ergebnis Mit eingerichteter DMZ-Architektur trennen Sie öffentliche Web-Komponenten und internes KuferSQL sauber voneinander: Stammdaten fließen einseitig über KuferTransfer in die MySQL-Datenbank auf dem Webserver, eingehende Anmeldungen kommen verschlüsselt über BAS\_DMZ in Echtzeit in KuferSQL an, und Bestätigungs-Mails werden zuverlässig zugestellt. Ihre interne Datenbank bleibt dabei niemals direkt aus dem Internet erreichbar. ✅ **Geschafft:** Sie verstehen den vollständigen Datenfluss Ihrer KuferWEB-Installation und wissen, welche Komponente auf welchem Port spricht. - [KuferWEB-Funktionen](https://cs.kufer.de/de-de/kb/kuferweb/kuferweb-funktionen?hsLang=de-de) - [CMS-Integration](https://cs.kufer.de/de-de/kb/kuferweb/cms-integration?hsLang=de-de#main-content) - [WordPress](https://cs.kufer.de/de-de/kb/kuferweb/cms-integration?hsLang=de-de#wordpress) - [TYPO3](https://cs.kufer.de/de-de/kb/kuferweb/cms-integration?hsLang=de-de#typo3) - [Webadmin](https://cs.kufer.de/de-de/kb/kuferweb/webadmin?hsLang=de-de) - [KuferWEB-Betrieb](https://cs.kufer.de/de-de/kb/kuferweb/kuferweb-betrieb?hsLang=de-de) © 2026 Kufer Software [Datenschutz](https://www.kufer.de/datenschutz) [Impressum](https://www.kufer.de/impressum)