Sicherheitsarchitektur

Diese Seite beschreibt das Zugriffskontroll- und Schlüsselmanagement-Design von RemCam für Security-Teams, die ein Deployment bewerten. Sie bildet die ausgelieferte Implementierung ab, nicht Absichtserklärungen; wo eine Design-Entscheidung von gängiger Praxis abweicht (etwa Zertifikat-Pinning statt einer CA-Hierarchie), wird die Begründung genannt.

Deployment- und Expositionsmodell

RemCam ist eine einzelne Go-Binärdatei, die als Systemdienst auf dem verwalteten Server installiert wird und unter einem dedizierten Dienstkonto ohne Root-Rechte läuft. Es gibt kein Cloud-Relay, kein Agent-Mesh und keinen Drittanbieter für Fernzugriff im Pfad: sämtlicher Anzeige- und Steuerungsverkehr bleibt zwischen VMS/Operator und dem Server.
Ab Werk bindet die Web-Konsole ausschließlich an 127.0.0.1. Der RTSP-Desktop-Stream und die ONVIF-Schnittstelle sind dauerhaft loopback-only - sie werden vom mitinstallierten VMS-Server konsumiert und sind niemals im Netzwerk exponiert. Die einzige Möglichkeit, die Konsole in einem Netzwerk zu exponieren, ist der explizite Binding-Schalter pro Schnittstelle, stets über HTTPS.
Ausgehende Verbindungen beschränken sich auf den Lizenzdienst (Aktivierung, Deaktivierung, Prüfung auf signierte Updates) über HTTPS.

Zwei-Faktor-Zugriff

Jeder Listener (Loopback und jede gebundene Schnittstelle) ist unabhängig für die Zwei-Faktor-Durchsetzung konfigurierbar. Bei aktivierter 2FA auf einem Listener gilt:

Faktor 1 - Besitz, auf der TLS-Ebene. Der Listener verwendet mutual TLS. Der Client muss während des Handshakes ein registriertes Client-Zertifikat vorweisen; ohne dieses wird der Handshake abgewiesen, bevor irgendein HTTP-Austausch stattfindet - keine Anmeldeseite, keine Fehlerseite, keinerlei Anwendungsoberfläche. Ein nicht authentifizierter Angreifer in diesem Netzwerk sieht eine fehlgeschlagene TLS-Sitzung, mehr nicht.
Faktor 2 - Wissen, auf der Anwendungsebene. Auch eine zertifikatsverifizierte Verbindung benötigt das Kontopasswort, um eine Sitzung aufzubauen. Das Zertifikat identifiziert das Konto; die Anmeldung ist erst nach der Passwortprüfung abgeschlossen.

Bei deaktivierter 2FA genügt ein Faktor allein (Zertifikat oder Passwort) - angemessen für den Loopback-Listener und vertrauenswürdige Managementnetze. Die Konsole verhindert das Aktivieren der 2FA, bevor der Administrator ein funktionierendes Client-Zertifikat besitzt, sodass die Änderung der Durchsetzung den aktivierenden Operator nicht aussperren kann.

Client-Zertifikat-Pinning

RemCam betreibt bewusst keine CA-Hierarchie. Client-Zertifikate werden einzeln gepinnt, nicht über Ketten validiert:

Jedes Zertifikat wird auf dem Server erzeugt (ausschließlich Kryptografie der Go-Standardbibliothek - keine externe CA, kein Zertifikatsdienst, kein Netzwerkaufruf), ist selbstsigniert und wird über seinen SHA-256-Fingerprint registriert, an genau ein Administratorkonto gebunden und pro Gerät beschriftet.
Auf der TLS-Ebene prüft der Verifizierer den Fingerprint des vorgelegten Leaf-Zertifikats gegen die registrierte Menge. Es gibt keinen CA-Vertrauensanker, der gestohlen werden könnte, keine Kette, die fehlvalidiert werden könnte, und das Registrieren eines Zertifikats gewährt genau eine Identität - die Kompromittierung eines Zertifikats erzeugt niemals Autorität über andere.
Zertifikate haben einen expliziten Lebenszyklus: ausgestellt → aktiv, mit den Operationen Suspendieren, Reaktivieren und Widerrufen pro Zertifikat. Das Löschen eines Kontos widerruft alle zugehörigen Zertifikate. Die Vorlage eines widerrufenen Zertifikats wird als Sicherheitssignal behandelt: sie wird beim Handshake abgewiesen und löst ein Alarmereignis an das VMS aus.
Das herunterladbare .p12-Paket enthält nur den privaten Schlüssel des Clients und dessen End-Entity-Zertifikat, geschützt durch ein bei der Erzeugung festgelegtes Passwort. Es enthält niemals ein CA-Zertifikat - der Import kann dem Browser des Operators keinen Vertrauensanker hinzufügen.
Die Zertifikatsnutzung wird nachverfolgt (zuletzt vorgelegt / zuletzt verwendet), und die erste Verwendung eines Ersatzzertifikats widerruft automatisch das Zertifikat, das es ablöst.

Server-TLS

Das Server-Zertifikat wird beim ersten Start lokal erzeugt (Go-Standardbibliothek; keine externe CA- oder ACME-Abhängigkeit - die Konsole muss in vollständig abgeschotteten Netzen funktionieren). Der Installer hinterlegt es in den Betriebssystem- und Browser-Vertrauensspeichern auf dem Server; Operatoren verifizieren es auf ihren eigenen Geräten über den veröffentlichten SHA-256-Fingerprint (Trust-on-First-Use-Endpunkt).
Mindestens TLS 1.2, gewählt wegen der Kompatibilität mit dem in NX Witness eingebetteten Browser.

