Datenschutz & Sicherheit

Diese Seite beschreibt den aktuell belegten Datenschutz- und Sicherheitsstand des Superheld-Workspaces. Sie trennt bewusst zwischen verifizierter Runtime-Wahrheit und Zielarchitektur.

Achtung

Der heute belegte Produktpfad ist ein lokaler Android-plus-Cloud-MVP im Workspace. Nicht als aktueller Runtime-Stand belegt sind unter anderem:

• ein Endkunden-Konto-, Abo- oder Passwort-Produktmodell
• ein ausgerolltes DSGVO-/Compliance-Programm mit extern belegten Lösch- oder Auskunftsprozessen
• eine gehostete EU-Produktumgebung
• Zwei-Faktor-Authentifizierung, biometrische App-Entsperrung oder Session-Timeouts als belegter Nutzerpfad
• lokale AES-256-Verschlüsselung aller Gerätedaten
• Cloud-Enrichment über Hash- oder Feature-Vektor-Uploads als belegter Android-v1-Pfad
• Store-Distribution, öffentliche Support-SLAs oder ein publiziertes Transparency-Programm

Aktuell verifizierter Runtime-Schnitt

Für den heute belegten Runtime-Pfad gilt:

• Runtime-proven ist nur Android gegen lokales superheld-cloud.
• Der verifizierte Tablet-Pfad nutzt adb reverse tcp:8080 tcp:8080 und http://127.0.0.1:8080.
• superheld-cloud startet im Secure-Mux-Default tenant-gebunden mit Bootstrap-Token.
• Die Android-App kann POST /devices, POST /events, GET /status, GET /alerts, GET /incidents, GET /incidents/{id}, GET /jobs, GET /jobs/{id}, GET /traces/{id} und GET /traces/{id}/steps gegen denselben lokalen Backend-Lauf nutzen.
• Device-Registrierung und Event-Submission sind an ein lokales RSA-Schlüsselpaar im Android Keystore gekoppelt; der Backend-Pfad verifiziert den Signatur-Contract.
• Tenant-gebundene API-Tokens steuern die app-relevanten Read-/Write-Pfade.
• Der Backend-Prozess schreibt operative Logs nach stdout oder stderr; der App-Start schreibt den belegten app_launch-Slice nach logcat.

Welche Daten der belegte Pfad heute wirklich verarbeitet

Datenklasse	Aktueller belegter Pfad	Heutiger Status
Device-Registrierung	device_id, tenant_id, platform, status, public_key_b64 in POST /devices	runtime-proven
Event-Submission	signiertes Demo-Event mit event_id, tenant_id, device_id, threat_category, confidence, action_taken, policy_id, severity, description, indicators in POST /events	runtime-proven
Abgeleitete Read-Modelle	tenant-scoped Alerts, Incidents, Jobs, Traces	runtime-proven
Token-Metadaten	tenant-gebundene Scope-Bindungen im Secure-Mux	runtime-proven
Audit-Daten	Token- und Job-Audit-Reads über eigene Endpunkte	runtime-proven
Telemetrie/Logs	App-logcat, Backend-stdout/stderr, korrelierte X-Superheld-*-Header	runtime-proven

Was der Workspace heute ausdrücklich nicht beweist

Die folgenden Privacy- oder Security-Claims dürfen aus dem aktuellen Workspace nicht als heutiger Ist-Stand abgeleitet werden:

• Analyse von Nachrichteninhalten, E-Mails, Dateien, Audio oder Browserdaten im ausgelieferten Android-v1-Pfad
• Upload anonymisierter Feature-Vektoren oder stateless Hash-Lookups als belegte Cloud-Kommunikation
• lokale AES-256-Event- oder Log-Verschlüsselung auf dem Android-Gerät
• feste öffentliche Aufbewahrungsfristen wie 30, 90, 180 oder 365 Tage
• gehostete EU-Datenhaltung, Backup-Policies oder produktive Löschprozesse
• Nutzerkonten, Passwort-Reset, TOTP, Hardware-Keys oder biometrische Entsperrung
• veröffentlichte Support-, Incident-Response- oder Responsible-Disclosure-Reaktionszeiten als operativ belegter Service

Aktuelle Integritäts- und Transportmechanismen

Bereich	Heutiger belegter Stand
Tenant-Isolation	API-Tokens bleiben tenant-gebunden; Secure-Mux erzwingt die Scope-Bindung auf app-relevanten Endpunkten
Device-Identität	Android-App hält ein lokales RSA-Schlüsselpaar im Android Keystore; POST /devices und POST /events nutzen denselben Signaturpfad
Event-Integrität	signierte Event-Submission, Replay-Schutz und tenant-scoped Ableitung von Alerts/Incidents im Backend
Transport	der verifizierte lokale Tablet-Pfad nutzt Loopback-HTTP über adb reverse; daraus folgt keine Aussage über öffentliche Internet- oder Produktionshärtung
Agent-Pinning	die Agent-Runtime kennt optionales SPKI-Pinning über SUPERHELD_CLOUD_PIN_SHA256; ein produktweiter Pinning-Claim bleibt Zielarchitektur

Retention und Persistenz im Ist-Stand

Die aktuelle Runtime beweist keine festen öffentlichen Retention-Garantien. Der belegte Stand ist:

• Security Events, Incidents und weitere Runtime-Daten hängen vom aktiven Backend ab: in-memory, lokale JSON-Dateien oder SQLite
• Token- und Job-Audits folgen demselben konfigurierten Runtime-Backend
• Webhook-DLQ hat im aktuellen Runtime-Vertrag eine 7-Tage-Retention
• ein eigener externer Telemetrie- oder Analytics-Store ist nicht als Produktbestandteil belegt

Details zum heute belastbaren Observability-Schnitt stehen in Telemetrie & Logging.

Zielarchitektur bleibt Zielarchitektur

Andere Seiten in dieser Dokumentation beschreiben bewusst breitere Produktziele. Dazu können unter anderem gehören:

• gehostete Cloud-Umgebungen
• weitergehende Privacy-Programme
• Feature-Vektor- oder Hash-basierte Cloud-Enrichment-Pfade
• lokale Event-Store-Verschlüsselung
• Nutzerkonten, Team-Modelle und zusätzliche Authentifizierungsfaktoren

Solche Aussagen sind nur dann als aktueller Workspace-Stand zu lesen, wenn die Passage den verifizierten Android-plus-Cloud-Pfad explizit nennt.