[yads, security, compliance, dsgvo, dora]

YADS, DSGVO, DORA und NIS2: Die ehrliche Gap-Analyse

2026-03-21 10:00:00 +0100 // Marco Frischkorn

KI generiert und vom Menschen redigiert

Tja... wenn man ein Security-Tool baut, das anderen dabei helfen soll, Schwachstellen und Compliance-Lücken zu finden -- dann ist es nur fair, sich mal selbst auf den Prüfstand zu stellen. Gesagt, getan.

Ich hab mich hingesetzt, alle Datenpunkte die YADS anfasst systematisch gegen DSGVO, DORA und jetzt neu auch NIS2 abgeglichen. Das Ergebnis? Ein klassisches Glas-halb-leer-halb-voll-Bild. Viel steht solide. Einiges steht noch nicht. Und ein paar Sachen müssen dringend angepackt werden.

Dieser Post ist kein Marketing. Der ist eine ehrliche Todo-Liste. Mit Kontext.

Und ja, ich weiß -- ein Post der damit beginnt "hier ist alles was ich noch nicht gemacht habe" ist nicht das, was man sich für sein eigenes Produkt wünscht. Aber wer anderen bei der Compliance hilft und dabei die eigene Hausaufgaben nicht macht, wäre ein schlechter Witz. Also machen wir das ordentlich.

📋 Was YADS überhaupt anfasst

Bevor es in die Lücken geht, kurz der Überblick was YADS an Daten verarbeitet. Das ist mehr als man auf den ersten Blick denkt:

  • Accountdaten: Name, E-Mail, Passwort-Hash (Bcrypt), MFA/TOTP-Secrets, Session-JWTs, OIDC-Subject-IDs
  • Audit-Events: Login-Versuche, Passwortänderungen, Rollenänderungen -- alles in der SecurityAuditLog mit SHA256-Hash-Chain
  • Scan-Ergebnisse: Domains, IPs, SSL-Zertifikate, Screenshots, gefundene E-Mails, Social-Handles, Credentials aus OSINT
  • HTTP-Traffic-Logs: Vollständige Request- und Response-Header -- inklusive Authorization-Header und Cookie-Werte
  • BYOK-API-Keys: OpenAI, Shodan, Censys, VirusTotal -- alle externen API-Zugänge die der User konfiguriert
  • Bug-Reports: Systeminfos der YADS-Installation, Hostnamen, Benutzernamen, Pfade
  • Support-Nachrichten und Client-IPs aus dem Support-Portal

Das ist eine beachtliche Liste. Und jeder einzelne Punkt muss auf Rechtsgrundlage, Speicherdauer und technische Maßnahmen geprüft sein. Gegen drei verschiedene Regelwerke. Gleichzeitig.

✅ Was bereits solide steht

Fangen wir mit dem Positiven an -- das gibt's nämlich auch, und es ist nicht wenig.

Die Rechtsgrundlagen nach Art. 6 DSGVO sind für den Kern von YADS sauber. Accountdaten, MFA-Secrets, Session-JWTs, OIDC-IDs -- alles läuft auf Art. 6 Abs. 1 lit. b (Vertragserfüllung). Audit-Events sind über lit. c (rechtliche Verpflichtung) und lit. f (berechtigtes Interesse: Sicherheit) gedeckt. Scan-Ergebnisse bei Unternehmens-Targets: kein Personenbezug, kein Problem.

Bei den technisch-organisatorischen Maßnahmen (Art. 32 DSGVO) sieht's ordentlich aus:

  • Passwort-Hashing mit Bcrypt ✅
  • MFA via TOTP (optional per Tenant) ✅
  • HTTPS/TLS in Transit via Reverse Proxy ✅
  • JWT in HttpOnly Cookies ✅
  • CSRF-Schutz via Double-Submit-Cookie-Pattern ✅
  • RBAC mit vier Rollen (admin, tenant_admin, scanner, auditor) ✅
  • SecurityAuditLog mit SHA256-Hash-Chain ✅
  • Bug-Reports verschlüsselt in Transit (X25519 ECDH) ✅
  • Datenbankbackup als Encrypted ZIP ✅
  • Netzwerkisolation via Docker Swarm Overlay ✅
  • Security-Headers (HSTS, CSP, X-Frame-Options) ✅
  • Input-Validierung via SQLModel ORM (parameterisiert) ✅
  • GitLab CI/CD, SBOM/CBOM-Generierung via Syft, Docker Multi-Stage Builds ✅

