Bilag 1 Kundens opgavebeskrivelse

Transkript

1 Bilag 1 Kundens opgavebeskrivelse

2 Side 2 af 12 Indhold 1. Indledning Baggrund og formål Vision og mål Målgruppe Begreber Begrebsliste Opgavebeskrivelse Dokumentation Sikkerhed Trusler og egenskaber Sikkerhedspolitikker Lovmæssige krav Persondataloven Lov 429 af 31. maj Optioner Option Option Option

3 Side 3 af Indledning 1.1. Baggrund og formål Der er indenfor de seneste år sket en hastig udbredelse af mobile enheder som smartphones og tablet pc ere både til privat og erhvervsmæssig brug. Det har medført en hastigt voksende efterspørgsel på tjenester, der er udviklet til at fungere hensigtsmæssigt på de mobile platforme. Foruden at brugerne ønsker at kunne anvende mobile enheder til deres private og erhvervsmæssige brug af digitale tjenester, er der også konkrete potentialer for at optimere arbejdsgange mv. ved at inkludere mobile platforme i virksomhedernes IT-infrastrukturer. De mobile enheder understøtter generelt ikke Java og forskellige andre proprietære teknologier, som gennem mange år har været bredt anvendt i webbaserede tjenester til brug via traditionelle pc er. Det medfører, at en lang række webbaserede tjenester og redskaber, som i dag anvendes af virksomhederne, er helt eller delvist utilgængelige via mobile platforme. Den eksisterende NemID medarbejdersignatur er udviklet med anvendelse af Javateknologi, der således ikke kan afvikles på mobile platforme. NemID medarbejdersignatur med nøglekort opnår mobil understøttelse via den løsning, der også sikrer mobil understøttelse af NemID til borgere. SignaturGruppen har for Kunden udviklet Tjenesteudbyderpakken til NemID mobil medarbejdersignatur med lokal signaturserver. Kunden udbyder opgaven at supportere og vedligeholde Tjenesteudbyderpakken til NemID mobil medarbejdersignatur med lokal signaturserver Vision og mål Kunden ønsker at få vedligeholdt og supporteret den eksisterende Tjenesteudbyderpakke for NemID til mobil medarbejdersignatur til lokal signaturserver (LSS) Målgruppe Denne opgavebeskrivelse retter sig mod leverandører, der skal vedligeholde og supportere den eksisterende tjenesteudbyderpakke som kan anvendes af: 1) Leverandører af TU services, der skal levere en digital tjeneste via en mobil enhed, hvor NemID er påkrævet. 2) Leverandører af LSS produkter, der skal implementere koblingen med mobil NemID Klient API et og egen Service Provider Interface (SPI)

4 Side 4 af Begreber I dette afsnit findes oversigt over relevante begreber, som anvendes i denne opgavebeskrivelse Begrebsliste Følgende termer og centrale begreber er relevante i forbindelse med løsning af denne opgave. Begreb API App Browser Certifikat CSS CRL Beskrivelse Application Programming Interface. En standardiseret snitflade til et stykke software. Et API realiseres i nogle tilfælde af flere leverandører, der så implementerer API et mod deres eget SPI. En selvstændig applikation som hentes, installeres, startes og afvikles direkte på en mobil enhed. Se Hybrid App, Native App og Web App. Specifikt browser til mobile enheder, der overordnet set er identiske i funktionalitet og formål med en PC browser som Internet Explorer, Firefox m.fl. Et X.509 certifikat, der i denne kontekst overholder kravene til NemID med nøglefil. Central signaturserver, et produkt der lagrer private nøgler og certifikater for medarbejdere lokalt i virksomheden. Certificate Revocation List. En liste over certifikater, der er blevet spærret, som kan hentes den med intervaller og checkes lokalt. Se desuden OCSP. Hybrid App En App, som er hentet og installeret som en Native App, men som herefter tilgår en Web App (fx via en indlejret browser). Klient API MOCES Herved forstås specifikt NemID API et som kan anvendes ved implementering af Web-/Hybrid- /Native Apps på en mobil enhed. Se API OCES Medarbejdercertifikat (NemID medarbejdersignatur) Native App En App, der er designet og skrevet specifikt til en mobil enhed og dens platform. En Native App præsenterer indhold for brugeren og giver mulighed for bruger-input (indtastning, valg mv.). En Native App skal installeres eksplicit på den mobile enhed. NemID OCSP Den fællesoffentlige løsning til at få adgang til offentlige digitale tjenester med ét login og password, samt. evt. One-Time Password token (OTP) Online Certificate Status Protocol. Et online check af hvorvidt et certifikat er blevet spærret. Se desuden CRL. Privat nøgle En asymmetrisk nøgle, der sammen med en offentlig nøgle muliggør asymmetrisk kryptografi. Den private nøgle hører i denne kontekst sammen med den offentlige nøgle, der findes i en

