Underbilag 2.3 Logning

Transkript

1 Underbilag 2.3 Logning

2 INSTRUKTION TIL TILBUDSGIVER Underbilaget er en del af bilag 2, De generelle krav og beskriver Krav til logning. Tilbudsgivers eventuelle forbehold til underbilag 2.3 anføres i forbeholdslisten og skrives ind med track changes i selve bilaget i overensstemmelse med udbudsbetingelserne. Det bemærkes, at Kontrakten (forstået som Kontrakten uden bilag) og Driftskontrakten (forstået som bilag 7.2, 7.3 og 7.4) er at betragte som minimumskrav, jf. udbudsbetingelserne. Tilbudsgiver skal derfor sikre, at eventuelle forbehold til underbilag 2.3 ikke udgør et forbehold overfor Kontrakten (forstået som Kontrakten uden bilag) og Driftskontrakten (forstået som bilag 7.2, 7.3 og 7.4). Om betydningen af vurderingen af Tilbudsgivers besvarelse af instrukser og eventuelle forbehold til bilaget henvises til punkt 5.9 i udbudsbetingelserne. Tilbudsgiver skal som del af sit tilbud følge og besvare instruktioner, som er markeret med [ ]. For nærværende bilag betyder det, at Tilbudsgiver skal: Underbilaget skal ikke udfyldes af Tilbudsgiveren. SÆRLIGT OM UNDERBILAGET Dette underbilag har et indhold svarende til dokumentet 9 Logning dateret Vinter 2013, som udarbejdet af KOMBIT og gjort tilgængeligt på KOMBITs hjemmeside, på nær følgende rettelser: Anvendelse af en teksttypografi, kravstypografi og nummerering der stemmer overens med de øvrige underbilag. Krav til beskrivelse af løsningen forefindes i respektive underbilag til bilag 2,, i stedet for i nærværende underbilag. Sætningen I nedenstående krav er [LOGNING] en reference til nærværende dokument. er tilføjet til kapitel 5. I kravstitler og kravstekst er Løsningen erstattet med Støttesystemerne. Kravet Ensartet struktur og format for logning af data i Løsningen er delt i 2 Krav - Krav og Krav Side 2 af 22

3 Indhold 1 Indledning Baggrund Logningsemner Loven Kilder Generelt Afvigelser eller specificeringer Logningsemner og -typer Logningsemner Logningstyper Sammenfatning Tværgående logningsmål Sammenhængende logs Transaktions ID Logstruktur og format Kravtabel Side 3 af 22

4 1 Indledning En række kommunale interessenter har løbende behov for at kunne se hvilke handlinger der er udført i et givent fagsystem. Da sagsbehandling og andre processer/aktiviteter i høj grad foregår i et samspil mellem mange systemer, er det essentielt at kunne verificere og dokumentere hele sagsbehandlingen på tværs af systemerne. Eksempler på de omtalte interessenter er følgende, og alle disse interessenters behov skal tilgodeses, listen er dog ikke udtømmende: Datatilsynet - fx i relation til en række lovmæssigheder Kommuner - fx i relation til afregning, drift og SLA Fælles kommunalt - fx i relation til afregning, drift og SLA Kommunernes revision - fx i relation til sagsbehandlingen og forvaltning Leverandører af enkelte systemer - fx i relation til overvågning og fejlfinding Leverandører af tilstødende systemer - fx i relation til tilgangen til andre systemers data, monitorering af brugsmønstre og fejlsøgning For at opnå sammenstillingsbehovene, og imødekomme interessenterne generelt, anvendes logning i forskellige variationer, så det vil være muligt at udtrække og sammenstille logningsdata. For hensigtsmæssigt at kunne sammenstille logningsdata fra forskellige systemer anvendes, så vidt det er muligt, et fælles logningsformat og en standardiseret måde at lagre/udtrække logs fra et givent system. Da systemer (og tilhørende driftsmiljøer) implementerer logning i mange forskellige teknologiske varianter mv., kan disse ikke umiddelbart forventes at have et standardiseret udtryk, herunder både i relation til indhold og format. Der er derfor behov for at definere en fælles opfattelse af logning i form af politikker og basis krav, der giver leverandører af systemer en forståelse for fortolkning af forskellige logningsaspekter i forbindelse med implementeringen af de forskellige fælleskommunale systemer. I dette dokument beskrives følgelig en række retningslinjer for, hvordan de fælleskommunale systemer skal logge information generelt for systemmæssigt at kunne verificere og dokumentere aspekter relateret til sagsbehandlingen, de tværgående aktiviteter, drift, mv. i systemerne. Selve sagsbehandlingen, herunder de mere fagnære aspekter af sagsbehandlingen, dokumenteres bl.a. via OIO standarderne Sag og Dokument, og dette sker i selve fagsystemerne. Generelt berør og beskriver indeværende dokument kun de aspekter af logning, som er generelt for alle de fælleskommunale systemer, og det forventes derfor, at de enkelte systemer, og specifikationen af disse, selv står for at sikre at eventuelle systemspecifikke aspekter beskrives separat, og derudover logges som et tillæg til de i dette dokument beskrevne aspekter. 1.1 Baggrund Det kommunale systemlandskab vil i fremtiden gennemgå en transformation fra at være et centralt landskab til at blive et meget distribueret systemlandskab. Landskabet vil bestå af en række fagsystemer og støttesystemer, der vil blive leveret af en række forskellige leverandører. Drift af de forskellige systemer vil således blive varetaget af forskellige leverandører. Side 4 af 22

