Frågor om tjänste- och underleverantörer (FAQ)

Vad är Biobank Sverige IT för typ av organisation?

Biobank Sverige IT är skapat genom regional samverkan mellan vårdhuvudmän i Sverige.
Uppdrag, finansiering och styrning hanteras gemensamt av alla deltagande regioner i samverkan och regleras genom ett samverkansavtal. Rent praktiskt har samverkansavtalet utsett Region Uppsala uppdraget att hålla linjeorganisation för berörd personal samt att upphandla de resurser som behövs för att förverkliga organisationens mål.
Region Uppsala blir även personuppgiftsbiträden i relation till de huvudmän som deltar i samverkan eftersom de system som förvaltas innehåller personuppgifter. För detta finns ett personuppgiftsbiträdesavtal.

Vilken är relationen mellan Biobank Sverige och Biobank Sverige IT?

Biobank Sverige är en infrastruktur som består av parter från vård, forskning, näringsliv och allmänhet. Uppdelat på intresseområden organiseras infrastrukturens styrande arbete av olika arbetsutskott. Ett specifikt arbetsutskott utgör styrgrupp för Biobank Sverige IT. Man kan därmed säga att Biobank Sverige har en styrande funktion för Biobank Sverige IT, eller omvänt att Biobank Sverige IT är en enhet som utför ett uppdrag åt Biobank Sverige.

Är Svenska Biobanksregistret respektive BISKIT att betrakta som molntjänster?

Det kommer snarast ner till vilken definition man utgår från samt vilka egenskaper man betonar. Utifrån Post och telestyrelsens(PTS) definition menar vi att SBR inte är att betrakta som en molntjänst enligt vad som beskrivs i NIS-direktivet.

De är definitivt tjänster som levereras över internet, som tillämpar lagring av data och som är universellt åtkomliga för användare, men samtidigt är de inte system som har en motsvarande funktionalitet i en lokal installation på det sätt PTS beskriver. Det är inte heller så att Biobank Sverige IT har någon omfattande skalbarhet i tjänstens leverans. Den är bunden till ett ställe och kan inte agnostiskt fördelas ut på andra datacenter.

Vidare är definitionen av leverantör inte helt lätt att applicera på den samverkan som styr arbetet. Varje region i samverkansgruppen är förvisso en juridisk person men det finns inget avtalsförhållande mellan köpare och leverantör. Det finns inte heller någon möjlighet för en organisation som inte är med i samverkan att ta del av tjänsten och därmed kan man inte se Biobank Sverige IT som en leverantör av en tjänst.
De system som samverkansöverenskommelsen omfattar utvecklas specifikt för de vårdgivare som deltar i samverkansorganisationen. De förvaltas av en utpekad organisation som bara svarar för dessa system och de har sin drift på utpekade servrar enligt avtal som formulerats av organisationen. De är i vår mening snarare att betrakta som traditionellt webbaserade system med en centraliserad drift som därtill utvecklas internt av en grupp samverkande organisationer.

Hur säkerställs att personuppgifter inte hanteras utanför EU/EES? (lagring, replikering et.c.)

De system som hanterar personuppgifter driftas av Proact Sweden som därigenom är underleverantörer till Biobank Sverige IT. Proact Sweden tillhandahåller en driftsmiljö som förvaltas inom organisationen av egen personal. Det är samma system som används för ett antal av regionens egna system.

Hur säkerställer ni att personuppgiftsbiträdesavtal upprättas i enlighet med gällande regelverk för all berörd personal?

För driften av systemen har ett underbiträdesavtal tecknats med Proact Sweden. De utvecklare som deltar i utvecklingen av systemen och som kan komma att behöva ta del av personuppgifter exempelvis i samband med felsökning är anställda i Region Uppsala alternativt har ett konsultavtal som innefattar erinran om sekretess enligt gängse regelverk.

I händelse av att annan underleverantör behöver anlitas för ett specifikt uppdrag kommer personuppgiftsbiträdesavtal upprättas och som baseras på det aktuella uppdragets innebörd.