5 Side 5 af 12 brugers certifikat. RSA SPI TU Web App Web App klient-side og serverside RSA er en public-key krypteringsalgoritme der baserer sig på at faktorisering af store heltal er et svært problem. RSA står for Ron Rivest, Adi Shamir and Leonard Adleman, som publicerede algoritmen i Service Provider Interface. En term, der dækker over en leverandørspecifik snitflade, der kaldes gennem et fælles API. Et SPI rummer desuden den logik, der oversætter mellem API og SPI (ofte kaldet en driver eller et plugin). Tjenesteudbyder. En offentlig eller privat organisation, der ønsker at udbyde en teknisk service, der kan kaldes via en App. En App, der bruger browseren til at præsentere indhold for medarbejderen og giver mulighed for bruger-input (indtastning, valg mv.). En Web App kræver ikke installation på enheden, eftersom enheden bliver leveret med en browser (som er det eneste værktøj der anvendes). En Web App er kendetegnet ved at have en server-side og en klient-side. Implementeringen af en Web App består af en del af app en der kører på en server (her TU ens server) og en del af app en der kører i brugerens browser (her på den mobile enhed). Klient-siden består af HTML(5) og JavaScript. Server-siden kan være realiseret med mange forskellige teknologier. 3. Opgavebeskrivelse Kunden udbyder vedligeholdelse og support af tjenesteudbyderpakke til NemID mobil medarbejdersignatur med lokal signaturserver. Denne Tjenesteudbyderpakken består af følgende komponenter: Documentation for service providers o General documentation o Implementation documentation o Test documentation o Test tools and source code Documentation for LSS suppliers o Implementation documentation o Test documentation o Solution documentation o Test tools and source code Documentation for end customers Vedligeholdelsesopgaven omfatter Nødvendige sikkerhedsopdateringer se nedenstående afsnit 5 om sikkerhed

