Uw documentbeheersysteem kan niet aantonen wanneer een document is gearchiveerd

Het probleem van metadatamanipulatie dat compliance, procesvoering en bewijsbewaring in gevaar brengt

Er is een vraag die zelden gesteld wordt tijdens een DMS-aankoop, en die zou moeten luiden: kan uw systeem buiten redelijke twijfel bewijzen dat een document gearchiveerd werd op de datum die het beweert? Niet alleen beweren. Bewijs het.

Voor de meeste organisaties is het eerlijke antwoord nee. De aanmaakdatum en archiveringsdatum die in vrijwel elk mainstream Enterprise Content Management en Document Management Systeem zijn opgeslagen, is een gewone databasewaarde. Deze kan worden gewijzigd. In de meeste gevallen kan deze geruisloos worden gewijzigd, zonder sporen achter te laten in het auditlogboek, door iedereen met voldoende toegang tot de database. Dat zijn databasebeheerders, systeembeheerders en in sommige gevallen superusers op applicatieniveau.

Dit is geen theoretisch risico. Het is een gedocumenteerde realiteit in de hele ECM-sector, die erkend wordt in forums van leveranciers, migratiegidsen en documentatie van ontwikkelaars. Toch worden de gevolgen voor organisaties die op deze systemen vertrouwen voor compliance-archivering, ondersteuning bij rechtszaken en wettelijk bewijs zelden duidelijk uiteengezet.

 

Waarom de archiefdatum belangrijk is

Wanneer een document als bewijsmateriaal wordt gebruikt, is de datum waarop het is gemaakt of ontvangen vaak net zo belangrijk als de inhoud. Een contract, een factuur, een risicobeoordeling, een interne goedkeuring: elk van deze documenten heeft alleen bewijskracht als de herkomst ervan kan worden vastgesteld. Toezichthouders, rechtbanken en auditors geloven u niet zomaar op uw woord dat een document op een bepaalde datum bestond. Ze verwachten een chain of custody.

Gangbare DMS- en ECM-platforms slaan hun metadata op in relationele databases. Dat is op zich geen probleem. Het probleem is dat niets voorkomt dat die gegevens op de databaselaag gewijzigd kunnen worden, waarbij alle toegangscontroles en audit trails die de applicatie afdwingt, omzeild worden.

 

Een gereedschap dat buiten zijn ontwerpbereik wordt gebruikt

Het is belangrijk om hier eerlijk te zijn tegenover de verkopers. Dit is geen verhaal over nalatigheid of misleiding. Documentbeheersystemen zijn niet ontworpen als systemen voor het bewaren van bewijs, en de verkopers hebben nooit beweerd dat ze dat wel waren.

Het oorspronkelijke doel van een DMS was om de levenscyclus van werkdocumenten te beheren: concepten ter controle doorsturen, revisies bijhouden, controleren welke versie actueel was, goedkeuringsworkflows beheren. Een contract doorloopt tien concepten voordat het wordt ondertekend. Een kwaliteitshandboek heeft elk jaar een formele revisiecyclus nodig. Een technische tekening moet worden gecontroleerd voordat deze kan worden vrijgegeven voor productie. Dit zijn de problemen waarvoor DMS-platforms gemaakt zijn, en ze lossen ze goed op. De aanmaakdatum is in deze context een gemaksfunctie, een manier om zoekresultaten te ordenen en te begrijpen wanneer het werk is begonnen, geen juridisch instrument.

Na verloop van tijd keken organisaties redelijkerwijs naar hun DMS-investering en vroegen zich af of het ook kon dienen als een langetermijnarchief. De bestanden waren er al. De metadata waren er al. Het bewaarbeleid kon geconfigureerd worden. Het leek een natuurlijke uitbreiding van hetzelfde systeem, en leveranciers voegden functies toe om aan de vraag naar archivering te voldoen.

