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 ä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.
...
Detta kan synliggöras genom att exempel ställa upp värdena i en matris med konfidentialitet och riktighet på axlarna.
...
Exempel 1: Summan av konfidentialiteten och riktigheten utan särskild viktning, där det högsta värdet styr utfallet.
| K/R | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| 4 | 4 | 4 | 4 | 4 |
| 3 | 3 | 3 | 3 | 4 |
| 2 | 2 | 2 | 3 | 4 |
| 1 | 1 | 2 | 3 | 4 |
'
...
Det första exemplet med summerat värde har en svaghet i att ett högt värde i kombination med ett lågt värde ger ett lägre utfall och det är därmed rimligare att det högsta värdet sätter utfallet enligt det andra exemplet. 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.TLDR; paketering av krav och säkerhetsåtgärder bör ske i förhållande till ett utfall på skalan 1-4 där verksamhetens information avseende det högsta värdet av konfidentialitet eller riktighet (vid förändring av informationen) ligger 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ägare 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. Exmpelvis 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å.
...saknas nivåer eller ens en nivå av tillit och krav kopplat till behörighetsinformation
...ta med de olika parterna som samverkar kring tilliten (adm-katalog, katalog, avsändare/intygare, ev förmedlande parter i en kedja etc.)
Level of trust (LoT)
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
...
...
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
Det har diskuterats en alternativ underliggande modell där tillitsmärken är per komponent och tillitsnivå är |
|---|
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å?
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
| Level of Trust | Vad innebär det? | När ska man kräva det ? | LoT0 | Inga krav alls. Avsaknad av tillitsmärke. | LoT1 | Inga större krav på att identitet och åtkomststyrande attribut är korrekta | LoT2 | LoT3 | LoT4 | Jobbiga krav: 27001, Nycklar i HSM, beväpnade vakter, osv | 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.
| Status | ||||||
|---|---|---|---|---|---|---|
|
- 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 |