5 Dette giver en udfordring med at kunne verificere og dokumentere en given sagsgang, transaktion mv., og det skal derfor være muligt at sammenstille logs fra de forskellige systemer til samlet og entydigt logningsspor. Det betyder derudover at logningsdata skal stilles til rådighed på enten forespørgsel, efter nærmere aftale, eller ved automatisk overlevering til andre systemer. Derudover skal systemerne kunne levere logningsdata på en struktur og et format der gør maskinel læsning og analyse mulig. Derudover har kommunerne i øvrigt pligt til at overholde Persondataloven og anden relevant lovgivning på området. 1.2 Logningsemner Indeværende notat beskriver og behandler følgende liste af overordnede logningsemner. Emnerne skal opfattes som tematiske områder, indenfor for hvilke, det er relevant at logge forskellige aspekter. Emner skal derfor betragtes som områder, og i nogle tilfælde overlappende områder, som en række kommunale interessenter kunne have interesse i af få afdækket med hensyn til logning. De faktiske informationer som skal logges, og måden hvorpå dette udføres i praksis, vil derfor være realiseret på lignende måder, og via samme typer af konkrete logs. Herunder ses en kort oversigt og beskrivelse over logningsemnerne, som alle bliver behandlet senere. Derudover vil en række konkrete logtyper tilsvarende blive præsenteret i et senere afsnit, som alle konkret er med til at afdække og sikre logningsbehovene inden for hvert af disse emner. Oversigten er derfor kun en introduktion til emnerne. Emne Beskrivelse Årsag Lovmedholdelighed Det skal sikres at der logges efter den gældende lovgivning om behandling af fx persondataloven Hvis der er specificerede lovmæssige aspekter på område skal disse per definition over- Sikkerhed Revisionsspor SLA opfølgning Det skal være muligt at dokumentere at systemet behandler og opbevarer data jf. gældende sikkerhedskriterier I forbindelse med revisionsaktiviteter skal det være muligt at verificere og dokumentere at/om der er sagsbehandlet eller forvaltet korrekt Efter idriftsættelsen af et system skal det være muligt at kunne dokumenteres, at de aftalte serviceaftaler for det pågældende system over- holdes. Mulighed for at tjekke og efterforske eventuelle brud på dette Mulighed for at validere eventuelle afvigelser fra korrekte processer Mulighed for at tjekke om et givet system opfylder dets pågældende SLA aftale Side 5 af 22

6 Fejlsøgning Overvågning Afregning holdes Ved eventuelle fejlsituationer, skal der logges tilstrækkelig med data til en efterfølgende dokumentation for de konkrete forretningsmæssige og tekniske fejl Efter idriftsættelsen af et system skal det være muligt at logge tilstrækkeligt med data til at understøtte og dokumentere analyser af brugsmønstre, ressourcetræk, mv. I relation til betalingsbehæftede data, services eller lignende skal det være muligt at logge tilstrækkelige data så der sikres et informationsgrundlag til korrekt afregning Mulighed for at analysere og finde roden til fejlene, så de kan identificeres og elimineres Mulighed for at tjekke om systemerne fx overholder aftalte it mønstre eller principper, og få et overblik over deres konkrete ressourcetræk Mulighed for at administrere og forvalte adgangen til prissatte services eller data De nærmere beskrivelser af både logningsemnernes rammebetingelser, hvad de specifikt indeholder og imødekommer beskrives i de efterfølgende afsnit. 2 Loven Dette afsnit vil gennemgå de generelle lovmæssige omstændigheder relevant for logning, og det skal derfor betragtes som tværgående for alle de fælles kommunale systemer. 2.1 Kilder I det følgende beskrives en opsummering af det lovgrundlag, som er udgangspunktet for de identificerede logningsbehov. Der vil i de efterfølgende afsnit blive specifikt blive refereret til lovmæssigheder, som ligger til grund for de konkrete typer af logs og deres indhold. Derudover eksisterer der en række andre relevante lovmæssigheder i relation til de fælles kommunale systemer, herunder fx Forvaltningsloven, og det relaterede Ombudsmands notat Forvaltningsretslige krav til det offentliges IT-løsninger, Dok nr. 13, 16.februar 2012, Retssikkerhedsloven, Arkivloven og Regnskabsbekendtgørelsen. Alle disse lovmæssigheder er behandlet yderligere i KOMBIT s standard kravspecifikation, og er undladt her da de ikke direkte dikterer logningskrav relevant for niveauet i dette dokument. Der er anvendt følgende konkrete kilder: Side 6 af 22

