DiveLogix360 – Technische und organisatorische Massnahmen¶
Stand: 09.08.2026 12:55 Branch: main Status: In Bearbeitung
| Datum, Uhrzeit | Version | Änderung | Autor |
|---|---|---|---|
| 09.08.2026 12:55 | 1.6 | TOM-Katalog um fünf Schutzbereiche und verbindliches Wirksamkeitsnachweismodell vervollständigt | Codex |
| 09.08.2026 12:49 | 1.5 | Zeitbegrenzte Infrastruktur-, Tenant-, Notfall- und Providerzugriffe nach ADR-023 ergänzt | Codex |
| 09.08.2026 12:34 | 1.4 | Eigenbetriebenen ClamAV-Scanservice, Ausfallsperre und Signaturüberwachung nach ADR-022 ergänzt | Codex |
| 09.08.2026 12:17 | 1.3 | Grafana-Cloud-Monitoring mit Datenminimierung, Mindestabdeckung und Kostenkontrollen nach ADR-021 ergänzt | Codex |
| 09.08.2026 11:52 | 1.2 | Risikobasierte Wiederherstellungsziele, Falkenstein-Backup und dauerhafte Vertragsabschlussregel nach ADR-020 ergänzt | Codex |
| 08.08.2026 11:57 | 1.1 | Zentrale Fristenmatrix und kontrollierte Löschläufe als verbindlichen Nachweis für Speicherbegrenzung verknüpft | Codex |
| 08.08.2026 11:44 | 1.0 | Zentrale Massnahmenübersicht mit V1-Sicherheitsniveau, Zuständigkeiten, Nachweisen und Prüfintervallen erstellt | Codex |
Zweck: Zentrales Register der technischen und organisatorischen Massnahmen (TOM) für DiveLogix360. Es macht Anforderungen, Umsetzungsstand und Prüfnachweise nachvollziehbar, ersetzt aber weder die konkrete Systemkonfiguration noch deren Prüfung.
Geltungsbereich: Produktive Plattform, Datenbank, Objektspeicher, E-Mail-Versand, Backups, Monitoring sowie Entwicklungs-, Test- und Demo-Umgebungen.
V1-Bezug: Die verbindlichen UC00-Regeln stehen im UC00-Datenkatalog.
1. Status- und Nachweisregeln¶
Zulässige Statuswerte sind Geplant, In Bearbeitung, Umgesetzt, Geprüft, Blockiert und Nicht anwendbar.
| Status | Verbindliche Bedeutung |
|---|---|
Geplant |
Sollregel, Verantwortlichkeit und vorgesehene Prüfmethode sind festgelegt; die Umsetzung hat noch nicht begonnen. |
In Bearbeitung |
Umsetzung oder Nachweisaufbau läuft, ist aber noch nicht vollständig. |
Umgesetzt |
Die technische Konfiguration oder der organisatorische Prozess ist vorhanden und durch einen konkreten Nachweis belegt. |
Geprüft |
Zusätzlich wurde die tatsächliche Wirksamkeit mit dokumentiertem Ergebnis geprüft. |
Blockiert |
Umsetzung oder Prüfung kann wegen einer benannten Abhängigkeit nicht fortgesetzt werden. |
Nicht anwendbar |
Eine begründete und freigegebene Prüfung hat ergeben, dass die Massnahme im bezeichneten Geltungsbereich nicht anwendbar ist. |
Fehlende Nachweise werden nicht durch eine Selbsteinschätzung ersetzt. Eine fachlich vollständige Sollregel darf deshalb weiterhin Geplant oder In Bearbeitung sein.
2. Massnahmenregister¶
| ID | Schutzziel und verbindliche Regel | Verantwortlich | Status | Erforderlicher Nachweis | Prüfung |
|---|---|---|---|---|---|
| TOM-01 | Zugriff wird standardmässig verweigert und serverseitig nach Rolle, Tenant und Ressource freigegeben; Row-Level Security (RLS, zeilenbasierte Zugriffskontrolle) ergänzt die Anwendungskontrolle. | Entwicklung/Security | In Bearbeitung | Berechtigungsmatrix, RLS-Regeln, Isolationstests | Je Release; quartalsweise Rechteprüfung |
| TOM-02 | Administrative Zugriffe verwenden persönliche Konten, Zwei-Faktor-Authentifizierung (2FA), Minimalrechte und einen dokumentierten Zweck. Infrastrukturrechte gelten höchstens vier Stunden; normale tenantbezogene Supportrechte benötigen eine Tenant-Freigabe und gelten höchstens acht Stunden. | Operations/Security | In Bearbeitung | ADR-023, Kontenliste, 2FA-, Freigabe- und Access-Protokolle | Quartalsweise und je Zugriff |
| TOM-03 | Eintritt, Rollenwechsel und Austritt lösen einen dokumentierten Rechteprozess aus; Rechte werden bei Wegfall sofort entzogen. Ein alarmierter Notfallzugriff gilt höchstens eine Stunde, wird möglichst im Vier-Augen-Prinzip aktiviert und spätestens am nächsten Arbeitstag geprüft. | Operations | Geplant | ADR-023, Prozess, Tickets, Notfallzugriffsprotokoll | Quartalsweise und nach Ereignis |
| TOM-04 | Authentifizierung und Sitzungen verwenden 2FA für Superadmin und Tenant-Admin, sichere Cookies, Tokenrotation, Sitzungswiderruf sowie aktive allgemeine und verschärfte Auth-Ratenbegrenzung. | Entwicklung/Security | In Bearbeitung | Konfiguration, Guard-Nachweis, Auth- und Missbrauchstests | Je Release |
| TOM-05 | Cookie-basierte zustandsändernde Endpunkte prüfen Herkunft und Schutz gegen Cross-Site Request Forgery (CSRF); CORS verwendet eine exakte Freigabeliste. | Entwicklung | Geplant | CORS-/CSRF-Konfiguration und Negativtests | Je Release |
| TOM-06 | Externe und interne Transportwege verwenden Transport Layer Security (TLS) 1.2 oder höher, bevorzugt TLS 1.3; HTTP Strict Transport Security (HSTS) ist aktiv. | Operations | Geplant | TLS-Scan, Konfiguration, Zertifikatsmonitoring | Monatlich und nach Änderung |
| TOM-07 | Datenbank, private Objekte und Backups sind im Ruhezustand verschlüsselt; TOTP-Geheimnisse sind feldverschlüsselt, Schlüssel liegen ausserhalb der SQL-Datenbank. | Operations/Security | Geplant | Anbieter-/Speicherkonfiguration, Schlüsselkonzept | Quartalsweise |
| TOM-08 | Produktive Geheimnisse und Schlüssel werden zentral, umgebungsgetrennt und mit Minimalrechten verwaltet, rotiert und widerrufen; JWT-Schlüsselwechsel unterstützt eine Übergangsphase über eine Schlüssel-ID. | Operations/Security | Geplant | Secret-Inventar, Berechtigungen, Rotationsprotokoll | Quartalsweise |
| TOM-09 | Datenbank und interne Dienste sind nicht öffentlich erreichbar; Firewall, private Netze, minimale Ports, persönliche SSH-Schlüssel, Patchmanagement und nicht privilegierte Prozesse begrenzen die Angriffsfläche. | Operations | Geplant | Infrastrukturcode, Firewall- und Patchnachweis | Monatlich und nach Änderung |
| TOM-10 | Eingaben verwenden konkrete Datenübertragungsobjekte statt any, Feld- und Längenprüfungen sowie parametrisierte Datenbankzugriffe; Fehlerausgaben sind bereinigt. |
Entwicklung | In Bearbeitung | Codeanalyse, API-Negativtests | Je Release |
| TOM-11 | Sicherheitsheader, Frontend-Content-Security-Policy, no-store für sensible Antworten sowie freigegebene Weiterleitungs- und Linkziele sind verbindlich. Debug- und API-Dokumentationsflächen sind produktiv deaktiviert oder geschützt. |
Entwicklung/Operations | In Bearbeitung | Header-Scan, Konfiguration, Tests | Je Release |
| TOM-12 | Vertragsuploads erlauben ausschliesslich PDF bis 10 MB. Dateiendung, MIME-Typ, Magic Bytes und Struktur müssen übereinstimmen; verschlüsselte PDFs, JavaScript, Startaktionen und eingebettete Dateien werden abgewiesen. Signierte Dokumente werden nicht bereinigt oder neu geschrieben. | Entwicklung/Security | Geplant | Upload-Konfiguration und Positiv-/Negativtests | Je Release |
| TOM-13 | Uploads bleiben bis zum erfolgreichen Scan durch einen eigenbetriebenen, gehärteten und ressourcenbegrenzten ClamAV-Dienst in verschlüsselter Quarantäne. Scanner- oder Signaturfehler sperren die Freigabe; Signaturen werden stündlich aktualisiert und dürfen bei Freigabe höchstens zwei Stunden alt sein. Externe Malware-Dienste erhalten keine Vertragsdateien. | Entwicklung/Operations | Geplant | ADR-022, Container-, Netzwerk-, Objekt-, Update- und Scan-Konfiguration sowie Ausfalltests | Laufend überwachen; je Release prüfen |
| TOM-14 | Authentifizierungs-, Audit-, Zugriffs-, System-, Lösch- und Versandprotokolle sind minimiert, geheimnisfrei, zugriffsgeschützt und manipulationsüberwacht; sensible Zugriffe werden selbst protokolliert. | Entwicklung/Security | In Bearbeitung | Logschema, Filtertests, Access-Protokolle | Monatlich und je Release |
| TOM-15 | Verschlüsselte automatische Backups und PostgreSQL Point-in-Time Recovery (PITR, Wiederherstellung auf einen bestimmten Zeitpunkt) erreichen die risikobasierten internen V1-Obergrenzen RPO ≤ 1 Stunde und RTO ≤ 8 Stunden; Sicherungen liegen getrennt vom Nürnberger Produktivspeicher in Falkenstein. | Operations | Geplant | ADR-020, Backupkonfiguration, Regionen, Wiederherstellungsprotokoll | Backup täglich überwachen |
| TOM-16 | Backups werden monatlich technisch geprüft, quartalsweise testweise wiederhergestellt und jährlich in einer vollständigen Notfallwiederherstellung erprobt. | Operations | Geplant | Prüf- und Restoreprotokolle mit gemessenem RPO/RTO | Monatlich, quartalsweise, jährlich |
| TOM-17 | Grafana Cloud Pro Frankfurt alarmiert minimiert unter anderem Verfügbarkeit, Datenbank, Fehler, Speicher, Backups, Restore, Zertifikate, E-Mail, Malware-Scan, Auth-Missbrauch, Logausfall, administrative Zugriffe, Schlüsselrotation und abgewiesene Uploads; jeder Alarm besitzt Empfänger und Reaktionsregel. | Operations/Security | Geplant | ADR-021, Alarmmatrix, Testalarme, Rufbereitschaft | Monatlich |
| TOM-18 | Abhängigkeiten, Anwendungscode und Geheimnisse werden automatisiert geprüft; Software Bill of Materials (SBOM, Software-Stückliste), Lockfiles und reproduzierbare Builds sind vorhanden. Kritische Schwachstellen blockieren Produktion. | Entwicklung/Security | Geplant | Scanberichte, SBOM, Patchfristen | Je Build; monatliche Auswertung |
| TOM-19 | OWASP ASVS Level 2 dient als Prüfbasis. Vor Produktivstart, nach wesentlichen Sicherheitsänderungen und danach jährlich erfolgt ein unabhängiger Penetrationstest. | Security | Geplant | ASVS-Prüfliste, Penetrationstestbericht | Vor Go-live, nach Änderung, jährlich |
| TOM-20 | Ein Incident-Response-Prozess regelt Kontakte, Eindämmung, Beweissicherung, Betroffenheitsanalyse, Geheimnisrotation, Information, rechtliche Meldeprüfung, Register und Ursachenanalyse. | Security/Compliance | Geplant | Notfallplan, Incident-Register, Übungsprotokoll | Jährliche Übung; nach Vorfall |
| TOM-21 | Provider, Unterauftragnehmer, Support- und Fernzugriffe werden vor Einsatz und bei Änderung geprüft. Menschlicher Produktivzugriff ist in V1 auf Schweiz, EU und EWR begrenzt; andere Länder benötigen vorab eine Transferprüfung und eigene Freigabe. Einsatzende umfasst Rechteentzug, Rückgabe und Löschbestätigung. | Compliance/Operations | In Bearbeitung | ADR-023, Providerregister, Support-Audits | Jährlich und bei Änderung |
| TOM-22 | Entwicklungs-, Test- und Demo-Umgebungen sind von Produktion getrennt und enthalten keine Produktivkopien, echten Vertragsdokumente oder produktiven Geheimnisse; notwendige produktionsnahe Daten sind irreversibel anonymisiert. | Entwicklung/Operations | In Bearbeitung | Umgebungs- und Datenprüfung | Quartalsweise |
| TOM-23 | Mitarbeitende sind zur Vertraulichkeit verpflichtet und werden jährlich zu Sicherheit und Datenschutz geschult; Endgeräte verwenden Verschlüsselung, Sperre und Schutzsoftware. | Management/Compliance | Geplant | Verpflichtungen, Schulungs- und Gerätebelege | Jährlich |
| TOM-24 | Lokale Vertragskopien sind ohne Arbeitsbedarf untersagt und nach Nutzung zu löschen; Löschung, Sperrung und Aufbewahrung werden nach der Fristenmatrix automatisiert. | Compliance/Operations | In Bearbeitung | Löschkonzept, Stichprobe, technische Jobs | Monatlich; Provider und Backups quartalsweise |
| TOM-25 | Änderungen werden geprüft und versioniert. Kritische Änderungen erhalten nach Möglichkeit eine zweite Prüfung; bei Einzelbesetzung wird die Ausnahme mit Grund, Testnachweis und nachträglicher Kontrolle dokumentiert. | Entwicklung/Operations | In Bearbeitung | Pull Requests, Change-Tickets, Ausnahmen | Je Änderung |
| TOM-26 | Ein bestätigter Vertragsabschluss wird erst nach dauerhafter konsistenter Speicherung von Vertragsdatensatz, PDF-Objekt und Auditnachweis gemeldet; Teilausfälle werden idempotent wiederholt, kompensiert und alarmiert. | Backend/Operations | Geplant | ADR-020, Integrations- und Ausfalltests | Je Release und quartalsweise |
| TOM-27 | Monitoringmetriken verwenden keine personenbezogenen oder fachlichen IDs als Labels; Logs enthalten keine Formulareingaben, Bodies, Vertrags- oder Nachrichteninhalte, Geheimnisse oder ungefilterte Providertexte. | Entwicklung/Security | Geplant | ADR-021, Label-Positivliste, Logfilter- und Negativtests | Je Release; monatlich |
| TOM-28 | Messintervalle, Metrikkardinalität, Logvolumen, Benutzer, synthetische Prüfungen und Kosten werden begrenzt und monatlich geprüft; Warnungen erfolgen spätestens bei 70 und kritisch bei 85 Prozent eines Tarifkontingents. | Operations | Geplant | ADR-021, Nutzungsdashboard, Kostenalarme und Monatsprüfung | Laufend; monatlich |
| TOM-29 | Physischer Zutritt, Stromversorgung, Brand-, Wasser-, Klima-, Hardware- und Datenträgerschutz der Rechenzentren werden über geeignete Provider-, Zertifizierungs- oder Auditnachweise geprüft; DiveLogix360 betreibt keinen eigenen produktiven Serverraum. | Compliance/Operations | Geplant | Provider-TOM, Zertifikate, Audit- oder Prüfberichte mit Geltungsbereich | Vor Produktivfreigabe; jährlich |
| TOM-30 | Kapazitätsgrenzen, Ratenbegrenzung, Netzwerkfilter, Überlastungs- und Distributed-Denial-of-Service-Schutz (DDoS-Schutz) erhalten die erforderliche Verfügbarkeit; Angriffe und Grenzwertüberschreitungen werden alarmiert und nachbearbeitet. | Operations/Security | Geplant | Last- und Überlastungstest, Providerkonfiguration, Alarm- und Vorfallnachweis | Vor Produktivstart; je wesentlicher Änderung; jährlich |
| TOM-31 | Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen begrenzt Pflichtfelder, Sichtbarkeit, Protokollierung, Berechtigungen und Speicherfristen auf das erforderliche Mass; neue Funktionen durchlaufen vor Freigabe eine Datenschutz- und Sicherheitsprüfung. | Entwicklung/Compliance | In Bearbeitung | Datenkatalog, Designprüfung, Standardwert- und Negativtests | Je fachlicher oder technischer Änderung |
| TOM-32 | Auskunft, Berichtigung, Export, Einschränkung und Löschung betroffener Daten erfolgen über einen identitätsgeprüften, fristüberwachten und auditierten Prozess; Exporte sind verschlüsselt, zeitlich begrenzt und auf den zulässigen Umfang beschränkt. | Compliance/Entwicklung | Geplant | Verfahrensanweisung, Fallregister, Frist-, Berechtigungs-, Export- und Löschtests | Jährlich und je Fallstichprobe |
| TOM-33 | Datenträger, Instanzen, Volumes, Objekte, Sicherungen und Providerressourcen werden bei Austausch oder Einsatzende nach dokumentierten Verfahren sicher gelöscht, kryptografisch unzugänglich gemacht oder durch den Provider nachweislich vernichtet; Berechtigungen und Schlüssel werden entzogen. | Operations/Compliance | Geplant | Löschprotokoll, Providerbestätigung, Schlüssel- und Ressourceninventar, Stichprobe | Bei Einsatzende; quartalsweise Stichprobe |
3. Verbindliches Nachweismodell¶
Für jede produktionsrelevante Massnahme wird ein versionierter Nachweisdatensatz geführt. Die TOM-Übersicht bleibt die führende Soll- und Statusübersicht; umfangreiche Prüfberichte, Konfigurationsauszüge und Belege werden geschützt ausserhalb des öffentlich lesbaren Dokumentationsbereichs abgelegt und über eine nicht vertrauliche Nachweisreferenz verknüpft.
| Pflichtangabe | Inhalt |
|---|---|
| TOM-ID | Eindeutige Zuordnung zur Massnahme |
| Geltungsbereich | Umgebung, System, Dienst, Provider oder Prozess |
| Verantwortliche Funktion | Für Umsetzung und Behebung zuständige Funktion |
| Nachweisreferenz | Eindeutige Referenz auf Konfiguration, Bericht, Ticket oder Providerbeleg |
| Prüfdatum | Datum und Uhrzeit der tatsächlich ausgeführten Prüfung |
| Prüfende Person | Persönlich zuordenbare prüfende Person |
| Prüfmethode | Konfigurationsprüfung, Test, Wiederherstellung, Stichprobe, Audit oder Übung |
| Ergebnis | Bestanden, teilweise bestanden oder nicht bestanden mit kurzer Begründung |
| Abweichung | Offener Befund, Risiko und gegebenenfalls vorübergehende Ersatzmassnahme |
| Verantwortlicher und Zieltermin | Zuständigkeit und verbindlicher Behebungstermin |
| Nächste Prüfung | Risikobasierter oder in der TOM festgelegter Folgetermin |
Ein Nachweis gilt nur, wenn Geltungsbereich, Prüfmethode und Ergebnis nachvollziehbar sind. Geheimnisse, personenbezogene Produktivdaten und vollständige sicherheitskritische Konfigurationen werden nicht in das Repository übernommen.
UC00-07-10 ist erst Erledigt, wenn alle für den Produktivbetrieb anwendbaren Massnahmen mindestens Umgesetzt, ihre vorgeschriebenen Wirksamkeitsprüfungen bestanden und alle kritischen Abweichungen behoben sind. Eine fachlich vollständige TOM-Übersicht allein erfüllt dieses Prüfgate nicht.
4. Verbindliche Wiederherstellungsziele¶
| Kennzahl | V1-Ziel | Nachweis |
|---|---|---|
| Recovery Point Objective (RPO, maximal tolerierter Datenverlust) | Höchstens 1 Stunde | Gemessener Datenstand bei quartalsweiser Wiederherstellung |
| Recovery Time Objective (RTO, maximale Wiederherstellungszeit) | Höchstens 8 Stunden | Zeitstempel vom Wiederherstellungsstart bis zur geprüften Betriebsbereitschaft |
RPO und RTO sind risikobasierte interne V1-Obergrenzen und keine gesetzlich festgelegten Zahlen. Für bestätigte Vertragsabschlüsse gilt zusätzlich kein bewusst akzeptierter Verlust nach der Erfolgsbestätigung.
5. Review und Pflege¶
Die Gesamtübersicht wird mindestens jährlich sowie nach wesentlichen Architektur-, Provider-, Rechts- oder Sicherheitsänderungen überprüft. Massnahmen ohne aktuellen Nachweis dürfen nicht den Status Geprüft tragen. Überfällige Nachweise und Abweichungen werden im Projektstatus nachgeführt. Ein obligatorisches Vier-Augen-Prinzip für jede V1-Änderung besteht nicht; kritische Änderungen werden jedoch nach Möglichkeit gegengeprüft und Ausnahmen nachvollziehbar dokumentiert.