Sicherheit & Datenschutz

T.E.O. wurde mit einem Security-by-Design-Ansatz entwickelt. Sicherheitsrelevante Funktionen sind so implementiert, dass sensible Daten ausschliesslich in kontrollierten, serverseitigen Prozessen verarbeitet werden. Zwischen Client- und Server-Kontext besteht eine strikte Trennung; privilegierte Operationen laufen über separate, geschützte Server-Funktionen.

• Konto-Daten: E-Mail, Name, Profilbild, Account-Typ.
• Projekt-Inhalte: Canvas-Topologien, Geräte- und Netzwerkangaben (IP, Netzmaske, Gateway, MAC, Modbus-/Device-Adressen), hochgeladene Designs/Mockups und Konfigurationsdateien, Kommentare und Feedback.
• Scan-Daten: Kamerabilder für MAC-/RF-Erkennung werden lokal im Browser verarbeitet (OCR/DataMatrix) und nur auf ausdrückliche Aktion gespeichert.
• Technische Daten: Session-Tokens, Auth-Events, Fehler-Telemetrie (anonymisiert).
• Keine Zahlungsdaten, keine besonderen Personendaten (Gesundheit, Religion etc.).

Ausgewählte sensible Netzwerkdaten (z. B. IP-Adressen, MAC-Adressen, Netzmasken, Gateways und gerätespezifische Identifikatoren) werden serverseitig verschlüsselt gespeichert.

• Es werden moderne, etablierte kryptographische Verfahren eingesetzt (AES-256-GCM).
• Ver- und Entschlüsselung erfolgen ausschliesslich in geschützten Server-Funktionen.
• Kryptographische Schlüssel verlassen den Server zu keinem Zeitpunkt.
• Der Klartext dieser Daten ist nur im autorisierten Anwendungskontext für berechtigte Benutzer verfügbar.
• Zusätzlich: AES-256 at rest auf Datenbank- und Storage-Ebene durch die Cloud-Plattform.

Der Datenzugriff erfolgt über PostgreSQL Row-Level Security (RLS), ergänzt um rollenbasierte Policies.

• Projekte sind ausschliesslich für Eigentümer und berechtigte Mitglieder sichtbar.
• Zugriffsrechte werden über projektbezogene Mitgliedschaften (Viewer / Editor) gesteuert und sind jederzeit widerrufbar.
• Geteilte Inhalte erfordern explizite Freigaben (z. B. Share-Tokens mit Ablaufdatum, optional passwortgeschützt).
• Admin-Rollen liegen in einer separaten Tabelle (keine Profil-Felder → keine Privilege-Escalation).

Für die Benutzerverwaltung wird Supabase Auth verwendet.

• Passwörter werden ausschliesslich als kryptographische Hashes (bcrypt) gespeichert.
• E-Mail-Verifikation ist erforderlich, bevor ein Zugriff auf produktive Daten erfolgen kann.
• Sitzungen werden über sichere Token-Mechanismen verwaltet (Auto-Refresh, sicheres Storage).
• Google OAuth steht als zweite Login-Option zur Verfügung.
• Self-Service-Konto-Löschung im Profil (entfernt Projekte, Uploads, Rollen und Auth-User).
• Leaked-Password-Check (HIBP) aktiv: Passwörter werden bei Registrierung und Änderung gegen die Have-I-Been-Pwned-Datenbank geprüft.
• Zwei-Faktor-Authentifizierung (TOTP) optional aktivierbar im Profil — Code aus einer Authenticator-App (Google Authenticator, 1Password, Authy …) wird zusätzlich zum Passwort abgefragt.

• Die gesamte Kommunikation mit der Anwendung läuft über HTTPS/TLS.
• Unsichere HTTP-Zugriffe werden automatisch auf HTTPS umgeleitet.

• Feedback-Bilder und sensible Uploads liegen in privaten Storage-Buckets.
• Der Zugriff erfolgt ausschliesslich über zeitlich befristete, signierte URLs.
• Direkter, unautorisierter Zugriff ist nicht möglich.
• Avatare und öffentliche Katalog-Bilder sind bewusst öffentlich (kein PII).

• Der Kamerazugriff erfordert eine explizite Browser-Freigabe und lässt sich jederzeit widerrufen.
• OCR- und DataMatrix-Erkennung laufen vollständig lokal im Browser (WASM); es findet kein Upload von Live-Kamerabildern statt.
• Nur bewusst gespeicherte Aufnahmen landen im privaten Storage-Bucket.