Beim DORA-Abgleich für das IKT-Risikomanagement (Art. 5-16): Security-Scanning mit 19 Modulen, Nuclei, Nuclei-Suggestions, kontinuierliches Monitoring via Cron-Schedules, Patch-Management über Nuclei-CVE-Erkennung, Celery-Worker-Isolation, Swarm-Stress-Tests, Backup/Restore per UI -- alles da.

NIS2-Sicherheitsmaßnahmen (Art. 21) sind zum größten Teil ebenfalls abgedeckt: Risikoanalyse via Scan-Scoring (A-F), MITRE ATT&CK-Mapping, Business Continuity via verschlüsseltes Backup, Schwachstellenmanagement als Kernfunktion, Netzwerkisolation, Zugangskontrollen, Cyber-Hygiene.

Das ist eine solide Basis. Jetzt kommt der Teil der weniger Spaß macht.

❌ Die Lücken -- alle 15 davon

🔴 Prio 1: Das brennt jetzt

L1 — API-Keys im Klartext in der Datenbank.

BYOK steht für "Bring Your Own Key". Der User konfiguriert seinen OpenAI-Key, Shodan-API-Key, Censys-Token -- und die landen aktuell im Klartext in der DB. Kein AES, kein KMS, keine Verschlüsselung at rest. Wer die Datenbank kompromittiert, hat sofort und vollständig Zugriff auf alle externen API-Zugänge aller Tenants.

Das ist technisch kein DSGVO-Problem (API-Keys sind keine personenbezogenen Daten), aber es ist ein klares Art. 32 DSGVO Problem und ein NIS2 Art. 21 Problem -- "angemessene technische Maßnahmen" schließt plaintext API-Keys definitiv nicht ein.

Fix: AES-256 Verschlüsselung at rest. Schlüssel aus einer Secret-Variable oder -- wenn man es wirklich ernst meint -- aus einem HSM. Das ist keine Rocket Science, das ist Grundlage. Und es erklärt sich von selbst warum das in Prio 1 landet.

L2 — Bug-Reports als Plaintext in der DB.

Die sind in Transit verschlüsselt -- X25519 ECDH, gut gemacht. Aber nach der serverseitigen Entschlüsselung landen die Inhalte unverschlüsselt in der Datenbank. Bug-Reports können Hostnamen, Benutzernamen, absolute Pfade enthalten. Das sind potentiell personenbezogene Daten. Re-Verschlüsselung in der DB oder Anonymisierung nach Bearbeitung. Beide Optionen machbar, keine implementiert.

L3 — HTTP-Traffic-Logs ohne TTL.

Vollständige Request- und Response-Header werden gespeichert. Unbegrenzt. Inklusive Authorization-Header. Inklusive Cookie-Werte. Das widerspricht Art. 5 Abs. 1 lit. e DSGVO (Speicherbegrenzung) direkt.

Fix: Default-TTL 30 Tage. Kritische Header (Authorization, Cookie) werden vor der Speicherung rausgeschmissen oder gehasht. Der Scan-Traffic-Inhalt ist für Debugging relevant, der Auth-Token darin ist es nicht.

L4 — MFA ist optional, nicht Standard.

Hier kommt NIS2 Art. 21 Abs. 2 lit. j ins Spiel: MFA ist für privilegierte Accounts Pflicht, keine Option. Aktuell ist TOTP per Tenant optional konfigurierbar. Das reicht nicht wenn YADS von NIS2-pflichtigen Unternehmen eingesetzt wird.

