Ihr Dokumentenmanagementsystem kann nicht nachweisen, wann ein Dokument archiviert wurde

Das Problem der Manipulation von Metadaten, das die Einhaltung gesetzlicher Vorschriften, Rechtsstreitigkeiten und die Sicherung von Beweismitteln gefährdet

Es gibt eine Frage, die bei der Beschaffung eines DMS selten gestellt wird, die aber gestellt werden sollte: Kann Ihr System zweifelsfrei nachweisen, dass ein Dokument an dem angegebenen Datum archiviert wurde? Nicht nur behaupten. Sondern nachweisen.

Für die meisten Organisationen lautet die ehrliche Antwort „nein“. Das Erstellungsdatum und das Archivierungsdatum, die in praktisch jedem gängigen Enterprise-Content-Management- und Dokumentenmanagementsystem gespeichert sind, stellen einen reinen Datenbankwert dar. Dieser kann geändert werden. In den meisten Fällen kann er unbemerkt und ohne Spuren im Prüfprotokoll von jedem geändert werden, der über ausreichende Datenbankzugriffsrechte verfügt. Dazu gehören Datenbankadministratoren, Systemadministratoren und in einigen Fällen auch Superuser auf Anwendungsebene.

Hierbei handelt es sich nicht um ein theoretisches Risiko. Es ist eine dokumentierte Realität in der gesamten ECM-Branche, die in Anbieterforen, Migrationsleitfäden und Entwicklerdokumentationen anerkannt wird. Dennoch werden die Auswirkungen auf Unternehmen, die sich bei der Compliance-Archivierung, der Unterstützung bei Rechtsstreitigkeiten und der Vorlage von Nachweisen gegenüber Aufsichtsbehörden auf diese Systeme verlassen, selten klar dargelegt.

 

Warum das Archivierungsdatum von Bedeutung ist

Wird ein Dokument als Beweismittel vorgelegt, ist das Datum seiner Erstellung oder seines Eingangs oft ebenso wichtig wie sein Inhalt. Ein Vertrag, eine Rechnung, eine Risikobewertung, eine interne Genehmigung: Jedes dieser Dokumente hat nur dann Beweiskraft, wenn seine Herkunft nachgewiesen werden kann. Aufsichtsbehörden, Gerichte und Wirtschaftsprüfer verlassen sich nicht einfach auf Ihre Aussage, dass ein Dokument zu einem bestimmten Zeitpunkt existierte. Sie erwarten eine lückenlose Nachweiskette.

Gängige DMS- und ECM-Plattformen speichern ihre Metadaten in relationalen Datenbanken. Das ist an sich kein Problem. Das Problem besteht darin, dass nichts verhindert, dass diese Daten auf der Datenbankebene geändert werden, wodurch alle von der Anwendung durchgesetzten Zugriffskontrollen und Prüfpfade umgangen werden.

 

Ein Werkzeug, das außerhalb seines vorgesehenen Einsatzbereichs verwendet wird

Nun ist es wichtig, den Anbietern gegenüber fair zu sein. Hier geht es nicht um Fahrlässigkeit oder Täuschung. Dokumentenmanagementsysteme wurden nicht als Systeme zur Beweissicherung konzipiert, und die Anbieter haben auch nie behauptet, dass dies der Fall sei.

Der ursprüngliche Zweck eines DMS bestand darin, den Lebenszyklus von Arbeitsdokumenten zu verwalten: Entwürfe zur Überprüfung weiterzuleiten, Überarbeitungen nachzuverfolgen, die aktuelle Version zu kontrollieren und Genehmigungsworkflows zu verwalten. Ein Vertrag durchläuft zehn Entwürfe, bevor er unterzeichnet wird. Ein Qualitätshandbuch erfordert jedes Jahr einen formellen Überprüfungszyklus. Eine technische Zeichnung muss geprüft werden, bevor sie für die Produktion freigegeben werden kann. Dies sind die Probleme, für deren Lösung DMS-Plattformen entwickelt wurden, und sie lösen sie gut. Das Erstellungsdatum ist in diesem Zusammenhang eine praktische Funktion, eine Möglichkeit, Suchergebnisse zu ordnen und zu erkennen, wann die Arbeit begonnen hat – es handelt sich nicht um ein Rechtsinstrument.

