Vier niveaus van verificatie

Waarom een backup niet genoeg is

Tijdens de bouw van Zekura bleek dat een repository die op de bronmachine kerngezond lijkt, op een verse machine onleesbaar kan zijn: de lokale cache maskeert het. Daarom verifieert Zekura zoals een restore, niet zoals de bron. Elke verificatie gebeurt op een aparte machine, de verifier, nooit op uw server.

De vier niveaus

Niveau	Wat	Hoe vaak
L1 Integriteit	de verifier verbindt met lege cache, leest elk object van de snapshot terug en controleert alle checksums	na elke run
L2 Steekproef	een steekproef van bestanden wordt teruggezet en per sha256 vergeleken met het origineel op de bron	dagelijks
L3 Toepassing	een databank wordt in een wegwerp-instantie geladen en nageteld tegen de metriek van de run; Nextcloud wordt opgestart en gescand; voor bestanden kunt u een eigen healthcheck opgeven	wekelijks
L4 Opstarten	een Proxmox-VM wordt als nieuwe VM teruggezet en opgestart; de tijd tot de guest agent antwoordt wordt gemeten	maandelijks

Op de pagina van een opdracht ziet u de drie stippen L1, L2, L3 en bij VM's ook L4. In de score weegt een diepere verificatie zwaarder: L1 telt voor 0,5, L2 voor 0,7, L3 voor 0,9 en L4 voor 1,0.

Wat u op de pagina van een run ziet

Bovenaan de duur, de hoeveelheid nieuwe data, het aantal bestanden en het ketenrecord. Daaronder per pad of onderdeel het aantal bestanden, de logische en nieuwe omvang en het aantal fouten. Dan de snapshot met manifest, root-object en de handtekening van de agent. En tot slot de verificaties, met per niveau het verdict, de verifier, de starttijd, het bewijsmateriaal (aantal objecten gelezen, duur, versie van de engine) en het ketenrecord.

Mislukt een run of een verificatie, dan wordt dat ook ondertekend en vastgelegd. Het register verzwijgt niets.

De ransomware-remmen

• Anomaliedetectie. Springt het aandeel nieuwe data in een run plots omhoog ten opzichte van de vorige runs, dan is dat hoe versleuteling door ransomware eruitziet. Zekura meldt het, schrijft het in de keten en zet een hold op de opdracht: er wordt niets meer opgeruimd tot u de hold opheft, zodat de snapshots van vóór de versleuteling blijven bestaan.
• De agent kan niets wissen. Zijn sleutel mag alleen toevoegen. Opruimen doet een aparte worker, en onder object lock zijn ook die verwijderingen alleen delete markers tot de bewaartermijn om is.
• Delete-marker-monitor. Dagelijks telt Zekura de delete markers onder elke bestemming en vergelijkt dat met wat de keten verklaart. Onverklaarde markers geven een kritieke melding; de data zelf is dan nog niet weg.
• 72 uur uitstel voor elke wijziging die uw bescherming verzwakt.

Wie wil zien hoe dat getest is: lab/attack-sim.sh in de repository speelt een aanvaller met root op een klanthost en de agent-sleutel, en herstelt daarna de data via het root-object uit de keten.