Hvor hulen blev den fil nu af

Af Christian Stage, Stage One Computing A/S

Kender I det når man ikke lige kan finde det vigtige dokument man skrev forleden, og det er i dag det SKAL afleveres …? Situationen er måske ikke helt ukendt, og det sker vel lejlighedsvis at man har forlagt, om ikke andet, en version af et dokument, hvor man helt sikkert havde indsat rettelser der var væsentlige, men man kan ikke lige huske hvilke.

Denne situation kan blive meget forværret når man står ved en inspektion, og der bliver spurgt til hvor de sande data befinder sig. Mange systemer omkring os generer data, som vi efterfølgende kopierer og flytter i ét væk.

I gamle dage opsamlede vi alle relevante data, og lagde dem i en fin veldefineret filstruktur – På en server hvis det skulle være meget fint.

Sådan er det ikke længere. Nu udveksler vi data via særegne kombinationer af filsharingtjenester (f.eks. WeShare, TransferNow, DropBox, Dracoon, Box etc.) SharePoint, Cloud fildrev, OneDrive, Teams, samt en blanding af diverse CMS’er (CMS = Content Management Systems, eller det vi kort og præcist kalder dokument­styrings­systemer på godt Dansk).

Brugen af alle disse forskellige platforme og systemer gør jo livet en anelse mere besværligt, hvis man lejlighedsvis skulle forsøge at beholde et overblik. Nogle af de udfordringer der følger med dette sammensurium af forskellige systemer, er strømlining af retentionstider, adgangs­kontrol, overførsel mellem de forskellige systemer, metadata, og arkivering. Jeg vil lige forsøge at give et overblik over de forskellige udfordringer der findes, samt lidt inspiration til krav man kan (eller bør) sætte.

Baggrunden for at tage dette emne op var egentligt at jeg for nyligt bemærkede at en de virksomheder jeg arbejder for, var begyndt at benytte Teams filhåndteringsfunktion til at udveksle projekt­- og kvalitetsrelaterede filer, i forventning om at de blev liggende dér. Filerne ligger jo i virkeligheden ikke i Teams, men i den tilknyttede SharePoint installation eller overføres til OneDrive afhængigt af hvordan man benytter Teams, eller har sat Teams op – Den kvikke QA bemærkede nok de 2 gange ”eller” i denne sætning?

< Hvor længe er egentlig min dataretention >

Forskellige systemer har forskellige standarder med hensyn til retentionstider. De fleste CMS systemer er opbygget således at man enten skal rydde op manuelt, eller at man skal ind og definere for en organisation, dokumenttype eller lignende hvordan retention skal opføre sig.

Sådan er Teams f.eks. også, lidt afhængigt af hvor filerne placeres, men Teams har en default opbevaringstid (jeg tro faktisk den default er så lav som 3 måneder). Der er også mulighed for at styre det via de såkaldte ”policies” (en policy er en slags standardkonfiguration man kan sætte for et defineret område på ens netværk) man kan påtrykke via et Microsoft domæne på de pågældende OneDrive’s eller SharePoint installationen der ligger nedenunder Teams

I fildelingstjenester kan man som hovedregel beholde sine data indtil man sletter dem, eller indtil man stopper med at betale for dem. Det er også muligt at sætte regler op for opbevaringstider i de fleste fildelingstjenester. Her skal jeg lige erindre om vigtigheden af en serviceaftale med den pågældende leverandør, samt en vurdering af leverandørens soliditet …

Egne CMS-systemer er jo lettere at styre, så det kan vi godt lide.

< Er adgangskontrol = kontrol af at alle har adgang >

Nogle af de omtalte systemer er designet til benhårdt at styre adgangskontrol, herunder især at styre adgangsbegrænsninger. Andre systemer er bygget til netop det modsatte!

De fleste CMS systemer er bygget til at styre adgange, ud fra projektorganisation, roller o.s.v.. Andre systemer, herunder f.eks. SharePoint er bygget netop til at give flest muligt adgang til data, ud fra et ønske om at fremme samarbejde på tværs af en organisation. Dette betyder i praksis at man proaktivt skal ind og beskytte sin information, frem for at give adgang til sin information ud fra et behovsmæssigt standpunkt.

En af de normale arbejdsmetoder indenfor medicinalbranchen, er netop at sige at noget som udgangspunkt er ”formodet dårligt”, indtil det er kontrolleret ”godt” (sådan fungerer de fleste kontrolfunktioner i maskiner i hvert fald). Hvis man overfører denne strategi på sine dokumentadgange, siger logikken os at ingen skal have adgang til information, med mindre de specifikt har et behov, og har fået tildelt adgangen (via en styret proces).

Hvis man styrer sine adgange via organisationen, skal man være opmærksom på at alle i en organisatorisk enhed typisk kan få adgang til de samme informationer, og det kan således være ganske svært at differentiere sin adgangskontrol.

Det sidste nye i denne Coronatid er, at mange benytter f.eks. Teams til samarbejde på tværs af organisationer (samarbejder med leverandører, kunder, konsulenter etc.). Teams er smart fordi det er hurtigt og let at dele information. Ulempen er at alle i et Team som udgangspunkt har adgang til de samme informationer, hvorved begrænsninger kræver en særdeles hård styring.

