Autentisering i Tellucare & TelluCare Go

Innholdet på denne siden gir veiledning til helsevirksomheter som skal velge autentiseringsmetoder for tilgang til Tellucare og Tellucare Go

Innholdet på denne siden gir veiledning til helsevirksomheter som skal velge autentiseringsmetoder for tilgang til Tellucare og Tellucare Go. Tellucare er tilgjengelig både på stasjonære og mobile enheter, og kan nås via både fast internettforbindelse og mobilnett. Den native Tellucare Go-appen er tilgjengelig for mobile enheter. 

Siden gir en oversikt over kravene, ulike kombinasjoner av autentiseringsmekanismer og andre relevante faktorer som helsevirksomheten bør vurdere ved valg av autentiseringsmetode. Tellucare er en plattform utviklet med fokus på både sikkerhet og brukervennlighet, og tilbyr derfor flere autentiseringsfunksjoner.

Sikkerhetsnivået i systemet er avhengig av brukerens valg og prosedyrer definert av helsevirksomheten, der Tellu gir veiledning om implementering og bruk.

Autentiseringsmetoder i Tellucare inkluderer "innebygde" alternativer, som stoler utelukkende på Tellucares plattform, og autentisering basert på eksterne identitetstjenester, som utnytter plattformer som Azure AD eller ID Porten.
Notatet legger til grunn at tilgang til Tellucare vil gjøres over «åpent nett», dvs. internett eller mobilnettet.

Regulatoriske krav og anbefalinger

Krav gitt av Personopplysningsloven og relevant helselovgivning er sammen med anerkjent praksis i helse- og omsorgssektoren innarbeidet i Norm for informasjonssikkerhet for helse- og omsorgssektoren. Nedenfor gjengis utvalgte deler av Normen[1] og støttedokumenter.

[1] https://ehelse.no/normen/normen-for-informasjonssikkerhet-og-personvern-i-helse-og-omsorgssektoren

Normens hoveddokument

5.2.2 Autentisering

Autentisering skal som minimum ivareta følgende:

• Den autoriserte skal bekrefte sin identitet på en sikker måte. Sikker måte må besluttes på grunnlag av en risikovurdering.
• Ulike ansettelsesforhold skal identifiseres.
• Flere personer skal ikke benytte samme autentiseringskriterier.
• Tildeling av autentiseringskriterier (for eksempel brukernavn og passord) skal gjennomføres på en betryggende måte.
• Tilgang fra hjemmekontor og/eller mobilt utstyr (og mobilnettverk) skal sikres ved sikker autentiseringsløsning. Dette gjelder også for lokasjoner som kommuniserer ved hjelp av linjer virksomheten ikke har fysisk kontroll over.
• Alle standardpassord (fabrikkinnstillinger) på systemer og utstyr skal endres før behandling av helse- og personopplysninger starter.
• Ved bruk av trådløse nettverk for behandling av helse- og personopplysninger skal den autoriserte brukeren autentiseres med sikker autentiseringsløsning.

Benyttes roller, skal ulike roller identifiseres, og ved behov gis ny autentisering

5.3.4 Mobilt utstyr og hjemmekontor

For slikt utstyr kan man ikke sikre lokaler, utstyret skal derfor sikres. Det skal gjennomføres risikovurdering før løsningene tas i bruk, og ved endringer som kan påvirke informasjonssikkerheten. Det skal etableres administrative rutiner for bruk av mobilt utstyr og hjemmekontor.

Helse- og personopplysninger skal bare lagres lokalt på utstyret når dette er nødvendig ut fra tjenstlig behov, og skal alltid lagres kryptert.

Normens veileder for tilgangsstyring[1]

