Technisch-organisatorische Maßnahmen

1. Vertraulichkeit (Art 32 Abs 1 lit b DSGVO)

1.1 Zutrittskontrolle

Der physische Zutritt zum Server wird durch den Hosting-Anbieter STRATO GmbH (Otto-Ostrowski-Straße 7, 10249 Berlin, Deutschland) im Rechenzentrum gesichert. HAVA:SOFT mietet einen virtuellen Server (VPS); die physische Zugangs­sicherung obliegt dem Hosting-Anbieter und ist im AVV geregelt. Die Verwaltung des Servers durch erfolgt ausschließlich remote über authentifizierte Verbindungen.

• Zutrittskontrolle zum Rechenzentrum durch den Hosting-Anbieter (PIN/Terminal, Ausweis, Videoüberwachung gemäß AVV-Anhang).
• Server-Verwaltung durch ausschließlich remote über authentifizierte SSH-Verbindungen; kein physischer Direktzugriff.
• SSH-Authentifizierung ausschließlich über Schlüssel (Public-Key); Passwort-Login deaktiviert.
• Administrative Zugänge nur für namentlich berechtigte Personen von .

Die Rechenzentrums-Zutrittskontrolle wird durch die AVV-Nachweise des Hosting-Anbieters dokumentiert; diese liegen vor und werden auf Anfrage der Aufsichtsbehörde nachgewiesen.

1.2 Zugangskontrolle

• Passwort-Hashing: PBKDF2-HMAC-SHA512 mit 600 000 Iterationen, pro Konto individuelles Salt.
• Passwort-Richtlinie: Mindestlänge 12 Zeichen, Komplexitäts­anforderungen, Sperrliste bekannter Schwach-Passwörter.
• Konto-Lockout: nach 5 fehlgeschlagenen Login-Versuchen Sperrung für 10 Minuten.
• Rate-Limiting: auf IP- und Konto-Ebene zur Abwehr automatisierter Versuche.
• Zwei-Faktor-Authentisierung: für alle Nutzer aktivierbar (TOTP, Authenticator-Apps); für administrative Rollen empfohlen.
• Session-Management: Authentifizierungs-Cookies mit Secure-/HttpOnly-/SameSite-Attributen; serverseitige Session-Invalidierung bei Passwort-Wechsel oder Rolle-Änderung über Security-Stamp.
• OAuth-Tokens: AES-256-verschlüsselt at-rest (ASP.NET DataProtection).

1.3 Zugriffskontrolle

• Cross-Tenant-Isolation auf Code-Pfad-Ebene: Jeder Datensatz trägt eine TenantId; sämtliche Datenbank-Queries laufen über EF-Core Global Query Filter, die die Tenant-Bedingung automatisch und nicht-umgehbar einsetzen. Ein Datensatz aus einem fremden Workspace ist programmatisch nicht abrufbar, selbst bei Implementierungs-Fehlern in einzelnen Endpunkten.
• Granulare Rollen und Berechtigungen pro Workspace: Owner / Admin / Mitglied / externer Beteiligter mit feinkörnigen Regeln pro Gruppe (Issues, Zeiten, Stammdaten); externe Beteiligte sehen ausschließlich die ausdrücklich freigegebenen Sichten.
• API-Zugriff: Per-Tenant API-Keys mit eigenen Scopes (read/write); Deaktivierung auf Knopfdruck führt zu sofortigem 403 bei jeder API-Anfrage.

1.4 Trennungskontrolle

• Logische Mandanten-Trennung über TenantId in jeder Tabelle und über Global Query Filter (siehe 1.3).
• Physische Trennung Produktions-, Test- und Entwicklungs-Umgebung über separate Hosts und Datenbanken.
• Keine Echt­daten in Test- oder Entwicklungs-Umgebungen.

2. Integrität (Art 32 Abs 1 lit b DSGVO)

2.1 Weitergabekontrolle

• Transport-Verschlüsselung: TLS 1.2+ erzwungen; HSTS mit includeSubDomains in Production.
• CSRF-Schutz: Antiforgery-Tokens für alle zustands­ändernden HTTP-Methoden; SameSite-Cookies.
• Keine Drittland-Übermittlung im Plattform-Betrieb: Inhalte ruhen ausschließlich auf dem Server bei STRATO GmbH in Deutschland (STRATO-Rechenzentrum, Berlin/Brandenburg) (siehe 3.1). Eine Übermittlung an externe KI-Endpunkte erfolgt nur dann, wenn der Workspace-Inhaber dies ausdrücklich konfiguriert, und nur nach lokaler Pseudonymisierung (siehe 5.2).
• Datenträger-Vernichtung erfolgt nach eigenen Prozessen von bei End-of-Life-Hardware (sicheres Löschen nach DIN 66399 bzw. physische Vernichtung).

2.2 Eingabekontrolle

• Audit-Log sicherheits­relevanter Ereignisse: Jeder Login, jede Berechtigungs­änderung, jeder Daten-Export und jede Konto­löschung wird mit Tenant-, Nutzer- und Zeitstempel persistiert. Aufbewahrung 12 Monate, anschließend automatisches Pruning.
• Historie auf Geschäftsobjekten: Änderungen an Tickets, Berechtigungen und Sprint-Konfiguration werden mit Nutzer und Zeitstempel versioniert.
• Server-Logs: IP, Zeitstempel, Pfad, User-Agent für 14 Tage zur Aufklärung von Sicherheits­vorfällen.

