| LICENSE | ||
| readme.md | ||
| rfc-sgbd-hybride-fs-v03-fr.md | ||
FSDB — Filesystem-Database Hybrid Model
Métadonnées natives pour les bases de données relationnelles.
Version : v0.4
Statut : Spécification ouverte - Draft
Licence : EUPL-1.2 / CC-BY-4.0
Hébergement : Souverain - git.fixmybug.fr
Auteur : L. Dennery - FIXMYBUG SARL
Le problème
Les bases de données relationnelles (MariaDB, PostgreSQL, MySQL) savent stocker, trier et chercher. Elles ne savent pas protéger.
Elles ne savent pas qui a modifié une ligne. Elles ne savent pas qui a lu une donnée sensible. Elles ne savent pas chiffrer une colonne sans que l'application fasse tout le travail. Elles ne savent pas à qui appartient une donnée.
Résultat : c'est le logiciel au-dessus de la base qui gère l'audit, le chiffrement, la propriété et les permissions. Et le logiciel oublie, se trompe, et se fait contourner.
Pourtant, le système de fichiers de n'importe quel serveur Linux fait tout ça nativement. Propriétaire, permissions, horodatage, chiffrement — gérés par le noyau, pas par l'application.
FSDB pose la question : pourquoi les bases de données ne font-elles pas la même chose ?
La proposition
FSDB n'est pas un nouveau moteur de base de données. C'est une spécification architecturale pour enrichir les moteurs existants d'une couche de métadonnées inspirée des filesystems modernes (Btrfs, POSIX).
Le modèle est optionnel, rétrocompatible, et ne nécessite aucun changement du moteur de stockage sous-jacent.
Les 4 piliers
1. Identité structurelle immuable (_struct_id)
Chaque objet du catalogue (table, colonne, index) reçoit un identifiant unique et immuable à sa création, analogue au numéro d'inode d'un fichier. Cet identifiant survit aux renommages, migrations et réplications. C'est la fondation du modèle — tout le reste en dépend.
2. Souveraineté utilisateur (_owner)
La donnée appartient à une identité humaine, pas à un compte technique applicatif. L'identité est propagée depuis l'interface utilisateur via un token authentifié. L'application agit comme un délégataire temporaire, pas un propriétaire. Le transfert de propriété est une opération protocolaire sécurisée par double signature.
3. Métadonnées natives (audit et intégrité)
Le moteur gère automatiquement :
- Suivi d'écriture (
track_write PERSISTENT) — qui a créé, qui a modifié, quand. Infalsifiable. - Suivi de lecture (
track_read VOLATILE) — qui a consulté quoi. En mémoire uniquement, jamais dumpé.
Plus de colonnes d'audit à coder. Plus d'oublis de logging.
4. Chiffrement contextuel
Le chiffrement est lié à la structure (_struct_id) et au propriétaire (_owner). La clé est dérivée de métadonnées non-dumpables combinées avec une clé maître dans un serveur externe. Un dump SQL volé est cryptographiquement inutile.
Le mot-clé SECRET déclare qu'une colonne contient un secret par nature (mot de passe, IBAN, token). Le moteur impose automatiquement le chiffrement, interdit l'indexation, et active l'audit de lecture.
Comparaison
| Problème actuel | Avec FSDB |
|---|---|
| Audit contournable et falsifiable | Audit natif moteur, infalsifiable |
| Propriété floue (compte technique) | _owner humain natif |
| Chiffrement bricolé (clé dans conf.php) | Déclaratif (SECRET), clés externalisées |
| Pas de suivi de lecture | track_read VOLATILE en mémoire |
| Renommage casse les références sécurité | _struct_id immuable |
| Sécurité dépend du code applicatif | Sécurité dans le moteur |
Documentation
La spécification technique complète est dans ce dépôt :
Sections clés :
- Sections 1-4 : Modèle conceptuel (analogie Filesystem / SGBD)
- Section 5 : Spécification technique (
_struct_id,track_write/read, catalogue des métadonnées en trois niveaux : Cœur, Extension, Horizon) - Sections 6-7 : Syntaxe DDL, chiffrement contextuel,
SECRET - Section 8 : Architecture de confiance (
ACL_USER_SOURCE, annuaire externe, cache ACL) - Section 9 : Sécurité (accaparement, élévation de privilèges contextuelle)
- Section 13 : Estimation de réduction de dette technique
Degré de réalisme
Le catalogue des métadonnées est organisé en trois niveaux de maturité honnêtes :
- Cœur — faisable en plugin sur MariaDB ou PostgreSQL. C'est le MVP :
_struct_id,track_write PERSISTENT,SECRET,ENCRYPTED USING,acl_column,_immutable,_append_only,_undeletable. - Extension — nécessite une intégration moteur plus profonde :
track_read VOLATILE,acl_row,TRANSFER OWNERSHIP, chmod/umask, intégrité chaînée,SUBVOLUME,STORAGE_CLASS. - Horizon — pistes de recherche, non validées en faisabilité : overlay, sharding, quorum, réplication structurelle, CDC natif. Listées comme portes ouvertes, pas comme promesses.
Souveraineté
Ce projet est né en Europe (France/Suisse) et est hébergé sur une infrastructure souveraine, soumise au RGPD et au droit européen.
- Licence EUPL-1.2 — copyleft européen. Les modifications redistribuées restent ouvertes. Pas de fork propriétaire fermé.
- Licence CC-BY-4.0 — attribution obligatoire sur le document de spécification.
Contribuer
FSDB est une proposition ouverte. Nous la proposons pour :
- Développeurs C++/Rust pour des preuves de concept (plugins MariaDB/PostgreSQL, extension SQLite)
- Experts en sécurité pour auditer le protocole de chiffrement contextuel et de double signature
- Éditeurs de logiciels (ERP, CRM, SaaS) pour évaluer l'impact sur leurs schémas existants
Pour contribuer :
- Ouvrez une Issue pour discuter d'un point technique
- Proposez une Merge Request pour des corrections ou extensions de la spécification
- Implémentez un prototype et référencez-le ici
Contact
- Auteur : L. Dennery
- Organisation : FIXMYBUG SARL
- Site : fixmybug.fr
- Email : contact@fixmybug.fr