Checklista för tekniskt ansvarig

Transkript

1 Checklista för tekniskt ansvarig E-identitet för offentlig sektor Sid 1/14

2 Revisionshistorik Version Datum Författare Kommentar Första utkastet Uppdaterade antalet målgrupper Adderat på antalet målgrupper och börjat beskriva vad varje målgrupp behöver göra Uppdaterat beskrivning på målgrupper Uppdaterat beskrivning på målgrupper. Lagt till en ny punkt på den fulla tekniska checklistan: Integration mot Net Id Access Server Ronny Nilsson Kommentarer inlagda där det behövs förbättringar och förslag på förbättringar Uppdaterat dokumentet med Ronny föreslog som förbättringar och ändringar Efos förkortning har blivit ändrad till Efos istället Ändrat på alla länkar enligt direktiv från Maria Brunzell. 10 Ändrat namnet på dokumentet samt uppdaterat innehållet för att spegla det nya namnet. Sid 2/14

3 Innehållsförteckning 1. Introduktion Syfte Bakgrunden Målgrupper Referenser Terminologi Planeringskalender för tekniskt ansvariga Du har en e-tjänst som använder Säkerhetstjänsten för inloggning Du som enbart användare som skall använda Efos-kort Du har en tjänst som har gjort direktintegration med Net ID Du har tjänst som vill att era användare ska kunna använda Chrome, Firefox eller Edge Du har en tjänst som skapar underskrifter Du har en tjänst som enbart använder sig av ett webbservercertifikat Du har en tjänst som använder sig av ett funktionscertifikat Du har en inloggningstjänst av typen SAML Tekniska checklistan Sid 3/14

4 1. Introduktion 1.1 Syfte Detta är en sammanfattande information och checklista över vad införandet av E-identitet för offentlig sektor, Efos, innebär. OBS! Listan är ett levande dokument som kommer uppdateras kontinuerligt. Dokumentet är uppdelat i dessa kapitel: 1. Introduktion detta kapitel inklusive bakgrunden 2. Planeringskalender för tekniskt ansvariga 3. Tekniska checklistan 1.2 Bakgrunden Detta dokument ingår i dokumentationen för migration från SITHS-kort till Efos-kort. 1.3 Målgrupper De huvudsakliga målgrupperna för dokumentet är: Systemägare Systemförvaltare Systemarkitekter Förvaltningstekniker Utvecklare 1.4 Referenser I följande avsnitt anges länkar till ytterligare relevant dokumentation och en sammanställning av samtliga referenser som har förekommit i dokumentet. Ref Dokument-id Länk R1 R2 referensarkitektur_identitet_oc h_atkomst.pdf Inera - Cert migrering POC rapport v2.pdf Projektplatsen för projektet. e-identitet för offentlig sektor i katalogen Migrering/CA Migrering Sid 4/14

5 R3 R4 1.5 Terminologi Begrepp Certifikat Definition Ett elektroniskt, av CA-systemet, signerat intyg av en publik nyckels tillhörighet till en specifik nyckelinnehavare. Efos Identifiering Kryptering NetID PKI System Architecture Document (SAD) SAMLidentitetsintyg Secure Sockets Layer (SSL) Process vari en användare eller resurs anger sin identitet. Omvandling av klartext till kryptotext med hjälp av ett krypteringssystem och aktuell kryptonyckel i syfte att förhindra obehörig åtkomst av konfidentiell information. Klient som krävs vid användning av SITHS-kort. Public Key Infrastructure, Formell beskrivning av ett IT-systems arkitektur. SAML 2.0 är en öppen XML-baserad standard för utbyte av data vid autentisering och auktorisation. En användare kan med SAML 2.0 loggas in till ett system med en identitet som inte har någon anknytning till systemet. Genom SAML 2.0 uppnås så kallad federerad inloggning. SAML-identitetsintyget är den information som användaren tar med sig när denne loggar in eller förflyttar sig mellan två system. Protokoll som används för att kryptera kommunikation mellan två enheter för att försvåra avlyssning eller manipulation av informationen. SITHS Sid 5/14

