Informationssicherheitsrichtlinie

Diese Informationssicherheitsrichtlinie beschreibt die Zertifizierungen, die Didit besitzt, die technischen und organisatorischen Kontrollen, die Didit betreibt, und die Vertrauensartefakte, die Kunden, potenziellen Kunden, Aufsichtsbehörden und Auditoren zur Verfügung stehen. Sie wird mindestens alle sechs Monate überprüft.

• Sicherheitskontakt: security@didit.me
• Datenschutzbeauftragter: dpo@didit.me
• Statusseite (Echtzeit): status.didit.me
• Trust Pack (unter NDA): E-Mail an security@didit.me

1. Zertifizierungen und Bestätigungen

Um die zugrunde liegenden Berichte oder Zertifikate anzufordern, sende eine E-Mail an security@didit.me. Berichte, die unter den Bedingungen ihres Ausstellers eingeschränkt sind (z. B. SOC 2 Typ 1), werden nach Unterzeichnung einer Geheimhaltungsvereinbarung (NDA) am selben Werktag geteilt.

2. Geltungsbereich

Diese Richtlinie deckt alle Didit-Mitarbeiter (Angestellte, Auftragnehmer und autorisierte Dritte), alle Didit-Produktions- und Unternehmensinformationssysteme sowie die kundenorientierten Dienste ab, die in den Geschäftsbedingungen beschrieben sind. Sie wird durch die Anwendbarkeitserklärung unterstützt, die Didits ISO/IEC 27001:2022 Managementsystem verankert.

3. Governance

• Informationssicherheits- und Datenschutz-Managementsystem ausgerichtet an ISO/IEC 27001:2022 und ISO/IEC 27701 Kontrollen, mit einer dokumentierten Anwendbarkeitserklärung.
• Der Chief Technology Officer ist der benannte Executive Sponsor für Informationssicherheit; der Datenschutzbeauftragte (dpo@didit.me) ist für die Governance des Datenschutzprogramms verantwortlich.
• Jährliches externes Sicherheitsaudit durch unabhängige Auditoren (ISO 27001 Überwachung und SOC 2 Prüfungen).
• Risikoregister wird vierteljährlich überprüft und aktualisiert. Wesentliche Risiken werden an den Managementausschuss eskaliert.
• Kontinuierliche Verbesserung, jeder Vorfall, Auditbefund und jede Risikobewertung fließt in den Korrekturmaßnahmen-Backlog und die nächste Richtlinienaktualisierung ein.

4. Verschlüsselung und Schlüsselverwaltung

• Im Ruhezustand: AES-256 über jede Produktionsdatenbank, Objektspeicher und jedes Backup-Volume.
• Während der Übertragung: TLS 1.3 für jeden externen API-Aufruf, Webhook und jede Business Console-Sitzung. Ältere TLS-Versionen und schwache Chiffren sind deaktiviert. HTTP Strict Transport Security (HSTS) wird websiteweit erzwungen und vorgeladen.
• Schlüsselverwaltung: AWS Key Management Service (KMS) verwaltet und rotiert die Schlüssel. Anwendungscode berührt niemals rohes Schlüsselmaterial. Sandbox- und Produktionsschlüssel sind vollständig getrennt.
• Hashing: Kundenanmeldeinformationen werden mit branchenüblichen adaptiven Funktionen (bcrypt oder gleichwertig) gehasht. API-Schlüssel werden als Einweg-Hashes gespeichert; der Rohwert wird dem Operator nur zum Zeitpunkt der Erstellung angezeigt.

5. Identität, Zugriff und Zero-Trust-Architektur

• Standardmäßig Zero-Trust, jede Anfrage an jedes interne System wird authentifiziert und autorisiert. Es gibt kein implizites Vertrauen basierend auf dem Netzwerkstandort.
• Rollenbasierte Zugriffssteuerung (RBAC) mit dem Prinzip der geringsten Rechte. Zugriffsüberprüfungen werden vierteljährlich durchgeführt.
• Multi-Faktor-Authentifizierung (MFA) ist für jeden Mitarbeiter, jedes Produktionssystem, jede Cloud-Konsole und jedes Code-Hosting-Konto obligatorisch.
• Single Sign-On (SSO) für interne Anwendungen, mit Hardware-Token-MFA für privilegierte Rollen.
• Just-in-Time-Zugriff für die Produktion: Stehender privilegierter Zugriff ist die Ausnahme, nicht die Regel.
• Audit-Protokollierung, jede privilegierte Aktion wird in einer manipulationssicheren, einmalig beschreibbaren Audit-Pipeline protokolliert, die mindestens 12 Monate aufbewahrt wird.