Wat niet veranderde, was de onderliggende architectuur. Een DMS is opgebouwd als een gelaagd systeem: een relationele database bevat de metadata, een bestandssysteem of objectopslag bevat de eigenlijke bestanden en de applicatielaag erboven dwingt de regels af. Deze scheiding is fundamenteel voor de werking van deze systemen. Deze scheiding van niveaus is fundamenteel voor de manier waarop deze systemen werken. Het betekent ook dat de metadata laag nooit meer dan een database query verwijderd is van iemand met directe toegang tot de infrastructuur. De beschermingen van de applicatielaag zijn echt, maar ze zijn niet de enige weg naar binnen.

Het bewaren van bewijs vereist een andere architecturale garantie: een garantie waarbij de tijdstempel niet alleen door het systeem wordt geregistreerd, maar ook buiten het systeem wordt verankerd, door een onafhankelijke autoriteit, op een manier die niet ongedaan gemaakt kan worden zonder ontdekt te worden. Die garantie maakte simpelweg nooit deel uit van de DMS-ontwerpopdracht. Het is niet de schuld van de verkopers dat ze niet iets bouwen wat hen nooit gevraagd is. Het risico ontstaat wanneer organisaties deze systemen inzetten voor een doel waarvoor ze niet ontworpen zijn, zonder te begrijpen wat die leemte in de praktijk betekent.

 

Het patroon op elk belangrijk platform

OpenText Documentum

Documentum is misschien wel het meest gedocumenteerde geval. De r_creatie_datum attribuut op een dm_sysobject wordt door de applicatielaag behandeld als een alleen-lezen systeemveld, en noch de standaard DFC/DQL bewerkingen noch de WebTop client staan toe dat het gewijzigd wordt. Maar de onderliggende dm_sysobject_s tabel in de Oracle of SQL Server database is volledig toegankelijk voor iedereen met DBA-referenties. Praktijkmensen hebben op OpenText's eigen ontwikkelaarsforums bevestigd dat het aanroepen van uitvoeren_sql bijwerken r_creatie_datum rechtstreeks in die tabel werkt zonder enig probleem en wordt routinematig gebruikt in grootschalige documentmigraties.

Hetzelfde geldt voor r_wijzig_datum. Een Franse ontwikkelaarsblog merkt op dat de enige manier om r_wijzig_datum door Documentum volledig te omzeilen is om het direct in de dm_sysobject_s tabel, en geeft de exacte SQL om dit te doen.

OpenText Extended ECM (xECM / Content Server)

OpenText Content Server, de basis van xECM, vertoont dezelfde architectuur. Terwijl de applicatieserver pogingen negeert om AangemaaktDatum via normale API-aanroepen, bestaat deze bescherming alleen op de applicatielaag. Een discussie op het OpenText ontwikkelaarsforum over datamigratie bevestigt dat het hulpprogramma Object Importer zelf expliciet directe SQL gebruikt om datumoverschrijding bij het importeren mogelijk te maken, en dat het hacken van het systeem op databaseniveau mogelijk is, hoewel dit niet wordt ondersteund.4 Elke organisatie die DBA-toegang verleent tot de SQL Server of Oracle backend, heeft impliciet de mogelijkheid om deze waarden te herschrijven.

IBM FileNet P8

IBM heeft een technote gepubliceerd die specifiek ingaat op de vraag of DateCreated en Schepper gewijzigd kan worden op een IBM FileNet P8 Content Engine object store. Alleen al het bestaan van dit kennisbankartikel vertelt u dat het scenario bekend is. Verder bevat IBM's documentatie over het FileNet toestemmingsmodel een specifiek toegangsrecht met de naam “Bepaalde systeemeigenschappen wijzigen,” waarmee, indien toegekend aan een gebruiker, die normaal gesproken alleen-lezen velden met systeemdata kunnen worden bijgewerkt via de standaard API. On-premises implementaties waar dit recht misbruikt wordt, of waar de onderliggende database toegankelijk is, lopen hetzelfde risico als elk ander platform in deze lijst.