6 2. Planeringskalender för tekniskt ansvariga Punkterna nedan riktar sig till främst till tekniskt ansvariga personer för SITHS och Efos inom organisationen. Det finns några förenklande situationer när den fulla tekniska checklistan inte behöver användas. Passa inte dessa fall in, behöver ni gå igenom hela den tekniska checklistan och se vad som ni behöver göras. Det är inte säkert att alla punkter behöver göras utan det behöver kontrollera och testas för att se vad som behövs. De förenklande situationerna som begränsar vad ni behöver göra är dessa: Du har en e-tjänst som använder Säkerhetstjänsten för inloggning Du har en inloggningstjänst av typen SAML Du har enbart användare och klienter som skall använda Efos-kort och ingenting annat Du har en tjänst som enbart använder sig av ett SITHS funktionscertifikat Du har en tjänst som har gjort direktintegration med Net ID Du har tjänst som vill att era användare ska kunna använda Chrome, Firefox eller Edge Du har en tjänst som skapar underskrifter Du har en tjänst som enbart använder sig av ett webbservercertifikat Du har en tjänst som använder sig av ett funktionscertifikat 2.1 Du har en e-tjänst som använder Säkerhetstjänsten för inloggning Har du tjänster som enbart använder befintliga Säkerhetstjänsten för inloggning kommer du inte behöva göra någonting. Det beror på att all Efos hantering sker hos säkerhetstjänsten och det man får tillbaka från Säkerhetstjänsten är SAML identitetsintyg som är underskriver av ett SITHS funktionscertifikat, samt att kommunikationen mellan e-tjänsten och Säkerhetstjänsten är redan specificerad sedan tidigare och använder SITHS funktionscertifikat. Test kan göras omedelbart. Men du bör göra en test för att säkerställa att det är korrekt. Test görs i Säkerhetstjänstens acctest miljö. Det enda man behöver är ett Efos-testkort som kan beställas från Inera. Kommentar: Sid 6/14

7 Andra inloggningstjänster än Säkerhetstjänstens kan fungera annorlunda, och behöver kontrolleras med den specifika inloggningstjänsten exakt hur denna har hanterar Efos. 2.2 Du som enbart användare som skall använda Efos-kort Du ansvarar för en rad av användare och deras klient miljö. Du använder Internet Explorer som webbläsare och behöver även hantera Efos-kort. Du behöver även ta hänsyn till den information som de e-tjänster skickar ut och som användarna avvänder. Följande aktiviteter i den full tekniska checklistan behöver säkerställas: Öppna brandväggar för spärrkontroll Inställningar för webbläsaren IE11 ActiveX filtrering Inställningar för webbläsaren IE11 Trusted Sites/Betrodda platser Installera nya versioner av applikationen Net id (Enterprise) Installera nya versioner av applikationen Net id Access Client Så snart som möjligt. Glöm inte att Net Id behöver finnas på alla klienter innan lanseringsdatumet. Behöver säkerställa att rätt Net Id klient finns installerad. Det finns två olika klientprogramvaror som behöver installeras, Net Id Enterprise klienten samt NetId Access klienten. Båda behövs för att få fullt stöd för alla nya funktioner och för Efos-kortet. Ni som användare eklient behöver kontrollera era GPO och kanske uppdatera dessa för stödja Efos-korten. Det kan komma behövas installeras nya CA certifikat för Efos, detta behöver stämmas av. Brandväggarna behöver släppa igen hämtning av spärrinformation för Efos-korten. Kontrollera även att inställningarna i Internet Explorer hanterar att man kan använda pluginer för Net Id klienten samt att betrodda platser är konfigurerade i Net Id klienten. 2.3 Du har en tjänst som har gjort direktintegration med Net ID Detta gäller en tjänst som använder funktioner direkt mot Net ID och sköter exempelvis inloggningen. Det finns flera sätt hur denna integration fungerar, ex att använda HSA-id mot ett eget lokalt behörighetsregister eller med ett medarbetaruppdrag i HSA-katalogen. Använder man sig av innehållet i certifikatet förutom namn och HSA-id behöver man kontrollera skillnaden mellan SITHS och Efos certifikat specifikationer. Följande aktiviteter i den full tekniska checklistan behöver säkerställas: Installera tillit till de nya rot-certifikaten för Efos Kontrollera om tjänsten kan hantera Efos certifikatsinnehåll och -egenskaper. Sid 7/14

