1 Information om dokumentet Bakgrund och syfte Designkriterier Generella krav på beskrivning av systemarkitekturen...

Transkript

1 SAD 1 (33) DÄHS designdokument v1.1 INNEHÅLLSFÖRTECKNING 1 Information om dokumentet Bakgrund och syfte Designkriterier En lösning för flera parter Ensning av kravbilden Systemsamverkan i det kommunsammanbindande nätet (KSB) Dokument- och ärendehantering skiljs från publicering av digitala möteshandlingar Åtkomst till dokument- och ärendehanteringsdelen Kvalitetssäkring av personuppgifter Ingen kryptering i samband med lagring av information Bestämning av tekniska skyddsåtgärder E-underskrift Beroenden till Karlstads IAM-tjänst Generella krav på beskrivning av systemarkitekturen Tekniska miljöer Övergripande systemegenskaper Driftsform Logisk instansiering (tenants) Systemets mognad Prestanda Applikationsarkitektur Verksamhetsrelaterad funktionalitet Inbyggd integritet Tillämpningsanvisning checklista Arkivering och gallring av information Arkivering av information Gallring av information Auktorisation, autentisering samt kontroll av användares åtkomst Terminologi Auktorisation av användare Känsliga personuppgifter/uppgifter med sekretess Personer med sekretessmarkering i folkbokföringsregistret...16

2 2 (33) Personer med kvarskrivning Personer med fingerade personuppgifter Autentisering av användare och kontroll av åtkomst Kryptering av information Transportkryptering (data i rörelse) Lagringskryptering (data i vila) Underskrift och stämpling av elektroniska handlingar Känsliga uppgifter/sekretess i molnet Ombud Samtycken Tillgänglighet och kontinuitet Kvalitetssäkring av personuppgifter Uppgiftsminimering Portering av data Pseudonymisering av personuppgifter Loggning av system- och användarrelaterade händelser Information till den registrerade Rättelse av personuppgifter Radering av personuppgifter Invändning mot behandling Begränsning av behandling Registerutdrag Krav på enskilda system Krav på det gemensamma registret över personuppgiftsbehandlingar Hjälpfunktioner Avisering Utsökning av information Rapportering Datastruktur och datainnehåll Webbapplikationer Microsoft Windows-baserade (native) applikationer Apple ios-baserade (native) applikationer Google Android-baserade (native) applikationer Beroenden till tredjepartsapplikationer Systemintegration och kommunikationsmönster Logiska systemsamband, bruttolista över integrationer Troligt förekommande integrationsbehov Mindre troligt förekommande integrationsbehov Krav på tekniska gränssnitt (API) Kommunikationstopologier Åtkomst till dokument- och ärendehanteringssystemet utan VPN Åtkomst till ärende- och dokumenthanteringssystemet med VPN Publicering av dokument till publiceringstjänst Åtkomst av dokument till publiceringstjänst för digitala möteshandlingar...31

3 3 (33) 8 Infrastrukturarkitektur Klient Klientdatorer av typen stationära (desktops) och bärbara (laptops) Klientdatorer av typen surfplattor Klientdatorer av typen smarta telefoner Server Nätverk Standarder för kommunikation VPN...33

4 4 (33) 1 Information om dokumentet Dokumentets ursprung Datum Version Initiator / roll / organisation Kommentar Gunnar Kartman, IT-arkitekt, Karlstads kommun Ändringshistorik Datum Version Namn / roll / organisation Avsnittshänvisning Kommentar v1.1 Gunnar Kartman, IT-arkitekt, Karlstads kommun Byte från diarie- och ärendehanteringssystem till dokumentoch ärendehanteringssystem. Godkännande och fastställande Datum Version Namn / roll / organisation Kommentar v1.0 Marie Edwinson / projektledare DÄHS Granskning i projektgrupp Remissinstanser Datum Instans Dokument Bilagor Nr Dokumentbeteckning Filnamn/länk [1] [2] Dokumentreferenser Nr Dokumentbeteckning Filnamn/länk [1] [2]