3. Verfügbarkeit und Belastbarkeit (Art 32 Abs 1 lit b DSGVO)

3.1 Hosting und Standort

Plattform-Betrieb auf einem virtuellen Server (VPS) von STRATO GmbH (Otto-Ostrowski-Straße 7, 10249 Berlin, Deutschland, Deutschland (STRATO-Rechenzentrum, Berlin/Brandenburg)). STRATO GmbH ist Auftragsverarbeiter im Sinne des Art 28 DSGVO; ein schriftlicher AVV ist geschlossen. Die Rechenzentrums-Infrastruktur (Stromausfall, Brand­schutz, Kühlung, Anbindung) wird vom Hosting-Anbieter bereitgestellt und im AVV-Anhang beschrieben. Eine Drittland-Übermittlung findet nicht statt.

3.2 Backup

• Tägliche verschlüsselte Datenbank-Backups als Hangfire-Hintergrund-Job.
• 14-Tage-Rotation; ältere Backups werden automatisch überschrieben.
• Backup-Volume ist räumlich vom Anwendungs-Container getrennt verwaltet.
• Geprüfter Restore-Pfad — Wiederherstellung wurde mindestens einmal pro Halbjahr getestet.

3.3 Wiederherstellbarkeit

• Dokumentierte Restore-Prozedur für vollständige und punktuelle Wiederherstellung.
• Point-in-Time-Recovery auf Tagesebene innerhalb der Rotations­frist.
• Notfall-Kontakt: .

3.4 Belastbarkeit

• Health-Checks für Anwendung, Datenbank und Hintergrund-Jobs.
• Automatischer Neustart fehlgeschlagener Services durch den Container-Orchestrator.
• Rate-Limiting und Konto-Lockout zur Abwehr von Denial-of-Service auf Login-Endpunkten.

4. Verfahren zur regelmäßigen Überprüfung (Art 32 Abs 1 lit d DSGVO)

• Build- und Test-Pipelines mit automatisierten Unit- und Integrations­tests vor jedem Release-Deployment.
• Regelmäßige Aktualisierung der eingesetzten Frameworks und Bibliotheken (.NET, EF Core, ASP.NET Identity) zur Schließung sicherheits­relevanter Lücken.
• Periodische Überprüfung der Berechtigungs­vergaben.
• Periodische Überprüfung der Auftragsverarbeiter und ihrer Sicherheits­zusagen.
• Pflichten- und Vorfall-Reviews nach jedem Sicherheits­vorfall, einschließlich Anpassung dieser Maßnahmen.

5. Pseudonymisierung und Verschlüsselung (Art 32 Abs 1 lit a DSGVO)

5.1 Verschlüsselung at-rest

• AES-256 via ASP.NET DataProtection für sensible Felder — externe API-Keys, OAuth-Refresh-Tokens.
• Persistentes Schlüssel­material — DataProtection-Keys überleben Container-Restarts; Migration bei Schlüssel­rotation ohne Datenverlust.
• Datenbank-Backups verschlüsselt im Backup-Volume.

5.2 Pseudonymisierung vor externer KI

Wenn ein Workspace-Inhaber einen externen KI-Endpunkt aktiviert, läuft jede Outbound-Anfrage durch einen lokalen Anonymisierer:

• NER-Modell (ONNX) zur Erkennung von Personen-, Orts- und Organisations­namen.
• Regex-Erkennung für E-Mail, IBAN, Telefonnummer, Postleitzahl, Straße.
• Ersetzung durch Token-Platzhalter; die Zuordnung von Token zu Klartext wird ausschließlich in der Sitzung des Aufrufers gehalten und nicht persistiert.
• Rück­übersetzung der Antworten in den Klartext erfolgt erst auf dem Server, vor Anzeige in der Anwendung.
• Der externe Endpunkt sieht den Klartext der personen­bezogenen Bezeichner nie.

6. Auftragskontrolle (Art 28 DSGVO)

• Schriftliche Weisungs­dokumentation per E-Mail an .
• Auftragsverarbeitungs-Verträge mit allen eingesetzten Unterauftragnehmern (siehe /subprocessors).
• Vertraulichkeits­verpflichtung aller mit der Verarbeitung befassten Personen — auch über das Ende des Beschäftigungs­verhältnisses hinaus.
• Regelmäßige Kontrolle der Unterauftragnehmer.

7. Organisation und Mitarbeitende

• Schriftliche Vertraulichkeits­verpflichtung aller mit der Verarbeitung befassten Personen vor Tätigkeits­aufnahme.
• Datenschutz-Sensibilisierung als Bestandteil der Einarbeitung.
• Need-to-know-Prinzip: Zugriffe auf Produktions­systeme nur, soweit für die jeweilige Tätigkeit erforderlich.
• Trennung von Entwicklung, Betrieb und administrativem Zugriff über getrennte Konten und Schlüssel.

Version 1.2 · Stand: 2026-07-19 · Kontakt: