Votre système de gestion documentaire ne peut pas prouver quand un document a été archivé

Le problème de la manipulation des métadonnées qui met en péril la conformité, les litiges et la conservation des preuves

Il y a une question qui est rarement posée lors d'un achat de DMS, et qui devrait l'être : votre système peut-il prouver, au-delà de tout doute raisonnable, qu'un document a été archivé à la date qu'il revendique ? Ne vous contentez pas de l'affirmer. Prouvez-le.

Pour la plupart des organisations, la réponse honnête est non. La date de création et la date d'archivage stockées dans pratiquement tous les systèmes de gestion de contenu d'entreprise et de gestion de documents courants sont des valeurs de base de données simples. Elle peut être modifiée. Dans la plupart des cas, elle peut être modifiée silencieusement, sans laisser de trace dans le journal d'audit, par toute personne disposant d'un accès suffisant à la base de données. Cela inclut les administrateurs de base de données, les administrateurs système et, dans certains cas, les superutilisateurs au niveau de l'application.

Il ne s'agit pas d'un risque théorique. Il s'agit d'une réalité documentée dans l'ensemble du secteur de l'ECM, reconnue dans les forums des fournisseurs, les guides de migration et la documentation des développeurs. Pourtant, les implications pour les organisations qui dépendent de ces systèmes pour l'archivage de conformité, l'assistance en cas de litige et les preuves réglementaires sont rarement énoncées clairement.

 

L'importance de la date d'archivage

Lorsqu'un document est produit à titre de preuve, la date à laquelle il a été créé ou reçu est souvent aussi importante que son contenu. Un contrat, une facture, une évaluation des risques, une approbation interne : chacun de ces documents n'a de valeur probante que si sa provenance peut être établie. Les régulateurs, les tribunaux et les auditeurs ne se contentent pas de croire sur parole qu'un document a existé à une date donnée. Ils attendent une chaîne de contrôle.

Les plates-formes DMS et ECM classiques stockent leurs métadonnées dans des bases de données relationnelles. Ce n'est pas un problème en soi. Le problème est que rien n'empêche la modification de ces données au niveau de la base de données, en contournant tous les contrôles d'accès et les pistes d'audit mis en place par l'application.

 

Un outil utilisé en dehors de son enveloppe de conception

Il est important d'être juste envers les vendeurs. Il ne s'agit pas d'une histoire de négligence ou de tromperie. Les systèmes de gestion documentaire n'ont pas été conçus pour être des systèmes de préservation des preuves, et les fournisseurs n'ont jamais prétendu qu'ils l'étaient.

L'objectif initial d'un SGD était de gérer le cycle de vie des documents de travail : acheminement des projets pour examen, suivi des révisions, contrôle de la version actuelle, gestion des flux de travail d'approbation. Un contrat fait l'objet de dix versions avant d'être signé. Un manuel de qualité doit faire l'objet d'un cycle de révision formel chaque année. Un dessin technique doit être vérifié avant d'être mis en production. Ce sont les problèmes que les plates-formes DMS ont été conçues pour résoudre, et elles les résolvent bien. Dans ce contexte, la date de création est une caractéristique pratique, un moyen d'ordonner les résultats de la recherche et de comprendre quand le travail a commencé, et non un instrument juridique.

Au fil du temps, les organisations ont, à juste titre, examiné leur investissement dans le DMS et se sont demandé s'il pouvait également servir d'outil de gestion de l'information. archives à long terme. Les fichiers étaient déjà là. Les métadonnées étaient déjà là. Les politiques de conservation pouvaient être configurées. Cela semblait être une extension naturelle du même système, et les fournisseurs ont ajouté des fonctions d'archivage pour répondre à la demande.

Ce qui n'a pas changé, c'est l'architecture sous-jacente. Un SGD est construit comme un système à plusieurs niveaux : une base de données relationnelle contient les métadonnées, un système de fichiers ou un magasin d'objets contient les fichiers proprement dits, et la couche d'application située au-dessus applique les règles. Cette séparation des niveaux est fondamentale pour le fonctionnement de ces systèmes. Elle signifie également que la couche de métadonnées n'est jamais éloignée de plus d'une requête de base de données de toute personne ayant un accès direct à l'infrastructure. Les protections de la couche d'application sont réelles, mais elles ne constituent pas la seule voie d'accès.

