API-nycklar och behörigheter – säkerhetschecklista
Av CodexierPublicerad 4 min läsning
Varje integration mellan dina system har en nyckel: en API-nyckel, en OAuth-token eller ett lösenord till ett tjänstekonto. Tillsammans har de ofta mer åtkomst än någon enskild anställd, och betydligt mindre tillsyn. En läckt nyckel till bokföringen eller CRM:et är en personuppgiftsincident som väntar på att hända. Checklistan tar upp hur du kartlägger kopplingarna, begränsar vad var och en får göra, lagrar nycklar säkert, byter dem och tar bort åtkomst när personer eller leverantörer slutar.
Förteckning över kopplingar och nycklar
Du kan inte skydda det du inte vet finns. Börja med att lista varje koppling: webbshop till Fortnox, formulär till CRM, flöden i Zapier, AI-verktyg med åtkomst till inkorgen, leverantörer med API-åtkomst till era system. Anteckna för var och en systemet, typen av inloggningsuppgift, behörigheterna, var den lagras, vem som skapade den och när den senast byttes.
Minsta möjliga behörighet per integration
Många system erbjuder behörighetsområden eller roller för API-åtkomst. Använd dem. En integration som bara skapar fakturor ska inte kunna läsa lönedata. En integration som läser ordrar ska inte kunna radera kunder. Erbjuder ett system bara nycklar med full åtkomst är det en risk att notera och en fråga att ställa till leverantören.
| Arbetssätt | Varför det spelar roll |
|---|---|
| En nyckel per integration | Du kan återkalla en utan att förstöra de andra, och loggarna visar vilken integration som gjorde vad |
| Snävast möjliga behörighet | En läckt nyckel kan göra mindre skada |
| Tjänstekonton, inte personliga inloggningar | Åtkomsten hänger inte på en anställd och överlever att hen slutar |
| Endast läsrätt där det går | Många rapport- och synkjobb behöver aldrig skriva |
| IP-begränsning där det stöds | En stulen nyckel kan inte användas varifrån som helst |
Lagra nycklar säkert
De vanligaste läckorna är vardagliga: en nyckel inklistrad i en chatt, incheckad i ett kodförråd, mejlad till en frilansare eller sparad i ett delat kalkylark. Nycklar hör hemma i ett hemlighetsförråd, i driftplattformens miljövariabler eller i automationsplattformens krypterade kopplingsinställningar. Dela åtkomst via en lösenordshanterare med loggning, aldrig genom att kopiera värdet.
- Checka aldrig in nycklar i Git, inte ens i privata förråd – använd automatisk sökning efter hemligheter för att fånga misstag.
- Lägg aldrig nycklar i frontendkod eller mobilappar, där vem som helst kan läsa dem.
- Använd separata nycklar för test och produktion.
- Lagra nycklar som leverantörer behöver i ett gemensamt valv som du styr över, inte bara i deras system.
Byte av nycklar och avslut
Nycklar ska bytas enligt schema och när risken förändras. När en anställd, konsult eller leverantör med åtkomst slutar ska varje nyckel hen kan ha sett bytas, och varje OAuth-koppling hen godkände flyttas till ett tjänstekonto. Det är här de flesta små företag är sårbara: den gamla webbyrån har fortfarande adminbehörighet och en före detta anställds token driver fortfarande fakturasynken.
Byte enligt schema
Byt långlivade nycklar minst en gång om året, oftare för känsliga system. För in datumen i förteckningen.
Byte vid händelser
Byt direkt vid förändringar bland personal eller leverantörer, eller om en nyckel kan ha exponerats.
Checklista vid avslut
Lägg till integrationer och API-åtkomst i checklistan när någon slutar, bredvid mejl och dator.
Loggning och larm
Loggning visar vad en integration gjorde, och larm säger till när den gjorde något ovanligt. Slå på åtkomstloggar för API:er där systemen erbjuder det. Håll utkik efter toppar i volym, åtkomst från nya platser, misslyckade inloggningar och exporter av stora datamängder. Missbrukas en nyckel är det också loggarna du behöver för att bedöma om en personuppgiftsincident ska anmälas till IMY inom 72 timmar.
Vi använder checklistan i varje genomgång av integrationer vi gör. När du inte behöver oss: har ni två eller tre integrationer och en person som har koll på dem är det realistiskt att gå igenom listan själva. Har ni ärvt ett virrvarr av kopplingar från tidigare anställda eller leverantörer kan du boka ett kostnadsfritt samtal, så hjälper vi er att kartlägga dem. Vår guide API:er förklarade för företagare är en bra introduktion.
Vanliga frågor
Vad är skillnaden mellan en API-nyckel och en OAuth-token?
En API-nyckel är en statisk hemlighet som ger åtkomst tills den återkallas. En OAuth-token utfärdas när en användare eller ett tjänstekonto godkänner åtkomst, oftast med begränsad behörighet och ett utgångsdatum, och kan förnyas. OAuth är i regel säkrare eftersom åtkomsten är begränsad och spårbar.
Hur ofta ska vi byta API-nycklar?
Minst en gång om året för långlivade nycklar, oftare för system med känsliga data, och direkt när någon med åtkomst slutar eller en nyckel kan ha läckt.
Är det säkert att ge vår byrå eller frilansare API-åtkomst?
Ja, om de får en egen nyckel med begränsad behörighet som lagras i ett valv ni styr över och återkallas när uppdraget är klart. Undvik att dela er egen admininloggning.
Vad gör vi om en nyckel har läckt?
Återkalla den direkt, skapa en ny, gå igenom loggarna efter missbruk och bedöm om personuppgifter har kommit åt. Har de det kan GDPR:s regler om personuppgiftsincidenter kräva anmälan till IMY inom 72 timmar.
Osäker på vem som har åtkomst till vad?
Lista systemen ni kopplar ihop. På en kvart hjälper vi er att hitta de mest riskabla nycklarna och var ni ska börja.
Boka ett kostnadsfritt 15-minuterssamtal