5 5 (33) 2 Bakgrund och syfte För bakgrundsinformation se projektets styrdokument. Detta designdokument är en preliminär beskrivning av den tänkta lösningen för en DSN 1 -gemensam tjänst för dokument- och ärendehantering där Karlstads kommun ansvarar för driften och är i rollen som tjänsteleverantör gentemot övriga parter i DSN (Värmlands kommuner). Syftet med dokumentet är att projektets intressenter ska få en möjlighet att förstå den preliminära tekniska omfattningen av den kommande tjänsten och att leverantörer i upphandlingen ska få ett så väl underbyggt underlag som möjligt att lämna anbud på. De beskrivningar som finns i dokumentet illustrerar hur Karlstads kommun som upphandlare och beställare tänker sig att den färdiga implementationen kan komma att se ut, givet de osäkerheter som förekommer i och med att utfallet av upphandlingen är okänt. 3 Designkriterier Följande kriterier sätter ramarna för DÄHS 2 systemdesign inklusive samverkan med andra externa system. 3.1 En lösning för flera parter Den lösning som eftersöks bygger på en multitenant-arkitektur så att Karlstads kommun som tillhandahållare av tjänster till de övriga parterna kan leverera så effektivt som möjligt. Varje tenant behöver konfigureras efter respektive parts behov. Det betyder att parterna gör sina egna bedömningar och att man avropar därefter. 3.2 Ensning av kravbilden Genom inhämtning av teknisk information från de övriga parterna har det efter bästa förmåga skapats en ensad kravbild. Av naturliga skäl kan dock inte alla krav tillgodoses. I de delar där det avviker är det Karlstads behov som har fått styra. Initialt så har Landstinget i Värmland av olika anledningar avgränsats. 1 Kommunerna i Värmland ingår i en gemensam drifts- och servicenämnd, som är en del av Karlstads kommuns organisation. 2 Dokument- och ärendehanteringssystem.

