Wie VLYX tatsächlich betrieben wird – ohne Marketing-Nebel
Viele Anbieter sagen „sichere Cloud“ und lassen offen, was das heißt. Diese Seite beschreibt konkret, worauf VLYX läuft: virtuelle Maschinen in einem Rechenzentrum in Deutschland, darauf Linux, darauf Docker-Container je Anwendung und Datenbank – abgeschirmt durch Firewalls, private Netze und einen vorgelagerten Reverse Proxy.
VLYX wird von uns betrieben – Sie brauchen keinen Server
VLYX ist kein Softwarepaket, das Sie sich auf einen eigenen Server installieren und danach selbst pflegen müssen. Wir stellen die Umgebung bereit, härten sie, halten sie aktuell und sichern sie. Sie arbeiten im Browser.
- Betreute Instanz: Einrichtung, Aktualisierung, Sicherung und Wiederherstellung liegen bei uns.
- Getrennt je Kunde: eigene Container, eigene Datenbanken, eigene Zugangsdaten – keine gemeinsame Datenhaltung.
- Standort Deutschland: Anwendungen, Datenbanken und Dateien liegen in derselben Umgebung im deutschen Rechenzentrum.
- Keine Bindung an ein Format: verbreitete, quelloffene Bausteine statt proprietärer Speicherstrukturen.
Der Aufbau von unten nach oben
Rechenzentrum in Deutschland
Physische Sicherheit, Strom, Kühlung, Netzanbindung – vom Betreiber zertifiziert erbracht.
Cloud-VM unter Linux
Eigene virtuelle Maschine, minimal installiert, gehärtet und laufend mit Sicherheitsupdates versorgt.
Docker-Container je Dienst
Anwendung und Datenbank laufen getrennt – klar abgegrenzt statt alles auf einem System.
Reverse Proxy & Firewall davor
Nur verschlüsselte Web-Zugriffe erreichen die Anwendung. Alles andere bleibt außen.
Jede Schicht hat eine Aufgabe – und eine Grenze
Sicherheit entsteht nicht aus einer einzelnen Maßnahme, sondern daraus, dass jede Ebene die nächste möglichst wenig Angriffsfläche bietet. Fällt eine Schicht aus, steht die darunterliegende noch.
- Der Browser spricht ausschließlich verschlüsselt mit dem Reverse Proxy.
- Der Proxy spricht mit der Anwendung – nicht mit der Datenbank.
- Die Datenbank ist von außen überhaupt nicht erreichbar.
Was passiert, wenn jemand eine VLYX-Seite aufruft?
Fünf Stationen – jede mit einer eigenen Kontrollfunktion.
1 · Browser
Die Verbindung wird per HTTPS/TLS verschlüsselt aufgebaut. Ohne gültiges Zertifikat kommt keine Sitzung zustande; unverschlüsselte Aufrufe werden umgeleitet.
2 · Firewall
Auf Ebene der Cloud-Umgebung und zusätzlich auf dem Server selbst sind ausschließlich die benötigten Ports geöffnet. Alles Übrige wird verworfen, nicht nur ignoriert.
3 · Reverse Proxy
Ein vorgelagerter Proxy nimmt die Anfrage entgegen, beendet die TLS-Verbindung, setzt Sicherheits-Header und leitet gezielt an den zuständigen Container weiter. Die Anwendungen selbst sind nie direkt aus dem Internet erreichbar.
4 · Anwendungs-Container
Die VLYX-Anwendung läuft in einem eigenen Container mit eingeschränkten Rechten. Dort greifen Anmeldung, Rollenprüfung, CSRF-Schutz und Protokollierung.
5 · Datenbank-Container
Die Datenbank liegt in einem eigenen Container in einem privaten Netz, das nur die zugehörige Anwendung erreicht. Sie hat keinen nach außen veröffentlichten Port.
Daneben: Dateispeicher
Hochgeladene Dateien liegen außerhalb des Web-Verzeichnisses in einem eigenen Speicherbereich. Ausgeliefert werden sie nur über die authentifizierte Anwendung, nie über eine direkte URL.
Warum wir jede Anwendung in einen eigenen Container stecken
Klassisch landen mehrere Anwendungen auf einem Server, teilen sich PHP-Version, Bibliotheken und Datenbank. Ein Problem in einer Anwendung wird damit schnell zum Problem aller. Mit Containern trennen wir das auf.
- Eigener Container je Anwendung – Navigator, Belegmanager, Cloud und die übrigen Module laufen getrennt voneinander.
- Eigener Container je Datenbank – mit eigenem Konto und eigenem Passwort, ohne Zugriff auf fremde Datenbestände.
- Private Netze zwischen den Containern – nur ausdrücklich vorgesehene Verbindungen sind möglich.
- Definierte Stände statt gewachsener Systeme – jeder Container hat eine festgelegte Version; Updates sind reproduzierbar und rücknehmbar.
- Getrennte Umgebungen – Test und Produktion laufen nicht auf demselben Datenbestand.
Was von außen erreichbar ist
| Dienst | Von außen erreichbar |
|---|---|
| Web (HTTPS) | ja – über den Reverse Proxy |
| Anwendungs-Container | nein – nur über den Proxy |
| Datenbank | nein |
| Dateispeicher | nein – nur über die Anwendung |
| Administrativer Zugang | eingeschränkt, schlüsselbasiert |
Grundsatz: Was nicht erreichbar sein muss, ist nicht erreichbar. Offene Ports sind die Ausnahme, nicht der Normalfall.
Was laufend passiert – und nicht nur einmal bei der Einrichtung
Sicherheitsupdates
- Regelmäßige Aktualisierung von Betriebssystem und Container-Abbildern
- Beobachtung sicherheitsrelevanter Meldungen der eingesetzten Komponenten
- Reproduzierbare Aktualisierung mit definierter Rücknahmemöglichkeit
Datensicherung
- Regelmäßige Sicherung von Datenbanken und Dateibeständen
- Aufbewahrung getrennt von der laufenden Umgebung
- Wiederherstellung wird geprüft – eine ungetestete Sicherung ist keine Sicherung
Überwachung
- Erreichbarkeit, Ressourcen und Fehlerprotokolle im Blick
- Auffälligkeiten wie gehäufte Fehlanmeldungen werden sichtbar
- Protokolle liegen in der Umgebung, nicht bei einem Analysedienst
Zugriff auf die Systeme
- Administrativer Zugang schlüsselbasiert statt per Passwort
- Nur benannte Personen mit begründetem Bedarf
- Zugriffe im Rahmen der Auftragsverarbeitung geregelt
Trennung der Umgebungen
- Test- und Produktivumgebung sind getrennt
- Änderungen werden vor dem Einspielen erprobt
- Keine Echtdaten in Testumgebungen ohne ausdrückliche Absprache
Transport & Zertifikate
- HTTPS/TLS erzwungen, unverschlüsselte Aufrufe werden umgeleitet
- Automatisierte Zertifikatserneuerung
- Sicherheits-Header zentral am Proxy gesetzt
Bewährt und quelloffen statt exotisch
Wir setzen bewusst auf verbreitete Technik. Das hält die Angriffsfläche überschaubar, sorgt für schnelle Sicherheitsaktualisierungen – und macht Sie unabhängig davon, dass ausgerechnet wir Ihr System betreiben.
| Ebene | Eingesetzt | Warum |
|---|---|---|
| Rechenzentrum | Cloud-VMs eines deutschen Anbieters | Standort Deutschland, vertraglich geregelt, jederzeit skalierbar |
| Betriebssystem | Linux (Server-Distribution mit langem Wartungszeitraum) | Minimale Installation, planbare Sicherheitsaktualisierungen |
| Isolation | Docker-Container mit privaten Netzen | Jede Anwendung und Datenbank abgegrenzt, definierte Stände |
| Zugang | Reverse Proxy mit TLS-Terminierung | Ein kontrollierter Eingang, zentrale Sicherheits-Header |
| Abschottung | Cloud-Firewall und Host-Firewall | Zwei Ebenen, damit ein Konfigurationsfehler nicht sofort alles öffnet |
| Datenhaltung | MariaDB/MySQL je Anwendung | Bewährt, gut zu sichern, vollständig exportierbar |
| Anwendungen | PHP-Anwendungen der VLYX-Module | Ohne schwere Framework-Abhängigkeiten, schlank zu betreiben |
| Dateien & Zusammenarbeit | Nextcloud (von VLYX gehostet) | Etablierte Open-Source-Lösung mit großer Entwicklergemeinschaft |
Den konkreten Anbieter, den Standort und die eingesetzten Versionen legen wir im Auftragsverarbeitungsvertrag und in der Systemdokumentation Ihrer Instanz verbindlich fest – dort gehören sie hin, nicht auf eine Marketingseite.
Was wir nicht versprechen
Kein Betriebskonzept macht ein System unangreifbar, und wir behaupten das auch nicht. Was wir zusagen: eine überschaubare, dokumentierte Architektur aus bewährten Bausteinen, klare Trennung zwischen Kunden und Diensten, laufende Pflege statt eingefrorener Installationen und ein Datenbestand, den Sie jederzeit vollständig mitnehmen können. Hochverfügbarkeit, besondere Zertifizierungsanforderungen oder ein abweichender Betriebsort sind möglich – aber Gegenstand einer eigenen Vereinbarung, nicht des Standards.
Kurz beantwortet
Nein. VLYX wird von uns betrieben. Sie erhalten eine betreute Instanz in einem Rechenzentrum in Deutschland – ohne eigene Hardware, ohne Serverraum, ohne Update-Wochenenden. Für Sie bleibt der Browser.
In einem Rechenzentrum in Deutschland. Anwendungen, Datenbanken und Dateispeicher liegen in derselben Umgebung; eine Verarbeitung außerhalb der EU findet nicht statt. Den konkreten Betreiber und Standort nennen wir Ihnen im Auftragsverarbeitungsvertrag – dort gehört diese Angabe verbindlich hin.
Nein. Jeder Kunde erhält eigene Anwendungs- und Datenbank-Container mit eigenen Zugangsdaten. Es gibt keine gemeinsame Mandantentabelle, in der Ihre Daten neben denen anderer Unternehmen stehen.
Über einen vollständigen Export: Datenbankabzug und Dateibestand. Wir setzen bewusst auf verbreitete Bausteine (Linux, Docker, MariaDB/MySQL, PHP, Nextcloud) statt auf ein geschlossenes Format – ein Wechsel bleibt technisch möglich.
Datensicherungen werden getrennt von der laufenden Umgebung aufbewahrt, damit sich eine Instanz neu aufbauen lässt. Eine unterbrechungsfreie Hochverfügbarkeit sagen wir standardmäßig nicht zu – wenn Sie diese benötigen, planen wir sie gesondert.
Ihre IT möchte es genauer wissen?
Im Sicherheitsgespräch gehen wir Architektur, Betrieb, Datensicherung und Auftragsverarbeitung Punkt für Punkt durch – mit Ihren Fachleuten, nicht an ihnen vorbei.