7 Lov om behandling af personoplysninger (Persondataloven) Lov nr. 429 af med ændringer, herunder ved lov nr. 280 af (Justitsministeriet/Datatilsynet), og Lov nr. 639 af (Justitsministeriet). Bekendtgørelse nr. 528 af 15. juni 2000 som ændret ved Bekendtgørelse nr. 201 af 22. marts 2001 om sikkerhedsforanstaltninger til beskyttelse af personoplysninger, som behandles for den offentlige forvaltning (Sikkerhedsbekendtgørelsen). Vejledning til bekendtgørelse nr. 528 af 15. juni 2000 om sikkerhedsforanstaltninger til beskyttelse af personoplysninger, som behandles for den offentlige forvaltning, VEJ nr. 37 af 02/04/2001 Udvalgte elemeter af disse lovmæssigheder vil blive behandlet i flere detaljer, dog kun kort, i de efterfølgende afsnit. Heri henvises til kilderne via det angivne akronym i ovenstående tabel. 2.2 Generelt Specifikt om logning står der fra Bekendtgørelsen: 19 Der skal foretages maskinel registrering af alle anvendelser af personoplysninger. Registreringen skal mindst indeholde oplysning om tidspunkt, bruger, type af anvendelse og angivelse af den person, de anvendte oplysninger vedrørte, eller det anvendte søgekriterium. Loggen skal opbevares i 6 måneder, hvorefter den skal slettes. Myndigheder med særlige behov kan opbevare loggen i op til 5 år. Når der foretages almindelige sagsbehandling kræves det altså, at der som minimum logges oplysninger om følgende aspekter og elementer: Tidspunkt Bruger Type af anvendelse Angivelse af den person, de anvendte oplysninger vedrørte, eller Det anvendte søgekriterium Ovenstående liste, og uddrag fra bekendtgørelsen, dikterer derfor en række afledte overordnede krav til logning: Det skal være muligt at finde frem til den person, brugeren af systemet repræsenterer, også efter vedkommende er ophørt med at være bruger af det givne system, er rejst fra kommunen mv. Anvendelsen af loggen skal også logges Loggen skal gemmes i 6 måneder, og derpå slettes, men ved særlige tilfælde kan loggen gemmes i 5 år, og derefter slettes. Det enkelte system skal beslutte, hvor længe logs skal opbevares Det enkelte system skal beslutte, og kravsætte en sletteproces 2.3 Afvigelser eller specificeringer Herunder er fremhævet en række relevante enten afvigelser eller specificeringer i relation til Bekendtgørelsen, som alle har bidraget til udarbejdelsen af indeværende dokument: Side 7 af 22

8 Stk. 2 Bestemmelse i stk. 1 finder ikke anvendelse for personoplysninger, som indgår i tekstbehandlingsdokumenter og lignende der foreligger i endelig form. Stk. 3 Bestemmelse i stk. 1 finder ikke anvendelse, hvis behandlingen af personoplysninger udelukkende sker ved afvikling af programmer, som foretager en forud defineret massebehandling af personoplysninger ( batch kørsler). Der skal dog foretages maskinel logning af bruger og tidspunkt for behandlingen. Stk. 4 Bestemmelse i stk. 1 finder endvidere ikke anvendelse, hvis behandlingen af personoplysninger udelukkende sker med henblik på statistiske eller videnskabelige undersøgelser, og identifikationsoplysningerne forinden enten er krypteret eller erstattet med et kodenummer eller lignende. Der skal dog foretages maskinel logning af bruger og tidspunkt for behandlingen. 3 Logningsemner og -typer Indeværende notat er struktureret efter de overordnede spørgsmål vedrørende hvorfor, hvordan og hvad i relation til logning. Spørgsmålet vedrørende hvorfor, er dækket af henvisninger til lovmæssighederne (foregående afsnit, se Loven ), interessenternes behov og ønsker, udtrykt ved en række udvalgte logningsemner (næste afsnit, se Logningsemner ). Spørgsmålet vedrørende hvordan er dækket at de konkrete typer af logs, som et givent system skal implementere, og spørgsmålet vedrørende hvad er dækket af selve indholdet af de specificerede logs (efterfølgende afsnit, se Logningstyper ). 3.1 Logningsemner Som allerede nævnt i introduktionen, gennemgås en række overordnede logningsemner. Hvert emne bliver behandlet i de efterfølgende afsnit, og har til formål at give et kort overblik over indholdet og rationalet bag de generelle områder, hvor logning er nødvendigt, relevant eller ønskeligt Overvågning Dokumentation til brug for overvågning af de fælles kommunale systemer i en driftssituationen er ikke direkte med i afgrænsningen af indeværende dokument. Det vil dog påhvile den enkelte driftsleverandør at sætte sådanne overvågningsmekanismer og rutiner op, så SLA-kravene for det enkelte system kan opfyldes. Dvs. en opfyldelse af aspekterne relateret til servicemålene generelt, herunder fx verifikation af tilgængelighed, belastning af produktionsmiljøet, etablering og vedligeholdelse af alarmer i overvågningsværktøjerne, etc. (se yderligere detaljer i driftskontrakten, Bilag_7B_Ydelser_og_servicemål ). Det nødvendige data grundlag for at overholde og efterleve de førnævnte krav er alle relateret til produktionsmiljøet og ikke selve systemet. Der vil dog sandsynligvis være dele at den opsamlede information som vil være relevant for analyser af brugsmønstre mv. som kan udtrækkes af system-, revisions- og verifikationsloggen Sikkerhed Fra Persondataloven p. 27 Side 8 af 22