6 6 (33) 3.3 Systemsamverkan i det kommunsammanbindande nätet (KSB) Efter kontroll med IT-avdelningens IKT-förvaltning så ska vi kunna klara av att hantera kommunikationskraven för systemsamverkan via det kommunsammanbindande nätet (KSB) enligt de topologier som designen bygger på. I följande diagram ansluter KSB till Karlstads kommun via TeraCom:s infrastruktur (TeraCom FW). Grundskiss för det kommunsammanbindande nätet KSB. De kommuner som i ovanstående diagram ansluter sig till KSB via Telia Datanet har minst 10 Mbit/s dedikerad bandbredd för kommunikation mot KSB (uppgift från Telia ). Samtliga anslutningar är av fibertyp, förutom Årjängs anslutning som är av typen kopparanslutning. Lösningen per kommun ser lite olika ut då de kör olika tjänster på sina respektive Datanet anslutningar (exempelvis har Karlstad en variant där man kör mot CGI. KSB är uppsatt som ett eget slutet virtuellt nät med hjälp av VLAN- och VRF-teknik som åtskiljer denna trafik från de av Telias övriga kunder som kör på samma infrastruktur. Med andra ord är nätet slutet för alla andra utom parterna i KSB-samverkan, men utifrån parternas perspektiv måste man definitionsmässigt betrakta nätet som öppet då en kommun kan adressera alla andra KSB-anslutna kommuner, vilket i sin tur innebär att det är möjligt för respektive part att sätta upp tjänster som kan nås från vilken annan part som helst. Det är enkelt att höja kapaciteten för att kunna köra mer på KSB VPN eller lägga till ett nytt VPN. De fiberanslutna kommunerna som ligger utanför Telia Datanet kör 100 Mbit/s per förbindelse.

7 7 (33) Då Karlstad inte självt har kontroll på KSB, och bandbredderna varierar så rekommenderar IT-avdelningen att den upphandlade applikationen bör vara en webbapplikation utformad för en distribuerad användning. Bearbetning av data bör med andra ord ske på ett sådant sätt att minimalt utnyttjande av bandbredd kan uppnås. Det finns inga speciella krav på latency i KSB enligt IT-avdelningen. Följande gäller för användandet av KSB: Respektive part måste själva administrera sina egna brandväggar. Man kan inte räkna med hjälp från Karlstad då resurser saknas för den typen av assistans. Vaksamhet krävs på eventuella behov av kapacitetshöjningar. Huruvida det blir aktuellt styrs av det anskaffade systemets krav i kombination med respektive parts konfiguration i KSB. Respektive part måste besluta om och därefter administrera sina egna eventuellt förekommande VPN-lösningar. Karlstad kommer att exponera de systemresurser som krävs för att respektive part ska kunna köra DÄHS via KSB. Karlstads övriga resurser är med andra ord inte tillgängliga. 3.4 Dokument- och ärendehantering skiljs från publicering av digitala möteshandlingar Dokument- och ärendehanteringsdelen skiljs åt från publiceringsdelen i arkitektur och kravarbete. Skälet till detta är att det kan vara fråga om två olika system från olika leverantörer - eller inte, beroende på utfallet i upphandlingen. Publiceringsdelen delas i sin tur upp i en offentlig del samt en del för publicering av digitala möteshandlingar. Åtkomst sker via Internet. 3.5 Åtkomst till dokument- och ärendehanteringsdelen Av säkerhetsskäl tillåter vi åtkomst för användare av dokument- och ärendehanteringsdelen av systemet endast via KSB. Den part som lokalt väljer att använda VPN kommer självklart åt systemet utifrån ändå. Detta val ska hanteras med utgångspunkt från riskanalyser som denna part genomför. Utgångspunkten ska vara att övriga parter inte ska påverkas genom bristande säkerhet i KSB trafikflöde. 3.6 Kvalitetssäkring av personuppgifter Någon anslutning mot folkbokföringstjänsten Navet tillhandahålls inte i det här läget. Kvalitetssäkrade uppgifter om systemets användare förutsätts komma in genom korrekt manuellt registrerade uppgifter eller automatiskt via respektive parts eventuella användning av IAM-system. Kvalitetssäkring utförs inte för personuppgifter som har sitt ursprung i inkomna handlingar. Där är det handlingens uppgifter som gäller. Däremot rättar vi självklart uppgifter i handlingar som vi själva skapar.

8 8 (33) 3.7 Ingen kryptering i samband med lagring av information Om det är aktuellt att hantera känsliga uppgifter eller uppgifter med sekretess i molnet är det avgörande att man genomför en riskanalys och bedömer om de säkerhetsåtgärder som leverantören erbjuder är tillräckliga för att säkerställa det skydd som krävs. I riskanalysen ska det prövas om det alls är förenligt och lämpligt att använda en molntjänst. Att genomföra en riskanalys räknas som en första organisatorisk säkerhetsåtgärd och ska ombesörjas av den personuppgiftsansvarige. Som en del i analysen ska man bedöma olika organisatoriska och tekniska förutsättningar såsom: Krav på kryptering i alla typer av överföring av data till och från molntjänstleverantören. Utgångspunkten är att det krävs kryptering i överföringen i så gott som samtliga fall numera oavsett om det rör sig om känsliga uppgifter/uppgifter med sekretess eller inte. Krav på krypterad lagring av information. Här styr riskanalysen vad som kan vara lämpligt. Krav på tvåfaktorsmetod för inloggning till molntjänsten. Utgångspunkten är att det krävs en tvåfaktorsmetod för åtkomst. Klassning och riskanalys får visa vilken styrka. Krav på en säker hantering av säkerhetskopior. Krav på att personuppgiftsbiträdet bistår med att tillgodose registrerades rätt till registerutdrag och att få rättelse enligt dataskyddsförordningen. Karlstads kommun har idag ingen tillämpning där vi krypterar i samband med lagring av information, men förmodligen kan kryptering tillhandahållas om det bedöms som nödvändigt. Ett sådant beslut kommer dock att rendera i ett behov av lämpligt tekniskt stöd och nya rutiner för ändamålet. Det är i dagsläget oklart vad det skulle innebära i form av ytterligare resurser/kostnader. Projektets bedömning är att omständigheterna kring Karlstads kommuns roll som tjänsteleverantör är sådana att ingen kryptering av lagrad information behövs. 3.8 Bestämning av tekniska skyddsåtgärder Utgångspunkten är att respektive part bestämmer sina egna skyddsåtgärder. Karlstads kommun är emellertid personuppgiftsbiträde gentemot övriga parter, och Karlstads bedömning är att informationsklassificering med avseende på konfidentialitet hamnar på nivå två (2), vilket innebär någon form av tvåfaktorsmetod för inloggning. Som biträde har vi en skyldighet att inte göra fel gentemot PuA varför det blir nödvändigt att hamna i en riktig teknisk lösning som kan implementeras per tenant i lösningen.

9 9 (33) 3.9 E-underskrift Dokument- och ärendehanteringssystemet förväntas kunna förse handlingar med digitala underskrifter och stämplar i den omfattning som kan behövas. För detta och andra ändamål i koncernen Karlstads kommun övervägs anslutning till en fristående underskriftstjänst enligt E-legitimationsnämndens rekommendationer 3. Det kommande dokument- och ärendehanteringssystemet bör därför kunna anslutas till denna tjänst när det blir så dags. Med e-underskrift menas krypterade uppgifter i elektronisk form som är fogade till eller logiskt knutna till andra uppgifter i elektronisk form, för att säkerställa de senares ursprung och dataintegritet [ ] En fristående underskriftstjänst kan leverera såväl kvalificerade som avancerade e-underskrifter enligt eidasförordningen (EU nr 910/2014) 4. Det förväntas att den part i samverkan som tycker sig ha behov av en underskriftstjänst upphandlar en sådan för anslutning till sin tenant i lösningen

10 10 (33) 3.10 Beroenden till Karlstads IAM-tjänst I nuläget är det inget som helst tryck på att avropa det tjänsteerbjudande som Karlstad tidigare har erbjudit medlemmarna i DSN rörande Identity Management. Möjligen kan detta läge ändras under upphandling och införandeplaneringen av DÄHS. De personella resurserna skulle i så fall behöva ses över inom IAMförvaltningen. Utgångspunkten är att respektive part tillhandahåller sin egen IAM-lösning om det finns behov av den typen av funktionalitet. Anslutning sker mot den egna tenanten utan påverkan på andra tenants. Administration av användare är därmed tänkt att ske med ett av följande två sätt: Manuellt direkt i upphandlat system Automatiskt med egen IAM-lösning Inom ramen för Access Management finns det däremot sedan tidigare en identifieringstjänst, den s.k. regions- IDP:n, som kan användas för autentisering och åtkomstkontroll till olika anslutna e-tjänster. Regions-IDP:n i sin nuvarande form har inga uppgifter om enskilda användare internt hos de samverkande parterna. De metoder för autentisering som är tillgängliga är SITHS med HSA som attributkälla, samt Mobilt Bank-ID.

11 11 (33) 4 Generella krav på beskrivning av systemarkitekturen 5 Tekniska miljöer Oavsett driftsform så skiljer Karlstads kommun noga på de olika tekniska miljöerna. För lite större verksamhetssystem ska i normalfallet följande tekniska miljöer vara tillgängliga: Utvecklingsmiljö Testmiljö (QA) Produktionsmiljö 6 Övergripande systemegenskaper 6.1 Driftsform 6.2 Logisk instansiering (tenants) 6.3 Systemets mognad 6.4 Prestanda

12 12 (33) 7 Applikationsarkitektur 7.1 Verksamhetsrelaterad funktionalitet Basen för detta avsnitt utgörs av den funktionalitet som specificeras av verksamheten och kraven formuleras och dokumenteras av dem i ett separat kravdokument Inbyggd integritet Följande avsnitt tar upp de krav på informationssystem som Karlstads kommun anser ryms inom begreppet inbyggt dataskydd enligt dataskyddsförordningens artikel 25. Genom att konsekvent tillämpa kraven i samband med egenutveckling av informationssystem, systemupphandlingar och systemrevisioner anser kommunen att dataskyddsförordningens principer för inbyggt dataskydd och dataskydd som standard 5 beaktas ur ett tekniskt perspektiv Tillämpningsanvisning checklista Det är lätt att tappa bort sig i detaljer. Innan du börjar titta på de detaljerade kraven kan det vara bra att gå igenom kommunens checklista för inbyggd integritet. Checklistan finns tillsvidare i ett externt dokument Arkivering och gallring av information Arkivering av information regleras av arkivlagen och har egentligen inte med dataskyddförordningen att göra, men eftersom gallring och arkivering hänger ihop, och det finns en direkt koppling mellan gallring och dataskyddsförordningen, så motiverar detta förhållande att kraven tas upp i sammanhanget Arkivering av information Gallring av information 5 GDPR Privacy by Design and Privacy by Default

13 13 (33) Auktorisation, autentisering samt kontroll av användares åtkomst Terminologi Användare 6 Individ eller system som nyttjar informationstillgångar. Ofta avses en individ som direkt interagerar med ett datoriserat system (informationssystem). Här förutsätts som regel att användaren har behörighet att använda informationstillgångarna. Identitet 7 Användare tilldelas en identitet i informationssystemet (mer exakt: en i systemet unik identitetsbeteckning). Identifiering 8 Den process vari en identitet som angivits av en användare eller en resurs verifieras. En användare identifierar sig för systemet genom att ange sin identitet (identitetsbeteckning) vid inloggningen. Därefter verifierar systemet användarens identitet genom att användaren uppmanas att ange något som är unikt för denna användare, eller att utföra något som bara denna användare kan göra. I vissa system krävs ny verifiering efter viss tid eller i samband med att användaren utför särskilt känsliga operationer. Den närliggande termen autentisering relateras ofta mer konkret till ett specifikt, tekniskt verifieringsförfarande, ofta med hjälp av en säkerhetsmekanism med god mekanismstyrka. Autentisering 9 a) Den tekniska process vari äktheten, autenticiteten bekräftas kallas autentisering. Denna kontroll kan avse entiteter såsom användare, processer, systemkomponenter och informationsobjekt. b) Verifiering av ett påstående, exempelvis verifiering av att en användare är den man påstår sig vara. Denna typ av verifiering, utförd av verifierande part, används t.ex. vid inloggning eller vid kommunikation mellan två system eller användare. Lösenord 10 Teckensträng som anges vid behörighetskontroll för att möjliggöra identifiering av användare. Behörighetskontroll 11 Se åtkomstkontroll. 6 SIS-TR 50:2015 (Sv) 7 SIS-TR 50:2015 (Sv) 8 SIS-TR 50:2015 (Sv) 9 SIS-TR 50:2015 (Sv) 10 SIS-TR 50:2015 (Sv) 11 SIS-TR 50:2015 (Sv)

