Vom Hersteller-Cloud-System zur kontrollierten eigenen Infrastruktur
Moderne IP-Kameras sind längst mehr als digitale Augen. Hinter dem Objektiv arbeitet ein kleiner Computer mit Prozessor, Betriebssystem und Netzwerkverbindung – teilweise sogar mit eigener KI-Funktionalität. Damit entsteht ein zunächst widersprüchlich wirkendes Problem: Ausgerechnet eine Kamera, die ein Gebäude schützen soll, kann selbst zur digitalen Angriffsfläche werden. Wie sich dieses Risiko begrenzen lässt, hängt nicht nur von der Kamera ab, sondern von der Architektur der gesamten Videoüberwachung.
Bei der Auswahl einer Überwachungskamera stehen meist andere Fragen im Vordergrund: Wie hoch ist die Auflösung? Wie gut ist das Bild bei Nacht? Wie groß ist der Erfassungsbereich? Gibt es eine Bewegungserkennung?
Aus Sicht der IT-Sicherheit kommt jedoch eine weitere Frage hinzu:
Was darf die Kamera eigentlich in unserem Netzwerk?
Diese Frage wird zunehmend wichtig. Denn moderne Videoüberwachung und klassische Computersicherheit lassen sich kaum noch voneinander trennen.
Eine moderne Kamera ist ein Computer
Eine heutige IP-Kamera besitzt typischerweise einen eigenen Prozessor, Arbeitsspeicher, Netzwerkanschluss und ein Betriebssystem. Hinzu kommen Programme und Netzwerkdienste für unterschiedliche Aufgaben.
Dazu können beispielsweise gehören:
- die Übertragung des Videobildes,
- eine Weboberfläche zur Administration,
- Benutzerkonten,
- Zeitsynchronisation,
- Bewegungserkennung,
- Firmware-Updates,
- Smartphone-Apps,
- Fernzugriffe und
- Verbindungen zu Cloud-Diensten.
Technisch betrachtet ist eine solche Kamera deshalb ein vernetzter Computer.
Und wie jeder andere Computer kann auch eine Kamera Sicherheitslücken besitzen.
Veraltete Firmware, schwache Passwörter, unnötig aktivierte Netzwerkdienste oder unsichere Fernzugänge können dazu führen, dass aus einem Sicherheitsgerät selbst ein Sicherheitsrisiko wird.
Dabei geht es nicht nur darum, ob ein Unbefugter möglicherweise ein Kamerabild sehen könnte.
Mindestens ebenso wichtig ist die Frage:
Was passiert, wenn jemand Kontrolle über die Kamera erlangt?
Kann die Kamera dann andere Geräte im Unternehmensnetz erreichen? Kann sie unkontrolliert mit Servern im Internet kommunizieren? Kann sie andere Kameras angreifen?
Damit gelangen wir zu einer grundlegenden Frage der IT-Sicherheit: Wem vertrauen wir eigentlich?
Sicherheit ist eine Frage des Vertrauens
Es wäre zu einfach zu sagen, Cloud-Systeme seien grundsätzlich unsicher und selbst betriebene Systeme grundsätzlich sicher.
Ein professionell betriebener Cloud-Dienst kann sehr gut abgesichert sein. Umgekehrt kann ein schlecht gepflegter eigener Server erhebliche Sicherheitsprobleme verursachen.
Der wesentliche Unterschied liegt deshalb zunächst woanders:
Wer kontrolliert die Infrastruktur und wem muss der Betreiber vertrauen?
Je nach Aufbau einer Videoanlage fällt die Antwort darauf sehr unterschiedlich aus.
Modell 1: Das komfortable Hersteller-Cloud-System
Viele moderne Kameras sind darauf ausgelegt, möglichst einfach eingerichtet zu werden.
Die Kamera wird mit dem Netzwerk verbunden, eine App installiert und ein Benutzerkonto beim Hersteller eingerichtet. Nach kurzer Zeit kann der Benutzer von praktisch überall auf die Kamera zugreifen.
Vereinfacht sieht dieses Modell so aus:
Kamera
│
lokales Netzwerk
│
Internet
│
Hersteller-Cloud
│
Internet
│
App / Benutzer
Das ist bequem und kann für viele Anwendungen vollkommen ausreichend sein.
Der Komfort hat allerdings eine Konsequenz: Die Vertrauenskette wird länger.
Der Betreiber verlässt sich unter anderem auf den Hersteller, dessen Server, dessen Benutzerverwaltung, dessen Updateverfahren und die langfristige Verfügbarkeit des angebotenen Dienstes.
Das macht die Lösung nicht automatisch unsicher.
Es bedeutet aber, dass ein Teil der Kontrolle außerhalb der eigenen Infrastruktur liegt.
Modell 2: Die Aufzeichnung bleibt im eigenen Haus
Eine Alternative besteht darin, die Videodaten auf einem eigenen System zu speichern.
Dafür wird häufig ein sogenannter NVR – Network Video Recorder – verwendet. Vereinfacht gesagt ist ein NVR der zentrale Videorekorder einer IP-Kameraanlage.
Die Kameras übertragen ihre Bilder über das Netzwerk an diesen Server:
Kamera ───── Netzwerk ───── NVR
│
▼
lokaler Speicher
Damit muss der kontinuierliche Videostream für die Aufzeichnung nicht an einen externen Cloud-Dienst übertragen werden.
Ein solcher NVR kann eine fertige Appliance sein. Er kann aber auch auf einem eigenen Linux-Server betrieben werden.
Open-Source-Lösungen wie Frigate, Shinobi oder ZoneMinder ermöglichen einen solchen selbst gehosteten Betrieb.
Dadurch gewinnt der Betreiber Kontrolle zurück.
Gleichzeitig übernimmt er jedoch Verantwortung für Updates, Benutzerkonten, Datensicherung und die Absicherung des Servers.
Mehr Kontrolle bedeutet deshalb immer auch mehr Verantwortung.
Modell 3: Offene Software auf der Kamera
Noch einen Schritt weiter gehen offene Kamera-Firmwares wie OpenIPC.
OpenIPC basiert auf Linux und unterstützt verschiedene Prozessorplattformen, die in IP-Kameras eingesetzt werden.
Der entscheidende Vorteil liegt nicht darin, dass Open-Source-Software automatisch sicher wäre.
Das ist sie nicht.
Auch offene Software kann Fehler und Sicherheitslücken enthalten.
Der Unterschied liegt vielmehr in der Transparenz und Konfigurierbarkeit.
Bei offener Software kann grundsätzlich nachvollzogen werden, welche Software verwendet wird. Funktionen können angepasst, unnötige Bestandteile entfernt und eigene Sicherheitsmechanismen integriert werden.
Das ist insbesondere bei kleinen, funktional ausgerichteten Linux-Systemen interessant: Es muss nicht zwangsläufig jede Funktion vorhanden sein, die ein Hersteller für möglichst viele unterschiedliche Kunden vorgesehen hat.
Für einen bestimmten Einsatzzweck kann das System gezielter konfiguriert werden.
Open Source ist deshalb kein Sicherheitsversprechen. Es schafft aber Möglichkeiten zur Kontrolle, die bei vollständig geschlossener Software häufig nicht vorhanden sind.
Auch Linux bedeutet nicht vollständige Kontrolle
An dieser Stelle ist allerdings eine wichtige Einschränkung notwendig.
Eine Kamera besteht nicht nur aus dem sichtbaren Betriebssystem.
Unterhalb von Linux können weitere Bestandteile arbeiten, beispielsweise Firmware für einzelne Hardwarekomponenten, Bootloader, Gerätetreiber, Bildprozessoren oder andere Bestandteile des verwendeten Chips.
Nicht jede dieser Komponenten muss offen einsehbar sein.
Bei klassischen PCs ist dieses Problem beispielsweise durch zusätzliche Systemkomponenten wie die Intel Management Engine bekannt. Eine typische IP-Kamera besitzt nicht zwangsläufig ein direkt vergleichbares System.
Das grundsätzliche Problem bleibt jedoch bestehen:
Auch bei einer Kamera mit offenem Linux müssen nicht automatisch sämtliche Komponenten der Hardware offen und vollständig kontrollierbar sein.
Und daraus ergibt sich eine interessante Konsequenz.
Vielleicht müssen wir der Kamera überhaupt nicht vollständig vertrauen.
Modell 4: Die Kamera bekommt ihren eigenen Bereich
Statt darauf zu hoffen, dass eine Kamera niemals kompromittiert wird, kann man das Netzwerk so planen, dass eine kompromittierte Kamera möglichst wenig erreichen kann.
Dafür werden Kameras vom normalen Unternehmensnetz getrennt.
Vereinfacht:
Kamera 1 ─┐
Kamera 2 ─┼── eigenes Kamera-Netz
Kamera 3 ─┘
│
Firewall
│
▼
NVR
Eine Firewall kontrolliert, welche Verbindungen dieses Kamera-Netz verlassen dürfen.
Das Büro-Netz, Dateiserver oder andere Unternehmenssysteme bleiben für die Kameras gesperrt.
Das Prinzip dahinter ist einfach:
Eine Kamera erhält nur die Netzwerkverbindungen, die sie für ihre Aufgabe tatsächlich benötigt.
Beispielsweise:
Kamera → NVR erlaubt
Kamera → lokaler Zeitserver erlaubt
Kamera → Internet gesperrt
Kamera → Büro-Netz gesperrt
Kamera → Server-Netz gesperrt
Damit wird eine Kamera nicht automatisch sicher.
Aber die Folgen einer möglichen Kompromittierung werden begrenzt.
Warum sollten Kameras miteinander sprechen?
Bei mehreren Kameras stellt sich noch eine weitere interessante Frage.
Muss Kamera 1 überhaupt direkt mit Kamera 2 kommunizieren können?
In vielen Anlagen lautet die Antwort: nein.
Geeignete Netzwerk-Switches können deshalb so konfiguriert werden, dass einzelne Kameras zwar den NVR erreichen, nicht jedoch unmittelbar andere Kameras.
Kamera 1 ──X── Kamera 2
Kamera 1 ──X── Kamera 3
Kamera 2 ──X── Kamera 3
Kamera 1 ─────► NVR
Kamera 2 ─────► NVR
Kamera 3 ─────► NVR
Wird eine Kamera kompromittiert, kann sie dadurch nicht ohne Weiteres die nächste Kamera angreifen.
Das ist ein gutes Beispiel für ein grundlegendes Sicherheitsprinzip: Ein Gerät erhält nur die Rechte und Verbindungen, die es wirklich benötigt.
Modell 5: Die Sicherheitsgrenze wird aus der Kamera herausgenommen
Eine Linux-Kamera kann eine eigene Firewall besitzen. Auch ein verschlüsseltes VPN wie WireGuard kann direkt auf geeigneter Kamerasoftware betrieben werden.
Das ist grundsätzlich sinnvoll.
Es besitzt allerdings eine Schwäche.
Wenn ein Angreifer vollständige Kontrolle über die Kamera erlangt, könnte er möglicherweise auch deren Firewall, Routing oder VPN-Konfiguration verändern.
Das zu schützende Gerät kontrolliert dann gleichzeitig einen Teil seiner eigenen Sicherheitsgrenze.
Bei höheren Sicherheitsanforderungen kann man deshalb einen anderen Weg gehen.
Zwischen Kamera und restlichem Netzwerk wird ein separater Security-Gateway eingesetzt.
Dabei kann es sich beispielsweise um einen kleinen, besonders schlank eingerichteten Linux-Rechner mit zwei Netzwerkanschlüssen handeln.
Kamera
│
│
▼
┌────────────────────┐
│ Security-Gateway │
│ │
│ Firewall │
│ Netzwerkregeln │
│ VPN │
│ Protokollierung │
└─────────┬──────────┘
│
▼
weiteres Netz
Nun befindet sich die entscheidende Sicherheitsgrenze nicht mehr innerhalb der Kamera.
Das ist ein wichtiger Unterschied.
Selbst wenn die Kamera ihre eigene Netzwerkkonfiguration verändert, kontrolliert sie damit nicht automatisch den separaten Security-Gateway.
Ihr Netzwerkkabel führt nur zu diesem System.
Was bedeutet das im Ernstfall?
Nehmen wir bewusst den ungünstigen Fall an:
Die Kamera wurde vollständig kompromittiert.
Bei einem herkömmlichen Netzwerk könnte sie nun möglicherweise versuchen, andere Geräte oder externe Server zu erreichen.
Beim getrennten Sicherheitsmodell stößt sie dagegen auf eine unabhängige Grenze:
POTENZIELL NICHT VERTRAUENSWÜRDIG
Kamera
│
▼
════════ VERTRAUENSGRENZE ════════
Security-Gateway
/ Firewall
│
▼
erlaubte Systeme
Die Kamera kann versuchen, eine beliebige Internetadresse zu kontaktieren.
Der Gateway verwirft die Verbindung.
Sie kann versuchen, einen Bürocomputer zu erreichen.
Der Gateway verwirft die Verbindung.
Sie kann ihre eigene Firewall deaktivieren.
Die externe Firewall bleibt davon unberührt.
Das ist der eigentliche Kern dieses Sicherheitsmodells:
Nicht die Kamera entscheidet, mit wem sie kommunizieren darf. Das Netzwerk entscheidet es.
Modell 6: Entfernte Standorte über einen sicheren Tunnel anbinden
Besonders interessant wird dieses Prinzip bei räumlich entfernten Objekten.
Die Kameras befinden sich beispielsweise auf einem Firmengelände, während NVR oder Leitstelle an einem anderen Standort betrieben werden.
Dann kann der Security-Gateway einen verschlüsselten WireGuard-VPN-Tunnel aufbauen.
KUNDENOBJEKT
Kamera 1 ─┐
Kamera 2 ─┼── isoliertes Netz
Kamera 3 ─┘
│
▼
Security-Gateway
│
WireGuard-VPN
│
▼
════════════ INTERNET ════════════
│
▼
eigener NVR
eigene Leitstelle
Die Kameras selbst benötigen dabei keinen freien Internetzugang.
Nur der Gateway kommuniziert nach außen.
Und auch innerhalb des VPN muss nicht automatisch jede Verbindung erlaubt werden. Der Gateway kann weiterhin festlegen, welche Systeme und Dienste erreichbar sind.
Fällt der VPN-Tunnel aus, kann die Anlage zudem nach dem Prinzip Fail Closed aufgebaut werden:
Es gibt dann nicht automatisch einen weniger geschützten Ersatzweg über das offene Internet.
Modell 7: Die Videoanalyse bleibt ebenfalls lokal
Mit einem eigenen NVR eröffnet sich eine weitere Möglichkeit: Auch künstliche Intelligenz kann innerhalb der eigenen Infrastruktur betrieben werden.
Ein Beispiel dafür ist Frigate.
Frigate verbindet Videoaufzeichnung mit lokaler Objekterkennung. Je nach eingesetzter Hardware können Videobilder automatisch auf bestimmte Objekte untersucht werden.
Dazu gehören beispielsweise:
- Personen,
- Fahrzeuge,
- Tiere oder
- Bewegungen innerhalb definierter Bereiche.
Der entscheidende Punkt:
Das Videomaterial muss für diese Analyse nicht grundsätzlich an einen externen KI-Anbieter übertragen werden.
Die Verarbeitung kann auf eigener Hardware stattfinden.
Kamera
│
▼
Security-Gateway
│
▼
eigener NVR
│
▼
lokale KI
│
▼
Ereignis / Alarm
Damit können sowohl die Aufzeichnung als auch wesentliche Teile der automatischen Analyse innerhalb der eigenen Infrastruktur bleiben.
Eine erkannte Person ist noch kein Sicherheitsvorfall
Dabei sollte man die Möglichkeiten von KI realistisch betrachten.
Eine KI kann beispielsweise feststellen:
„Auf diesem Bild befindet sich eine Person.“
Das bedeutet noch nicht:
„Hier findet gerade ein Einbruch statt.“
Interessant wird Videoanalyse deshalb vor allem durch die Verbindung verschiedener Informationen.
Beispielsweise:
Person erkannt
+
gesperrter Bereich
+
02:37 Uhr
+
keine geplante Tätigkeit
↓
mögliches Sicherheitsereignis
Eine lokale KI kann damit große Mengen an Videodaten vorsortieren und auffällige Ereignisse hervorheben.
Die Bewertung, ob tatsächlich eine Gefahr vorliegt und welche Reaktion angemessen ist, bleibt davon zu unterscheiden.
Gerade im professionellen Sicherheitsdienst kann diese Aufgabenteilung sinnvoll sein: Technik erkennt und filtert – der Mensch bewertet und entscheidet.
Auch Uhrzeit und Updates gehören zur Sicherheit
Ein isoliertes Kameranetz bedeutet nicht, dass Kameras völlig ohne weitere Infrastruktur betrieben werden sollten.
Ein scheinbar nebensächliches Beispiel ist die Uhrzeit.
Wenn Kamera 1 einen Vorfall um 02:37 Uhr und Kamera 2 denselben Vorgang um 02:42 Uhr aufzeichnet, erschwert dies die spätere Rekonstruktion.
Deshalb kann ein eigener lokaler Zeitserver sinnvoll sein.
Auch Updates dürfen nicht vergessen werden.
Eine Kamera vom Internet zu trennen und anschließend jahrelang keine Sicherheitsupdates mehr einzuspielen, wäre keine gute Sicherheitsstrategie.
Stattdessen können Updates kontrolliert beschafft, geprüft und anschließend innerhalb der geschützten Umgebung eingespielt werden.
Isolation ersetzt Wartung nicht.
Mehrere Schutzschichten statt einer vermeintlich perfekten Kamera
Damit kommen wir zum eigentlichen Prinzip hinter der gesamten Architektur.
Keine einzelne Maßnahme schafft vollständige Sicherheit.
Open Source ermöglicht Transparenz und Konfigurierbarkeit, verhindert aber keine Softwarefehler.
Eine Firewall begrenzt Netzwerkkommunikation, verhindert aber nicht die Kompromittierung der Kamera selbst.
WireGuard schützt den Übertragungsweg, macht aber einen kompromittierten Endpunkt nicht wieder vertrauenswürdig.
Ein eigener NVR schafft Kontrolle über die Speicherung, muss dafür selbst abgesichert werden.
Lokale KI reduziert die Abhängigkeit von externen Analyseplattformen, ist aber wiederum ein zusätzliches Softwaresystem.
Deshalb werden mehrere voneinander unabhängige Schutzschichten kombiniert.
Dieses Prinzip wird in der IT-Sicherheit als Defense in Depth – Verteidigung in der Tiefe – bezeichnet.
Fällt eine Schutzschicht aus, soll eine andere den möglichen Schaden weiterhin begrenzen.
Vom einfachen Cloud-System zur eigenen Sicherheitsarchitektur
Die verschiedenen Ansätze lassen sich vereinfacht gegenüberstellen:
HERSTELLER-CLOUD
Kamera
↓
Cloud des Herstellers
↓
App
LOKALE AUFZEICHNUNG
Kamera
↓
eigener NVR
↓
eigener Speicher
GETRENNTES KAMERANETZ
Kameras
↓
isoliertes Netz
↓
Firewall
↓
eigener NVR
EXTERNE SICHERHEITSGRENZE
Kameras
↓
isoliertes Netz
↓
Security-Gateway
↓
eigener NVR
ENTFERNTER STANDORT
Kameras
↓
Security-Gateway
↓
WireGuard
↓
eigene Infrastruktur
LOKALE DATENVERARBEITUNG
Kameras
↓
Security-Gateway
↓
eigener NVR
↓
lokale KI
↓
eigener Speicher
↓
Leitstelle
Das ist ausdrücklich keine Rangliste, bei der nur die letzte Variante als sicher gelten kann.
Nicht jede Anwendung benötigt dieselbe technische Komplexität.
Eine einzelne Kamera in einem wenig sensiblen Bereich stellt andere Anforderungen als die Überwachung eines Industrieobjekts, eines Rechenzentrums oder eines besonders geschützten Geländes.
Entscheidend ist vielmehr, dass die Architektur bewusst gewählt wird.
Die entscheidende Frage lautet nicht: Können wir der Kamera vertrauen?
Bei klassischen Sicherheitsüberlegungen versucht man häufig, ein möglichst vertrauenswürdiges Produkt auszuwählen.
Das bleibt wichtig.
Für vernetzte Sicherheitstechnik reicht dieser Gedanke jedoch nicht mehr aus.
Eine robustere Frage lautet:
Wie bauen wir die Videoüberwachung so auf, dass wir der Kamera nicht bedingungslos vertrauen müssen?
Eine Kamera kann Open-Source-Firmware verwenden und trotzdem isoliert werden.
Eine Kamera kann proprietäre Firmware besitzen und trotzdem keinen freien Internetzugang erhalten.
Eine Kamera kann kompromittiert werden und trotzdem vom Büro- und Servernetz getrennt bleiben.
Und eine Kamera kann ihre eigene Netzwerkkonfiguration verändern, ohne dadurch die Firewall eines physisch getrennten Security-Gateways kontrollieren zu können.
Darin liegt der Unterschied zwischen einer einzelnen Sicherheitsfunktion und einer durchdachten Sicherheitsarchitektur.
Die Sicherheit einer Videoüberwachungsanlage sollte deshalb nicht davon abhängen, dass jede Kamera und jede einzelne Firmware-Komponente uneingeschränkt vertrauenswürdig ist. Ein gutes Sicherheitskonzept begrenzt vielmehr systematisch, was ein einzelnes Gerät überhaupt erreichen kann.
Moderne Videoüberwachung beginnt damit zwar weiterhin am Objektiv – sie endet dort aber längst nicht mehr.