Migratie en conversie: verklaring en regeling
Ik ben op zoek naar volgende voorbeelden (modellen): - een verklaring van conversie of migratie - re...
Zivver email archiveren en bijlagen apart opslaan
- dec 2020
- Roos van den Broek - Grave
- ·
- Aangepast 27 jun
- 2
- 38
Misschien kijk ik er faliekant aan voorbij en staat het al ergens op dit forum...
Ik zit met twee vragen:
1) Op welke wijze worden ge-Zivverde e-mails gearchiveerd? Ik heb begrepen dat men ze in een e-depot enkel niet versleuteld opneemt. Daar kan ik me iets bij voorstellen. Tegelijkertijd staat mij bij dat je wel extra metadata moet opnemen over versleuteling/encryptie.
Als ik de NEN 2082 eisen 121/123 erop na sla dan beschikt een RMA (ook als onderdeel van een zaaksysteem) over de mogelijkheid om metadata over de versleutelde doorzending, het type algoritme en het gebruikte encryptieniveau vast te leggen.
Hoe dit er in de praktijk uitziet, weet ik niet. Heeft iemand hier ervaring mee en weet iemand waar je dergelijke metadata in een systeem kan vastleggen en terugvinden?
2) Hoe en om welke redenen sla je e-mails met bijlagen op?
Mij is verteld dat je de bijlagen in een email, doorgaans een msg bestand, altijd apart moet opslaan omdat a) de bijlagen anders na verloop van tijd niet meer te openen zijn vanuit de email zelf en b) deze met een eigen omschrijving makkelijker terug te vinden zijn.
Klopt dit idd en zijn het nog steeds twee valide gronden om het zo te doen?
De noodzaak van het apart opslaan van bijlagen heb ik o.a. ontleend aan de volgende informatiebron:
E-mails archiveren: hoe en waarom? - Project TRACKS
Verken
VNG adviseert leden TMLO te gebruiken
De VNG heeft in een brief aan haar leden (van 16-10-2014) geadviseerd om het TMLO te benutten als stan...
Aanleveren aan een e-depot: Hoe ga je om met de metagegevens van een bestand?
In de redactiegroep koppelvlak TMLO is een discussie ontstaan over de manier van aanleveren van metage...
Reacties
Hoi Roos, ik had toevallig vorige week in de (besloten) groep Adviseurs Digitale Informatie een gerelateerde vraag gepost. Nog geen reacties helaas, ben dus ook benieuwd.... Mijn vraag luidde als volgt:
Ben benieuwd naar jullie mening over de beveiligde mails die gemeenten versturen, bijv via Zivver. Dit gebeurt steeds meer vanuit oogpunt van beveiliging en privacy. De bestanden in deze mails moet je binnen een bepaalde tijd downloaden, anders zijn ze niet meer toegankelijk.
Uit archieftechnisch oogpunt lijkt dit me niet wenselijk omdat de koppeling tussen verzonden bericht met bijlagen, die bij elkaar horen, verbroken wordt. Als de mail en bijlagen goed gearchiveerd worden in een DMS/ZS (vaak ook al lastig, in Sharepoint kun je mails wel opslaan maar niet met bijlagen) is het geen probleem. Er kunnen blijkbaar ook mails en bijlagen direct vanuit de Zivver app verstuurd worden met als gevolg dat medewerkers hun mails en bijlagen niet meer terug kunnen vinden en hun dossier niet compleet (meer) is. Hoor graag jullie mening en advies hierover richting gemeenten.
Dag Monique,
Het is tot op heden een nogal abstracte situatie. Er is duidelijk wel belangstelling voor het onderwerp maar de oplossing is kennelijk gecompliceerd.
Voor een deel kan ik concrete antwoorden geven. Vanuit mijn functie is het niet aan mij om te bepalen hoe lang de organisatie een e-mail/bericht versleuteld laat. Daarin zou ik de FG, beleidsadviseur informatiebeveiliging/CISO en proceseigenaar betrekken. Die moeten daar gezamenlijk iets van vinden.
Stap voor stap heb ik dit vraagstuk ontleed en kom op het volgende:
- In de Archiefregeling art. 26-2 staat dat bij overbrenging de bijbehorende decryptiesleutel dient te worden verstrekt. Dit geldt in elk geval voor zover encryptie ook bij overbrenging noodzakelijk blijft en is toegepast. Vermoedelijk is dit niet het geval omdat openbaarheid en toegankelijkheid ook via autorisatie en beperking van openbaarheid kan worden geregeld. E-depothouders geven doorgaans aan dat zij geen versleutelde informatie in het e-depot opnemen;
- In de NEN 2082 eis 121 staat dat het mogelijk moet zijn om in het RMA (ook als onderdeel van een zaaksysteem) metadata over de versleutelde doorzending, het type algoritme en het gebruikte encryptieniveau vast te leggen. Als de decryptiesleutel niet meer noodzakelijk is omdat het document openbaar is, dan zijn de gegevens hierover als document- en procesdata te beschouwen;
- Metadata zoals genoemd in eis 121 van de NEN 2082 worden bij overbrenging meegenomen conform hetgeen hierover in de TMLO onder 21.7-1 t/m 3 staat vermeld;
(Deze regel is onder voorbehoud omdat ik nog wil checken of hiermee in het TMLO/MDTO hetzelfde bedoeld wordt).
- Binnen de organisatie wordt of is beleid opgesteld over de duur waarop informatie/e-mail vanuit het oogpunt van het werkproces versleuteld moet blijven. Het is aan te raden dit beleid samen met de FG, CISO en proceseigenaar af te stemmen. Wellicht wordt ervoor gekozen om het niet versleuteld op te slaan/archiveren omdat de informatie ook op andere wijze kan worden beveiligd;
- Informeer bij de leverancier van het systeem of en waar de betreffende metadata over encryptie zijn opgeslagen en hoe deze, bijvoorbeeld bij een audit, zichtbaar kunnen worden gemaakt;
- Het is raadzaam bijlagen apart op te slaan en de registratie in de omschrijving specifiek(er) te maken. Daarbij blijft er wel een link tussen de e-mail en de bijlagen;
- Niet of minder gangbare bestandsformaten van bijlagen kunnen onder andere in PDF/A-1b worden opgeslagen. Daar waar dit niet mogelijk is, biedt de tabel van het Nationaal Archief over voorkeursformaten uitkomst. Als men de bijlagen apart opslaat en verrijkt met metadata, raad ik aan deze ook om te zetten naar een voorkeursformaat (met behoud van het origineel).
Hopelijk heb je hier wat aan. Wat Sharepoint betreft: het is volgens mij op diverse punten nog niet voldoende om in te zetten als Records managementsysteem.
Functionaliteiten voor e-mailarchivering, selectie en vernietiging en overbrenging zijn nog in ontwikkeling. Hier en daar zijn er wel oplossingen mogelijk door andere tools naast Sharepoint in te schakelen. Daar weet ik niet het fijne van.