5. Requirements voor het waarborgen en beoordelen van betrouwbaarheid van informatieobjecten

Bijsluiter

Toepassing

Dit zijn functionele eisen die als input kunnen dienen voor een programma van eisen voor de inkoop of ontwikkeling van een nieuw informatiesysteem. Deze eisen zijn bedoeld als template die door organisaties vertaald kunnen worden naar hun eigen situatie, toegespitst op het type applicatie dat wordt aangeschaft.

Waar mogelijk, worden er meerdere oplossingsopties aangedragen waarin organisaties binnen een project zelf een keuze kunnen maken.

Scope

Het waarborgen en beoordelen van betrouwbaarheid van informatieobjecten binnen of behorende bij een informatiesysteem.

Dit document kent het volgende uitgangspunt:
We gebruiken de term ‘betrouwbaarheid’ in plaats van ‘integriteit’ en ‘authenticiteit’ omdat deze in de praktijk een grote overlap vertonen.

Doelgroep

Medewerkers die zich bezighouden met archiving by design en betrokken zijn bij de aanschaf van een nieuw informatiesysteem.

Hoe is dit tot stand gekomen

Deze requirements zijn opgesteld door het scrumteam Archiving by Design.

Requirements

1. Event geschiedenis

Handelingen die geleid hebben tot creatie/vastlegging of mutatie van gegevens worden vastgelegd op een leesbare wijze.

Minimaal worden vastgelegd:

• het soort handeling

• door wie de handeling is uitgevoerd (de actor)

• op welk moment de handeling is uitgevoerd

In de event geschiedenis wordt niet vastgelegd of de actor de handeling had mogen uitvoeren (verwijzing naar requirement 2).

Rationale
Deze informatie wordt vastgelegd om op een later moment te kunnen reconstrueren hoe de creatie/vastlegging of mutatie van gegevens tot stand is gekomen. Op die manier kun je de betrouwbaarheid van gegevens toetsen.

2. Tegengaan van onbevoegde wijzigingen

Handelingen mogen uitsluitend worden uitgevoerd door actoren die daartoe bevoegd zijn.

Dit betekent minimaal het:

• het actueel houden en handhaven van het autorisatieschema waarin is vastgelegd welke gebruikers welke wijzigingen kunnen uitvoeren

Ook (mutaties in) de autorisaties worden bijgehouden en bewaard zolang als noodzakelijk.
Het is afhankelijk van de applicatie en het soort werkproces welke informatie van een gebruiker wordt vastgelegd, bijvoorbeeld of enkel een relatie naar een ‘IAM’ noodzakelijk is, of dat er persoonsgegevens in de applicatie zelf moeten worden opgeslagen. Vanuit een AVG-perspectief is het sowieso wenselijk om uitsluitend persoonsgegevens op te slaan als hier een noodzaak voor is.
Er zijn meerdere middelen om het tegengaan van onbevoegde wijzigingen te bereiken. Dit kan bijvoorbeeld door de data zelf te versleutelen (encryptie) of door de toegang tot de data te beperken (autorisaties).

Rationale
Deze informatie is nodig om te kunnen reconstrueren of iemand ten tijde van de handeling bevoegd was om deze handeling uit te voeren. Daarnaast wordt hiermee voorkomen dat er onbedoeld / ongewenste wijzigingen worden doorgevoerd. Hiervoor is het noodzakelijk dat er een informatiebeveiligingsbeleid organisatiebreed is vastgesteld.

3. Versiebeheer

Bij wijzigingen van een informatieobject wordt geautomatiseerd een nieuwe versie gecreëerd. Daarbij is het mogelijk om voorgaande versies in te zien. Versies zijn voorzien van een timestamp waarmee voor elk moment in de tijd duidelijk is welke versie op dat moment de actuele versie was.

Rationale
Bij bepaalde werkprocessen is het noodzakelijk om het ontstaan van een record te kunnen reconstrueren, bijvoorbeeld bij bestuurlijke besluitvorming of BRP-aanpassingen. In genoemde voorbeelden kan het voor het reconstrueren van het proces van totstandkoming van belang zijn de opeenvolgende concepten op te roepen. Naar gelang het doel kan het wenselijk zijn om eisen te stellen aan de vorm van versiebeheer.

4. Fixeren

Definitieve informatieobjecten en oude versies zijn gefixeerd, wat inhoudt dat er geen mutaties meer mogelijk zijn.
Dit valt op meerdere manieren te bereiken:

• het volledig beperken van de autorisaties: er zijn alleen nog leesrechten mogelijk

• het fixeren van het informatieobject zelf, bijvoorbeeld door een PDF/A van een tekstbestand te maken

Rationale
Voor bepaalde informatie is het wenselijk om mutaties na bepaald moment, zoals afhandeling van een zaak, niet meer mogelijk te maken. Het gaat er hierbij om dat actoren informatie niet meer (on)bedoeld kunnen wijzigen.

5. Mogelijkheden tot herstel

Het is mogelijk om informatie te herstellen naar een eerdere toestand als er een incident optreedt met informatieverlies tot gevolg.

Dit kan bijvoorbeeld door informatie te spiegelen naar een andere locatie, maar ook door backups te maken.
Bij de herstelde informatie dient in de event geschiedenis van elk hersteld informatie element vastgelegd te worden dat er herstel heeft plaatsgevonden én hoe oud het herstelde informatie element op moment van herstel was.

Rationale
In elke applicatie moeten maatregelen worden getroffen om informatieverlies tegen te gaan, bijvoorbeeld in het geval van een incident.

6. Betrouwbaarheid informatieobject vaststellen

Het is mogelijk om de betrouwbaarheid van een informatieobject vast te stellen, bijvoorbeeld door middel van een checksum of een digitaal waarmerk en/of logging van alle wijzigingen.

Rationale
Bestanden op een fileserver kunnen beschadigd raken, bijvoorbeeld door bitrot, maar ook bij migraties. Er moeten daarom maatregelen getroffen worden om de betrouwbaarheid (integriteit) op bestandsniveau te kunnen garanderen. Dit kan bijvoorbeeld geregeld worden door een checksum of een digitaal waarmerk vast te leggen in de applicatie en deze periodiek te vergelijken.

7. Back-up-protocol

De frequentie waarmee back-ups worden gemaakt is in verhouding tot de risico’s op informatieverlies.

Rationale
Deze eis is primair gericht op SAAS. Bij on-premise is dit geen eis aan een leverancier, maar kan dit met interne procesafspraken worden geregeld.
De frequentie van backups zal per geval bepaald moeten worden en is bijvoorbeeld afhankelijk van de waarde van de informatie en van de mogelijke risico’s en niet generiek te bepalen. Daarom is het in deze eis algemeen verwoord.
Als een back-up wordt teruggezet, dan moet uit de metadata bij de informatie duidelijk worden dat dit het geval is. Mede op basis hiervan kan bijvoorbeeld ook worden vastgesteld of er informatieverlies heeft opgetreden.