Pourquoi QoreDB bloque les mutations en production par défaut

Un développeur connecté à une base de production peut, en une seconde d'inattention, exécuter un DROP TABLE ou un DELETE sans WHERE. Les outils comme DBeaver ou pgAdmin laissent passer ce type d'opération sans broncher. QoreDB prend le parti inverse : par défaut, les mutations destructrices sont bloquées en production.

Ce n'est pas un simple warning UI. La vérification se fait côté backend, en Rust, avant que la moindre requête ne soit transmise au moteur de base de données.

Chaque connexion a un environnement

Dans QoreDB, chaque connexion est associée à un environnement : Development, Staging ou Production. Ce choix est fait à la création de la connexion et stocké dans le vault chiffré, aux côtés des credentials. L'environnement n'est pas un label cosmétique. Il conditionne le comportement du backend pour toute la durée de la session.

Le code Rust convertit la chaîne d'environnement en un enum typé (Development, Staging, Production) dès la réception de la commande. Cette classification est ensuite injectée dans le contexte de chaque requête interceptée. Le typage fort garantit qu'aucune requête ne peut être exécutée sans environnement connu.

Côté interface, l'environnement Production déclenche un thème visuel distinct avec des bordures rouges dans la barre d'état. Ce feedback permanent rappelle au développeur le contexte dans lequel il travaille. Mais le vrai garde-fou est ailleurs.

L'analyse SQL avant exécution

Avant d'envoyer une requête au moteur de base de données, QoreDB l'analyse avec sqlparser, un parser SQL écrit en Rust. Le parser produit un AST (arbre syntaxique abstrait) que le module sql_safety.rs inspecte pour classifier la requête.

Deux propriétés sont extraites de chaque statement. Premièrement, is_mutation : la requête modifie-t-elle des données ? Un INSERT, UPDATE, DELETE ou SELECT INTO est une mutation. Un SELECT, SHOW ou EXPLAIN ne l'est pas. Deuxièmement, is_dangerous : la requête est-elle potentiellement destructrice ? Un DROP, TRUNCATE, ALTER, ou un UPDATE/DELETE sans clause WHERE entre dans cette catégorie.

Le parser utilise le dialecte SQL correspondant au driver actif. PostgreSQL, MySQL, DuckDB et SQL Server ont chacun leur dialecte dédié, ce qui évite les faux positifs liés aux différences de syntaxe entre moteurs.

Le Safety Engine et ses règles intégrées

Le résultat de l'analyse SQL alimente le Safety Engine, le composant central de prévention. Ce moteur de règles évalue chaque requête avant son exécution en la confrontant à un ensemble de règles, certaines intégrées, d'autres définies par l'utilisateur.

Les règles intégrées couvrent les cas les plus courants. En environnement Production, les DROP et TRUNCATE sont bloqués. Les DELETE déclenchent une demande de confirmation. Les UPDATE et DELETE sans WHERE demandent une confirmation explicite, y compris en Staging. Les ALTER génèrent un avertissement.

Chaque règle définit un triplet : les environnements concernés, les types d'opération ciblés, et l'action à appliquer (Block, RequireConfirmation ou Warn). Certaines règles ajoutent un pattern regex pour affiner le ciblage, par exemple pour détecter un UPDATE sans WHERE indépendamment du parser AST.

Le mode read-only comme verrou supplémentaire

Indépendamment du Safety Engine, chaque connexion peut être configurée en mode read-only. Ce mode est vérifié côté backend avant même l'analyse de la requête. Si la connexion est en lecture seule, toute mutation est rejetée immédiatement, quel que soit l'environnement.

Cette vérification intervient dans chaque commande Tauri de mutation (insert_row, update_row, delete_row). Le code vérifie d'abord le flag read_only via le session manager, puis les capabilities du driver, et enfin les règles de sécurité. Ce triple contrôle garantit qu'aucun chemin d'exécution ne peut contourner la protection.

Des règles personnalisables et des overrides par variable d'environnement

Les règles intégrées peuvent être désactivées individuellement, et des règles personnalisées peuvent être ajoutées. Chaque règle custom définit son propre pattern regex, ses environnements cibles et son action. Le moteur compile et cache les regex pour éviter la recompilation à chaque requête.

Pour les déploiements gérés, deux variables d'environnement permettent de forcer la politique de sécurité au niveau système. QOREDB_PROD_BLOCK_DANGEROUS bloque toutes les requêtes dangereuses en production, sans possibilité de confirmation. QOREDB_PROD_REQUIRE_CONFIRMATION exige une confirmation explicite. Ces variables surchargent la configuration locale, ce qui permet à un administrateur de garantir une politique uniforme sur toutes les installations.

En pratique : ce qui se passe quand on exécute un DROP en production

Prenons un scénario concret. Un développeur est connecté à une base PostgreSQL marquée Production. Il tape DROP TABLE users dans l'éditeur SQL et lance l'exécution.

Le backend reçoit la commande. Le module sql_safety parse la requête avec le dialecte PostgreSQL et détecte un statement DROP : is_mutation et is_dangerous sont tous les deux vrais. Le contexte d'exécution est construit avec l'environnement Production, l'opération Drop, et le flag acknowledged à false.

Le Safety Engine évalue ses règles dans l'ordre. La première règle applicable est "Block DROP in Production". Son action est Block. La requête est rejetée avant d'atteindre le driver PostgreSQL. L'entrée est enregistrée dans le journal d'audit avec le flag blocked à true.

L'utilisateur voit un message d'erreur explicite dans l'interface. Pas de popup ambigu, pas de "êtes-vous sûr ?". La requête est simplement bloquée.

La protection des environnements de production dans QoreDB repose sur une chaîne de vérifications côté backend : classification d'environnement typée, parsing SQL par dialecte, moteur de règles avec actions graduées, mode read-only indépendant, et surcharge par variables d'environnement système. Chaque maillon est testé unitairement. L'objectif est simple : qu'un accident en production soit structurellement impossible, pas seulement improbable.