Architecture de sécurité

Cette page décrit la conception du contrôle d'accès et de la gestion des clés de RemCam, à l'intention des équipes sécurité évaluant un déploiement. Elle reflète l'implémentation livrée, non des intentions ; lorsqu'un choix de conception s'écarte des pratiques courantes (par exemple l'épinglage de certificats au lieu d'une hiérarchie de CA), la justification est exposée.

Modèle de déploiement et d'exposition

RemCam est un binaire Go unique installé comme service système sur le serveur administré, s'exécutant sous un compte de service dédié non root. Aucun relais cloud, maillage d'agents ou prestataire tiers d'accès distant ne se trouve sur le chemin : tout le trafic de visualisation et de contrôle reste entre le VMS/l'opérateur et le serveur.
Par défaut, la console web n'écoute que sur 127.0.0.1. Le flux RTSP du bureau et l'interface ONVIF sont limités en permanence à la boucle locale - ils sont consommés par le serveur VMS co-localisé et ne sont jamais exposés au réseau. La seule façon d'exposer la console sur un réseau est le commutateur explicite de liaison par interface, toujours en HTTPS.
Les connexions sortantes se limitent au service de licence (activation, désactivation, vérification des mises à jour signées) en HTTPS.

Accès à deux facteurs

Chaque écouteur (boucle locale et chaque interface liée) est configurable indépendamment pour l'application du double facteur. Avec le 2FA activé sur un écouteur :

Facteur 1 - possession, au niveau de la couche TLS. L'écouteur applique le TLS mutuel. Le client doit présenter un certificat client enrôlé pendant la négociation ; à défaut, la négociation est rejetée avant tout échange HTTP - pas de page de connexion, pas de page d'erreur, aucune surface applicative. Un attaquant non authentifié sur ce réseau ne voit qu'une session TLS en échec, rien de plus.
Facteur 2 - connaissance, au niveau applicatif. Une connexion vérifiée par certificat exige toujours le mot de passe du compte pour établir une session. Le certificat identifie le compte ; la connexion n'aboutit qu'après vérification du mot de passe.

Avec le 2FA désactivé, un seul facteur suffit (certificat ou mot de passe) - approprié pour l'écouteur de boucle locale et les réseaux d'administration de confiance. La console empêche l'activation du 2FA tant que l'administrateur ne détient pas un certificat client fonctionnel, de sorte que le changement d'application ne peut pas verrouiller l'opérateur qui l'active.

Épinglage des certificats clients

RemCam n'opère délibérément pas de hiérarchie de CA. Les certificats clients sont épinglés individuellement, et non validés par chaîne :

