Technische und organisatorische Maßnahmen

Technische und organisatorische Maßnahmen (TOM)

Stand: 12.10.2026 · V117-2026-10-12

Zeitkommando ist technisch und organisatorisch auf einen DSGVO-konformen Betrieb ausgelegt. Die folgenden Maßnahmen beschreiben den aktuellen Plattform V117 · Windows-Firmenanwendung 30.0.22 · Android 4.3.19 · PWA 4.0.14-pwa.11 · Material Android 1.3.8 · Material Windows 1.3.4 und werden im Betrieb regelmäßig überprüft.

1. Mandanten- und Datentrennung

• Eigene operative MySQL-Datenbank je produktivem Kundenmandanten; die zentrale Plattformdatenbank dient nur Mandantenzuordnung, Plattformverwaltung, Bestellung, Abrechnung und Support.
• Serverseitige Mandantenauswahl über Firmencode und registrierte Datenbankzuordnung.
• Mandantenbezogene private Dateipfade für Personalunterlagen, Profilbilder und Wachbuch-Audioentwürfe.
• Automatisierte Mandanten-Isolationstests prüfen zentrale API- und Datenzugriffsgrenzen gegen Cross-Tenant-Zugriffe.

2. Identitäts- und Zugriffskontrolle

• Anmeldung über Firmencode, persönliche E-Mail-Adresse und Passwort; Passwörter werden als sichere Passwort-Hashes gespeichert.
• Rollen- und Rechtehierarchie mit serverseitig durchgesetzten Seiten- und Datensichten sowie gesonderten Rechten für sensible Bereiche.
• Zentrale Plattformadministration mit TOTP-/Authenticator-2FA und zusätzlichem IP-basiertem Login-Rate-Limiting. Das TOTP-Geheimnis wird bei der Einrichtung wahlweise als lokal im Browser erzeugter QR-Code oder als manueller Einrichtungsschlüssel bereitgestellt; für die QR-Erzeugung wird kein externer QR-Dienst verwendet.
• Mobile Sitzungen der Android-Plattformverwaltung sind serverseitig widerrufbar und laufen nach spätestens 7 Tagen absolut ab; Nutzung verlängert diese Frist nicht. Token und serverseitiges Ablaufdatum werden lokal gemeinsam mit Android Keystore/AES-GCM geschützt gespeichert und bei Ablauf oder nicht mehr gültiger Authentifizierung verworfen. Die Plattform-WebView akzeptiert nur HTTPS-Ziele der freigegebenen Zeitkommando-Domain.
• Android-API-Sitzungen werden gerätebezogen geführt; Access- und Refresh-Token werden serverseitig ausschließlich als SHA-256-Hashes gespeichert, zeitlich begrenzt, rotiert und widerrufbar verwaltet.
• Gespeicherte Android-Sitzungsdaten werden mit einem Schlüssel aus dem Android Keystore und AES-GCM verschlüsselt.
• Die PWA erhält keine Access-/Refresh-Token im Local- oder Session-Storage. Ein Same-Origin-Gateway hält die API-Tokens serverseitig in der PHP-Sitzung und schützt sie zusätzlich mit AES-256-GCM. Der Browser erhält nur die Session-ID in einem Secure-, HttpOnly- und SameSite=Strict-Cookie; zustandsändernde Gateway-Anfragen verwenden zusätzlich CSRF-Schutz.
• Ein optionaler PWA-Geräteschutz kann WebAuthn/Plattform-Authenticators verwenden; biometrische Rohdaten verbleiben beim jeweiligen Plattform-Authenticator und werden nicht an Zeitkommando übertragen.

3. Übertragung, mobile Verschlüsselung und private Dateien

• Produktiver Zugriff ausschließlich über HTTPS; die Android-Anwendung deaktiviert Klartext-HTTP, die PWA ist ebenfalls für HTTPS und Same-Origin-Kommunikation ausgelegt.
• Sitzungscookies mit HttpOnly und SameSite; bei HTTPS zusätzlich Secure. Für die PWA wird SameSite=Strict verwendet.
• Offline-Arbeitsnachweise einschließlich EL- und Kundenunterschriften werden in der Android-Anwendung mit Android Keystore/AES-GCM verschlüsselt gespeichert. In der PWA werden entsprechende lokale Entwürfe in IndexedDB mit WebCrypto/AES-GCM mandanten- und benutzerbezogen verschlüsselt; der benutzerspezifische Schlüssel wird serverseitig abgeleitet und nur im Arbeitsspeicher des Browsers gehalten.
• Android und PWA bereinigen lokale Arbeitsnachweis-Kopien nach dem vorgesehenen 30-Tage-Zeitraum; synchronisierte Nachweise auf dem Server werden dadurch nicht gelöscht.
• Die PWA verwendet restriktive CSP-, Referrer- und Permissions-Policy-Vorgaben und bindet in der Standardauslieferung keine Werbe-/Analyse-Tracker, externen Webfonts oder externen JavaScript-CDNs ein.
• Mitarbeiter-Profilbilder und weitere private Dateien werden nicht über öffentliche Upload-Links ausgeliefert, sondern über authentifizierte bzw. berechtigungsgeprüfte Serverrouten.
• Private Wachbuch-Audioentwürfe liegen in einem nicht öffentlich erreichbaren Mandantenbereich und sind über die Anwendung nur für den jeweiligen Ersteller abrufbar.
• Physische Löschvorgänge privater Audioentwürfe verwenden eine mandantenbezogene Pfadvalidierung. Vorübergehende Löschfehler werden als Systemereignis protokolliert und in einer mandantenbezogenen Retry-Warteschlange zur automatischen Nachlöschung vorgemerkt.

3a. Signaturbindung bei Dienstanweisungen