IBM CMOD (Content Manager OnDemand)

IBM CMOD is van alle platforms het meest transparant over dit risico. De eigen documentatie van de CMOD community wiki voor de arsdoc update commando staat expliciet: “Het wijzigen van indexgegevens als onderdeel van normale verwerking creëert het risico dat uw systeem niet als een betrouwbaar archief wordt beschouwd, en in een rechtszaak kan de nauwkeurigheid van het systeem in twijfel worden getrokken.”

CMOD heeft ook een structurele kwetsbaarheid die specifiek is voor zijn architectuur. Datums worden van oudsher opgeslagen als gehele getallen die het aantal dagen sinds 1 januari 1970 UTC vertegenwoordigen, wat betekent dat ze in gewone databasetabellen staan als eenvoudige numerieke waarden zonder cryptografische bescherming.

Microsoft SharePoint

SharePoint is misschien wel het meest tolerante platform van allemaal. Hoewel de browsergebaseerde UI de Gemaakt veld voor bewerking, is deze bescherming volledig oppervlakkig. Microsofts eigen documentatie en communitygidsen beschrijven in detail hoe u het volgende kunt bijwerken Gemaakt, Gewijzigd, Gemaakt door en Gewijzigd door velden met PowerShell en het Client-Side Object Model (CSOM). Een veelgelezen gids op SharePoint Diary laat precies zien hoe u deze systeemvelden op elke willekeurige waarde kunt instellen voor elk document in een bibliotheek. De auteur merkt op dat hij niet aanbeveelt om deze metadatavelden te manipuleren “tenzij het echt nodig is”, maar bevestigt dat de mogelijkheid volledig functioneel is. SharePoint Online is niet anders: dezelfde PowerShell-aanpak werkt ook voor Microsoft 365.

Alfresco (Hyland)

Alfresco slaat documentmetadata op, inclusief de cm:aangemaakt eigendom, in een relationele database, met de metadata beschreven in de officiële documentatie zoals apart opgeslagen in de database van de inhoudsbestanden. Terwijl cm:aangemaakt is gemarkeerd als alleen-lezen via de CMIS interface, bevat de Alfresco developer hub een eenvoudige workaround: door het aanroepen van policyBehaviourFilter.disableBehaviour() op het controleerbare aspect, kan een ontwikkelaar vervolgens nodeService.setProperty() om de aanmaakdatum op een willekeurige waarde in te stellen. Voor grootschalige importen merkt Alfresco's eigen officiële documentatie op dat de Bulk Import tool het automatische systeembeheer van deze eigenschappen uitschakelt zodat de originele bestandsdata bewaard kunnen blijven, wat betekent dat het systeem zelf een officieel mechanisme biedt om ze te overschrijven.

M-Files

M-Files slaat kluisgegevens op in Firebird of Microsoft SQL Server. De documentatie van de ontwikkelaar erkent dat sommige waarden van eigenschappen ingebouwd zijn en automatisch onderhouden worden, zoals de aanmaakdatum, maar dat het instellen van eigenschappen vanuit VBScript of het Vault Application Framework ervoor kan zorgen dat het controlespoor verbroken wordt, tenzij u voorzichtig bent. De vault database-engine is een standaard SQL Server-instantie: elke DBA met toegang tot die instantie kan rechtstreeks UPDATE-statements tegen vault-tabellen uitvoeren, zonder tussenkomst van de applicatielaag. M-Files documenteert SQL Server expliciet als een ondersteunde en aanbevolen database-engine voor grote implementaties.

Hyland OnBase

OnBase is gebouwd op SQL Server en volgt hetzelfde patroon. Hyland's eigen documentatie waarschuwt expliciet voor het maken van directe wijzigingen in het OnBase databaseschema of de gegevens.17 De waarschuwing zelf is het bewijs: directe databasetoegang is mogelijk, en de toepassing vertrouwt erop dat beheerders ervoor kiezen om dit niet te doen in plaats van op een cryptografische garantie die knoeien voorkomt.

