Technische und Organisatorische Maßnahmen (TOM)

Transportverschlüsselung – Web-Zugriff

• Alle Web-Interfaces und API-Zugriffe sind ausschließlich über HTTPS/TLS erreichbar
• Unterstützte Protokolle: TLS 1.2 und TLS 1.3 (ältere Versionen sind deaktiviert)
• SSL-Zertifikate werden automatisch über Let's Encrypt (Certbot) bereitgestellt und erneuert
• HTTP Strict Transport Security (HSTS) ist aktiviert: max-age=63072000; includeSubDomains; preload

Transportverschlüsselung – Video-/Audio-Streams

• Alle Streams werden über das SRT-Protokoll (Secure Reliable Transport) mit AES-128-Verschlüsselung übertragen
• Jeder Konferenzraum erhält eine eigene, 32 Zeichen lange SRT-Passphrase, die automatisch generiert wird
• WebRTC-Streams nutzen die standardmäßige DTLS/SRTP-Verschlüsselung

Verschlüsselung gespeicherter Daten

• Passwörter werden ausschließlich als bcrypt-Hash gespeichert (12 Runden für Admin-Konten) – keine Klartextspeicherung
• Authentifizierungs-Tokens (JWT) werden mit mindestens 64 Zeichen langen Secrets signiert
• Server-Management erfolgt ausschließlich über SSH mit Schlüsselauthentifizierung (Passwort-Login ist deaktiviert)

Physische Sicherheit (Rechenzentrum)

• Server werden ausschließlich in Rechenzentren der Hetzner Online GmbH in Deutschland betrieben (Standorte: Falkenstein, Nürnberg)
• Hetzner-Rechenzentren verfügen über: Zutrittskontrollsysteme mit Chipkarten, biometrische Zugangskontrolle, 24/7-Videoüberwachung, Wachpersonal, Brandmeldeanlage und Löscheinrichtungen
• Kein physischer Zugriff Dritter auf die Server-Hardware möglich

Standort des Betreibers

• Der Betreiber arbeitet an einem gesicherten Arbeitsplatz mit Bildschirmsperre
• Administrative Zugänge werden ausschließlich über verschlüsselte Verbindungen (SSH mit Key-Authentifizierung) aufgebaut

Server-Zugang

• SSH-Zugang ausschließlich per Public-Key-Authentifizierung (Passwort-Login ist serverseitig deaktiviert: PasswordAuthentication no)
• Fail2ban ist aktiv: 5 fehlgeschlagene SSH-Versuche führen zu einer IP-Sperre für 60 Minuten
• UFW-Firewall ist aktiviert mit Deny-All-Default und Whitelist für die benötigten Ports (22, 80, 443, 8189, 8890)
• Root-Login nur per SSH-Key (PermitRootLogin prohibit-password)

Web-Zugang (Admin-Bereich)

• Zweistufige Authentifizierung: Nginx Basic Authentication (htpasswd) als erste Schutzschicht, darüber hinaus JWT-basierte Session-Verwaltung auf Anwendungsebene
• Admin-Passwörter als bcrypt-Hash gespeichert (12 Runden)
• JWT-Ablaufzeit konfigurierbar (Standard: 24 Stunden)
• Sessions werden nach 1 Stunde Inaktivität automatisch beendet
• Secure-Cookie-Flag in Produktion aktiviert, generischer Cookie-Name (kein Express-Standard)

Konferenzraum-Zugang

• Jeder Konferenzraum erfordert individuelle Zugangsdaten (Benutzername + Passwort)
• Raum-Tokens mit 5 Minuten TTL und maximaler Session-Dauer von 10 Stunden
• Raum-Token-Secrets sind mindestens 32 Zeichen lang

Rollenbasiertes Berechtigungskonzept

• Admin: Vollzugriff auf Admin-Panel, Benutzerverwaltung, Konfiguration (separate Admin-Authentifizierung)
• Konferenz-Nutzer: Zugriff nur auf den eigenen Konferenzraum (kein Zugriff auf Konfiguration oder andere Räume)
• Raspberry Pi (Eddi): Nur Stream-Sende-/Empfangsberechtigung für den zugewiesenen Raum

Rate Limiting und Brute-Force-Schutz

Datentrennung zwischen Kunden

• Dedizierter Server: Jeder Hosting-Kunde erhält einen eigenen, isolierten Server mit eigener IP-Adresse und Domain
• Getrennte Datenbanken: Jeder Server hat eine eigene SQLite-Datenbank – kein gemeinsamer Datenspeicher zwischen Kunden
• Getrennte SRT-Passphrasen: Jeder Konferenzraum hat eine individuell generierte 32-Zeichen-Passphrase

Docker-Container-Isolation (Server)

• Anwendungskomponenten laufen in getrennten Docker-Containern: MediaMTX (Streaming), Socket.IO-Server (Anwendungslogik), Nginx (Reverse Proxy)
• Jeder Container hat eingeschränkte Berechtigungen: no-new-privileges: true
• Streaming- und Webserver-Container laufen im Read-Only-Dateisystem
• Dediziertes Docker-Netzwerk (Bridge) mit eigenem Subnetz
• Socket.IO-Server ist nicht direkt aus dem Internet erreichbar (nur intern über Nginx)

Manipulationsschutz am Endgerät (Raspberry Pi)