Hur säkerställer ni att personuppgiftsbiträdesavtalet ej är underordnat annat avtal eller de generella avtalsvillkoren för leverans av den aktuella tjänsten?

Utformningen av de PUB-avtal som används är beslutad av samverkansgruppens styrgrupp och därmed direkt underställt alla de huvudmän för vilka Biobank Sverige IT har i uppdrag att hantera personuppgifter för. Avtalet reglerar hur underbiträden kan användas och villkoren för det. De underleverantörer som engageras granskas därför med avseende på deras organisation för att säkerställa att de inte står under tredje lands kontroll på ett sätt som äventyrar lagstiftning i Sverige eller EU.

Vem/vilka kommer att behandla eller ha åtkomst till personuppgifterna? Motivera respektive person/funktion behov av att behandla personuppgifterna.

Först och främst har de användare som regionen utser åtkomst för att använda systemet för de ändamål som det är byggt för. Grovt sett kan man dela upp behörigheter i sådant som rör de administrativa processer som systemet stödjer och sådant som rör administration av användare och funktioner i systemet självt. Vid start utser varje deltagande region en person som är huvudadministratör för den regionens användare. Den personens kontouppgifter registreras av Biobank Sverige IT eftersom det inte ska vara tekniskt möjligt att så att säga ge sig själv behörigheter. Därefter delas alla behörigheter inom regionen ut av den användaren, inklusive eventuellt byte av huvudanvändare. Biobank Sverige har tagit fram förslag på rutiner för utdelning av behörigheter i systemet.

Som beskrivs i punkten rörande molntjänst är de system som Biobank Sverige IT utvecklar inom ramen för den regionala samverkan i första hand att betrakta som så kallade "SAAS" system (Software As A Service). Uppdraget omfattar utveckling och förvaltning av systemen men innehåller inte någon uppgift som innebär behandling av personuppgifter utöver att hålla dem lagrade i systemet.

Personal vid Biobank Sverige IT har därför inte konton som medger åtkomst till någon inloggning i systemets produktionsmiljö. Det innebär dock inte att det saknas tekniska möjligheter för personal att bereda sig åtkomst till personuppgifter. I och med att åtkomstregleringen är implementerad av organisationen själv är det ofrånkomligt att samma personer även har kunskap om hur systemet kan kringgås. Alla säkerhetssystem, fysiska eller digitala kommer med den inneboende begränsningen att ytterst måste de vila på ett förtroende för den som implementerat systemet.

Därför regleras detta genom instruktioner för personal och ytterst i anställningsavtal där erinran om sekretess finns på samma sätt som för all personal i vården. Vår instruktion för detta område innebär att en åtkomst till data i produktionsmiljöer endast får förekomma i sammanhanget av en skriftligt formulerad uppgift som är tidsbudnen och definierad i omfattning. Dessa ska därtill dokumenteras i logg när de utförs så att det framgår när någon har tagit del av uppgifter och varför.

För att konkretisera så handlar det typiskt om antingen felsökning i samband med upptäckta avvikelser alternativt arbete med data i sig självt såsom för kvalitetskontroller eller konverteringar och liknande. I dessa fall finns en direkt beställning av den personuppgiftsanvarige alternativt för organisationen generellt.

Exempel på ett tillfälle när personal måste behandla alla personuppgifter som systemet innehåller är vid de återkommande tillfällen då vi övar återställning av system efter ett tänkt katastrofscenario. I de fallen skapas en helt ny miljö från tagna backuper och innehållet jämförs kvantitativt med originalsystemet för att säkerställa att en korrekt återställning har gjorts. Även om det i legal mening är en personuppgiftsbehandling finns det inget i uppgiften som motiverar att personal tar del av enskilda patienters personuppgifter. Principen om begränsning av personuppgiftsbehandling innebär att vi strävar efter att så långt som möjligt använda kvantitativa metoder snarare än att behandla enskilda personers uppgifter.

