API-åtkomst i molntjänster: vad bör ingå i avtalet?

API-åtkomst i molntjänster: därför behövs ett tydligt avtal

Att koppla ett system till en molntjänsts API verkar vara en teknisk detalj: nyckel, slutpunkt, integration. I praktiken passerar och behandlas uppgifter ni ansvarar för i miljöer leverantören styr. IMY beskriver samma risk: leverantören av molntjänsten kontrollerar IT-utrustningen som hanterar och lagrar informationen, och leverantörens personal och eventuella underleverantörer kan därför ta del av den. Informationen kan dessutom behandlas i länder utanför EU, med andra lagar och sämre skydd för integriteten.

Avtalet måste därför reglera mer än anropen. Skatteverkets partner-API:er visar: användaren signerar avtal med myndigheten, och avtalet reglerar bland annat hur API:et får användas och hur myndigheten meddelar om förändringar – det ger både skyldigheter och rättigheter. Oavsett leverantör bör samma områden ingå: personuppgiftsroller, hur åtkomst beviljas och återkallas, autentisering, säkerhetskrav, ändringshantering, underbiträden och tredjelandsöverföringar, incidenter och support, samt vad som händer med data och åtkomst när avtalet upphör.

Förhandlingsutrymmet är inte alltid stort. I IMY:s undersökning av sju myndigheters molntjänstanvändning, som gjordes inom en samordnad åtgärd inom Europeiska dataskyddsstyrelsen (EDPB), uppgav samtliga myndigheter att det är en utmaning att hitta molntjänster förenliga med dataskyddsregelverket, och att det ofta är svårt att förhandla med molntjänstleverantörer och därmed påverka utformningen av eller villkoren för tjänsterna. Därför är det viktigare att i förväg veta vilka punkter ni inte kan kompromissa om.

Roller och ansvar för personuppgifter

Avtalet bör först slå fast vem som är personuppgiftsansvarig, vem som är personuppgiftsbiträde och om parterna i något avseende är gemensamt personuppgiftsansvariga. Det är ingen formalitet: IMY:s undersökning indikerar att myndigheterna har vissa utmaningar att fastställa rollfördelningen mellan personuppgiftsansvarig och personuppgiftsbiträde eller gemensamt personuppgiftsansvar. Är rollen otydlig i avtalet hamnar frågan i praktiken hos er efter en incident.

Undersökningen pekar också på att vissa molntjänstleverantörer uppges ha bristande kunskaper om grundläggande dataskyddsregler, vilket ställer stora krav på den upphandlande parten. Enligt IMY gäller det till exempel vad som är personuppgifter och personuppgiftsbehandling, roll- och ansvarsfördelningen mellan personuppgiftsansvarig och personuppgiftsbiträde samt personuppgiftsbiträdets ansvar vid anlitande av underbiträden. Avtalet bör därför vara explicit i stället för att hänvisa till leverantörens egen tolkning: vilka behandlingar som omfattas, vilka kategorier av uppgifter och registrerade det gäller, och vilket ansvar biträdet tar för sina underbiträden.

Ett särskilt granskningsmoment gäller påståenden om att uppgifter är anonymiserade eller pseudonymiserade och därför faller utanför personuppgiftsreglerna. IMY:s undersökning pekar på att molntjänstleverantörer i vissa fall felaktigt uppger att de har skyddsmekanismer i form av anonymisering och pseudonymisering. Sådana påståenden bör inte skrivas in i avtalet som sanning utan underlag – de flyttar ansvar och risker från leverantören till er.

Påståenden om anonymisering/pseudonymisering – risker och rekommendationer

Åtkomst, autentisering och API-nycklar

Avtalet bör beskriva hela kedjan från ansökan till återkallad åtkomst. Skatteverkets process för partner-API:er visar hur den kan se ut: den som vill använda API:et fyller i ett formulär på myndighetens webbplats och begär tillgång, med uppgifter om företaget och programvaran som ska ansluta. Uppfylls kraven får företaget ett avtal att signera på Mina sidor, av behörig firmatecknare, varefter Skatteverket granskar och skriver under. Först när avtalet är underskrivet av båda parter skickas API-nycklar ut till de kontaktuppgifter som lämnats i formuläret. Det illustrerar två lätt glömda avtalspunkter: vem hos er som får begära och ta emot nycklar, och vilken kontaktväg som används.

