Sicherheit

Schutzschicht vor der Anwendung

Jede Anfrage läuft durch eine vorgelagerte Schicht, bevor sie die Anwendung erreicht. Sie setzt die Sicherheits-Kopfzeilen, wehrt Scan-Anfragen ab, begrenzt die Zahl der Anfragen je Adresse und prüft die Herkunft zustandsändernder Aufrufe.

• Content Security Policy mit einem eigenen Nonce je Anfrage und strict-dynamic. Fremde Skripte laufen nicht, auch nicht bei einer Lücke in der Oberfläche.
• frame-ancestors none und X-Frame-Options DENY: Die Anwendung lässt sich nicht in einen fremden Rahmen einbetten.
• Permissions-Policy: Standort, Kamera und Mikrofon nur für die eigene Seite, Zahlung und USB gesperrt.
• HSTS mit zwei Jahren Laufzeit im Produktivbetrieb, dazu nosniff, Referrer-Policy und Cross-Origin-Opener-Policy.
• Scan-Abwehr: Anfragen auf .php, /wp-admin, /.env, /.git oder /phpmyadmin beantwortet die Schicht mit 404, ohne die Anwendung zu behelligen.

Anfragebegrenzung

Die Grenze für die Anmeldung ist bewusst großzügig, weil ein Büro hinter einer Adresse morgens viele Anmeldungen erzeugt. Den eigentlichen Schutz gegen das Durchprobieren von Passwörtern übernimmt die Kontosperre je Adresse.

Anmeldung und Konten

• Kontosperre. Acht Fehlversuche in 15 Minuten sperren die E-Mail-Adresse für 15 Minuten, auch bei richtigem Passwort. Eine erfolgreiche Anmeldung setzt den Zähler zurück.
• Keine Auskunft über Konten. Eine unbekannte Adresse bekommt dieselbe Meldung und dieselbe Antwortzeit wie ein falsches Passwort.
• Passwortregeln. Mindestens zehn Zeichen, keine sehr verbreiteten Passwörter, nicht die eigene Adresse, nicht nur ein Zeichen. Gespeichert wird ein bcrypt-Hash.
• Anmeldeprotokoll. Zeit, Adresse und Ergebnis je Versuch. Jede Person sieht ihre letzten erfolgreichen Anmeldungen und die verwendete Anmeldeart.
• Abmelden auf allen Geräten. Beendet sämtliche Sitzungen der Person sofort.
• Uploads. Der tatsächliche Dateityp wird an den Magic Bytes geprüft. Eine als PNG benannte PDF wird abgewiesen.

Zwei-Faktor-Anmeldung

Die Einrichtung läuft über einen QR-Code für die üblichen Authenticator-Apps, mit Schlüssel zum Abtippen und Bestätigung durch den ersten Code. Erst danach ist der zweite Faktor aktiv. Acht Wiederherstellungscodes werden einmalig angezeigt und sind je einmal gültig.

Beim Anmelden entsteht nach dem Passwort ein signiertes Zwischen-Cookie mit fünf Minuten Laufzeit; die Sitzung entsteht erst nach einem gültigen Code. Fehlversuche zählen für die Kontosperre. Das Geheimnis liegt mit AES-256-GCM verschlüsselt in der Datenbank, die Wiederherstellungscodes nur als SHA-256-Hash.

Je Firma lässt sich der zweite Faktor für Administratoren erzwingen: Ein Admin ohne zweiten Faktor sieht auf jeder Seite nur die Einrichtung, und das Abschalten ist gesperrt. Mitarbeitende sind davon nicht betroffen. Wer sein Gerät verliert, bekommt den zweiten Faktor von einem Admin in der Personalakte zurückgesetzt; der Vorgang steht im Audit-Protokoll.

Fremdanmeldung über Microsoft und Google

Beide laufen als OpenID Connect im Authorization-Code-Flow. State und Nonce sind kurzlebige Cookies, Empfänger und Aussteller des Tokens werden geprüft. Es werden keine Konten angelegt und keine Zugriffstokens gespeichert.

Die Adresse liest die Anwendung bei Microsoft aus upn oder preferred_username und nur ersatzweise aus email; ein Token, das ausschließlich email mitbringt, gilt als unbestätigt und wird abgewiesen. Grund: email ist in Entra ein frei setzbares Profilfeld und damit kein Nachweis. Bei Google muss email_verified gesetzt sein. Je Firma sind erlaubte Verzeichnis-IDs und erlaubte E-Mail-Domains zu hinterlegen; ohne Eintrag ist die Fremdanmeldung für diese Firma aus, und Freimail-Domains werden beim Speichern abgelehnt.

Trennung der Firmen

Eine Installation bedient beliebig viele Firmen. Jede fachliche Tabelle trägt eine Mandantenspalte, und ein Wächter im Datenbankzugriff setzt und prüft sie bei jeder Abfrage. Fehlt der Mandant im Kontext, wird der Zugriff abgelehnt, statt ungefiltert ausgeführt zu werden. Der Mandant kommt aus dem angemeldeten Konto, nicht aus der aufgerufenen Adresse.

Die Dateiablage ist je Firma getrennt. Ein KI-Zugriff über die MCP-Schnittstelle hängt an einer Person und damit an genau einer Firma; einen firmenübergreifenden Systemschlüssel gibt es nicht. Ein Prüflauf weist die Trennung gegen eine echte Datenbank nach.

Nachvollziehbarkeit

• Zeiten werden nicht überschrieben, sondern über Korrekturanträge geändert. Eine so entstandene Buchung ist als solche gekennzeichnet.
• Jeder Eingriff durch Vorgesetzte oder Admins in fremde Zeiten steht im Audit-Protokoll, ebenso jedes erzeugte Personaldokument.
• Kündigungen entstehen erst nach der Freigabe durch eine zweite berechtigte Person.
• Eine abgeschlossene Fahrt im Fahrtenbuch ist festgeschrieben und nicht mehr änderbar.
• Exportierte Abrechnungspositionen sind gegen einen zweiten Export gesperrt.

Betrieb

Die Anwendung läuft als Container hinter einem Reverse Proxy, die Daten liegen in einer PostgreSQL-Datenbank in Deutschland. Der Zugang zur Plattformverwaltung lässt sich zusätzlich auf freigegebene Netze beschränken, und eine Sperrliste blockiert einzelne Adressen für die gesamte Anwendung.