On 2017-08-10 17:33, Richard PALO wrote: > Le 10/08/2017 à 16:21, Cédric Krier a écrit : > > On 2017-08-10 16:05, Cédric Krier wrote: > >> On 2017-08-10 14:47, Richard PALO wrote: > >>> Le 10/08/2017 à 10:22, Richard PALO a écrit : > >>>> un simple horodatage certifié (ISO/IEC 18014-3) ? > >>> > >>> pour ce cas plutôt simpliste, pourquoi pas servir de `openssl ts`? > >>> (avec la possibilité d'une autorité d'horodatage configurée localement) > >> > >> C'est encore mieux évidement si on peut réutiliser un standard (que je > >> ne connaissais pas). > > > > En fait, ça ne protège pas contre la suppression des derniers > > enregistrement signé. Il faut que le serveur de signature vérifie la > > non-rupture de la chaîne. > > > > En effet, j'ai réfléchi à cela. Je me suis dit qu'il existe plusieurs cas > de figure dont le cas d'une simple restauration depuis une sauvegarde d'une > base après une panne de quelque sorte. > > Ce sera incompréhensible si votre tiers vous met dans une situation où il > serait impossible (ou bien très difficile) de reprendre votre comptabilité. > > Je pense qu'il existe des possibilités à évaluer comment éviter (ou au moins > permettre à détecter) cette sorte de malveillance. > > Hélas, une fois détecté .. une restauration depuis une sauvegarde encore > valable > s'impose ainsi que la nécessité de reprendre les écritures perdues... > sinon la comptabilité risque d'être déclarée non-probante.
Après une seconde réfection, je pense que ce ne sera pas un réel problème d'attester une solution à base de "timestamping". Car soit c'est le cas d'une restauration après crash et donc un honnête utilisateur va réencoder les écritures manquantes qui auront un timestamp décaler (voir même avec un très petit intervalle). Dans un tel cas, il pourra se justifier par rapport au crash etc. Soit c'est un utilisateur malhonnête qui a mis en place du code qui supprime certaine écriture et re-fait le chaînage avec un nouveau timestamp. Dans ce cas, il y aura une incohérence importante entre les dates des mouvements et le timestamp qu'il ne pourra pas justifier. Et vis-a-vis de l'attestation, on pourra l'invalider sous prétexte que l'utilisateur a mis en place un contournement des protections. Donc il faudra pouvoir présenter une vérification basé sur des anomalies de décalage dans les timestamps. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/20170810162006.GG3701%40kei.
