SITHS på egna och andra organisationers kort. Hur SITHS kort-information uppdateras i HSA

Transkript

1 SITHS på egna och andra organisationers kort Hur SITHS kort-information uppdateras i HSA

2 Innehållsförteckning 1. Certifikat och kortadministration HSA och SITHS SITHS en förtroendemodell Tekniska beroenden Information på Magnetremsa och hur påverkas SITHS? Information på RFID-chip Certifikat till befintligt kort Certifikat till reservkort Certifikat till nytt kort En eller flera förekomster i HSA Läs- och skrivrättigheter av SITHS Admin till HSA Vad som uppdateras (skrivs) till HSA Avregistrering av Kort Spärr av certifikat Avregistrering av kort Misslyckad publicering... 7 Revisionshistorik Version Författare Kommentar 1.0 Thomas Näsberg Upprättande och fastställande av dokument 1.2 Thomas Näsberg Uppdatering av dokument, Katrine Streng Uppdaterat till senaste dokumentmall, Sid 1/9

3 1. Certifikat och kortadministration HSA och SITHS Detta dokument, som är en fristående bilaga till SITHS anpassning av IT system, beskriver de operationer som SITHS CA, dvs SITHS Admin, läser och skriver till HSA när kort och certifikat (oavsett egna eller andra organisationers kort) administreras vid såväl beställning som avregistrering/spärr. 1.1 SITHS en förtroendemodell SITHS är en modell som bygger på förtroenden. Ett förtroende avseende att kort och certifikat utfärdas, hanteras och avregistreras i enlighet med gällande regler (SITHS RA-policy och SITHS CA-policy). Alla medlemmar i SITHS ska känna till reglerna och kan därefter besluta om identifiering eller signering med ett SITHS-certifikat är lämpligt för dem. Det viktigaste är att SITHS som förlitande part ansvarar för att det aktuella SITHS-certifikatet är utgivet på ett fastställt och överenskommet sätt. Om nedladdning av certifikat på annan korttyp än de idag använda inom SITHS inte uppfyller detta, motverkas syftet med SITHS och riskerar på sikt att rasera förtroende modellen. SITHS certifikat, ibland benämnt som HCC, identifierar personal som dagligen hanterar mycket integritetskänslig information om t.ex. vårdtagare. Med denna identifiering som grund ges behörigheter att läsa och ändra sådan information. Därför är det viktigt att utgivning av certifikat sker enligt fastställda rutiner och att samma regler gäller för alla parter, oavsett om de direkt hanterar vårdinformation eller ej. Detta bör gälla även för SITHS certifikat på kort utgivna av andra parter än SITHS-medlemmar, t ex kort med Telia e-legitimation eller andra av Nämnden för E-legitimation godkända e-legitimationer. SITHS-modellen lägger i sig inga hinder i vägen för att ge ut SITHS certifikat till andra kort (snarare tvärtom!). Det är förtroendet för den andra partnern som är avgörande. Aktuellt primärcertifikat måste alltid godkännas av SITHS, något som är en relativt omfattande procedur. I och med att SITHS sprider sig, både inom Sveriges landsting och till kommuner, privata vårdgivare och andra intressenter, uppkommer frågan om att tillåta att SITHS certifikat laddas ned på andra korttyper. På det viset kan andra kortinfrastrukturer användas som bärare till SITHS-certifikat. Vissa utfärdare av e-legitimationer, t ex Swedbank eller Handelsbanken, kräver att förlitande part har ett avtal med utgivaren för att få verifiera äktheten av e-legitimationen. Detta kan hindra att SITHS kan ge ut certifikat grundat på dessa e-legitimationer. Sid 2/9

