Wenn ja, ist es ganz einfach: Der zweite Administrator meldet sich an, öffnet die Benutzerverwaltung, wählt den betreffenden Zugang aus und erstellt einen neuen Einladungslink. Über diesen Link kann ein neues Passwort vergeben werden. Dafür ist kein technisches Wissen nötig, alles läuft im Browser.
Gibt es keinen zweiten Administrator und kommt niemand mehr hinein, hilft ein kleines Wartungswerkzeug direkt auf dem Server. Dazu wird über SSH eine Verbindung zum Server hergestellt und im Verzeichnis der App ein Skript ausgeführt:
cd /root/eventmvp/event_mgrvenv/bin/python3 reset_admin.pyDas Programm zeigt danach eine Internetadresse an. DEINE-DOMAIN muss durch die Adresse der Installation ersetzt werden. Wird die Adresse im Browser eingegeben, kann nun ein neues Passwort vergeben werden. Der Link ist 14 Tage gültig, gibt vollen Administrator-Zugang und sollte deshalb nicht offen weitergegeben werden. Nach dem Setzen des Passworts verliert er automatisch seine Gültigkeit.
Wer sich mit SSH nicht auskennt und keinen zweiten Administrator hat, kann sich an kontakt@veranstalterei.de wenden. Solche Fälle sind selten und lassen sich per Fernzugriff meist schnell lösen.
Ein Tipp, damit das gar nicht erst passiert: Gleich zu Beginn einen zweiten Administrator anlegen. Das erspart im Ernstfall den Weg über die Kommandozeile, ganz ohne Technik.
Ja. Wichtig ist dabei die Unterscheidung zwischen dem Server und der Software selbst.
Der Server
Die Sicherheit des Servers hängt nicht von der Veranstalterei ab. Ubuntu installiert sicherheitsrelevante Aktualisierungen automatisch, unabhängig davon, ob es neue Versionen von der Veranstalterei gibt. Diese Automatik wird bei der Einrichtung eingeschaltet und läuft ohne weiteres Zutun. Der Unterbau bleibt damit geschützt, solange die installierte Ubuntu-Version unterstützt wird, in der Regel rund fünf Jahre. Was danach zu tun ist, steht in der Frage zum Server-Betriebssystem.
Die Software
Die Veranstalterei läuft auf dem eigenen Server als internes Werkzeug für das Team, nicht als offener Dienst im Internet. Die Angriffsfläche ist dadurch gering. Der Zugang ist durch Anmeldung geschützt, die Verbindung durchgehend verschlüsselt. Solange die Anwendung wie vorgesehen hinter eigener Domain und Anmeldung betrieben wird, ist der Betrieb auch ohne neue Programmversionen unbedenklich.
Keine Abhängigkeit vom Hersteller
Die Veranstalterei ist gekauft, nicht gemietet. Die Software liegt auf dem eigenen Server und läuft dort eigenständig weiter. Anders als bei einem Abonnement endet die Nutzung nicht, wenn ein Anbieter den Dienst einstellt. Auch die Daten bleiben jederzeit im eigenen Zugriff und lassen sich als Sicherung herunterladen.
Für einen sehr langen Betrieb über viele Jahre empfiehlt es sich, gelegentlich zu prüfen, ob das Server-Betriebssystem noch mit Sicherheitsupdates versorgt wird, und es bei Bedarf zu erneuern.
Auf dem Server läuft Ubuntu. Jede Ubuntu-Version erhält rund fünf Jahre lang automatisch Sicherheitsupdates. Danach sollte der Server einmal auf eine neue Version gebracht werden. Das steht ungefähr alle fünf Jahre an und dauert etwa eine Stunde. Ein zweiter Server ist dafür nicht nötig, und die Internetadresse bleibt dieselbe.
Wann ist es soweit?
Als Faustregel: fünf Jahre nach der Einrichtung von der Veranstalterei. Viele Anbieter weisen vorher darauf hin. Im Zweifel genügt eine kurze Nachfrage beim Server-Anbieter, ob das Betriebssystem noch Sicherheitsupdates erhält.
Ablauf
Am besten an einem ruhigen Tag. Die Veranstalterei ist währenddessen etwa eine Stunde lang nicht erreichbar.
-
Backup herunterladen. In der Veranstalterei anmelden, auf
Verwaltung gehen und Backup herunterladen anklicken. Die Datei
endet auf
.dbund sollte an einem leicht wiederauffindbaren Ort gespeichert werden, zum Beispiel auf dem Schreibtisch. Bei dieser Gelegenheit auch den Lizenzschlüssel bereitlegen. - Zugangsschlüssel prüfen. Im Kundenbereich des Server-Anbieters anmelden und nachsehen, ob der SSH-Schlüssel dort noch hinterlegt ist. Falls nicht, erneut hinterlegen. Wie das geht, steht in der Installationsanleitung.
- Server neu aufsetzen. Im Kundenbereich des Anbieters gibt es eine Funktion, die meist Neu installieren, Reinstall oder Image neu aufsetzen heißt. Dort die neueste Ubuntu-Version mit dem Zusatz LTS wählen und darauf achten, dass der SSH-Schlüssel übernommen wird. Der Vorgang dauert einige Minuten.
- Veranstalterei installieren. Genauso wie bei der ersten Einrichtung, beschrieben in der Installationsanleitung. Internetadresse und Server bleiben dieselben, es muss also nichts bestellt und nichts umgestellt werden.
-
Backup einspielen. Die Veranstalterei im Browser aufrufen und den
Administrator-Zugang neu anlegen. Das Passwort darf dabei beliebig sein, es wird
gleich wieder ersetzt. Anschließend auf Verwaltung gehen und unter
Backup einspielen die Datei aus Schritt 1 auswählen.
Nach dem Einspielen erfolgt eine Abmeldung. Die Anmeldung geschieht jetzt wieder mit dem alten Benutzernamen und Passwort, so wie vor dem Neuaufsetzen. Der eben angelegte Zugang wurde durch das Backup ersetzt, ebenso wie alle Zugänge der Mitarbeitenden.
Wer sich das nicht zutraut, gibt die Aufgabe an einen IT-Dienstleister ab. Für ihn sind die folgenden Angaben gedacht.
Für den IT-Dienstleister
-
Veranstalterei ist eine Flask-Anwendung mit SQLite-Datenbank, betrieben
über Gunicorn hinter nginx, systemd-Unit
eventmgr. -
Ein
do-release-upgradewird nicht empfohlen. Die virtuelle Python-Umgebung ist gegen die vorhandene Python-Version gebaut und muss nach einem Versionssprung ohnehin neu erzeugt werden. Eine Neuinstallation ist der vorhersehbarere Weg. - Empfohlener Ablauf: Datenbank sichern, Server mit aktueller Ubuntu-LTS neu aufsetzen, Installationsskript ausführen, Datenbank zurückspielen.
-
Das Installationsskript richtet nginx, Zertifikat, systemd-Unit,
virtuelle Umgebung und automatische Sicherheitsupdates ein:
curl -fsSL https://dl.veranstalterei.de/install.sh -o install.sh && sudo bash install.sh -
Die Datenbank liegt unter
/root/eventmvp/event_mgr/instance/event_mgr.db. Das über die Oberfläche erzeugte Backup ist genau diese SQLite-Datei und kann alternativ direkt dorthin kopiert werden, bei gestopptem Dienst und ohne die-wal- und-shm-Dateien. -
Automatische Backups liegen unter
/root/eventmvp/event_mgr/instance/backups/. -
Wenn keine Programmversionen mehr erscheinen, lassen sich die
mitgelieferten Python-Pakete eigenständig anheben. In der virtuellen
Umgebung unter
/root/eventmvp/event_mgr/venv:
venv/bin/pip install --upgrade <paket>
Anschließendsystemctl restart eventmgr. Bekannte Schwachstellen zeigtvenv/bin/pip-audit -r requirements.txt. -
Rückweg bei Problemen:
venv/bin/pip install -r requirements.txt --force-reinstallsetzt alle Pakete auf den ausgelieferten Stand zurück. Die Datenbank ist davon nicht betroffen.
Ja, durchgehend. Der Zugriff läuft ausschließlich über eine verschlüsselte HTTPS-Verbindung. Unverschlüsselte Aufrufe werden automatisch auf die sichere Verbindung umgeleitet.
Technisch: Das Zertifikat stammt von Let's Encrypt und wird automatisch erneuert.
Der Server sendet zusätzlich den Header Strict-Transport-Security (HSTS),
sodass der Browser für die Domain nur noch verschlüsselte Verbindungen zulässt. Es
kommen ausschließlich aktuelle TLS-Verfahren zum Einsatz.
Der Webserver ist so eingestellt, dass gängige Angriffe über den Browser ins Leere laufen und keine unnötigen Informationen über das System nach außen dringen.
Technisch: Gesetzt werden unter anderem eine Content-Security-Policy gegen
das Einschleusen fremder Skripte, X-Frame-Options und
frame-ancestors gegen Clickjacking, X-Content-Type-Options
gegen MIME-Sniffing sowie eine Referrer-Policy. Die Server-Version wird
über server_tokens off verborgen.
Ja. Die Einrichtung aktiviert automatisch eine Firewall. Von außen sind nur die nötigen Zugänge erreichbar, der Rest wird blockiert.
Technisch: Eingesetzt wird UFW mit der Grundhaltung eingehend sperren, ausgehend erlauben. Eingehend offen sind nur SSH sowie HTTP und HTTPS (Ports 22, 80, 443). Ausgehende Verbindungen bleiben offen, damit Mailversand, Reservierungsportale und der Update-Server erreichbar sind.
Der Zugang ist durch Anmeldung geschützt, und die Veranstalterei ist ein internes Werkzeug, kein offener Dienst im Internet. Die Angriffsfläche ist dadurch klein.
Technisch: Wiederholte Fehlanmeldungen werden serverseitig gebremst, sodass automatisiertes Passwortraten wirkungslos ist. Zugänge sind über abgestufte Rollen geregelt, wer nur lesen darf, kann nichts verändern. Der Anwendungsprozess selbst ist von außen nicht direkt erreichbar, sondern nur über den vorgelagerten Webserver (nur lokal gebundenes Gunicorn hinter nginx).
Sensible Zugangsdaten wie das Passwort des Mailservers werden nicht im Klartext gespeichert, sondern verschlüsselt.
Technisch: Passwörter der Benutzerkonten werden als Hash abgelegt und sind nicht rückrechenbar. Hinterlegte Mailserver-Zugangsdaten werden mit einem installationseigenen Schlüssel verschlüsselt in der Datenbank gespeichert. Selbst wer die Datenbankdatei erhielte, könnte diese Zugangsdaten ohne den Schlüssel nicht lesen.
Die Veranstalterei versendet E-Mails über den in den Einstellungen hinterlegten eigenen Mailserver und verhält sich dabei wie ein E-Mail-Programm, das sich dort anmeldet.
Technisch: Ob eine Nachricht ankommt oder im Spam landet, entscheidet die Konfiguration dieses Mailservers, insbesondere die DNS-Einträge SPF, DKIM und DMARC. Diese werden beim jeweiligen Mailanbieter eingerichtet, nicht in der Veranstalterei. Bei Zustellproblemen ist deshalb die Einstellung des verwendeten Mailkontos der richtige Ansatzpunkt.