Når et ”projekt” slutter, meldes brugerne ud af teamet, efterhånden som de ikke længere arbejder på projektet. Når den sidste i teamet er meldt ud kan teamet nedlægges. Hvis man nedlægger teamet, bliver mange overraskede over at adgang til informationen også forsvinder (der er jo ingen ”ejer” længere). For visse (især cloudbaserede) systemer sletter man samtidig de data der var tilknyttet arbejdsteamet, når teamet nedlægges, idet der ikke længere er nogen til at betale for opbevaringen af data.

Hvis man forestiller sig at man er en virksomhed der laver innovation og produktudvikling, vil man typisk gerne kunne dokumentere de adgange der har været til data, f.eks. med henblik senere patenter, og derfor er åbne teams eller organisationer med fri adgang til så mange data som muligt ikke en brugbar option.

Husk også lige at adgangs også giver adgang til at slette data!

< Taber vi data ved overførsel mellem systemer >

Brugen af mange systemer giver mange filoverførsler. Kravet er jo stadigvæk at dataoverførsel mellem systemer skal være valideret. Valideringen består af en dokumenteret kontrol af at data er korrekt overført. Det betyder at valideringen af en dataoverførsel pludselig kan være en udfordring, da de fleste moderne systemer er baseret på databaser, hvor interne filformater ikke nødvendigvis er ens. Man kan således ikke blot kopiere filer fra et system til et andet bare med brugen af en Explorer, men skal i stedet dokumentere/validere den proces man benytter.

Ved overførsel af data mellem systemer skal man især være opmærksom på metadata (dvs. de informative data der beskriver de data man overfører), også overføres på en valideret måde.

Metadata er basis for at man kan genfinde og behandle sine data på en struktureret måde, og kan desuden udgøres af f.eks. signaturer, tagnumre, gamle dokumentnumre (hvis data f.eks. kommer fra et gammelt udgående system) ændringslog o.l.. Dette burde give en forståelse af hvor vigtige disse metadata er, og ligeledes hvor vigtigt det er at overføre dem på en dokumenteret og struktureret måde.

Man skal i særdeles høj grad være varsom hvis man laver overførsel af signaturer. Signaturer skal entydigt være knyttet til de data de dækker over.

Det er normalt (bl.a. fordi det er et regulatorisk krav) at en signatur ikke må kunne overføres mellem data, da man i givet fald kan drage en signatur i tvivl. Hvis man overfører signerede dokumenter, eller værre endnu signerede data, så SKAL der være en meget nøje plan for valideringen af denne overførsel, for at sikre signaturernes fremtidige gyldighed.

< Vil du vise mig vejen til arkivet >

En mere banal udfordring er arkivering. Eftersom ikke alle data har samme retentionstid, og ikke alle data er driftsaktive i lige lang tid, skal man hhv. have en veldefineret strategi for arkivering, samt en mekanisme der sikrer overførsel af data til arkiv jf. den definerede strategi.

Husk også at for mange produktionssystemer bevarer man dele af rå-data i produktions­systemets database (dette kunne f.eks. være audit trails, eller opsamlede rå-data der benyttes til beregninger samt afrapportering). Disse rå-data skal opbevares lige så længe som de batchrapporter de har ligget til grund for.

Det kan således betale sig sammen med de øvrige batchdata at overføre rå-data på en valideret måde, til et system egnet til formålet. I forbindelse med overførslen, fjernes både batchdata og de underliggende rå-data helt fra oprindelsessystemet. På den måde har man ikke en udfordring ved at udpege sine ”true data”, og IT-vedligehold har ikke en udfordring med at skulle slette data/rydde op fra tid til anden.

< Findes der faktisk rimelige krav >

Hermed et par tips til krav man kunne sætte til systemer hvori man opbevarer data:

#Krav
 
88Der skal som default ikke være adgang til data, medmindre denne adgang er specifikt tildelt
89Tildeling af adgange til data skal køres via en formel godkendelsesproces
90Der skal identificeres en formel dataejer for alle kritiske data
91Dataejer skal være en funktion i virksomheden, ikke en fysisk person
92For data der opbevares i skyen, skal der defineres en formel exitstrategi
93Der skal defineres en specifik retentionsperiode for ALLE data i virksomheden
94Der skal defineres en teknisk arkiveringsstrategi for data der er underlagt arkivregler
95Det skal til enhver tid være muligt at dokumentere hvem der har haft adgang til data
96Data må kun ligge ét sted
 

< Er gratis nu egentligt lige billigt nok >

Når vi nu er i gang, har jeg lige et par ord om ubetalte tjenester: I denne nymodens cloud-orienterede verden, findes der mængder af muligheder for at dele og opbevare data ganske gratis.

Microsoft, Apple, Google og mange flere giver mange gigabyte opbevaringsplads til os brugere ganske gratis, og det er kun hvis man overskrider dette pladsbehov at man skal betale. 5 Gb er f.eks. nok til mange tusinde Word dokumenter, så hvorfor betale for opbevaring af data?

I gamle dage havde alting en pris – Det har det stadigvæk. Hvis man ikke betaler for sin serviceydelse i rede penge, kan man betale med lav hastighed, reklamer eller via lav sikkerhed. Det er også rigtigt svært at komme og stille krav til noget man ikke betaler for, og hvis en leverandør pludselig dropper sin tjeneste, eller ændrer på systemet, er det rigtigt svært at komme efter dem med et rimeligt juridisk grundlag.

Derfor: Vælg ALTID betalte løsninger eller betalte versioner af løsninger.