This page in English

Dette dokumentet er et vedlegg for sikkerhetsprofilen til HelseID. Hensikten er å forklare hvorfor vi stiller de ulike kravene i sikkerhetsprofilen slik at leverandører bedre kan tilpasse sine løsninger.

Generelle krav for alle HelseID-klienter

Krav om bruk av TLS (SK1)

TLS er nå industristandard for all kommunikasjon over internett, kostnaden ved implementasjon er lav og det er svært lav ekstra kostnad ved bruk.

Trusselmodellen for OAuth2 bygger på en antagelse om at konfidiensialitet er garantert gjennom bruk av TLS. Dersom denne antagelsen ikke stemmer, så må man revurdere all bruk av OAuth2 og OpenID Connect.

Vi krever derfor at TLS er brukt for all trafikk over åpne nett og vi anbefaler at mekanismen også er brukt internt.

Krav om klientautentisering med private_key_jwt (SK2)

HelseID tillater ikke bruk av andre mekanismer for klientautentisering enn private_key_jwt. Denne mekanismen baserer seg på asymmetrisk kryptografi ved bruk av nøkkelpar. Her besitter klienten en privatnøkkel og HelseID kjenner bare til den offentlige nøkkelen. Den offentlige nøkkelen kan kun brukes til å bekrefte digitale signaturer laget ved bruk av privatnøkkelen.

Denne mekanismen har to fordeler i forhold til den mer utbredte mekanismen client_secret der klientautentisering gjøres ved bruk av et passord som er kjent både for klienten og HelseID. Den første fordelen er at HelseID aldri har kjennskap til privatnøkkelen, det er kun klienten som har tilgang på denne.

Den andre fordelen er at det erfaringsmessig er lettere å sikre et nøkkelpar enn det er å sikre et passord. Mange operativsystemer har gode mekanismer for å lagre signeringsnøkler slik at bare utvalgte brukere eller prosesser kan bruke dem.

Krav om at klienter er konfidensielle klienter og bruk av nøkkelpar (SK3, SK4, SK5)

De fleste API-ene HelseID beskytter gir tilgang til sensitive helseopplysninger om store grupper av mennesker. Konsekvensen av urettmessig tilgang til disse er såpass høy at vi ikke tillater klienter som ikke kan beskytte en hemmelighet tilstrekkelig. I HelseID knyttes dessuten hemmeligheten til en organisasjon, det er denne mekanismen som gjør at vi kan legge til organisasjonsinformasjon i Access-token.

Det finnes mange mekanismer for å beskytte hemmeligheter i en "ren" webapplikasjon, men ingen gir tilstrekkelig grad av sikkerhet for vår bruk. Samtidig tillater HelseID at lokalt installerte tykklienter framstår som en konfidensiell klient. Dette er for å være kompatibel med de mange eksisterende journalsystemene som er i bruk i dag. En stor andel av disse er lokalt installerte tykklienter. Vi krever at hemmeligheten beskyttes på samme måte som helseopplysningene i klienten beskyttes.

Det er et vanlig prinsipp ved håndtering av nøkkelpar at dette bare skal brukes for ett formål. Hensikten er både å beskytte nøkkelparet mot urettmessig bruk og å forhindre forvirring.

HelseID stiller ingen krav til hvordan nøkkelparet utstedes, det er opp til leverandør av klienten å velge en god rutine. Det skal derfor være få eller ingen behov for å gjenbruke nøkkelparet for andre formål. En liste over hvilke algoritmer og nøkkelengder HelseID støtter finnes her.

Selvbetjeningsløsningen til HelseID tilbyr et API for automatisk rullering av nøkkelpar. Ved å bruke dette API-et kan leverandøren av klienten lett bytte nøkler som klienten selv oppretter ved behov.

Krav om bruk av DPoP (SK6)

Trusselmodellen og angripermodellen for OAuth2 beskriver Access-token på avveie som en stor risiko. I utgangspunktet er det ingen garanti for at den som bruker et Access-token er den riktige klienten, API-et må derfor stole på at klienten er tilstrekkelig sikret. Det er mange måter et Access-token kan komme på avveie. Det kan for eksempel vises i brukergrensesnittet til klienten, det kan ende opp i logger eller det kan plukkes opp av verktøy som avlytter nettverkstrafikk.