Speicherung von Zugangsdaten und Schlüsseln

Kontopasswörter werden als bcrypt-Hashes mit Arbeitsfaktor 12 gespeichert. Die Verifizierung ist zeitlich normalisiert: unbekannte Konten werden gegen einen Decoy-Hash verglichen, sodass das Antwortzeitverhalten die Existenz eines Kontos nicht preisgibt. Klartext-Passwörter werden niemals auf Datenträger oder in Protokolle geschrieben.
Geheimnisse im Ruhezustand (Linux): Zugangsdaten (Kontospeicher, RTSP-Zugangsdaten und Ähnliches) liegen in einem verschlüsselten Dateispeicher unter /etc/vmsmc/credentials (Verzeichnismodus 0700, im Besitz des Dienstkontos). Jeder Eintrag ist AES-256-GCM-verschlüsselt; der Schlüssel wird per HKDF-SHA256 aus der Maschinenidentität und einem installationsspezifischen Zufalls-Salt abgeleitet. Zugangsdaten-Dateien sind damit nicht auf eine andere Maschine übertragbar, und ein kopiertes Datenträgerabbild allein liefert ohne die zugehörige Maschinenidentität keine Zugangsdaten.
Geheimnisse im Ruhezustand (Windows): es wird der Plattform-Anmeldeinformationsspeicher über die native Einrichtung des Betriebssystems verwendet.
Private Schlüssel: der TLS-Schlüssel des Servers und das registrierte Client-Zertifikatsmaterial liegen unter /etc/vmsmc (Modus 0700, nur Dienstkonto). Private Client-Schlüssel existieren serverseitig nur transient während der Erzeugung sowie im passwortgeschützten .p12, das dem Administrator übergeben wird.
Sitzungen werden ausschließlich im Arbeitsspeicher gehalten - ein Dienstneustart invalidiert jedes Sitzungstoken.

Sitzungs- und Sperrrichtlinie

Sitzungen haben eine absolute Lebensdauer von 24 Stunden und eine Inaktivitätsobergrenze von 8 Stunden; abgelaufene Token werden bei der ersten Zurückweisung entfernt.
Die Brute-Force-Sperre ist global, nicht pro Quelle oder pro Konto: fehlgeschlagene Anmeldungen aus beliebigen Quellen teilen sich einen eskalierenden Zähler, sodass das Rotieren von Quelladressen oder Benutzernamen den Schwellenwert nicht zurücksetzt. Nach dem letzten Schwellenwert sperrt sich die Konsole dauerhaft, bis der Dienst auf dem Server selbst neu gestartet wird - eine bewusste Eigenschaft im Sinne von „physische Präsenz zur Wiederherstellung".

Audit-Trail

Jede sicherheitsrelevante Aktion - Anmeldung und Fehlversuch, Sperre, Sitzungsbeginn, Übernahme/Freigabe/erzwungene Übernahme der Konsolensteuerung, Konto- und Konfigurationsänderungen, Übergänge im Zertifikatslebenszyklus, Dienststart/-stopp - wird in das lokale Ereignisprotokoll geschrieben und als ONVIF-Ereignisse unter dem Topic-Baum tns1:RemCam publiziert (vollständige Liste in der Bedienungsanleitung). Das VMS kann darauf alarmieren, Lesezeichen setzen und sie gemäß seiner eigenen Aufbewahrungsrichtlinie vorhalten - auf Infrastruktur, die das Security-Team bereits kontrolliert.
Die Verwaltungssitzung selbst ist Beweismaterial: der Desktop des Servers ist ein aufgezeichneter Kamerafeed, sodass die Wirkung jedes Tastendrucks neben den Ereignissen im VMS-Archiv liegt.

Software-Lieferkette

Updates sind Ed25519-signiert. Die Signatur wird gegen einen in der Binärdatei gepinnten Schlüssel verifiziert und innerhalb des privilegierten Anwendungsschritts erneut geprüft - eine nach der Erstverifizierung ausgetauschte Datei (Download-zu-Installation-TOCTOU) wird abgewiesen. Update-Downloads verweigern Klartext-HTTP zu Nicht-Loopback-Hosts.
Das Produkt ist eine einzelne statisch gebaute Go-Binärdatei: keine mitgelieferten Interpreter, keine FFmpeg- oder Transcoder-Subprozesse, kein Laden von Plugins. Privilegierte Operationen (Aktualisierungen der OS-Vertrauensspeicher und Ähnliches) werden an einen einzelnen auditierten Helper mit validierten Argumenten delegiert, statt den Dienst als Root zu betreiben; die systemd-Unit wendet Sandboxing der Kernel-Oberfläche an (geschützte Kernel-Parameter/-Module/-Logs, gesperrte Personality, eingeschränktes Realtime sowie eingeschränkte SUID/SGID-Erzeugung).

Eine Schwachstelle melden

Senden Sie Details an support@remcam.software. Wir bestätigen Meldungen umgehend, und sicherheitskritische Korrekturen werden ausgerollten Konsolen über den signierten Update-Kanal mit einer befristeten Anwendungsfrist signalisiert.