14 14 (33) Åtkomstkontroll 12 a) Åtkomstkontroll syftar till att skydda information och tillhörande resurser så att de endast är tillgängliga för den som registrerats som behörig. Åtkomstkontrollen reglerar också vad en behörig användare kan göra med information och resurser. b) Funktioner i ett system som syftar till att reglera och kontrollera en användares åtkomst till information och resurser. Behörighetskontrollsystem 13 a) Säkerhetsåtgärder som tillsammans reglerar och registrerar användarens aktiviteter. b) BKS omfattar tre grundläggande säkerhetsåtgärder i ett it-system. Dessa ska tillsammans se till att verksamhetens säkerhetsregler (kontinuerligt) följs: 1. verifiering av en användares uppgivna identitet. Jfr identitet samt autentisering 2. reglering av åtkomsträttigheter 3. registrering av användarens aktiviteter i systemet Auktorisation 14 Fastställande av åtkomsträttigheter för en användare. Åtkomsträttighet 15 Användares behörighet till åtkomst. En användares behörighet uttrycks i tilldelade åtkomsträttigheter. Dessa åtkomsträttigheter definierar vilka operationer en användare har rätt att utföra t.ex. läsa, söka, skriva, radera, skapa och exekvera. Åtkomst 16 Interaktion mellan en användare och en resurs som resulterar i överföring av information dem emellan eller utnyttjande av resurser. Termen omfattar all typ av interaktion med ett generellt system, mellan dess användare, information, utrustning, program etc. Även förändring av systemparametrar utgör ett fall av åtkomst. Behörighet 17 Tilldelade rättigheter att använda en informationstillgång på ett specificerat sätt. Rättigheter kan innefatta t.ex. rättigheten för en viss användare att ta del av innehållet i en databas eller att skriva ut på en viss skrivare. 12 SIS-TR 50:2015 (Sv) 13 SIS-TR 50:2015 (Sv) 14 SIS-TR 50:2015 (Sv) 15 SIS-TR 50:2015 (Sv) 16 SIS-TR 50:2015 (Sv) 17 SIS-TR 50:2015 (Sv)