La conservation des preuves nécessite une garantie architecturale différente : une garantie dans laquelle l'horodatage n'est pas simplement enregistré par le système, mais ancré à l'extérieur de celui-ci, par une autorité indépendante, d'une manière qui ne peut être annulée sans être détectée. Cette garantie n'a tout simplement jamais fait partie du cahier des charges du DMS. Les fournisseurs ne sont pas responsables de ne pas avoir construit quelque chose qu'on ne leur a jamais demandé de construire. Le risque survient lorsque les organisations déploient ces systèmes dans un but pour lequel ils n'ont pas été conçus, sans comprendre ce que cette lacune signifie dans la pratique.

 

Le même modèle sur toutes les grandes plateformes

OpenText Documentum

Documentum est peut-être le cas le plus largement documenté. Les r_creation_date sur un attribut dm_sysobject est traité comme un champ système en lecture seule par la couche d'application, et ni les opérations DFC/DQL standard ni le client WebTop ne permettent de le modifier. Mais le champ sous-jacent dm_sysobject_s dans la base de données Oracle ou SQL Server est entièrement accessible à toute personne disposant d'informations d'identification de l'administrateur de bases de données. Les praticiens ont confirmé dans les propres forums de développeurs d'OpenText que l'appel d'une table Oracle ou SQL est entièrement accessible à toute personne ayant des informations d'identification DBA. exec_sql pour mettre à jour r_creation_date directement dans ce tableau fonctionne sans problème et a été utilisé régulièrement lors de migrations de documents à grande échelle.

Il en va de même pour r_modify_date. Un blog de développeurs français note que la seule façon de modifier le r_modify_date en contournant entièrement Documentum est de le mettre à jour directement dans le système d'information. dm_sysobject_s et fournit le code SQL exact pour ce faire.

OpenText Extended ECM (xECM / Content Server)

OpenText Content Server, la base de xECM, présente la même architecture. Alors que le serveur d'application ignore les tentatives de mise en Date de création par le biais d'appels API normaux, cette protection n'existe qu'au niveau de l'application. Un fil de discussion du forum des développeurs d'OpenText sur la migration des données confirme que l'outil Object Importer lui-même utilise explicitement le SQL direct pour permettre l'annulation de la date lors de l'importation, et que le piratage du système au niveau de la base de données est possible, bien qu'il ne soit pas pris en charge.4 Toute organisation qui accorde un accès de niveau DBA à son serveur SQL ou à son backend Oracle a implicitement accordé la possibilité de réécrire ces valeurs.

IBM FileNet P8

IBM a publié une note technique traitant spécifiquement de la question de savoir si Date de création et Créateur peut être modifié sur un magasin d'objets IBM FileNet P8 Content Engine. L'existence même de cet article de la base de connaissances vous indique que le scénario est bien connu. En outre, la documentation d'IBM sur le modèle de permission FileNet comprend un droit d'accès spécifique appelé “Modifier certaines propriétés du système” qui, lorsqu'il est accordé à un utilisateur, permet de mettre à jour ces champs de date système normalement en lecture seule par le biais de l'API standard. Les déploiements sur site où ce droit est mal utilisé, ou lorsque la base de données sous-jacente est accessible, courent le même risque que toutes les autres plates-formes de cette liste.

IBM CMOD (Content Manager OnDemand)

IBM CMOD est la plus transparente de toutes les plateformes en ce qui concerne ce risque. La documentation du wiki de la communauté CMOD pour l'application Mise à jour de l'arsdoc indique explicitement : “La modification des données d'index dans le cadre d'un traitement normal crée un risque que votre système ne soit pas considéré comme une archive fiable et que, devant un tribunal, l'exactitude du système puisse être remise en question”.”

CMOD présente également une vulnérabilité structurelle propre à son architecture. Les dates ont toujours été stockées sous forme d'entiers représentant le nombre de jours écoulés depuis le 1er janvier 1970 UTC, ce qui signifie qu'elles sont stockées dans des tables de base de données ordinaires sous forme de simples valeurs numériques sans aucune protection cryptographique.

Microsoft SharePoint

SharePoint est sans doute la plateforme la plus permissive de toutes. Bien que l'interface utilisateur basée sur le navigateur n'expose pas les données de l Créé pour l'édition, cette protection est tout à fait superficielle. La documentation de Microsoft et les guides de la communauté décrivent en détail la manière de mettre à jour les fichiers Créé, Modifié, Créé par et Modifié par à l'aide de PowerShell et du Client-Side Object Model (CSOM). Un guide très lu sur SharePoint Diary montre exactement comment définir ces champs système à n'importe quelle valeur arbitraire pour n'importe quel document d'une bibliothèque. L'auteur indique qu'il ne recommande pas de manipuler ces champs de métadonnées “à moins que cela ne soit vraiment nécessaire”, mais il confirme que la capacité est entièrement fonctionnelle. SharePoint Online n'est pas différent : la même approche PowerShell fonctionne avec Microsoft 365.

Alfresco (Hyland)

Alfresco stocke les métadonnées des documents, y compris les éléments suivants cm:créé dans une base de données relationnelle, les métadonnées décrites dans la documentation officielle étant stockées dans la base de données séparément des fichiers de contenu. Tandis que les métadonnées sont stockées dans la base de données séparément des fichiers de contenu. cm:créé est marqué en lecture seule via l'interface CMIS, le hub des développeurs Alfresco contient une solution de contournement simple : en appelant policyBehaviourFilter.disableBehaviour() sur l'aspect contrôlable, un développeur peut alors appeler nodeService.setProperty() pour définir la date de création à n'importe quelle valeur. Pour les importations à grande échelle, la documentation officielle d'Alfresco indique que l'outil d'importation en bloc désactive la gestion automatique de ces propriétés par le système afin de préserver les dates d'origine des fichiers, ce qui signifie que le système lui-même fournit un mécanisme officiel pour les remplacer.

M-Files

M-Files stocke les données de l'espace de stockage dans Firebird ou Microsoft SQL Server. Sa documentation reconnaît que certaines valeurs de propriétés sont intégrées et maintenues automatiquement, comme la date de création, mais que la définition des propriétés à partir de VBScript ou du cadre d'application de l'espace de stockage peut entraîner la rupture de la piste d'audit si l'on n'y prend pas garde. Le moteur de base de données du coffre-fort est une instance standard de SQL Server : tout administrateur de bases de données ayant accès à cette instance peut émettre des instructions UPDATE sur les tables du coffre-fort directement, sans médiation de la couche applicative. M-Files présente explicitement SQL Server comme un moteur de base de données supporté et recommandé pour les grands déploiements.

Hyland OnBase

OnBase est construit sur SQL Server et suit le même modèle. La documentation de Hyland met explicitement en garde contre les modifications directes du schéma ou des données de la base de données OnBase.17 L'avertissement lui-même en est la preuve : l'accès direct à la base de données est possible, et l'application repose sur le choix des administrateurs de ne pas l'exercer plutôt que sur une quelconque garantie cryptographique empêchant la falsification.

Nuxeo (Hyland)

Nuxeo est, je dois le dire, la plateforme la plus franche de toutes en ce qui concerne l'architecture de sa base de données. Sa documentation officielle VCS (Visible Content Store) indique : “Les données étant stockées de manière transparente dans des tables SQL, il est très facile d'y jeter un coup d'œil et de comprendre exactement ce qui se passe. Pour la migration de données volumineuses, vous pouvez utiliser l'injection SQL directe”. La documentation de l dc:créé est une colonne normale dans ces tables SQL. Nuxeo positionne explicitement l'accès SQL direct comme une fonctionnalité pour les scénarios de migration, ce qui signifie que la “protection” de ce champ est entièrement conditionnée par le fait que personne ne choisisse d'utiliser cette fonctionnalité à des fins moins légitimes.

