Executive Summary#

Dieses Dokument beschreibt die technischen und organisatorischen Sicherheitsmaßnahmen der Anwendung Inkasso.live. Ziel ist der Schutz personenbezogener Daten gemäß DSGVO, die Gewährleistung der Integrität aller verarbeiteten Informationen sowie die Einhaltung aktueller regulatorischer Vorgaben wie dem EU Cyber Resilience Act (CRA). Die Anwendung setzt auf passwortlose Authentifikation mittels WebAuthn, starke Mehr-Faktor-Authentifizierung, verschlüsselte Datenhaltung, Rollen- und Rechtekonzepte sowie eine moderne Software-Lieferkettensicherheit. Alle sicherheitsrelevanten Prozesse folgen dem Prinzip „Security by Design“ und „Security by Default“. Durch diese Mechanismen wird das Risiko unbefugter Zugriffe signifikant reduziert. Gleichzeitig wird gewährleistet, dass sensible Daten wie Schuldnerinformationen, Finanzdaten oder personenbezogene Vorgangsdaten ausschließlich innerhalb klar definierter und kontrollierter Sicherheitsgrenzen verarbeitet werden.

Sicherheit & Datenschutz#

Der Schutz personenbezogener Daten und die Absicherung aller technischen Komponenten sind zentrale Anforderungen an den Betrieb einer modernen Inkasso-Anwendung. Die gesamte Architektur folgt konsequent den Prinzipien Security by Design und Security by Default. Diese Leitlinien entsprechen den Vorgaben des EU Cyber Resilience Act (CRA), der DSGVO sowie weiteren etablierten Best Practices wie OWASP und NIST.

Die folgenden Kapitel erläutern die technischen und organisatorischen Maßnahmen, die in der Anwendung umgesetzt wurden. Dabei wird jeweils dargestellt, welche Risiken adressiert werden und wie die gewählten Sicherheitsmechanismen wirken.

1. Passwortlose Authentifikation mit WebAuthn#

Die Anwendung verzichtet vollständig auf Kennwörter, um bekannte Risiken wie Brute-Force-Angriffe, Credential Stuffing oder Passwortdiebstahl auszuschließen. Die Authentifikation basiert ausschließlich auf WebAuthn, einem modernen, standardisierten Verfahren, das starke kryptografische Merkmale nutzt und auf allen gängigen Betriebssystemen verfügbar ist.

1.1 Initiale Registrierung durch Einmal-Token#

Vorgehen:
Neue Anwender erhalten ein zeitlich begrenztes Einmal-Token (OTP), um ein Konto anzulegen. Das Token wird individuell generiert, per E-Mail zugestellt und verfällt unmittelbar nach der ersten Verwendung. Damit wird verhindert, dass ein Konto ohne tatsächliche Nutzerinteraktion entsteht.

Risiko:
Sollte ein Angreifer die E-Mail abfangen, könnte er das Konto anlegen. Da das Token jedoch sofort verfällt, wäre der Angriff unmittelbar erkennbar. Der legitime Nutzer würde keine Möglichkeit mehr haben, das Token zu nutzen und könnte den Vorfall melden.

Weiterführende Maßnahmen (optional):
Für Umgebungen mit besonders hohen Sicherheitsanforderungen kann das Token über alternative Kanäle (z. B. Briefpost, verschlüsselte Kommunikation oder Zwei-Kanal-Verfahren) zugestellt werden.

1.2 Erzeugung des WebAuthn-Schlüsselpaares#

Bei der Registrierung mit WebAuthn wird ein Schlüsselpaar erzeugt. Dieser Prozess wird nicht von der Anwendung, sondern vom Betriebssystem bzw. Browser durchgeführt.

• Privater Schlüssel: verbleibt sicher im Gerät des Anwenders (z. B. Secure Enclave, TPM, Android Keystore). Ein Auslesen ist systemseitig ausgeschlossen.
• Öffentlicher Schlüssel: wird an den Server übertragen und gespeichert. Sein Verlust oder seine Kenntnis durch Dritte stellt kein Sicherheitsrisiko dar.

Durch diesen Mechanismus wird sichergestellt, dass keine geheimen Daten den Endgeräte-Schutzbereich verlassen und damit auch nicht abgefangen oder missbraucht werden können.