15 15 (33) Informationstillgång 18 Information, och resurser som hanterar den, som är av värde för en organisation. Informationstillgångar kan vara av fysisk eller logisk karaktär, eller bådadera. Exempel på informationstillgångar är: information (kunddatabas, metodik, dokument etc.) program (applikation, operativsystem etc.) tjänster (kommunikationstjänst, abonnemang etc.) fysiska tillgångar (dator, datamedier, lokala nätverk etc.) människor och deras kompetens, färdigheter och erfarenheter immateriella tillgångar (rykte och image etc.) Klientdator 19 Med klientdator avses en enhet av valfri typ som en fysisk person (IT-användare) använder sig av för att ansluta sig till ett eller flera IT-system: Stationär eller bärbar persondator oavsett processorarkitektur eller operativsystem Surfplatta oavsett processorarkitektur eller operativsystem Smart telefon oavsett processorarkitektur eller operativsystem 18 SIS-TR 50:2015 (Sv) 19 Karlstads kommun, IT-avdelningen

16 16 (33) Auktorisation av användare Följande avsnitt tar upp generella krav för hantering av ett systems användare och behörigheter (auktorisation). Specifika krav kan finnas beskrivna i den verksamhetsspecifika kravspecifikationen men ambitionen är att kraven i detta avsnitt ska vara heltäckande och inte behöva närmare beskrivning någon annanstans. Auktorisation av användare utgår från principen om vilken information en individ behöver tillgång till i vissa givna situationer. För att få klarhet i vilka säkerhetsåtgärder som då behövs genomförs en klassning av aktuell information. Klassningen åtföljs av en riskanalys varvid relevanta nivåer av konfidentialitet klarläggs 20. Exempelvis är det är endast vissa behöriga personer som ska komma åt information med sekretess, alla andra ska nekas tillgång Känsliga personuppgifter/uppgifter med sekretess Detta är ett specialfall av avsnittet Auktorisation av användare. Närliggande krav finns även i avsnitt Personer med sekretessmarkering i folkbokföringen Personer med sekretessmarkering i folkbokföringsregistret Detta är ett specialfall av avsnittet Auktorisation av användare. Begreppet sekretessmarkering definieras hos Skatteverket som en av tre skyddsåtgärder inom samlingsbegreppet skyddade personuppgifter eller skyddad identitet som man också kan säga. 20 Se avsnitt x.y.z Informations- och IT-säkerhet.

