Tjänstemodellen innebär inte att organisationen släpper kontrollen över sin information. Tvärtom behöver ägarskap, åtkomst, lagring, spårbarhet och ansvar vara tydliga från början. Organisationens data ska kunna förstås, förvaltas och följas upp även när den tekniska driften sker som tjänst.
Beslutsfaktorer
| Område | Vad det betyder |
|---|
| Svensk drift | Tydligare utgångspunkt för var information behandlas och vilken juridisk miljö som gäller |
| Tydligt dataägarskap | Organisationen kan förstå, styra och följa upp sitt eget data |
| Spårbarhet och loggar | Beslut, förändringar och säkerhetshändelser kan granskas |
| Drift och underhåll | Plattform, uppdateringar och teknisk förvaltning kan hanteras i tjänsten |
| Anpassning vid särskilda krav | Införandet kan planeras utifrån integrationer, loggflöden och ansvarsfördelning |
Svensk drift och svensk jurisdiktion
En viktig del av tjänstemodellen är att IDOmbud levereras med svensk drift och svensk jurisdiktion som utgångspunkt. Det gör det lättare att bedöma var information behandlas, vilken rättslig miljö som gäller och hur leveransen förhåller sig till organisationens egna krav.
För verksamheter inom offentlig sektor, vård, finans och andra reglerade områden är driftmodell, datasuveränitet och regelefterlevnad ofta avgörande delar av beslutet. Det räcker inte att en funktion fungerar tekniskt. Det måste också gå att visa hur information hanteras, vem som ansvarar för olika delar och hur tjänsten kan granskas över tid.
Den svenska infrastrukturgrunden är relevant därför att den påverkar mer än var servrarna står. Den påverkar även vilka lagar som kan bli aktuella, hur personuppgifter får behandlas, hur loggar och säkerhetsdata hanteras och hur organisationen kan förklara sin lösning vid revision, tillsyn eller upphandling.
Mer detaljerad information om infrastruktur, certifieringar och driftmodell kan lämnas som en del av införande- och kravdialogen.
Organisationens data
Organisationen ska kunna äga, förstå och styra sitt eget data även när IDOmbud används som tjänst. Det betyder att informationen inte ska bli otydlig, svår att följa eller beroende av informella rutiner.
Datat i tjänsten behöver kunna kopplas till tydliga ändamål och ansvar. Det gäller exempelvis identitetsinformation, behörigheter, intyg, loggar, attestflöden och uppgifter om vem som har haft åtkomst till vad. När dessa uppgifter hanteras samlat blir det lättare att skapa spårbarhet och att göra uppföljning utan att informationen sprids mellan flera separata system.
Dataägarskap behöver därför beskrivas praktiskt. Organisationen behöver veta vilka datatyper som finns i tjänsten, varför de behandlas, hur länge de behöver sparas, vilka roller som får administrera dem och hur information kan följas upp i efterhand. Det gäller både verksamhetsdata och tekniska säkerhetsdata.
Det bör också vara tydligt hur information kan granskas, exporteras, arkiveras eller avvecklas vid förändrade behov. En tjänstebaserad modell ska inte skapa otydligt ägarskap eller göra det svårt att byta arbetssätt över tid. Den ska ge organisationen en stabilare grund för kontroll.
Drift, underhåll och uppdateringar
Som tjänst omfattar IDOmbud drift, underhåll och teknisk förvaltning av lösningen. Organisationen behöver därför inte bygga upp motsvarande driftmiljö, övervakning och uppdateringsprocess själv.
Tjänstemodellen kan omfatta drift av plattformen, övervakning, uppdateringar, löpande tekniskt underhåll, patchning och incidenthantering. Logghantering, analys och larm kan ingå där det är en del av den avtalade leveransen.
Det gör att organisationen snabbare kan komma igång och samtidigt minska sitt eget ansvar för den tekniska plattformen. Fokus kan i stället läggas på processer, styrning, införande och hur tjänsten ska användas i verksamheten.
Det betyder inte att organisationen släpper sitt ansvar. Den behöver fortfarande styra krav, besluta om processer, förvalta roller och följa upp att tjänsten används på rätt sätt. Skillnaden är att den tekniska plattformen, säkerhetsdriften och det löpande underhållet kan hanteras inom tjänsteleveransen.
Datasuveränitet i praktiken
Datasuveränitet handlar om att organisationen kan förklara och kontrollera hur data hanteras under hela livscykeln. För IDOmbud innebär det att drift, lagring, åtkomst, loggning och säkerhetskontroller behöver hänga ihop med organisationens egna krav.
Det är särskilt viktigt när tjänsten används för identitet och åtkomst. Sådana uppgifter kan visa vilka personer som finns i en organisation, vilka behörigheter de har, vilka intyg som har utfärdats och vilka system de kan nå. Om den informationen hanteras utspritt blir det svårare att visa kontroll. Om den hanteras samlat och spårbart blir det enklare att styra ansvar, upptäcka avvikelser och följa upp förändringar.
En svensk tjänstemodell gör det också lättare att diskutera krav på personuppgiftshantering, sekretess, upphandling, arkivering och incidenthantering med en tydlig geografisk och juridisk utgångspunkt.
Spårbarhet, loggar och uppföljning
När identitet och åtkomst hanteras som tjänst blir loggar och spårbarhet centrala delar av lösningen. Loggar behövs inte bara för felsökning. De behövs för att kunna visa vem som gjorde vad, när en förändring genomfördes, vilken åtkomst som fanns vid en viss tidpunkt och hur avvikelser har hanterats.
IDOmbud bör därför användas med en tydlig syn på vilka händelser som ska vara spårbara. Det kan handla om inloggningar, ändrade behörigheter, utfärdade eller återkallade intyg, attestbeslut, administrativa åtgärder och säkerhetsrelaterade händelser.
När loggning och uppföljning ingår i tjänstens arbetssätt blir det lättare att möta krav från revision, intern kontroll, GDPR, NIS2 och andra regelverk där spårbarhet och incidenthantering är viktiga delar.
Kryptering och nyckelkontroll
För känsliga identitets- och åtkomstflöden är det inte tillräckligt att data lagras på rätt plats. Skyddet behöver också omfatta kryptering, nyckelhantering och tekniska kontroller som minskar risken för obehörig åtkomst.
I scenarier där tjänsten hanterar stark autentisering, e-Legitimation eller andra tillitsbärande funktioner kan nyckelkontroll och hårdvarubaserat skydd vara en viktig del av helheten. Det stärker möjligheten att beskriva hur kryptografiskt material skyddas och hur lösningen förhåller sig till högre tillitskrav.
Ansvar i tjänstemodellen
| Område | Kund | IDOmbud |
|---|
| Verksamhetskrav | Äger | Stödjer |
| Drift | Följer upp | Ansvarar enligt avtal |
| Roller och processer | Beslutar | Implementerar och stödjer |
| Loggar | Granskar | Tillhandahåller |
| Incidenthantering | Samverkar | Driver enligt avtal |
| Dataägarskap | Äger | Möjliggör kontroll och uppföljning |
Passar när
- organisationen vill samla identitet, inloggning och åtkomst i en styrd tjänstemodell
- drift, spårbarhet och dataägarskap behöver kunna förklaras tydligt
- införandet behöver börja i ett avgränsat område och byggas vidare stegvis
- verksamhet, IT och säkerhet behöver en gemensam modell för ansvar och uppföljning
- externa användare, e-legitimation eller governance behöver kopplas till samma förtroendekedja
Frågor att ta med till genomgång
- Var ska identitets- och åtkomstdata behandlas?
- Vilka loggar behöver bevaras?
- Vem äger beslut om roller och behörigheter?
- Vilka krav finns på export, arkivering och uppföljning?
- Vilka delar behöver kopplas till befintliga säkerhetsverktyg?
- Finns särskilda krav på nätverk, miljöer eller integrationer?
Certifieringar och tillitsgrund
IDOmbud ska kunna förankras i krav på säkerhet, drift och efterlevnad. Det är viktigt eftersom tjänsten inte bara handlar om funktioner för inloggning och identitet. Leveransen måste också gå att granska, följa upp och beskriva i relation till organisationens egna krav.
Relevanta certifieringar och regelverk kan vara en del av den bedömningen. Exempel är PCI DSS Level 1, ISO 27001, ISO 9001, ISO 14001, GDPR och DIGG:s krav kopplade till tillitsnivåer. Vilka krav som är aktuella behöver bedömas utifrån organisationens användning, avtal och regulatoriska miljö.
För organisationer som omfattas av upphandling, tillsyn eller interna revisionskrav kan detta vara avgörande. Tjänsten behöver kunna beskrivas både tekniskt och organisatoriskt: hur driftmiljön är skyddad, hur åtkomst kontrolleras, hur förändringar loggas, hur incidenter hanteras och hur ansvar är fördelat mellan organisationen och tjänsteleveransen.
Snabbare väg till fungerande lösning
Eftersom IDOmbud är en tjänst kan organisationen komma igång snabbare än om motsvarande lösning ska byggas och driftas helt lokalt.
Organisationen kan börja med ett konkret behov, till exempel autentisering eller e-Legitimation, och sedan bygga vidare med fler delar över tid. Det gör tjänstemodellen praktisk både för avgränsade införanden och för verksamheter som på sikt vill samla en större del av identitet, åtkomst och tillit i samma lösning.
On-premise och särskilda driftkrav
IDOmbud är en tjänst. Vissa organisationer kan samtidigt ha särskilda krav på drift, infrastruktur, integrationer eller ansvarsfördelning. I sådana fall behöver förutsättningarna tydliggöras tidigt, så att tjänsten kan införas med rätt gränsdragning mellan organisationens ansvar och det ansvar som ingår i leveransen.
Det kan exempelvis handla om krav på integration med befintliga säkerhetsverktyg, särskilda loggflöden, rapportering, arkivering, nätverkskopplingar eller hantering av separata miljöer. Sådana krav förändrar inte att IDOmbud är en tjänst, men de påverkar hur införandet bör planeras och dokumenteras.
