Logging, rutiner og rettigheter

Prosedyre for behandling av logger fra systemer, tjenester og applikasjoner.

1. Formål

Hensikten med denne prosedyren er å beskrive hvordan ulike brukergrupper skal gis tilgang til ulike logger i USITs 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

Versjon:    

Forfatter:

Dato:

Kommentar:

0.1 Ståle Askerød Johansen 2016-02-23 Første utkast
0.9 Ståle Askerød Johansen 2016-04-19 Andre utkast etter innspill

3.2 Godkjenningsstatus

Denne prosedyren er under utarbeidelse

4. Endringer

Ved behov for endringer i denne prosedyren skal IT-sikkerhetssjefen 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. Endel av loggene samles inn fordi det er pålagt ved lov.

6.2 Bruksområder

Loggene har to hovedkategorier av brukere, med ulike behov.

  1. Driftsgruppene ved USIT. Disse trenger loggene for å sikre stabil og skalerbar drift.
  2. Sikkerhetsgruppen ved USIT og UiO-CERT. Disse 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.

I tillegg finnes det en tredje brukergruppe som kan nyttiggjøre seg logging, og spesielt korrelering, nemlig 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

Brukerne er ofte ikke ansatt ved USIT og er oftest ikke driftspersonale. Dette er, for USIT, en forholdsvis ny måte å bruke logger på.

I denne versjonen av dokumentet fokuserer vi derfor mest på drift og sikkerhet. 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 Lagring, backup og arkivering

Autentiseringslogger og andre 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-sikkerhetssjefen og dokumenteres. Dette inkluderer sikkerhetskopier, så etter maksimum to år skal alle logger være borte fra alle lagringsmedier.

Andre 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.

6.4 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 vanlige brukere i de enhetene som trenger det. Dette skal styres ved innmelding i egne grupper.

6.5 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. Der applikasjoner, systemer og tjenester har mulighet for å logge feilsituasjoner som oppstår, skal dette gjøres.

6.6 Hva KAN logges?

  • Systemlogger fra applikasjoner, systemer og programmer.. For eksempel
    • Logger over nett-trafikk
    • 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.7 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.8 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.9 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.10 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

 

Av Ståle Askerød Johansen
Publisert 2. apr. 2017 20:31 - Sist endret 23. mai 2019 10:57