Sikker-hetsnivå (LOA)	Løsning
1	Ukjent bruker med selvvalgt passord og selvvalgt brukernavn
2	Identifisert bruker med tildelt brukernavn og førstegangs passord, tvungen bytte av passord
3	Tildelt brukernavn og engangspassord tilsendt på mobiltelefon (som SMS) eller personlig sertifikat
4	Løsninger basert på Public Key Infrastructure (PKI). Iht til gjeldende regelverk må løsningene være selvdeklarert i Nasjonal kommunikasjonsmyndighet i forhold til om de oppfyller krav i Kravspesifikasjon for PKI i offentlig sektor når det gjelder Person Høyt og Virksomhet (personlig kvalifisert sertifikat).

Normen Faktaark 24 – Kommunikasjon over åpne nett[2]

Normen setter krav til at det skal benyttes sikker autentiseringsløsning når det blir gitt tilgang til helseopplysninger for personell fra andre virksomheter. Ved autentisering av personer som kommuniserer helseopplysninger over et åpent nett anbefales det sikker autentisering. Dataansvarlig kan gjennom risikovurdering evt. konkludere med at lavere nivåer kan benyttes dersom andre tiltak totalt sett gir en god nok sikkerhet.

[1] https://ehelse.no/normen/veiledere/veileder-tilgangsstyring

[2] https://ehelse.no/normen/faktaark/faktaark-24-kommunikasjon-over-apne-nett

Sikkerhet ved mobile enheter

Uansett hvilken autentiseringsfaktor som velges, må tilstrekkelig sikkerhet være på plass på de mobile enhetene som brukes, og de må ha en gyldig brukersesjon etter pålogging. Helsevirksomheten er ansvarlig for sikkerheten til mobiltelefonene, inkludert, men ikke begrenset til:

• Valg av fysisk enhet (tjenesten forutsetter Android operativsystem)
• Operativsystemversjon og innstillinger
• Andre installerte apper på enheten
• Tilgangskontroll (skjermlås med pinkode, biometri eller annen tilgangskontroll)

Tellucare og Tellucare Go er utviklet og vedlikeholdt etter beste praksis for å gi brukervennlige funksjoner uten å gå utover sikkerheten. Likevel avhenger sikkerhetsnivået på løsningen av hvordan disse funksjonene brukes, samt kundenes valg og prosedyrer. Kunden er ansvarlig for disse valgene og må utføre en passende risikoanalyse for å definere hva som er akseptabelt og hva som ikke er det. Tellu sin oppgave er å gi relevant informasjon om hvordan Tellucare er implementert og gi gode råd om hvordan funksjonene kan og bør brukes.

Tellucare tilbyr mange alternativer for brukerautentisering, som kan deles inn i to kategorier: autentisering innenfor Tellucare og autentisering basert på en ekstern identitetsleverandør. Implementeringen av alle Tellucare sine autentiseringsmetoder baserer seg på den åpne plattformen Keycloak, noe som sikrer en toppmoderne implementering av standard autentiseringsprotokoller og kompatibilitet med alle større eksterne autentiseringsplattformer.

Tilgjengelige autentiseringsmekanismer

Autentisering som er innebygd i Tellucare

Tellucare sin "innbygde" autentisering er basert på brukernavn og passord autentisering og kan kombineres med et sett med 2FA-alternativer (SMS, Autentiseringsapp, IP-begrensning, osv).

Innebygd autentisering gir kontroll over autentiseringsregler og sesjonsvarighet innenfor Tellucare, og sikrer kontinuerlig tilgang selv uten tredjepartstjenester. Imidlertid mangler det Single-Sign-On (SSO)-funksjonalitet og legger fullt ansvar på Tellucare-administratorer.

 

Tofaktorautentisering

Tofaktorautentisering er en form for autentisering der man benytter to autentiseringsmetoder i kombinasjon. Tofaktorautentisering gir høyere sikkerhet når man skal bekrefte identitet ved pålogging.
 Tofaktorautentisering benytter to av følgende tre hovedmetoder:
•    noe man vet – for eksempel et passord
•    noe man har – for eksempel en kodegenerator eller engangskoder
•    noe man er – for eksempel biometriske data, slik som fingeravtrykk eller en håndskrevet signatur
Det mest vanlige er å kombinere noe man vet med noe man har, da innsamling og verifisering av biometriske data kan være vanskelig, for eksempel ved opprettelse av en ny brukerkonto. Kombinasjon av noe man vet og noe man har, er for eksempel en kodegenerator og et passord, eller en engangskode tilsendt på tekstmelding sammen med et passord.
Tofaktorautentisering gir vesentlig økt sikkerhet: Det er langt vanskeligere for en utenforstående å få tak i både en fysisk gjenstand og et passord, enn bare et passord.
Styrken til hver autentiseringsfaktor er avhengig av bl.a. hvordan utleveringen foregår og varighet på engangskoder.

*Vi støtter for øyeblikket primært LOA4 for ID-Porten når vi konfigurerer det via administrasjonsgrensesnittet. Selv om vi kan justere det manuelt i Keycloak (vår autensitesringsmegler), vil eventuelle konfigurasjonsendringer gjort via administrasjonsgrensesnittet overskrive disse endringene.

Det er faktisk å foretrekke å bruke tofaktorautentisering (2FA) via en app i stedet for SMS for Tellu-innlogging. Imidlertid kan ikke denne metoden forhåndsregistreres; brukerne vil sette den opp under sin første innlogging. SMS, selv om den er vanlig brukt, regnes ikke som fullstendig sikker for 2FA på grunn av sårbarheten for man-in-the-middle-angrep som muliggjøres av falske radiobase-stasjoner 

Fordeler:

• Reglene for autentisering (2FA-innstillinger, osv.) er fullstendig definert og konfigurert innenfor Tellucare. Dette betyr at Tellucare-administratoren kan definere og kontrollere autentiseringsreglene. Tellucare-administratoren kan aktivere eller deaktivere innlogging ved passord for en bruker.

• Varigheten på autentiseringssesjonen er definert og kontrollert i Tellucare, typisk satt til litt lenger enn det lengste skiftet for helsepersonell (anbefalt verdi er mellom 8 og 12 timer). Dette sikrer at helsepersonell kun trenger å autentisere seg en gang per skift.
• Tilbakestilling av legitimasjon og hjelp til brukerautentisering kan gjøres innenfor Tellucare ved hjelp av Administrator-rollen.
• Brukere kan alltid autentisere så lenge Tellucare er tilgjengelig, da denne metoden kun er avhengig av Tellucare.

Begrensninger:

• Tillater ikke Single-Sign-On (SSO) til andre applikasjoner på samme enhet.
• Tellucare-administratoren er fullt ansvarlig for å administrere brukere, deres autentiseringsmetoder og identitetsverifisering.

Styrken til hver autentiseringsfaktor er avhengig av bl.a. hvordan utleveringen foregår og varighet på engangskoder.

Når vil vi anbefale autentisering som er innebygd i Tellucare?

•    Dersom helsevirksomheten ønsker å ha kontroll over autentiseringsregler og varigheten av sesjonene i Tellucare, og samtidig sikre kontinuerlig tilgang uten å være avhengig av tredjepartstjenester.
•    Dersom helsevirksomheten ønsker å ha definert og kontrollert autentiseringssesjonsvarigheten.

Autentisering via en ekstern identitetsleverandør

Dette kan forenkle administrasjonen, bedre identitetsverifisering eller gi en SSO-opplevelse, men fordeler og ulemper avhenger av hvilken tredjeparts identitetsleverandør som brukes.

Fordeler:

• Reduserer Tellucare-administratorens ansvar ved å delegere autentisering til en ekstern plattform.
• Kan gi en sømløs SSO-opplevelse hvis andre applikasjoner også bruker samme eksterne identitetsleverandør.
• Kan tilby sterkere brukeridentitetsverifisering.

Begrensninger:

• Autentiseringsprosess og regler er ikke kontrollert av Tellucare-administratoren, men avhenger av reglene og innstillingene til den eksterne identitetsleverandøren.
• Varigheten på brukerens autentiserte sesjon avhenger av innstillingene til identitetsleverandøren.
• Brukere kan ikke bruke Tellucare hvis identitetsleverandørens plattform er midlertidig utilgjengelig.

