När olika parter ska utbyta information är det ofta relevant att säkerställa vem man pratar med, från båda sidor sätt. Vidare att den man utbyter information med har den behörighet som krävs för att få åtkomst. Traditionellt eller historiskt sätt finns det ofta lokala behörighetskataloger i olika former med replikerad eller lokalt hanterad information, likaså att man "loggar in" i det system som man avser att ha tillgång till. I ett mer federativt ekosystem så loggar man in i sin egen information, behörigheten administreras i stor även inom den egna organisationen och dessa förmedlas vid anrop (som användare eller som systemanvändare) som ett behörighetsunderlag som beslut om åtkomst kan utgå från.

I en sådan förmedling är det viktigt att det finns tillit till behörighetsunderlaget, med olika nivåer för att inte driva mer långtgående krav än vad som är adekvat på en viss nivå. Signalering av förväntad nivå av tillit avseende behörighetsunderlaget sker med hjälp av tillitsmärken där Ena (läs: Digg som ledningsaktör) är ägare av dessa märken. De partar som bidrar direkt till underlaget eller förmedlar eller på annat sätt bearbetar eller hanterar underlaget behöver även omfattas av krav kopplat till tilliten.

Grundläggande faktorer som är viktiga kopplat till arbetet:

• Bred återanvändning av gemensamma LoT-märken oavsett tillämpningar/sektorer/domäner eller typen av information.
  • Generella och med en gemensam grund som alla kan acceptera och känna igen sig i
• Aktiv vidareutveckling och förvaltning av märken och dess krav
  • När nya parter ansluter kan det komma nya krav eller upptäcker som föranleder ändringar i den gemensamma grunden.
  • Säkerhet eller snarare hot mot är under ständig förändring och därmed behöver en aktiv livscykelhantering finnas för att möte upp mot det.

Gemensam grund att utgå från vid framtagande av tillitsmärken 

Informationssäkerhet

Informationssäkerhet handlar om att förhindra att information läcker ut, förvanskas och förstörs. Det handlar också om att rätt information ska finnas tillgänglig för rätt personer, i rätt tid. Det är normalt sätt informationsägaren som värderar eller klassar sin information och informationsbehandlande resurser utifrån olika skyddsvärden och därmed även identifierar säkerhetskrav. Myndigheten för samhällsskydd och beredskap (MSB) har bland annat ett metodstöd för att klassificera informationstillgångar som exempelvis på en fyrgradig skala klassificerar utifrån konfidentialitet, riktighet och tillgänglighet och för fortsatt resonemang kommer detta metodstöd att ligga till grund.

Identitet och behörighet inom Ena är inte en del av den ursprungliga klassningen utan snarare en säkerhetsåtgärd, med det är rimligt att anta att en given klassning har likvärdiga nivåer på åtgärder och att identitet och behörighet skulle kunna skapa mer generella paketeringar som då antas motsvara en viss klassning, alternativt utgöra en bra grund. Det vill säga att utifrån en klassning av en verksamhets information faller säkerhetsåtgärder eller krav ut, identitet och behörighet skulle genom olika paketering möta upp mot dessa krav. En positiv effekt av detta skulle även kunna vara samverkan runt olika paketeringar som långsiktigt även skulle kunna verka generaliserande och normerande.

Vidare är det huvudsakligen områdena konfidentialitet (behörighet att ta del) och riktighet (inte kunna förändras av obehöriga) som identitet och behörighet aktivt medverkar till att lösa delar av, även om tillgängligheten är viktig så är det snarare ett krav som verksamhetssystemet eller andra nyttjare ställer på tillämpningen av identitet och behörighet och inte en aktiv del av lösningen i den bemärkelsen. Likheterna mellan konfidentialitet och riktighet avseende identitet och behörighet är att på en stigande skala ökar behovet av att säkerställa vem eller vad det är som har åtkomst till, eller förändrar informationen.

Detta kan synliggöras genom ställa upp värdena i en matris med konfidentialitet och riktighet på axlarna, där det högsta värdet styr utfallet.

Det vill säga att när antingen konfidentialiteten eller riktigheten överstiger ett visst värde så faller likvärdiga krav och säkerhetsåtgärder ut kopplat till identitet och behörighet.

https://metodstod-informationssakerhet.msb.se/globalassets/exempel-pa-matris-med-konsekvenskriterier-och-konsekvensnivaer-for-riskanalys.png

Identitet

Inom området identitet finns det redan etablerad standard som Myndigheten för digital förvaltning (Digg) tillhandahåller, Svensk e-legitimation. Nedan följer ett citat från digg.se:

Tillitsramverket för Svensk e-legitimation syftar till att etablera gemensamma krav för utfärdare av Myndigheten för digital förvaltning (Digg) granskade och godkända e-legitimationer. Kraven är fördelade på olika skyddsklasser – tillitsnivåer – som svarar mot olika grader av teknisk och operationell säkerhet hos utfärdaren och olika grader av kontroll av att den person som tilldelas en elektronisk legitimationshandling verkligen är den han eller hon utgett sig för att vara.