4 1.2 Tekniska beroenden Kommunikationen med kortets chip på en klientdator hanteras av aktuell CSP 1, dvs. mjukvara på klientdatorn (SITHS erbjuder via ett generellt avtal programvaran Net ID). Att ur ett tekniskt perspektiv lägga på ett certifikat på ett visst kortchip hanteras via aktuell CSP. Många CSP hanterar många olika typer av kortchip, men inte alla chiptyper. I värsta fall kan det hända att en persons kort inte fungerar på en dator inom en annan organisation, beroende på vilken CSP som används där. Net ID är t ex programmet för att möjliggöra SSO, vilket Nexus Personal inte tar hänsyn till. Det är dock viktigt att kortets chip kan hantera både signerings- och autentiseringsnycklar för att SITHS modell ska rymmas i det Information på Magnetremsa och hur påverkas SITHS? Normalt finns tre spår på en magnetremsa. Läsare av magnetremsa läser ofta ett visst spår, vilket tvingar korttillverkare att använda just det spåret. Enligt den med SITHS överenskomna standarden (HiCo magnetband med 3 spår - ISO standard ) för dessa kort kodas kortets serienummer med dess 16 sista siffror på magnetbandets spår 2. Organisationen kan själva fritt koda om spår 2 (eller 1 och 3). Om kortet inte är utgivet inom SITHS utgivningsprocess kan informationen på magnetremsan inte styras. Magnetremsor kan normalt kodas om, men om detta är lämpligt eller ej kan bara avgöras i det enskilda fallet och av den egna organisationen. Kortets magnetlagrade information kanske används i någon annan tillämpning. Vid omkodning av magnetremsa försvinner den information som fanns där innan Information på RFID-chip Det krävs en speciell administratörsnyckel för att koda ett korts RFID-chip enligt Mifarespecifikationen, dvs sektorerna 0, 14 och 15. Sektor 0 läses med de öppna nycklarna a0a1a2a3a4a5, se Instruktion överlämning av Mifare A-nyckel. SITHS korten använder sig av en Mifare Classic standard, Mifare RF Interface (ISO A). Antingen kan mifareserienumret i mifareslingan (sektor 0) användas för kontaktlös inpassering, eller så kan man använda sektorläsning. Sektor 14 kodas med de 16 sista tecknen i kortserienumret och sektor 15 kodas med HSA-id (om kortet har ett HCC). Tanken är att HSA-ID och/eller kortets serienummer exporteras till användarens HSA katalog (precis som certifikatet). En export därifrån till organisationens logistik/intelligens för inpasseringssystemen kan sedan genomföras. Kortläsarna skall då kunna känna igen det som presenteras från Mifaresignalen, dvs. HSA-id eller Kortets serienummer. För mer information om sektorkodning hänvisas till specifikationen av Mifare som är framtagen av Inera, se Mifare Specifikation HCC v CSP = Cryptographic Service Provider, t ex Net ID eller Nexus Personal. Sid 3/9

5 1.3 Certifikat till befintligt kort Certifikat kan administreras (laddas ned eller spärras) under tre förutsättningar: till Befintliga kort (koppling mellan certifikat och kort sker till personens personnummer eller samordningsnummer på kortets primärcertifikat), Reservkort (koppling mellan certifikat och kort sker till kortets serienummer på kortets primärcertifikat) eller Nya kort (koppling mellan certifikat och kort sker till personens personnummer eller samordningsnummer på kortets primärcertifikat under korttillverkarens tillverkningsprocess). Ett befintligt kort är i normalfallet ett SITHS kort, men kan även vara av annan typ, t ex Skatteverkets ny id kort. Kraven är att det finns en betrodd utgivare, som Telia e-legitimation (HW CA v1/telia EU HW CA), e-legitimation för samordningsnummer (EnterpriseCA) och reservkortens transportcertifikat (Telia Card Identifier CA v1) för utgivning av certifikat i SITHS CA eller annan part enligt Nämnden för e-legitimation. De uppgifter (attribut) som lagras i verksamhetens HSA katalog för ett kort är: cardnumber hsamifareserialnumber De uppgifter (attribut) som lagras i verksamhetens HSA katalog för ett certifikat är: serialnumber usercertificate validnotafter validnotbefore Om kort- och certifikatinformation finns sedan tidigare i verksamhetens HSA katalog, så kompletteras detta med nya poster ( attribut ). Inga data riskerar att skrivas över. Om överföringen av certifikat till kortet misslyckas, så uppdateras inte verksamhetens HSA katalog, se avsnitt Misslyckad publicering. 1.4 Certifikat till reservkort När certifikat överförts till kortet, så uppdateras verksamhetens HSA katalog med: cardnumber hsamifareserialnumber serialnumber usercertificate Sid 4/9

