Sicherheit und Verantwortung
Diese Seite ist die wichtigste des Buchs. Der Zugang ist mächtig, und ein Teil der Absicherung ist eine Frage der Organisation, nicht der Einstellungen.
Der Schlüssel ist der Zugang
Ein einzelnes Geheimnis öffnet den gesamten Mandanten — lesend und schreibend. Es ist gleichwertig zu einem Administratorkennwort der SelectLine und gehört genauso behandelt.
Daraus folgt:
- Nicht per E-Mail, Chat oder Ticket versenden.
- Nicht in einer Datei auf einem geteilten Laufwerk ablegen.
- Nur an Personen geben, die den Zugang wirklich brauchen.
- Bei Verdacht auf Weitergabe erneuern lassen — das entwertet alle bestehenden Verbindungen.
Was technisch abgesichert ist
| Bereich | Absicherung |
|---|---|
| Lesen | nur Abfragen, die nichts verändern; Schreibbefehle und Anweisungen, die die Datenbankverbindung umstellen, werden abgewiesen |
| Datenbanken | nur die eigene Mandantendatenbank und die Benutzerdaten der SelectLine, das Rechnungswesen nur, wenn es freigeschaltet ist — andere Mandanten auf demselben SQL-Server bleiben außen vor |
| Datenbankverbindung | eigene Verbindungen, getrennt von denen der übrigen Module und nach jeder Abfrage zurückgesetzt — eine Abfrage des Assistenten kann Lager, Shops oder Mail2SL nicht stören |
| Schreiben | über geprüfte Funktionen; Tabellen- und Spaltennamen werden gegen den Systemkatalog geprüft, berechnete Felder abgewiesen. Freies Schreiben in beliebige Tabellen gibt es nur, wenn es für die Installation freigeschaltet ist |
| Zugang | ein zufällig erzeugtes Geheimnis, zeitkonstant geprüft; Fehlversuche werden protokolliert |
| Übertragung | verschlüsselt, sobald ein Zertifikat vorliegt — der Zugang benutzt dasselbe wie die Oberfläche. Fehlt es, ist die Verbindung unverschlüsselt |
| Schlüssel | verschlüsselt in der Konfiguration abgelegt, nie im Protokoll |
| Web-Abrufe | Adressen im eigenen Netz ausgeschlossen, Größe begrenzt |
| Beleg-PDFs | nur über signierte Links mit kurzer Frist; danach wird auch die Datei gelöscht |
| Sitzungen | keine — jede Anfrage steht für sich und wird für sich geprüft, es bleibt nichts offen |
Was nicht abgesichert ist
Es gibt keine abgestuften Rechte. Der Zugang kennt kein „nur lesen" für einzelne Benutzer und keine Beschränkung auf Bereiche. Wer verbunden ist, kann alles, was der Assistent kann.
Ebenso wenig bremst der Zugang Fehlversuche: Ein falscher Schlüssel wird protokolliert, aber nicht gesperrt. Ist der Zugang von außen erreichbar, gehört eine Begrenzung der Versuche in einen vorgeschalteten Webserver — die Anwendung selbst kann das nicht. Siehe Zugang von außen.
Wer eine Trennung braucht, löst sie über die Umgebung:
- Testmandant für alles, was ausprobiert wird
- Zugang nur im eigenen Netz, solange es keinen Grund für den Zugang von außen gibt
- die Weiterleitung im Webserver abschalten, wenn der Zugang von außen pausieren soll
Empfehlung für den Anfang
- Testmandant.
- Nur im eigenen Netz.
- Nur Fragen, keine Anweisungen.
- Erst danach schreiben, erst danach nach außen.
Siehe Erstinbetriebnahme.
Was im Haus geklärt sein sollte
| Frage | Warum |
|---|---|
| Wer nutzt den Zugang? | es gibt keine Rechteverwaltung |
| Wo liegt der Schlüssel? | er ist der ganze Zugang |
| Darf geschrieben werden, und was? | technisch ist alles erlaubt |
| Wer prüft Zahlen, die weitergegeben werden? | Antworten sind reproduzierbar, aber nicht unfehlbar |
| Wer bemerkt Ungewöhnliches? | das Protokoll wird nicht von sich aus gelesen |
Nachvollziehbarkeit
Jeder Aufruf steht im Protokoll von FINN.ghost, und daran hängt der Name des Programms, das sich verbunden hat — auf beiden Zugangswegen gleichermaßen. Welche Person gefragt hat, steht dort nicht: Es gibt nur einen Schlüssel für die Installation.
Am Datensatz in der SelectLine ist nicht erkennbar, dass ein Assistent ihn angelegt hat. Wer das unterscheiden möchte, muss ins Protokoll von FINN.ghost sehen.