Sécuriser les caméras IP et le stockage vidéo cloud

Sécuriser les caméras IP et le stockage vidéo cloud

Une caméra connectée est un ordinateur exposé, équipé d’un capteur et souvent administré comme un grille-pain. Le compromis central est net : le stockage cloud réduit l’effort d’exploitation et facilite l’accès distant, mais il étend la surface d’attaque aux identités, aux interfaces de programmation et aux flux vidéo hors du périmètre physique.

Explication de la marmotte

Un système de vidéosurveillance ressemble à un réseau de vigiles qui écrivent tout dans des carnets placés soit dans le bâtiment, soit chez un archiviste extérieur. Cela sert à revoir un incident, mais aussi à décider qui peut consulter ces images et qui peut entrer dans la salle où elles sont conservées.

→ Lire l’explication complète de la marmotte

Architecture réseau des caméras IP et des enregistreurs

Une caméra IP (Internet Protocol) ne doit jamais résider dans le réseau utilisateur ni dans un réseau serveur généraliste. La séparation minimale impose un VLAN (Virtual Local Area Network) dédié aux équipements vidéo, un sous-réseau d’administration distinct et un NVR (Network Video Recorder) placé dans une zone de service contrôlée. Le NVR collecte les flux, applique la rétention et expose les consultations autorisées. La caméra ne doit pas être un serveur web disponible depuis Internet sous prétexte que l’application mobile le demande.

Le flux vidéo utilise fréquemment RTSP (Real Time Streaming Protocol), parfois encapsulé ou négocié via ONVIF (Open Network Video Interface Forum). Ces protocoles facilitent l’interopérabilité, mais ils ne transforment pas une caméra en composant de confiance. ONVIF expose des fonctions d’inventaire, de configuration et de découverte qui intéressent autant l’exploitant que l’attaquant présent sur le même segment. Désactiver ONVIF lorsqu’il n’est pas nécessaire réduit réellement la surface, contrairement à beaucoup de cases « sécurité avancée » qui décorent surtout les captures d’écran de plaquette.

La politique réseau doit être restrictive par destination et par port :

• caméra vers NVR : RTSP ou protocole constructeur, uniquement ;
• station d’administration vers caméras : HTTPS (Hypertext Transfer Protocol Secure) et SSH (Secure Shell) si ce dernier est indispensable ;
• caméra vers DNS (Domain Name System), NTP (Network Time Protocol) et dépôt de mises à jour explicitement autorisés ;
• NVR vers plateforme cloud : sortie HTTPS limitée aux noms de service documentés ;
• aucune entrée Internet directe vers une caméra, un NVR ou une passerelle vidéo.

L’accès distant doit terminer sur un point d’accès authentifié, journalisé et segmenté, jamais sur une redirection de port domestique recyclée dans un bâtiment professionnel. Le sujet rejoint les principes exposés dans l’architecture cyber et dans les fondations réseau. Le chiffrement du transport ne corrige pas une exposition publique : ouvrir l’interface d’administration à Internet avec HTTPS revient à verrouiller une porte dont l’adresse figure sur un panneau lumineux.

Le recours à un service cloud doit préférer une architecture où le NVR pousse les enregistrements vers le cloud. Connecter chaque caméra directement à un compte cloud multiplie les identités matérielles, les mises à jour et les chemins sortants. Cette approche n’est acceptable que pour un matériel administré de bout en bout, avec inventaire matériel, mises à jour forcées, certificats uniques et journalisation exploitable. Sinon, le NVR local reste le point de contrôle à conserver.

Vulnérabilités documentées des caméras IP

Les identifiants d’usine restent une cause majeure de compromission. Les listes de comptes connus sont intégrées à des outils de balayage et à des logiciels malveillants ciblant les objets connectés. Modifier le mot de passe administrateur ne suffit pas si l’équipement conserve un compte de maintenance, une interface Telnet ou un service Universal Plug and Play activé. L’acceptation de mots de passe faibles doit être considérée comme un défaut bloquant à l’achat, pas comme une excentricité de firmware.

Des vulnérabilités documentées montrent pourquoi la caméra ne mérite aucune confiance implicite. CVE-2017-7921 décrit un contournement d’authentification affectant certaines caméras Hikvision, permettant l’accès à des ressources sans session légitime. CVE-2021-36260 documente une injection de commandes dans le serveur web de produits Hikvision concernés. Dans les deux cas, le correctif n’est pas « mettre un mot de passe compliqué » : il faut identifier les versions affectées, appliquer le micrologiciel validé, vérifier le redémarrage et isoler les équipements qui ne peuvent pas être corrigés.

Une caméra compromise offre plusieurs chemins :

• récupération de flux vidéo et d’identifiants réutilisés ;
• pivot vers le NVR, le service DNS ou les postes d’administration ;
• désactivation de l’enregistrement ou falsification de l’heure ;
• relais vers un réseau de déni de service distribué ;
• exfiltration via une connexion sortante chiffrée, donc invisible à un filtrage qui ne regarde que les ports.