Åtkomstkraven kan vara villkorade av företagets status. Skatteverket kräver exempelvis att programvaruföretag är godkända för F-skatt eller FA-skatt, registrerade för moms och registrerade som arbetsgivare (gäller inte egenföretagare) samt fria från skulder till Skatteverket och skatteskulder som gått till Kronofogden. Samma krav gäller företag i andra EU-länder, som dessutom behöver skicka in underlag som styrker att kraven är uppfyllda. Ansökan kan avslås, exempelvis om företaget inte är registrerat för moms, och en ny ansökan är möjlig när bristerna åtgärdats. Avtalet bör därför reglera vad som händer med integrationen om kraven inte längre uppfylls eller om åtkomsten nekas i ett senare skede.

För autentiseringen bör avtalet ställa krav på båda parter. IMY rekommenderar ett starkt och unikt lösenord för att ingen obehörig ska komma åt informationen i molntjänster, och att tvåfaktorsautentisering aktiveras om det är möjligt. I API-sammanhang betyder det att avtalet bör ange hur nycklar och andra autentiseringsuppgifter skapas, lagras, roteras och återkallas, vem som får utfärda dem och hur snabbt åtkomst kan dras in – till exempel vid avtalsslut, uppsägning eller när en person lämnar sin roll. Behörigheter bör begränsas till vad användningen kräver, och avtalet bör beskriva hur behörigheter beviljas, ändras och följs upp.

Process för API-åtkomst i Skatteverkets partner-API:er

Tjänstebeskrivning, versioner och förändringar

API:et behöver en skriftlig definition av vad det faktiskt gör. Skatteverket löser det genom att avtalsdokumentationen består av avtal, allmänna villkor, tjänstebeskrivning och förändringspolicy, och varje API:s dokumentation finns på utvecklarportalen. Modellen fungerar även för kommersiella leverantörer: när de fyra delarna hänger ihop syns vad som är avtalat, vad som är en beskrivning av tjänsten och vad som är en ensidig policy – och därmed vilka delar leverantören kan ändra utan er medverkan.

Avtalet bör också reglera hur ändringar av API:et kommuniceras. Skatteverket anger uttryckligen att avtalet reglerar hur myndigheten ska meddela användaren om förändringar. Ni bör därför kräva svar på: vilken kanal notifieringen sker genom, vem hos er som tar emot den, hur långt i förväg en ändring aviseras, hur länge en äldre version stöds parallellt och vad som gäller om ni inte hinner anpassa er integration. Bolagsverkets API-avtal nämner en notifieringsfunktion som gör det möjligt att få information när något ändras för ett företag som är registrerat hos Bolagsverket – ett exempel på att händelseinformation kan byggas in i tjänsten, men det ersätter inte er rätt till besked om ändringar i själva API:et.

Ett praktiskt grepp är att låta avtalet skilja på ändringar som kräver er anpassning och ändringar som är transparenta för integrationen, och att bestämma vilken part som bär kostnaden för anpassningen i respektive fall.

Säkerhetskrav för API och applikation

Säkerheten bör kravställas i avtalet och inte lämnas till leverantörens interna praxis. IMY:s vägledning om säker applikationsutveckling beskriver vad som kan förväntas av den som utvecklar eller använder en applikation: analysera designen av applikationen innan koden börjar skrivas, så att sårbarheter kan identifieras tidigt och personuppgiftsbehandlingen blir överskådlig – exempelvis genom hotmodellering, en typ av hot- och riskanalys. Vidare kodgranskning, det vill säga att man granskar källkoden manuellt eller med särskilda granskningsverktyg för att hitta brister, och att fler än den som skrivit koden granskar den. Slutligen att testa säkerheten genom sårbarhetsskannningar och penetrationstester, manuellt eller automatiserat, och att dokumentera resultaten.