Im Laufe der Zeit haben Unternehmen ihre Investitionen in DMS-Systeme ganz vernünftigerweise unter die Lupe genommen und sich gefragt, ob diese auch als Langzeitarchiv. Die Dateien waren bereits vorhanden. Die Metadaten waren bereits vorhanden. Die Aufbewahrungsrichtlinien konnten konfiguriert werden. Es schien eine natürliche Erweiterung desselben Systems zu sein, und die Anbieter fügten archivierungsnahe Funktionen hinzu, um der Nachfrage gerecht zu werden.

Was sich nicht geändert hat, war die zugrunde liegende Architektur. Ein DMS ist als mehrschichtiges System aufgebaut: Eine relationale Datenbank enthält Metadaten, ein Dateisystem oder Objektspeicher enthält die eigentlichen Dateien, und die darüber liegende Anwendungsschicht sorgt für die Durchsetzung der Regeln. Diese Trennung der Ebenen ist grundlegend für die Funktionsweise dieser Systeme. Sie bedeutet auch, dass die Metadatenebene für jeden, der direkten Zugriff auf die Infrastruktur hat, nie weiter entfernt ist als eine Datenbankabfrage. Die Schutzmaßnahmen der Anwendungsschicht sind zwar wirksam, stellen jedoch nicht den einzigen Zugangsweg dar.

Die Beweissicherung erfordert eine andere architektonische Garantie: eine, bei der der Zeitstempel nicht lediglich vom System aufgezeichnet, sondern außerhalb desselben durch eine unabhängige Stelle so verankert wird, dass dies nicht unbemerkt rückgängig gemacht werden kann. Diese Garantie war schlichtweg nie Teil des DMS-Entwurfs. Den Anbietern kann kein Vorwurf gemacht werden, dass sie nichts entwickelt haben, wozu sie nie aufgefordert wurden. Das Risiko entsteht, wenn Unternehmen diese Systeme für einen Zweck einsetzen, für den sie nicht konzipiert wurden, ohne zu verstehen, was diese Lücke in der Praxis bedeutet.

 

Das Muster auf allen wichtigen Plattformen

OpenText Documentum

Documentum ist wohl der am ausführlichsten dokumentierte Fall. Der r_Erstellungsdatum Attribut eines dm_sysobject wird von der Anwendungsschicht als schreibgeschütztes Systemfeld behandelt, und weder mit den Standard-DFC/DQL-Operationen noch über den WebTop-Client lässt es sich ändern. Die zugrunde liegende dm_sysobject_s Auf die Tabelle in der Oracle- oder SQL Server-Datenbank kann jeder mit DBA-Zugangsdaten uneingeschränkt zugreifen. Praktiker haben in den eigenen Entwicklerforen von OpenText bestätigt, dass der Aufruf von exec_sql um zu aktualisieren r_Erstellungsdatum Die direkte Bearbeitung in dieser Tabelle funktioniert problemlos und wird routinemäßig bei umfangreichen Dokumentenmigrationen eingesetzt.

Das Gleiche gilt für r_modify_date. In einem französischen Entwicklerblog wird darauf hingewiesen, dass die einzige Möglichkeit, r_modify_date indem man Documentum vollständig umgeht, besteht darin, es direkt in der dm_sysobject_s Tabelle und liefert den genauen SQL-Befehl dafür.

OpenText Extended ECM (xECM / Content Server)

