Drift och dataägarskap

Hur IDOmbud hanterar detta

IDOmbud som tjänst innebär att organisationen får tillgång till funktioner för identitet, autentisering, e-Legitimation, behörighetsstyrning och governance utan att själv behöva bygga och drifta hela den tekniska plattformen. Drift, underhåll, uppdateringar och teknisk förvaltning kan hanteras inom tjänsteleveransen enligt avtal.

Det innebär däremot inte att kunden släpper kontrollen över sin information. Kunden äger sina verksamhetskrav, sina processer, sina beslut och sitt data. IDOmbud ska möjliggöra att informationen kan hanteras, förstås, granskas och följas upp i en tydlig modell.

Svensk drift och svensk jurisdiktion bör beskrivas som en viktig utgångspunkt för tjänsten. Det ger organisationen en tydligare grund för att bedöma var information behandlas, vilken rättslig miljö som gäller och hur leveransen förhåller sig till krav på upphandling, sekretess, personuppgiftshantering och datasuveränitet. Mer detaljer om infrastruktur, certifieringar, separata miljöer och särskilda driftkrav bör hanteras i införande- och kravdialogen.

Datatyper som kan behöva omfattas av dataägarskap och styrning är till exempel:

• identitetsinformation
• användarkonton och attribut
• behörigheter, grupper och roller
• attestbeslut och certifieringshistorik
• loggar och säkerhetshändelser
• utfärdade e-Legitimationer och credentials
• spärrar, återkallelser och statuskontroller
• integrationsdata och rapporter

För varje datatyp behöver organisationen veta varför informationen behandlas, vem som får administrera den, vem som får läsa den, hur länge den behöver sparas och hur den kan exporteras, arkiveras eller raderas när den inte längre ska användas.

Ansvar i tjänstemodellen

För säkerhetsarkitekter är gränsdragningen viktig. IDOmbud kan hantera drift och tekniska förmågor, men kundens egna applikationer, källsystem, nätverk, klientmiljöer och interna säkerhetsprocesser ligger normalt kvar i kundens ansvar. Därför behöver integrationer, loggflöden, åtkomstmodeller och incidentrutiner definieras tidigt.

För upphandling är det viktigt att formulera krav som går att verifiera. Exempel är krav på driftland, supportmodell, personuppgiftsbiträdesavtal, åtkomst till loggar, exportformat, retention, avvecklingsstöd, incidentrapportering och möjlighet att granska tjänstens användning över tid.

Texten bör undvika hårda löften om certifieringar, tillgänglighetsnivåer, incidenttider, kryptering eller separata miljöer om detta inte är bekräftat i avtal eller produktdokumentation. Däremot kan sidan tydligt säga att sådana krav behöver redas ut i införande- och avtalsdialogen.

Vad kunden behöver ta ställning till

• vilka krav som finns på driftland, jurisdiktion och datasuveränitet
• vilka datatyper som kommer att hanteras i IDOmbud
• vem som äger respektive datatyp och respektive beslut
• vilka roller som får administrera, läsa och exportera information
• vilka loggar och revisionsunderlag som krävs
• hur länge data, loggar och historik ska sparas
• vilka krav som finns på export, arkivering och avveckling
• om data behöver integreras med SIEM, arkiv, ärendehantering eller analysverktyg
• hur incidenter ska rapporteras, utredas och följas upp
• vilka krav GDPR, NIS2, offentlig upphandling, intern kontroll eller tillsyn ställer
• vilka delar som ska regleras i avtal, instruktioner, rutiner och teknisk konfiguration
• hur kunden ska följa upp att tjänsten används enligt beslutade regler