Generelle sikkerhetsvurderinger

HelseAPI er laget for å håndtere alle typer informasjon inkludert sensitiv personinformasjon. Dette betyr at sikkerheten må vurderes nøye for å unngå at uvedkommende får tak i informasjonen som er tilgjengelig eller får tilgang til noen tjenester via HelseAPI.

De som implementerer HelseAPI (for eksempel ved støtte for SMART on FHIR og FHIR) må være oppmerksom på krav til sikkerhet og gjennomføre en vurdering av risiko og sikkerhet innenfor flere områder før HelseAPI kan etableres.

Ved tilkobling til helsenettet binder man seg til Normens krav til informasjonssikkerhet. Selv om det er ikke er et krav om at HelseAPI tilbys via helsenettet, BURDE en tilbyder av HelseAPI vurdere sikkerhetskravene som er definert i Normen.

I tillegg til dette har Direktoratet for e-helse utgitt referansearkitekturer for datadeling og dokumentdeling. Under er det kort beskrevet noen områder og krav, men hver implementasjon må vurdere sikkerheten ved sin egen implementasjon.

Juridisk / Avtale

Ved etablering av HelseAPI SKAL det vurderes hvilke juridiske og avtalemessige krav som gjelder basert på informasjonen som tilbys. Dette kan inkludere databehandleravtaler eller andre juridiske krav for etablering av HelseAPI.

Krav til risikovurderinger

Ved etablering av HelseAPI SKAL det gjennomføres en risikovurdering, og denne skal dokumenteres for senere revisjon ved behov

Sikring av kommunikasjonen mot HelseAPI

For HelseAPI basert på REST, er det viktig av generell HTTP sikkerhet implementeres og det SKAL benyttes TLS eller annet transportsikring ved overføring av informasjon mot HelseAPI. Direktoratet for e-helse har utgitt en referansearkitektur for datadeling som burde vurderes.

For å støtte nettleserbaserte klientprogrammer med flere integrasjoner, BURDE tjenerne implementere cross-origin Resource sharing (CORS)

Autentisering

HelseAPI i produksjon SKAL i utgangpunktet autentisere klienten (og bruker) som får tilgang og autentiseringen skal være i henhold til kravene for informasjonen som tilbys. HelseAPI kan likevel tilby endepunkter eller tjenester som ikke krever autentisering dersom informasjonen som tilbys ikke krever dette, og et eksempel på et slikt endepunkt er "capability statement"

Autorisasjon / tilgangskontroll

Når klient og bruker er autentisert må også tilgangen autoriseres for å sikre at informasjon og tjenester kun tilbys de som skal ha tilgang.

HelseAPI SKAL verifisere korrekt autorisasjon basert på informasjonen og tjenesten som tilbys. Dette gjelder uavhengig av om informasjonen skrives eller leses fra HelseAPI.

Normen inneholder informasjon og krav om autorisasjon og det finnes bl.a. veiledere for tilgangsstyring.

Logging / Audit

Ved tilgang til HelseAPI SKAL det logges nok informasjon til at det i etterkant er mulig å verifisere tilgangsbeslutningen.

Responshåndtering ved tilgangsnekt

Både ved bruk av REST og FHIR med REST er det viktig at svar fra en tjener følger standardisering av HTTP status koder. HTTP standarden definerer følgende status kodeserier:

• 1xx-serien er reservert for lavnivå HTTP-ting.

• 2xx-serien er reservert for vellykkede kall der alt går som planlagt.

• 3xx-serien er reservert for omadressering av trafikk.

• 4xx-serien er reservert for å svare på feil gjort av klienten, f.eks. feil inputdata eller at de ber om ting som ikke eksisterer. Disse forespørslene skal være idempotente, og skal ikke endre tjenerens tilstand.

• 5xx-serien er reservert for svar når tjeneren gjør en feil. Ofte blir disse feilene returnert av applikasjonene og normalt utenfor utviklerens rekkevidde. Dette er for å sikre at klientene faktisk mottar et svar. Klienten kan ikke muligens vite tilstanden til serveren når et 5xx-svar mottas, og derfor bør disse unngås.

 Når klienter nektes tilgang, må en tjener gi nok informasjon slik at det dekker klientens behov for en god brukervennlighet. Tjeneren må returnere en http status kode som klienten kan presentere for brukeren sin. Nekting av tilgang kan skyldes flere forhold, for eksempel at bruker ikke er autorisert til å benytte API-et, bruker er ikke autorisert til å få tilgang til bestemte data eller at innbygger har sperret tilgang til dataene for brukeren.

Det er viktig når klienter nektes tilgang at svaret fra en tjener blir valgt med omhu. Dersom tjeneren returnerer for mye informasjon, kan dette avsløre sensitiv informasjon. For eksempel kan svaret fra en spørring etter en pasient sin diagnose som brukeren ikke har tilgang til, kunne gi opplysninger om at data om diagnosen faktisk finnes hos tjeneren. Dette kan brukeren sette sammen med annen informasjon som kan resultere i at brukeren kan forstå at pasienten har diagnosen.

FHIR-standarden har noen anbefalinger vedrørende håndtering av dette som vi ønsker å ta med som generelle anbefalinger for bruk av REST.