Logging, rutiner og rettigheter

1. Formål

Hensikten med dette dokumentet er å beskrive hvordan ulike brukergrupper skal gis tilgang til ulike logger i IT-avdelingens systemer for loggbehandling. Prosedyren skal revideres ofte for å tilpasses nye muligheter i systemene, og nye krav og ønsker fra brukergruppene. Det er viktig med rett balanse mellom praktisk nytteverdi på den ene siden, og beskyttelse av persondata på den andre siden.

2. Virkeområde

Loggdata fra UiO sine IT-systemer.

3. Versjon og dokumenthistorie

3.1 Dokumenthistorie

3.2 Godkjenningsstatus

Denne prosedyren er godkjent.

4. Endringer

Ved behov for endringer i denne prosedyren skal IT-sikkerhetssjef kontaktes.

5. Ansvar og forankring

IT-direktøren er ansvarlig for denne prosedyren. Endringer i prosedyren skal legges frem for IT-direktøren for godkjenning.

IT-sikkerhetssjef eier denne prosedyren. Endringer utføres av IT-sikkerhetssjef som sørger for formell godkjenning hos IT-direktøren.

6. Fremgangsmåte

6.1 Sentral vs. lokal logging

Logger bør fortrinnsvis samles sentralt i et egnet verktøy fremfor å ligge spredt på de enkelte tjenermaskiner og klienter. Dette gjør korrelering, debugging og feilsøking på tvers av applikasjoner, tjenester og maskiner mye enklere. Det sikrer også enhetlig behandling av logger med hensyn til tilgangskontroll og arkivering.

Datamaskiner er mer flyktige enn tidligere, og det er viktig å sikre oversikt over hendelser lagret et annet sted enn selve maskinen. Dette sikrer også loggenes integritet.

Endel av loggene samles inn fordi det er pålagt ved lov.

6.2 Bruk til drift og sikkerhet

Dette er de to primære bruksområdene for logger. I all hovedsak har loggene to hovedkategorier av brukere, med ulike behov.

6.2.1 Drift

Driftsgruppene ved IT-avdelingen trenger loggene for å sikre stabil og skalerbar drift.

6.2.2 Sikkerhet

Sikkerhetsgruppen ved IT-avdelingen og UiO-CERT trenger loggene som en hjelp til å etterforske sikkerhetshendelser og planlegge sikring av infrastrukturen.

Begge gruppene bruker logger på to måter:

1. Aktiv feilsøking og korrelering i logger for å finne ut mer om et problem, en utfordring eller en hendelse.
2. Statistisk bruk, altså grafing over tid for å kjenne til trender og hvordan infrastrukturen oppfører seg når alt er normalt.

6.3 Bruk til andre formål

I tillegg finnes det to sekundære bruksområder for logging.

6.3.1 Bruksanalyse

En brukergruppe som som også kan nyttiggjøre seg logging, og spesielt korrelering, er tjenesteeierne. Disse er ofte interessert i å analysere loggene på tvers av ulike systemer for å

• avdekke mønstre i bruken av ulike tjenester.
• måle kvaliteten på tjenestene

Tjenesteeierne er ofte ikke ansatt ved USIT og er oftest ikke driftspersonale.

Tjenesteeiere kan få tilgang til anonymiserte data etter definisjonen gitt nedenfor. Se eget punkt. Dersom tjenesteeierne ønsker mer detaljerte data for å gjøre grundigere bruksanalyser, må det gjøres egne juridiske vurderinger i hvert enkelt tilfelle.

6.3.2 Forskning

Enkelte logger kan i noen tilfeller gjøres tilgjengelige for forskningsformål dersom det foreligger rettslig grunnlag for dette. Dette gjøres kun etter at loggene er tilpasset denne bruken, som regel ved at direkte identifiserbare personopplysninger er fjernet eller gjort utilgjengelige på andre måter. Skal loggene anomymiseres eller avidentifiseres skal dette gjøres forsvarlig og dokumenteres.

Dersom det er ønskelig å forske på slike logger, skal det godkjennes av it-sikkerhetssjef, og det skal lages tilpassede og dokumenterte rutiner for å utlevere loggene på en egnet form og med en egnet metode. Det skal også sikres at forskningsprosjektet er godkjent og registrert i henhold til gjeldende rutiner.

6.4 Lagring, backup og arkivering

Logger som inneholder personinformasjon

Logger med personinfomasjon skal være tilgjengelig i minimum tre måneder, og maksimum i to år. Som hovedregel ønsker vi at slike logger er tilgjengelig i seks måneder, og deretter slettes. Unntak fra dette må vurderes av IT-sikkerhetssjef og skal dokumenteres. Dette inkluderer sikkerhetskopier, så etter maksimum to år skal alle logger være borte fra alle lagringsmedier.

Logger som ikke inneholder personinformasjon

Andre logger er ikke underlagt lovreguleringer, og kan slettes etter kortere tid enn tre måneder. Man må vurdere hva som er mest hensiktsmessig lagringsperiode ut fra hensyn til feilsøking og lagringsplass.

Logger med utvidet lagringstid

For sikkerhetsformål har enkelte loggkilder utvidet lagringstid.

Logger som omhandler inn- og utlogging av brukere

USIT tar vare på deler av noen logger for sikkerhetsformål. Disse loggene er sammenstilt av andre logger, og inneholder informasjon om når brukere logget inn og ut av tjenestene. Disse tas vare på i 12 måneder.