8 Öppna brandväggar för spärrkontroll Innan produktionsstart för Efos. Vid direktintegration behöver man hantera certifikatet som man loggar in med. Efos-korten ser lite annorlunda ut. De har en annan CA struktur och de nya CA certifikaten behöver installeras för att valideringen skall fungera. Brandväggar för att hämta certifikatstatus behöver öppnas. 2.4 Du har tjänst som vill att era användare ska kunna använda Chrome, Firefox eller Edge För er som vill använda Efos-korten för att kunna använda någon annan Webbläsare än Internet Explorer. Observera SITHS-korten kommer enbart kunna använda Internet Explorer. Följande aktiviteter i den full tekniska checklistan behöver säkerställas: Installera tillit till de nya rot-certifikaten för Efos Stöd för kommunikation till Net id Access Server Kontrollera om tjänsten kan hantera Efos certifikatsinnehåll och -egenskaper. Öppna brandväggar för spärrkontroll Innan produktionsstart för Efos. För att kunna acceptera Efos-kortsinloggning behöver man antingen använda sig av en TLS skyddad webbsida. Observera att det måste vara dubbelriktad TLS skyddad sida. Webbservern som hanterar TLS behöver ha de nya rot-certifikaten installerade samt öppna brandväggar för spärrkontroll. Eller så behöver man använda det nya webbservice protokollet mot Net id Access Servern(NiAS). Denna nya server NiAS använder samma typ av protokoll som Bank Id, för att kommunicera med kortet. Se separat dokument för hur man programmerar mot NiAS (Ref?). Förutom en de två olika metoderna ovan behöver man installera stöd för rot-certifikaten i tjänsten, samt se om behöver ta hänsyn till certifikatet för Efos-korten. Observera att brandväggar behöver öppnas för att kunna genomföra spårkontroller. Sid 8/14

9 2.5 Du har en tjänst som skapar underskrifter För er som vill använda Efos-korten för att skapa underskrifter och inte vill använda IE11 och pluginer måste använda skapa stöd för den nya Net Id Access Server Följande aktiviteter i den full tekniska checklistan behöver säkerställas: Installera tillit till de nya rot-certifikaten för Efos Stöd för kommunikation till Net id Access Server Kontrollera om tjänsten kan hantera Efos certifikatsinnehåll och -egenskaper. Öppna brandväggar för spärrkontroll Innan produktionsstart för Efos. Underskriften måste skapas via det nya webbservice protokollet mot Net id Access Servern(NiAS). Denna nya server NiAS använder samma typ av protokoll som Bank Id, för att kommunicera med kortet. Se separat dokument för hur man programmerar mot NiAS. Förutom detta behöver man installera stöd för rot-certifikaten i tjänsten, samt se om behöver ta hänsyn till certifikatet för Efos-korten. Observera att brandväggar behöver öppnas. 2.6 Du har en tjänst som enbart använder sig av ett webbservercertifikat För er som behöver byte till ett Efos funktionscertifikat, eller vill byta till ett nytt certifikat behöver man byta till ett Efos-funktionscertifikat. Följande aktiviteter i den full tekniska checklistan behöver säkerställas: Installera tillit till de nya rot-certifikaten för Efos Kontrollera om tjänsten kan hantera Efos certifikatsinnehåll och -egenskaper. Öppna brandväggar för spärrkontroll OBS. Rekommendationen är att använda SITHS funktionscertifikat så länge som möjligt. Vid behov Förutom att installera det nya funktionscertifikatet behöver man installera behöver man installera stöd för rot-certifikaten i tjänsten, samt se om behöver ta hänsyn till certifikatet innehållet för Efos-korten. Observera att brandväggar behöver öppnas. Sid 9/14

10 2.7 Du har en tjänst som använder sig av ett funktionscertifikat För er som behöver byte till ett Efos funktionscertifikat, eller vill byta till ett nytt certifikat behöver man byta till ett Efos-funktionscertifikat. Detta gäller tjänster som skall använda det för att kommunicera mot andra tjänster, som annars kallad system till system kommunikation eller kommunicera mot tjänsteplattformen. Följande aktiviteter i den full tekniska checklistan behöver säkerställas: Installera tillit till de nya rot-certifikaten för Efos Kontrollera om tjänsten kan hantera Efos certifikatsinnehåll och -egenskaper. Öppna brandväggar för spärrkontroll OBS. Rekommendationen är att använda SITHS funktionscertifikat så länge som möjligt. Vid behov Förutom att installera det nya funktionscertifikatet behöver man installera behöver man installera stöd för rot-certifikaten i tjänsten, samt se om behöver ta hänsyn till certifikatet innehållet för Efos-korten. Observera att brandväggar behöver öppnas. 2.8 Du har en inloggningstjänst av typen SAML Detta gäller alla som har en inloggningstjänst för andra applikationer. Följande aktiviteter i den full tekniska checklistan behöver säkerställas: Installera tillit till de nya rot-certifikaten för Efos Stöd för kommunikation till Net id Access Server Kontrollera om tjänsten kan hantera Efos certifikatsinnehåll och -egenskaper. Öppna brandväggar för spärrkontroll Innan produktionsstart för Efos. För att kunna använda Efos-kort behöver man antingen använda sig av en TLS skyddad webbsida. Observera att det måste vara dubbelriktad TLS. Eller så behöver man använda det nya webbservice protokollet mot Net id Access Servern(NiAS). Denna nya server NiAS använder samma typ av protokoll som Bank Id, för att kommunicera med kortet. Se separat dokument för hur man programmerar mot NiAS. Sid 10/14