9 Den dataansvarlige skal sørge for, at oplysninger ikke kommer til uvedkommendes kendskab, misbruges eller i øvrigt behandles i strid med loven. Dette er først og fremmest krav om at uvedkommende ikke må kunne skaffe sig adgang til fortrolige oplysninger om andre menneskers forhold. Det betyder, at det skal logges, når data tilgås, således det kan dokumenteres: Hvem der har tilgået data og, i Hvilken sammenhæng data er tilgået, og Tidspunktet relateret til data adgang samt Systemet, som har forsøgt at få adgang Der er identificeret følgende afledte krav forbindelse med dette: Ure skal være synkroniseret på tværs af maskiner, driftscenter og systemer for at muliggøre sammenstilling af logs ud fra tid Et fælles rapporteringsformat på tværs af systemer for at kunne sammenstille logs Et gennemgående unik transaktions ID, som propageres videre med rundt i systemerne, som indgå i en given transaktion Et data grundlag for det loggede, som tillader en eventuel fremtidig konsolidering af data og separate logs Ved tid forstås UTC, mere specifikt, højopløsning UTC, 60bit, a la den brugt i UUID standarden RFC4122 (IEFT). Dette sikrer fx, den nødvendige præcision ved sammenstilling samt angivelse af tidszone og sommertidsangivelse. Derudover så gælder sidstnævnte punkt, angående fælles rapporteringsformat, alle logs, og ikke kun den eller de logs, som er relateret til sikkerhed. Krav i relation til fælles format, vil blive behandlet yderligere og senere i notatet Revisionsspor Der skal logges data der dokumenterer, hvordan en given sag er blevet håndteret af en myndighed. Meget af denne form for logdata vil blive genereret internt i et fagsystem. Men eftersom det fulde flow for en sag typisk omfatter brugen af flere yderligere systemer, skal det være muligt at sammenstille logdata således alle relevante aspekter af en sag dokumenteres, og kan fremfindes og vurderes på en overskuelig måde. Dette vil sige, at der som minimum skal logges oplysninger om følgende elementer: Sags ID Tilstandsskift jf. OIO sags- og dokumentstandarderne Tilknytning/skift af parter Tilknytning/skift af sagsbehandler Hvilke øvrige informationer, der måtte være relevante defineres af det enkelte fagsystem, dette kunne inkludere fx objektets tekniske fremdrift i forhold til eksistens, herunder når attribut- Side 9 af 22

10 ter/tilstande eller relationer bliver henholdsvis oprettet, importeret, passiveret, slettet (logisk) i stedet for det mere forretningsnære tilstandsskift, når en sag bliver oprettet, oplyst, afgjort etc SLA opfølgning Systemerne skal logge informationer til brug for dokumentation af deres opfyldelse af de SLA krav der er stillet til det enkelte system. Hvad der vil være relevante oplysninger, og det rette niveau, aftales for hvert enkelt system. Dog skal informationer om anvendte integrationer altid logges, både hvad angår hvilke systemer der tilgås, hvor ofte og hvad svartiderne på forespørgsler samt hvad deres størrelse etc. har været. Dette krav er tænkt per enkelt kald, og anses for gældende i alle situationer. Detaljeniveauet er nødvendigt for på sigt at kunne trække detaljeret statistik i flere dimensioner om nødvendigt. Derudover skal logning ske på begge sider af integrationen, hvis begge systemer indgår i rammearkitekturen, eller som minimum for den ende af integrationen om indgår i rammearkitekturen. Disse informationer skal anvendes til at give et billede af brugsmønstre mv. for de involverede systemer som helhed og hvor stort trækket på de specifikke andre systemer har været. Udover opsamlingen af denne form for historik skal informationerne også bruges til planlægning/forudsigelse af kapacitetsbehov Fejlsøgning Systemerne skal logge informationer til brug for fejlsøgning, både den system-interne fejlsøgning og den fejlsøgning der kan være relevant på tværs af systemer. Dette vil sige at der som minimum skal logges oplysninger om: Kaldt operation Parametre Tidspunkt IP-adresse og port Sidstnævnte punkt, angående IP-adresse og port gælder for modpart samt modpartens system ID. Transaktions ID et (se senere beskrivelse) gør det dog endelig muligt at se relationerne på tværs af systemerne Afregning I forbindelse med anvendelsen af services og andre ydelser i et system, skal det i flere tilfælde være muligt at afregne efter faktisk forbrug af den service eller ydelse, der via systemet stilles til rådighed. Afregningen af forbruget skal ske med den eller de aftagere, forbruget henføres til. Alle forsøgte og gennemførte servicekald eller brug af ydelser skal logges med henblik på en eventuel afregning. I forbindelse med afregning samles derfor information om dynamisk brug af systemet med relevans for afregningen (servicekald), mens elementer af mere statisk karakter separat skal samles ind af specifikke afregningsmoduler. Side 10 af 22