Åtkomsterna görs inom ramen för det som allmänt kallas ett undantag för administrativ och teknisk personal, men har likväl utformats för att så lång det är möjligt behålla den transparens och spårbarhet som vi eftersträva att uppnå.

Åtkomster för huvudmannens egna personal, alltså de som vi normalt kallar "användare", hanteras helt av huvudmannen själv genom administrativa funktioner i systemen och motiveras givetvis av systemets ändamål, behovet att kunna fullgöra sin uppgift som vårdgivare och myndighet.

Hur autentiseras de användare som loggar in i systemet?

Det är ytterst en fråga för deltagande regioner att besluta men vi har generellt byggt ett system som förlitar sig på att användare kan autentisera sig genom certifikat från utställaren SITHS. Det är ett uppenbart val eftersom alla de regioner som deltar i samverkan också är RA-enheter i certifikatsorganisationen SITHS. Vi har valt att kräva tillitsnivå 3 för inloggningar (LOA 3) och användare identifieras av det HSA-id som lagras på certifikatet. Man kan inte använda eventuella andra certifikat som kan finnas på e-tjänstekortet. (SITHS med personnummer eller Telia e-ID m.m.)

Vilka mekanismer finns för att förhindra att teknisk personal olovligen bereder sig inloggning till produktionssystem?

Utvecklare har i allmänhet bara tillgång till kort med certifikat utställda för testmiljö (PP i Ineras terminologi) vilka inte är betrodda i produktionsmiljön. För personal hos Region Uppsala som i sin tjänst har SITHS-kort utfärdade gäller fortfarande att det är respektive regions företrädare som reglerar behörigheter i systemet. I praktiken innebär det att personal från Biobank Sverige IT inte har möjlighet att logga in som användare i produktionsmiljön om inte en regional administratör skulle lägga upp denna som en betrodd användare med behörigheter.
Bakomliggande system skyddas sedan från åtkomst genom att de placerats på ett eget skyddat virtuellt nätverk hos driftsleverantören Proact Sweden. Det finns därmed ingen enkel väg att bereda sig ett eget konto i produktionsmiljön.

Vilka säkerhetsmekanismer används för att förhindra obehörig åtkomst till bakomliggande system?

All åtkomst till system som innehåller eller berör hantering av produktionsdata skyddas från insyn genom kryptering enligt aktuella standarder och autentisering sker i samtliga fall med två-faktor autentisering. (Exempelvis kod-repositorys, byggservrar, loggservrar et.c.)
Rent praktiskt skyddas produktionsmiljön (eget kluster av logiska servrar) genom att de hanteras på ett separat och dedikerat nät. I brandvägg blockeras anrop från internet med undantag för en handfull utpekade IP-adresser som tillhör Biobank Sverige IT alternativt underkonsult med avtal. Det är således inte möjligt att anropa resurser annat än från de nät där våra utvecklare arbetar.

Därutöver har varje utvecklare en personlig nyckel för att logga in på klustrets maskiner. Dessa har installerats på utvecklares maskiner som sedan är skyddade med rot-kryptering och krav på relevant svåra lösenord.

Hur arbetar ni för att minimera åtkomst till personuppgifter för teknisk personal och som inte har i sitt uppdrag att behandla personuppgifterna?

Teknisk personal har enbart tillgång produktionsdata i samband med specifika uppgifter som med nödvändighet kräver åtkomst till produktionsdata. Det rör sig i allmänhet om antingen felsökning eller i samband med arbete med data i sig (exempelvis inläsningar, konvertering eller kvalitetssäkring). I samband med en uppgift där utvecklare behöver bereda sig åtkomst till data i produktionsmiljö skrivs detta upp i en logg med referens till ärendet som föranledde arbetet. I övrig tillåts ingen tillgång till produktionsdata av IT-personalen.

Även om denna typ av system ytterst kräver ett förtroende för personalen ifråga, vilket kommer till uttryck i sekretesserinran, så finns en dokumentation över frekvens och omfattning och som kan utvärderas i efterhand.

Beskriv hur personuppgifterna kommer att lagras

