Überprüfungen von Objekten und daraus resultierende Maßnahmen

Verschiedene objektbezogene Maßnahmen wirken den Risiken bezüglich der Langzeitverfügbarkeit von Dateien und deren Formaten entgegen und dienen dem langfristigen Erhalt der (techno)logischen Verfügbarkeit digitaler Objekte, sind also Grundlage für Bitstream, Logical und Semantic Preservation. Dazu gehören Maßnahmen wie Prüfsummenchecks, Virenprüfung, Dateiformatidentifizierung, Dateiformatvalidierung, Obsoleszenz-Erkennung und zur Dateiformatmigration und Emulation, die durch verschiedene Tools umgesetzt werden können.

Entsprechende Maßnahmen sollten durch die Datenproduzent*innen und -Kurator*innen so früh wie möglich im Entstehungsprozess der Ressourcen vorgenommen werden. 

Prüfsummen- und Virencheck

Prüfsummen

Eine Prüfsumme oder Checksum, auch als "Fingerabdruck" einer Datei bezeichnet, ist ein eindeutiger Wert, mit deren Hilfe die Integrität von Dateien überprüft werden kann. Sie berechnet sich direkt aus der Datei heraus.  Zur Erstellung von Prüfsummen werden verschiedenste Algorithmen genutzt, die sich hinsichtlich ihrer Komplexität und folglich auch ihrer Verlässlichkeit unterscheiden, zum Beispiel MD5, SHA-1 oder SHA-2-Prüfsummen. Bereits die Änderung nur eines Bits sollte dazu führen dass die Prüfsummen nicht mehr übereinstimmen und die Dateiversionen somit als nicht mehr konsistent angezeigt werden. Ein regelmäßig durchgeführter Prüfsummencheck ist daher eine der Grundlagen für die Bitstream Preservation.

Viren

Viren geraten üblicherweise eingebettet in Dateien in Endgeräte und können sich nach dem Öffnen der jeweiligen Datei ausbreiten und Schäden anrichten. Es treten verschiedenste Virentypen auf, zwei der bekanntesten Typen sind Malware und Ransomware. Während Malware unbemerkt Schäden am System selbst verursacht, verschlüsselt Ransomware Dateien und Daten auf einem Computer, um für die Freigabe Geld zu verlangen. Ein weiterer bekannter Virentyp sind Trojaner, über die Zugriff auf das System erlangt werden kann.

Zur Erkennung von Viren können Antivirensoftware-Tools verwendet werden. Darüber hinaus ist es auch hilfreich, Dateinamen auf verdächtige Erweiterungen zu prüfen. So weist z. B. die Endung .docm auf eine eine Word-Datei hin, die Makros enthält, die Schäden auf dem System anrichten könnten.

Prüfsummen- und Virencheck in Rosetta

In Rosetta werden für den Prüfsummencheck (in Rosetta: Fixity Check) und den Virencheck Plugins benötigt. Die Funktionen der vorinstallierten Plugins können durch Custom Plugins ergänzt werden. Der Virencheck wird in der Rosetta-Installation des hbz durch das Standard-Plugin durchgeführt. Ein Custom-Plugin wird verwendet, um als Prüfsumme SHA-512 zu nutzen. Weitere mögliche Prüfsummen-Algorithmen in Rosetta sind MD5, SHA-1, SHA-256 und CRC32. Soll ein Custom Plugin zur Überprüfung der Prüfsumme genutzt werden, muss der Plugin-Name in die Metadaten-Datei geschrieben, während für die anderen Prüfsummen die Angabe des jeweiligen Algorithmus reicht. Hierbei ist zu beachten, dass SHA-512 im Feld fixityType ohne Bindestrich geschrieben werden muss.