Dessa moment går att skriva in som avtalskrav på leverantören och som egna åtaganden för er integration: att design och arkitektur gås igenom innan förändringar driftsätts, att kod granskas av någon annan än upphovspersonen, att säkerhetstester genomförs med viss regelbundenhet och att resultaten dokumenteras och kan begäras ut. IMY nämner OWASP Top Ten som ett stöd för att arbeta med säker applikationsutveckling; dokumentet syftar till att öka medvetenheten kring riskerna med framför allt utveckling av webbapplikationer och kan fungera som gemensam referens i avtalet när ni vill undvika egna, svårbedömda definitioner av vad som är en säkerhetsbrist.

Krypterad överföring hör till miniminivån. IMY beskriver att förbindelser till många webbplatser och molntjänster är krypterade, att det syns i adressfältet genom att adressen markerats med https där S-et står för secure, och att det stängda hänglåset visar att förbindelsen är krypterad. I avtalet bör motsvarande krav formuleras för API-trafiken: att uppgifter överförs krypterat, vilka protokoll och versioner som godtas, samt vad som gäller för loggning och för de uppgifter som passerar i anrop och svar.

Säkerhetskrav i API-avtal – jämförelse mellan myndigheters och kommersiella leverantörers praxis

Underbiträden och överföring till tredjeland

Underbiträden är en av de punkter där avtalet behöver vara mest konkret, eftersom leverantörens kedja också blir er kedja. IMY konstaterar att det enligt undersökningen av myndigheternas molntjänstanvändning är oklart om det vid överföring av uppgifter till tredje land alltid finns stöd för överföringen i form av ett tillämpligt överföringsverktyg i kapitel V i dataskyddsförordningen. Avtalet bör därför inte nöja sig med en hänvisning till att leverantören följer gällande rätt, utan namnge vilket överföringsverktyg som används, för vilka kategorier av uppgifter överföringen sker och till vilka länder.

Samma resonemang gäller underbiträden: vilka de är, vad de gör, var de finns och vilket ansvar leverantören tar för dem. Undersökningen pekar på att leverantörernas bristande kunskaper bland annat rör just personuppgiftsbiträdets ansvar vid anlitande av underbiträden, vilket innebär att ni behöver reglera frågan snarare än att förutsätta att den är hanterad. Ett avtalsmönster är att lista godkända underbiträden, kräva information i förväg vid ändringar, ge er rätt att invända och att säga upp avtalet om ni inte accepterar en ny underbiträdesrelation.

Även IMY:s allmänna råd om molntjänster är relevanta här. Myndigheten lyfter att information kan behandlas i länder utanför EU med andra lagar och sämre skydd för integriteten, och att det därför är viktigt att göra ett medvetet val av vilka uppgifter man anser att andra kan få ta del av. Det valet bör återspeglas i avtalet: vilka uppgiftskategorier som över huvud taget får förekomma i API-trafiken, och vilka som ska hållas utanför.

Risker vid tredjelandsoverföringar – enligt IMY:s undersökning

Incidenter, support och avveckling

Avtalet bör fastställa hur fel och incidenter hanteras: var felanmälan görs, vilka kontaktuppgifter och supportfunktioner som gäller, vem som är mottagare hos respektive part och vad som ska rapporteras till er respektive av er. IMY:s råd till användare av molntjänster är att ta del av leverantörens information om hur man kan få hjälp vid problem – kontaktuppgifter och supportfunktioner. Det är en rimlig miniminivå, men i ett API-avtal bör den konkretiseras: vilka typer av fel som omfattas, hur incidenter eskaleras och hur ni underrättas när något inträffat som rör era uppgifter.

Säkerhetskopiering är en egen avtalspunkt, inte en följd av att data ligger i molnet. IMY påpekar att det att lagra information i en molntjänst inte är samma sak som att den är säkerhetskopierad, och att information kan förstöras eller bli oåtkomlig för användaren under kort eller lång tid. Avtalet bör därför beskriva vem som ansvarar för säkerhetskopiering och återställning, vilka data som omfattas, hur ofta återställning ska kunna ske och hur ni får tillgång till era egna kopior.

Avveckling behöver regleras innan den blir aktuell. IMY nämner att molntjänstleverantören kan lägga ner sin verksamhet eller bli uppköpt av ett annat företag, och att man bör försöka ta reda på vad som händer med informationen om det skulle ske. I avtalet motsvarar det frågor som: i vilket format och inom vilken tid får ni ut era data, hur länge finns de kvar efter avtalets slut, när upphör API-åtkomsten och vad händer med utfärdade nycklar och autentiseringsuppgifter vid uppsägning, konkurs eller ägarbyte. Svaret bör vara skriftligt och inte bygga på leverantörens framtida goda vilja.