Nuxeo (Hyland)

Nuxeo is, moet ik zeggen, het meest openhartige platform van allemaal over zijn database-architectuur. In de officiële VCS (Visible Content Store) documentatie staat het volgende: “Omdat gegevens transparant worden opgeslagen in SQL-tabellen, is het heel eenvoudig om ze te bekijken en precies te begrijpen wat er aan de hand is. Voor de migratie van grote gegevens kunt u directe SQL-injectie gebruiken.” De dc:created veld is een gewone kolom in die SQL-tabellen. Nuxeo positioneert directe SQL-toegang expliciet als een functie voor migratiescenario's, wat betekent dat de “bescherming” van dit veld volledig afhankelijk is van het feit of niemand ervoor kiest om deze functie voor minder legitieme doeleinden te gebruiken.

Laserfiche

Laserfiche's community forum bevat een thread die de situatie precies illustreert. Een gebruiker vraagt of de aanmaakdatum van een entry gewijzigd kan worden. Het antwoord is direct: “By design, there is no supported way to change an entry's creation date. De enige manier om dit te doen is door de toc tafel direct.” Dezelfde gemeenschap bevestigt dat metadatavelden “gewoon gegevens in een database” zijn en dat SQL-updates technisch haalbaar zijn, hoewel ze niet worden ondersteund.

SAP ArchiefLink

SAP ArchiveLink slaat de logische toewijzing tussen toepassingsdocumenten en hun gearchiveerde tegenhangers op in standaard SAP databasetabellen, met name de TOA01 tabellenfamilie. Deze tabellen zijn gewone relationele databasetabellen binnen het SAP-systeem, toegankelijk voor iedereen met SAP-basistoegang of toegang tot de onderliggende database. De archiefdatum die in deze tabellen wordt vastgelegd, is een standaardveld zonder onafhankelijke cryptografische verankering.

Elk zelfbouwsysteem

De hierboven genoemde platforms vertegenwoordigen alleen de commerciële markt. Veel organisaties werken met op maat gemaakte of sterk aangepaste documentbeheersystemen die intern of door gespecialiseerde integrators zijn ontwikkeld. Deze systemen zijn niet gevrijwaard van dezelfde kwetsbaarheid. Ze zijn zelfs nog kwetsbaarder.

Elk DMS, commercieel of op maat gemaakt, is gebouwd volgens hetzelfde architectuurprincipe: een relationele database bevat metadata, een bestandssysteem of objectopslag bevat bestanden, en een applicatielaag dwingt toegangsregels af boven beide. Dat is geen ontwerpkeuze die eigen is aan een specifieke leverancier; het is het natuurlijke gevolg van hoe bedrijfssoftware wordt gebouwd. Een aangepast systeem dat gebouwd is op PostgreSQL, SQL Server, MySQL of Oracle heeft precies dezelfde blootstelling. De aanmaakdatum is een kolom in een tabel. Iedereen met databasereferenties kan deze veranderen.

Aangepaste systemen hebben vaak zelfs niet de gedeeltelijke bescherming die commerciële platforms bieden. Er is geen door de leverancier beheerde controle van wijzigingen in databaseschema's, geen ondersteuningsgemeenschap die bekende manipulatiepaden documenteert en vaak is er geen scheiding tussen de rol van applicatiebeheerder en de rol van databasebeheerder. De persoon die de applicatie opnieuw kan opstarten is dezelfde persoon die een directe SQL UPDATE kan uitvoeren. De organisatie die haar eigen DMS heeft gebouwd, heeft haar eigen kwetsbaarheid gebouwd, samen met al het andere.

 

Hoe dit kan worden uitgebuit