• Unterschriften zu Dienstanweisungen werden nur innerhalb einer authentifizierten Sitzung mit gültiger Benutzeranmeldung und für eine dem angemeldeten Benutzer zugewiesene Anweisung angenommen.
• Die serverseitige Personalakten-Zuordnung verwendet den authentifizierten Benutzer und den Mandantenkontext; eine vom Client frei wählbare Ziel-Mitarbeiter-ID ist nicht Bestandteil dieses Pfads.
• Original- und unterschriebene PDF-Dateien werden im privaten Mandantenbereich gespeichert und durch Hashwerte, Zuweisungsstatus und Zeitpunkte nachvollziehbar verknüpft.
• Zugewiesene Original-PDFs werden authentifiziert bereitgestellt; signierte Fassungen werden nachvollziehbar mit Zuweisung, Benutzerkonto und digitaler Personalakte verknüpft.

3a. Native Push-Benachrichtigungen

• Firebase-Cloud-Messaging-Token der Android-Mitarbeiter-App werden serverseitig mit dem Application-Keyring verschlüsselt gespeichert; Klartexttoken werden nicht als normale Protokolldaten geführt.
• Eine FCM-Zustellung wird nur für registrierte Geräte mit aktiver, nicht widerrufener App-Sitzung versucht. Nach erfolgreicher Zustellung wird das Ereignis gerätebezogen markiert, damit der Polling-Fallback keine Doppelbenachrichtigung erzeugt.
• Beim Abmelden wird die serverseitige Push-Registrierung deaktiviert und die App veranlasst die Löschung ihres lokalen Firebase-Messaging-Tokens.

4. Schlüssel- und Geheimnisverwaltung

• Technische Geheimnisse wie Mandanten-Datenbankkennwörter und Zahlungsanbieter-Geheimnisse werden verschlüsselt gespeichert.
• Versionierter Application-Keyring mit aktivem Schlüsselkennzeichen; ein separates Betriebswerkzeug unterstützt kontrollierte Schlüsselrotation und verifizierte Neuverschlüsselung geschützter Werte.
• Lokale Konfigurationsdateien, Keystores, produktive Kundendaten und andere Secrets werden nicht in Release-/Updatepakete aufgenommen.
• Quell- und Releaseartefakte werden mit Prüfsummen sowie automatisierten Secret-/Release-Scans geprüft.

5. Protokollierung, Wachbuchrevision und Monitoring

• Änderungsprotokolle für sensible Geschäfts-, Personal- und Arbeitszeitvorgänge sowie datensparsame System- und Sicherheitsereignisse für Betriebsüberwachung und Fehleranalyse.
• Geheimnisse, Zugangstoken und vergleichbare sensible Werte werden aus vorgesehenen Ereignistexten herausgefiltert bzw. nicht in den vorgesehenen Kontext aufgenommen.
• Wachbuch-Einsatznotizen und Vorfallsberichte können nachträglich erst ab Einsatzleitung geändert werden; jede Änderung verlangt Änderungsgrund und neue Unterschrift und erzeugt einen eigenen Revisionsdatensatz mit Vorher-/Nachherstand, Bearbeiter und Zeitpunkt.
• Reguläre Wachbucheinträge können erst ab Managerrolle logisch gelöscht werden; die Löschung wird protokolliert. Private Audioentwürfe sind hiervon bewusst getrennt und können vom Ersteller ohne Wachbuch-Revisionsprotokoll gelöscht werden.
• Integritätsprüfungen/Prüfsummen für ausgewählte Arbeitszeit- und Vertragsnachweise sowie ein geschütztes Masterprotokoll unterstützen die Nachvollziehbarkeit.

6. Verfügbarkeit, Backup und Wiederherstellung

• Hosting- und Datenbanksicherungen im Rahmen der eingesetzten Infrastruktur.
• Mandantenbezogene Datenbanken erleichtern eine getrennte Wiederherstellung, soweit geeignete Sicherungsstände vorhanden sind.
• Dokumentierte Backup-/Restore-, Incident-Response- und Disaster-Recovery-Runbooks sowie ein Restore-Drill-Werkzeug.
• Updateverfahren mit Versionsständen und zentraler Prüfung der Firmendatenbanken.

7. Technische Qualitätssicherung

• Automatisierte PHP-Syntax- und Regressionstests.
• Mandanten-Isolationstests und Concurrency-/Parallelverarbeitungsprüfungen für kritische Datenpfade.
• Secret-/Release-Scanning, Release-Prüfsummen und Release-Verifikation vor der Paketfreigabe.
• Saubere Releasepakete ohne produktive Secrets, private Laufzeitdaten, Kundenuploads, Backups oder lokale Entwicklerkonfiguration.

8. Datenschutz durch Technikgestaltung und Auftragskontrolle

• Restriktive Standardberechtigungen und rollenbasierte Sichtbarkeit.
• Datenexport- und dokumentierte Lösch-/Prüffunktionen; keine automatisierte Massenlöschung sensibler Daten ohne Prüfung entgegenstehender Pflichten.
• Keine externen Marketing-Tracker in der Standard-Produktwebsite oder der ausgelieferten PWA; externe Webfonts und externe JavaScript-Runtimes sind für die PWA nicht erforderlich.
• Dokumentierte AVV, TOM und Unterauftragnehmerübersicht; weitere vom Anbieter ausgewählte Auftragsverarbeiter werden datenschutzrechtlich bewertet und vertraglich eingebunden, soweit erforderlich.

9. Überprüfung

Die Maßnahmen werden bei wesentlichen technischen Änderungen, Sicherheitsvorfällen, Dienstleisterwechseln und regelmäßig im Rahmen des Betriebs überprüft und bei Bedarf angepasst.