Sikkerhet og tilgang
====================

Sikkerhetskonfigurasjonen er de valg som treffes om hvor strenge krav
som stilles for tilgang til arkivenheter og dokumenter i et arkiv.
Kravene til sikkerhet kan variere etter behov. Formålet med kravene i
Noark 5 er fleksibilitet, de konkrete kravene til forvaltning og sikring
av dokumentenes og metadataenes integritet er i stor grad overlatt til
virksomhetene og de konkrete løsningene som skal implementere
standarden.

Dokumentene i et Noark 5-arkiv skal forvaltes og bevares med ivaretatt
autentisitet, pålitelighet, integritet og anvendelighet. Metadata som
gir informasjon om hvert arkivdokument, som knytter det til handlingen
som skapte det, er grunnleggende for å sikre dette. Dokumenter og
metadata må sikres mot uautoriserte endringer. Det må etableres
retningslinjer og prosedyrer som sier noe om hvem som har lov til å
gjøre hvilke endringer med dokumenter og metadata etter at de er
opprettet, og hvilke betingelser som ligger til grunn for endringene som
er tillatt. Dette skjer gjennom brukeradministrasjon og autorisasjoner.

*Autorisasjon* er silingen av hva en individuell pålogget bruker faktisk
får lov til å gjøre i et system. Det er to prinsipielt forskjellige
overordnede prinsipper for hvordan autorisasjon kan uttrykkes, som ofte
betegnes «need to know» og «need to protect». «Need to know», som
overordnet prinsipp, innebærer at man tar som utgangspunkt at all
tilgang er stengt, og at autorisasjoner skal være eksplisitt uttrykt.
«Need to protect» er autorisasjon med det motsatte utgangspunkt: Alt er
åpent med mindre tilgangen sperres eller skjermes eksplisitt. «Need to
protect» er primært aktuelt for tilgang til å lese, søke i og skrive ut
informasjon. Redigeringstilgangene i forvaltningen bør uansett baseres
på «need to know»-prinsippet.

Rettighetsangivelser er konkret kobling mellom objekter i arkivet og de
tjenester, eller alternativt personlige brukere, som har
tilgangsrettigheter til dem. Endringsloggen i henhold til Vedlegg 3 kan
brukes til å etterprøve at endringene er utført av autoriserte brukere.

.. list-table::
   :header-rows: 1

   * - Krav nr.
     - Krav
     - Type
     - Merknad
   * - 4.1
     - Løsningen skal sikre at dokumenter og tilhørende metadata er
       lagret bestandig og sikkert, og at de forblir tilgjengelig og kan
       hentes frem over tid, i tråd med definert bevaringstid
     - O
     - 
   * - 4.2
     - Det bør være mulig å definere regler for at løsningen skal
       generere sjekksummer eller andre mekanismer for
       integritetskontroll på dokumentene i løsningen.
     - V
     - 
   * - 4.3
     - Brukere som skal ha tilgang til arkivenheter, objekter og
       dokumenter i en Noark 5-løsning, skal identifiseres, autentiseres
       og autoriseres i tilstrekkelig grad før de blir gitt tilgang
     - O
     - En bruker kan være en person eller et system
   * - 4.4
     - Det bør være mulig å identifisere, autentisere og autorisere
       brukere via en ekstern katalog eller et eksternt system som
       definerer hvilke rettigheter brukeren skal ha
     - V
     - 
   * - 4.5
     - Brukere bør kunne autoriseres på grunnlag av administrativ
       tilhørighet
     - V
     - 
   * - 4.6
     - Løsningen skal kunne gjenkjenne hvilken administrativ sammenheng
       eller rolle brukeren har og opptrer i til enhver tid
     - O
     - 
   * - 4.7
     - En bruker som ikke lenger skal ha tilgang til arkivenheter,
       objekter og dokumenter i en Noark 5-løsning, skal fortsatt være
       identifisert i løsningen, men med en status som indikerer at den
       er passiv, som hindrer brukeren i å få tilgang til løsningen
     - O
     - 
   * - 4.8
     - Det skal finnes en oversikt over hvilket eller hvilke tidsrom
       hver bruker har vært aktiv
     - O
     - 
   * - 4.9
     - Det bør være mulig å endre en brukers navn uten å endre brukerens
       identifikasjon i løsningen.
     - V
     - 
   * - 4.10
     - All redigerings- og skrivetilgang i Noark 5-løsningen skal være
       basert på et “need to know” grunnprinsipp
     - O
     - 
   * - 4.11
     - Et “need to protect” grunnprinsipp kan velges for lesetilganger
     - V
     - 
   * - 4.12
     - Det skal ikke være mulig å opprette roller som opphever de
       generelle begrensninger som er definert i løsningen
     - O
     - 
   * - 4.13
     - Ulike kombinasjoner av funksjonelle krav som stilles til
       brukerens autorisasjon bør kunne settes sammen til forskjellige
       funksjonelle roller, som uttrykker typiske stillingskategorier
       eller oppgaveporteføljer i virksomheten
     - V
     - 
   * - 4.14
     - For hver funksjonell rolle bør det være mulig å definere et
       regelsett for prosessrelaterte rettigheter
     - V
     - 
   * - 4.15
     - Det bør være mulig å definere eller avgrense en rolles
       nedslagsfelt, for eksempel til angitte arkivenheter med
       underliggende arkivenheter, angitte organisatoriske grenser,
       visse typer mapper eller registreringer, gitte skjermings- eller
       graderingskoder, egenskaper ved registrerte parter, eller andre
       definerte kriterier som finnes i løsningen.
     - V
     - 
   * - 4.16
     - En bruker bør kunne ha ulike roller
     - V
     - 
   * - 4.17
     - Innenfor hver av rollene som en bruker har, bør det kunne
       defineres en tilgangsprofil som utgjøres av rollens funksjonelle
       rettigheter i kombinasjon med nedslagsfeltet for rollen
     - V
     - 
   * - 4.18
     - Det skal lagres informasjon om hvilke tilgangsrettigheter en
       bruker har hatt, og når de var gyldige
     - O
     - 
   * - 4.19
     - Tilgangsrettigheter for en identifisert bruker skal kunne
       begrenses i tid, rettighetene må kunne gjelde fra dato til dato
     - O
     -