Den tidigare arbetsytan för Tillitsstruktur som låg här har flyttas till Leveransteam Tillitsstruktur.
Tanken är att vi här istället dokumenterar resultatet av arbetet, det vill säga själva leveransen.
Inledning
När två parter behöver utbyta information är det ofta krav på att respektive sida behöver säkerställa att motparten är den den utger sig att vara, och att denne är behörig att ta del av den information som delas. Det är informationsägaren som ansvarar för säkerställa att man är behörig innan informationen kan lämnas ut. I dessa fall krävs det säkerställd information om vem organisationen, systemet och/eller individen som begär åtkomst är, samt vad som berättigar åtkomsten . Exempelvis kan organisationen vara en myndighet, region, eller kommun, och användaren agerar utifrån ett tilldelat uppdrag. Det kan också ställas krav på att användaren har en specifik kvalifikation, eller agerar i en legitimerad yrkesroll. Man kan förenklat säga att det är en skala från inget behov alls till hög tillförlitlighet till underlaget som ger behörighet. Var på skalan man är för en specifik åtkomst står normalt i direkt proportion till informationens känslighet.
Inom ramen för detta dokument beskrivs ett ramverk för att ge tillit till att förmedling och hantering av identiteter och behörighetsgrundande information sker på ett säkert sätt. Ramverket ska minimera risken för obehörig åtkomst till information. I dagens komplexa samverkan, där man ofta behöver hämta och behandla information från flera parter för att stödja verksamhetsbehov, behöver också tilliten upprätthållas i flera led mellan alla parter som tar fram det underlag som behövs för åtkomstbeslut. För att möjliggöra korrekta åtkomstbeslut krävs att tillit kan skapas till alla inblandade parter och komponenter - detta är målet med Enas tillitsramverk.
Drivkrafter och principer
- Ramverket ska skapa en struktur för bred återanvändning av gemensamma, generella och överenskomna nivåer av tillit.
- Oavsett tillämpningar/sektorer/domäner eller typen av information.
- En gemensam grund som alla kan acceptera och känna igen sig i.
- Ramverket ska möjliggöra aktiv vidareutveckling och förvaltning av tillitsmärken
- När digitala tjänster med krav som skiljer sig avsevärt från andras, ska det gå att ta fram nya tillitsmärken inom ramverket.
- När nya säkerhetsambitioner, eller nya säkerhetshot, uppkommer ska ramverket stödja aktiv livscykelhantering för existerande tillitsmärken.
- Det ska vara lätt för befintliga digitala tillämpning i samhället att relatera till Ena tillitsramverk och se eventuella förflyttningar som krävs för att kunna erbjuda tillämpningar inom Ena.
Summering
TODO Lyfta olika delar från 2.x som en summering av förslaget hit.
Förslag på tillitsmodell
Den föreslagna modellen utgår ifrån att de olika komponenter som deltar i en samverkan med utbyte av skyddsvärd information, bidrar med olika förmågor vid hantering av metadata, identiteter och behörighetsgrundande information. En grundsten i modellen är tillitsmärken som signalerar tillit och tilldelas komponenterna efter att specifika krav kopplade till tillitsmärket är uppfyllda. Vilka tillitsmärken som en komponent behöver beror på vilka förmågor som den realiserar.
IAM-förmågor
En IAM-förmåga innefattar här både en tekniska förmåga inom identitets- och behörighetsområdet och de verksamhetsprocesser som behövs för att upprätta och underhålla förmågan. IAM-förmågor realiseras av specifika tekniska komponenter och fungerar som byggstenar för tillit vid samverkan som kräver säker hantering av identiteter och åtkomstbeslut.
I modellen som visas i nedanstående bild och efterföljande tabell beskrivs de olika typer av tekniska komponenter och vilka IAM-förmågor som de realiserar.
TODO Intygsutfärdade => Intygsutfärdande i bilden | Betrodd metadatapublicering => Metadatapublicering
Komponent | Beskrivning | IAM-förmåga | Beskrivning |
---|---|---|---|
Tillitsankare | Ett Tillitsankare är en komponent som utgör den yttersta källan till tillit i en federationsinfrastruktur och publicerar signerad metadata som omfattar godkända underordnade entiteter, som tex Anslutningspunkter och Tillitsmärkesutfärdare. | Metadatapublicering | Metadatapublicering är en IAM-förmåga som innebär att en komponent på ett kontrollerat, säkert och tillförlitligt sätt publicerar signerad metadata om sig själv – och i vissa fall även om andra entiteter – inom ramen för en federation. Publiceringen sker för att möjliggöra teknisk tillit, interoperabilitet och korrekt tolkning av entitetens roll och kapacitet i federationen. Den metadata som publiceras kan inkludera:
Funktionen är central för att federationens övriga parter ska kunna validera, lita på och kommunicera med komponenten på ett säkert sätt. I vissa fall sker metadatapubliceringen via en federationens gemensamma tjänst (t.ex. via ett tillitsankare), i andra fall genom egen publicering och signering |
Anslutningspunkt | En Anslutningspunkt är en mellanliggande komponent i federationsinfrastrukturen som publicerar signerad metadata för underordnade entiteter som tex Legitimeringstjänster, Auktorisationstjänster, E-tjänster och API:er | ||
Tillitsmärkesutfärdare | En Tillitsmärkesutfärdare är en komponent i federationsinfrastrukturen som utfärdar tillitsmärken till entiteter som uppfyller definierade krav kopplade till specifika IAM-förmågor. | ||
Uppslag och verifieringstjänst | En Uppslag- och verifieringstjänst är en komponent i federationsinfrastrukturen som används för att slå upp, hämta och verifiera metadata för andra entiteter inom en federation. | Metadatavalidering | Metadatavalidering är en IAM-förmåga som innebär att en komponent kan hämta, tolka och kryptografiskt verifiera signerad metadata från andra entiteter inom en federation. Denna förmåga är avgörande för att säkerställa att tilliten mellan parter i federationen är tekniskt grundad och uppdaterad. Funktionen omfattar flera moment:
Metadatavalidering skapar teknisk tillit genom att identifiera och autentisera entiteter innan någon interaktion sker, och används som grund för vidare beslut inom t.ex. intygsförfrågningar och åtkomstkontrol |
Legitimeringstjänst | En Legitimeringstjänst är en komponent i federationsinfrastrukturen som ansvarar för att autentisera en användare | Intygsutfärdande | Intygsutfärdande är en IAM-förmåga som innebär att en komponent på ett tillförlitligt och säkert sätt kan skapa och leverera digitalt signerade intyg. Dessa intyg innehåller påståenden om en användare eller klient, exempelvis vilken nivå av autentisering som har genomförts, vilka attribut som är giltiga och aktuella, eller vilka åtkomsträttigheter användaren är tilldelad. Funktionen utgör en kärna i federativ åtkomsthantering, där beslut om åtkomst ofta baseras på dessa intyg. Förmågan inkluderar inte enbart den tekniska akten att signera data, utan även processer för att säkerställa:
|
Auktorisationstjänst | En Auktorisationstjänst är en komponent som beslutar om och utfärdar information om användares åtkomsträttigheter till digitala resurser, baserat på tillgänglig identitets- och attributinformation. | ||
Attributkälla | En Attributkälla är en komponent som tillhandahåller information om användare, exempelvis roller, organisatorisk tillhörighet eller andra behörighetsgrundande attribut. | Attributhantering | Attributhantering är förmågan att säkert förvalta, kvalitetssäkra och tillgängliggöra användarattribut som används för identitets- och åtkomstbeslut. |
Åtkomstkontroll | Åtkomstkontroll är förmågan att fatta och tillämpa beslut om en användares rätt att få tillgång till en viss digital resurs, baserat på tillgänglig identitets- och behörighetsinformation. | ||
TODO sammanfoga med cellen ovan (tabellformatet blir helt fel när jag testar) | |||
Resurs Server (API) | En Resursserver är en komponent som tillhandahåller åtkomst till skyddade digitala resurser, och som kontrollerar åtkomst baserat på presenterade intyg eller behörigheter. | ||
E-tjänst | En E-tjänst är en webbaserad applikation som erbjuder funktionalitet till användare, ofta via en webbläsare. | ||
Klient | En Klient är en fristående applikation eller serverprogramvara som agerar å användarens vägnar, ibland även utan direkt användarinteraktion. | Åtkomstbegäran TODO sammanfoga med cellen ovan (tabellformatet blir helt fel när jag testar) | Här, en begäran om identitet- eller åtkomstintyg, innehållande avsett syfte med intyget, samt underlag för begärans behandling och för intygets utformning. |
Tillitsmärken
Att en teknisk komponent tilldelas ett tillitsmärke innebär att komponenten (och den organisation och verksamhet som ansvarar för komponenten) uppfyller de krav som krävs för att på ett tillitsfullt sätt kunna utföra eller erbjuda IAM-förmågor. För viss samverkan via digitala tjänster kan det finnas informationssäkerhetskrav som föranleder mer omfattande tillitskrav och detta tänker vi oss ska representeras av nivåindelad tillitsmärkning.
Det finns två olika modeller för hur man kan kombinera tillitsmärken och tillitsnivåer. Antingen har man fristående tillitsmärken för tillitsnivån komponenter erbjuder, eller så har man nivåspecifika tillitsmärken för varje IAM-förmåga. Då vi strävar efter en så enkel modell som möjligt att hantera och administrera för parterna förordar vi i dagsläget fristående tillitsmärken för tillitsnivåer. Vi ser vidare att specifika tillitsmärken endast behövs för att deklarera en specifik (högre) tillitsnivå för hos de komponenter som tillför behörighetsgrundande information och inte för de som endast hanterar existerande information.
Vi föreslår således tillitsmärken som mappar emot tekniska komponenter enligt nedanstående bild och tabell.
TODO IAM-förmåga nästan samma sak som Tillitsmärke, dvs LoT-Utfärdare = IAM-förmåga Intygsutfärdare, LoT-hantering = IAM-förmåga Åtkomstkontroll och åtkomstbegäran. osv ...
Komponent | Tillitsmärken |
---|---|
Legitimeringstjänst | Ena Utfärdare, Ena LoT-1, Ena LoT-2, Ena LoT-3, Ena LoT-4 |
Auktorisationstjänst | Ena Utfärdare, Ena LoT-1, Ena LoT-2, Ena LoT-3, Ena LoT-4 |
Attributkälla | Ena Källa, Ena LoT-1, Ena LoT-2, Ena LoT-3, Ena LoT-4 |
Resursserver (API) | Ena Hantering |
E-tjänst | Ena Hantering |
Klient | Ena Hantering |
Notera!
- Vi föreslår inte tillitsmärken för metadatapublicering och -validering. Detta då dessa förmågor är grundläggande i tillitsinfrastrukturen och det inte är vettigt att säkerställa dem genom specifik tillitsmärkning.
TODO Eftersom dessa IAM-förmågor är centrala och krav som ställs på dessa bör vara i stort samma som för Intygsutfärdare bör öven dessa ha Tiillitsmärken om än bara på LoT-nivå 3-4. Annars behöver dessa säkerhetskrav bara hanteras via anslutninsregler och avtal vilket borde ge en mindre flexibel och dynamisk hantering av federationsinfrastrukturaktörer. - LoT-nivå kan inte mappas rakt av mot Svensk e-legitimations LoA-nivåer, men en viss LoT-nivå kan ställa krav på att legitimering av användare skett på ett visst sätt.
Utvikning kring tillitsnivåer
Vi föreslår att behov av en viss tillitsnivå grundar sig i klassningen av den information eller funktion som en digital tjänst behandlar. För detta utgår vi ifrån MSB:s stöd för informationsklassning (Ref: Klassningsmodell, MSB). 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 och utgöra en bra grund. Det vill säga att utifrån en klassning av en verksamhets information faller säkerhetsåtgärder ut.
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.
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 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.
Vi föreslår att Ena baserar sina tillitsnivåer på stödet "Klassningsmatris A - Fyra nivåer" från MSB med en tolkning av nivåernas innebörd enligt tabellen nedan.
Level of Trust | När ska man kräva det och vad innebär det? |
---|---|
LoT-1 | Ett riktmärke är att konsekvenser ligger på försumbar skada avseende konfidentialitet eller riktighet. |
LoT-2 | Ett riktmärke är att konsekvenser ligger på måttlig skada avseende konfidentialitet eller riktighet. |
LoT-3 | Ett riktmärke är att konsekvenser ligger på betydande skada avseende konfidentialitet eller riktighet. |
LoT-4 | Ett riktmärke är att konsekvenser ligger på allvarlig skada avseende konfidentialitet eller riktighet. |
Krav på LoT
Varje samverkanstillämpning bör kräva att alla komponenter som ingår i tillitskedjan har LoT-tillitsmärke på minst den klassade nivån.
Tillitsskapande krav
Tillitsskapande krav kan vara av olika karaktär. Inom Enas tillitsarbete har vi identifierat fyra huvudkategorier av tillitsskapande krav:
- Organisatoriska krav
- Administrativa krav
- Fysiska krav
- Tekniska krav
Vi har genomfört en analys och sammanställning av tillitskrav ställda inom federationerna Sweden Connect, Sambi, Skolfederation, SITHS och HSA. Kraven överlappar till stor del och vi har föresatt oss att skapa en nettolista av krav i Enas terminologi och anpassade för komponenter som hanterar identiteter och behörighetsgrundande information för samverkan via digitala tjänster inom Ena.
ALLA krav som stipuleras av något tillitsmärke ska finnas registrerade med unika identiteter per krav i en gemensam Ena Kravkatalog. Detta innebär att ett enskilt tillitsmärke blir dels en listning av identiteterna på de krav som omfattas, dels vilka krav på efterlevnadskontroll som föreligger.
Målen med denna påbörjade men ännu inte färdiga övning är flera:
- Verksamheter som redan genomgått tillitsgranskning för någon av de genomgångna tillitsramverken ska automatiskt kunna vara kvalificerade för att bli tilldelade nödvändiga tillitsmärken och kunna etablera samverkan via digitala tjänster i Ena.
- Digitala tjänster som erbjuds inom någon av de genomgångna federationerna ska kunna erbjuda samma tjänst inom Ena till parter som är anslutna till Enas federationsinfrastruktur.
- Existerande federationer ska på sikt kunna luta sig emot Enas tillitsmärken för existerande tillgång till digitala tjänster och därmed minska samhällets totala kostnad för återkommande tillitsgranskningar.
preliminär tidplan
Vi siktar på att kunna presentera en första version av Enas kravkatalog under Q3 2025.
Efterlevnadskontroll vid tilldelning och revision av tillitsmärken
Tanken bakom det sätt som strukturen med tillitsmärken och en central kravkatalog är uppbyggd är att alla granskningsaktiviteter ska anpassas utifrån vilka krav som en organisation, en verksamhet, eller en teknisk komponent redan uppfyller baserat på redan tilldelade tillitsmärken. Ett steg i utfärdandet av ett tillitsmärke är att ta fram vilka krav som ansökanden behöver granskas emot. Det vill säga gapet mellan aktuellt tillitsmärkes kravomfång och de krav som den tekniska komponenten och dess bakomliggande ansvariga verksamhet eller organisation redan uppfyller.
För att påvisa efterlevnad av de krav som omfattas av ett tillitsmärke krävs det initiala och periodiskt återkommande mekanismer för efterlevnadskontroll. Vi har identifierat nedanstående mekanismer som används idag i olika sammanhang:
- Lagstadgad efterlevnad - granskning av många myndigheters efterlevnad av lagstadgade krav genomförs dels av myndigheten intern och av utpekad kontrollmyndighet.
- Självdeklarerad efterlevnad baserad på intern revision - parter granskar sin egen efterlevnad genom internrevision och redovisar granskningsresultatet till Ena i en självdeklaration.
- Självdeklarerad efterlevnad baserad på extern revision - parter låter genomföra en externt kontrakterad revision och redovisar granskningsresultatet till Ena i en självdeklaration.
- Granskning - en av ena godkänd part granskar efterlevnad
Vilken granskning som genomförs beror dels av vilken part det är som granskas, dels av vilket tillitsmärke granskningen gäller. Exakt utformning av regelverk för efterlevnadskontroll och tillhörande processer kvarstår att utforma.
preliminär tidplan
Vi siktar på att kunna presentera en första version av Enas regelverk för efterlevnadskontroll för tillitsmärken under Q4 2025.
Exempel på tillämpning av tillitsstrukturen
TODO Från möte 12/6 - det är bra om vi exemplifierar en eller flera tillämpningar av föreslagen struktur.