Sécurité et confiance
Un backup de cellule robotisée décrit une installation de production : programmes, entrées/sorties, repères, paramètres de sécurité. Voici comment ces fichiers sont protégés, et ce que nous nous interdisons d'en faire.
Dernière révision :
Isolation entre organisations
Chaque donnée métier porte l'organisation à laquelle elle appartient, et aucune requête ne peut en sortir. L'isolation est imposée à deux niveaux indépendants : dans l'application, et dans la base de données elle-même par les politiques de sécurité au niveau des lignes (Row-Level Security) de PostgreSQL.
Deux niveaux plutôt qu'un, parce qu'un seul suffirait tant que le code est parfait. Le second niveau est celui qui tient quand le premier a un défaut : même une requête mal écrite ne peut pas rapporter la ligne d'une autre organisation, la base refusant de la rendre.
Le rôle applicatif qui sert le trafic n'est ni superutilisateur, ni propriétaire des tables — trois situations sous PostgreSQL permettent de contourner ces politiques, et le service refuse de démarrer s'il détecte l'une d'elles.
Chiffrement
En transit : TLS sur tous les accès au service — interface web, appels d'API, stockage objet.
Au repos : le stockage objet et la base de données sont chiffrés par les plateformes qui les hébergent. Les archives ne sont jamais dans un espace public : elles sont atteignables par un lien signé à durée courte, cryptographiquement lié à UN objet précis, et émis seulement après vérification que le demandeur est membre de l'organisation propriétaire. Le lien porte l'objet ; c'est notre route qui porte l'organisation.
Ce que le produit ne fait pas
Maatron lit des fichiers. Il ne se connecte à aucun contrôleur, n'écrit sur aucun robot, ne déploie aucun programme et ne déclenche aucun mouvement. Cette limite n'est pas un manque de fonctionnalité : c'est ce qui garantit qu'une erreur de notre part ne peut pas atteindre une cellule de production.
Vos fichiers ne servent pas à entraîner de modèle. Ils restent votre propriété, et le traitement automatisé qui les analyse est déterministe — mêmes fichiers, même résultat — plutôt que probabiliste.
Aucune donnée client en développement
Aucune archive client n'entre dans les environnements de développement, de test ou de démonstration — y compris pour reproduire un incident ou préparer une démonstration. Le matériel d'essai est fabriqué pour l'occasion, ou dérivé d'une sortie de contrôleur neutralisée : identifiants généricisés, ne se rattachant à aucune installation.
C'est précisément dans ces contextes que la vigilance se relâche, donc la règle y est identique plutôt qu'assouplie.
Conservation et suppression
Trois délais, parce qu'un seul chiffre serait faux dans les deux sens : la perte d'accès est immédiate, alors qu'aucune sauvegarde sérieuse ne se réécrit à la demande.
Révocation d'accès : immédiate, sur demande. La donnée cesse d'être joignable par quiconque.
Effacement des systèmes vivants (stockage objet et base de données) : trente jours au plus.
Destruction des copies de sauvegarde et de reprise après sinistre : soixante jours au plus, par expiration de leur propre cycle.
Le détail figure dans Politique de confidentialité et dans Entente de traitement des données.
Signaler une vulnérabilité
Écrivez à info@maatron.dev. Nous accusons réception et tenons informé du traitement. Aucune poursuite ne sera engagée contre une recherche menée de bonne foi qui ne dégrade pas le service et ne touche pas aux données d'autrui.