Du cloud du fabricant à une infrastructure maîtrisée
Les caméras IP modernes sont bien plus que des yeux numériques. Derrière l’objectif se trouve un petit ordinateur doté d’un processeur, d’un système d’exploitation et d’une connexion réseau – parfois même de fonctions d’intelligence artificielle. Il en résulte un paradoxe apparent : une caméra destinée à protéger un bâtiment peut elle-même devenir une surface d’attaque numérique. La réduction de ce risque ne dépend pas uniquement de la caméra, mais de l’architecture de l’ensemble du système de vidéosurveillance.
Lors du choix d’une caméra de surveillance, d’autres questions sont généralement prioritaires : quelle est sa résolution ? Quelle est la qualité de l’image de nuit ? Quelle zone peut-elle couvrir ? Dispose-t-elle d’une détection de mouvement ?
Du point de vue de la sécurité informatique, une autre question doit cependant être posée :
Que peut réellement faire la caméra sur notre réseau ?
Cette question devient de plus en plus importante. La vidéosurveillance moderne et la sécurité informatique classique ne peuvent plus être considérées comme deux domaines totalement distincts.
Une caméra moderne est un ordinateur
Une caméra IP moderne dispose généralement de son propre processeur, de mémoire, d’une interface réseau et d’un système d’exploitation. Elle exécute également différents logiciels et services réseau.
Il peut notamment s’agir de :
- la transmission des flux vidéo,
- une interface Web d’administration,
- comptes utilisateurs,
- la synchronisation de l’heure,
- la détection de mouvement,
- mises à jour du micrologiciel,
- applications pour smartphones,
- accès à distance et
- connexions à des services cloud.
Du point de vue de la sécurité informatique, une telle caméra est donc un ordinateur connecté au réseau.
Et comme tout autre ordinateur, une caméra peut présenter des vulnérabilités.
Un micrologiciel obsolète, des mots de passe faibles, des services réseau inutiles ou des accès à distance insuffisamment sécurisés peuvent transformer un équipement destiné à assurer la sécurité en un risque de sécurité.
Le problème ne se limite pas à la possibilité qu’une personne non autorisée puisse consulter les images d’une caméra.
Une question tout aussi importante est la suivante :
Que se passe-t-il si quelqu’un prend le contrôle de la caméra ?
La caméra pourrait-elle alors accéder à d’autres appareils du réseau de l’entreprise ? Pourrait-elle communiquer librement avec des serveurs sur Internet ? Pourrait-elle attaquer d’autres caméras ?
Nous arrivons ainsi à l’une des questions fondamentales de la sécurité informatique : à quoi faisons-nous réellement confiance ?
La sécurité est une question de confiance
Il serait trop simple d’affirmer que les systèmes cloud sont par principe peu sûrs, tandis que les systèmes exploités en interne seraient automatiquement sécurisés.
Un service cloud exploité de manière professionnelle peut être très bien protégé. À l’inverse, un serveur privé mal entretenu peut présenter des risques considérables.
La différence essentielle se situe donc ailleurs :
Qui contrôle l’infrastructure et à qui l’exploitant doit-il faire confiance ?
Selon l’architecture du système de vidéosurveillance, la réponse peut être très différente.
Modèle 1 : le cloud pratique du fabricant
De nombreuses caméras modernes sont conçues pour être installées aussi simplement que possible.
La caméra est connectée au réseau, une application est installée et un compte est créé auprès du fabricant. Peu de temps après, l’utilisateur peut accéder à sa caméra depuis pratiquement n’importe où.
De manière simplifiée, l’architecture se présente ainsi :
Caméra
│
réseau local
│
Internet
│
cloud du fabricant
│
Internet
│
application / utilisateur
Cette solution est pratique et peut parfaitement convenir à de nombreuses applications.
Cette simplicité a toutefois une conséquence : la chaîne de confiance s’allonge.
L’exploitant dépend notamment du fabricant, de ses serveurs, de sa gestion des comptes utilisateurs, de ses procédures de mise à jour et de la disponibilité à long terme de son service.
Cela ne signifie pas automatiquement que la solution est peu sûre.
Cela signifie en revanche qu’une partie du contrôle de la sécurité se trouve en dehors de l’infrastructure de l’exploitant.
Modèle 2 : conserver les enregistrements dans sa propre infrastructure
Une autre possibilité consiste à stocker les données vidéo sur un système contrôlé par l’exploitant.
On utilise souvent pour cela un NVR – Network Video Recorder –. En termes simples, un NVR constitue l’enregistreur vidéo central d’un système de caméras IP.
Les caméras lui transmettent leurs flux vidéo par le réseau :
Caméra ───── réseau ───── NVR
│
▼
stockage local
Le flux vidéo continu n’a donc pas besoin d’être transmis à un service cloud externe pour être enregistré.
Un NVR peut être un appareil dédié, mais il peut également fonctionner sur un serveur Linux exploité en interne.
Des solutions open source telles que Frigate, Shinobi ou ZoneMinder permettent ce type d’hébergement autonome.
L’exploitant gagne ainsi en contrôle.
En contrepartie, il devient responsable des mises à jour, des comptes utilisateurs, des sauvegardes et de la sécurisation du serveur.
Davantage de contrôle implique donc également davantage de responsabilités.
Modèle 3 : des logiciels ouverts sur la caméra
Les micrologiciels ouverts pour caméras, tels que OpenIPC, vont encore plus loin.
OpenIPC repose sur Linux et prend en charge différentes plateformes de processeurs utilisées dans les caméras IP.
Son principal avantage ne réside pas dans le fait qu’un logiciel open source serait automatiquement sécurisé.
Ce n’est pas le cas.
Un logiciel ouvert peut lui aussi contenir des erreurs et des vulnérabilités.
La différence réside surtout dans la transparence et les possibilités de configuration.
Avec un logiciel ouvert, il est en principe possible d’examiner les composants utilisés. Des fonctions peuvent être adaptées, des éléments inutiles supprimés et des mécanismes de sécurité supplémentaires intégrés.
Cette approche est particulièrement intéressante pour de petits systèmes Linux conçus pour une fonction précise : ils n’ont pas nécessairement besoin de toutes les fonctionnalités qu’un fabricant peut intégrer afin de répondre aux besoins du plus grand nombre de clients possible.
Le système peut ainsi être configuré plus précisément en fonction de son utilisation réelle.
L’open source n’est donc pas une garantie de sécurité. Il offre cependant des possibilités de transparence et de contrôle qui sont souvent absentes des logiciels entièrement fermés.
Même Linux ne signifie pas un contrôle total
Une précision importante s’impose cependant.
Une caméra ne se limite pas à son système d’exploitation visible.
Sous Linux peuvent fonctionner d’autres composants, par exemple des micrologiciels destinés à certains éléments matériels, des chargeurs d’amorçage, des pilotes, des processeurs d’image ou d’autres composants de la puce utilisée.
Tous ces éléments ne sont pas nécessairement ouverts et accessibles à l’analyse.
Sur les ordinateurs classiques, cette problématique est notamment connue à travers des composants supplémentaires tels que l’Intel Management Engine. Une caméra IP classique ne possède pas nécessairement un système directement comparable.
Le problème fondamental demeure néanmoins :
Même lorsqu’une caméra fonctionne sous un système Linux ouvert, tous ses composants matériels ne sont pas automatiquement ouverts et entièrement contrôlables.
Cela conduit à une conclusion intéressante.
Peut-être n’est-il tout simplement pas nécessaire de faire entièrement confiance à la caméra.
Modèle 4 : attribuer aux caméras leur propre zone réseau
Au lieu de supposer qu’une caméra ne sera jamais compromise, le réseau peut être conçu de manière à limiter autant que possible les possibilités d’action d’une caméra compromise.
Pour cela, les caméras sont séparées du réseau informatique normal de l’entreprise.
De manière simplifiée :
Caméra 1 ─┐
Caméra 2 ─┼── réseau dédié aux caméras
Caméra 3 ─┘
│
pare-feu
│
▼
NVR
Un pare-feu contrôle les connexions autorisées à quitter le réseau des caméras.
Le réseau bureautique, les serveurs de fichiers et les autres systèmes de l’entreprise restent inaccessibles aux caméras.
Le principe est simple :
Une caméra ne reçoit que les connexions réseau dont elle a réellement besoin pour accomplir sa tâche.
Par exemple :
Caméra → NVR AUTORISÉ
Caméra → serveur de temps local AUTORISÉ
Caméra → Internet BLOQUÉ
Caméra → réseau bureautique BLOQUÉ
Caméra → réseau des serveurs BLOQUÉ
Cela ne rend pas automatiquement la caméra sûre.
Mais cela limite les conséquences d’une éventuelle compromission.
Pourquoi les caméras devraient-elles communiquer entre elles ?
Lorsque plusieurs caméras sont utilisées, une autre question intéressante se pose.
La caméra 1 doit-elle réellement pouvoir communiquer directement avec la caméra 2 ?
Dans de nombreuses installations, la réponse est non.
Des commutateurs réseau adaptés peuvent donc être configurés de manière à permettre à chaque caméra d’accéder au NVR sans pour autant pouvoir communiquer directement avec les autres caméras.
Caméra 1 ──X── Caméra 2
Caméra 1 ──X── Caméra 3
Caméra 2 ──X── Caméra 3
Caméra 1 ─────► NVR
Caméra 2 ─────► NVR
Caméra 3 ─────► NVR
Si une caméra est compromise, il devient ainsi plus difficile pour un attaquant de passer directement à une autre caméra.
C’est un bon exemple d’un principe fondamental de sécurité : un appareil ne doit disposer que des droits et des connexions dont il a réellement besoin.
Modèle 5 : déplacer la frontière de sécurité hors de la caméra
Une caméra fonctionnant sous Linux peut disposer de son propre pare-feu. Un VPN sécurisé tel que WireGuard peut également être exécuté directement sur un micrologiciel de caméra adapté.
Cette solution peut être utile.
Elle présente cependant une faiblesse fondamentale.
Si un attaquant prend entièrement le contrôle de la caméra, il pourrait éventuellement modifier également son pare-feu, son routage ou sa configuration VPN.
L’appareil que l’on cherche à protéger contrôlerait alors lui-même une partie de sa propre frontière de sécurité.
Pour des systèmes présentant des exigences de sécurité plus élevées, une autre approche est donc possible.
Une passerelle de sécurité distincte est placée entre la caméra et le reste du réseau.
Il peut s’agir, par exemple, d’un petit ordinateur Linux spécialement renforcé et équipé de deux interfaces réseau.
Caméra
│
│
▼
┌────────────────────┐
│ Passerelle de │
│ sécurité │
│ │
│ Pare-feu │
│ Règles réseau │
│ VPN │
│ Journalisation │
└─────────┬──────────┘
│
▼
réseau externe
La frontière de sécurité essentielle se trouve désormais en dehors de la caméra.
Cette distinction est importante.
Même si la caméra modifie sa propre configuration réseau, elle ne prend pas automatiquement le contrôle de la passerelle de sécurité indépendante.
Sa connexion réseau ne mène qu’à ce système.
Que se passe-t-il dans le pire des cas ?
Prenons volontairement une situation défavorable :
La caméra a été entièrement compromise.
Sur un réseau conventionnel, elle pourrait alors tenter d’accéder à d’autres appareils ou à des serveurs externes.
Avec le modèle de sécurité séparé, elle rencontre en revanche une frontière indépendante :
POTENTIELLEMENT NON FIABLE
Caméra
│
▼
════════ FRONTIÈRE DE SÉCURITÉ ════════
Passerelle de sécurité
/ Pare-feu
│
▼
systèmes autorisés
La caméra peut tenter de contacter une adresse Internet quelconque.
La passerelle bloque la connexion.
Elle peut tenter d’accéder à un ordinateur du réseau bureautique.
La passerelle bloque la connexion.
Elle peut désactiver son propre pare-feu.
Le pare-feu externe n’en est pas affecté.
C’est le principe central de ce modèle de sécurité :
Ce n’est pas la caméra qui décide avec qui elle peut communiquer. C’est le réseau qui le décide.
Modèle 6 : connecter des sites distants par un tunnel sécurisé
Ce principe devient particulièrement intéressant lorsque les caméras sont installées sur des sites distants.
Les caméras peuvent, par exemple, se trouver sur le site d’un client tandis que le NVR ou le centre de télésurveillance est exploité ailleurs.
Dans ce cas, la passerelle de sécurité peut établir un tunnel VPN WireGuard chiffré.
SITE CLIENT
Caméra 1 ─┐
Caméra 2 ─┼── réseau isolé
Caméra 3 ─┘
│
▼
Passerelle de sécurité
│
VPN WireGuard
│
▼
════════════ INTERNET ════════════
│
▼
NVR interne
centre de télésurveillance
Les caméras elles-mêmes n’ont pas besoin d’un accès Internet illimité.
Seule la passerelle communique vers l’extérieur.
Et même au sein du VPN, toutes les connexions ne doivent pas nécessairement être autorisées. La passerelle peut continuer à déterminer quels systèmes et services sont accessibles.
En cas de panne du tunnel VPN, le système peut également être conçu selon le principe fail closed.
Cela signifie que la défaillance de la connexion sécurisée n’entraîne pas automatiquement l’utilisation d’une connexion de secours moins protégée via Internet.
Modèle 7 : conserver également l’analyse vidéo en local
L’exploitation de son propre NVR ouvre une autre possibilité : l’intelligence artificielle peut elle aussi fonctionner au sein de l’infrastructure de l’exploitant.
Frigate en est un exemple.
Frigate associe l’enregistrement vidéo à la détection locale d’objets. Selon le matériel utilisé, les flux vidéo peuvent être analysés automatiquement afin d’identifier certains objets.
Il peut notamment s’agir de :
- personnes,
- véhicules,
- animaux ou
- mouvements dans des zones définies.
Le point essentiel est le suivant :
Pour cette analyse, les données vidéo ne doivent pas nécessairement être transmises à un fournisseur externe d’intelligence artificielle.
Le traitement peut avoir lieu sur du matériel local.
Caméra
│
▼
Passerelle de sécurité
│
▼
NVR interne
│
▼
IA locale
│
▼
événement / alerte
L’enregistrement ainsi qu’une part importante de l’analyse automatisée peuvent donc rester au sein de l’infrastructure de l’exploitant.
Détecter une personne ne signifie pas détecter un incident de sécurité
Les capacités de l’intelligence artificielle doivent néanmoins être considérées avec réalisme.
Un système d’IA peut par exemple constater :
« Une personne se trouve sur cette image. »
Cela ne signifie pas automatiquement :
« Un cambriolage est en cours. »
L’analyse vidéo devient particulièrement intéressante lorsque plusieurs informations sont combinées.
Par exemple :
personne détectée
+
zone interdite
+
02 h 37
+
aucune activité prévue
↓
incident de sécurité possible
L’IA locale peut ainsi aider à filtrer de grandes quantités de données vidéo et à mettre en évidence des événements inhabituels.
Déterminer s’il existe réellement une menace et décider de la réaction appropriée restent des tâches distinctes.
Dans les services professionnels de sécurité, cette répartition des tâches peut être particulièrement pertinente : la technologie détecte et filtre – l’être humain évalue et décide.
L’heure et les mises à jour font également partie de la sécurité
Un réseau de caméras isolé ne signifie pas que celles-ci doivent fonctionner sans infrastructure complémentaire.
L’heure en est un exemple apparemment secondaire.
Si la caméra 1 enregistre un incident à 02 h 37 tandis que la caméra 2 enregistre le même événement à 02 h 42, la reconstitution ultérieure du déroulement devient inutilement difficile.
Un serveur de temps local peut donc être utile.
Les mises à jour ne doivent pas non plus être oubliées.
Déconnecter une caméra d’Internet puis la laisser fonctionner pendant des années sans mises à jour de sécurité ne constituerait pas une stratégie satisfaisante.
Les mises à jour peuvent au contraire être obtenues de manière contrôlée, vérifiées, puis installées au sein de l’environnement protégé.
L’isolation ne remplace pas la maintenance.
Plusieurs couches de protection plutôt qu’une caméra prétendument parfaite
Nous arrivons ainsi au principe fondamental de l’ensemble de cette architecture.
Aucune mesure isolée ne garantit une sécurité complète.
L’open source peut offrir transparence et possibilités de configuration, mais il n’empêche pas les vulnérabilités logicielles.
Un pare-feu limite les communications réseau, mais n’empêche pas la caméra elle-même d’être compromise.
WireGuard protège le canal de communication, mais ne peut pas rendre à nouveau fiable un terminal déjà compromis.
Un NVR exploité en interne offre davantage de contrôle sur le stockage, mais doit lui-même être sécurisé.
L’IA locale réduit la dépendance vis-à-vis de plateformes d’analyse externes, mais constitue à son tour un système logiciel supplémentaire qui doit être entretenu.
C’est pourquoi plusieurs couches de protection indépendantes sont combinées.
En sécurité informatique, ce principe est appelé Defense in Depth, ou défense en profondeur.
Si une couche de protection échoue, une autre doit continuer à limiter les dommages potentiels.
Du simple système cloud à une architecture de sécurité dédiée
Les différentes approches peuvent être comparées sous une forme simplifiée :
CLOUD DU FABRICANT
Caméra
↓
cloud du fabricant
↓
application
ENREGISTREMENT LOCAL
Caméra
↓
NVR interne
↓
stockage interne
RÉSEAU DE CAMÉRAS SÉPARÉ
Caméras
↓
réseau isolé
↓
pare-feu
↓
NVR interne
FRONTIÈRE DE SÉCURITÉ EXTERNE
Caméras
↓
réseau isolé
↓
passerelle de sécurité
↓
NVR interne
SITE DISTANT
Caméras
↓
passerelle de sécurité
↓
WireGuard
↓
infrastructure interne
TRAITEMENT LOCAL DES DONNÉES
Caméras
↓
passerelle de sécurité
↓
NVR interne
↓
IA locale
↓
stockage interne
↓
centre de télésurveillance
Il ne s’agit expressément pas d’un classement dans lequel seule la dernière architecture pourrait être considérée comme sûre.
Toutes les applications n’exigent pas le même niveau de complexité technique.
Une caméra unique surveillant une zone présentant peu de risques n’a pas les mêmes exigences que la vidéosurveillance d’un site industriel, d’un centre de données ou d’un autre site particulièrement sensible.
L’essentiel est de choisir l’architecture de manière consciente.
La question essentielle n’est pas : pouvons-nous faire confiance à la caméra ?
Les approches classiques de la sécurité cherchent souvent à sélectionner le produit le plus fiable possible.
Cela reste important.
Pour les technologies de sécurité connectées, cette approche ne suffit cependant plus à elle seule.
Une question plus robuste consiste à se demander :
Comment concevoir la vidéosurveillance de manière à ne pas devoir faire confiance sans réserve à la caméra ?
Une caméra peut utiliser un micrologiciel open source tout en restant isolée.
Une caméra peut utiliser un micrologiciel propriétaire tout en étant privée d’un accès Internet illimité.
Une caméra peut être compromise tout en restant séparée des réseaux bureautiques et des serveurs.
Et une caméra peut modifier sa propre configuration réseau sans pour autant prendre le contrôle du pare-feu d’une passerelle de sécurité physiquement distincte.
C’est là que réside la différence entre une fonction de sécurité isolée et une architecture de sécurité réellement réfléchie.
La sécurité d’un système de vidéosurveillance ne devrait donc pas dépendre du fait que chaque caméra et chaque composant de son micrologiciel soient considérés comme entièrement fiables. Un bon concept de sécurité limite au contraire, de manière systématique, ce qu’un appareil individuel est réellement capable d’atteindre.
La vidéosurveillance moderne commence toujours par l’objectif – mais elle ne s’arrête plus là depuis longtemps.