11 Afregningslogning, har derfor til formål at danne datagrundlag for at kunne afregne efter forbrug. Dette kan fx inkludere hver gang et anvendersystem tilsluttes til en service, hvor mange gange et anvendersystem sender et servicekald, og hvor meget data, der overføres til og fra anvendersystemet. I forbindelse med afregning og rapportering i øvrigt skal det sikres, at eventuelle følsomme data filtreres fra log-data i forbindelse med etablering af datagrundlaget for de administrative applikationer. 3.2 Logningstyper Der opereres i dette dokument med 5 forskellige typer af logs, samt nogle generelle forhold som gælder for alle 5 typer af logs. De forskellige logs fremhæves det med det hovedformål at sikre, at de aspekter og informationer, som de tidligere beskrevne logningsemner har behov for enten at overholde, efterlever eller at sikre sig adgang til i logningshenseender, kan i imødekommes. De 5 overordnede logs er følgende: Log type Systemlog Revisionslog Afregningslog Verifikationslog Driftslog Beskrivelse Fælles betegnelse af for alle tekniske logs. Denne typer af logs har ofte til formål at bistå ved fejlfinding af systemet. Det er fagsystemet, som selv sørger for at oprette, vedligeholde og udfylde de relevante systemlogs. Formålet med denne log er opsamling af, hvordan systemet er blevet anvendt på et givent tidspunkt. Herunder opsamling af hvilke informationer tilgås af hvilke brugere. Krav direkte udledt af Persondataloven og tilsvarende krav om revisionsspor og sikring mod uretmæssig tilgang til personfølsomme oplysninger. Logning til brug for afregning. Loggen skal indeholde tilstrækkelige information for at kunne beregne afregning for brug i en given periode. Logning af events i forbindelse med udrulning og ændringer i de fysiske miljøer. Muliggør verifikation af om ændringer er udrullet korrekt. Logning fra de fysiske miljøer inkl. operativsystem, netværksudstyr med videre, som kan danne grundlag for fejlsøgning. Det skal noteres, at verifikations- og driftsloggene kun vil blive behandlet på overordnet niveau, da indeværende dokument primært er målrettet de fælles kommunale systemer direkte, og ikke de fysiske miljøer, og de driftssystemer de fælles kommunale systemer bliver afviklet i (se mere omkring dette, i de efterfølgende afsnit vedr. begge logtyper). Det betyder endvidere, at strategier og krav, om fx central overvågning med alarmer er uden for scope af dette dokument, men at indeværende dokument blot skal sikre, at det nødvendige informationsgrundlag er til stede for at imødekomme dette, hvis det på sigt vælges at blive implementeret. Side 11 af 22