Logger som omhandler passordbytte

Loggene fra systemet som håndterer passordbytte for UiO-brukere, passord.uio.no, skal tas vare på i 64 uker (16 måneder).

6.5 Tilgangskontroll

Drifts- og sikkerhetslogger

Tilgang til å se logger gis kun til driftsbrukere. Det gis ikke tilgang til vanlige brukere. Man skal i utgangspunktet kun se de loggene man trenger i sitt vanlige arbeid.

Det kan i noen tilfeller gis tilgang til enkelte systembrukere.

For å styre tilgang skal det fortrinnsvis brukes standard driftsgrupper som har navn som starter på «it-».

Anonymiserte logger for bruk til f. eks. analyse av bruksmønster

Tilgang til å se logger gis til folks vanlige brukerkontoer i de enhetene som trenger det. Dette skal styres ved innmelding i egne grupper.

Anonymiserte logger for bruk til forskning

Tilgang til å se logger gis til folks vanlige brukerkontoer i de enhetene som trenger det. Dette skal styres ved innmelding i egne grupper.

6.6 Hva skal logges?

1. Alle autentiseringsdata skal logges, dette inkluderer inn- og utlogginger i alle systemer.
2. Alle logger fra operativsystemer skal logges.
3. Aksesslogger fra webservere og tilsvarende applikasjonstjenere.
4. Logger fra nettverksutstyr som gir data om nettverksoppkoblinger og portnummer til og fra interne og eksterne IP-adresser. Disse loggene skal tas vare på i 90 dager.

• Der applikasjoner, systemer og tjenester har mulighet for å logge feilsituasjoner som oppstår, skal dette gjøres.
• Det skal være mulig å knytte autentiseringer til en reell ip-adresse som representerer klienten man autentiserer fra.

6.7 Hva KAN logges?

• Systemlogger fra applikasjoner, systemer og programmer. For eksempel
  • Utskrift
  • Lagringssystemer
  • AV-utstyr
• Logger fra driftsverktøy, f. eks. logger over installasjoner av programmer og deployment av maskiner.
• Andre logger som er interessant for driftspersonale og IT-sikkerhetsgruppen.

6.8 Felles logger

Noen logger klassifiseres som «felles logger», under antagelsen av at flere driftsgrupper ved USIT trenger tilgang til disse loggene for å lette feilsøkingen i egne systemer. Disse loggene er:

• Logger fra operativsystemene, altså standard OS-logger fra Windows og Linux.
• Autentiseringslogger fra systemer som Radius, LDAP og IDP-systemer som f. eks. FEIDE.
• Nett-komponenter som f. eks. lastbalanserere

Hvilke logger som regnes som felleslogger er klarere definert nederst i dette dokumentet. Det er IT-sikkerhetsgruppen som vedlikeholder denne listen. Utvidelser i denne listen skjer kun etter avtale med IT-sikkerhetssjefen.

6.9 Rettigheter og formål

1. Sikkerhetsformål: UiO-CERT og IT-sikkerhetsgruppen har i utgangspunktet tilgang til alle logger.
2. Driftsformål: USITs driftsgrupper har tilgang til
   1. Felles logger som beskrevet over, også for maskiner som i utgangspunktet ikke tilhører driftsgruppens virkeområde. Dette punktet vil kunne endres, slik at man i fremtiden bare kan se logger fra maskiner som berører ens eget fagfelt.
   2. Gruppe- eller fagspesifikke logger som f. eks. logger fra Apache, SafeCom eller ePhorte.
       
   Et viktig prinsipp her er at man kun skal bruke de delene av loggene man faktisk trenger for å korrelere og feilsøke egne systemer og tjenester. Korrelering og sammensetting av loggdata utover dette er ikke tillatt.
3. Måling av tjenestekvalitet kan gjøres dersom dataene er anonymiserte. Se eget punkt.
4. Korrelering av data skal i utgangspunktet bare skje mellom felleslogger og den enkelte logowner sine logger. Dersom man har behov for korrelering utover dette, for eksempel på tvers av logownere, skal dette godkjennes av IT-sikkerhetssjef eller underdirektør for IT-drift på forhånd. Godkjenningen skal være sporbar.

6.10 Anonymisering av logger

Anonymiserte logger der personrelatert informasjon er fjernet kan brukes fritt til statistisk bruk, f. eks. for trending for å se mønstre over tid. Dette kan da skje over en periode på lenger enn to år.

Anonymisering av logger kan også brukes til å gjøre logger egnet til bredere analyse av tjenestekvalitet.

Begrepet «anonymiserte data» er, i denne versjonen av policyen, definert slik: Data som ikke kan spores til en brukergruppe på mindre enn 100 personer.

6.11 Definisjoner av felles logger

Operativsystemlogger for linux

• authlog
• messages
• secure
• yum
• dnf
• lastlog

Operativsystemlogger (Event Logs) for windows

• windows/security
• windows/application
• windows/system
• windows/setup
• applications and services/admin
• applications and services/operational
• applications and services/analytic
• applications and services/debug

Andre logger

• aksesslogger fra radius-serverne
• aksesslogger fra LDAP-serverne
• aksesslogger fra FEIDE
• aksesslogger fra lastbalanserer-tjenester
• informasjon om inn- og utlogging fra DC-ene i UiO-domenet