OpenText Content Server, die Grundlage von xECM, weist dieselbe Architektur auf. Während der Anwendungsserver Versuche, Erstellungsdatum Bei normalen API-Aufrufen besteht dieser Schutz lediglich auf der Anwendungsebene. Ein Thread im OpenText-Entwicklerforum, in dem es um die Datenmigration geht, bestätigt, dass das „Object Importer“-Tool selbst explizit direktes SQL verwendet, um beim Import das Überschreiben von Datumsangaben zu ermöglichen, und dass ein Eingriff in das System auf Datenbankebene möglich ist, wenn auch nicht unterstützt wird.4 Jede Organisation, die Zugriff auf DBA-Ebene auf ihr SQL Server- oder Oracle-Backend gewährt, hat damit implizit die Möglichkeit eingeräumt, diese Werte zu ändern.

IBM FileNet P8

IBM hat einen Technote veröffentlicht, in dem speziell darauf eingegangen wird, ob Erstellungsdatum und Urheber kann in einem IBM FileNet P8 Content Engine-Objektspeicher geändert werden. Allein die Existenz dieses Knowledge-Base-Artikels zeigt Ihnen, dass dieses Szenario allgemein bekannt ist. Darüber hinaus enthält die Dokumentation von IBM zum FileNet-Berechtigungsmodell ein spezifisches Zugriffsrecht namens “Bestimmte Systemeigenschaften ändern”, das es einem Benutzer, wenn es ihm gewährt wird, ermöglicht, diese normalerweise schreibgeschützten Systemdatenfelder über die Standard-API zu aktualisieren. Lokale Bereitstellungen, bei denen dieses Recht missbraucht wird oder bei denen Zugriff auf die zugrunde liegende Datenbank besteht, sind demselben Risiko ausgesetzt wie jede andere Plattform in dieser Liste.

IBM CMOD (Content Manager OnDemand)

IBM CMOD ist von allen Plattformen diejenige, die dieses Risiko am transparentesten darlegt. Die eigene Dokumentation des CMOD-Community-Wikis zu dem arsdoc-Aktualisierung In der Anweisung heißt es ausdrücklich: “Die Änderung von Indexdaten im Rahmen der normalen Verarbeitung birgt das Risiko, dass Ihr System nicht als zuverlässiges Archiv angesehen wird und die Genauigkeit des Systems vor Gericht in Frage gestellt werden könnte.”

CMOD weist zudem eine strukturelle Schwachstelle auf, die spezifisch auf seine Architektur zurückzuführen ist. Datumsangaben wurden in der Vergangenheit als Ganzzahlen gespeichert, die die Anzahl der Tage seit dem 1. Januar 1970 (UTC) darstellen. Das bedeutet, dass sie in einfachen Datenbanktabellen als reine Zahlenwerte ohne kryptografischen Schutz vorliegen.

Microsoft SharePoint

SharePoint ist wohl die Plattform mit den weitreichendsten Möglichkeiten von allen. Zwar bietet die browserbasierte Benutzeroberfläche keinen Zugriff auf die Erstellt Feld zur Bearbeitung; dieser Schutz ist jedoch rein oberflächlich. In der Dokumentation von Microsoft selbst sowie in den Anleitungen der Community wird ausführlich beschrieben, wie man ein Update durchführt Erstellt, Geändert, Erstellt von und Geändert von Felder mithilfe von PowerShell und dem Client-Side Object Model (CSOM). Ein vielgelesener Leitfaden auf SharePoint Diary zeigt genau, wie diese Systemfelder für jedes beliebige Dokument in einer Bibliothek auf einen beliebigen Wert gesetzt werden können. Der Autor merkt an, dass er die Manipulation dieser Metadatenfelder “nur dann” empfiehlt, „wenn es wirklich erforderlich ist“, bestätigt jedoch, dass die Funktion voll funktionsfähig ist. Bei SharePoint Online verhält es sich nicht anders: Der gleiche PowerShell-Ansatz funktioniert auch mit Microsoft 365.