Chaque certificat est généré sur le serveur (cryptographie de la bibliothèque standard Go uniquement - pas de CA externe, pas de service de certificats, pas d'appel réseau), auto-signé, et enrôlé par son empreinte SHA-256, lié à un seul compte administrateur et étiqueté par appareil.
Au niveau de la couche TLS, le vérificateur compare l'empreinte du certificat feuille présenté à l'ensemble des certificats enrôlés. Il n'y a aucune ancre de confiance de CA à dérober, aucune chaîne à mal valider, et l'enrôlement d'un certificat n'accorde exactement qu'une seule identité - la compromission d'un certificat ne confère jamais d'autorité sur les autres.
Les certificats ont un cycle de vie explicite : émis → actif, avec des opérations de suspension, de réactivation et de révocation par certificat. La suppression d'un compte révoque tous ses certificats. La présentation d'un certificat révoqué est traitée comme un signal de sécurité : elle est rejetée lors de la négociation et déclenche un événement d'alarme vers le VMS.
Le lot .p12 téléchargeable contient uniquement la clé privée du client et son certificat d'entité finale, protégés par un mot de passe défini à la génération. Il n'inclut jamais de certificat de CA - son import ne peut pas ajouter d'ancre de confiance au navigateur de l'opérateur.
L'utilisation des certificats est suivie (dernière présentation / dernière utilisation), et la première utilisation d'un certificat de remplacement révoque automatiquement le certificat qu'il remplace.

TLS serveur

Le certificat serveur est généré localement au premier démarrage (bibliothèque standard Go ; aucune dépendance à une CA externe ou à ACME - la console doit fonctionner sur des réseaux isolés). L'installateur le place dans les magasins de confiance du système et des navigateurs sur le serveur ; les opérateurs le vérifient sur leurs propres appareils via l'empreinte SHA-256 publiée (point de terminaison trust-on-first-use).
TLS 1.2 minimum, choisi pour la compatibilité avec le navigateur embarqué de NX Witness.

Stockage des identifiants et des clés

Les mots de passe des comptes sont stockés sous forme de hachés bcrypt, facteur de travail 12. La vérification est à temps constant : les comptes inconnus sont comparés à un haché leurre, de sorte que le temps de réponse ne révèle pas l'existence d'un compte. Les mots de passe en clair ne sont jamais écrits sur disque ni dans les journaux.
Secrets au repos (Linux) : les identifiants (magasin de comptes, identifiants RTSP et similaires) résident dans un magasin de fichiers chiffré sous /etc/vmsmc/credentials (répertoire en mode 0700, appartenant au compte de service). Chaque entrée est chiffrée en AES-256-GCM ; la clé est dérivée via HKDF-SHA256 à partir de l'identité machine et d'un sel aléatoire propre à l'installation, si bien que les fichiers d'identifiants ne sont pas portables sur une autre machine et qu'une image disque copiée ne livre pas à elle seule les identifiants sans l'identité machine correspondante.
Secrets au repos (Windows) : le magasin d'identifiants de la plateforme est utilisé via le mécanisme natif du système d'exploitation.
Clés privées : la clé TLS du serveur et le matériel des certificats clients enrôlés sont conservés sous /etc/vmsmc (mode 0700, compte de service uniquement). Les clés privées clientes n'existent côté serveur que transitoirement, à la génération, et dans le .p12 protégé par mot de passe remis à l'administrateur.
Les sessions ne sont conservées qu'en mémoire - un redémarrage du service invalide tous les jetons de session.

Politique de session et de verrouillage

Les sessions ont une durée de vie absolue de 24 heures et un plafond d'inactivité de 8 heures ; les jetons expirés sont évincés dès leur premier rejet.
Le verrouillage anti-force-brute est global, et non par source ou par compte : les échecs de connexion de toutes origines partagent un même compteur progressif, si bien que la rotation des adresses source ou des noms d'utilisateur ne réinitialise pas le seuil. Une fois le seuil final atteint, la console se verrouille définitivement jusqu'au redémarrage du service sur le serveur lui-même - une propriété délibérée de « présence physique pour récupérer ».

Piste d'audit

Chaque action pertinente pour la sécurité - connexion et échec, verrouillage, ouverture de session, prise/libération/prise forcée du contrôle de la console, modifications de comptes et de configuration, transitions du cycle de vie des certificats, démarrage/arrêt du service - est consignée dans le journal d'événements local et publiée sous forme d'événements ONVIF dans l'arborescence de sujets tns1:RemCam (liste complète dans le guide d'utilisation). Le VMS peut déclencher des alarmes, poser des signets et conserver ces événements selon sa propre politique de rétention, sur une infrastructure que l'équipe sécurité contrôle déjà.
La session d'administration constitue elle-même une preuve : le bureau du serveur est un flux caméra enregistré, si bien que l'effet de chaque frappe se trouve dans l'archive du VMS, aux côtés des événements.

Chaîne d'approvisionnement logicielle

Les mises à jour sont signées en Ed25519. La signature est vérifiée contre une clé épinglée dans le binaire, puis revérifiée au sein de l'étape privilégiée d'application - un fichier substitué après la vérification initiale (TOCTOU entre téléchargement et installation) est rejeté. Les téléchargements de mise à jour refusent le HTTP en clair vers des hôtes hors boucle locale.
Le produit est un unique binaire Go compilé statiquement : aucun interpréteur embarqué, aucun sous-processus FFmpeg ou de transcodage, aucun chargement de plugins. Les opérations privilégiées (mise à jour des magasins de confiance du système et similaires) sont déléguées à un unique assistant audité avec arguments validés, plutôt que d'exécuter le service en root ; l'unité systemd applique un cloisonnement de la surface noyau (paramètres, modules et journaux du noyau protégés, personnalité verrouillée, temps réel et création de SUID/SGID restreints).

Signaler une vulnérabilité

Écrivez à support@remcam.software en détaillant votre découverte. Nous accusons réception des signalements rapidement, et les correctifs critiques pour la sécurité sont signalés aux consoles déployées via le canal de mise à jour signé, avec un délai d'application imparti.