Bitpreservering - integriteitschecks

Versie door RCEbot (overleg | bijdragen) op 9 aug 2024 om 03:21
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)

Introductie

Welke maatregelen worden genomen om de bit integriteit te monitoren?

Een tekening van een vrouw met een aantal grote groene check marks (v-tjes)
Checks

Wat is een integriteitscheck?

Een integriteitscheck of fixity check is een manier om te verifiëren dat een digitaal object niet op ongedocumenteerde wijze is gewijzigd. Een dergelijke check levert een checksum op: een unieke numerieke handtekening die is afgeleid van een digitaal bestand.

Integriteitschecks vinden idealiter plaats:

  • Voor opname
    De compleetheid van het digitale object moet worden gedefinieerd voorafgaand aan opname in het digitaal archief. Een digitaal archief kan overleggen met de producent/leverancier en deze vragen een checksum aan te leveren.
  • Tijdens opname
    Tijdens opname kunnen de ontvangen checksums worden vergeleken met de checksums die worden gegenereerd tijdens inname. Hiermee kan worden aangetoond of bits tijdens het transport verloren zijn gegaan.
  • Tijdens het beheer
    Tijdens alle verplaatsingen en bewerkingen van digitale objecten tijdens de preserveringsfase, geeft een integriteitscheck aanwijzingen of het digitale object nog steeds volledig en onbeschadigd is.

Wat is het risico als wij geen integriteitschecks uitvoeren?

Een gebrek aan procedures voor het uitvoeren van integriteitschecks kan ongemerkt verlies van data veroorzaken. Een van de belangrijkste doelstellingen van organisaties die streven naar duurzame toegang, is dat de digitale objecten in het digitaal archief niet (on)opzettelijk kunnen worden gewijzigd. Met het uitvoeren van een integriteitscheck kun je aantonen of een digitaal object de originele sequentie van bits heeft behouden. Dergelijk bewijs voor de integriteit en authenticiteit van het digitale object is essentieel voor vertrouwen in het digitaal archief.

Welke vragen kunnen wij onszelf stellen?

  • Gaan wij in gesprek met de producent of de leverancier van het digitale materiaal over gelijktijdig aan te leveren checksums, zodat deze na aanlevering van het digitale materiaal kunnen worden vergeleken?
  • Accepteert onze organisatie de aanlevering van digitaal materiaal zonder checksum?
  • Stelt onze organisatie checksums verplicht bij de producent?
  • Creëert ons digitaal archief zelf een checksum bij de ontvangst van digitale objecten?
  • Zijn er procedures geïmplementeerd om regelmatig de checksums te controleren?
  • Heeft ons digitaal archief procedures om met checksums om te gaan gedurende preserveringsacties?
  • Heeft onze organisatie de volledige procedure beschreven voor het monitoren van de integriteit van digitale objecten: plan, do, check, act?

Hoe verwoorden andere instellingen integriteitschecks?

Beeld en Geluid

5.2 Het waarborgen van de integriteit

Een digitaal archief moet voldoen aan de eis van de persistentie. Dat houdt in dat het materiaal er exact zo uit moet komen als het erin gegaan is, d.w.z. compleet en bit voor bit gelijk aan de originele bitconfiguratie. Deze data-integriteit wordt door Beeld en Geluid vastgesteld door het gebruik van ‘checksums’. Om een string te creëren die uniek is voor het object, worden alle bits in een specifieke hoeveelheid data verwerkt met behulp van een bepaald algoritme. Voorafgaand aan de instroom of op het moment dat het AV-object in het archiefmanagementsysteem wordt opgeslagen, wordt er een checksum berekend. Bij elke bewerking of verplaatsing van een versie van het object voor (hernieuwde) opslag, kopiëring, migratie of uitlevering aan gebruikers, wordt er een fixitycheck gebruikt om de checksum opnieuw te berekenen en deze te vergelijken met de eerder opgeslagen checksum. Dit wordt gedaan om er zeker van te zijn dat het object identiek is aan de data die in een eerdere fase werd overgebracht.

Voor erfgoedcollecties en commerciële diensten wordt standaard gewerkt met checksums die vóór instroom in het Digitaal Archief worden gemaakt en meegeleverd. Bij de collecties van publieke omroepen worden checksums niet meegeleverd door de depotgever. In dergelijke gevallen wordt door het softwareprogramma Baton een kwaliteitscontrole uitgevoerd om erachter te komen of het bestand een header en een footer bevat. Deze controle garandeert dat het bestand volledig is overgekomen en dat het transport niet halverwege is afgebroken. Ook kan via deze controle worden bevestigd dat het containerformaat uitgelezen kan worden. Fouten in het containerformaat en in de audio- en videodata worden hiermee namelijk opgespoord. Een header-and-footer-controle kan alleen uitgevoerd worden op bestanden die daadwerkelijk een footer hebben. Voor wat betreft de preserveringsformaten is dit nu alleen het geval bij MXF.

Digital Preservation Sound and Vision: Policy, Standards and Procedures

IISG

6. Preservation Strategy
Data integrity checks by the IISG:
Fixity: When the archival donor delivers the digital collection in an Archival Bag (in which checksums are included) fixity is checked as soon as the bag reaches the institute. If not, the institute will create an archival bag with MD5 checksums after arrival which is then ingested. In that case any data corruption that took place before the bag reached the institute falls outside the responsibility of the institute.

During the pre-ingest (resulting in a SIP) and ingest (resulting in an AIP and DIP) the checksums are validated by Archivematica.

During the pre-ingest, Archivematica produces SHA-256 checksums for each of the files. After the creation of the AIP, Archivematica performs a bag check which includes a final fixity check. After the storage of the AIP the fixity is regularly checked by the IISG.

IISG

York University Library

Policy Statement York University Library are committed to maintaining the integrity of objects in its care. This includes creating checksums for all archival format objects -- plus associated datastreams -- ingested into the repository, and regular fixity checking of those objects.

Implementation At the time of ingest an SHA1 checksum value is calculated for the archival format object, and is stored along the object in the repository.

Daily, a set number of files in the repository will have their current checksum calculated (using a single checksum) and compared to this stored value, which is expected to match. In cases where the calculated and stored values do not match, this is reported to the repository manager.

York University Library

Fout bij het aanmaken van de miniatuurafbeelding: Bestand is zoek
Deze wegwijzer is ontwikkeld binnen het Netwerk Digitaal Erfgoed (NDE) en wordt beheerd door de Rijksdienst voor het Cultureel Erfgoed. De illustraties zijn gemaakt door Jørgen Stamp voor digitalbevaring.dk, tenzij anders vermeld.
U kunt op deze kennisbank reageren via het reactieformulier.

Deze pagina is voor het laatst bewerkt op 9 aug 2024 om 03:21.