Logging, rutiner og rettigheter

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

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

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
1.0 St?le Asker?d Johansen 2018-01-01  
1.1 St?le Asker?d Johansen 2021-08-12  
1.2 Martin Bore 2021-11-14 Logger med utvidet lagringstid
1.3 St?le Asker?d Johansen 2023-02-14 Bruk av utvalgte loggdata til forskning

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 亚博娱乐官网_亚博pt手机客户端登录

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

 

Publisert 2. apr. 2017 20:31 - Sist endret 28. feb. 2023 09:30