6 Side 6 af 12 Tjenesteudbyderpakken skal til enhver tid afspejle de gældende certifikatstandarder Opdateringer, der kan være nødvendige af hensyn til understøttelse på nye versioner af styresystemer og webbrowsere At opdatere indholdet i dokumentationen på Fejlhåndtering/fejlrettelser Ved alle ændringer og opdateringer af Tjenesteudbyderpakken skal alle relevante komponenter i Tjenesteudbyderpakken opdateres, dokumenteres og testes grundigt, således at en samlet opdatering af Tjenesteudbyderpakken kan publiceres. Leverandøren skal i Løsningsbeskrivelsen (bilag 2), på baggrund af nedenstående minimumskrav til reaktionstider og fejltype-definitioner, redegøre for, om Leverandøren kan tilbyde en bedre SLA forbundet med vedligeholdelsesopgaven. Reaktionstid defineres som den tid det maksimalt må tage at registrere og klassificere fejlen og tilkalde personale med den nødvendige kompetence og udbedring påbegyndes. Fejltyper er opdelt i tre kategorier, som defineret herunder. 1. Prioritet 1-fejl: En fejl skal klassificeres som en prioritet 1 fejl, hvis der konstateres fejl i tjenesteudbyderpakken, som medfører at én eller flere tjenester ikke er tilgængelige via NemID mobil medarbejdersignatur med lokal signaturserver 2. Prioritet 2-fejl: En fejl skal klassificeres som en prioritet 2 fejl, hvis der konstateres fejl i tjenesteudbyderpakken, der medfører at en eller flere, men ikke alle, understøttede browserversioner ikke længere er understøttet 3. Prioritet 3-fejl: En fejl skal klassificeres som en prioritet 3 fejl, hvis det konstateres at: Den fundne fejl ikke har prioritet 1 eller 2. For fejlkategorier Prioritet 1 og Prioritet 2 skal Leverandøren uden unødigt ophold fortsætte afhjælpning indtil fejlen er rettet. Der skal garanteres en reaktionstid som angivet i tabellen herunder. Fejltype Reaktionstid (angivet i timer) Prioritet 1-fejl Max 1 Prioritet 2-fejl Max 2 Prioritet 3-fejl Max 8 Leverandøren skal måle og opgøre opfyldelse af SLA på vedligeholdelse pr. den 10. i hver måned og levere en månedlig statusrapport til Digitaliseringsstyrelsen. Hvis opgørelsen af SLA-opfyldelse for en periode ikke opfylder det aftalte, er Kunden berettiget til bod, jf. kontraktens pkt Reduktion i vederlag for vedligeholdelse og support beregnes efter følgende formel:

7 Side 7 af 12 For hver påbegyndt procent af det samlede antal henvendelser vedrørende indberetninger af fejl indenfor de respektive fejltyper i den pågældende måned, der ikke overholder målene defineret i SLA vedrørende vedligeholdelse, sker der reduktion i vederlaget for vedligeholdelse og support, jf. bilag 4, på 5 % for den pågældende måned, dog maksimalt 50 % af det faste månedlige vederlag for vedligeholdelse og support, jf. bilag 4. Leverandøren skal i Løsningsbeskrivelsen (bilag 2) angive kontaktoplysninger til brug ved indberetning af fejl og redegøre for hvordan vedligeholdelsesopgaven samlet set løses og organiseres. Supportopgaven omfatter: Max 2 timers support via telefon og /webformular pr. tjenesteudbyder/lokal signaturserverleverandør i forbindelse med implementering/installation af Tjenesteudbyderpakken, som er inkluderet i prisen for vedligeholdelse og support, jf. bilag 4. Er der mod forventning behov for yderligere support, kan der efter direkte aftale mellem Leverandøren og Tjenesteudbydere/lokale signaturserverleverandører ydes support. Sådanne aftaler er ikke omfattet af denne kontrakt. Ændringer og nødvendige tilpasninger i tjenesteudbyders og LSS-leverandørers eget miljø varetages af tjenesteudbyders egne ressourcer. Leverandøren skal i Tjenesteudbyderpakken angive kontaktoplysninger til supporten. Leverandøren skal i denne sammenhæng redegøre for placering og organisering af servicedesk eller anden form for single point of contact vedrørende support samt fejl- og ændringshåndtering i driftsfase. Disse oplysninger skal desuden indgår i proceduren, jf. særskilt leverance under dokumentation. Supportens åbningstider skal dække kl alle arbejdsdage. Supporten skal være tilgængeligt pr. telefon og . Arbejdsdage er defineret i kontraktens pkt Dokumentation Som dokumentation for Tjenesteudbyderpakken henviser Kunden til følgende hjemmeside: Tjenesteudbyderpakken vedligeholdes kun på engelsk. Som særskilt leverance skal Leverandøren levere en procedure for varetagelse af vedligeholdelsen i pdf-format til Kunden. Denne leverance skal ske i overensstemmelse med fristen i bilag 3.