Laserfiche

Le forum communautaire de Laserfiche contient un fil de discussion qui illustre précisément la situation. Un utilisateur demande s'il est possible de modifier la date de création d'une entrée. La réponse est directe : “De par sa conception, il n'existe aucun moyen soutenu de modifier la date de création d'une entrée. La seule façon de le faire serait de mettre à jour le fichier toc directement à la table”.” La même communauté confirme que les champs de métadonnées sont “simplement des données dans une base de données” et que les mises à jour SQL sont techniquement possibles, bien qu'elles ne soient pas prises en charge.

SAP ArchiveLink

SAP ArchiveLink stocke l'affectation logique entre les documents d'application et leurs équivalents archivés dans des tables de base de données SAP standard, notamment la table TOA01 famille de tables. Ces tables sont des tables de base de données relationnelles simples au sein du système SAP, accessibles à toute personne disposant d'un accès au niveau de base SAP ou à la base de données sous-jacente. La date d'archivage enregistrée dans ces tables est un champ standard sans ancrage cryptographique indépendant.

Chaque système homebrew

Les plates-formes étudiées ci-dessus ne représentent que le marché commercial. De nombreuses organisations utilisent des systèmes de gestion documentaire personnalisés ou fortement personnalisés, développés en interne ou par des intégrateurs spécialisés. Ces systèmes ne sont pas exempts de la même vulnérabilité. Ils sont même plus exposés.

Tous les SGD, qu'ils soient commerciaux ou sur mesure, reposent sur le même principe architectural : une base de données relationnelle contient les métadonnées, un système de fichiers ou un magasin d'objets contient les fichiers, et une couche d'application applique les règles d'accès au-dessus des deux. Il ne s'agit pas d'un choix de conception propre à un fournisseur spécifique ; c'est la conséquence naturelle de la manière dont les logiciels d'entreprise sont construits. Un système personnalisé basé sur PostgreSQL, SQL Server, MySQL ou Oracle est exposé de la même manière. La date de création est une colonne dans une table. Toute personne disposant d'un accès à la base de données peut la modifier.

Les systèmes personnalisés ne bénéficient souvent pas des protections partielles offertes par les plates-formes commerciales. Il n'y a pas d'audit des modifications du schéma de la base de données maintenu par le fournisseur, pas de communauté d'assistance documentant les chemins de manipulation connus, et souvent pas de séparation entre le rôle d'administrateur de l'application et le rôle d'administrateur de la base de données. La personne qui peut redémarrer l'application est la même que celle qui peut exécuter une UPDATE SQL directe. L'organisation qui a créé son propre DMS a créé sa propre vulnérabilité, comme tout le reste.

 

Comment cela peut être exploité

Il convient d'être explicite sur la signification du terme “exploitable” dans la pratique, car le risque ne concerne pas seulement les mauvais acteurs au sein d'une organisation.

Le scénario de l'administrateur mécontent. Un DBA ou un administrateur système ayant un accès légitime à la base de données sous-jacente peut modifier les horodatages d'archives sur des documents relatifs à un litige, à une enquête réglementaire ou à un audit interne. Comme la modification est effectuée au niveau de la base de données, elle contourne entièrement la piste d'audit de l'application. Il n'y a pas d'entrée dans le journal.

Le scénario de migration comme couverture. Les migrations de documents sont monnaie courante dans les grandes organisations. Chaque plateforme mentionnée ci-dessus a un modèle documenté d'utilisation de l'accès direct aux bases de données ou d'appels API privilégiés pour préserver les dates d'origine des systèmes sources. Cela crée une justification apparemment légitime pour les modifications directes des bases de données. Un initié peut prétendre qu'une divergence de date suspecte est le résultat d'un problème de migration plutôt que d'une manipulation délibérée.

Le scénario du litige juridique. Lorsqu'une organisation est impliquée dans un litige et doit produire des documents, les avocats de la partie adverse peuvent contester l'authenticité des horodatages. Sans preuve cryptographique indépendante qu'un document a été archivé à une date donnée, l'organisation ne peut pas démontrer que les métadonnées n'ont pas été modifiées depuis le début du litige. Tout ce qu'elle peut offrir, c'est la parole du système, et la parole du système peut être modifiée.