17 17 (33) Personer med kvarskrivning Begreppet kvarskrivning definieras hos Skatteverket som en av tre skyddsåtgärder inom samlingsbegreppet skyddade personuppgifter eller skyddad identitet som man också kan säga. Skatteverket skriver så här om kvarskrivning 21 : Kvarskrivning fungerar som ett adresskydd när du har flyttat till annan, hemlig adress. I praktiken innebär det att din nya, verkliga bostadsort inte framgår av folkbokföringsregistret och därmed inte heller sprids till andra myndigheter. Din gamla adress tas bort och du registreras som "på kommunen skriven" i din gamla folkbokföringsort. Skattekontorets adress anges som en särskild postadress. En markering om att du har skyddade personuppgifter meddelas ut till andra myndigheter tillsammans med adressen till skattekontoret. Din post går till ett regionalt skattekontor där särskilda handläggare har din nya adress manuellt förvarad och kan vidarebefordra din post. Du kan få kvarskrivning på din gamla folkbokföringsort i högst tre år i taget efter att du har flyttat. Kravet för att få bli kvarskriven är att du av särskilda skäl kan antas bli utsatt för brott, förföljelser eller andra allvarliga trakasserier. Omständigheterna ska i princip motsvara de som gäller för meddelande av kontaktförbud enligt lagen (1988:688) om kontaktförbud. I september 2014 fanns det 2012 personer kvarskrivna i Sverige. En anledning till att det är så pass få, är att det kan vara besvärligt att ta del av samhällsservicen om du är folkbokförd någon annanstans än där du bor. Folkbokföringen har betydelse för exempelvis tillgång till förskoleplats, skolgång eller bostadsbidrag. Dessutom är beskattning och rösträtt knutet till var du är folkbokförd. Formulerade krav för upphandlingen finns i DÄHS kravdokument och täcks in genom att man ska kunna ändra förekommande adressuppgifter i systemet Personer med fingerade personuppgifter Detta avsnitt är inte relevant för DÄHS-upphandlingen. 21 Skatteverket och kvarskrivning

18 18 (33) Autentisering av användare och kontroll av åtkomst Karlstads kommuns referensarkitektur för IAM bygger på Ineras referensarkitektur (bilaga Referensarkitektur-Identitetochatkomst-RevA.pdf ) och ser i sammanfattning ut enligt följande två tabeller: Teknisk förmåga Primära tekniska protokoll Alternativa tekniska protokoll Anslutning av e-tjänst för federerad inloggning, SSO och utloggning. (sign-in protocols) Identitet & egenskaper. Intygstyp (token type) SAML OpenID Connect (OIDC) 23 SAML 2.0 Assertions JSON Identity Suite, JWT WS-Trust, WS-Federation IWA/kerberos 24 (dock enbart för lokal SSO, klass 1 med avseende på konfidentialitet) SAML 1.0 Assertions Delegerad åtkomst OAuth 2.0 (förmågan saknas inom SAML 2.0-sviten) Kerberos Constraint Delegation 25 (endast lokalt, klass 1 med avseende på konfidentialitet) Autentisering 26 (authentication protocols) Användar-id & lösenord e-identitet med stöd för flerfaktorsautentisering på skyddad bärare. Användar-id & lösenord Annan, ev. leverantörsspecifik lösning med motsvarande tillitsnivå, t.ex. en generator för engångslösenord (OTP) Metod baserad på stark asymmetrisk kryptering och utmaning-svar (challenge response). x509 certifikat / client-tls / digital signering PKCS#7 eller motsvarande. Identitetsbärare kompatibel med FIDO UAF/U2F Federation & tillit samt metadatahantering SAML Metadata OpenID Connect Federation 27 WS-Federation Sammanställning av rekommenderade tekniska protokoll per teknisk förmåga (funktion) inom Identitet och Åtkomst Integrated Windows Authentication med Kerberos, även benämnd AD-integrerad inloggning med Kerberos. Nackdel: saknar federativt stöd, ej optimal vid delade klientdatorer Typ av metod bestäms av föregående krav på tillgänglighet vägt mot informationsklassificering och riskanalys 27 Notera att denna är per ht-2016 en draft, varför implementationer bör ta hänsyn till att specifikationen kan komma att förändras i slutlig version.