11 Förutom en de två olika metoderna ovan behöver man installera stöd för rot-certifikaten i tjänsten, samt se om behöver ta hänsyn till certifikatet för Efos-korten. Observera att brandväggar behöver öppnas. 3. Tekniska checklistan Punkterna nedan är sådant som ni måste göra för att få utbytet till Efos-certifikat att fungera. Varje punkt i listan behöver kontrolleras om denna är relevant och behöver göras. Installera tillit till de nya rot-certifikaten Efos kommer att utfärda certifikat från en ny PKI-struktur. Läs mer på sidan /e-identitet_for_offentlig_sektor under rubriken "Nyheter och skillnader mellan Efos och SITHS". Kontrollera om tjänsten kan hantera Efos certifikatsinnehåll och -egenskaper. Läs mer på sidan /e-identitet_for_offentlig_sektor under rubriken "Nyheter och skillnader mellan Efos och SITHS". Säkerställ att ni har SITHS funktionscertifikat som är giltiga minst 6 månader efter införandet av Efos. Detta för att ni ska hinna säkerställa att alla tjänster ni kommunicerar med är förberedda på Efos Öppna brandväggar för spärrkontroll Öppna brandväggar för SITHS CRL och OCSP då de flyttas från Telia till Försäkringskassan Öppna brandväggar för de nya motsvarigheterna inom Efos Dokumentet med information om detta finns på inera.se och är nu komplett. Läs mer på sidan /e-identitet_for_offentlig_sektor under rubriken "Införandeguide för tekniskt ansvariga" Stöd för kommunikation till Net id Access Server Denna instruktion är inte klar vid detta tillfälle. Kommer senare. Installera nya versioner av applikationen Net id (Enterprise) Läs mer på sidan /e-identitet_for_offentlig_sektor under rubriken "Införandeguide för tekniskt ansvariga" Finns nu för nedladdning på Net id Enterprise är den äldre funktionaliteten och behövs för all befintlig autentisering. För id-administratörer krävs den senaste versionen. Sid 11/14

12 För alla övriga användare rekommenderas också senaste versionen. Dock krävs minst Net id Enterprise oavsett paketering för att läsa de nya kortprofilerna. Installera nya versioner av applikationen Net id Access Client - när applikationen finns tillgänglig. Läs mer på sidan /eidentitet_for_offentlig_sektor under rubriken "Införandeguide för tekniskt ansvariga" Net id Access Client krävs för all nyutvecklad autentisering som börjar introduceras nu. Den möjliggör en mer plattformsoberoende underskrift och mobilt Efos. För id-administratörer krävs den senaste versionen. Vi rekommenderar användning av samma version av Net id Access inom hela organisationen. Notera att vissa versioner av Net id Enterprise är sampaketerad med Net id Access, vilket kan orsaka förvirring för användarna. Kontrollera era integrationer för SITHS-kort Efos innebär nya kontaktchip och kortprofiler, läs mer på sidan /eidentitet_for_offentlig_sektor under rubriken "Nyheter och skillnader mellan Efos och SITHS" Om ni integrerat via operativsystemet och Net id Enterprise för att kunna använda SITHS-kort som inloggning i en tjänst behöver era användares datorer förses med en ny version av Net id Enterprise för att Efos-korten ska fungera. Läs mer på sidan /e-identitet_for_offentlig_sektor under rubriken "Införandeguide för tekniskt ansvariga" Om ni integrerat direkt mot SITHS-korten, alltså utan att använda Net id, kommer dessa integrationer sannolikt inte fungera för Efos-korten. Inställningar för webbläsaren IE11 ActiveX filtrering I eklient är ActiveX filtrering påslaget i standard GPO:erna Gäller för id-administratörer som ska använda portalen och användare som ska logga in i selfservice måste ActiveX plugins tillåtas för domänen *.efos.se. (Detta problem kan redan ha påträffats för användare av SITHS Admin) Detta kan antingen göras genom att en användare som är administratör på sin dator trycker på den blåa ikonen som syns i bilden nedan och tillåter att pluginen körs Exempel: Så här ser det ut när pluginen inte tillåts Eller genom att domännamnet efos.se läggs till som ett hexadecimalt 32-bitars värde (DWORD) som är konfigurerat till 1 i registernyckeln [HKCU\Software\Microsoft\Internet Explorer\Safety\ActiveXFilterExceptions] Inställningar för webbläsaren IE11 Trusted Sites/Betrodda platser Säkerställ att *.efos.se läggs till i zonen Betrodda platser i Internet Explorer 11 Sid 12/14