6 validnotafter validnotbefore Om kort- och certifikatinformation finns sedan tidigare i verksamhetens HSA katalog, så kompletteras detta med nya poster ( attribut ). Inga data riskerar att skrivas över. Om överföringen av certifikat till kortet misslyckas, så uppdateras inte verksamhetens HSA katalog, se avsnitt Misslyckad publicering. 1.5 Certifikat till nytt kort När certifikat och kort skapats, så uppdateras verksamhetens HSA katalog uppdateras med: cardnumber hsamifareserialnumber serialnumber usercertificate validnotafter validnotbefore Uppdatering sker i samband med att kunddatafil levereras från kortleverantören (Gemalto). Detta sker vanligtvis kl. 02 varje vardag. Om kort- och certifikatinformation finns sedan tidigare i verksamhetens HSA katalog, så kompletteras detta med nya poster ( attribut ). Inga data riskerar att skrivas över. Om uppdatering misslyckas aktiveras funktionen Misslyckad publicering. 1.6 En eller flera förekomster i HSA En medarbetare (eller objekt som en webbserver eller funktionscertifikat) är lagrad på minst ett ställe i verksamhetens katalog. Medarbetaren kan även finnas kopierad på fler ställen om han/hon har fler anställningar eller uppdrag hos en organisation, t ex deltidstjänstgöring inom primärvården och deltidstjänstgöring inom slutenvården. Om person finns på flera ställen försöker SITHS CA, dvs SITHS Admin att kopiera kort och certifikatinformation till samtliga poster med samma HSA ID som kan lokaliseras under verksamhetens o -nivå. Om verksamheten däremot har detaljerat certifikatets innehåll av ou-nivåer i verksamhetens konfigurationsparametrar, så begränsas SITHS CA:s möjligheter att publicera respektive radera information. Se även SITHS RA Utbildning. Dubbelkopior av data lagras aldrig i verksamhetens HSA katalog, om t ex validnotbefore redan finns, så lagras det inte igen. Det finns inget i verksamhetens HSA katalog som visar vilka certifikat som finns på vilket kort. Denna information kan dock utläsas från kortet. Det finns inget i verksamhetens HSA katalog som visar vilka attribut som hör till vilket certifikat. Denna information kan dock utläsas ur attributet usercertificate. Sid 5/9

7 2. Läs- och skrivrättigheter av SITHS Admin till HSA 2.1 Vad som uppdateras (skrivs) till HSA SITHS Admin kopplar ihop en kortbeställning med utfärdandet av underlag för certifikat. När kortet tillverkas hämtas underlaget för certifikat och används för att tillverka ett certifikat i samma process. Alla uppgifter om kortets serienummer, certifikatets serienummer, administratör som utfärdade kortet m.m. sparas i SITHS Admin. Ges ett nytt certifikat ut kopplas även detta till kortet. Om aktuellt kort inte är ett kort som beställts och tillverkats i SITHS-systemet kommer inte SITHS Admin kunna hantera uppgifter kring kort och e-legitimation. Information på magnetremsa och RFID-chip kan heller inte administreras. 2.2 Avregistrering av Kort Om person finns på flera ställen försöker SITHS CA, dvs SITHS Admin att kopiera och uppdatera kort- och certifikatinformation till samtliga poster med samma HSA ID som kan lokaliseras under verksamhetens o -nivå. När certifikat tas bort från verksamhetens HSA katalog, så kontrolleras att attributvärden inte också tillhör något annat certifikat. När kortet lämnas tillbaka avregistreras det i SITHS Admin som då noterar detta och uppdaterar kortets post i bakomliggande databaser. Alla certifikat och e-legitimationer spärras automatiskt, liksom själva kortet, så att allting på kortet är taget ur bruk. SITHS Admin tar dessutom bort alla uppgifter som tillhör det aktuella kortet från HSA; kortnummer, certifikatets serienummer, Mifare-nummer, m.m. då kortet avregistreras. Om aktuellt kort inte är ett kort som beställts och tillverkats i SITHS-systemet kommer inte SITHS Admin kunna hantera uppgifter kring kort och e-legitimation. Spärr av kort och e- legitimation behöver då utföras hos utgivande part. Information på magnetremsa och RFID-chip kan heller inte administreras. Om det enligt databasen inte finns fler certifikat på kortet så tas även kortdata bort. När ett kort ska tas bort så tas först de certifikat som enligt databasen ska finnas på kortet bort, sedan tas kortdata bort. Sid 6/9