Den einzuliefernden Dateien können bereits im Vorfeld eine oder mehrere Prüfsumme mitgegeben werden, anderenfalls wird diese von Rosetta nach der Einlieferung errechnet. Der genutzte Algorithmus wird im Validation Stack festgelegt. Erfolgt die Errechnung der Prüfsumme erst in Rosetta, können nur Veränderungen an der Datei nach der Einlieferung überprüft werden, nicht Veränderungen, die während der Einlieferung, z.B. durch eine fehlerhafte Übertragung, passieren. Daher wird dringend empfohlen, Dateien schon vor der Einlieferung mit einer Prüfsumme zu versehen. Zwar kann Rosetta mehrere Prüfsummen kontrollieren, die Dauer des Fixity Checks wird dadurch aber deutlich länger.

Überprüfung von Dateiformaten

Tools zur Dateiformatüberprüfung wie DROID und JHOVE unterstützen dabei, formatbezogene Risiken zu erkennen und auf dieser Basis ggf. direkt Gegenmaßnahmen durchzuführen.

Diese Tools (DROID und JHOVE) sind darüber hinaus auch in Rosetta implementiert.
Damit ermöglicht Rosetta toolbasierte Prozesse zur Dateiformatidentifizierung und -validierung, als Basis für ein automatisierbares Risk Management zur Identifizierung obsoleter Dateiformate sowie für die Dateiformatmigration ausgewählter Dateiformate.

Empfehlungen zu dateiformatbezogenen LZV-Maßnahmen finden sich auch in den Levels of Digital Preservation der National Digital Stewardship Alliance.