19 19 (33) Teknisk förmåga Teknikstack för SOAP/XMLbaserad kommunikation Teknikstack för http/rest/jsonbaserad kommunikation Federation & tillit SAML2 Metadata OIDC Federation Federerad inloggning, SSO SAML2 WebSSO OIDC Identitet & egenskaper SAML2 Assertions JSON Identity Suite Delegerad åtkomst Autentisering OAuth2 Användar-id+lösenord, e-id på smart kort, e-id eller OTP (ej SMS) i mobil klientdator. Teknikstackar för kommunikation per teknisk förmåga (funktion) inom Identitet och åtkomst. Följande krav blir aktuella beroende på hur respektive part i upphandlingen klassificerar den information som systemet ska behandla. Karlstad bedöms kunna använda en 1FA-metod 28 vid intern användning. Detta kommer dock aldrig bli fallet för de andra parterna som alltid kommer in via KSB som betraktas som öppet nät. All trafik som passerar över öppet nät måste dels krypteras, dels måste en 2FA-metod användas för inloggning. 28 1FA/2FA refererar till en- respektive tvåfaktorsmetod vid inloggning.

20 20 (33) Kryptering av information Kryptering kan förekomma i två olika sammanhang: Transportkryptering (data i rörelse) Lagringskryptering (data i vila) Transportkryptering (data i rörelse) Lagringskryptering (data i vila) Detta avsnitt är inte relevant för DÄHS-upphandlingen Underskrift och stämpling av elektroniska handlingar Karlstads kommun avser att ansluta till en fristående underskriftstjänst enligt E-legitimationsnämndens rekommendationer. Denna tjänst är tänkt att vara koncernövergripande med möjlighet till anslutning av de system där det förekommer behov av e-underskrifter och/eller e-stämplar. Det kommande dokument- och ärendehanteringssystemet ska därför kunna anslutas till denna tjänst när det blir så dags.

21 21 (33) Känsliga uppgifter/sekretess i molnet Detta avsnitt är inte relevant för DÄHS-upphandlingen Ombud Detta avsnitt är inte relevant för DÄHS-upphandlingen Samtycken Detta avsnitt är inte relevant för DÄHS-upphandlingen Tillgänglighet och kontinuitet Formulerade SLA-krav finns i DÄHS kravdokument inför utskicket till parterna för beslut om deltagande i upphandlingen. Detaljerade tekniska krav kommer formuleras i tid inför upphandlingen Kvalitetssäkring av personuppgifter Detta avsnitt är inte relevant för DÄHS-upphandlingen. Ingen speciell funktionalitet är utpekad för området Uppgiftsminimering Detta avsnitt är inte relevant för DÄHS-upphandlingen. Ingen speciell funktionalitet är utpekad för området.

22 22 (33) Portering av data Detta avsnitt är inte relevant för DÄHS-upphandlingen Pseudonymisering av personuppgifter Detta avsnitt är inte relevant för DÄHS-upphandlingen Loggning av system- och användarrelaterade händelser Information till den registrerade Detta avsnitt är inte relevant för DÄHS-upphandlingen. Ingen speciell funktionalitet är utpekad för området Rättelse av personuppgifter Rätta uppgifter kan vi göra med stöd av förvaltningslagen men vi rättar inte i inkommande allmänna handlingar. Detta avsnitt är inte relevant för DÄHS-upphandlingen. Ingen speciell funktionalitet är utpekad för området Radering av personuppgifter Om en registrerad har rättslig grund för att begära radering av personuppgifter blir kraven för arkivering (bevarande) och gallring tillämpbara.

23 23 (33) Invändning mot behandling Detta avsnitt är inte relevant för DÄHS-upphandlingen. Ingen speciell funktionalitet är utpekad för området Begränsning av behandling Detta avsnitt är inte relevant för DÄHS-upphandlingen. Ingen speciell funktionalitet är utpekad för området Registerutdrag Dataskyddsförordningens artikel 15 reglerar den registrerades rätt till tillgång, d.v.s. att den registrerade ska ha rätt att av den personuppgiftsansvarige få bekräftelse på huruvida personuppgifter som rör honom eller henne håller på att behandlas och i så fall få tillgång till personuppgifterna i sig (artikel 15.3) samt information om själva behandlingen (artikel 15.1 a-h). När det gäller det senare, nämligen uppgifter om den eller de personuppgiftsbehandlingar som berör en registrerad så är det tänkt att kommunen ska föra ett centralt register över samtliga personuppgiftsbehandlingar. Det finns alltså inga explicita krav på respektive informationssystem för denna del. I detta avsnitt redovisas ändå de krav som ställs på det centrala registret så att man på frivillig bas kan implementera kraven i de enskilda systemen om så önskas Krav på enskilda system Krav på det gemensamma registret över personuppgiftsbehandlingar Detta avsnitt är inte relevant för DÄHS-upphandlingen.