1.3 Anmeldeprozess (Challenge-Response-Verfahren)#

Die Anmeldung erfolgt ausschließlich über eine kryptografisch signierte Challenge:

1. Die App sendet Geräte-ID und Credential-ID an den Server.
2. Der Server generiert eine einmalige Challenge.
3. Der Nutzer authentifiziert sich lokal (PIN, Fingerabdruck, Face-ID).
4. Der Authenticator signiert die Challenge.
5. Der Server prüft die Signatur mit dem öffentlichen Schlüssel.
6. Die Anmeldung wird freigegeben.

Wichtig für den Datenschutz:
Biometrische Daten verlassen niemals das Gerät. Sie dienen nur zur lokalen Entsperrung des privaten Schlüssels.

1.4 Mehr-Faktor-Authentifizierung (MFA)#

WebAuthn erfüllt automatisch die Anforderungen einer starken Mehr-Faktor-Authentifizierung:

• Besitz: das Endgerät, auf dem der private Schlüssel liegt
• Wissen: lokale Geräte-PIN oder Passwort
• Biometrie (optional als Besitzmerkmal): Fingerabdruck / Face ID

Somit erfüllt die Anwendung die typischen regulatorischen Anforderungen an eine starke Authentifikation gemäß Stand der Technik.

2. Anwendungs- und Endgerätesicherheit#

Neben der Authentifikation enthält die Anwendung weitere Schutzmechanismen, die direkte oder indirekte Angriffe auf Endgeräte, Sessions oder lokale Daten verhindern.

2.1 Sandboxing der Anwendung (PWA)#

Die Anwendung wird als Progressive Web App (PWA) im Browser ausgeführt. Dadurch entsteht eine systemseitig isolierte Umgebung:

• kein Zugriff auf lokale Dateien
• kein Zugriff auf Daten anderer Webseiten
• keine Möglichkeit zum Ausführen unsicherer Systembefehle
• regelmäßige Sicherheitsupdates durch den Browserhersteller

Das Sandboxing minimiert das Risiko, dass lokale Informationen extrahiert oder Schadsoftware über die Anwendung eingeschleust werden kann.

2.2 Verschlüsselte Offline-Datenhaltung#

Zur Unterstützung des Offline-Modus werden notwendige Daten in einer IndexedDB abgelegt. Diese Datenbank wird vollständig verschlüsselt.

• Der Schlüssel wird erst durch WebAuthn freigeschaltet.
• Die App besitzt diesen Schlüssel nicht dauerhaft.
• Ohne gültige Authentifikation kann niemand auf die lokalen Daten zugreifen, selbst wenn er physischen Zugriff auf das Gerät hat.

Damit ist sowohl die Vertraulichkeit als auch Integrität der lokal zwischengespeicherten Daten gewährleistet.

2.3 Kurzlebige Session-Tokens#

Sobald ein Nutzer angemeldet ist, erhält die Anwendung ein Session-Token. Dieses Token:

• hat nur eine sehr kurze Gültigkeitsdauer
• wird automatisch und regelmäßig erneuert
• ändert sich bei jeder Erneuerung
• verliert nach kurzer Zeit seine Wirksamkeit

Ein abgefangenes Token ist deshalb nur für einen sehr kurzen Zeitraum überhaupt nutzbar und bietet keinen nachhaltigen Zugriff.

2.4 Rollen- und Rechtekonzept (RBAC)#

Die Anwendung implementiert ein feingranulares Rollenmodell.

Jeder Anwender erhält ausschließlich die Berechtigungen, die für seine Aufgaben erforderlich sind. Dies umfasst:

• rollenbasierte Zugriffskontrolle
• standardmäßig verweigerter Zugriff (deny by default)
• klar definierte Rechte für Lesen, Schreiben, Bearbeiten und Löschen

Dadurch wird verhindert, dass personenbezogene Daten unnötig eingesehen oder verarbeitet werden.

2.5 Datenbank-Scopes zur serverseitigen Zugriffsbeschränkung#

Neben RBAC wird die Zugriffskontrolle zusätzlich in der Datenbank enforced.

• Jede Datenbankabfrage berücksichtigt automatisch den Scope des Anwenders.
• Daten, auf die ein Benutzer keinen Zugriff haben darf, können technisch gar nicht erst geliefert werden.
• Die Filterung erfolgt bereits vor der Ausführung der Query.