For å beskytte mot misbruk av Access-token krever HelseID at alle klienter og API-er tar i bruk mekanismen DPoP. Ved bruk av denne mekanismen kan API-et være veldig sikker på at klienten som bruker det er den riktige eieren.

DPoP krever tilpasninger både i klienten og i API-et. Vi ender derfor i en situasjon der leverandørene av klienter venter på at API-ene skal støtte DPoP, mens API-ene venter på at et tilstrekkelig antall klienter skal støtte mekanismen. For å få fortgang i denne prosessen krever vi at alle nye API-er støtter DPoP og at alle klienter implementerer støtte for DPoP. Siden DPoP er bakoverkompatibel med tradisjonelle Bearer-token kan klientene bruke mekanismen selv om API-ene de kaller ikke støtter den ennå.

Krav om beskyttelse av Access-token (SK7, SK8)

Begge disse kravene er her for å beskytte mot misbruk av Access-token. Selv om risikoen for misbruk er lavere ved bruk av DPoP, så vil vi fremdeles holde på disse kravene for å minimere sannsynligheten.

Krav om intern sikring på linje med kravene til HelseID (SK9)

HelseID er et stort økosystem som beskytter svært sensitive helseopplysninger. Tilliten mellom API-et som tilbyr helseopplysningene og eier av klienten som uthenter disse er høy, og vi ser derfor at et angrep mot en slik klient vil få store konsekvenser. Dersom et internt API fungerer som mellomledd mot et eksternt API sikret med HelseID, må det interne API-et derfor implementere de samme sikkerhetskravene. Slik kan man forhindre at det interne API-et blir et svakt ledd som kan kompromittere tillitskjeden.

Krav om generell web-sikkerhet (SK10)

De fleste klientene som integrerer med HelseID er webapplikasjoner, vi stiller derfor spesifikke krav om sikring av disse. Kravene er basert på kjente feil og svakheter som kan gi tilgang til API-ene HelseID beskytter. Disse kravene er mindre relevante for tykklienter siden angrep mot disse ofte krever tilgang til den lokale datamaskinen klienten kjører på.

Krav om bruk av et sertifisert klientbibliotek (FK1)

OAuth2 og OpenID Connect har blitt komplekse protokoller som det er krevende å implementere riktig. Samtidig er konsekvensen av feil stor, både for klienten og for API-ene klienten integrerer med. Vi krever derfor at leverandørene bruker ferdige biblioteker så sant disse finnes for programmeringsspråket som brukes. Dersom det ikke finnes et bibliotek som dekker alle behovene, krever vi at man bruker et bibliotek så langt det er mulig.

HelseID har publisert en liste over anbefalte klientbiblioteker her.

Krav om bruk av metadata-endepunktet til HelseID (FK2)

Det er veldig mange klienter og API-er som integrerer med HelseID. Endringer i tjenesten kan kreve oppdatering av veldig mange systemer, vi krever derfor at systemene er så fleksible som mulig.

Ved å bruke metadataene til HelseID i stedet for å hardkode verdier kan vi endre disse uten at systemene må endres. Dette gjelder særlig klienter som gjør brukerinnlogging og API-er siden disse trenger tilgang til signeringsnøklene til HelseID for å validere Identity- eller Access-token.

Vi anbefaler at metadataene caches i et døgn, dersom klienten eller API-et mottar et token som det ikke klarer å validere kan de forsøke å laste ned metadataene på nytt i tilfelle disse er oppdaterte.

Krav om caching av Access-token (FK3)

HelseID har blitt en kritisk komponent i Norsk helsesektor, vi er derfor opptatt av å beskytte tjenesten mot unødvendig eller uheldig bruk. Et Access-token har alltid en levetid og innenfor denne levetiden skal tokenet gjenbrukes i stedet for at klienten ber om et nytt token for hver forespørsel mot API-et.