6. Datenresidenz und -trennung

• Standardmäßig Europäische Union. Produktionsdaten werden in der Europäischen Union auf Amazon Web Services verarbeitet und gespeichert. Spezifische Regionen oder länderspezifische Residenz sind für Enterprise-Verträge verfügbar, vorbehaltlich der Verfügbarkeit, für Gerichtsbarkeiten, deren Aufsichtsbehörden dies verlangen.
• Umgebungstrennung. Sandbox, Staging und Produktion sind auf Netzwerk-, Identitäts- und Schlüsselverwaltungsebene isoliert. Kein Mensch oder Dienst in einer Umgebung kann Daten in einer anderen lesen, ohne einen expliziten, auditierten Zugriffspfad.
• Mandantentrennung. Multi-Tenant-Daten werden logisch mit mandantenbezogenen Verschlüsselungsschlüsseln getrennt, wo zutreffend. Mandantenübergreifende Abfragen werden auf Anwendungs- und Datenbankebene blockiert.

7. Sicherer Entwicklungslebenszyklus (SDLC)

• Code-Review ist für jede Produktionsänderung erforderlich. Kein einzelner Ingenieur kann unüberprüften Code in die Produktion mergen.
• Statische Anwendungssicherheitsprüfung (SAST), Abhängigkeitsscanning und Software Composition Analysis (SCA) laufen automatisch bei jedem Pull Request.
• Container- und Infrastruktur-Scanning bei jedem Build und nach einem wiederkehrenden Zeitplan für bereitgestellte Images.
• Pre-Production-Sicherheitstests für hochwirksame Änderungen (Authentifizierung, Schlüsselverwaltung, biometrische Pipelines, Zahlungsabläufe).
• Interne Penetrationstests kontinuierlich; externe Penetrationstests mindestens einmal pro Jahr durch unabhängige Spezialisten. Wesentliche Befunde werden bis zur Behebung nach einem SLA-gebundenen Zeitplan verfolgt.
• Bug-Bounty / Responsible-Disclosure-Kanal, Sicherheitsprobleme an security@didit.me melden.

8. Schwachstellenmanagement

• Patching-SLA nach Schweregrad, kritisch (innerhalb von 72 Stunden nach Offenlegung durch den Anbieter), hoch (innerhalb von 7 Tagen), mittel (innerhalb von 30 Tagen), niedrig (innerhalb von 90 Tagen).
• Kontinuierliches Schwachstellenscanning über die gesamte Produktionsinfrastruktur, Container und Abhängigkeiten.
• Bedrohungsmodellierung für neue Produktoberflächen, biometrische Pipelines und umgebungsübergreifende Integrationen.

9. Überwachung, Erkennung und Incident Response

• 24x7-Überwachung jedes Produktionssystems mit Alarmierung bei Verfügbarkeits-, Fehler- und Sicherheitssignalen.
• Security Information and Event Management (SIEM) aggregiert und korreliert Sicherheitsereignisse; anormale Muster werden an Bereitschafts-Sicherheitsingenieure eskaliert.
• Dokumentierter Incident Response Plan mit benannten Rollen, Kommunikationsbaum, Schweregradmatrix und Post-Incident-Review-Prozess. Der Plan wird mindestens jährlich durch Tabletop-Übungen getestet.
• Benachrichtigung über Verletzungen personenbezogener Daten. Didit benachrichtigt betroffene Kunden unverzüglich und in jedem Fall rechtzeitig, damit Kunden ihre eigene 72-Stunden-Meldepflicht gemäß Artikel 33 der Datenschutz-Grundverordnung (DSGVO) erfüllen können. Enterprise-Kunden erhalten einen namentlich benannten Ingenieur im Bereitschaftsdienst und einen dedizierten Kommunikationskanal.
• Öffentliche Statusseite unter status.didit.me, jeder Produktionsvorfall, jede Post-Mortem-Analyse, kein Login erforderlich.

10. Geschäftskontinuität und Notfallwiederherstellung

• Multi-AZ aktive Redundanz in jeder Produktionsregion; automatisches Failover für zustandslose Dienste.
• Backups sind verschlüsselt, geografisch innerhalb der gewählten Residenzgrenze getrennt und nach einem wiederkehrenden Zeitplan getestet.
• Recovery Point Objective (RPO) ≤ 1 Stunde und Recovery Time Objective (RTO) ≤ 4 Stunden für die Kern-Verifizierungs-API und die Business Console.
• Disaster Recovery (DR)-Tests mindestens jährlich.