De uppgifter som hanteras i systemet lagras i ett lokalt installerat lagringssystem. Vår driftsleverantör, Proact Sweden, tillhandahåller en yta inom ett serverkluster för våra ändamål. Det är ett kluster som bygger på produkten OpenShift från Red Hat och till det finns lagringsytrymme från en dedikerad lagringslösning kopplad. Denna är lokaliserad i samma serverhall.
Utöver det använder vi en lösning för säkerhetskopiering som också finns inom regionen men av naturliga skäl på annan plats.

Finns det kodnyckel? Ja/Nej

Frågan kan inte besvaras på ett meningsfullt sätt utan att sättas i ett sammanhang, men sannolikt är svaret Nej. (eller Ja, beroende på hur man ser det)
Allt i systemet är skyddat av kodnycklar på olika nivåer och moderna system är inte uppbyggda för att skyddas på det sätt som frågan implicerar.

Hur kommer kodnyckeln att förvaras?

Koder, lösenord och nycklar hanteras i en för ändamålet dedikerad produkt i klustret. Applikationer som instansieras ges information om dessa när de startas.
Behörighet till "secrets" ges till utvecklare som loggar in med personliga konton och baserat på certifikat och lösenord (ssh). Tjänsten är därutöver skyddat av ett VPN som kräver en elektronisk kodgenereringsdosa för att nå nätverket.

Vem äger data i som skapas i och med systemets användning?

All data som skickas till, hanteras av eller skapas i samband med arbete i systemet tillhör den huvudman som ansvarar för den specifika hanteringen.
Biobank Sverige IT (Region Uppsala) äger inte rätt att använda lagrade uppgifter för annat än det som uppdraget omfattar och under den tid som uppdraget varar.
Vid avtalets avslut ansvarar personuppgiftsansvarig huvudman för beslut om data skall exporteras och återlämnas eller om den skall destrueras.

Vilken metadata skapas och hur används den?

När användare använder de funktioner som systemet erbjuder skapas samtidigt metadata om hur systemet används av alla användare. Loggar från anrop som görs till systemet från klientens webbläsare berättar om hur användaren navigerar och hur systemet svarar.
Biobank Sverige IT innehar rätten att använda metadata från systemen som förvaltas i syfte att säkerställa att systemet levereras med hög kvalitet. Det kan typiskt föra sig om att övervaka svarstider eller belastning i systemet för att identifiera eventuella problem som kräver åtgärd.
Det innebär att data behandlas automatiserat och fortlöpande men utan att kopplas till enskilda användare. På samma sätt sammanställs statistik från detta i syfte att underlätta dimensionering och för att identifiera återkommande källor till avvikelser m.m.
I de fall en upptäckt felhändelse kan misstänkas ha orsakat dataförlust eller på annat sätt påverkat användare i sin myndighetsutövning kommer den specifika användaren att spåras i syfte att hantera den uppkomna incidentens konsekvenser på bästa sätt, exempelvis för incidentrapportering till Intigritetsskyddsmyndigheten.
Frågan om metadata och dess användning är numer intressant med anledning av att många tjänsteleverantörer har hittat en lukrativ sidoanvändning av metadata i relation till tredje part. Det kan exempelvis röra sig om profilering för optimernig av marknadsföring eller försäljning av “mervärdestjänster”. Det förekommer inte någon profilering på kontonivå och den enda information som sparas och används från loggar är sådant som följer av legala krav eller för felsökning.

Hur hanterar ni avvikelser?

Avvikelser som upptäcks i systemen rapporteras automatiserat till en kommunikationskanal som förvaltningen bevakar under kontorstid. Förvaltningen arbetar under instruktion att dessa skall hanteras utan dröjsmål när de upptäcks.
Hantering innebär normalt att utvecklare granskar det inträffade för att bestämma avvikelsens orsak. Därefter vidtas de eventuella åtgärders som behövs för att återställa normal funktion så snart som är praktiskt möjligt.
I den händelse det finns strukturella orsaker bakom felet (buggar eller fel i design) dokumenteras dessa och förslag på preventiva åtgärder formuleras för närmare prioritering och utveckling efter det akuta skedet är hanterat.