Fix: MFA als Default-Pflicht für alle admin- und tenant_admin-Rollen. Reguläre User können es optional lassen. Das ist ein konfigurierbarer Default -- aber der Default muss stimmen.

Diese vier Punkte sind Prio 1. Die kommen zuerst.

🟡 Prio 2: Kurzfristig

L5 — Kein Default für DATA_RETENTION_DAYS.

YADS hat eine konfigurierbare Retention-Policy für Scan-Ergebnisse. Das ist gut. Aber der Default ist... nichts. Kein Wert. Wer die Variable nicht setzt, behält Scan-Ergebnisse für immer. Das widerspricht Art. 5 lit. e DSGVO und DORA Art. 12 (5 Jahre Mindestaufbewahrung).

Fix: Default 1825 Tage (5 Jahre) für Scan-Ergebnisse, default 30 Tage für HTTP-Traffic-Logs. Die meisten Leute nehmen den Default -- der muss stimmen.

L6 — Client-IPs im Support-Portal ohne TTL.

Eine IP-Adresse ist ein personenbezogenes Datum. Ja, auch die vom Kontaktformular. Aktuelle Speicherdauer: unbegrenzt. Gängige Praxis und gut vertretbar: max. 7 Tage. Automatische Löschung rein, fertig.

L7 — Kein AVV mit OpenAI/Anthropic.

Wenn YADS Finding-Texte zur KI-Analyse an OpenAI oder Anthropic schickt -- und die Findings können Personendaten enthalten -- dann ist das Auftragsverarbeitung nach Art. 28 DSGVO. Dafür brauche ich einen Auftragsverarbeitungsvertrag. Mit beiden Anbietern. Aktuell nicht dokumentiert.

Außerdem muss sauber dokumentiert sein: KI-Analyse nur auf expliziten User-Trigger, nicht im Hintergrund. Das ist bereits so gebaut, muss aber auch in der Doku stehen.

L8 — Kein DORA/NIS2-Vorfallsmeldungs-Workflow.

DORA Art. 19 verlangt Meldung schwerwiegender IKT-Vorfälle an BaFin oder EZB. NIS2 Art. 23 ist noch schärfer: 24-Stunden-Frühwarnung, vollständige Meldung innerhalb 72 Stunden, Abschlussbericht nach einem Monat. Das ist kein "irgendwann"-Thema.

YADS hat Webhook-Notifications (Slack, Teams, Jira) -- das ist die technische Basis. Aber ein strukturierter Reporting-Workflow mit den richtigen Feldern, Fristen und Behörden-Adressen? Fehlt komplett.

Fix: Melde-Template in der Doku, 24h/72h-Checkliste für Tenants, Webhook als Notification-Mechanismus. Der Tenant ist für die eigentliche Meldung verantwortlich -- aber YADS muss den Rahmen liefern.

L9 — Kein strukturierter Incident-Response-Plan.

NIS2 Art. 21 Abs. 2 lit. b verlangt explizit ein Konzept für das Behandeln von Sicherheitsvorfällen. Der SecurityAuditLog ist da, die Hash-Chain ist da, Grafana Alerts sind da -- aber ein formeller IR-Plan der beschreibt was man im Vorfall-Fall tut? Fehlt.

Das ist kein technisches, sondern ein Dokumentationsprojekt. Aber es muss gemacht werden.

🟠 Prio 3: Mittelfristig

L10 — Kein formelles Drittparteien-Register.

DORA Art. 28 und NIS2 Art. 21 Abs. 2 lit. d verlangen ein Inventar kritischer IKT-Drittparteien. YADS nutzt: crt.sh, Wayback Machine, Google Custom Search, HIBP, Shodan, Censys, VirusTotal, OpenAI, Anthropic, Splunk HEC, und je nach Tenant noch Slack, Teams und Jira via Webhooks.

