Driftsaftale. OS2faktor

Transkript

1 Driftsaftale OS2faktor

2 1 Terminologi I dette aftaledokument har nedenstående ord følgende betydning. Leverandøren Kunden Løsningen betegner Digital Identity betegner OS2 fællesskabet omkring OS2faktor betegner OS2faktor produktet Driftsmiljøet betegner den driftsinfrastruktur der er beskrevet i afsnit 3 2 Omfang Denne aftale dækker drift, backup, overvågning samt løbende opdatering af OS2faktor backend og klienter som en SaaS (Software-as-a-Service) ydelse. Denne aftale drækker ikke videreudviklingsopgaver på Løsningen, alene drifts- og supportaspekter. 3 Driftsinfrastruktur Leverandøren anvender AWS som driftsleverandør, og benytter sig af følgende IaaS (Infrastructure-as-a-Service) komponenter fra AWS platformen. Elastic Load Balancer (ELB) Elastic Container Services (ECS) Elastic Container Registry (ECR) Elastic Compute Cloud (EC2) Relational Database Services (RDS) Amazon CloudWatch Alle ovenstående komponenter er en del af AWS ISO27001 (Information Security) og ISO27018 (Cloud Privacy Protection) certificeringer, og der er indgået en databehandleraftale med Amazon AWS. 3.1 Miljø og redundans Driftsmiljøet gør brug af de High-Availability features som tilbydes på AWS platformen, herunder brugen af Load Balancer, Applications Cluster og Database Cluster, kombineret med AWS platformens automatiske re-etablering af døde servere, databaser, diske m.m Applikationsservere Driftsmiljøet konfigureres med et cluster af applikationsservere (Docker Container Hosts via ECS), der er skaleret til at imødekomme mængden af tilsluttede kommuner og antallet af klienter og connectors. AWS platformen overvåger serverne via de overvågningssnitflader som løsningen tilbyder, og tager ikke-responsive servere ud af drift, og starter nye servere op efter behov, så der altid er det nødvendige antal aktive servere kørende i clusteret. Applikation er stateless, hvilket betyder at applikationsservere kan tages ind og ud af clusteret uden at det påvirker brugeroplevelsen af løsningen. AWS Platformen understøtter at drifte applikationen i flere tilgængeligshedszoner (fysiske hosting centre), og Driftsmiljøet er konfigureret til at køre mindst én applikationsserver i hver Digital Identity ApS, Bakkedraget 1, 8362 Hørning 2 / 8

3 tilgængelighedszone, så evt større nedbrud i ét driftscenter ikke påvirker tilgængeligheden af løsningen. Driften ligger i AWS driftcentre i Irland, hvor der på nuværende tidspunkt er 3 tilgængelighedszoner Database servere Driftsmiljøet konfigureres med en serverless datababase, baseret på AWS Aurora platformen, der tilbyder høj tilgængelighed, og optimale skaleringsmuligheder. Storage er spejlet på tværs af flere diske i hver tilgængeligszone, og replikeret på tværs af tilgængelighedszoner, og AWS platformen sørger for at døde diske erstattes løbende, for at sikre højeste mulige oppetid. Der tages automatisk fuld backup af databasen hver 4. time, og backups gemmes i 10 dage, inden de destrueres. 3.2 Load balancer og netværksadgang Driftsmiljøet er låst for direkte adgang til såvel applikationsservere og database, og installation af software, backup/restore af database m.m. foretages primært automatisk via konfiguration af Driftsmiljøet, og sekundært via AWS Management Console. Kundens adgang til miljøet sker alene gennem den Load Balancer der er opsat foran miljøet, der alene accepterer trafik på HTTPS/ Arkitekturtegning 3.4 Logning og overvågning Applikationsservere, OS2faktor og databasen anvender AWS logopsamlings-infrastruktur til at sende alle logdata til CloudWatch, hvor de gøres tilgængelige for såvel overvågning/alarmering samt visuel adgang via AWS Management Console. Digital Identity ApS, Bakkedraget 1, 8362 Hørning 3 / 8

4 3.5 Driftstatus Der udstilles en driftstatusside for OS2faktor, baseret på real -tidsovervågning (op til 5 minutters forsinkelse) af driftsmiljøet. Driftstatussiden viser status på de enkelte komponenter i driftsmiljøet, samt information om evt utilgængelige tjenester indenfor de sidste 24 timer. 4 SLA 4.1 Oppetid Løsningens planlagte oppetid er 24/7/365 Der må være 1 planlagt servicevindue hver måned Servicevinduet skal planlægges til at falde i en weekend (dvs starte efter lørdag morgen kl 04:00, og slutte før mandag morgen kl 04.00) Servicevinduet må ikke være længere end 4 sammenhængende timer Servicevinduet skal meldes ud mindst 1 kalendermåned for det påbegyndes Løsningen skal være tilgængelig 99,9% af den planlagte oppetid (planlagte servicevinduer tæller ikke som nedetid) Bemærk at Servicevinduer som udgangspunkt altid planlægges så de ikke påvirker oppetiden af løsningen alene ændringer der kræver omstrukturering af skemaet i databasen vil kræve nedetid, og i så tilfælde kun den tid der tager at foretage opdateringen af databasen. 4.2 SLA på standard ydelser Support foregår på , og svartiden på support-henvendelse er maksimalt 2 arbejdsdage. Supporten håndterer de nedenfor nævnte standardydelser, samt evt tilkøbesydelser. 4.3 SLA ved systemnedbrud Leverandøren er ansvarlig for automatisk overvågning af Løsningen og Driftsmiljøet, og håndterer systemnedbrud med det samme de opdages, også i weekend/helligdage. Leverandøren skal kunne re-etablere driften indenfor maksimalt 12 timer efter nedbruddet er opdaget, evt ved at slå driften over på ny-etablerede images, med et restore af en database backup. 4.4 Kontaktkanaler Den primære kontaktkanal ved support/drifts-henvendelser er , og Leverandøren kan kontaktes på [email protected]. Alle indgående s på denne adresse resulterer i en automatisk oprettelse af en trouble-ticket i Leverandørens trouble-ticketing system (pt. Jira). Kunden skal stille en (eller flere) adresser til rådighed, hvor Leverandøren kan sende driftsinformation vedrørende servicevinduer og lignende. Leverandøren vil sikre at Kunden holdes opdateret om alle drifts-relaterede hændelser via denne kanal. Kunden har også mulighed for at kontakte Leverandøren på telefon ( ), der er dog ingen SLA på svar telefonåbningstid, men Leverandøren vil forsøge at besvare alle indkommende kald, samt ringe tilbage på ubesvarede kald så snart som muligt. Digital Identity ApS, Bakkedraget 1, 8362 Hørning 4 / 8