12 For de identificerede logtyper eksisterer en del sammenfaldende loginformation, men der optræder samtidig en del som er mere specifikt for den enkelte logtype. De generelle dele bliver derfor beskrevet først, og de individuelle logtyper samt deres specifikationer behandles dernæst individuelt. Systemets logning kan i udgangspunktet foretages decentralt i de enkelte systemkomponenter og integrationer, for at sikre at logning kan skalere og dermed foregå effektivt i det samlede system. Systemet skal sikre at indholdet af det samlede datagrundlag for logning er komplet, uanset om logningen foretages centralt eller decentralt. Udtrækkene fra eller adgangen til systemets logning skal være konsoliderede, således at alle loggede data indgår i udtrækkene eller adgangen til disse Generelt indhold Generelt for alle typer af logs, skal følgende logges, de steder, hvor det for det specifikke system er muligt. Enkelte datafelter er derudover markeret som valgfrie, da det enkelte projekt kan vurdere dem som værende ikke strengt påkrævet eller ikke relevante for et givet system. Det skal dog tydeligt fremgå, hvorfor og hvornår et system fraviger og undlader at gemme enkelte datafelter (eller hele logs, fx afregningsloggen, mere om det senere). Når der i det følgende refereres til Unikt ID, er det kritisk at understrege, at det for det givne system skal individuelt vurderes, hvor unik ID et behøver at være. Det betyder i praksis, at det per system skal vurderes om der er behov for, at id et er unikt for enten et given systemkomponent, hele systemkomplekset eller alle systemer på tværs. Succeskriteriet er blot at undgå dubletter i relation til genereringen af og derfor brugen af id er. For det systemmæssige tværgående ID, Transaktions ID, skal det dog som minimum sikres, at graden af hvor unik dette ID er, lever op til den af IETF specificererede standard rfc4122 (se eller tilsvarende. Felt ID Indhold Type/Format Eksempel Log ID Unikt id for log Int besked Kald ID Unik identifikation af selve forespørgslen Transaktions ID Globalt unikt id som generes af det system, som initierer kaldet, og propageres tværs 19a0c7c: c0312:7ffd 1 f81d4fae-7dec- 11d0-a765-00a0c91e6bf6 2 1 Eksempel på et systemmæssig unikt ID 2 Eksempel på et globalt unikt ID, jvf IETF specifikationen rfc4122 Side 12 af 22

13 Aftale ID (valgfri) KaldersAftale ID (valgfri) Parametre Tidspunkt over andre fagsystemer og maskingrænser. Unikt ID, som identificerer den aftale, som anvendes i forbindelse med forespørgsel Unikt ID, som identificerer kalders aftale, som anvendes i forbindelse med forespørgsel Parametre som er anvendt ved forespørgsel Tidspunkt for logning YYYY-MM- DD tt:mm:ss mls tzone :21: UTC hvor YYYY = årstal, 4 cifre MM = måned (1..12), 2 cifre DD = dag i måneden (1..31), 2 cifre tt = timer (0..24), 2 cifre mm = minutter (0..59), 2 cifre ss = sekunder (0..59), 2 cifre mls = millisekunder, 3 Side 13 af 22

14 cifre tzone = tidszone Service ID (valgfri) IP Adresse Maskinnavn Bruger ID IT-System ID Organisation ID Organisationsenhed ID Id, som identificerer den kaldte service IPv4 eller IPv6 adresse, som entydigt identificerer enheden i et netværk. Maskinnavn for enhed, som genererer logbeskeden Unik identifikation af brugeren, som udfører kaldet Unik identifikation af det IT- System som udfører kaldet Teknisk nøgle, som identificerer organisationen, som brugeren er tilknyttet Teknisk nøgle for den organisatoriske enhed som brugeren er tilknyttet , 3ffe:1900:4545:3- :200:f8ff:fe21:67cf Pc2314 KK/jensho KYV2.13 KK KK/Udsatte børn og unge Systemlog Systemloggen er en fælles betegnelses for alle tekniske logs, som ikke falder indenfor de øvrige kategorier. Ved brug af kategori information, som ofte indeholder specifikke komponentnavne, vil systemloggen i realiteten kunne segmenteres målrettet på kilden, således at al log output for et givent artefakt eller komponent kan filteres. Kategoriseringen betyder, at den samme systemlog kan benyttes af flere separate systemkomponenter, hvilket er aktuelt når det samlede system eventuelt er opbygget af en samling separat delkomponenter eller -moduler. Side 14 af 22

15 For systemloggen logges udover det generelle log indhold, som beskrevet i afsnit følgende felter: Felt ID Indhold Type/Format Eksempel Loglevel Betydningseller alvorlighedsgrad DEBUG, IN- FO, WARN, ERROR WARN Logbesked Selve log indhold med vilkårligt data - Fejlkode Separat attribut som identificerer selve typen af fejl Int eller 1001 eller Illegal- Argument Revisionslog Det er revisionssporets primære formål at kunne fungere som grundlag, når/hvis et system skal dokumentere, at det lever op til de forskellige love, som omhandler adgang til data. Det er endvidere revisionssporet som danner grundlag for, at kunne dokumentere, hvem der i kommunerne har haft adgang til en given borgers data. I det efterfølgende beskrives først de love og bekendtgørelse, som stiller krav til revisionssporet. Foruden det generelle indhold, som beskrevet i afsnit 3.2.1, vil der i dette afsnit beskrives, hvad der yderligere skal logges i forhold til revisionsspor. Da meget af denne form for logdata vil blive genereret internt i et fagsystem, er der stadig behov for at kunne sammenstykke sagsbehandling foretaget over flere fagsystemer. For at muliggøre dette er det vigtigt, at der logges unikt data, som gør det muligt at sammenstille logdata fra flere systemer, således at alle relevante aspekter af en sag dokumenteres og kan fremfindes og vurderes på en overskuelig måde. Specifikt for revisionsspor logges følgende, udover det generelle log indhold, som beskrevet i afsnit 3.2.1, følgende felter: Felt ID Indhold Type/Format Eksempel Applikation Identifikation KY, SAPA af applikationen, samt evt. Komponent Komponent Navn på den kilde, som danner logbesked, som identificerer komponenten. For fagsystemer, som ikke opererer med komponent anvendes en anden unik Side 15 af 22

16 Borger ID Søgekriterier (valgfri) Sags ID Tilstandsskift* (valgfri) Part** (valgfri) Aktør*** (valgfri) Note (valgfri) Unik identifikation af borgeren, som der arbejdes med Anvendes, hvis borgers unikke identifikation ikke er tilgængelig. Unik identifikation på en given sag. Beskrivelse af tilstandsskift i en pågældende sag Ændringer i sagsparter Ændringer i sagsbehandler Mulighed for valgfrit at logge ekstra information identifikation af kilden f.eks delsystem eller agentnavn. CPR? Anden nøgle? Oplyst -> afgjort * Note: Et tilstandsskifte skal registrere selve skiftet, og ikke data tilknyttet, dvs. informationen om, fra hvilken tilstand og til hvilken tilstand, dette vil fremgår af selve sagsbehandlingssystemet. Dette skyldes at et tilstandstands ofte medfører en hændelse som distribueres (via klienter til beskedfordeleren), og som resulterer i en ny registrering i Sagsindekset, hvor al informationen er tilgængelig omkring selve skiftet. ** Note: Part refererer til OIO standarden for Part, og dækker derfor en person, virksomhed, organisationsaktør eller adresse, som er tilknyttet sagen. *** Note: Aktør referer til OIO standarden, og dækker den medarbejder 3, organisatorisk enhed eller det it-system, der udfører en given aktivitet eller den person, som har ansvaret for sagen (det er 3 Medarbejder er dog per OIO standarden Organisation, dækket af aktørtyperne Organisatorisk funktion eller Bruger, men bliver nævnt for den forståelsesmæssige beskrivelse. Side 16 af 22

17 den organisatoriske enhed, der har det formelle ansvar). Begrebet stammer fra OIO standarden for Organisation. Hvis der indgår ikke-kommunale systemer, andre ikke fælles kommunale systemer, eller kommunale lagacy systemer i en sagsbehandling, er det ikke sikkert at alle ovenstående logfelter kan opfyldes. Denne usikkerhed, i relation til de førnævnte andre systemtyper, end de fælles kommunale, skyldes, at man her ofte må forlade sig på de eksisterende logs, hvilket kan gøre sammenstillingen af logdata vanskelig, da formater og strukturer umiddelbart ikke kan forventes at være helt tilpasset med de retningslinjer, der beskrives i dette dokument. Der må derfor stilles krav til de eksisterende systemer, der vil indgå i en given sagsbehandling, eller anden interaktion med fag- og støttesystemer, om at de skal kunne levere logdata jf. disse retningslinjer på længere sigt. Derudover kan ovenstående problemstilling på sigt imødekommes ved at gøre generelle logningsservices tilgængelig (fx gennem Service Platformen), som kan tage imod/hente logdata Afregningslog Der ønskes en gennemsigtig afregningsproces, hvor aftageren, af fx data, og anvendersystemernes forbrug af services på systemet kan afregnes efter forskellige afregningsmodeller. Der er derfor et behov for, at kunne måle den enkelte aftagers og det enkelte anvendersystems forbrug af services og yderligere omkostningsbaserede ydelser, og afregne på baggrund af en serviceaftale. Afregning af forbrug af en service foretages efter definerede afregningsmodeller, der blandt andet kan baseres på antal servicekald eller overførte data ud fra forskellige takster. Systemet skal i denne forbindelse sikre det nødvendige datagrundlag. Indledningsvist vil afregning foregå ved, at et system er i stand til periodisk at fremskaffe og fremsende et udtræk af logning af forbrug. Udtrækket viser, hvor meget den enkelte aftager har forbrugt af de enkelte services, fordelt på de enkelte anvendersystemer. Udtrækket indeholder tilstrækkelige informationer til at kunne foretage korrekt afregning. For afregningsloggen logges derfor udover det generelle log indhold, som beskrevet i afsnit 3.2.1, hvilket betyder at det samlede datagrundlag for at kunne foretage afregningen består af både nedenstående logningsdata samt det logningsdata som er specificeret i de generelle logfelter. De følgende felter ønskes yderligere logget til brug for afregningsloggen: Felt ID Indhold Type/Format Eksempel Status Status på - forespørgsel Svarstørrelse Størrelsen på Integer svaret Operation Navnet på metode eller operation, som er kaldt - Forespørgselsstørrelse Størrelsen af beskeden Integer Svartid Tid brugt på operation Integer Side 17 af 22

18 Serviceaftale (valgfri) eller metode kald i millisekunder Unik ID på den service aftale som ligger til grund for forespørgslen (hvor muligt) Integer eller Verifikationslog og Driftslog Systemerne skal fx logge informationer til brug for dokumentation af deres opfyldelse af de SLA krav der er stillet til det enkelte system. Disse informationer skal fx anvendes til at give et billede af ressourcetræk, brugsmønstre mv. Derudover skal systemerne logge informationer til brug for fejlsøgning, både den system-interne fejlsøgning og den fejlsøgning der kan være relevant på tværs af systemer. Verifikationsloggen og Driftsloggen (eller Operatørloggen) specificeres ikke yderligere her, da den indgår som en del selve driftskontrakten, og kun omhandler produktionsmiljøet, men dele af informationerne i de generelle logfelter, systemloggen og verifikationsloggen vil kunne udtrækkes og bruges til formålet vedrørende systemmæssige fejlsøgning. Udover den generelle logs indhold, som beskrevet i afsnit 3.2.1, skal der driftsleverandøren sikre overholdelse af en række driftsrelaterede emner og logningskrav (se yderligere detaljer i driftskontrakten [REFERENCE]). Eksempler på førnævnte emner kunne være og er ofte følgende: Konfiguration af logning til registrering af ændringer, herunder at der skal være mulighed for at registrere alle ændringer, der er foretaget på systemet og data. Logning af succesfulde og mislykkede forsøg på adgang, herunder at der skal være mulighed at registrere alle forsøg på adgang til udstillede services og data. Sporbarhed for hele transaktionsforløb, herunder at det skal være muligt at følge givne transaktioner igennem et eller flere transaktionsforløb Logning af fejlsituationer, herunder at der skal foretages logning af fejlsituationer både i internt testmiljø, eksternt testmiljø, præproduktionsmiljøet og produktionsmiljøet. Overvågning af loggede informationer fra driftsværktøjer, herunder at det skal være muligt at opsamle informationer omkring systemet, således at det er muligt via overvågnings- eller logningsværktøjer i driftsværktøjer at følge systemets driftsstatus. Periodisk logningsudtræk, herunder at systemet skal understøtte periodisk udtræk af den samlede logning. Change historik, herunder logning af ændringer som er gennemført på produktionssystemet med tidsstempel for at sikre et revisionsspor. Patch management, herunder at der skal logges, hvornår patches var til rådighed og hvornår de blev installeret mhp. at have et revisionsspor på sikkerhed. Access management, herunder at der skal logges, hvem som har hvilke rettigheder til systemerne og serverne på hvilke tidspunkter samt hvilke ændringer vedkommende har lavet. Logning af sletning eller destruktion af server, udstyr og bånd i tilfælde af udskiftning for at sikre, at data ikke bliver tilgængelig for uvedkommende. Side 18 af 22

19 Datatilsynet Kommuner Fælles kommunalt Kommunernes revision Leverandør af tilstående fagsystemer Systemlog Driftslog Revisionslog Verifikationslog Afregningslog 3.3 Sammenfatning Dette afsnit opsummerer på følgende oversigter: Logningsemner med logtyper Logningsemner med interessenter Logningstyper og interessenter Tabellerne giver mulighed for at danne sig et overblik over, hvordan logningsemner og logtyper korrelerer, og hvordan de forskellige interessenters behov bliver afdækket i relation til disse Oversigt over logningsemner og logtyper Nedenstående oversigt sammenstiller sammenhængen mellem de identificerede logningsemner og logtyper. Emne/Logtype Lovmedholdelighed X X Sikkerhed X X X Revisionsspor X SLA Opfølgning X X X Fejlsøgning X X Overvågning X X X Afregning X X Oversigt over logningsemner og interessenter Nedenstående oversigt sammenstiller hvilken logningsemner, som er relevante for de identificerede interessenter. Emne/Interessen t Leverandør af fagsystem Lovmedholdelighed X X X X Sikkerhed X X X Revisionsspor X X X X SLA opfølgning X X X X Fejlsøgning X X X X Overvågning X X X X Afregning X X X X Side 19 af 22

20 Kommuner Fælles kommunalt Nedenstående oversigt sammenstiller hvilke logtyper er relevante for de identificerede interessenter: Datatilsynet Kommunernes revision Leverandør af fagsstem Oversigt over logningstyper og interessenter Logtype / Interessent Leverandør af tilstående fagsystemer Systemlog X X X X X X Revisionslog X X X X Verifikationslog X X X X Driftslog X X X X Afregningslog X X X 4 Tværgående logningsmål 4.1 Sammenhængende logs Som nævnt indledningsvist er der et behov for at kunne sammenstille logs fra de forskellige systemer med forskellige formål. Dette betyder, at logdata skal stilles til rådighed på forespørgsel efter nærmere aftale. Og at de skal kunne leveres på en struktur og et format der gør maskinel analyse mulig. For at kunne følge en given transaktion i alle de systemer, der måtte være en del af denne er det nødvendigt at logs indeholder en unik nøgle, der går igen i alle relevante systemers logs at logs har på grundlæggende punkter en forholdsvis ens struktur at logs findes/kan leveres i et format, der gør det muligt at sammenstille dem 4.2 Transaktions ID For at det skal være muligt at sammenstille logs på tværs af systemer, skal det transaktionsgenererende system medsende et Transaktions ID. Transaktions ID et skal være en UUID, skal dække hele transaktionen, og det vil eksempelvis betyde en hel sagsoprettelsesproces med udgangspunkt i det oprettende system. Dette gælder også selvom det indebærer interaktion med flere støttesystemer. Alle forespørgsler/transaktioner, hvor der modtages et UUID, skal logge, anvende og medtage dette frem for at generere egen/ny UUID. Side 20 af 22

21 4.3 Logstruktur og format Som minimum skal logs kunne leveres på en struktur der gør det muligt at sammenstille logs fra forskellige systemer. Indholdsmæssigt indebærer dette derudover det tidligere omtalte Transaktions ID, men i dette afsnit henvises udelukket til de formmæssige aspekter for loginformationerne. Loginformationerne skal gemmes via en gængs lagringsmetode, hvorfra standardværktøjer og metoder kan tilgå dem for efterfølgende behandling. Et eksempel på en gængs lagringsmetode er fx en relationel database, og eksempler på tilhørende standard værktøjer og metoder ville fx være via brug af ODBC eller JDBC, eller vha. standard rapporteringsværktøjer. Det skal noteres, at der ikke er eksplicitte krav for systemets interne lagringsformat, men det anbefales dog at følge gængse standard formater på området. Der er derimod særlige krav ved enten enkelte udtræk eller ved periodevise eksport af data til efterbehandling i forbindelse med en sammenstillingen. Eksempler på gængse formater for de gemte loginformationer, og specielt ved eksporterede loginformationer, er fx XML eller CSV. Begge formater betragtes som værende eksempler på maskinlæsbare formater. 5 Kravtabel Nedenstående krav er en række overordnede krav til de fælles kommunale systemer, i relation til at implementere, og så de følgelig overholder, de i dette dokument beskrevne aspekter i relation til logning. Det skal noteres af afregningsloggen er den eneste af de beskrevne logs, som for et givet system er en option. Den skal kun benyttes for de systemer, hvor der er behov for at afregning. De resterende krav, som ikke omhandler afregning, betragtes derfor alle som udgangspunkt som ufravigelige Dog som tidligere nævnt med enkelte undtagelser på udvalgte datafelter for de enkelte logs. Krav Opsamling og lagring af logdata i Løsningen Kategori: (MK) Type: Ikke funktionelt Beskrivelse: Støttesystemerne opsamler og gemmer logdata i og via en maskinlæsbar lagringsmetode og -system. Krav Generering og brug af et unik TransaktionsID Kategori: (MK) Type: Ikke funktionelt Beskrivelse: Støttesystemerne generer og benytter sig af unikke transaktions ID er, som anført i afsnit , og 4.2. Transaktions ID et skal sikre muligheden for at sammenstille logs på tværs af systemer. Krav Understøttelse af Systemlog i Støttesystemerne Kategori: (MK) Type: Ikke funktionelt Beskrivelse: Støttesystemerne implementerer en generel systemlog, som anført i afsnit og Systemloggen er en fælles betegnelses for alle tekniske logs, som ikke falder indenfor logkategorier. Side 21 af 22

22 Krav Understøttelse af Revisionslog i Støttesystemerne Kategori: (MK) Type: Ikke funktionelt Beskrivelse: Støttesystemerne implementerer en generel revisionslog, som anført i afsnit og Det er revisionsloggens primære formål at fungere som datagrundlag, når et system skal dokumentere, at det lever op til lovmæssigheder, som omhandler adgang til data. Krav Understøttelse af Afregningslog i Støttesystemerne Kategori: (MK) Type: Ikke funktionelt Beskrivelse: Støttesystemerne implementerer en generel afregningslog, som anført i afsnit og Afregningslogning har til formål at danne datagrundlag for at kunne afregne efter forbrug. Krav Ensartet struktur og format for logning af data i Løsningen Kategori: (K) Type: Ikke funktionelt Beskrivelse: Støttesystemerne kan eksportere logdata i et standard format, som anført i afsnit 4.3. Den ensartede struktur og format skal sikre muligheden for at sammenstille logs på tværs af systemer. Side 22 af 22