Alfresco (Hyland)

Alfresco speichert Metadaten zu Dokumenten, darunter die cm:created Eigenschaft in einer relationalen Datenbank, bei der die Metadaten – wie in der offiziellen Dokumentation beschrieben – getrennt von den Inhaltsdateien in der Datenbank gespeichert werden. Während cm:created als schreibgeschützt über die CMIS-Schnittstelle gekennzeichnet ist, bietet der Alfresco Developer Hub eine einfache Abhilfe: durch den Aufruf von policyBehaviourFilter.disableBehaviour() Was den Aspekt der Nachvollziehbarkeit betrifft, kann ein Entwickler dann folgende Funktion aufrufen: nodeService.setProperty() um das Erstellungsdatum auf einen beliebigen Wert festzulegen. Für umfangreiche Importe wird in der offiziellen Dokumentation von Alfresco darauf hingewiesen, dass das Bulk-Import-Tool die automatische Systemverwaltung dieser Eigenschaften deaktiviert, damit die ursprünglichen Dateidaten beibehalten werden können; das bedeutet, dass das System selbst einen offiziellen Mechanismus zum Überschreiben dieser Eigenschaften bereitstellt.

M-Files

M-Files speichert Vault-Daten entweder in Firebird oder in Microsoft SQL Server. In der Entwicklerdokumentation wird darauf hingewiesen, dass einige Eigenschaftswerte fest integriert sind und automatisch gepflegt werden, wie beispielsweise das Erstellungsdatum; das Festlegen von Eigenschaften über VBScript oder das Vault Application Framework kann jedoch dazu führen, dass der Prüfpfad unterbrochen wird, sofern nicht mit der gebotenen Sorgfalt vorgegangen wird. Die Vault-Datenbank-Engine ist eine Standard-SQL-Server-Instanz: Jeder Datenbankadministrator mit Zugriff auf diese Instanz kann UPDATE-Anweisungen direkt auf Vault-Tabellen ausführen, ohne dass eine Vermittlung auf Anwendungsebene erforderlich ist. M-Files dokumentiert SQL Server ausdrücklich als unterstützte und empfohlene Datenbank-Engine für große Bereitstellungen.

Hyland OnBase

OnBase basiert auf SQL Server und folgt demselben Muster. In der Dokumentation von Hyland wird ausdrücklich davor gewarnt, direkte Änderungen am OnBase-Datenbankschema oder an den Daten vorzunehmen.17 Die Warnung selbst ist der Beweis: Ein direkter Datenbankzugriff ist möglich, und die Anwendung verlässt sich darauf, dass Administratoren davon keinen Gebrauch machen, anstatt sich auf eine kryptografische Garantie zu stützen, die Manipulationen verhindert.

Nuxeo (Hyland)

Nuxeo ist, das muss ich sagen, die Plattform, die am offensten über ihre Datenbankarchitektur berichtet. In der offiziellen Dokumentation zu VCS (Visible Content Store) heißt es: “Da die Daten transparent in SQL-Tabellen gespeichert werden, ist es sehr einfach, einen Blick darauf zu werfen und genau nachzuvollziehen, was vor sich geht. Für die Migration großer Datenmengen können Sie direkte SQL-Abfragen verwenden.” Die dc:created Das Feld ist eine reguläre Spalte in diesen SQL-Tabellen. Nuxeo positioniert den direkten SQL-Zugriff ausdrücklich als Funktion für Migrationsszenarien, was bedeutet, dass der “Schutz” dieses Feldes vollständig davon abhängt, dass niemand diese Funktion für weniger legitime Zwecke nutzt.

Laserfiche

