Base de données "inalterable" ?

[L33thium]

Bonjour,
j'étudie comment créer un logiciel de facturation à code ouvert qui me servirait à moi-même (donc je suis dieu).
Pour respecter la loi je dois faire en sorte que les entrées de la base de données soient inaltérable (interdit de modifier ou supprimer une entrée).
Ma difficulté est qu'elle doit se protéger de moi-même.

Je sais qu'on peux pas vraiment empêcher les modifications mais il existe certainement un moyen qui m'échappe pour qu'on ne puisse pas le faire sans que ça se sache (rendre la tâche suffisamment complexe pour que ça soit validable par l'AFNOR).

Pour l'instant sur l'embryon je bosse sur sqlite (en python) mais les idées peuvent aussi être proposées pour PGSQL et MariaDB/MySQL.
Un mécanisme de la BDD ou un moyen cryptographique peut être ?

J'ai songé créer la table et les triggers avec un compte admin à mot de passe aléatoire qui sera oublié après l'initialisation mais ça compliquerait légèrement la maintenance.
Hasher et signer servirait à rien puisque je suis dieu, j'aurais toutes les clés...

Bref, je sèche 😞

[brice.wernet]

Il y a 1 heure, L33thium a écrit :

Bref, je sèche 😞

Brave saucisse.

En règle général, si tu es dieu, la solution la plus simple est que le hashage soit fait par un tiers de confiance que tu ne maîtrise pas. Ou une copie dans un environnement sécurisé (mais ça ne correspondra peut-être pas à AFNOR).

Mais ce sujet, ça ne ressemble pas à une application de bloc chain?

[L33thium]

blockchain reviens de temps en temps dans le résultat de mes recherches mais je ne comprends pas du tout ces mécanismes.

[Charles.w]

Salut,

Comme mentionné dans la chatbox hier, dans l'absolu si tout le monde était parfait et que le temps était infini:

• tu peux regarder des technos de type blockchain privée (hyperledger & co)...c'est hype et donc relativement facile à vendre...même si je pense que pour ton usecase c'est overkill...et contrevient probablement à la GDPR si un client veut supprimer toutes les données qui le concernent
• tu peux aussi envisager d'utiliser un journal d'évènement, comme ce qu'on a sur des solutions de streaming de données (kafka streams, apache flink, ...)...tout tes évents de mise à jour sont en append only dans ton journal, ce dernier est snapshotté à intervalle régulier chez un tiers de confiance, et dans le pire des cas, tu ne perds que ce qui a entre l'instant d'un crash et ton dernier snapshot

Plus pragmatiquement, je te conseille de regarder du côté de ce qui se fait du côté de MongoDB et des delayed replicas sets...si tu as plusieurs instances de Mongo tu peux faire en sorte que certaines de tes instances aient un certain lag avant d'accepter les mises à jours...comme ça tu peux rattraper tes erreurs...si tu part sur cette option, je te conseille vivement de suivre les cours (gratuits et en anglais) sur MongoUniversity...même si à la fin tu part sur une solution hébergée style mLab...bonus, mLab peut faire des snapshots régulièrement

Sinon, et pour des solutions plus marouflées à la mimine, tu as des mécanismes de filesystem sur linux qui permettent de faire des filesystem en append-only (option O_APPEND de la commande open())...mais bien évidemment, cette solution ne te met pas à l'abri d'un admin sys qui lance une commande foireuse . En mode Richard Stallman / Linus Torvalds / Théo de Raadt tu peux regarder du côté des Log-Structured Merge Tree (LSM) et coder ta propre base en append-only .

Après, au  début évite de te prendre trop la tête...OK, ça se sera pas parfait, mais il ne faut pas nécessairement se focaliser là dessus...si tu as des politiques de backup propres, ça devrait le faire...par ailleurs, comme l'explique Robert C. Martin (Uncle Bob) dans Clean Code, sur certains projets, le mieux est de retarder le plus possible ce type de décision...ça se trouve, un simple répertoire synchronisé fera le taf.

