Decisions made on basis of these design discussion are listed in Design Decisions - Integrity.

Random sample and nonce/salt

Vi har diskuteret muligheden for at lade benene udvælge en stikprøve af data, hvis man ønsker at køre f.eks. checksumcheck på en tilfældig mængde filer. At lægge den funktionalitet i benene giver benene mulighed for at vælge filerne mere repræsentativt.

Hvis paging af requests benyttes som beskrevet ovenfor kan man som alternativ vælge en tilfældig mængde filnavne for at få en stikprøve.

For at bevare enkelhed i benene og undgå unødig ekstra funktionalitet foreslås at vi lader klienterne udvælge de tilfældige stikprøver.

For at sikre friske checksummer har vi diskuteret at genberegne dem ved at benytte et nonce. Se http://en.wikipedia.org/wiki/Cryptographic_nonce

I virkeligheden er det vi mener nok snarere et "salt" http://en.wikipedia.org/wiki/Salt_%28cryptography%29

Vi vil anbefale at vi indfører muligheden for at bruge et salt, når vi beder om checksummer fra benene. Det skal bruges når der er tvivl om filernes integritet, og evt. ved stikprøveanalyser, hvis det aftales i SLA.

Bemærk at et salt ikke kan bruges på checksumben.

Vi skal være sparsomme med at bruge salts, da det kræver processering fra benene.

Restoring mass loss of data on a pillar

Dataoverførsel efter massetab

Hvis et ben taber en hel disk - eller alle data - skal der overføres temmelig store mængder data for at genoprette datasikkerheden.

I det scenarie kan det give problemer at en klient skal tage initiativ til dataoverførsel, og det normale paradigme hvor ben ikke må kende hinanden kan blive en voldsom flaskehals. I den situation vil det normalt være vigtigt at der oprettes direkte forbindelse mellem benene, for at få udvekslet de store mængder data.

Der er to måder at løse problemet på, med svagheder og fordele ved dem begge.

Den ene måde er at lade protokollen understøtte direkte kontakt mellem to ben i katastrofescenarier. Kontakten kan f.eks. være beskyttet af særlige sikkerhedscertifikater, som kun kan frigives ved menneskelig godkendelse på de to ben. Kontakten kan stadig initieres fra integritetsklienten, men den efterfølgende kommunikation går direkte.

Den anden måde er at lade systemet generere oplysninger om de mistede data, der er tilstrækkelige til at identificere dem i det "raske" ben, og derefter lade det være op til organisatoriske procedurer at få genetableret data udenom systemet. I det tilfælde skal vi selvfølgelig stadig have tilstrækkelige tekniske løsninger til at checke at alt er gået godt efter genopretningen.

	Fordele	Ulemper
Teknisk løsning	Komplet automatik	Kompleks løsning, mange ressourcer for sjældent forekommende scenarie, svært at afprøve, kræver direkte kontakt mellem ben, risiko for at organisatorisk løsning alligevel benyttes i praksis
Organisatorisk løsning	Enkel at etablere, giver mulighed for at udveksle data på anden vis end online	Større risiko for menneskelige fejl, kræver adgang til data udenom bitarkivsoftware

Det er på baggrund af ovenstående fordele og ulemper vores anbefaling at vi benytter den organisatoriske løsning.

Kendskab til fysisk placering i ben

Vi har idag en drift udfordring i Netarkivet, idet man gerne vil vide den fysiske placering af en manglende fil eller rettere når der findes mange, hvilken disk kunne det så være der var dårlig.

. Problemet bør være benets, idet vi ikke ønsker sådanne detaljer på klien niveau.
. Udfordringen er at benet har mistet så mange data at den ikke selv kan finde ud af det. I tilfælde af integritetscheck er det klienten der hævder at have set den før.
. Den pæneste løsning er at informationen eksistere i logning fra benet. Logningen er del af audittrail, som også skal sikres. Derfor er den bedste løsning at vi finder ud af hvordan vi sikrer audit trails, og kan give denne information til benet i sådanne tilfælde

Browser not supported