11. Personalsicherheit

• Hintergrundüberprüfungen für jeden Mitarbeiter und jeden Auftragnehmer mit Zugang zu Produktionsdaten oder personenbezogenen Daten, wo dies nach geltendem Recht zulässig ist.
• Vertraulichkeitsvereinbarungen bei Einstellung für jeden Mitarbeiter und Auftragnehmer.
• Obligatorische Sicherheits- und Datenschutzschulungen bei der Einarbeitung und mindestens jährlich für jeden Mitarbeiter. Gezielte Schulungen (sichere Codierung, Umgang mit biometrischen Daten, Betrugsbekämpfung, Geldwäschebekämpfung) für die Rollen, die sie benötigen.
• Phishing-Simulationen nach einem wiederkehrenden Zeitplan.
• Joiner / Mover / Leaver-Prozess widerruft den Zugriff innerhalb von 24 Stunden nach Rollenwechsel oder Ausscheiden.

12. Anbieter- und Unterauftragsverarbeiter-Management

• Jeder Unterauftragsverarbeiter wird vor der Aufnahme einer Risikobewertung unterzogen und mindestens jährlich erneut überprüft.
• Jeder Unterauftragsverarbeiter unterzeichnet einen Datenverarbeitungsvertrag (DPA), der Datenschutzpflichten auferlegt, die im Wesentlichen denen ähneln, die Didit seinen eigenen Kunden schuldet.
• Die aktuelle Liste der Unterauftragsverarbeiter wird Kunden und potenziellen Kunden per E-Mail nach Unterzeichnung einer Geheimhaltungsvereinbarung (NDA) mitgeteilt. Sende eine E-Mail an security@didit.me, um sie anzufordern. Kunden, die Benachrichtigungen über Änderungen bei Unterauftragsverarbeitern abonniert haben, werden per E-Mail mit ausreichender Vorankündigung benachrichtigt, um Einspruch erheben zu können.

13. Rechte der betroffenen Person und Löschung

• Recht auf Zugang und Datenübertragbarkeit, `GET /v3/sessions/:session_id/decision/`.
• Recht auf Löschung, `POST /v3/sessions/:session_id/delete/`. Entfernt die Sitzung und jedes verknüpfte Artefakt über jede Replik hinweg.
• Anwendungsbezogene Aufbewahrung ist in der Business Console zwischen 30 Tagen und 10 Jahren konfigurierbar; der Standard ist unbegrenzt, es sei denn, der Kunde konfiguriert einen kürzeren Zeitraum. Die Aufbewahrung biometrischer Daten unterliegt in jedem Fall den anwendbaren Gesetzen und Vorschriften zum Schutz biometrischer Daten und ist durch diese begrenzt, einschließlich Artikel 9 der EU-Datenschutz-Grundverordnung (DSGVO), des Illinois Biometric Information Privacy Act (BIPA), des Texas Capture or Use of Biometric Identifier Act (CUBI), des Washington H.B. 1493 und aller anderen anwendbaren Gesetze zum Schutz biometrischer Daten; wo ein solches Gesetz eine kürzere Aufbewahrungsfrist oder eine frühere Vernichtungspflicht vorschreibt, hat diese kürzere oder strengere Regel Vorrang vor jeder Standard- oder vom Kunden konfigurierten Aufbewahrungsfrist.
• Siehe die Datenschutzrichtlinie und den Datenschutzhinweis zur Verifizierung für den vollständigen Prozess der Rechte der betroffenen Person.

14. Meldung eines Sicherheitsproblems

Wenn du glaubst, eine Sicherheitslücke in einem Didit-Produkt oder -Dienst gefunden zu haben, sende eine E-Mail an security@didit.me mit einer Beschreibung, Reproduktionsschritten und der beobachteten Auswirkung. Didit bestätigt Sicherheitsberichte innerhalb von 2 Werktagen und arbeitet in gutem Glauben mit Reportern zusammen, die verantwortungsvolle Offenlegungspraktiken befolgen.

15. Kontakt

• Sicherheit: security@didit.me
• Datenschutzbeauftragter: dpo@didit.me
• Datenschutz: privacy@didit.me
• Rechtliches / Verträge: legal@didit.me
• Trust Pack Anfrage (unter NDA): security@didit.me