8 Side 8 af Sikkerhed 5.1 Trusler og egenskaber Den distribuerede arkitektur omkring anvendelse af NemID på mobile platforme udløser en række sikkerhedstrusler, som en leverandør af API et skal bekymre sig om. I analysen omkring den valgte arkitektur er følgende alvorlige trusseltyper identificeret: Type af angreb Kommentarer Phishing Et ikke-teknisk angreb af typen Social Engineering, hvor brugeren narres til at anvende en falsk tjeneste. Man-in-the-middle (MitM) Man-in-the-middle angreb betinger at det er muligt for en modstander at placere sig in-themiddle og her aflytte og/eller påvirke kommunikationen. Angreb på den sikrede kommunikation Angreb på enten digitale signaturer/certifikater (autenticitet generelt), og angreb på kryptografiske algoritmer (konfidentialitet generelt) der finder sted efter en sikker forbindelse / chain-of-trust er etableret. Angreb på operativsystemet / infrastrukturapplikationer Det mobile operativsystem implementerer sikkerhedsforanstaltninger, der fx gør det umuligt for en Native App at tilgå hukommelse m.v. fra en anden Native App. Da der fra tid til anden findes nye sikkerhedshuller i operativsystemer, udgør operativsystemet en potentiel sikkerhedsrisiko. Dette gælder også andre Apps hvis sårbarheder kan udnyttes af en modstander til at få eleverede system rettigheder. En LSS leverandør, der laver en produktspecifik implementering af API et mod egen LSSserver, vil skulle forholde sig til ovenstående angrebsvektorer og forsøge at imødekomme dem. Leverandøren af Tjenesteudbyderpakken kan imidlertid opstille

9 Side 9 af 12 generelle retningslinjer, f.eks. for hvordan den virksomhed, der har købt et LSS produktet bør forholde sig til sikkerhed på mobile enheder, i driftsmiljøet, mm. Generelle retningslinjer for sikkerhed Beskrivelse Tjenesteudbyderpakken skal indeholde retningslinjer for sikkerhed, der kan videregives til en virksomhed, som ønsker at implementere en LSS server, der skal benyttes i NemID scenarier. Retningslinjerne skal som minimum rumme krav til beskyttelse af mobile enheder, samt krav til beskyttelse af driftsmiljøet og servere. Retningslinjer for sikkerhed mellem Klient API og LSS Server Beskrivelse Tjenesteudbyderpakken skal indeholde anbefalinger omkring sikkerheden mellem Klient API et og LSS serveren, der kan bruges af en LSS leverandør til at implementere en sikret kommunikation mellem de to dele. Overvejelserne skal gives i form af konkrete eksempler på protokoller, der fx. kan sikre integritet, autenticitet og konfidentialitet på transportlaget, samt evt. også på datalaget. Leverandøren skal desuden redegøre i Tjenesteudbyderpakken for, hvilke tiltag og relevante kombinationer heraf, der er nødvendige for at opnå et sikkerhedsniveau svarende til det, der er gældende ved de eksisterende java-baserede løsninger. 5.2 Sikkerhedspolitikker Der eksisterer flere forskellige sikkerhedspolitikker og krav, som er direkte relateret til support og vedligeholdelse af løsningen, men ikke som sådan en del af løsningen. Det forventes at disse sikkerhedsbetingelser og politikker er opfyldt i forbindelse med anvendelse af løsningen. Eksisterende betingelser for sikkerhed Certifikatpolitikken skal overholdes af virksomheden, LSS-Leverandøren og CA. Virksomhedens sikkerhedspolitikker skal overholdes. Virksomheden skal overholde betingelser og krav fremsat af LSS- Leverandøren. Virksomhedens personale spiller en vigtig rolle i at opnå et tilstrækkeligt

