Le système d'environnements : Dev, Staging, Prod et leurs garde-fous

Classer ses connexions pour éviter les accidents

Le principal risque quand on manipule des bases de données au quotidien n'est pas technique. C'est humain. Un onglet ouvert sur la mauvaise connexion, un DROP TABLE exécuté trop vite, un UPDATE sans WHERE lancé sur la prod au lieu du staging. Les outils classiques ne distinguent pas vraiment les environnements. La connexion de production ressemble à celle de développement. Le même bouton "Execute" produit les mêmes effets partout.

QoreDB part d'un principe simple : chaque connexion doit déclarer son environnement, et l'application doit adapter son comportement en fonction. Ce n'est pas un label cosmétique. C'est une métadonnée stockée dans le vault, propagée au backend Rust, et utilisée par le moteur de règles pour décider ce qui est autorisé.

Trois niveaux, trois comportements

Chaque connexion enregistrée dans QoreDB porte un champ environment qui prend l'une des trois valeurs possibles : Development, Staging ou Production. Ce champ est défini au moment de la création de la connexion et fait partie des métadonnées persistées dans le vault chiffré, au même titre que le host, le port ou le driver.

En mode Development, aucune restriction particulière ne s'applique. L'utilisateur peut exécuter librement des DROP, des TRUNCATE ou des UPDATE sans clause WHERE. C'est l'environnement de travail courant, celui où on itère rapidement.

En mode Staging, QoreDB commence à intervenir. Les UPDATE et DELETE sans WHERE déclenchent une demande de confirmation. L'interface affiche un indicateur visuel distinct pour rappeler qu'on n'est plus en développement.

En mode Production, les garde-fous sont au maximum. Les DROP et TRUNCATE sont bloqués par défaut. Les DELETE demandent une confirmation explicite. Les ALTER génèrent un avertissement. Et le mode lecture seule peut être activé pour interdire toute mutation.

Un signal visuel permanent

L'identification de l'environnement ne repose pas uniquement sur les règles de sécurité. Elle passe aussi par un système de couleurs appliqué à l'interface. Chaque environnement est associé à une paire de variables CSS : une couleur principale et une variante adoucie pour les fonds.

Le Development utilise un thème neutre. Le Staging se distingue par une couleur dédiée. La Production affiche des bordures rouges, un badge "PROD" visible dans la barre de statut et dans l'arbre de connexions. L'objectif est qu'à aucun moment l'utilisateur ne puisse confondre un onglet de production avec un onglet de développement. Le rappel est constant, pas seulement au moment de l'exécution.

L'analyse SQL avant exécution

Quand une requête est soumise, QoreDB ne se contente pas de la transmettre au moteur de base de données. Elle passe d'abord par un module d'analyse, sql_safety, qui utilise sqlparser pour parser la requête selon le dialecte du driver actif (PostgreSQL, MySQL, DuckDB, SQL Server, ou un dialecte générique).

L'analyse produit deux indicateurs : is_mutation et is_dangerous. Le premier identifie toute requête qui modifie des données (INSERT, UPDATE, DELETE, CREATE, ALTER, DROP). Le second cible les cas à haut risque : DROP, TRUNCATE, ALTER, et surtout les UPDATE ou DELETE sans clause WHERE.

Cette analyse est syntaxique, pas heuristique. Elle repose sur l'arbre syntaxique produit par le parser, ce qui évite les faux positifs liés à des mots-clés présents dans des commentaires ou des chaînes de caractères. Le frontend effectue aussi une pré-vérification avec des regex pour donner un retour immédiat, mais c'est le backend Rust qui fait foi.

Le moteur de règles de sécurité

L'analyse SQL alimente un moteur de règles, le SafetyEngine, qui décide de l'action à prendre. Ce moteur fonctionne avec deux catégories de règles : les règles intégrées et les règles personnalisées.

Les règles intégrées couvrent les cas les plus courants. En production, un DROP est bloqué. Un TRUNCATE est bloqué. Un DELETE demande une confirmation. Un UPDATE sans WHERE demande une confirmation (y compris en staging). Un ALTER déclenche un avertissement. Ces règles sont actives par défaut et peuvent être désactivées individuellement si nécessaire.

L'utilisateur peut aussi définir ses propres règles via l'interface. Chaque règle spécifie un environnement cible, un type d'opération, une action (bloquer, avertir, demander confirmation) et un pattern regex optionnel pour cibler des requêtes spécifiques. On peut par exemple créer une règle qui bloque tout SELECT sur une table contenant des données sensibles en production.

Le moteur évalue les règles dans l'ordre. La première règle qui correspond au contexte de la requête détermine l'action. Le contexte inclut l'environnement, le type d'opération, le texte de la requête et l'état d'acquittement de l'utilisateur.

Une politique configurable par déploiement

Au-delà des règles individuelles, QoreDB expose une politique globale via le fichier config.json et des variables d'environnement. La variable QOREDB_PROD_BLOCK_DANGEROUS force le blocage de toutes les requêtes dangereuses en production. QOREDB_PROD_REQUIRE_CONFIRMATION active la confirmation obligatoire.

D'autres variables permettent de borner l'exécution : durée maximale d'une requête, nombre maximal de lignes retournées, nombre maximal de requêtes concurrentes. Ces limites ne sont pas spécifiques à un environnement, mais elles sont particulièrement utiles dans un contexte de production partagée.

Ce système de variables d'environnement permet aux équipes de déployer QoreDB avec une politique de sécurité prédéfinie, sans dépendre de la configuration manuelle de chaque utilisateur.

Conclusion

Le système d'environnements de QoreDB traite la sécurité comme une propriété de la connexion, pas comme une option globale qu'on active ou qu'on oublie. La classification Dev/Staging/Prod traverse toute l'application, du vault chiffré jusqu'au moteur de règles, en passant par l'interface visuelle. Le résultat est un outil qui rend difficile de faire une erreur en production, tout en restant non-intrusif en développement.