[L33thium]

Merci mais il ne s’agit pas que de la sécurisation des données.
C'est une des obligations mais la loi anti-fraude me force à protéger la bdd des altérations volontaires  sur les factures existantes.

L'admin tiers de confiance est une solution mais je préfèrerais tant que possible garder une solution 100% locale.

La solution de replis serait d'oublier la gestion des factures et m'interfacer avec un logiciel certifié.

[Charles.w]

Tes éditeurs tiers doivent générer les PDF et les stocker sur disque en append only...

[brice.wernet]

Est-ce que tu sais comment se passe la validation AFNOR?

Nous nos prestataires nous envoient un courrier comme quoi la base est inaltérable, qu'on ne peut pas remonter une base de sauvegarde car elle passe en mode test, bla bla bla... ALors que le 1er truc que fait le presta, c'est de rstaurer un base vierge et de la passer en mode prod ... et de me filer la command eau cas où...

Il y a 15 heures, Charles.w a écrit :

Plus pragmatiquement, je te conseille de regarder du côté de ce qui se fait du côté de MongoDB et des delayed replicas sets...

Sinon, et pour des solutions plus marouflées à la mimine, tu as des mécanismes de filesystem sur linux qui permettent de faire des filesystem en append-only (option O_APPEND de la commande open())...mais bien évidemment, cette solution ne te met pas à l'abri d'un admin sys qui lance une commande foireuse .

Je ne crois pas que ce soit la question. Et pour le FS en append only, on peut le faire quelque soit le système.

 Mais je vois des gros logiciels de type compta, et ils n'ont pas "sécurisé" à outrance. Par contre il y a en général une double lecture, un peu comme une journalisation: le stockage de l'intention et le stockage de l'effet.

Et les principes doivent être clairs: le logiciel ne doit pas permettre d'altérer ou de supprimer des éléments. Parfois les interventions dans la BDD sont loguées (la BDD recopie le journal de connexion pour les connexions autres que l'utilisateur de la BDD). Aucune idée de comment fonctionne la purge.

Pour moi, il faut prouver qu'on ne peut pas modifier ou faire disparaître: pas de trous dans les n° de factures, pas de modification d'un devis, ...

Le stockage PDF est peut-être convaincant (chaque facture associée au document électronique PDF), mais il faut tout horodater et compter dans les traitements de justification.

 