Le chiffrement TLS (Transport Layer Security) protège le flux contre l’interception entre deux extrémités authentifiées. Il ne protège pas contre une caméra compromise qui diffuse volontairement les images. Une autorité de certification privée peut délivrer des certificats individuels, mais la révocation d’un certificat ne coupe pas les flux déjà établis et ne corrige pas le micrologiciel vulnérable. Pour les mécanismes de canal, voir TLS, HTTPS et mTLS.

La liste d’actifs doit contenir le fabricant, le modèle exact, la version du micrologiciel, l’adresse matérielle, le propriétaire métier, le NVR associé et la date de fin de support. Sans cette donnée, une alerte de sécurité devient une chasse au trésor administrative, avec moins de pirates et davantage de tableurs.

Stockage vidéo cloud, identités et chiffrement

Une plateforme cloud de stockage vidéo concentre les risques sur l’identité. Le compte qui peut exporter une séquence, modifier la rétention ou générer un lien de partage a une valeur supérieure à la caméra elle-même. L’authentification multifacteur doit être obligatoire pour les comptes humains, tandis que les intégrations utilisent des identités de service à privilèges minimaux et à durée limitée.

Les liens de téléchargement signés sont utiles pour distribuer ponctuellement une vidéo. Ils deviennent des fuites dès qu’ils ont une durée excessive, sont écrits dans des journaux applicatifs ou transmis dans une messagerie. Un lien signé doit être limité à un objet précis, à une opération précise, à une fenêtre courte et, lorsque la plateforme le permet, à une adresse réseau attendue. Un lien qui donne accès à tout un conteneur de stockage est un jeton d’administration déguisé en URL.

Le chiffrement au repos doit être vérifié sur trois plans : chiffrement des objets vidéo, gestion des clés et séparation des droits. Une DEK (Data Encryption Key) chiffre les données, tandis qu’une KEK (Key Encryption Key) chiffre ou protège la DEK. Lorsque l’exigence de maîtrise des clés est forte, la KEK doit être gérée dans un HSM (Hardware Security Module), ou dans un service de gestion de clés adossé à un HSM. Cela ne rend pas le fournisseur incapable de supprimer les vidéos, de suspendre le compte ou de collecter des métadonnées. Une clé bien gardée ne reconstitue pas un fichier supprimé. La cryptographie traite la confidentialité et l’intégrité, pas la disponibilité ni le contrôle d’accès métier.

Le compromis entre clé fournie par le cloud et clé contrôlée par l’organisation dépend de la capacité d’exploitation. Une clé contrôlée par l’organisation permet une révocation et une séparation plus fortes, mais une erreur de politique de clé peut bloquer tous les exports et toutes les restaurations. Cette option est recommandée lorsque la plateforme permet une procédure testée de reprise, des journaux d’usage de clé et une délégation séparée entre administration cloud et administration de la clé. Sinon, la promesse de souveraineté finit souvent dans un ticket urgent portant le mot « inaccessible ».

Exemple de filtrage réseau pour un VLAN vidéo

L’exemple suivant utilise nftables sur une passerelle Linux. Il autorise les caméras du réseau 10.42.20.0/24 à joindre seulement le NVR, le résolveur interne et le serveur de temps. La politique par défaut bloque tout le reste, y compris les sorties directes vers Internet.

table inet video_filter {
  chain forward {
    type filter hook forward priority filter; policy drop;

    # Autoriser le retour des flux déjà établis.
    ct state established,related accept

    # Caméras vers le NVR, RTSP sur TCP et UDP.
    ip saddr 10.42.20.0/24 ip daddr 10.42.10.15 \
      tcp dport 554 accept
    ip saddr 10.42.20.0/24 ip daddr 10.42.10.15 \
      udp dport 554 accept

    # Caméras vers les services d'infrastructure internes.
    ip saddr 10.42.20.0/24 ip daddr 10.42.1.53 udp dport 53 accept
    ip saddr 10.42.20.0/24 ip daddr 10.42.1.123 udp dport 123 accept

    # Administration depuis le bastion seulement, via HTTPS.
    ip saddr 10.42.5.10 ip daddr 10.42.20.0/24 tcp dport 443 accept
  }
}

Avant déploiement, vérifier les ports réellement employés par le modèle concerné avec une capture réseau. Certains équipements basculent vers des ports propriétaires ou tentent de joindre des services de télémétrie externes. Ne pas ouvrir ces flux par réflexe : exiger une justification, un nom de destination stable et une méthode de supervision. Le « cloud obligatoire » inscrit dans une interface n’est pas une exigence d’architecture, c’est parfois une préférence de fabricant avec un costume.

Exploitation, rotation et reprise des enregistrements

La supervision doit détecter l’absence de flux, les redémarrages, les changements de configuration, les échecs d’authentification et les écarts d’horloge. Une caméra active mais figée sur une image ancienne est plus dangereuse qu’une caméra déclarée hors ligne : l’indicateur vert est alors un accessoire de théâtre.

