Isolement
Le principe de moindre privilège appliqué aux scripts et environnements de test.
Les scripts et protocoles de contrôle fournis par le client — qu'il s'agisse d'un Test Pack maison, adapté d'un modèle RestorSignal, ou même généré partiellement par un LLM — sont traités par principe comme du code non fiable. Cette prudence n'est pas une question de confiance envers le client : c'est une hygiène de sécurité standard appliquée à tout code exécuté dans un environnement partagé.
Ce que le sandbox n'accorde pas par défaut
Par défaut, un script client n'a accès à aucun des éléments suivants :
- un accès root à la machine hôte ;
- le socket Docker ;
- les métadonnées du fournisseur cloud sous-jacent ;
- une connexion Internet sortante ;
- les secrets appartenant à d'autres tenants ;
- les données ou résultats d'autres jobs en cours ou passés.
Chacune de ces restrictions ferme une voie d'évasion classique hors d'un environnement de test isolé. Un script qui a besoin d'une capacité en dehors de ce périmètre par défaut doit en faire la demande explicite, évaluée au cas par cas — l'ouverture n'est jamais implicite.
Les secrets sont injectés temporairement
Lorsqu'un test nécessite un secret — un mot de passe de base de données, une clé d'API applicative — celui-ci est injecté juste avant son utilisation, pour la durée strictement nécessaire au contrôle concerné. Ce secret ne doit apparaître à aucun moment dans le Test Pack lui-même, ni dans le rapport produit, ni dans le résultat normalisé transmis, ni dans les données reçues par l'API centrale de RestorSignal. Cette règle s'applique quel que soit le mode d'exécution.
Le résultat produit n'est pas automatiquement digne de confiance
L'artefact restauré étant par nature une entrée non maîtrisée, ce qu'il produit l'est tout autant. Le résultat technique d'un test est donc validé selon un schéma strict avant d'entrer dans le dossier de preuve : champs bornés, aucun texte arbitraire issu du moteur restauré recopié tel quel, aucune donnée métier extraite de la sauvegarde. Le fait qu'un résultat provienne du composant d'exécution prévu ne le dispense jamais de cette validation.
Le principe général : moindre privilège
L'ensemble de ces règles découle d'un même principe : un script de test ne doit disposer que des accès strictement nécessaires à l'exécution des contrôles pour lesquels il a été conçu, rien de plus. Ce principe s'applique de la même manière en mode Local et en environnement temporaire. Dans ce second mode, l'isolement est renforcé par un élément supplémentaire : l'environnement entier, avec tout ce qu'il contient, est détruit à l'issue du test — voir Environnement temporaire pour le détail du processus de destruction et ses limites.