De olika tillitsnivåerna som återfinns inom tillitsramverket är på en fyrgradig skala med tillägg för icke bofasta för nivåerna två och uppåt. Även om icke bofast signaleras så är krav och kravuppfyllnad motsvarande och det är huvudsakligen tillvägagångssättet som skiljer sig och exempelvis möjligheten att representeras med exempelvis svenskt personnummer.

Det finns även möjlighet att signalera "uncertified" för nivåerna två och tre, vilket då innebär att man inte har genomgått en granskning utan att tillhandahållaren genomför en självskattning hävdar att relevant nivå är uppfylld.

 ? eIDAS High för hälsodata och att motsvarigheten då är nivå 4 med viss utökning...

Utöver e-legitimation som identifierar individer behövs det även stöd för att identifiera system eller tjänster hos en organisation när det inte är individen som har åtkomst, eller när kännedom om individen inte är relevant. 

TODO Finns behov av att kunna identifiera system eller tjänster på ett säkert och motsvarande sätt som för individer.

Behörighet

För att en informationsägaren ska kunna ta beslut om åtkomst till informationen krävs normalt som grund identiteten (vem) på den eller det som begär åtkomst. Utöver identitet kan andra egenskaper behöva förmedlas. det kan då vara egenskaper som hör till utbildning, anställning eller situation. För system eller tjänster får man tänka om begreppen, då anställning snarare motsvarar driftsatt eller installerad, men att man i grunden har en relation till organisationen och representerar den i vissa avseenden.

Ett tillitsmärke för behörighet bör användas för att uppvisa graden av tillit eller korrekthet av den information som förmedlas, där underlag från autentisering i form av identitet även kan förmedlas. Exempelvis skulle man kunna likställa genomförd autentiseringen och dess identitet som en "attributkälla" motsvarande andra attribut eller egenskaper som kläs på.

Level of Trust (LoT)

Level of Trust (LoT) eller nivå av tillit avser att beskriva olika nivåer av tillit kopplat till information som ligger till grund för ett åtkomstbeslut och förmedlas inom ramen för Ena Identitet & behörighet med tyngdpunkt på den senare. Det vill säga att Level of Trust (LoT) kompletterar befintliga tillitsnivåer för autentisering, exempelvis Level of Assurance (LoA), genom att det istället handlar om att säkert förmedla information från autentisering (ex identitet) vidare inom ramen för behörighet och åtkomstbeslut.

Modell/struktur för de gemensamma tillitsmärken

Det finns i nuläget huvudsakligen tre olika förslag på modell eller struktur på tillitsmärken, de beskrivs mer ingående under respektive avsnitt:

• Förslag #1 - Avsnitt 2.1.1 - Samtliga egenskaper kombineras till ett märke
  • Exempelvis en UTFÄRDARE på en LoT-2 skulle då få ett märke enligt UTFÄRDARE_LoT-2
  • Öppen fråga: Kan det finnas ett märke eller anslutning som UTFÄRDARE utan att ha gemensam LoT-nivå. Ska det då symboliseras genom LoT-0? Eller bara genom UTFÄRDARE (och rimligen då kompletteras med annat TM enligt Förslag #2 eller driva att samma modell lämpligen används även vid utökade eller specifika tillämpningar)
  • Antagande att vissa typer inte har nivåer, utan endast en: att förmedla LoT-<X> oavsett nivå.
• Förslag #2 - Avsnitt 2.1.2 - Separata märken för typ och nivå
  • Exempelvis en UTFÄRDARE på LoT-2 skulle då få ett märke enligt UTFÄRDARE + LoT-2
  • Öppen fråga: Blir det mer komplicerat att applicera krav och förstå vad som gäller?
• Förslag #3 - Avsnitt 2.1.3 - Utökning av specifikationen för Trust Mark (TM) så att det innehåller attribut som bär ex nivå

De olika förslagen behöver analyseras mer utifrån flera perspektiv:

• Går det att förstå modellen, dvs kan den kommuniceras på ett bra sätt?
• Kan kraven delas upp på ett bra sätt, utan överlapp etc?
• Går den att bygga vidare på?
• etc...

Förslag #1 - Samtliga egenskaper kombineras till ett märke

Ref: ena-authorization/tillitsmodell/arkitekturell_modell.md at tillitmodell · diggsweden/ena-authorization

Varje specifikt tillitsmärke har följande egenskaper:

1. det gäller en specifik komponenttyp
2. det ger en viss nivå av tillit (Level of Trust)
3. det omfattar ett visst urval av krav från den gemensamma kravkatalogen
4. det har ett regelverk för hur uppfyllande av tillitsmärkets krav ska kontrolleras

Grafiskt kan detta presenteras på två olika sätt:

Ref: https://samarbeta.digg.se/index.php/f/161796

Den övre bilden detaljerar att det finns totalt 4 x 4 = 16 tillitsmärken, medan den undre bilden döljer det faktum att det finns 16 märken och endast beskriver modellen konceptuellt. Detta för att förtydliga att en specifik samverkan ställer krav på tillitsnivå och att detta då gäller alla inblandade komponenter.

Modell - Separata märken för typ och nivå 

En tanke var att det är olika tillitsmärken för "level_of_trust" och den typ av komponent/organisation som är med i den federativa tillvaron. Exempelvis ligger skillnaden då i om en "intygsutfärdare" antingen har TM_intygsutfärdare-LoT<1-4> eller TM_intygsutfärdare + TM_LoT<1-4>.

Oavsett lösning/modell så görs antagandet att det inte är alla komponenter som ingår i kedjan som behöver separata nivåer, det är rimligt att anta att den part som är källa eller garant för informationen behöver uppvisa nivå av "tillit", men att andra parter som förmedlar informationen endast behöver generella krav kopplat till förmedling avseende icke spridning, incidenter, PU etc...vilket då bör vara lika oavsett nivå på tillit. (då det är informationen som sådan som bör reglera detta, och inte korrektheten på den...)

Det vill säga att för att vara en förmedlande komponent så finns det grundkrav kopplat till "typen" och inte ett behov av att skala ut "LoT" i hela kedjan.

Exempel på konceptet för modellen enligt nedan bild: (om specifika krav för ett visst funktionsobjekt behövs kan typerna behöva skala ut så att ex utfärdare och hantering separeras/delas upp, men att permutationen av typ och nivå definierar antal märken är fortfarande skillnaden mot modellen enligt 2.1.1)

Modell - Utöka standarden för Trust Mark med egna attribut

Tillitsnivåer

Vad innebär det att en komponent är innehavare av ett tillitsmärke på en viss tillitsnivå? 

Vi utgår ifrån MSB:s stöd för informationsklassning (Ref: Klassningsmodell, MSB) och väljer att basera våra tillitsnivåer på stödet "Klassningsmatris A - Fyra nivåer".

Not: Klassa som kommuner använder har en skala på 1-3 och på 4 faller säkerhetskyddsklassificerad information ut. Det vill säga en tre-gradig skala

Tanken är sedan att en tillämpning som kräver en viss tillitsnivå kräver att alla komponenter som ingår i tillitskedjan har Ena tillitsmärke på minst den tillitsnivån.

ANTAGANDE:Att befintliga implementationer på ett generellt plan inom hälsa- vård och omsorg i dag ligger på en motsvarande LoT-3 och bör hamna där inom Ena. Med utrymme att i specifika fall, eller specifika tillämpningar där åtkomsten är bred kan kvalificera sig till LoT-4, vidare även kopplingar till eIDAS/HIGH etc.

Berörda tillitsskapande objekt eller funktioner

Nedan diagram visar på de olika tillitsskapande objekt eller funktioner samt om de är direkt involverade i auktorisationsflödet och om de bidrar genom att förmedla information eller om den är avsändare av eller källa till informationen. Eftersom information inte bara uppstår av sig själv behöver den tillitsskapande funktionen som introducerar den i ekosystemet även ta ansvar för den, ur det perspektivet är den källa eller ansvarar för informationen motsvarande en källa till den.

ANTAGANDE: 

• Att avsändarna eller källorna (blåa) behöver ha tillitsmärken på olika nivåer. (LoT-<1-4>)
• Att förmedling/hantering inte kräver särskilda nivåer, utan ett gemensamt tillitsmärke som medger förmedling eller hantering av förmedlad information oavsett LoT-nivå.
  • Om vi vidare antar att det i grunden kan vara personuppgifter som förmedlas och att LoT medger nivån av tillit till informationen, så påverkar inte tilliten i sig hur den ska hanteras. Det går dock att argumentera för att åtkomster som kräver en högre tillit ger allvarligare konsekvenser och därmed kan det finnas det ett ökat skyddsbehov.

Hur kan tillitsmärken nyttjas till fler saker?

Tillit är subjektiv och uppstår ofta lokalt mellan parter som har en befintlig relation. Vad vi gör inom Ena är att försöka skapa en modell och ett ramverk som gör att tillit kan uppstå till parter man inte har en relation med sedan tidigare. Man behöver dock inte begränsa användandet av tillitsmärken utan man kan tillåta skapandet av lokala tillitsmärken för att markera lokal tillit.

1. Tillitsmärken som representerar externt reglerad avtalsrelation. Man skulle till exempel kunna tänka sig skapa tillitsmärken för Nationella läkemedelslistan:
   1. NLL Klient - komponent godkänd att koppla upp sig mot NLL API i syfte att visa information för invånare.
   2. NLL Vårdgivare - komponent godkänd för att koppla upp sig mot NLL API i syfte att skapa recept, samt visa information för vårdmedarbetare.
   3. ...
2. Tillitsmärken som representerar lokal tillit inom ett visst samverkanskontext där åtkomst inte bestäms regelstyrt baserat på klientegenskaper utan explicit till specifika klienter.
3. ...

Tillitsmärken