Das ist eine lange Liste. Die muss irgendwo stehen -- mit Klassifizierung, Zweck, Risikobewertung, und bei NIS2 auch mit Sicherheitsnachweis-Anforderung (SOC2, ISO27001 oder äquivalent). Ein Markdown-Dokument in der Doku reicht erstmal. Aber es muss existieren.

Besonders kritisch: OpenAI und Anthropic haben NIS2-Risiko "Hoch" -- Finding-Texte mit potentiellem Personenbezug werden in die USA übertragen. BYOK schützt vor Vendor-Lock-in, aber nicht vor Datentransfer. Das muss dokumentiert sein.

L11 — OSINT-Zweckbindung für Personendaten unklar.

OSINT-Ergebnisse die YADS findet -- E-Mail-Adressen, Social-Handles, Credentials -- wenn die natürliche Personen betreffen, greifen Art. 5 lit. b DSGVO (Zweckbindung) und Löschfristen. Die Nutzungsrichtlinie muss klar sagen: YADS ist für Security-Testing autorisierter Systeme. Nicht für Überwachung natürlicher Personen. Das gehört in die Tenant-AGB.

L12 — Kein AVV-Template für Webhook-Empfänger.

Wer Findings via Webhook an Slack, Teams oder Jira schickt, überträgt möglicherweise personenbezogene Daten. Das ist Sache des Tenants -- aber YADS sollte im Onboarding-Wizard darauf hinweisen. Und ein Template oder einen Hinweis liefern. Nicht machen können ist keine Entschuldigung.

L13 — SSRF-Schutz ohne explizites RFC-1918-Blocklist.

Der aktuelle SSRF-Schutz läuft über Domain-Regex-Filter. Das ist ein Anfang, aber kein vollständiger Schutz. Wer einen internen DNS-Namen auflöst der auf eine RFC-1918-Adresse zeigt (10.x.x.x, 172.16-31.x.x, 192.168.x.x), kann den Regex-Filter möglicherweise umgehen. Ein expliziter ipaddress.ip_address(ip).is_private Check im Scanner-Eingang ist Pflicht. Art. 32 DSGVO und NIS2 Art. 21.

L14 — Keine dokumentierte Governance-Struktur.

NIS2 Art. 20 ist ein bisschen unangenehm: Leitungsorgane müssen Cybersicherheitsmaßnahmen billigen, überwachen und für Verstöße persönlich haften. Sie müssen regelmäßig geschult werden. Das ist organisatorisch -- YADS kann das nicht für den Betreiber abbilden. Aber YADS kann zumindest einen Hinweis und ein Template für das Management-Sign-off liefern. Und ich kann für YADS-as-a-Vendor diese Governance dokumentieren.

L15 — Kein STIX/TAXII für Threat Intelligence.

NIS2 Art. 45 und DORA Art. 45 befassen sich mit dem strukturierten Informationsaustausch über Bedrohungen. YADS nutzt Nuclei-Templates (öffentlich), VirusTotal-Feeds -- das ist ein Anfang. Aber strukturierter STIX/TAXII-Export? Fehlt. Das ist kein Sofort-Thema, aber es gehört auf die mittelfristige Roadmap.

⚖️ Der Drei-Wege-Konflikt: DSGVO will kurz, DORA und NIS2 wollen lang

Hier wird's philosophisch. Drei Regelwerke, die sich teilweise widersprechen -- und YADS muss alle drei bedienen.

SecurityAuditLog: DSGVO sagt "so kurz wie nötig". DORA sagt "mind. 5 Jahre". NIS2 sagt "mind. 3 Jahre". Wenn DORA-pflichtige Finanzdienstleister YADS einsetzen: 5 Jahre. Wenn NIS2-pflichtige Kunden ohne DORA: 3 Jahre. Default: 5 Jahre. Unbegrenzte Speicherung (aktuelle Implementierung) erfüllt zumindest die Mindestanforderung -- das ist die gute Nachricht.