24 24 (33) Hjälpfunktioner Avisering Utsökning av information Rapportering

25 25 (33) 7.2 Datastruktur och datainnehåll 7.3 Webbapplikationer 7.4 Microsoft Windows-baserade (native) applikationer 7.5 Apple ios-baserade (native) applikationer 7.6 Google Android-baserade (native) applikationer 7.7 Beroenden till tredjepartsapplikationer

26 26 (33) 7.8 Systemintegration och kommunikationsmönster Logiska systemsamband, bruttolista över integrationer I detta avsnitt görs antaganden om de systemsamband som kan bli aktuella i en kommande implementation. Följande skiss gäller för respektive part (tenant) i den tilltänkta lösningen. Resultatet blir en bruttolista över integrationsbehovet då man på förhand inte med säkerhet kan avgöra utfallet av upphandlingen och de olika parternas val. Antagna systemsamband per part (tenant) i den tilltänkta lösningen.

27 27 (33) Troligt förekommande integrationsbehov E-tjänstplattform med stor sannolikhet den inom DSN redan etablerade plattformen. I införandefasen när respektive parts data i tidigare dokument- och ärendehanteringssystemet migreras till det nya. System för publicering av handlingar för publik målgrupp. Målsystem är digital anslagstavla, "författningssamling" (respektive parts webbsida?) System för publicering av digitala möteshandlingar för begränsad målgrupp såsom deltagare i nämndmöten. E-postsystem/kontorsprogram. I denna upphandling endast Microsoft Office 365 med bakåtkompatibilitet för lokalt installerade Microsoft Office-produkter. Internt system eller extern tjänst för arkivering av ärenden med dess handlingar. Extern tjänst för e-underskrift. IAM-system för provisionering av elektroniska identiteter och behörigheter. Rör ett begränsat antal parter. IAM-system för åtkomstkontroll (lokal eller regional IDP). Rör ett begränsat antal parter. Extern tjänst för SMS-tjänst för avisering av användare. Gäller om denna kanal befinns användbar. Här bör Karlstad stå för integrationen och sedan debitera övriga? Mindre troligt förekommande integrationsbehov Krav på tekniska gränssnitt (API) Detaljerade tekniska krav kommer formuleras i tid inför upphandlingen

28 28 (33) Kommunikationstopologier Eventuella systemintegrationer kommer att ske över KSB, utom i de fall externa tjänster blir aktuella, exempelvis i fallet NetPublicator där Karlstad kommunicerar över Internet via en VPN-tunnel Åtkomst till dokument- och ärendehanteringssystemet utan VPN

29 Åtkomst till ärende- och dokumenthanteringssystemet med VPN 29 (33)

30 30 (33) Publicering av dokument till publiceringstjänst

31 Åtkomst av dokument till publiceringstjänst för digitala möteshandlingar 31 (33)

32 32 (33) 8 Infrastrukturarkitektur Klient Klientdatorer av typen stationära (desktops) och bärbara (laptops) Detta avsnitt är inte relevant för DÄHS-upphandlingen. Vi har inga specifika krav på typ av klientdator i förhållande till användarmålgrupp. Fokus ligger på operativsystemet och vi använder de klientdatortyper som leverantören rekommenderar för sitt system Klientdatorer av typen surfplattor Detta avsnitt är inte relevant för DÄHS-upphandlingen. Vi har inga specifika krav på typ av klientdator i förhållande till användarmålgrupp. Fokus ligger på operativsystemet och vi använder de klientdatortyper som leverantören rekommenderar för sitt system Klientdatorer av typen smarta telefoner Detta avsnitt är inte relevant för DÄHS-upphandlingen. Vi har inga specifika krav på typ av klientdator i förhållande till användarmålgrupp. Fokus ligger på operativsystemet och vi använder de klientdatortyper som leverantören rekommenderar för sitt system.

33 33 (33) Server Detaljerade tekniska krav kommer formuleras i tid inför upphandlingen Nätverk Standarder för kommunikation Detaljerade tekniska krav kommer formuleras i tid inför upphandlingen VPN Detaljerade tekniska krav kommer formuleras i tid inför upphandlingen.