Das Community-Forum von Laserfiche enthält einen Thread, der die Situation genau veranschaulicht. Ein Nutzer fragt, ob das Erstellungsdatum eines Eintrags geändert werden kann. Die Antwort fällt klar aus: “Aus technischen Gründen gibt es keine unterstützte Möglichkeit, das Erstellungsdatum eines Eintrags zu ändern. Die einzige Möglichkeit hierfür wäre die Aktualisierung der Inhaltsverzeichnis ”direkt in die Tabelle.“ Dieselbe Community bestätigt, dass Metadatenfelder “lediglich Daten in einer Datenbank” sind und dass SQL-Aktualisierungen technisch möglich sind, wenn auch nicht unterstützt werden.

SAP ArchiveLink

SAP ArchiveLink speichert die logische Zuordnung zwischen Anwendungsbelegen und ihren archivierten Entsprechungen in Standard-SAP-Datenbanktabellen, insbesondere in der TOA01 Tabellenfamilie. Bei diesen Tabellen handelt es sich um einfache relationale Datenbanktabellen innerhalb des SAP-Systems, auf die jeder Zugriff hat, der über Zugriffsrechte auf SAP-Basisebene oder auf die zugrunde liegende Datenbank verfügt. Das in diesen Tabellen gespeicherte Archivierungsdatum ist ein Standardfeld ohne eigenständige kryptografische Verankerung.

Jedes Homebrew-System

Die oben untersuchten Plattformen repräsentieren lediglich den kommerziellen Markt. Viele Organisationen nutzen maßgeschneiderte oder stark angepasste Dokumentenmanagementsysteme, die intern oder von spezialisierten Integratoren entwickelt wurden. Diese Systeme sind von derselben Sicherheitslücke nicht ausgenommen. Sie sind, wenn überhaupt, sogar noch stärker gefährdet.

Jedes DMS – ob kommerziell oder maßgeschneidert – basiert auf demselben architektonischen Prinzip: Eine relationale Datenbank enthält Metadaten, ein Dateisystem oder Objektspeicher enthält Dateien, und eine Anwendungsschicht setzt über beiden Ebenen Zugriffsregeln durch. Dies ist keine für einen bestimmten Anbieter typische Designentscheidung, sondern die natürliche Folge der Art und Weise, wie Unternehmenssoftware aufgebaut ist. Ein maßgeschneidertes System, das auf PostgreSQL, SQL Server, MySQL oder Oracle basiert, weist genau dieselbe Sicherheitslücke auf. Das Erstellungsdatum ist eine Spalte in einer Tabelle. Jeder, der über Datenbankzugangsdaten verfügt, kann es ändern.

Bei maßgeschneiderten Systemen fehlen häufig sogar die teilweisen Schutzmaßnahmen, die kommerzielle Plattformen bieten. Es gibt keine vom Anbieter gepflegte Protokollierung von Änderungen am Datenbankschema, keine Support-Community, die bekannte Manipulationswege dokumentiert, und oft keine Trennung zwischen der Rolle des Anwendungsadministrators und der des Datenbankadministrators. Die Person, die die Anwendung neu starten kann, ist dieselbe Person, die einen direkten SQL-UPDATE-Befehl ausführen kann. Das Unternehmen, das sein eigenes DMS entwickelt hat, hat damit neben allem anderen auch seine eigene Sicherheitslücke geschaffen.

 

Wie dies ausgenutzt werden kann

Es lohnt sich, genau zu klären, was “ausnutzbar” in der Praxis bedeutet, da das Risiko nicht nur von böswilligen Akteuren innerhalb einer Organisation ausgeht.

Das Szenario des unzufriedenen Administrators. Ein DBA oder Systemadministrator mit berechtigten Zugriffsrechten auf die zugrunde liegende Datenbank kann die Archivierungszeitstempel von Dokumenten ändern, die im Zusammenhang mit einem Rechtsstreit, einer behördlichen Untersuchung oder einer internen Revision stehen. Da die Änderung auf Datenbankebene vorgenommen wird, umgeht sie den Prüfpfad der Anwendung vollständig. Es wird kein Protokolleintrag erstellt.

