YPCad
Français
Demander une démonstration

Sécurité

Cette page dit à la fois ce que nous protégeons et ce que nous ne pouvons pas protéger. Un discours de sécurité auquel manque la seconde partie pousse le lecteur à confondre une liste avec une garantie.

Point de départ

Publier un paquet, c’est exécuter du code sur le poste de chaque ingénieur qui l’installe. Chaque décision de sécurité de ce produit a d’abord été pesée face à une question : ce changement rend-il plus facile une publication non autorisée ?

  • Les paquets sont signés (ECDSA P-256)

    Le fichier de signature voyage à l’intérieur du paquet. Il signe un manifeste contenant les empreintes des fichiers, l’identifiant du paquet et la version — pas une simple empreinte de l’archive.

    Si seule l’empreinte était signée, une vieille archive correctement signée pourrait être présentée sous un nouveau numéro de version : la signature passerait la vérification, et l’utilisateur installerait comme « mise à jour » un outil portant une vulnérabilité connue.

  • La clé privée n’est PAS sur le serveur

    Le serveur ne fait que vérifier. La signature se produit sur le poste de celui qui publie, avec un outil distinct.

    Si la clé résidait sur le serveur, celui qui s’en empare pourrait modifier un paquet et le resigner — ce qui rendrait la signature vaine.

  • Le client vérifie aussi

    L’extension installée sur le poste de l’ingénieur vérifie la signature de son côté, et la liste des clés de confiance qu’elle utilise ne vient pas du serveur.

    La signature existe précisément parce qu’on ne peut pas croire le serveur sur parole. Prendre la liste de confiance sur ce même serveur annulerait en silence l’hypothèse de départ.

  • Un journal d’audit qui ne s’efface pas

    Chaque publication, chaque changement de droit et chaque décision de canal s’écrivent pour toujours. Il n’existe, à dessein, aucun chemin de modification ou de suppression, et le nettoyage après la durée de conservation n’y touche pas.

    « Comment cet outil est-il arrivé ici » se demande en général des mois plus tard. Ce jour-là, une trace qui aurait pu être effacée est une trace qui n’a jamais existé.

  • Règle des quatre yeux, en option

    Monter une version vers un canal plus large peut exiger l’accord d’un second administrateur, et celui qui a demandé ne peut pas approuver sa propre demande. Le retour arrière n’exige jamais d’accord.

    Elle est désactivée par défaut. Dans une équipe de trois personnes, l’obstacle se transforme en quelques semaines en un message approuvé sans être lu ; un contrôle qu’on croit protecteur sans qu’il protège est pire que pas de contrôle du tout.

  • Décompresser une archive est en soi une surface d’attaque

    Les archives déposées sont contrôlées contre la sortie de dossier (zip-slip) et contre les bombes de décompression, et la taille après décompression est limitée.

    Décompresser une archive paraît anodin. Une archive spécialement préparée peut écrire des fichiers hors du dossier cible ou remplir le disque du serveur.

  • Connexion sans mot de passe

    Les utilisateurs se connectent par un code à usage unique envoyé à leur adresse. La session tient à un jeton de courte durée ; le jeton de rafraîchissement n’est jamais visible pour le code du navigateur.

    S’il n’y a pas de coffre de mots de passe à gérer, il n’y a pas non plus de base de mots de passe qui puisse fuir. Et la réutilisation d’un jeton de rafraîchissement déjà révoqué est traitée comme un signe de vol : la session se ferme.

  • Vous voyez ce que vous installez

    Le dossier d’installation contient une nomenclature lisible par machine (SBOM CycloneDX) et les scripts de migration pour les deux bases de données.

    Votre équipe informatique doit pouvoir contrôler ce qui arrive sur le serveur avant que cela n’arrive. Quand une vulnérabilité est annoncée dans une dépendance, « l’avons-nous ? » devient une recherche dans des fichiers.

Ce que nous ne pouvons pas protéger

Ce ne sont pas des lacunes, ce sont des limites. Elles découlent de la structure, et affirmer le contraire serait faux.

  • Deux administrateurs qui agissent de concert. La règle des quatre yeux en arrête un, pas deux.
  • L’administrateur système du serveur. Pour qui a accès à la base de données et au système de fichiers, aucun contrôle applicatif n’est un obstacle.
  • Le poste où se trouve la clé de signature. La clé n’est pas sur le serveur, mais elle est quelque part ; si cette machine tombe, la signature tombe avec elle.
  • Un comportement malveillant délibérément caché. Notre inspection des paquets est heuristique et nous ne prétendons pas qu’elle attrapera du code qui cherche à se dissimuler.
  • La fuite de données. Un outil installé travaille avec les droits de l’ingénieur lui-même et peut lire tout ce qu’ils atteignent. Ce sont les contrôles du système d’exploitation et du réseau qui limitent cela, pas ce produit.
  • La sécurité de vos sauvegardes. La copie de la base de données est entre vos mains, et tout ce qu’elle contient vaut exactement le système vivant.

Signaler une vulnérabilité

Si vous en avez trouvé une, écrivez-nous. Nous prenons les signalements au sérieux, nous n’écartons pas celui qui signale du processus, et nous vous disons quand le correctif sort.

security@ypcad.com