Hur hanterar ni säkerhetsincidenter?

Med säkerhetsincidenter avses här avvikelser där man kan misstänka att någon i strid med tänkt begränsning, medvetet eller omedvetet har tagit del av information som skulle ha varit skyddad, alternativt på en teknisk nivå kunnat skaffa behörigheter denne inte skall ha.

På samma sätt som för vanliga avvikelser prioriteras det akuta skedet i det initiala arbetet. Däremot tillkommer sedan en analys av felets konsekvenser med avseende på om incidenten fått konsekvenser för tredje part eller inte. Analysen avslutas med en kort skriftlig rapport som bevaras och om där förekommit en konsekvens för tredje part inleds incidentrapportering enligt rutin beskriven nedan.

Hur fungerar er incidentrapporteringsrutin?

Med incident avses här en situation där en uppkommen skada är konstaterad. Till skillnad från en teknisk avvikelse vet vi i dessa fall att det finns en skada att hantera och därmed att det potentiellt finns ett ansvar hos en eller flera av huvudmännen att göra relevanta rapporteringar till granskande myndighet.
Förvaltningen hos BiobankSverigeIT rapporterar utan dröjsmål de uppgifter vi har om uppkomna incidenter till berörda huvudmän. Därefter bistår vi dessa i de vidare utredningar som behöver göras för att säkerställa att en korrekt rapportering kan göras.

Hur är er kontinuitetsplan formulerad?

Kontinuitetsplan för den grundläggande driften är samma som Proact Sweden arbetar efter i och med att det är hos dem som systemen hålls i drift. Till grundläggande drift räknas här nätverk, containermiljö för applikationsdrift (OpenShift), samt en del bakomliggande tjänster för exempelvis säkerhetskopiering.
Kontinuitetsplan för de applikationer som Biobank Sverige IT utvecklar och förvaltar är utformad med beskrivning av system och information samt reservrutiner och återställningsrutiner.

Vad har ni för rutiner för säkerhetsuppdateringar?

Prroact Sweden underhåller kluster och nätverksmjukvara i enlighet med etablerad plan hos dem. Klustermiljön bygger på produkten OpenShift som levereras av Red Hat som är ett linuxbaserat system för storskalig serverdrift. Produkten är licenserad och uppdateras i enlighet med leverantörens rekommendationer.

I och med att de applikationer som omfattas av avtalet utvecklas av Biobank Sverige IT själva är de versioner som tas i drift per definition de senaste och aktuella. Nya versioner av underliggande ramverk tas i bruk när det finns stabila utgåvor tillgängliga utifrån prioritering med andra åtgärder. Inaktuella versioner tas ut bruk med god marginal.

Hur säkerhetskopieras data från förvaltade system?

Säkerhetskopior av filsystem tas dygnsvis, veckovis och månadsvis och roteras så att vi kan återställa med avtagande granularitet i upp till ett år bakåt.
Bevarande för avbildningar sker enligt följande:
- Dygnsbackuper roteras efter 30 dagar
- Veckobackup roteras efter 12 veckor
- Månadsbackup roteras efter 12 månader

För databas innehas även transaktionsloggar mellan de ögonblicksbilder som tas vilket innebär att det i större detalj går att återskapa specifika tillstånd.
Återställning av systemet från backup testas regelbundet enligt förvaltningsplan. (Senast i mars 2024)

För ett katastrofscenario, hur genomförs återställning av systemet till normal drift och hur lång tid beräknas det att ta?

Återställningstid är givetvis starkt beroende på omfattningen av tänkt katastrof och vilka system som drabbats av haveri och när avbrott upptäcks. Förvaltningen är dimensionerad för att verka under kontorstid och har under denna en konstant beredskap att övergå till en kontinuitetsinsats för att återställa havererade system till normal drift.