Das Migrationsszenario als Vorwand. Datenmigrationen gehören in großen Organisationen zum Alltag. Jede der oben genannten Plattformen verfügt über ein dokumentiertes Verfahren, bei dem direkter Datenbankzugriff oder privilegierte API-Aufrufe genutzt werden, um die ursprünglichen Datumsangaben aus den Quellsystemen beizubehalten. Dies schafft eine scheinbar legitime Rechtfertigung für direkte Datenbankänderungen. Ein Insider kann behaupten, dass eine verdächtige Datumsabweichung eher auf ein Migrationsproblem als auf eine absichtliche Manipulation zurückzuführen sei.

Das Szenario eines Rechtsstreits. Wenn eine Organisation in einen Rechtsstreit verwickelt ist und Dokumente vorlegen muss, können die Anwälte der Gegenpartei die Echtheit von Zeitstempeln anzweifeln. Ohne einen unabhängigen kryptografischen Nachweis, dass ein Dokument zu einem bestimmten Datum archiviert wurde, kann die Organisation nicht nachweisen, dass die Metadaten seit Beginn des Rechtsstreits nicht verändert wurden. Sie kann lediglich die Aussage des Systems selbst vorbringen – und diese Aussage des Systems lässt sich ändern.

Das Szenario der aufsichtsrechtlichen Prüfung. Gemäß der DSGVO, der MiFID II, der DORA, dem belgischen Digitalgesetz und einer wachsenden Zahl branchenspezifischer Vorschriften müssen Organisationen nachweisen, dass Dokumente innerhalb festgelegter Fristen erstellt, empfangen oder archiviert wurden. Wenn die in einem DMS gespeicherten Datumsangaben unbemerkt geändert werden können, sind diese Nachweise wertlos.

 

Literaturverzeichnis

OpenText-Entwicklerforen (2011). Soll „r_creation_date“ manuell festgelegt werden?

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

JavaBlog.fr (2017). Documentum: Ländereinstellung, Speicherung des Datums, Aktualisierung des Datums der letzten Änderung / des letzten Bearbeiters (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-Entwicklerforen (2013). Dokument hochladen und Erstellungsdatum ändern.

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

IBM-Support (verschiedene). Ändern Sie die Felder „DateCreated“ und „Creator“ im Objektspeicher (OS) der IBM FileNet Content Engine.

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

IBM Support (2012). Es ist nicht möglich, Elemente aus einem Objektspeicher in einen anderen zu exportieren und zu importieren.

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

CMOD.wiki. arsdoc-Aktualisierung.

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

CMOD.wiki. Datums- und Zeitformate in Content Manager OnDemand.

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

SharePoint-Tagebuch (2016). SharePoint Online: Aktualisieren der Feldwerte „Erstellt von“ / „Geändert von“, „Erstellt am“ / „Geändert am“ mithilfe von PowerShell.

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

Alfresco-Dokumentation. Richten Sie Content-Speicher ein.

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

Alfresco Hub (2018). Wie lässt sich das Erstellungsdatum ändern?

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

Alfresco-Dokumentation. Erweiterungspunkt für das Inhaltsmodell.

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

M-Files-Entwicklerdokumentation. Aufbau des Tresorraums.

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

M-Files-Benutzerhandbuch. Konfiguration von Microsoft SQL Server-Datenbanken.

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

Hyland-Support. Datenbank-Referenzhandbuch: Ändern des Datenbankschemas.

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-Dokumentation. Visible Content Store (VCS)

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

Laserfiche Answers (Community-Forum). Änderung des Erstellungsdatums.

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

Laserfiche Answers (Community-Forum). Funktionsanfrage: Tool zur Massenaktualisierung von Metadaten.

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

SAP-Knowledge-Base-Artikel 1900309. Anleitung: Archivierung von ArchiveLink-Verbindungseinträgen aus den Tabellen TOA01.

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