Les journaux du NVR, de l’annuaire d’identité et de la plateforme cloud doivent être corrélés. Un export vidéo doit laisser une trace incluant l’identité, l’objet demandé, l’heure, la décision d’autorisation et le résultat. Sans journal d’export, une consultation abusive ne peut être ni attribuée ni investiguée. Les principes d’accès et de fédération relèvent aussi de la gestion des identités.

La rotation concerne les mots de passe locaux, les certificats, les jetons d’interface de programmation applicative et les clés de chiffrement. Elle doit être orchestrée avec une fenêtre où le NVR accepte l’ancien et le nouveau secret, sinon le renouvellement coupe les flux. Les comptes d’administration doivent être nominatifs ou liés à une identité fédérée, jamais partagés. Un compte admin commun rend l’attribution impossible et transforme chaque incident en séance de spiritisme numérique.

Les sauvegardes doivent couvrir les configurations de NVR, les règles de rétention, les certificats, les paramètres d’intégration cloud et les métadonnées d’indexation. Sauvegarder les vidéos sans leur index rend la recherche lente, donc l’investigation incomplète. Tester la restauration sur un environnement isolé, avec contrôle de l’intégrité des fichiers et de l’horodatage. La conservation légale des images dépend du contexte et ne se déduit pas d’un réglage de produit : l’architecture doit fournir des capacités de rétention et de purge vérifiables, pas improviser du conseil juridique.

🐝 Ce qui arrive si on s’en passe

Sans VLAN dédié ni filtrage des sorties, deux mécanismes contournent l’interdiction d’entrée depuis Internet sans que personne ne l’ait décidé. Le premier : une caméra qui garde UPnP actif peut demander elle-même au routeur l’ouverture d’une redirection de port, publiant son interface d’administration sans aucune règle écrite par l’exploitant. Le second : les services de relais « P2P » des fabricants maintiennent un tunnel sortant permanent vers leurs serveurs ; l’accès distant ne dépend alors plus du pare-feu mais du seul mot de passe du compte grand public du fabricant, hors de l’annuaire et hors de l’authentification multifacteur de l’organisation. Sur un réseau plat, la découverte ONVIF et UPnP livre en outre à tout poste compromis l’inventaire des caméras, avec modèles et versions de micrologiciel, ce qui suffit à cibler les CVE connues.

🦫 Explication de la marmotte 🍫

Une caméra connectée prend des images et les envoie par le réseau vers un appareil qui les enregistre, ou vers un service externe. Chaque caméra possède un logiciel, un compte d’administration et des services réseau. Si le logiciel contient une faille, si le mot de passe d’origine reste actif ou si la caméra est visible depuis Internet, une personne non autorisée peut consulter les images, modifier les réglages ou utiliser l’appareil pour attaquer d’autres systèmes.

La première protection consiste à placer les caméras dans une partie séparée du réseau. Elles peuvent parler à l’appareil d’enregistrement, au serveur qui donne l’heure et au serveur qui traduit les noms en adresses, mais pas aux ordinateurs des employés ni à Internet sans besoin précis. L’accès d’administration passe par un point contrôlé et enregistré.

Le stockage externe facilite la consultation à distance, mais il ajoute des comptes et des autorisations. Les personnes doivent prouver leur identité avec au moins deux moyens, et les programmes automatiques reçoivent des droits limités. Les vidéos sont chiffrées pendant le transport et pendant le stockage, mais ce chiffrement ne protège pas une caméra déjà piratée.

Enfin, il faut mettre à jour les caméras, remplacer les secrets, surveiller les coupures de flux et tester la restauration des enregistrements. Quand une caméra, un compte ou le stockage tombe en panne, l’enquête dépend de ces préparations.

À lire aussi

• Cyberspace Administration of China et conformité cybersécuritéMandat, exigences de données et conséquences d’architecture du Cyberspace Administration of China pour les systèmes opérés en Chine.
• Résidence des données et souveraineté cloudRésidence des données et souveraineté : distinguer la localisation réelle des données, le contrôle technique et les dépendances juridiques.
• Sécuriser badges RFID, NFC et serrures connectées en entrepriseSécurité des systèmes de contrôle d'accès physique connectés, des badges RFID clonables aux serrures connectées, avec le cycle de vie des accès et la convergence entre sécurité physique et logique.
• Sécuriser l'accès des flottes de véhicules connectésSécuriser les systèmes de contrôle d'accès des véhicules connectés et des flottes face aux attaques par diagnostic et connectivité cellulaire.

Pages voisines

La citent

• Réseaux personnels, IoT et objets contraints
• Edge, MEC, Fog, Cloud-RAN et infrastructures distribuées
• IPv6 sans NAT

Sécuriser les caméras IP et le stockage vidéo cloud

Elle cite

• ⇄Lien dans les deux sens :Inventorier les objets IoT oubliés sur le réseau
• Défendre un DDoS volumétrique et applicatif
• Pourquoi supprimer les comptes de service partagés

⇄ : les deux pages se citent l’une l’autre.