Azure AD (administrert av kundens IT-organisasjon)

I kommuner er det vanlig at helsepersonell administreres av IT-organisasjonen gjennom et Microsoft Azure-abonnement. Denne Azure-kontoen kan brukes som en identitetsleverandør for tredjepartsapplikasjoner som Tellucare. For brukerne muliggjør dette en Single-Sign-On-opplevelse. Når man er logget inn på Azure, kan tilgang til andre applikasjoner gis sømløst uten å kreve en ny autentisering.

Fordeler:

• God og sømløs brukeropplevelse for personell med en Azure-konto, spesielt hvis flere applikasjoner er konfigurert for SSO via Azure AD.
• Administrasjon av brukeren av IT-avdelingen. Hvis en konto fjernes fra Azure AD, mister den tilsvarende brukeren automatisk tilgang til alle applikasjoner som delegerer autentiseringen til Azure AD.
• Automatisk brukersynkronisering er mulig for å gi tilgang til Tellucare for ansatte lagt til i Azure AD (SCIM-protokoll).

Begrensinger:

• Ikke alle ansatte som trenger tilgang til Tellucare, har en Azure-konto. Avhengig av kundens IT-prosedyrer, kan det hende at bare en del av Tellucare-brukerne har en Azure-konto (Azure-kontoer er en betydelig kostnad for helsevirksomheten).
• Å legge til brukere i Tellucare kan kreve en integrasjon via IT-organisasjonen. Dette kan være tidkrevende og urealistisk med tanke på den store omsetningen av midlertidige ansatte i sektoren.
• Standardvarigheten for en autentiseringssesjon via Azure AD er 90 dager. Dette er veldig praktisk for brukerne, men kan ikke møte sikkerhetskravene for kritiske applikasjoner som Tellucare. Dette er spesielt et problem hvis Azure-sesjonen er åpen på en ikke-sikret enhet eller en enhet som deles mellom flere ansatte.

Når vil vi anbefale autentisering ved bruk av Azure AD (administrert av kundens IT organisasjon)?

• Dersom at tjenesteutøvere ikke deler telefoner med andre kollegaer
• Dersom alle ansatte som trenger tilgang til Tellucare har en Azure-konto
• Dersom det er vanlig å dele telefonen med andre kollegaer og kunden har implementert en løsning som sikrer at både Tellu-sesjonen og den eksterne sesjonen avsluttes korrekt før telefonen blir overlevert til neste bruker.
• Dersom det er akseptabelt for kunden at tjenesteleverandøren må velge tjenesten hver gang de logger inn, ved å skrive inn navnet eller koden for å identifisere tjenesten de ønsker å bruke.

ID Porten (nasjonal identitetsleverandør)

ID Porten er den norske nasjonale plattformen for autentisering (lignende plattformer finnes i andre land, og lignende fordeler/ulemper gjelder). ID Porten er ment å brukes for å autentisere private personer. Det er ikke en gratis tjeneste, men den kan brukes gratis av offentlige organisasjoner (kommuner og sykehus). Den er normalt ikke ment for å autentisere ansatte i en profesjonell setting, men i praksis bruker kommuner den for å autentisere ansatte til mange tjenester.

Fordeler:

• Veldig enkel å bruke siden alle i Norge er kjent med ID Porten i sitt private liv.
• Brukernes identitet er offisielt verifisert gjennom ID Porten (autentisering nivå 4).
• SSO med andre applikasjoner som bruker ID Porten er mulig (men begrenset til ID Portens korte sesjonsvarighet).
• Kort autentiseringssesjonsvarighet (kun opptil 3 timer), kortere enn Tellucare-sesjonen (8 til 12 timer), sikrer at ny autentisering er nødvendig for hver nye Tellucare-sesjon.

Ulemper:

• Krever bruk av den ansattes private enhet (typisk for BankID på mobil) som kanskje ikke er akseptabelt.
• Ingen tilkobling til den ansattes IT-miljø eller brukerregister. Brukere må legges til og fjernes fra Tellucare med deres FNR (nasjonalt identifikasjonsnummer).

Delte enheter

Den største utfordringen med bruk av delte enheter er håndteringen av sesjons - å sikre at økter blir ryddet mellom brukere, slik at en bruker ikke får tilgang til pålogginger etterlatt av forrige bruker. Når du bruker en ekstern ID-leverandør som Azure AD, gjelder dette separat for Tellu-sesjon og Azure-sesjon.

Enhver organisasjon som ønsker å bruke Tellu-apper på delte enheter, må ha en løsning på plass for å sikre at både Tellu-sesjonen og eventuelle eksterne sesjoner avsluttes korrekt før telefonen overleveres til neste bruker. Dette er en oppgave som må implementeres av IT-organisasjonen på helsevirksomhetssiden, men Tellu er mer enn villige til å bistå med å velge den mest hensiktsmessige løsningen.

Autentisering i TelluCare Go

Tellucare Go (Tellus app for tjenesteutøvere) er en Android-applikasjon designet for å administrere pasientalarmer. Autentisering innen Tellucare Go håndteres gjennom en separat webkomponent innebygd i applikasjonen, som minimerer brukerinteraksjonen. Viktige innebygde funksjoner inkluderer støtte for push-varsler og bakgrunnsadministrasjon av geofence. Implementering av autentisering og sikkerhet i mobile apper er komplekst, og ressurser som OWASP Mobile Security Testing Guide tilbyr verdifulle innsikter og beste praksis.

Figuren nedenfor viser de viktige komponentene som er involvert i app-bruk.

For å diagnostisere eventuelle problemer med appen, er det viktig å forstå hvilke av disse komponentene som er involvert i den spesifikke funksjonaliteten som ikke fungerer som forventet.

Appen selv består av tre forskjellige komponenter. Hver av disse er ansvarlige for forskjellige skjermer i brukergrensesnittet, og hver kobler til en annen nettverkstjener i Tellu-systemet. Alle tre er essensielle for appfunksjonaliteten, og det er viktig å forstå forskjellen mellom dem. I tillegg kobler appen til noen tredjepartstjenester, som også er oppført nedenfor.

Native app

Den native app-komponenten er den første komponenten brukeren samhandler med ved første oppstart. Brukergrensesnittet til denne komponenten består av skjermer for å starte autentisering, velge helseleverandør og sjekke status og innstillinger.

Det er ingen tjenestefunksjonalitet i UI her, bare et rammeverk for å huse Responder-weben og samhandle med de native funksjonene til enheten. Brukere vil normalt bare se startskjermen med Logg inn-knappen fra denne komponenten. Den er ansvarlig for sesjonshåndtering, noe som betyr at den starter autentiseringsmeglerkomponenten for å få en autentiseringsnøkkel og deretter lagrer og oppdaterer denne nøkkelen til økten avsluttes ved utlogging. Også denne komponenten er ansvarlig for å samhandle med varslingsystemet, slik at Tellucares back-end kan sende varselsmeldinger til den mobile enheten. Hvis aktivert, kan den også gi posisjonssporing, samt sette geogjerder for utløsning i bakgrunnen når brukeren når stedet for en oppgave, og legge ut nærværsoppdateringer direkte til Tellucares back-end.

Ved oppstart kobler den til API-en på back-enden for å få en tjenestebeskrivelse, som gir adressene som trengs for de to andre komponentene. Produksjonsimplementeringsvert for dette er tellucare-api.tellucloud.com.

Tjenesteutøver-web

Alle brukergrensesnittene som sees innenfor Tellucare Go, men ikke eksplisitt nevnt for de to andre app-komponentene, tilhører Tjenesteutøver-webkomponenten. Dette er en webapplikasjon som vises av en webvisning inne i den native appen, og dette er hvor Responder-funksjonaliteten finnes. Denne webapplikasjonen kan også brukes direkte i en nettleser, men bruk av den native appen er nødvendig for å motta varsler til telefonen. Verts-URL-en er i form av <subdomene>.tellucare.no, med et helsevirksomhetsspesifikt subdomene.