• Die Raspberry Pis laufen mit einem schreibgeschützten Root-Dateisystem (OverlayFS): Das Betriebssystem ist nicht dauerhaft beschreibbar
• Schutz vor Datenverlust bei Stromausfällen: Da das Dateisystem read-only ist, wird die SD-Karte bei plötzlichem Stromverlust nicht beschädigt
• Schutz vor dauerhafter Kompromittierung: Selbst wenn ein Angreifer temporären Zugriff erlangt, gehen Änderungen nach einem Neustart verloren
• OverlayFS wird für autorisierte Updates (OTA) gezielt temporär deaktiviert und anschließend automatisch wieder aktiviert
• Der OverlayFS-Status ist im Admin-Panel sichtbar und kann von autorisierten Administratoren umgeschaltet werden

Weitergabekontrolle

• Alle externen Verbindungen sind ausschließlich über TLS 1.2/1.3 verschlüsselt
• Umfangreiche Nginx Security Headers sind konfiguriert:
  • X-Frame-Options: DENY – Schutz vor Clickjacking
  • X-Content-Type-Options: nosniff – Schutz vor MIME-Sniffing
  • Content-Security-Policy – Einschränkung auf eigene Ressourcen
  • Referrer-Policy: strict-origin-when-cross-origin
  • Cross-Origin-Opener-Policy: same-origin
  • Cross-Origin-Resource-Policy: same-origin
  • Permissions-Policy: camera=(self), microphone=(self), geolocation=()
  • X-DNS-Prefetch-Control: off
  • Server-Token-Offenlegung deaktiviert (server_tokens off)
• Kamera und Mikrofon sind per Permissions-Policy auf den eigenen Ursprung beschränkt

Eingabekontrolle / Protokollierung

• Audit-Log: Administrative Aktionen werden mit Benutzername, durchführender Person, Details, IP-Adresse und Zeitstempel protokolliert
• Update-Log: Alle Geräte-Updates werden mit Status und Zeitstempel dokumentiert
• Systemlogs: Zentrale Protokollierung auf Anwendungsebene (Log-Level: info)
• Rate-Limit-Monitoring: Übersicht über Rate-Limit-Ereignisse im Admin-Panel mit E-Mail-Benachrichtigung
• Docker-Log-Rotation: Max. 50 MB pro Log-Datei, max. 5 Dateien – automatische Rotation

Infrastruktur

• Hosting in Hetzner-Rechenzentren in Deutschland mit redundanter Strom- und Netzwerkversorgung
• DDoS-Schutz durch Hetzner auf Netzwerkebene
• Regelmäßige Sicherheitsupdates des Betriebssystems und aller Softwarekomponenten

Ressourcenlimits (Docker)

Durch die Ressourcenlimits wird verhindert, dass ein einzelner Container das gesamte System beeinträchtigt.

Wiederherstellung

• Automatisierte Deployment-Skripte ermöglichen eine vollständige Neuinstallation innerhalb weniger Minuten
• Raspberry Pis erstellen vor Firmware-Updates ein automatisches Backup (letzte 10 Versionen werden aufbewahrt)
• Docker-Container starten bei einem Crash automatisch neu (restart: unless-stopped)

Pseudonymisierung

• Konferenz-Zugangsdaten werden ohne Klarnamen vergeben (z. B. „eddi01" statt Name des Kindes)
• Raspberry Pis werden über technische Geräte-IDs identifiziert, nicht über Personennamen
• In technischen Logdaten werden keine Klarnamen betroffener Personen gespeichert

Datenminimierung

• Keine Aufzeichnung: Video- und Audio-Streams werden ausschließlich in Echtzeit übertragen und nicht gespeichert
• Keine Cookies: Die öffentliche Website (avapingu.de) setzt keine Cookies und nutzt kein Tracking
• Keine externen Dienste: Keine Einbindung von Google Fonts, Google Analytics, Facebook Pixel oder vergleichbaren Diensten
• Minimale Datenhaltung: In der Datenbank werden nur die für den Betrieb zwingend erforderlichen Daten gespeichert (Benutzername, Passwort-Hash, Raumzuordnung)

Monitoring und Alarmierung

• Admin-Panel bietet Echtzeitübersicht über verbundene Geräte, aktive Streams und Systemstatus
• E-Mail-Benachrichtigung bei Rate-Limit-Ereignissen und verdächtigen Zugriffsmustern
• Rate-Limit-Übersicht im Admin-Panel mit Möglichkeit zur manuellen IP-Freigabe

Update- und Patch-Management

• Regelmäßige Updates des Betriebssystems und aller eingesetzten Softwarekomponenten
• Automatisiertes Deployment-System für Server-Software-Updates
• Over-the-Air (OTA) Update-System für Raspberry Pis mit automatischem Rollback bei Fehlern
• Versionskontrolle aller Konfigurationen über Git

Organisatorische Maßnahmen

• Zugriff auf Server und administrative Systeme ist auf den Betreiber (Einzelunternehmer) beschränkt
• SSH-Keys sind personengebunden und werden nicht weitergegeben
• Kundenzugangsdaten werden in einer verschlüsselten KeePassXC-Datenbank verwaltet
• Sensible Daten (Passwörter, API-Keys) werden nicht in Versionskontrollsystemen gespeichert

Löschfunktionen

• Benutzer löschen: Vollständige Löschung inkl. aller verknüpften Daten (Geräte, Provisionen, Zugänge)
• Gerät löschen: Entfernung des Raspberry Pi inkl. Raumzuordnung und SRT-Passphrase
• Rate-Limit-Daten: Manuell löschbar über Admin-API