Damit entsteht ein zusätzlicher Schutzlayer, der sowohl Fehler in der Geschäftslogik als auch potenziell manipulierte Requests abfängt.

3. Software-Bill-of-Materials, Lieferkettensicherheit und Updates#

3.1 Komponentenüberwachung (SBOM)#

Alle eingesetzten externen Komponenten und Bibliotheken werden transparent dokumentiert. Die Software führt eine vollständige Software Bill of Materials (SBOM), die für:

• Sicherheitsprüfungen
• CRA-Konformität
• interne Audits
• Lieferkettentransparenz

verwendet wird.

Sicherheitslücken (z. B. CVEs) werden automatisiert überwacht. Betroffene Komponenten werden zeitnah aktualisiert.

3.2 Kontinuierliche Updates durch CI/CD#

Server- und Clientkomponenten werden über automatisierte Prozesse regelmäßig aktualisiert.

Dadurch:

• gelangen Sicherheitspatches schnell in den Einsatz
• wird die Angriffsfläche minimiert
• sinkt das Risiko veralteter oder verwundbarer Komponenten
• werden Bugfixes zeitnah verteilt

Der Prozess erfüllt typische Anforderungen an moderne Development- und Betriebsumgebungen (DevSecOps).

4. Einhaltung regulatorischer Vorgaben#

4.1 EU Cyber Resilience Act (CRA)#

Die Architektur erfüllt wesentliche Anforderungen des CRA:

• Security by Design & Default
• dokumentierte SBOM
• sichere Update-Prozesse
• kontinuierliche Schwachstellenanalyse
• starke Authentifikation
• Absicherung der Software-Lieferkette

Damit entspricht die Lösung den zukünftigen Marktanforderungen für sichere digitale Produkte.

4.2 Datenschutz-Grundverordnung (DSGVO)#

Besonders relevante DSGVO-Anforderungen werden explizit erfüllt:

• Art. 5 (Datenminimierung, Integrität, Vertraulichkeit)
• Art. 25 (Privacy by Design & Default)
• Art. 32 (Sicherheit der Verarbeitung)
• Art. 33/34 (Risikominimierung für Betroffene)

Die Anwendung reduziert personenbezogene Daten auf das notwendige Minimum und schützt diese durch moderne kryptografische und organisatorische Maßnahmen.

5. Zusammenfassung#

Die Kombination aus passwortloser Authentifikation, kryptografischer Absicherung, rollenbasierten Berechtigungen und moderner Software-Lieferkettensicherheit bietet ein sehr hohes Schutzniveau für personenbezogene Daten. Die gewählten Mechanismen erfüllen alle regulatorischen Anforderungen und entsprechen gleichzeitig dem Stand der Technik.

6. Anhänge#

Risikomodell (vereinfacht)#

Bedrohungsmatrix nach STRIDE#

LINDDUN-Datenschutzmatrix (Auszug)#

Threat Modeling#

Das Threat Modeling dient dazu, potenzielle Angriffsvektoren systematisch zu identifizieren und die Wirksamkeit der vorhandenen Sicherheitsmaßnahmen zu bewerten. Grundlage bildet eine Kombination etablierter Methoden wie STRIDE, LINDDUN und Asset-basierter Risikoanalyse. Die Analyse berücksichtigt sowohl technische Angriffsszenarien als auch Risiken im Bereich Datenschutz und Compliance.

1. Schutzwürdige Assets#

Die zentralen zu schützenden Werte der Anwendung lassen sich in folgende Kategorien einteilen:

1.1 Personenbezogene Daten#

• Schuldnerdaten
• Kommunikationsdaten
• Benutzerinformationen
• Zahlungsrelevante Informationen
  Diese Daten weisen eine hohe Schutzbedürftigkeit nach DSGVO Art. 5 und Art. 32 auf.

1.2 Authentifikations- und Autorisierungsdaten#

• WebAuthn-Credentials (öffentliche Schlüssel)
• Temporäre Session-Tokens
• Rollen- und Rechteinformationen

1.3 Integrität von Geschäftsprozessen#

• Vorgangsverarbeitung
• Statuswechsel
• Verantwortlichkeitszuordnung

1.4 Betrieb und Infrastruktur#

• Backend-Services
• Datenbanken
• CI/CD-Pipeline
• SBOM und Dependency-Daten