10 Side 10 af 12 sikkerhedsniveau for løsningen, hvorfor der opstilles antagelser og krav til personale. Phishing er en signifikant trussel mod sikkerheden i løsningen, hvilket medfører yderligere krav til virksomhedens personale og dens tekniske kompetencer. Krav til virksomhedens medarbejdere Det påhviler virksomheden at sikre, at dets medarbejdere har de rette kompetencer og den nødvendige viden til at agere hensigtsmæssigt i sikkerhedsmæssig forstand. Som minimum skal medarbejderne være uddannet i virksomhedens interne sikkerhedspolitik, der skal inkludere krav vedrørende NemID med LSS. Virksomhedens medarbejdere skal have den fornødne tekniske viden omkring sikre HTTP forbindelser samt certifikaters gyldighed Virksomhedens medarbejdere skal uddannes i identificering af phishing angreb Virksomhedens medarbejdere kan uddannes i identificering af sikkerhedsrisici for mobile enheder Virksomheden skal aktivt søge at forhindre, at dets medarbejderes akkreditiver falder i de forkerte hænder. Krav til virksomhedens netværk, kommunikation og hardware Virksomhedens LAN og WiFi skal være sikret tilstrækkeligt Hvis medarbejderen skal tilgå virksomheden fra en ekstern fysisk lokation, skal dette ske igennem en sikker forbindelse (VPN) Mobile enheder skal sikres og der skal være klare sikkerhedsretningslinjer for medarbejderne Mobile enheder kan administreres fra lokalt hold vha. MDM For Tjenesteudbyder er det primært vigtigt at sikre applikationer mod hacking og dermed potentiel kompromittering af klient API et, når dette hentes via LSS en.

11 Side 11 af 12 Samtidig er det væsentligt, at Tjenesteudbyderens klientkode arbejder mod den aktuelle version af klient API et. Krav til Tjenesteudbyder Tjenesteudbyder skal sikre at klient API'et ikke caches i browseren vha. cache-direktiver Tjenesteudbyder skal imødegå sikkerhedsrisici for egen applikation, tekniske som organisatoriske 6. Lovmæssige krav 6.1 Persondataloven Lov 429 af 31. maj 2000 Både i den offentlige og i den private sektor gælder loven først og fremmest for behandling af personoplysninger, som sker ved hjælp af elektronisk databehandling. Det betyder, at loven gælder, når personoplysninger behandles ved hjælp af computerteknik, f.eks. skrivning af breve eller systematisering af persondata i en pc. "Elektronisk databehandling" omfatter altså almindelig tekstbehandling, hvori der indgår personoplysninger, men ikke brug af gammeldags, elektriske skrivemaskiner. Loven gælder også, når personoplysninger sendes over Internettet, og når personoplysninger offentliggøres på en hjemmeside på Internet. På tilsvarende vis skal bestemmelserne i Sikkerhedsbekendtgørelsen overholdes jf. BEK 528 af 15. juni Overholdelse af Persondataloven og Sikkerhedsbekendtgørelsen Beskrivelse Leverandøren skal i tjenesteudbyderpakken beskrive krav til overholdelse af Persondatalovens forskrifter om beskyttelse af personlige oplysninger overholdes, samt at forskrifterne i Sikkerhedsbekendtgørelsen imødekommes. 7. Optioner Krav der er formuleret som optioner skal besvares af Leverandøren på en måde, så Kunden kan til- og fravælge disse i forbindelse med kontraktindgåelse. Optioner prissættes særskilt i bilag 4.

12 Side 12 af Option 1 Inden kontaktens udløb med et varsel på 1 måned kan Kunden vælge at forlænge kontrakten med 1 år. Prisen for Option 1 fremgår af bilag Option 2 Såfremt Kunden vælger at gøre brug af Option 1, kan kontrakten forlænges med yderligere 1 år. Kunden skal gøre brug af Option 2, inden Option 1 udløber med et varsel på 3 måneder. Prisen for Option 2 fremgår af bilag Option 3 Såfremt Kunden vælger at gøre brug af Option 1 og Option 2, kan kontrakten forlænges med yderligere 1 år. Kunden skal gøre brug af Option 3, inden Option 2 udløber med et varsel på 3 måneder. Prisen for Option 3 fremgår af bilag 4.