13 Gäller för id-administratörer som ska använda portalen och användare som ska logga in i selfservice Lokala tester. Läs mer på sidan /e-identitet_for_offentlig_sektor under rubriken "Införandeguide för tekniskt ansvariga" Innehållet i certifikatet är i princip samma, Mifare innehållet är samma Det som kan testas är att ni i den miljö där ni testar är: - Att ni har installerat tillit till Efos SAT CA, - Att ni har öppnat brandväggar för åtkomst till CRL och OCSP för Efos SAT CA - Hur er tjänst beter sig när det finns flera utfärdare under samma rot (både personnummer och HSA-id). - Att er tjänst är redo att hantera både tillitsnivå 2 och 3 i testmiljön. Båda tillitsnivåerna kommer användas direkt vid lanseringen av Efos. Därför är minsta antalet testkort vid beställning 2 kort, ett för respektive nivå. - Att er tjänst stödjer SHA-256 i hela certifikatskedjan, framförallt för inloggning av personer då det tidigare varit SHA-1 Enstaka testkort med testcertifikat för testanvändare med angivet HSA-id från er egen gren i HSA integrationsmiljö (det som förr hette HSA Test2) kommer att kunna beställas från inera.se via formuläret på sidan /eidentitet_for_offentlig_sektor under rubriken "Införandeguide för tekniskt ansvariga" Enstaka testfunktionscertifikat för funktion med angivet HSA-id från er egen gren i HSA integrationsmiljö (det som förr hette HSA Test2) kommer att kunna beställas från inera.se via sidan /e-identitet_for_offentlig_sektor under rubriken "Införandeguide för tekniskt ansvariga" Information om kort och certifikat som skapas inför lanseringen av Efos kommer inte automatiskt att publiceras till HSA integrationsmiljö. Din egen organisation kan därför behöva göra en manuell handpåläggning för tester av egna tjänster och system som är beroende av att denna information skrivs till HSA SITHS Preprod kommer att stängas vid lanseringen av Efos och en ersättare kommer först när Efos är i stabil drift. Att göra senare Byt till Efos-funktionscertifikat i god tid innan motsvarande SITHSfunktionscertifikat blir ogiltigt För att kunna byta tillbaka till SITHS-funktionscertifikatet om några problem skulle uppstå Valfritt att göra Läs mer på sidan /e-identitet_for_offentlig_sektor under rubriken "Nyheter och skillnader mellan Efos och SITHS" om ni funderar på om ni ska införa stöd för säkrare inpasseringsteknik: Den nya tekniken heter MIFARE DESFire EV2 och kommer levereras som separata korttyper. Dessa kommer vara beställningsbara först en tid efter lanseringen av Efos Observera att införande av detta kommer att kräva ett införandeprojekt för varje organisation för att säkerställa kompatibilitet i den egna miljön. Sid 13/14

14 Det finns inga planer på att i närtid införa kort med både MIFARE CLASSIC och MIFARE DESFire på samma kort. Detta eftersom dessa kombinationer har visat sig medföra en rad olika kvalitetsproblem Korten kommer inte heller att stödja Dual Interface av samma anledning som ovan, samt att tiden för att läsa kortet är längre och att läsarnas placering ofta är ologisk, vilket i sin tur kräver USB-läsare Sid 14/14