Å gjenbruke Access-tokens gir mange gevinster. Ikke bare begrenser det trafikken mot HelseID, det vil også gi bedre responstid i klienten siden den slipper å gjøre http-kall mot HelseID og det vil forbedre tilgjengeligheten til klienten siden den vil fungere selv om HelseID er utilgjengelig i en kort periode.

Krav om synkronisering av klokker (FK4)

NHN har observert flere feil der årsaken har vært store forskjeller i hva klienten og HelseID eller API-et klienten kaller mener er riktig klokke. Dette slår særlig ut i validering av DPoP-bevis, men kan også føre til feil ved autentisering av klienten og i andre situasjoner.

Disse feilene er vanskelige å feilsøke siden de har en tendens til å være midlertidige. For å unngå disse feilene krever vi at alle klienter har en klokke som er synkronisert mot HelseID og NHN slik at tidsforskjellen blir så liten som mulig.

Krav om mekanismer for innsending av informasjon fra klienten til HelseID (FK5)

HelseID har mekanismer for å motta informasjon fra klienten som skal eksponeres som claim i Access-tokenet. Denne mekanismen er mest brukt for innsending av organisasjonsinformasjon, men den kan også brukes for å sende inn helsepersonellets attest (tillitsrammeverket) eller journal-id for SFM.

Applikasjonen skal sende inn informasjon via Token-endepunktet. Mekanismen som brukes her er en HelseID-spesifikk utvidelse av standardene, HelseID anbefaler ikke innsending via Request Object mot PAR-endepunktet. Årsaken er at implementasjonen blir enklere og i de fleste tilfeller blir brukeroppplevelsen bedre.

Krav for maskin-til-maskin-klienter

Krav om at klienten bruker Client Credentials Grant (SC1)

Selv om OAuth2 beskriver andre mekanismer enn Client Credentials Grant for uthenting av Access-token uten at en bruker er aktiv så har vi valgt å kun støtte denne mekanismen i HelseID. Årsaken er at den er relativt enkel å implementere, de fleste biblioteker støtter den og mekanismen passer godt sammen med andre deler av sikkerhetsprofilen til HelseID.

Krav for klienter som trenger brukerinnlogging

Krav om bruk av authorization-code-flyten og tilhørende mekanismer (SB1, SB2, SB3)

Disse kravene beskriver den grunnleggende bruken av brukerinnlogging i HelseID. De andre flytene som tilbyr brukerinnlogging er ikke lenger ansett som sikre, og selv Authorization Code-flyten må sikres med PKCE for å beskytte mot kjente angrep. PAR reduserer risikoen for angrep ved å beskytte en rekke sensitive parametre som ellers måtte sendes via nettleseren.

Krav om validering av ID-token (SB4)

Flere kjente angrep på OpenID Connect-protokollen handler om å lure en applikasjon til å godta et falskt token. Dersom applikasjonen ikke validerer ID-tokenet godt nok kan en angriper klare å logge inn selv om de egentlig ikke skal ha tilgang.

Klienten kan selv kontrollere hvilken informasjon som skal være med i ID-tokenet, dette gjør den ved å be om de HelseID-spesifikke scopene som beskrevet her (scopes) og her (tilhørende claims) .

Krav om sammenkobling mellom lokal og ekstern brukeridentitet (SB5)

Dette kravet treffer kun applikasjoner der brukeren logger inn med andre mekanismer enn HelseID og senere logger inn med HelseID for å få tilgang til nasjonale API-er. I disse applikasjonene er det en risiko for at de to innloggingene gjøres av ulike personer noe som igjen fører til utlevering av helseopplysninger på feil grunnlag. For eksempel kan man logge inn lokalt med brukernavn og passord for deretter å låne en annen brukers BankID for å logge inn til de nasjonale fellestjenestene.

For å beskytte mot denne feilen krever vi at applikasjonen sjekker fødselsnummer eller HPR-nummer for den innloggede brukeren opp mot tilsvarende verdier i ID-tokenet. Det er ikke tilstrekkelige å sjekke navn og HelseID tilbyr ikke andre verdier som kan brukes for å bekrefte brukerens identitet.