5 Hvis der oprettes en driftssag på baggrund af en telefonhenvendelse, opretter Leverandøren en trouble-ticket på vegne af Kunden, så driftssagen kan spores på samme måde som hvis der var tale om en henvendelse. 5 Kundens opgaver ved ibrugtagning I forbindelse med ibrugtagning af Løsningen kan Kunden have en eller flere af følgende opgaver Informere medarbejdere om OS2faktor klienter, og hvordan disse skal installeres og ibrugtages Udruldning af OS2faktor klienter via MDM, SCCM eller lignende masseudruldningsfunktionalitet Opsætning af Connectors i AD FS, Netscaler, VPN Concentrator, osv Løbende indlæsning af evt bruger-pseudonymer Leverandøren tilbyder forskellige standard- og tilkøbsydelser til at assistere med disse opgaver. 6 Leverandørens opgaver Leverandøren er ansvarlig for stabil drift og overvågning af løsningen, samt tilslutning af Connectors til den fælles infrastruktur. Leverandøren skal sikre at infrastrukturen kan anvendes af de tilsluttede kommuner til alle de understøttede formål, herunder tilslutning af fællesudviklede Connectors, samt kommunens egenudviklede Connectors. Leverandøren er ansvarlig for at sikre at driften af løsningen overholder gældende dansk lovgivning. 7 Standardydelser Inkluderet i driften er følgende standardydelser, der tilbydes uden yderlige beregning Oprettelse af kommunen i OS2faktor backenden Tilslutning af Connectors i OS2faktor backenden (udveksling af nøgler og hul-igennemtest) 2nd level support, rettet mod den enkelte kommunes it-afdeling, hvor leverandøren bl.a. kan assistere med fejlsøgning i integrationen mellem kommunens infrastruktur og OS2faktor backenden Udtræk af metrikker fra driftsmiljøet efter forespørgsel fra OS2. Disse metrikker dækker o Målt oppetid på driftsmiljøet, angivet i % oppetid per måned, op til 6 måneder tilbage i tid o Antal aktive klienter, fordelt på klient-type o Antal logins foretaget siden sidste metrik-udtræk (leverandøren nulstiller tællere i forbindelse med udtræk af metrikker). 8 Tilkøbsydelser Leverandøren tilbyder også følgende tilkøbsydelser til medgået tid Assistance til opsætning af Connectors i kommunens egen infrastruktur Slutbruger support, herunder undervisning og hjælp til brug af klienter Digital Identity ApS, Bakkedraget 1, 8362 Hørning 5 / 8

6 Workshops omkring brugen af OS2faktor (fx om arkitektur-, strategi- og udruldnings overvejelser) 9 Leverandørens misligholdelse 9.1 Forsinkelse Såfremt Leverandøren har påtaget sig at løse opgaven indenfor en bestemt tid og overholder leverandøren ikke fristen er Leverandøren uden videre forpligtet til at betale Kunden en bod. Boden beregnes pr. arbejdsdag af det samlede beregningsgrundlag. Boden udgør 0,25 % pr arbejdsdag forsinkelsen varer. Beregningsgrundlaget for ovennævnte bod er det beløb, som oprindeligt er aftalt for opgavens gennemførelse, dog højst det beløb, som Leverandøren faktisk har faktureret Kunden de seneste 12 måneder for den pågældende opgave forud for forsinkelsens indtræden. Kunden er ikke berettiget til anden erstatning eller bod grundet forsinkelse udover den overfor nævnte bod. 9.2 Mangler Faktiske mangler Kunden er forpligtet til at undersøge, evaluere og teste det leverede, ved hver opgaves eller delopgaves afslutning. Der foreligger en faktisk mangel når systemet ikke lever op til denne aftales fastsatte krav til funktion, omgang, ydelser eller kvalitet. Eller i de tilfælde hvor kravene ikke er udtrykkeligt reguleret, i forhold til hvad Kunden med rimelighed kunne forvente af systemet/de leverede opgaver Reklamation Fejl eller mangler der opdages ved gennemgang af opgaverne udført i henhold til denne aftale, skal af Kunden påberåbes straks og uden ugrundet ophold overfor Leverandøren. Såfremt der foreligger en mangel ved de leverede ydelser, som må betegnes som væsentlig, og dette ikke burde være opdaget af Kunden i forbindelse med leveringen, kan Kunden påberåbe sig dette senest 12 måneder efter levering Afhjælpning Leverandøren er forpligtet til at afhjælpe de fejl og mangler, der opdages ved overleveringen af opgaverne omfattet af denne aftale. Mangler der konstateres efter leveringstidspunktet er omfattet af de øvrige misligholdelses beføjelser. 9.3 Ophævelse Kunden er berettiget til alene at hæve aftalen, hvis manglerne ikke inden rimelig tid er afhjulpet af Leverandøren. 9.4 Påkrav Krav på erstatning eller bod skal fremsættes overfor Leverandøren straks efter det tidspunkt, hvor Kunden ved sædvanlig agtpågivenhed er eller burde være i stand til at gøre sit krav gældende. Digital Identity ApS, Bakkedraget 1, 8362 Hørning 6 / 8