dateiformatbezogene LZV-Maßnahmen gemäß der NDSA Levels of Digital Preservation (https://ndsa.org/publications/levels-of-digital-preservation)

Quelle: https://www.hbz-nrw.de/produkte/langzeitverfuegbarkeit/langzeitverfuegbarkeit-fuer-hochschulen/lzv-services

Dateiformatidentifizierung

Bei der Dateiformatidentifizierung wird toolbasiert eine Datei hinsichtlich ihres Dateiformats untersucht. Da die Dateiformatendung einer Datei (zum Beispiel .jpeg oder .tiff) nicht zur eindeutigen Identifizierung des Dateiformats ausreicht, müssen bei der Dateiformatidentifizierung weitere Kriterien geprüft werden. Dazu zählt u.a. die Signatur (File Signature bzw. Magic Number) eines Dateiformats, die in der jeweiligen Dateiformatspezifikation definiert wird. Die Signatur besteht aus einem oder mehreren Byte-Mustern, die typisch für ein bestimmtes Dateiformat sind.

Tools wie DROID und Siegfried gleichen dabei die spezifischen Kriterien zur Dateiformatidentifizierung bswp. mit der PRONOM-Dateiformatdatenbank ab. Dort sind Dateiformate registriert, beschrieben und mit einem Identifier (PRONOM Unique Identifier, PUID) versehen.

Dateiformatidentifizierung in Rosetta

In Rosetta kann die Dateiformatidentifizierung mittels DROID oder Siegfried erfolgen. Aktuell wird im hbz DROID genutzt.

DROID durchsucht dabei, wie oben beschrieben, bestimmte Bereiche einer Datei hinsichtlich dateiformattypischer Muster. Diese werden mit der ebenfalls in Rosetta integrierten Dateiformatdatenbank auf Basis der PRONOM-Datenbank abgeglichen. Das Ergebnis der Dateiformatidentifizierung wird in Rosetta in den administrativen Metadaten zur digitalen Ressource abgebildet.

Kommt es zu Fehlermeldungen bei der Dateiformatidentifizierung, werden die betreffenden SIPs in den Rosetta-Bereich Technical Issues verschoben, wo sie von einem Technical Analyst einer genaueren Prüfung unterzogen werden können.

Screenshot Formaterkennungsfehler im Rosetta-Bereich Technical Issues

Dateiformatvalidierung

Bei der Dateiformatvalidierung wird toolbasiert eine Datei hinsichtlich ihrer Konformität zur betreffenden Dateiformatspezifikation untersucht. Diese wird im vorausgehenden Schritt der Dateiformatidentifizierung ermittelt.

Das Validierungstool prüft dann in einem ersten Schritt, ob eine Datei die in der Spezifikation vorgeschriebenen Strukturelemente aufweist (Wohlgeformtheit). Danach wird geprüft, ob innerhalb dieser Elemente die semantischen Regeln der Dateiformatspezifikation befolgt werden (Validität). Entspricht eine Datei den Regeln der jeweiligen Spezifikation ihres identifizierten Dateiformats, gilt sie als wohlgeformt und valide. 

Wenn eine Datei invalide und damit im Sinne der Langzeitverfügbarkeit gefährdet ist, können daraufhin entsprechende Maßnahmen eingeleitet werden, die diesem Problem entgegenwirken z. B. Reparatur/Korrektur der Datei oder Austausch der Datei durch eine valide Kopie.

Dateiformatvalidierung in Rosetta

In Rosetta erfolgt die Formatvalidierung mittels der implementierten Software JHOVE. Diese durchsucht dabei mehrere Bereiche einer Datei und prüft, ob deren Struktur und Semantik konform zur jeweiligen Dateiformatspezifikation sind. In JHOVE sind verschiedene Module implementiert, mit denen Dateien verschiedener Formate validiert werden können.

Kommt es zu Fehlermeldungen bei der Dateiformatvalidierung innerhalb von Rosetta, werden die betreffenden SIPs in den Rosetta-Bereich Technical Issues verschoben, wo sie von einem Technical Analyst einer genaueren Prüfung unterzogen werden können.

Tasks, Task Chains und Validation Stacks in Rosetta

In Rosetta werden alle oben beschriebenen Prüfungen über Tasks geregelt. Ein Task ist ein individueller Prozess, der eine bestimmte Systemoperation ausführt, z. B. eine Virenprüfung oder das Extrahieren von technischen Metadaten aus Dateien. Mehrere Tasks können zu einer Reihe von geordneten Prozessen zusammengefasst werden, die dann hintereinander ablaufen. Ein solcher Prozessablauf heißt Task Chain. Task Chains werden vom LZV-Serviceteam im Administrationsbereich von Rosetta konfiguriert und können dann unter anderem als ausführbare Services im Web Editor von Intellectual Entities zur Verfügung gestellt werden. Die Task Chain, die automatisch bei jedem Ingest von Objekten nach Rosetta ausgeführt wird, heißt Validation Stack. Dieser wird vor allem auf Dateiebene angewendet.

In der Regel besteht der Validation Stack aus folgenden Tasks:

1. Überprüfung von Prüfsummen
2. Virenprüfung
3. Dateiformatidentifizierung
4. (Dateiformatvalidierung)
5. Extraktion von technischen Metadaten (TechMD Extract)
6. Prüfung auf in Rosetta definierte Risiken

Die Dateiformatvalidierung und die Extraktion von technischen Metadaten werden zurzeit im selben Task vom selben Plugin ausgeführt (TechMD Extract), können aber in zwei Tasks aufgesplittet und von unterschiedlichen Programmen ausgeführt werden, z. B. Metadatenextraktion mit JHOVE und Validierung mit VeraPDF. Da die Prozesse im Validation Stack aufeinander aufbauen, werden Fehler, die beim Ausführen dieser Tasks erkannt werden, alle im Technical Analyst-Tab Validation angezeigt.

Über die genannten Tasks hinaus, kann der Validation Stack auch entweder gekürzt oder erweitert werden. Mögliche Tasks, die beim Ingest ebenfalls ausgeführt werden können, sind zum Beispiel: Enrichment wie das Hinzufügen der IE zu einer Collection in Rosetta, das Zuweisen von Access Rights (AR) Policies zu REPs oder Files, das Erzeugen von Derivative Copies oder eine Metadatenvalidierug anhand der AR Policy. Die Validierung von Metadatendateien wie METS oder CSV ist in der Regel nicht Teil der initialen Task Chains, da diese Validierung automatisiert anhand des Metadata Profiles im Assessor durchgeführt wird. Siehe dazu: Fehlerbehebung im Assessor.

Für Änderungen am Validation Stack wenden Sie sich bitte an das LZV-Serviceteam.