2. Angreiferprofile#

Die Bedrohungsanalyse berücksichtigt verschiedene Klassen potenzieller Angreifer:

2.1 Externe Angreifer#

Versuchen, über technische Schwachstellen Zugriff auf personenbezogene Daten oder interne Systeme zu erlangen (z. B. Credential Stuffing, Injection, Brute Force). Durch WebAuthn entfallen klassische Passwortangriffe vollständig.

2.2 Interne Angreifer#

Mitarbeiter oder Dienstleister mit legitimen, aber überproportionalen Rechten.
Gegenmaßnahmen: RBAC, DB-Scopes, Logging, „Deny by Default“.

2.3 Kompromittierte Endgeräte#

Angreifer, die Zugriff auf das Endgerät eines Nutzers haben.
Gegenmaßnahmen: WebAuthn, lokale Verschlüsselung, Sandboxing.

2.4 Lieferkettenangriffe#

Manipulationen oder Schwachstellen in Dependencies, Build-Prozessen oder Third-Party-Bibliotheken.
Gegenmaßnahmen: SBOM, Dependency Tracking, CI/CD-Härtung.

3. Angriffspfade und Gegenmaßnahmen#

3.1 Spoofing (Identitätsvortäuschung)#

Risiko: Versuch, sich als eine andere Person auszugeben.
Gegenmaßnahmen:

• WebAuthn (bietet starke bindende Identifikation)
• Mehr-Faktor-Authentifizierung
• Kurzlebige Sessions
• Serverseitige Signaturvalidierung

3.2 Tampering (Manipulation von Daten)#

Risiko: Veränderung von Daten während Übertragung, Speicherung oder Verarbeitung.
Gegenmaßnahmen:

• TLS-Verschlüsselung
• Signaturprüfungen
• Datenbank-Scopes
• Eingabevalidierungen
• Rollen- und Rechtekonzept

3.3 Information Disclosure (Datenleck)#

Risiko: Unbefugter Zugriff auf personenbezogene Daten.
Gegenmaßnahmen:

• Verschlüsselung gespeicherter Offline-Daten
• RBAC
• Sandboxing
• Zero-Password-Architektur
• Logische und physische Zugriffskontrollen

3.4 Elevation of Privilege (Rechteausweitung)#

Risiko: Ein Angreifer erhält höhere Berechtigungen als vorgesehen.
Gegenmaßnahmen:

• Feingranulares RBAC
• Deny-by-Default
• DB-Level-Scopes
• Strikte Prüfung aller API-Requests

3.5 Denial of Service#

Risiko: Störung oder Blockade des Dienstes.
Gegenmaßnahmen:

• Skalierbare Infrastruktur
• Rate-Limits
• Monitoring, Alerting
• Resiliente API-Architektur
• Fail2Ban-Policies, die Logins und Netzwerkzugriffe bei Brute-Force- oder DoS-Versuchen automatisiert blockieren
• GeoIP-Filterung, die ausschließlich Aufrufe aus vorab definierten, geschäftsrelevanten Ländern zulässt
• Vorgeschalteter Reverse Proxy mit URL-Whitelisting, sodass nur tatsächlich verwendete Endpunkte an die Anwendung weitergeleitet werden

3.6 Supply Chain Angriffe#

Risiko: Einschleusen manipulierter oder verwundbarer Komponenten.
Gegenmaßnahmen:

• Vollständige SBOM
• Vulnerability Monitoring
• Kontrollierte Build-Umgebungen
• Signierte Artefakte

4. Bewertung der Gesamtrisikolage#

Durch den Einsatz von WebAuthn, MFA, Datenbank-Scopes und einer klar dokumentierten Lieferkettensicherheit wird ein Großteil klassischer Angriffsvektoren deutlich reduziert oder vollständig eliminiert.

Die verbleibenden Risiken liegen überwiegend in den Bereichen:

• kompromittierte Endgeräte
• Social Engineering
• Zero-Day-Schwachstellen in Lieferketten

Diese Risiken werden durch organisatorische Maßnahmen, Monitoring und die CI/CD-Prozesse weiter mitigiert. Die Gesamtrisikolage ist im Ergebnis niedrig bis moderat und entspricht dem in DSGVO Art. 32 geforderten Stand der Technik.