Støtte for aktuelle sikkerhetsprotokoller
HelseID er bygget på enkelte sentrale sikkerhetsprotokoller (som Oauth 2.0 og OpenID Connect). For integrasjon med HelseID er det avgjørende at de tekniske systemene man ønsker at skal interagere med HelseID, uavhengig av hvilken aktørtype man representerer, også støtter disse sikkerhetsprotokollene.
Dersom man ikke selv rår direkte over den tekniske grunnmuren i de tjenester man tilbyr eller systemer man bruker, for eksempel fordi man kjøper inn dette som tjenester, er det viktig å kravstille støtte for disse sikkerhetsprotokollene overfor leverandørene.
Merk at i helsesektoren, herunder ved bruk av HelseID, har man definert en “profil” for bruk av disse sikkerhetsprotokollene. Vi anbefaler at denne følges ved integrasjon mot HelseID. Mer om dette kan leses her HAPI - Health Grade APIs og den aktuelle profilen finnes under vår tekniske dokumentasjon her Profil for identitetstilbydere og eID-leverandører.
Integrasjonsbehov ved typiske bruksscenarioer
Avhengig av tiltenkt bruk og ønskede gevinster må det settes opp ulike tekniske integrasjoner både mot HelseID, og potensielt mellom systemer i den enkelte virksomhet. Figuren under illustrerer integrasjonsbehov ved de to mest typiske scenarioene for bruk av HelseID.
...
Fellesflyt: Delen av fellesflyten som forvaltes av HelseID selv er allerede på plass, dvs. integrasjoner mellom HelseID og mot nasjonale registre og eksterne identitetstilbydere. Hvis det imidlertid er ønske om at en intern eID-løsning i en helsevirksomhet skal tilgjengeliggjøres i HelseID kreves særskilt integrasjon av dette. Det er da nødvendig at helsevirksomheten etablerer en integrasjonskomponent, kalt en "Secuity Token Service", som muliggjør at den interne eID-løsningen (f.eks. "Active Directory") kan kommunisere og utveksle sikkerhetsbilletter med HelseID. Eksempler på dette er Helse Sør-Øst sin bruk av "Ping identity", og HelseMidt som allerede er integrert med HelseID via "ADFS".
Lokale integrasjonsbehov for engangspålogging
Som beskrevet i enkelte av bruksscenarioene på HelseIDs hjemmeside, er det flere forutsetninger som må være på plass for å faktisk oppnå engangspålogging, og at hva man oppnår engangspålogging mellom kan variere. Engangspålogging forutsetter i stor grad tekniske integrasjoner mellom eller i lokale systemer i den enkelte virksomhet.
Lokal nettverkskonfigurasjon ved bruk av ID-porten
Brukerautentisering via identitetstilbydere som tilbys i HelseID gjennom ID-porten vil kreve tilgang fra helsepersonellets webleser til både ID-porten og aktuelle identitetstilbydere (slik som Buypass, Commfides og BankID). Nevnte aktører operer på internett, mens brukerorganisasjonene tjenestekonsumenter typisk operer på Helsenettet, et separat nettverk som ikke er direkte sammenkoblet med internett. Helsevirksomheter må følgelig sørge for å implementere nødvendige nettverksåpninger i helsepersonells weblesere fra eget nettverk og mot ID-porten og aktuelle eksterne identitetstilbyderne, alternativt konfigurere bruk av NHNs sikkerproxy.
For mer om dette, se Technical requirements for using HelseID
Støttede nettlesere
HelseID støtter IE 11 og nyere (utenom i "kompabilitetsvisning"), samt de andre store nettleserne Edge, Chrome, Safari og Firefoxnyere nettlesere, så som Firefox, Edge, Chrome og Safari. Det gjøres ikke testing mot andre nettlesere per i dag.
...
Merk også at de enkelte identitetstilbyderne kan ha egne kompatbilitetsgarantier.
Sårbarhet og driftsgaranti
HelseID arbeider kontinuerlig med å herde våre systemer og driftsmiljøer for å bli så robuste som mulig. Blant annet har vi fokus på å etablere redundans i systemer og driftsmiljøer, håndtere teknisk gjeld og å fortløpende oppdatere tjenesten dersom sikkerhetshull eller andre svakheter oppdages. Tjenesten leveres av Norsk Helsenett og kjører i Helsenettet, som har en oppetidsgaranti på 99,7% for sine tjenester.
Det finnes naturligvis en risiko i at jo flere aktører (tjenestekonsumenter og tjenestetilbydere) som er avhengig av HelseID som knutepunkt, jo høyere sårbarhet dersom noe mot formodning skulle forhindre tjenesten fra å operere som normalt (“single point of failure”). Av den grunn Samtidig er jo nettopp utbredt bruk av HelseID en av de store gevinstene for både sektoren og den enkelte virksomhet, ved at det blir enklere å samhandle med andre og tilgangen på informasjon blir større.
Det er til syvende og sist den enkelte virksomhet som må gjøre en kost/nytte- og risikovurdering for bruk av HelseID, og eventuelt gjøre tiltak de ser som nødvendige for å redusere risikoen for hva et “single-point-of-failure”-scenario med HelseID kan innebære. Merk at risiko knyttet til drift og stabilitet i HelseIDs driftsnett og “driftsleverandør”, altså hhv. Helsenettet og Norsk Helsenett SF, vil være lik for HelseID som for andre tjenester som er driftet i Helsenettet, herunder en god del nasjonale e-helsetjenester.
Anbefaling
Av ovennevnte grunner anbefaler vi generelt ikke å gjøre tilgang til systemer som kun skal være tilgjengelige lokalt (på et sykehus, for eksempel) avhengig av kun HelseID for tilgang.
Vi anbefaler derimot generelt at HelseID sikrer systemer som skal være del av digital samhandling på tvers av virksomheter, regioner , eller nasjonalt, eller samt for tjenester som skal være tilgjengelige på tvers av lokale nettverk og på internett på samme tid. Her har HelseID en klart verdiøkende effekt,.
Det å ha eventuelt skulle ha lokale systemer og løsninger som en backup hvis HelseID skulle være utilgjengelig kan være en vei å gå hvis man ønsker enda høyere driftssikkerhet eller lokal kontroll, men vil i mange tilfeller være meget ressurs- og teknisk krevende å få til. Derfor anbefaler vi generelt ikke dette.Det er til syvende og sist den enkelte virksomhet sitt ansvar å vurdere den operasjonelle risikoen og gjøre eventuelle tiltak de ser som nødvendige deretter.