8 2.3 Spärr av certifikat Vid begärd spärr kommer följande certifikatinformation att tas bort från verksamhetens HSA katalog: serialnumber usercertificate validnotafter validnotbefore Om borttagningen av certifikatinformation misslyckas, så fås ett felmeddelande. Om det enligt SITHS CA:s databas inte finns några fler certifikat på kortet, så tas även kortinformation bort från verksamhetens HSA katalog. 2.4 Avregistrering av kort Vid begärd avregistrering kommer följande kort- och certifikatinformation att tas bort från verksamhetens HSA katalog: cardnumber hsamifareserialnumber serialnumber usercertificate validnotafter validnotbefore Vilka certifikat som skall tas bort erhålls från SITHS CA:s databas. Om borttagningen av korteller certifikatinformation misslyckas, så fås ett felmeddelande. Borttagning sker i flera operationer och LDAP-protokollet saknar transaktionshantering, så det är teoretiskt möjligt att någon operation misslyckas. Det kan dock aldrig finnas certifikatinformation utan tillhörande kortdata. Om det enligt SITHS CA:s databas inte finns några fler certifikat på kortet, så tas även kortinformation bort från verksamhetens HSA katalog. 3. Misslyckad publicering Misslyckad publicering innebär att SITHS CA, dvs SITHS Admin, inte kunde kopiera in ett certifikat och dess eventuella kortinformation till verksamhetens HSA katalog. Kortet och certifikatet fungerar och är giltigt oavsett detta, men fler och fler tjänster (t ex BIF, egen webbservicetjänst, mm) kommer att vilja läsa certifikatet från HSA katalogen för att bland annat verifiera medarbetarens behörigheter och aktualitet. Finns inte certifikatet då på plats kommer medarbetaren att nekas åtkomst till applikationer. Sid 7/9

9 Publicering av certifikat och kortinformation genomförs endast en gång. Nekas SITHS CA, dvs SITHS Admin, åtkomst för publicering eller att information om var publicering skall ske inte kan tydas ut, så uppstår en misslyckad publicering. Ett e-postmeddelande med certifikat- och kortinformation automatgenereras och sänds till verksamhetens definierade RA-funktionsbrevlåda, se SITHS RA Utbildning.pdf. Via ett publiceringsverktyg (för beställning kontakta kan kort- och certifikatinformation i efterhand publiceras in till verksamhetens HSA katalog. Det vanligaste skälet till misslyckad publicering är att person (eller funktion) flyttats runt i verksamhetens HSA katalog från det att beställning av kort/certifikat påbörjats och innan det slutligen har producerats. SITHS CA, dvs SITHS Admin, försöker visserligen att leta reda på den nya placeringen av medarbetaren, men begränsas om verksamheten har detaljerat certifikatets innehåll av ou-nivåer i verksamhetens konfigurationsparametrar, se även SITHS RA Utbildning. TIPS! Definiera konfigurationsparametern antal ou som visas i certifikat=0. Ingår flera ou -nivåer i certifikatet, så är det dess lägsta ou -nivå som avgör om publicering av certifikat kan genomföras. Eller inte. Ingår inga ou -nivåer i certifikatet, så försöker SITHS CA att obegränsat under organisationens o söka reda på var en medarbetare är placerad. Sid 8/9