Systemer der innlogging gjøres med HelseID fra starten av trenger ikke å ta hensyn til denne problemstillingen.

Krav om at klienten ikke ser på innholdet i Access-tokenet (FB1)

Dette kravet er både for å beskytte klienten mot feil og for å gjøre det lettere for HelseID å gjøre endringer i framtiden.

Innholdet i et Access-token er ikke kontrollert av klienten, innholdet her er tilpasset behovet til API-et det gir tilgang til. Siden behovet til API-et kan endres over tid risikerer applikasjonen at det oppstår feilsituasjoner som det vil være vanskelig å håndtere. For eksempel kan et API som har behov for brukers fødselsnummer, velge å heller bruke HPR-nummer. Dersom klienten leser ut fødselsnummer fra Access-tokenet så vil denne feile når API-et gjør endring på sin side.

Klienten kan selv kontrollere hvilken informasjon som skal være med i ID-tokenet, dette gjør den ved å be om de HelseID-spesifikke scopene som beskrevet her (scopes) og her (tilhørende claims).

HelseID usteder i dag Json Web Tokens med digitale signaturer i JWS-format. Disse kan leses og verifiseres av alle som får tilgang til tokenet. I framtiden er det mulig at HelseID vil kryptere tokens ved å gå over til JWE-formatet eller til referanse-tokens der man må kalle HelseID for å få tilgang på innholdet. Applikasjoner som leser informasjon fra Access-tokenet vil i disse tilfellene feile.

I stedet for å lese innholdet i Access-tokenet bør applikasjonen bruke ID-tokenet samt responsen fra Token-endepunktet. Responsen inneholder en parameter expires_in som forteller hvor lenge Access-tokenet er gyldig. Denne brukes for å se hvor lenge tokenet kan gjenbrukes. Videre inneholder responsen en parameter scope som forteller hvilke scopes Access-tokenet gir tilgang til.

Krav om at innbyggere eller pasienter ikke kan bruke HelseID for innlogging (FB2)

HelseID er designet for innlogging i jobb-sammenheng, hensikten med tjenesten er å gjøre det enklest mulig for ansatte i helsesektoren å få tilgang til de ulike tjenestene på en sikker måte. Ett av tiltakene HelseID gjør for å få til dette er å ikke be personen som logger inn om samtykke (consent) til at klienten kan få tilgang til deres opplysninger og at den kan kalle API-er på vegne av dem. I HelseID antar vi at dette samtykket er gitt som en del av den ansattes kontrakt med arbeidsgiver.

For innbygger kan vi ikke gjøre denne antakelsen, skal innbygger logge inn må HelseID utvides med funksojnalitet for å gi samtykke dersom innloggingen gjøres som innbygger og ikke som ansatt i helsesektoren.

Krav for API-er som skal sikres med HelseID

Krav om at API-et må bruke et sertifisert OAuth2-bibliotek (FA1)

Begrunnelsen for dette kravet er den samme som for klienter, se over.

Krav om at API-er bruker metadataene til HelseID (FA2)

Begrunnelsen for dette kravet er den samme som for klienter, se over.

Krav om synkronisering av klokker (FA3)

Begrunnelsen for dette kravet er den samme som for klienter, se over.

Krav om bruk av HTTP for API-er (FA4)

Sikkerhetsprofilen til HelseID er basert på FAPI 2.0-profilen, denne bygger igjen på en svært detaljert trussel- og angriper-modell som er utviklet for OAuth2-protokollen. En grunnleggende antakelse i disse modellene er at man bygger på de eksisterende sikkerhetsmekanismene i HTTP-protokollen.

Det er mulig å bruke tokens fra HelseID i andre sammenhenger, vi har flere eksempler på dette i produksjon i dag, men denne bruken er basert på grundige risikovurderinger som er gjort på forhånd.

Ta kontakt med HelseID-teamet dersom du har et slikt behov, så bistår vi dere i å analysere behovet.