7 10 Erstatning 10.1 Erstatningsansvar Parterne er erstatningsansvarlige efter dansk rets almindelige erstatnings bestemmelser. Leverandørens erstatningsansvar er, hvis skaden er forårsaget ved simpel uagtsomhed, begrænset til direkte skader. Ansvaret omfatter ikke indirekte skade. Tab af data opfattes som direkte skade. Ovenstående begrænsning gælder ikke såfremt der er handlet groft uagtsomt eller forsætligt hos skadevoldende part. Der hæftes således også for indirekte skade og følge-skader. Leverandøren har bevisbyrden for at der ikke er handlet groft uagtsomt eller forsætligt Begrænsnings af erstatningsansvaret Det samlede erstatningsansvar er begrænset til 100 % af det fakturerede beløb, 12 måneder forud for skadens opståen. 11 Tvister Såfremt der opstår en uoverensstemmelse mellem parterne i forbindelse med nærværende aftale, skal parterne søge tvisten løst i mindelighed med en positiv, samarbejdende og ansvarlig holdning. Om nødvendigt skal forhandlingerne søges løftet op på højt plan i parternes organisationer. Såfremt der ej heller herved opnås nogen løsning, skal parterne søge at opnå enighed om i fællesskab at udpege en uafhængig og sagkyndig mægler, der kan mægle og komme med ikke-bindende forslag til tvistens løsning. Når det ovenfor beskrevne har været forsøgt, er hver af parterne berettiget til at kræve uoverensstemmelsen afgjort endeligt ved voldgift. Voldgiftsretten fastsætter selv sin procedure. Voldgiftsrettens kendelse, som skal være motiveret, skal afsiges snarest muligt og om muligt inden et halvt år efter voldgiftsrettens nedsættelse. 12 Pris Der anvendes en faktureringsperiode på 3 måneder, faktureret bagud. For en given faktureringsperiode faktureres et driftsvederlag, beregnet per tilsluttet kommune i perioden. Prisen per kommune afhænger af størrelsen på den enkelte tilsluttede kommune En lille kommune har under indbygere En mellem kommune har mellem og indbygere En stor kommune har over indbygere Hver lille kommune har et driftsvedelag på DKK ex. moms om året, hver mellem kommune har et driftsvederlag på DKK ex. moms om året, og hver stor kommune har et driftsvederlag på DKK ex. moms om året. Priserne baserer sig på det tilbudte driftsmiljø. Hvis ændringer i lovgivningen kræver større ændringer til driftsmiljøet (fx relokation af driftcenteret til Danmark), forbeholder Leverandøren sig retten til at ændre prismodellen. I forbindelse med en sådan ændring af prismodellen, vil den gamle prismodel være gældende i 6 måneder fra Leverandørens udmelding om ændringen. Digital Identity ApS, Bakkedraget 1, 8362 Hørning 7 / 8

8 Eksempel Hvis der for en given faktureringsperiode er 4 lille, 2 mellem og 3 store kommuner tilsluttet, bliver faktureringen for perioden på (4 x x x ) / 4 = DKK ex. moms De nævnte priser er indekspriser fastsat 1/1 2019, og korrigeres årligt d 1/1 i henhold til nettoprisindekset fra Danmarks Statistik 1, hvor der tages udgangspunkt i udviklingen fra oktober-til-oktober udviklingen i den foregående periode. 13 Dato og underskrift Aftalen er gældende fra og med xx/xx-20xx, og kan opsiges op til udgangen af en faktureringsperiode. Leverandør Digital Identity Aps CVR: Dato: Brian Graversen Kunde TODO CVR: TODO EAN: TODO Dato: TODO 1 Digital Identity ApS, Bakkedraget 1, 8362 Hørning 8 / 8