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
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:
...
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:
...
- 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
...
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>.
...
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
Det har diskuterats en alternativ underliggande modell där tillitsmärken är per komponent och tillitsnivå är ene en egenskap hos tillitsmärket. Enligt OpenID Federation och deras definition och användande av tilliitsmärken (ref: https://openid.net/specs/openid-federation-1_0.html#name-trust-marks) skulle detta kunna representeras av att vi inom Ena Federation adderar ett claim "level_of_trust" till våra trust mark claims till de tillitsmärken där vi vill kunna signalera olika tillitsnivåer. Huruvida detta är en bra lösning för våra behov kvarstår att diskutera både internt inom arbetsgruppen och även med OIDF-expertis. Framförallt att man då ställer krav på alla komponenter som ingår i en tillitskedja att verifiera värdet av level_of_trust som en del av valideringen. |
---|
Tillitsnivåer
Vad innebär det att en komponent är innehavare av ett tillitsmärke på en viss tillitsnivå?
...
Level of Trust | När ska man kräva det och vad innebär det? | ||||||||
---|---|---|---|---|---|---|---|---|---|
LoT-1 | Tillräcklig tillitsgrundande förmåga hos komponenten för att tillåta samverkan där grad av konsekvens av brist på riktighet är högst R1 och brist på konfidentialitet är högst K1 Konsekvenser som ligger på försumbar skada. | ||||||||
LoT-2 | Tillräcklig tillitsgrundande förmåga hos komponenten för att tillåta samverkan där grad av konsekvens av brist på riktighet är högst R2 och brist på konfidentialitet är högst K2. Konsekvenser som ligger på måttlig skada. | ||||||||
LoT-3 | Tillräcklig tillitsgrundande förmåga hos komponenten för att tillåta samverkan där grad av konsekvens av brist på riktighet är högst R3 och brist på konfidentialitet är högst K3. Konsekvenser som ligger på betydande skada. | ||||||||
LoT-4 | Tillräcklig tillitsgrundande förmåga hos komponenten för att tillåta samverkan där grad av konsekvens av brist på riktighet är högst R4 och brist på konfidentialitet är högst K4. Konsekvenser som ligger på allvarlig skada.
För systemanvändare .... |
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.
...
Status | ||||||
---|---|---|---|---|---|---|
|
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.
...
- 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.
- Tillitsmärken som representerar externt reglerad avtalsrelation. Man skulle till exempel kunna tänka sig skapa tillitsmärken för Nationella läkemedelslistan:
- NLL Klient - komponent godkänd att koppla upp sig mot NLL API i syfte att visa information för invånare.
- 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.
- ...
- 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.
- ...
Tillitsmärken
Tillitsmärke | LoT | Beskrivning | Motivering |
---|---|---|---|
Klient | LoT1 | ||
LoT2 | |||
LoT3 | |||
LoT4 | |||
Legitimering | LoT1 | ||
LoT2 | |||
LoT3 | |||
LoT4 | |||
Åtkomst | LoT1 | ||
LoT2 | |||
LoT3 | |||
LoT4 | |||
API | LoT1 | ||
LoT2 | |||
LoT3 | |||
LoT4 |