Le scénario de l'audit réglementaire. En vertu du GDPR, de MiFID II, de DORA, de la loi belge sur le numérique et d'un nombre croissant de réglementations sectorielles, les organisations doivent démontrer que les documents ont été créés, reçus ou archivés dans des délais précis. Si les dates stockées dans un DMS peuvent être modifiées silencieusement, ces démonstrations sont creuses.

 

Références

Forums des développeurs OpenText (2011). Pour définir manuellement la date de création de r ?

https://forums.opentext.com/forums/developer/discussion/150200/to-set-r-creation-date-manually

JavaBlog.fr (2017). Documentum : Locale, stockage des dates, mise à jour de la date de dernière modification / dernier modificateur (r_modify_date).

http://www.javablog.fr/documentum-locale-date-storage-update-of-last-modification-date-last-modifier-r_normal_tz-r_tz_aware-r_modify_date.html

Forums des développeurs OpenText (2013). Téléchargez le document et modifiez la date de création.

https://forums.opentext.com/forums/developer/discussion/274033/upload-document-and-change-create-date

Support IBM (divers). Modifiez les champs DateCreated et Creator dans le magasin d'objets IBM FileNet Content Engine (OS).

https://www.ibm.com/support/pages/modify-datecreated-and-creator-fields-ibm-filenet-content-engine-object-store-os

IBM Support (2012). Impossible d'exporter et d'importer des éléments d'un magasin d'objets à un autre.

https://www.ibm.com/support/pages/unable-export-and-import-items-one-object-store-another

CMOD.wiki. Mise à jour de l'arsdoc.

https://cmod.wiki/index.php/arsdoc_update

CMOD.wiki. Formats de date et d'heure dans Content Manager OnDemand.

https://cmod.wiki/index.php/Date_and_Time_formats_in_Content_Manager_OnDemand

Agenda SharePoint (2016). SharePoint Online : Mettre à jour les valeurs des champs Created By / Modified By, Created / Modified à l'aide de PowerShell.

https://www.sharepointdiary.com/2016/11/update-created-by-modified-by-created-at-modified-at-values-using-powershell.html

Documentation Alfresco. Créez des magasins de contenu.

https://docs.alfresco.com/content-services/7.0/admin/content-stores/

Alfresco Hub (2018). Comment modifier la date de création ?

https://hub.alfresco.com/t5/alfresco-content-services-forum/how-to-modify-the-creation-date/td-p/233214

Documentation Alfresco. Point d'extension du modèle de contenu.

https://docs.alfresco.com/content-services/latest/develop/repo-ext-points/content-model/

Documentation du développeur de M-Files. Structure de la voûte.

https://developer.m-files.com/Getting-Started/Vault-Structure/

Guide de l'utilisateur M-Files. Configuration des bases de données Microsoft SQL Server.

https://userguide.m-files.com/user-guide/latest/eng/configuring_sql.html

Hyland Support. Guide de référence de la base de données : Modification du schéma de la base de données.

https://support.hyland.com/r/OnBase/Database-Reference-Guide/Foundation-23.1/Database-Reference-Guide/Appendix-A-Database-Use-Policy/Policy/Modifying-the-Database-Schema

Documentation Nuxeo. Magasin de contenu visible (VCS)

https://doc.nuxeo.com/nxdoc/vcs/

Laserfiche Answers (forum communautaire). Modification de la date de création.

https://answers.laserfiche.com/questions/49430/Modifying-the-creation-date

Laserfiche Answers (forum communautaire). Demande de fonctionnalité : Outil de mise à jour en masse des métadonnées.

https://answers.laserfiche.com/questions/190619/Feature-Request–Metadata-bulk-update-tool

Article 1900309 de la base de connaissances SAP. Comment faire : Archivage des entrées de connexion ArchiveLink des tables TOA01.

https://userapps.support.sap.com/sap/support/knowledge/en/1900309