De applikationer som Biobank Sverige IT förvaltar kan normalt återställas från backup till en ny miljö inom 2 timmar från påbörjat arbete. Enligt rutin görs normalt felsökning för att säkerställa att störning inte medfört skada innan miljö återställs (enligt rutin beskriven i Incidentrapportering). Detta för att säkerställa att en återställning inte också återintroducerar ett fel som riskerar medföra än mer allvarliga konsekvenser. Tiden är därför en uppskattad angivelse och ett skarpt scenaro kan medföra längre perioder av nertid.

Vi uppfattar att för de aktuella tjänsterna är en korrekt återställning av högre prioritet än hastigheten med vilken den återstartas.

Har servrarna skydd mot skadlig kod?

Ja, om man med skadlig kod menar hot mot serverns funktion.

Aktuella produkter som används erhåller kontinuerliga säkerhetsuppdateringar från leverantör. Den kod vi utvecklar bygger på komponenter och bibliotek som baseras på öppen källkod. Den hämtas från officiella och signerade källor vilket innebär att vi har en grundläggande kontroll på vad som läggs upp för drift i miljön.
All byggd kod exekveras i avskilda kontainrar (docker/kubernetes) för att minska spridningseffekter av eventuella avvikelser.

De tjänster som servrar tillhandahåller för användare är inte trivialt öppna för exploatering eller för spridning av skadlig kod mellan klientmaskiner. Det finns inga mail-tjänster, delade filsystem eller annat som skulle kunna sprida virus mellan klienter och därför är anti-virus program i allmän bemärkelse inte aktuella för dessa servrar. Det finns funktioner för att ladda upp bilagor till ärenden över http(s). Dessa begränsas till specifika filformat och får aldrig exeveringsbefogenhet. Klienter som hämtar bilagda filer ansvarar för att ha erfoderligt skydd mot skadlig kod för hämtade filer.

Hur är den fysiska miljön för servrar säkrad?

Enligt driftsavtal ansvarar Proact Sweden för att den fysiska miljön är skyddad mot obehöriga.

Hur länge kommer uppgifterna att behandlas (inklusive lagras) för det aktuella ändamålet? Motivera lagringstid

Samverkansavtal och personuppgiftsbiträdesavtal reglerar inte ansvar för bevarande och gallring. Det innebär att ansvaret för gallring ligger kvar hos de personuppgiftsansvariga huvudmän som använder systemet ifråga. Biobank Sverige IT följer därför de instruktioner som respektive huvudman ger för bevarande och gallring.
I och med att Biobank Sverige IT endast behandlar uppgifterna genom lagring i system och inte aktivt förvaltar innehållet torde det vara lämpligt att personal från personuppgiftsansvarig huvudman själv tar bort information som inte är relevant att fortsätta behandla. Om det därutöver behövs någon mekanism som automatiskt gallrar uppgifter är det en funktion som måste specificeras som ett krav, vilket ännu inte har gjorts.

Det finns även ett tekniskt förhållande som i någon utsträckning påverkar denna fråga. Vi har ett beslut om att behålla säkerhetskopior, så kallad back-up av systemets databaser och filsystem. Detta för att kunna återställa systemet vid en kritisk händelse och för att kunna undersöka historik om något avvikande observerats. Rent praktiskt innebär det att vi har kopior av information lagrad i upp till 12 månader efter att de raderats av en användare. Återläsningsrutin för systemen innefattar en åtgärd för att återapplicera gallringar som eventuellt gjorts baserat på information från logg.

Det innebär att man kan hävda att det finns en "skugga" av personuppgiften som ligger passivt i en back-up, men att det även finns en rutin för att undvika att uppgiften återkommer i systemet. Denna praxis är vedertagen för system av denna typ.

Se även ytterligare information om bevarande och gallring på egen sida.

Hur tillämpas gallring i systemet?

Data ägs av den huvudman som registrerat uppgifterna i systemet. Det är således varje deltagande huvudmans uppgift att inom ramen för sitt personuppgiftsansvar definiera och implementera relevanta gallringsrutiner i sin personuppgiftshantering.