Autentiseringsmegler (Keycloak)

Bruk av Tellucare API og web krever en autentiseringsnøkkel som identifiserer brukeren og hva de har tilgang til. Nøkler tilbys av en autentiseringsmegler (Keycloak), som er en separat tjeneste med separat nettverksdomene: tellucare-id.tellucloud.com. Inn- og utlogging gjøres gjennom et webgrensesnitt levert av denne verten (eller en tredjeparts autentiseringstjeneste det videresendes til). Autentiseringsbrukergrensesnittet leveres av megleren og ikke av den native appen, fordi den kan videresende til andre autentiseringsmeglere, som ID-porten og Azure AD, som vanligvis krever tofaktorautentisering. Og dette webgrensesnittet er ikke integrert i den native appen av sikkerhetsmessige årsaker. Dette følger gjeldende sikkerhetsmønstre der en app aldri bør ha tilgang til brukerens legitimasjon. Mer spesifikt gjøres dette på Android med en funksjon kalt "Egendefinerte faner", der et vindu tilhørende enhetsleseren brukes i kontekst av en app og uten å gi brukeren full nettleser-UI. Hvis en ekstern ID-leverandør brukes, som ID-porten eller Azure AD, må også denne verten være tilgjengelig på nettverkstilkoblingen. Mens brukeren bare samhandler med autentiseringsmegleren for å logge inn eller ut, må appen samhandle med autentiseringsmegleren regelmessig for å oppdatere nøkler.

Veiledende vurdering av autentiseringsfaktorer for Tellucare Go

Tellucare Go er primært bruk av rollen tjenesteutøvere. Tellu vurderer følgende alternativer som tilstrekkelig sikre for tilgang til Tellucare Go i henhold til Personopplysningsloven, relevant helselovgivning og anbefalinger i Normen.

Alternativer	Autentiseringsnivå
Alt a) Personlig brukerkonto	juridisk person (fnr), autentisering på nivå PKI Person HØY (LOA4) vha. ID-porten (BankId, BankId for Mobil, Buypass, Buypass for Mobil, Commfides) – personlig e-id må benyttes
Alt b) Personlig brukerkonto (SMS)	juridisk person (fnr), autentisering på nivå PKI Person Standard (LOA3) vha. ID-porten (MinID via SMS – personlig mobiltelefon må benyttes)
Alt c) Personlig brukerkonto	kommunal identitet (brukernavn), autentisering med høy sannsynlighet (LOA3) vha. brukernavn/passord og forhåndsregistrert IPadresse 7

 

Veiledende vurdering av autentiseringsfaktorer

For tilgang til Tellucare vurderer Tellu følgende alternativer som tilstrekkelig sikre jfr. Personopplysningsloven, relevant helselovgivning og anbefalinger i Normen

For Administrator:

Administrator har tilgang til spesiell funksjonalitet blant annet for å administrere samtykker og brukerkontoer. Tilgangen bør være uavhengig av tilgang til lokasjon for å sikre tilstrekkelig tilgjengelighet bla for å kunne utføre konsekvensreduserende tiltak, ref. risikomatrise.

• Personlig brukerkonto – juridisk person (fnr), autentisering på nivå PKI Person HØY (LOA4) vha. ID-porten (BankId, BankId for Mobil, Buypass, Buypass for Mobil, Commfides).
• Personlig brukerkonto – kommunal identitet (brukernavn), autentisering med kommunens AD satt opp med 2FA

For tjenesteutøvere:

• Alt a) Personlig brukerkonto – juridisk person (fnr), autentisering på nivå PKI Person HØY (LOA4) vha. ID-porten (BankId, BankId for Mobil, Buypass, Buypass for Mobil, Commfides) – personlig e-id må benyttes.
• Alt b) Personlig brukerkonto – juridisk person (fnr), autentisering på nivå PKI Person Standard (LOA3) vha. ID-porten (MinID via SMS – personlig mobiltelefon må benyttes)
• Alt c) Personlig brukerkonto – kommunal identitet (brukernavn), autentisering med høy sannsynlighet (LOA3) vha. brukernavn/passord og forhåndsregistrert IP-adresse
• Alt d) Personlig brukerkonto – kommunal identitet (brukernavn), autentisering med kommunens AD satt opp med 2FA

For tilgang til Tellucare vurderer Tellu følgende alternativer som mindre sikre enn anbefalinger i Normen.

For Administrator:

• Alle andre beskrevne enn alternativet for Administratorer over.

For Operatører

• Alt e) Personlig brukerkonto – kommunal identitet (brukernavn), autentisering med middels sannsynlighet vha. brukernavn/passord (LOA2)
• Alt f) Upersonlig brukerkonto – ingen identitet, autentisering med middels sannsynlighet vha. delt Telenor brukernavn/passord og forhåndsregistrert IP-adresse (LOA1)
• Alt g) Upersonlig brukerkonto – ingen identitet, autentisering med lav sannsynlighet vha. delt Telenor brukernavn/passord (LOA1)

Fast offentlig IP-adresse som autentiseringsfaktor

Dersom fast offentlig IP-adresse skal benyttes som autentiseringsfaktor er det helsevirksomhetens ansvar å vurdere styrken ved denne. Tellu har følgende veiledende kriterier for vurdering:

Alt 1) Fast offentlig IP-adresse tildelt brukere av internt fastnett eller intern Wifi på institusjon eller annet lokale

• Grunnleggende Wifi-sikkerhet er helsevirksomhetens ansvar. Se f.eks. Normens faktaark nr 26 Sikring av trådløs teknologi
• Wifi skal ha tilstrekkelig tilgangskontroll (f.eks. WPA2 med tilstrekkelig kryptering og sterkt passord, radiusserver eller andre tiltak)
• Offentlig IP-adresse skal kun tildeles klienter innenfor denne fysiske lokasjon (fast nett eller intern wifi) og ikke kunne tildeles klienter ved andre lokasjoner
• Offentlig IP-adresse skal kun tildeles autoriserte personer/enheter, ikke tildeles brukere av gjestenett etc.

Alt 2) Fast offentlig mobil IP-adresse tildelt igjennom helsevirksomhetens kommunikasjonsleverandør

• Tilgangskontroll og autorisasjon tilsvarende for internt fastnett eller Wifi

Alt 3) Fast offentlig mobil IP-adresse tildelt igjennom Tellu Velferdsteknologi APN

• Tellu vurderer IP-adressen som tilstrekkelig sikker autentiseringsfaktor.
• Dette er en tilleggstjeneste som ikke inkludert i TelluCare standardtjenesten fra Tellu

Risikovurderinger

Helsevirksomhet er ansvarlig for endelig risikovurdering og valg av autentiseringsmekanismer blant alternativene listet opp under 3.Veiledende vurdering av autentiseringsmekanismer. Dette inkluderer å ta hensyn til aspekter som brukervennlighet og tilgjengelighet i den aktuelle brukssituasjon.

Autentisering av operatører ved bruk av ID-portens e-id alternativer kan oppleves som tungvint og lite fleksibelt, spesielt med tanke på gjenglemt bærer (kodegenerator, personlig mobil o.l.). Dette kan medføre høyere operasjonell risiko enn ønskelig.

Tellu vurderer at for operatører kan tilstrekkelig sikkerhet oppnås med kommunal identitet (brukernavn) og tilstrekkelig strenge autentiseringsfaktorer. Autentisering som juridisk person er ikke nødvendig dersom tilgangen til autentiseringsfaktorene gis basert på et konkret ansettelsesforhold og det er arbeidsgiver som administrerer brukerkontoene.