Dokumentation, uppföljning och revision

Avtalet blir bara så bra som dokumentationen runt det. IMY:s undersökning visar att samtliga myndigheter uppger att de har processer och rutiner för att anskaffa molntjänster, och att merparten genomför konsekvensbedömningar innan en molntjänst anskaffas. De delarna hänger ihop: kravställningen i anskaffningen blir avtalets bilagor, och konsekvensbedömningen avgör vilka skyddsåtgärder som måste stå med. Eftersom undersökningen samtidigt visar att det ofta är svårt att förhandla med leverantörerna och påverka deras villkor, är det värt att dokumentera sina egna minimikrav tidigt och spara underlaget för vad som faktiskt eftergavs.

Konkret bör följande dokument vara kända, versionshanterade och tillgängliga för dem som arbetar med integrationen: avtalet, de allmänna villkoren, tjänstebeskrivningen och förändringspolicyn – samma fyra delar som Skatteverket anger att avtalsdokumentationen består av. Till det kommer personuppgiftsbiträdesavtal eller motsvarande reglering av roller, lista över godkända underbiträden, beskrivning av överföringar till tredje land med överföringsverktyg, rutin för incidenthantering samt rutin för åtkomst och nyckelhantering.

Uppföljningen bör ha en ägare och en frekvens. Rimliga punkter att gå igenom med jämna mellanrum är om rollfördelningen fortfarande stämmer, om underbiträdeslistan är aktuell, om ändringar i API:et har aviserats enligt avtalet, om åtkomster och nycklar fortfarande motsvarar aktuella behov och om säkerhetstester och dokumenterade resultat finns från den period som gått. Om leverantören inte kan visa detta skriftligt är det i praktiken ett avtalsbrott ni behöver kunna åberopa.

Checklista inför signering

– Roller: Framgår det vem som är personuppgiftsansvarig, vem som är personuppgiftsbiträde och om något hanteras gemensamt? Finns det skriftligt stöd för eventuella påståenden om anonymisering eller pseudonymisering?

– Åtkomst: Vem hos oss får begära och ta emot API-nycklar, via vilken kontaktväg, och vilka krav måste vi fortsatt uppfylla för att behålla åtkomsten?

– Nyckelhantering: Hur skapas, lagras, roteras och återkallas nycklar och andra autentiseringsuppgifter, och hur snabbt kan åtkomst dras in vid avtalsslut eller personalbyte? Krävs starkt och unikt lösenord och tvåfaktorsautentisering där det är möjligt?

– Säkerhet: Finns krav på krypterad överföring, design- och arkitekturgenomgång, kodgranskning av någon annan än upphovspersonen, sårbarhetsskanning och penetrationstest, samt dokumenterade resultat som vi får ta del av?

– Ändringar: Vilken kanal och hur lång framförhållning gäller för ändringar i API:et, hur länge stöds äldre versioner, och vem bär kostnaden för anpassning? Finns tjänstebeskrivning och förändringspolicy med som bilagor?

– Underbiträden: Är de listade, får vi information i förväg vid ändringar, kan vi invända och vad händer då? Vilket ansvar tar biträdet för sina underbiträden?

– Tredjeland: Till vilka länder överförs uppgifter, vilket överföringsverktyg används enligt kapitel V, och vilka uppgiftskategorier får förekomma i API-trafiken?

– Incidenter och support: Var felanmälan görs, vilka kontaktuppgifter och supportfunktioner som gäller, hur incidenter eskaleras och hur vi underrättas.

– Säkerhetskopiering: Vem ansvarar för backup och återställning, vilka data omfattas, och hur får vi tillgång till egna kopior?

– Avveckling: I vilket format och inom vilken tid får vi ut våra data vid uppsägning, konkurs eller ägarbyte, och när upphör API-åtkomst och nycklar?

– Uppföljning: Vem äger avtalet internt, hur ofta ses rollfördelning, underbiträdeslista, åtkomster och säkerhetsdokumentation över, och finns avtal, allmänna villkor, tjänstebeskrivning och förändringspolicy i aktuell version?