Krav om at man ikke blander Access-tokens med andre mekanismer for tilgangsstyring i samme endepunkt (SA1)

Hensikten med sikkerhetsprofilen til HelseID er å etablere en felles forståelse av hva som er god nok teknisk sikkerhet for deling av helseopplysninger mellom virksomheter i norsk helsesektor. Sikkerhetsprofilen bygger på en del antakelser om hvilke egenskaper en mulig angriper har og om hvilke tiltak som er innført for å beskytte mot disse angrepene. (link til BCP her). Dersom man blander OAuth2 med andre sikkerhetsmekanismer kan vi ikke ta utgangspunkt i vurderingene som er gjort i det internasjonale fagmiljøet og vi må da gjøre alle vurderinger fra bunnen av. Omfanget av et slikt arbeid er såpass overveldende at vi velger å ikke tillate en slik sammenblanding.

Vår antakelse er at det ikke vil være mye ekstra arbeid for leverandøren av et API å tilby flere endepunkter. Samtidig vil det være mer tydelig for klientene hvilke autentiseringsmekanismer de ulike endepunktene støtter og koden som gjør tilgangsstyring vil bli enklere å vedlikeholde.

Krav om hvordan Access-token valideres (SA2)

Det er mange detaljer som må sjekkes for at et API skal kunne ta en riktig tilgangsbeslutning. Et ferdig bibliotek vil validere alle standardverdiene og dermed garantere tilliten til selve tokenet, men API-et må selv implementere sjekk av organisasjonsnummer eller brukers identitet dersom det er behov for dette.

Krav om at API-et støtter DPoP (SA3, SA4, SA6)

Begrunnelsen for disse kravene er den samme som for klienter. HelseID-teamet kan bistå leverandør av API-et med implementering av DPoP dersom det er behov.

Riktig validering av DPoP-bevis er komplekst, så vi krever at man bruker et ferdig bibliotek for dette dersom det er mulig. Merk også at i et redundant miljø der man kjører flere instanser av API-et samtidig må alle instansene dele tilstand (typisk med en distribuert cache) for å beskytte mot avspilling av DPoP-bevis.

Krav om at man ikke godtar DPoP- og Bearer-tokens i samme endepunkt (SA5)

Hensikten med DPoP er å beskytte API-et mot misbruk av Access-token på avveie. Et Bearer-token (altså et Access-token som ikke er beskyttet av DPoP) kan brukes av alle som får tilgang til det, API-et har i utgangspunktet ingen mulighet til å sjekke hvem som faktisk bruker det. DPoP gir API-et muligheten til å sjekke at den som bruker tokenet er den riktige klienten og ikke en angriper.

Siden innføringen av DPoP er en brekkende endring i API-et så er mekanismen bakoverkompatibel med tradisjonelle Bearer-tokens. Dette betyr at en klient kan bruke et DPoP-token mot et API som bare støtter Bearer-tokens uten at API-et trenger å gjøre endringer. Samtidig vil de fleste API-er som innfører DPoP støtte Bearer-tokens i et eget endrepunkt slik at de ikke brekker eksisterende klienter i en overgangsperiode.

På den ene siden er disse to tiltakene en stor fordel, det lar klientene ta i bruk DPoP mot noen API-er uten at alle API-er må gjøre endringer samtidig. API-ene kan også ta i bruk DPoP og gradvis gå over til å kreve mekanismen. Samtidig er dette en risiko siden et DPoP-token på avveie kan misbrukes mot endepunktene som støtter Bearer-tokens. Tiltaket med innføring av DPoP gir altså ikke verdi så lenge API-et støtter både Bearer- og DPoP-tokens.

Ved å kreve ulike endepunkter og ulike scopes sikrer vi at DPoP gir verdi selv om API-et også støtter Bearer-tokens. De to tiltakene er delvis overlappende, men den generelle anbefalingen er å innføre begge to.

Krav om generell web-sikkerhet for API (SA7)

API-ene som er sikret av HelseID er alle tilgjengelige enten via Internett eller via Helsenettet. Det er derfor viktig at disse i det minste følger beste praksis for sikring av web-tjenester.