Datenpanne: Was in den ersten 72 Stunden zu tun ist und wie Sie sie verhindern

Montagmorgen. Jemand aus dem Support meldet, dass im System etwas Seltsames passiert: Anfragen von unbekannten Adressen, Konten, die niemand kennt, Datenverkehr um drei Uhr nachts. Nach ein paar Stunden ist klar, dass jemand einen Zugang hat, den er nicht haben dürfte.

In diesem Moment fragt niemand, wer es war. Alle fragen dasselbe: Was hat er gesehen?

Die Uhr läuft ab dem ersten Moment

Wenn personenbezogene Daten von Kunden oder Nutzern betroffen sind, verlangt die DSGVO, dass Sie die Verletzung unverzüglich und möglichst binnen 72 Stunden, nachdem sie Ihnen bekannt wurde, der zuständigen Datenschutzaufsichtsbehörde melden. Ist das Risiko für die Betroffenen hoch, müssen Sie auch sie benachrichtigen.

Dafür brauchen Sie die Antwort auf drei Fragen: Auf welche Daten konnte der Angreifer zugreifen, auf welche hat er tatsächlich zugegriffen, und ist er noch drin? Wenn Sie es nicht wissen, bleibt nur die ehrliche Annahme des Schlimmsten: dass er alles gesehen hat. Und “alles” heißt, allen Kunden zu schreiben.

Der Unterschied zwischen “er hat zehn Datensätze gesehen” und “wir mussten alle Kunden benachrichtigen” wird nicht am Tag des Angriffs entschieden. Er wird Monate vorher entschieden, in der Art, wie die Anwendung gebaut wurde.

Die Lücken, die Angreifer wirklich nutzen

Angriffe auf Geschäftsanwendungen sehen selten aus wie im Film. Meistens braucht es keine Genialität, sondern nur eine Tür, die jemand offen gelassen hat:

• Passwörter im Klartext gespeichert. Wer an die Datenbank kommt, hat alle Passwörter. Und Nutzer verwenden dieselben Passwörter für E-Mail und Bank, also endet das Datenleck nicht bei Ihnen. Passwörter werden nie gespeichert, sondern nur ein Fingerabdruck, aus dem sich das Passwort nicht zurückgewinnen lässt.
• Die Anwendung sendet mehr, als der Bildschirm zeigt. Der Bildschirm zeigt Name und E-Mail, aber im Hintergrund sendet die Anwendung den ganzen Datensatz, mit Feldern, die niemand sieht, der nicht nachschaut. Angreifer schauen immer nach.
• Fremde Daten durch Ändern einer Nummer. Ändern Sie die Bestellnummer in der Adresse, und Sie sehen eine fremde Bestellung. Das klingt zu einfach, um wahr zu sein, und doch steht fehlerhafte Zugriffskontrolle ganz oben auf der OWASP-Liste der häufigsten Sicherheitsrisiken für Webanwendungen.
• Unbegrenzte Versuche. Ohne Limit kann ein Angreifer Passwörter oder Nummern tausendfach pro Minute ausprobieren, bis etwas funktioniert.
• Offene Selbstregistrierung. Wenn sich jeder registrieren kann, muss der Angreifer nicht einbrechen. Er legt ein Konto an und schaut, was ein Nutzer von innen alles abrufen kann.
• Administration aus dem ganzen Internet erreichbar. Eine Oberfläche, die fünf Leute im Unternehmen brauchen und die jeder auf der Welt erreichen kann.
• Logs, aus denen man nichts erkennt. Die Anwendung protokolliert Fehler, aber nicht, wer was abgerufen hat. Am Tag des Vorfalls ist das der Unterschied zwischen einer Antwort und einer Vermutung.

Wenn es passiert: die Reihenfolge

1. Tür schließenZugang kappen, Schlüssel ändern
2. Klären, was gesehen wurdeAus den Logs, nicht geraten
3. MeldenDer Behörde und, falls nötig, den Betroffenen
4. Ursachen behebenDamit es nicht wieder passiert

1. Schließen Sie die Tür. Kappen Sie jeden Zugang, der nicht bestehen dürfte: Sperren Sie verdächtige Konten, ändern Sie Passwörter, Schlüssel und Tokens, die der Angreifer gesehen haben könnte. Schnell, aber ohne Spuren zu verwischen.
2. Klären Sie, was gesehen wurde. Rekonstruieren Sie aus den Logs, was der Angreifer getan hat, auf welche Daten er zugegriffen hat und seit wann. Dieser Schritt entscheidet über alles Weitere.
3. Melden Sie. Der Behörde fristgerecht und den Betroffenen, wenn das Risiko hoch ist. Klar und ehrlich: Was ist passiert, welche Daten sind betroffen, und was unternehmen Sie?
4. Beheben Sie die Ursachen. Nicht nur die Lücke, durch die er gekommen ist, sondern alle ähnlichen. Ein Angreifer, der eine offene Tür gefunden hat, hat mit Sicherheit auch die anderen ausprobiert.

10 Fragen, die Sie Ihrem Team heute stellen können

Sie müssen nicht programmieren können, um sie zu stellen. Sie müssen nur auf einer klaren Antwort bestehen:

1. Wie speichern wir die Passwörter der Nutzer? Die richtige Antwort: als Fingerabdruck (Hash), nie als Text.
2. Liefert die Anwendung nur die Daten, die der Bildschirm wirklich braucht?
3. Prüft die Anwendung bei jeder Anfrage, ob dieser Nutzer genau diesen Datensatz sehen darf?
4. Wie viele Anmeldeversuche erlauben wir vor einer Sperre?
5. Kann sich jeder registrieren, und was sieht er danach?
6. Wer kommt an die Administration, und von wo aus?
7. Melden sich Administratoren mit Zwei-Faktor-Authentifizierung an?
8. Wenn morgen jemand eindringt, würden wir aus den Logs erkennen, was er gesehen hat? Wie lange bewahren wir Logs auf?
9. Wann haben wir zuletzt Bibliotheken mit bekannten Schwachstellen aktualisiert?
10. Wer ist zuständig, wenn um drei Uhr nachts ein Vorfall passiert, und weiß diese Person, was zu tun ist?

Wenn Sie auf mehr als zwei dieser Fragen “weiß ich nicht” oder “müsste eigentlich passen” hören, wissen Sie, wo Sie anfangen müssen.

Wie wir arbeiten

ProCoding ist ein .NET-Studio aus Split, Kroatien. Wir prüfen die Sicherheit von Geschäftsanwendungen auf Basis von .NET, ASP.NET Core, Blazor und SQL Server. Wir gehen Code, APIs, Anmeldung und Berechtigungen, Logs und Konfiguration durch, und Sie erhalten eine nach Risiko sortierte Liste der Lücken, mit einem Lösungsvorschlag für jede.

Und wenn ein Vorfall schon passiert ist, helfen wir beim Dringendsten: die Tür schließen, aus den Logs klären, was der Angreifer gesehen hat, und die Ursachen beheben. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Quellen

• Datenschutz-Grundverordnung (DSGVO), Artikel 33 und 34, EUR-Lex
• OWASP Top 10:2025, OWASP Foundation