UNI-login tilbyder samlet set mulighed for autentifikation på tværs af applikationer samt adgangsstyring/adgangsadministration (for leverandører af digitale løsninger). UNI-login er en ydelse leveret af Styrelsen for It og Læring (STIL) som en del af styrelsens opgavevaretagelse. Denne servicemålbeskrivelse fungerer derfor ikke som en SLA (Service Level Agreement) mellem kunde og en leverandør. Dokumentet beskriver de mål, der er sat for STIL’s ydelser omkring UNI-login. De angivne servicemål er derfor ikke bodsbelagte, ligesom det er STILs opgave til enhver tid at tilpasse denne beskrivelse til de samlede behov indsamlet fra interessenterne omkring løsningen. Hvis servicemål skal tilpasses, kræver det tilsvarende tilpasning i STILs rammer for opgavevaretagelsen. Dette dokument er målrettet tjenesteudbydere, der er tilsluttet UNI-logins services, som STIL stiller til rådighed. Servicemålbeskrivelsen dækker tidsrummet kl. 8-16 på skolehverdage (se skolernes ferieperioder under 2.2 - Servicevinduer). De enkelte services er som udgangspunkt tilgængelige 24 timer i døgnet 365 dage om året. Fejl registreret uden for servicemålbeskrivelsens tidsrum, behandles ved start af servicemålbeskrivelsens førstkommende tidsrum. Dokumentet beskriver forhold vedrørende:1 - Indledning
Den månedlige driftseffektivitetsprocent opgøres således for det enkelte Servicekategori: Hvis det ikke er muligt at opretholde almindelig drift på grund af fejlretning eller vedligeholdelse af en Servicekategori, skal dette ske inden for aftalte servicevinduer. STIL kan maksimalt etablere 12 servicevinduer om året af 4 timers varighed for de mest kritiske services. STIL vil så vidt muligt sikre, at der maksimalt afholdes ét servicevindue pr. måned på de mest kritiske services. For UNI-logins brugergrænseflader må der forekomme maximalt 24 servicevinduer om året. Annoncering af servicevinduer: Skolernes ferieperioder er: Tid anvendt på fejlretning eller vedligeholdelse inden for et udmeldt servicevindue indregnes hverken i tilgængelig eller potentiel driftstid. Såfremt STIL anvender mere tid til et servicevindue end udmeldt, fraregnes den yderligere anvendte tid dog den tilgængelige driftstid. Tjenesteudbydere, der er tilmeldt STIL’s driftsinformation, vil blive varslet om behovet for etableringen af et servicevindue, med mindre fejlretningen er meget kritisk for systemets generelle stabilitet. STIL Driftsinfo: http://driftsinfo.emu.dk Hvis nedetid skyldes forhold, der er STIL uvedkommende, f. eks. fejl i tjenesteudbyderens eget udstyr eller i tjenesteudbyderens applikationer, generelle netværksfejl eller fejl i kommunikationslinjer, udgør den manglende tilgængelighed ikke nedetid i denne beskrivelses forstand. Ved ’tjenesteudbyder’ forstås her en applikation, der benytter UNI-logins services; det er eksempelvis et forlag der tilbyder digitale læremidler eller en leverandør som leverer samarbejds- og læringsplatforme. Driftshindringer, som tjenesteudbyderen er ansvarlig for samt udefrakommende forstyrrelser, som f.eks. strømafbrydelser, lynnedslag, indbrud, brand, vandskader og lignende, medregnes ikke som nedetid. Servicevinduer og øvrige varslede stop, medregnes ikke som nedetid. Denne servicemål-beskrivelse omfatter ikke services der måtte eksistere længere end 6 måneder efter, de er erstattet af en ny version. 2 - Driftseffektivitet
2.1 - Definition
2.2 - Servicevinduer
2.3 - Øvrige forhold
2.4 - Undtagelser
Svartid måles så tæt på grænsen til tilsluttede applikationer som muligt, fra en forespørgsel modtages, til den returneres derfra igen.3 - Svartid
3.1 - Definition
Reaktionstid defineres som den tid, det maksimalt må tage at registrere og klassificere en fejl og tilkalde driftspersonale med de nødvendige kompetencer, der kan påbegynde udbedring. Fejltyper er opdelt i fire kategorier: Prioritet A-fejl: En fejl skal klassificeres som en prioritet A-fejl, hvis det ved måling eller alarm konstateres at: En eller flere services ikke er tilgængelige. Prioritet B-fejl: En fejl skal klassificeres som en prioritet B-fejl, hvis det ved måling eller alarm konstateres at: En eller flere services ikke overholder servicemål Prioritet C-fejl: En fejl skal klassificeres som prioritet C-fejl, hvis det ved måling eller alarm konstateres at: Den fundne fejl generer, men forhindrer ikke brug af servicen Prioritet D-fejl: En fejl skal klassificeres som prioritet D-fejl, hvis det ved måling eller alarm konstateres at: Den fundne fejl ikke har prioritet A, B eller C. Ved fejltyper prioriteret A og B skal STIL uden unødigt ophold fortsætte afhjælpning, indtil fejlen er rettet.4 - Reaktionstider ved fejlretning
4.1 - Definition
4.2 - Fejltyper
Nedenfor er opstillet de servicemål, som drift af UNI-Login skal overholde. Systemerne opdeles i fire servicekategorier, hvoraf: Servicekategori Kritikalitet Månedlig driftseffektivitetsprocent Kritisk driftstid på hverdage 1 - autentifikation 5 99% kl. 8-16 2 - straksopslag 5 99% kl. 8-16 3 - fulde træk og administration 4 99% kl. 8-16 4 - brugergrænseflader 3 99% kl. 8-16 Kritisk driftstid: Højkritisk driftstid: Servicekategori 1 består af UNI-Logins autentifikationsservices: Servicemålene for servicekategori 1 er: Fejltype Reaktionstid (timer) Prioritet A-fejl 0,25 Prioritet B-fejl 1 Prioritet C-fejl 6 Prioritet D-fejl (ved lejlighed) Servicekategori 2 består af UNI-Logins straksopslagswebservices og UNI-Logins autorisationsservices: Servicemålene for servicekategori 2 er: Fejltype Reaktionstid (timer) Prioritet A-fejl 0,5 Prioritet B-fejl 1 Prioritet C-fejl 6 Prioritet D-fejl (ved lejlighed) Servicekategori 3 består af Integrationsplatformens og UNI-Logins fulde træk-webservices og UNI-Logins administrations-webservices: Servicemålene for servicekategori 3 er: Fejltype Reaktionstid (timer) Prioritet A-fejl 1 Prioritet B-fejl 2 Prioritet C-fejl 6 Prioritet D-fejl (ved lejlighed) Servicemålene for Servicekategori 4 er: Fejltype Reaktionstid (timer) Prioritet A-fejl 1 Prioritet B-fejl 3 Prioritet C-fejl 6 Prioritet D-fejl (ved lejlighed) Det påhviler STIL at opgøre opfyldelsen af servicemål for UNI-Login d. 7. i hver måned. Der udarbejdes ikke tjenesteudbyderspecifikke statusrapporter eller lignende.5 - Servicemål for drift
5.1 - Servicekategori 1
5.2 - Servicekategori 2
5.3 - Servicekategori 3
5.4 - Servicekategori 4
5.5 - Måling og opgørelse af servicemål
Nedenfor er opstillet de servicemål, som tjenesteudbyder-support og serviceforespørgsler skal overholde. Serviceforespørgsler kan eksempelvis være en tjenesteudbyders behov for at blive tilsluttet en eller flere webservices. Supportkanal Servicemål Telefoni, support 80% af alle henvendelser skal kunne straksafklares telefonisk. Svarprocent på 90 % (90 % af alle henvendelser besvares) 80 % af besvarede kald er besvaret inden for 3 minutter Skriftlige sager, support Alle skriftlige henvendelser behandles inden for to arbejdsdage. 2. linje, support Sager videregivet til 2. linje skal være behandlet senest 2 dage efter sagen er videregivet. 1.linje informerer tjenesteudbyderen om, at sagen er videregivet Skriftlige sager, serviceforespørgsler Alle serviceforespørgsler skal ske skriftligt. Alle skriftlige henvendelser behandles inden for to arbejdsdage. Serviceforespørgsler skal være effektueret inden for fem arbejdsdage. STIL yder ikke support på systemer og komponenter hos tjenesteudbyderen, når det er problemer med disse, der er årsagen til manglende integration til STIL's grænseflader og webservices. STIL yder ikke support og rådgivning af forretningsmæssig karakter. Det påhviler STIL at måle op opgøre opfyldelsen af servicemål for tjenesteudbydersupport og serviceforespørgsler senest d. 7. i hver måned. Der udarbejdes ikke tjenesteudbyderspecifikke statusrapporter eller lignende.6 - Servicemål for support og serviceforespørgsler
6.1 - Supportens åbningstider
6.2 - Beskrivelse af tjenesteudbydersupport og serviceforespørgsler
6.3 - Systemer og områder, der ikke ydes support på
6.4 - Måling og opgørelse af servicemål for tjenesteudbydersupport og serviceforespørgsler
I tidsrummet kl. 8-16 på hverdage, udsendes der løbende driftsinformation i forbindelse med prioritet A- og prioritet B-fejl, jf. punkt 4.1. Nedenfor er opstillet de servicemål, som STIL skal overholde i forbindelse med information om driftproblemer. Tid efter registrering af fejl Beskrivelse 0-15 minutter Information om registrering af problem 15-30 minutter (om nødvendigt) Information om problemets karakter 15-90 minutter (om nødvendigt) Status på problemløsning og estimat på løsningstid 90-slut minutter (om nødvendigt) Løbende status på problemløsning og estimat på løsningstid Hurtigst muligt efter problemet er løst Information om at driften er normal Hurtigst muligt efter problemløsning (om nødvendigt) Nærmere information om problemets karakter og evt. tiltag foretaget i forbindelse med problemløsningen.7 - Servicemål for kommunikation
Der tages daglig backup af løsningen og løsningens data. Backup gemmes på servere ’eksternt’, og kan om nødvendigt benyttes i tilfælde af et større nedbrud, hvor data og løsning skal reetableres. Tid for reetablering afhænger at nedbruddets størrelse og kompleksitet.8 - Backup/restore
De oplysninger, der behandles i UNI-Loginsystemet, er alene identifikationsoplysninger, dvs. oplysninger om bl.a. navn, adresse, telefonnumre, e-mail, cpr-numre, uddannelsesoplysninger (f.eks. skole, afdeling, klasse) om elever og kontaktpersoner (f.eks. forældre eller værger) samt om medarbejdere på skolerne. Viden.stil.dk ses, hvilke data en skole potentielt kan overføre til UNI-Login-systemet. UNI-Login kan anvendes til styring af adgangsrettigheder til pædagogiske og administrative tjenester, hvorfor det er vigtigt, at der kan ske en entydig identifikation af den pågældende bruger, der vil tilgå den pågældende tjeneste. En entydig identifikation er f.eks. afgørende, hvor UNI-Login anvendes i forbindelse med digitale prøver i forbindelse med uddannelserne. UNI-Loginsystemet er indrettet således, at en administrator på hver skole i systemet skal markere, hvilke tjenester UNI-Login skal kunne bruges som digital identifikationsløsning i forhold til og derved få adgang til oplysningerne i UNI-Login. Tilsvarende kan en rettighed let fjernes igen, ligesom den enkelte skole let kan få et overblik over, hvilke tjenester der er tildelt rettigheder. Ud over markeringen skal den enkelte kommune eller skole indgå en databehandleraftale med den tjeneste (eksempelvis et forlag) der skal anvende UNI-Login. For så vidt angår systemer, hvor det ved lov eller bekendtgørelse er fastsat, at UNI-Login skal bruges, videregives oplysningerne i UNI-Login automatisk. For så vidt angår systemer, hvor det ikke ved lov eller bekendtgørelse er fastsat, at UNI-Login skal bruges, videregiver STIL oplysningerne i UNI-Login på skolens instruks. Der skal jf. ”Lov om ændring af lov om institutioner for almengymnasiale uddannelser og almen voksenuddannelse m.v., lov om institutioner for erhvervsrettet uddannelse og forskellige andre love” § 15 g ikke indgås databehandleraftaler mellem skolerne og STIL omkring behandlingen af skolernes data Ud over identifikationsoplysninger indeholder UNI-Login information om tjenesternes tilslutning til UNI-Login (f.eks. læringsplatforme, digitale læremidler mv). Denne information indeholder ikke personoplysninger.9 - Data
En sikkerhedshændelse defineres i dette dokument som: En hændelse der negativt påvirker eller vurderes at ville kunne påvirke tilgængeligheden af løsningen eller integritet eller fortrolighed af data i løsningen. Et eksempel på en sikkerhedshændelse, der negativt påvirker tilgængeligheden af løsningen, er et overbelastningsangreb (denial-of-service-angreb), hvor løsningen rammes af et stort antal forespørgsler, så brugere ikke kan få adgang til en hjemmeside. En sikkerhedshændelse, der negativt påvirker integriteten af data, kan eksempelvis være indtrængen i databasen, hvor oplysninger ændres uden STIL’s vidende. En sikkerhedshændelse, der negativt påvirker fortroligheden af løsningen, kan være en såkaldt »trojansk hest«, hvor der installeres et program i løsningen, som muliggør uautoriseret kopiering af data. UNI-login er sikret mod sikkerhedshændelser i henhold til gældende praksis på området. Berørte parter informeres direkte i det omfang, det er muligt. Der gennemføres årligt et sikkerhedseftersyn af UNI-login-løsningen, for at sikre at løsningen fortsat overholder gældende lovgivning omkring datasikkerhed. 10 - Sikkerhedshændelser og revision