Het is de moeite waard om expliciet te zijn over wat “exploiteerbaar” in de praktijk betekent, omdat het risico niet alleen betrekking heeft op slechte actoren binnen een organisatie.

Het scenario van de ontevreden beheerder. Een DBA of systeembeheerder met legitieme toegang tot de onderliggende database kan archieftijdstempels wijzigen op documenten die betrekking hebben op een geschil, een regelgevend onderzoek of een interne audit. Omdat de wijziging in de databaselaag wordt aangebracht, wordt het controlespoor van de applicatie volledig omzeild. Er is geen logboekvermelding.

Het migratiescenario als cover. Documentmigraties zijn routine in grote organisaties. Elk hierboven besproken platform heeft een gedocumenteerd patroon van het gebruik van directe databasetoegang of bevoorrechte API-oproepen om originele data van bronsystemen te behouden. Dit creëert een legitiem lijkende rechtvaardiging voor directe databasewijzigingen. Een insider kan beweren dat een verdacht datumverschil het gevolg was van een migratieprobleem in plaats van opzettelijke manipulatie.

Het scenario voor juridische geschillen. Wanneer een organisatie betrokken is bij een rechtszaak en documenten moet overleggen, kunnen de advocaten van de andere partij de authenticiteit van tijdstempels in twijfel trekken. Zonder onafhankelijk cryptografisch bewijs dat een document op een bepaalde datum werd gearchiveerd, kan de organisatie niet aantonen dat de metadata niet zijn gewijzigd sinds het ontstaan van het geschil. Het enige wat de organisatie kan bieden is het woord van het systeem zelf, en het woord van het systeem kan veranderd worden.

Het wettelijke controlescenario. Onder GDPR, MiFID II, DORA, de Belgische Digitale Wet en een groeiend aantal sectorspecifieke regelgevingen, moeten organisaties aantonen dat documenten binnen bepaalde tijdsbestekken werden aangemaakt, ontvangen of gearchiveerd. Als de data die in een DMS zijn opgeslagen stilzwijgend kunnen worden gewijzigd, zijn die aantoonbare termijnen hol.

 

Referenties

OpenText Developer Forums (2011). Om r_creation_date handmatig in te stellen?

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

JavaBlog.fr (2017). Documentum: Locale, Datumopslag, Bijwerken van laatste wijzigingsdatum / laatste wijzigingsfactor (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

OpenText Developer Forums (2013). Document uploaden en Aanmaakdatum wijzigen.

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

IBM Ondersteuning (diverse). Wijzig de velden DateCreated en Creator in IBM FileNet Content Engine object store (OS).

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

IBM Ondersteuning (2012). Kan geen items exporteren en importeren van het ene objectarchief naar het andere.

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

CMOD.wiki. arsdoc update.

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

CMOD.wiki. Datum- en tijdnotaties in Content Manager OnDemand.

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

SharePoint-agenda (2016). SharePoint Online: Created By / Modified By, Created / Modified Field Values bijwerken met PowerShell.

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

Alfresco-documentatie. Content stores instellen.

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

Alfresco Hub (2018). Hoe de aanmaakdatum wijzigen?

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

Alfresco-documentatie. Uitbreidingspunt inhoudsmodel.

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

M-Files documentatie voor ontwikkelaars. Kluisstructuur.

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

Gebruikershandleiding voor M-Files. Microsoft SQL Server-databases configureren.

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

Hyland-ondersteuning. Database Naslaggids: Het databaseschema wijzigen.

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

Nuxeo Documentatie. Zichtbare inhoud winkel (VCS)

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

Laserfiche Answers (gemeenschapsforum). De aanmaakdatum wijzigen.

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

Laserfiche Answers (gemeenschapsforum). Functieverzoek: Hulpprogramma voor bulkupdates van metagegevens.

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

SAP Knowledge Base Artikel 1900309. HowTo: ArchiveLink verbindingsitems archiveren van tabellen TOA01.

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