• KI-gestützte Recherche-Funktionen werden nur auf ausdrückliche Nutzeraktion ausgeführt.
• Übermittelt wird ausschliesslich der Inhalt der jeweiligen Anfrage (z. B. Artikelnummer, Suchtext) — keine Konto- oder Projektdatenbank.
• API-Schlüssel für Drittdienste liegen ausschliesslich serverseitig und werden nie an den Browser ausgeliefert.

• Verpflichtender Freigabeprozess (Approval Workflow) vor Zugriff auf produktive Daten.
• Account-Typ „Siemens intern" wird erst nach verifizierter E-Mail-Domain gesetzt (keine Selbstdeklaration).
• Getrennte Serverfunktionen für privilegierte Operationen.
• Strikte Trennung zwischen Client- und Server-Kontext (Service-Role-Keys verlassen den Server nicht).
• Anwendungs-Fehler werden anonymisiert erfasst (keine Inhalte, keine Tokens).
• Audit-Log: sicherheitsrelevante Änderungen an Projekten, Feedback, Rollen und Profilen werden mit Zeitstempel, Akteur und Diff protokolliert. Grosse Nutzdaten werden automatisch gekürzt (Datenminimierung). Einsicht nur durch Administratoren.
• Abhängigkeiten werden regelmässig auf bekannte Schwachstellen geprüft und bei Bedarf auf gepatchte Versionen fixiert.

• Automatische tägliche DB-Backups durch die Cloud-Plattform (Point-in-Time-Recovery innerhalb der Aufbewahrungsfrist).
• Gelöschte Projekte landen zuerst im Papierkorb (Soft-Delete) und können wiederhergestellt werden.

• Hosting in der EU (Frankfurt). Auftragsverarbeiter: Supabase/Lovable Cloud, Cloudflare (CDN), Google (OAuth).
• Verarbeitungsverzeichnis und Rechtsgrundlagen siehe Datenschutzerklärung.
• Recht auf Auskunft, Berichtigung, Löschung und Datenportabilität: per E-Mail an die unten genannte Adresse.

Sicherheitslücken können verantwortungsvoll gemeldet werden. Bitte nicht öffentlich publizieren, sondern eine E-Mail mit Beschreibung und (wenn möglich) Proof-of-Concept an bojan@trajkovic.ch senden. Maschinenlesbare Kontaktinformationen nach RFC 9116 unter /.well-known/security.txt.

Für gemeldete Schwachstellen gilt ein Coordinated-Vulnerability-Disclosure-Prozess (CVD) mit verbindlichen Reaktionszeiten:

• Eingangsbestätigung: innerhalb von 72 Stunden
• Triage & Erstbewertung (CVSS 3.1): innerhalb von 7 Werktagen
• Behebungsfristen ab Triage: Critical innerhalb von 7 Tagen, High innerhalb von 30 Tagen, Medium innerhalb von 90 Tagen, Low nach Roadmap
• Koordinierte Veröffentlichung: nach Behebung, in Abstimmung mit der meldenden Person

Safe Harbour: Wer eine Schwachstelle in gutem Glauben und regelkonform meldet, muss keine rechtlichen Schritte befürchten. Regelkonform bedeutet: keine Datenexfiltration, keine Beeinträchtigung der Verfügbarkeit, kein Zugriff auf Daten Dritter, keine Weitergabe an Dritte vor der koordinierten Veröffentlichung und Nutzung ausschliesslich eigener Testkonten.

CVE-Vergabe: Sollte TEO-Code künftig als Open Source veröffentlicht werden, erfolgt die CVE-Zuweisung über die GitHub Security Advisories (GitHub als CNA).

TEO wird als kontinuierlich aktualisierter Cloud-Dienst betrieben. Sicherheits-Updates werden ohne separates Versions-Rollout eingespielt und gelten für alle Nutzer, solange der Dienst betrieben wird.

Für den Fall, dass künftig eigenständig auslieferbare Komponenten (z. B. Plugin, Desktop-Build oder SDK) bereitgestellt werden, gilt ein Support-Zeitraum von mindestens 5 Jahren ab dem Datum der jeweiligen Release-Version. Eine Einstellung des Dienstes wird mindestens 6 Monate vorher angekündigt.

Software-Stückliste (SBOM): Für jede Version wird eine SBOM im CycloneDX-Format erzeugt. Sie kann für berechtigte Anfragen (z. B. Kunden-Security-Reviews) über den Security-Kontakt angefordert werden.

Bojan Trajkovic · bojan@trajkovic.ch