De ce que j'ai comme expérience, techniquement dans les logiciels réputé conforme (y compris à plusieurs 100k€) il n'y a rien, tout repose sur du standard (l'utilisateur de la BDD a des droits restreints, on ne diffuse pas le sa à tout le monde, tout ce qui génère un document est associé à un compteur).

J'imagine que le plus gros problème, c'est le ticket d'entrée pour être certifié

Peut-être simplement une appli en mode SAS sera plus facile à prouver?

[L33thium]

Quand on édite un logiciel à code source fermé pour des tiers, encore plus si on héberge la bdd pour eux, c'est très facile en effet.
Mon problème est de développer un logiciel pour moi-même, donc sans tiers de confiance.

Dans ce cas des règles morales et ma seule bonne foi ne permettra pas de valider un audit anti-fraude.
La génération du PDF systématiquement est une des choses à faire en effet.

Mais je cherche le moyen le moins faillible de faire en sorte que la modification des entrées laisse une trace trop compliquée à supprimer.
Un log chiffré avec les données sous une forme totalement inintelligible par un humain peut être un des mécanismes à mettre en place (mais du coup ça compliquerait aussi la recherche de modifications)
Peut être un moyen mathématique ? une clé dans chaque entrée dépendant de la valeur de toutes les autres clés ? je sais pas

Une clé qui devrait avoir une valeur prévisible si on remonte les entrées créées et dériverait si l'une d'elle a été créée puis modifiée ou supprimée ?

[Lyaume]

Hello,

Pourquoi ne pas t'appuyer sur un logiciel déjà existant ? Je pense notamment à Dolibarr.
Je pense que tu le connais mais sait-on jamais.

[Charles.w]

Pour moi, si tu as la capacité de tracer ce qui se passe sur tes serveurs de base et que tu as des sauvegardes très régulières, ça doit passer...et je pense que c'est ce que font la plupart des entreprises manipulant ce type de données...ce n'est pas idéal, mais si tu te renseignes auprès de l'administration concernée, cela peut potentiellement parfaitement suffire...

Pour le reste, je maintient que MongoDB peut faire l'affaire, tes logs d'audit sont stockés dans une base qui peut / doit être protégée...et avec les mécanismes de sauvegarde et de réplication retardée, tu peux faire en sorte de ne jamais perdre de données en cas de mauvaise manip ou de hack.

[brice.wernet]

Il y a 6 heures, L33thium a écrit :

Mais je cherche le moyen le moins faillible de faire en sorte que la modification des entrées laisse une trace trop compliquée à supprimer.
Peut être un moyen mathématique ? une clé dans chaque entrée dépendant de la valeur de toutes les autres clés ? je sais pas

Je rejoins Charles.w: on ne demande pas de faire un truc techniquement ultra haute volée à base de physique quantique (cantique?).

Ton soft dois:

• Garantir qu'on ne peut pas supprimer des données: la fonctionnalité ne doit pas être dans le soft, et avec des bases de données à auto-incrément pour l'ID, c'est franchement c....t de supprimer "discrètement" des données.
• Garantir qu'on ne peut pas altérer les données: oui, tu peux ajouter un hash dépendant de l'identifiant et des données.
• Garantir qu'on peut regénérer les documents: il faut conserver en format PDF tout ce que tu peux (ou tout du moins un XML qui permette de regénérer le PDF à l'identique
• Et d'autres règles, comme avoir des n° de version clairs, des notes de suivi de version, tes mises à jour ne doivent pas altérer ou empêcher de générer des documents créés avec l'ancienne version ...

Ton meilleur moyen, c'est d'avoir un journal comptable irréprochable. C'est comme en gestion de stock: si quelqu'un s'est gourré, on ne peut pas modifier ce qu'il a saisi, il faut saisir un mouvement qui compense l'erreur.

Mais surtout: pour être certifié dois-tu payer quelque chose?

[L33thium]

mon code devrait être audité par un développeur tiers.
Je compte pas vraiment le faire (en tous cas pas dans un premier temps) mais je veux qu'il soit irréprochable en cas de contrôle.
Oui l'autoincrement, les valeurs peuvent être changées dans la clé primaire mais la méthode n'est pas évidente. ça complique la suppression déjà.

Après il y a les tables virtuelles de sqlite (views pour les autres je crois) comme full text search qui ne supportent pas la commande UPDATE. donc pour modifier une entrée il faut la supprimer puis en créer une autre ce qui laissera une trace dans le rowid et le log.

Je commence à entrevoir quelques pistes grâce a cette discussion avec vous merci et continuez svp, je suis encore un peu dans le brouillard là ^^

[L33thium]

id, hash, timestamp en clés primaires (donc non modifiables), le hash inclus le hash de la ligne précédente
en ajoutant en plus une signature générée par les identifiants de l'utilisateur et des liens vers les tables clients et stock ça devrait être pas mal comme ça.

Si je veux restaurer la base de données à un état antérieur pour faire disparaitre une journée par exemple ça devrait faire un écart anormal dans les timestamps.
C'est toujours pas inviolable mais ça me parait assez robuste pour un logiciel de facturation qui laisse d'autres traces.
Peut être ajouter un journal comptable simplifié en prime.

Un logiciel de caisse là je vois pas comment faire sans un tiers de confiance. Mais c'était pas le sujet.

Je me suis basé sur les recommandations du LNE, très intéressant. (l'AFNOR ne fournit pas gratuitement la documentation du NF525...)
https://www.lne.fr/sites/default/files/bloc-telecharger/referentiel-certification-systemes-caisse.pdf