HTTP-Traffic-Logs: DSGVO hätte gerne 30 Tage (personenbezogene Daten in Headers). DORA könnte 5 Jahre verlangen wenn die Logs IKT-Vorfalls-Protokolle sind. NIS2: 3 Jahre für Incident-relevante Logs. Lösung durch Differenzierung: Routine-Crawler-Logs laufen nach 30 Tagen ab. Bei erkanntem Vorfall wird der relevante Log-Ausschnitt in Loki (MinIO, 5-Jahres-Retention) archiviert. Das lässt sich implementieren.

Scan-Ergebnisse: DSGVO: zweckgebunden löschen sobald der Zweck erfüllt ist. DORA und NIS2: IKT-Monitoring kann Langzeitaufbewahrung erfordern. Lösung: Konfigurierbar lassen via DATA_RETENTION_DAYS, aber Default 1825 Tage setzen. Der Tenant entscheidet je nach eigenem Compliance-Bedarf.

MFA: DSGVO sagt gar nichts dazu. DORA empfiehlt es. NIS2 Art. 21 Abs. 2 lit. j macht es zur Pflicht für privilegierte Accounts. Winner: NIS2. MFA wird Default-Pflicht für Admins.

Vorfallsmeldung: DSGVO Art. 33 gibt 72 Stunden für Datenpannen-Meldungen an die Aufsichtsbehörde. DORA Art. 19 verlangt Sofort-Meldung plus Abschlussbericht. NIS2 Art. 23 ist am schärfsten: 24 Stunden Frühwarnung, 72 Stunden vollständige Meldung, 1 Monat Abschlussbericht. Für einen einheitlichen IR-Workflow nimmt man die schärfste Anforderung als Basis -- das ist NIS2.

Diese Konflikte sind lösbar. Aber sie müssen bewusst gelöst werden, nicht ignoriert. Wer die Frage "welche Retention-Policy ist die richtige?" mit "weiß ich nicht, kein Default gesetzt" beantwortet, hat keine Antwort gegeben -- der hat das Problem auf den nächsten Audit verschoben. Und Audits sind teuer.

🌐 NIS2: Das neue Regelwerk das alle trifft

NIS2 ist der Neue hier und verdient extra Aufmerksamkeit weil die Meldepflichten echte Zähne haben.

24-Stunden-Frühwarnung, 72-Stunden-Vollmeldung, 1-Monat-Abschlussbericht. Das ist kein bürokratisches Ritual -- das sind rechtlich verbindliche Fristen mit Sanktionen bis zu 10 Millionen Euro oder 2% des weltweiten Jahresumsatzes für wesentliche Einrichtungen. Und das betrifft nicht nur Finanzdienstleister (DORA) sondern Energie, Gesundheit, Wasser, digitale Infrastruktur, Transport -- ein deutlich breiterer Scope.

Für YADS bedeutet das zwei Szenarien:

Szenario 1: Ein NIS2-pflichtiger Kunde nutzt YADS. Dann muss YADS als IKT-Drittpartei NIS2-kompatibel sein (Lieferkettenrisiko Art. 21 Abs. 2 lit. d). Konkret: Ich muss nachweisen können, dass YADS die Sicherheitsanforderungen des Kunden nicht gefährdet.

Szenario 2: Wenn YADS als Managed Security Service betrieben wird, könnte der Betreiber selbst NIS2-pflichtig sein. Dann gelten die Pflichten direkt.

Was ist der praktische Unterschied zwischen DORA und NIS2 für YADS-Nutzer? DORA ist Finanzsektor-spezifisch und fokussiert auf operative Resilienz und das Drittparteien-Risiko von IKT-Anbietern. NIS2 ist deutlich breiter im Scope (Energie, Gesundheit, Wasser, digitale Infrastruktur, Transport und mehr), schärfer bei den Meldepflichten, und verlangt explizite Governance auf Leitungsebene. Die Überschneidungen sind groß -- beide wollen Audit-Logs, Incident Response, Verschlüsselung, MFA. Aber die Details -- und besonders die Fristen und Sanktionen -- unterscheiden sich erheblich. Ein Finanzdienstleister der YADS einsetzt hat unter Umständen gleichzeitig DORA- und NIS2-Pflichten. Doppelte Freude.

Was YADS aktuell bei NIS2 fehlt: jeder strukturierte Meldeprozess. Erkennung ist da -- SecurityAuditLog, Grafana Alerts, Scan-basierte Anomalie-Erkennung. Alerting ist da -- Webhooks an Slack, Teams, Jira. Aber ein Workflow der bei einem erkannten Incident automatisch die 24h-Frühwarnung-Uhr startet, die richtigen Felder für die Behördenmelder befüllt und den Tenant Schritt für Schritt durch den Meldeprozess führt? Nicht implementiert. Das ist das größte NIS2-Gap. Und ehrlich gesagt auch ein Gap der erklären würde warum manche Kunden lieber zweimal fragen bevor sie unterschreiben.

🔗 AVV-Realität: Wer hat schon einen Vertrag?

Kurzer Reality-Check bei den externen Diensten:

  • crt.sh, Wayback Machine: Öffentliche Dienste, keine Personendaten. Kein AVV nötig. ✅
  • Google Custom Search, Shodan, Censys, VirusTotal: IPs und Queries können Personenbezug haben. AVV prüfen. ⚠️
  • HIBP: Hat eigene API-Bedingungen. Ob die als AVV ausreichen muss geprüft werden. ⚠️
  • OpenAI / Anthropic: Finding-Texte können Personendaten enthalten. AVV Pflicht. ❌ Aktuell nicht dokumentiert.
  • Splunk HEC: Wenn on-premise Kundendaten -- AVV-Pflicht Tenant-seitig. ⚠️
  • Slack / Teams / Jira Webhooks: Tenant-Verantwortung, aber Hinweis in Doku und Onboarding nötig. ⚠️

OpenAI und Anthropic sind hier die kritischsten Punkte. Das muss geklärt sein -- und zwar dokumentiert und auffindbar, nicht als "liegt irgendwo im E-Mail-Postfach" -- bevor YADS produktiv in Umgebungen mit Personendaten in den Findings läuft. Kein AVV ist kein Argument beim nächsten Audit. Das ist ein Argument für eine Bußgeldverfügung.

Fazit

Ich hab jetzt schwarz auf weiß wo ich stehe. Das ist der wertvollste Output dieser Analyse.

Vier Dinge brennen sofort (L1-L4): API-Keys im Klartext, Bug-Reports als Plaintext in der DB, HTTP-Traffic-Logs ohne TTL, MFA nicht als Default erzwungen. Die kommen als nächstes.

Fünf Sachen sind kurzfristig (L5-L9): Retention-Defaults setzen, Client-IP-TTL rein, AVV mit OpenAI/Anthropic klären, Vorfallsmeldungs-Template für DORA und NIS2 in die Doku, Incident-Response-Plan schreiben.

Sechs Punkte sind mittelfristig (L10-L15): Drittparteien-Register, OSINT-Nutzungsrichtlinie, Webhook-Hinweise, SSRF-Hardening, Governance-Dokumentation, STIX/TAXII auf die Roadmap.

Ist das viel? Ja. Ist es machbar? Ja. Und nach diesem Post hat zumindest niemand mehr die Ausrede, er hätte von nichts gewusst -- inklusive mir selbst.

Am Ende zählt, dass die Bude sicher bleibt. Und dass ich nicht nur anderen sage, wie es geht.

👉 yads-security.de

Basis: yads/datenpunkte_vs_vorgaben.md | Stand: YADS v1.51.5 | 2026-03-21

Transparency Note: Dieser Post wurde mit Unterstützung von KI erstellt und von mir (Marco) auf Vollständigkeit und Korrektheit geprüft. Die Analyse und Priorisierung der Lücken sind meine eigene -- die KI hat den Text strukturiert und ausformuliert. Wie immer... sonst wär's ja nicht ehrlich. ;-)