Kort svar: En API-nøgle ER et login – behandl den som et kodeord med superkræfter: én nøgle pr. integration (aldrig genbrug), mindste nødvendige rettighed (læseadgang, hvis der kun skal læses), opbevaring i kodeords-manager eller miljøvariabler (aldrig i mails, delte dokumenter eller frontend-kode), rotation ved mistanke og personaleafgang – og en kvartalsvis oprydning, hvor ubrugte nøgler slettes. Lækkes en nøgle: tilbagekald den FØRST, undersøg bagefter. Med de vaner er integrationssikkerhed ikke et projekt, men almindelig hygiejne.
Jo mere du automatiserer, jo flere nøgler får du: WooCommerce-nøgler til regnskabet, applikationskodeord til n8n, tokens til fragtplatformen, webhook-hemmeligheder på kryds og tværs. Hver af dem kan gøre præcis det, integrationen kan – læse ordrer, ændre priser, oprette indhold – uden at nogen logger ind, og uden at 2FA spørger om noget. Denne guide er disciplinen, der gør, at netop DÉT aldrig bliver dit problem.
Navnene varierer, principperne ikke. API-nøgler (fx WooCommerce consumer key/secret) er faste adgangskort: de virker, til de tilbagekaldes. Applikationskodeord i WordPress er samme idé bundet til en bruger – med den fordel, at de kan oprettes og slettes enkeltvist (se REST API-guiden). Tokens (typisk OAuth) er tidsbegrænsede adgangskort, der fornys automatisk – sikrere i drift, men med samme krav til opbevaring af det, der FORNYR dem. Webhook-hemmeligheder vender pilen om: de beviser, at indgående beskeder er ægte (jf. webhook-guiden). Fælles for alle fire: den, der HAR dem, ER integrationen – systemet spørger ikke om andet. Derfor gælder én mental regel: hver nøgle er en medarbejder, du har ansat uden samtale – og så vil du gerne vide, hvem de er, hvad de må, og hvornår de skal fyres.
Tre konkrete vaner: Én nøgle pr. integration. Rapporten, regnskabet og fragtplatformen får hver sin – så kan én tilbagekaldes uden at vælte de andre, og loggen viser, HVEM der gjorde hvad. Genbrugte nøgler er som fælles kodeord: umulige at rydde op i. Læse, når der kun skal læses. WooCommerce-nøgler oprettes med read/write-valg – mandagsrapporten skal have READ, punktum; så kan en lækket rapportnøgle højst lække data, aldrig ændre priser eller ordrer. Dedikerede brugere med små roller. Applikationskodeord arver brugerens rettigheder – så hæng dem på en integrationsbruger med mindste nødvendige rolle, ikke på administratoren. Det er samme princip som i team-adgangsstyringen – maskiner er bare medarbejdere, der aldrig går hjem.
Må BO: i kodeords-managerens delte boks (som ethvert andet kodeord), i integrationsplatformens indbyggede credentials-lager (n8n krypterer fx forbindelser med sin nøgle – pas godt på DÉN, jf. selvhost-guiden) og i miljøvariabler/konfigurationsfiler uden for webroden på serveren. MÅ IKKE BO: i mails og chatbeskeder (de lever evigt i arkiver), i delte regneark og dokumenter, i frontend-kode eller JavaScript (alt, browseren får, er offentligt), i versionsstyring (den klassiske ulykke: nøglen committet til et offentligt repo – automatiske scannere finder den på minutter) – og ikke i udviklerens hoved som „den husker jeg“. Skal en nøgle deles med en samarbejdspartner, så del den via kodeords-managerens dele-funktion eller et selvdestruerende link – aldrig i tråden, hvor resten af samtalen bor.
Nøgler skal roteres ved tre anledninger: MISTANKE (mærkelig aktivitet, muligt læk), AFGANG (en medarbejder eller et bureau med nøgleadgang stopper – præcis som fælles kodeord roteres) og ALDER for de mest kritiske (årlig rotation af nøgler med skriveadgang til penge og ordrer er billig forsikring). Og så oprydningen: sæt et kvarter i kvartalet af til at gå nøglelisterne igennem – WooCommerce → REST API, brugernes applikationskodeord, integrationsplatformens forbindelser – med to spørgsmål pr. nøgle: bruges den stadig (mange viser „sidst brugt“ – kig på det), og ved vi, HVAD der bruger den? Alt uden godt svar slettes; en integration, der så fejler, afslører sig selv og får en ny, dokumenteret nøgle. Før listen i samme dokument som jeres øvrige adgange – én række pr. nøgle: navn, formål, rettighed, ejer.
Rækkefølgen er fast, og første skridt er IKKE at undersøge: 1) Tilbagekald/rotér nøglen NU – hvert minut, den lever, er et minut med åben dør. 2) Opret en ny med samme (minimale) rettigheder, og opdatér integrationen, så driften kører videre. 3) Undersøg så: hvad KUNNE nøglen – og viser logs (ordrer, prisændringer, eksporter, API-kald) tegn på misbrug i perioden? 4) Vurdér følgerne: havde nøglen adgang til persondata, skal hændelsen vurderes efter samme spor som andre sikkerhedshændelser – inklusive underretning, hvis data er berørt. 5) Luk hullet: HVOR lå nøglen, siden den lækkede – og hvilken vane skal ændres? En lækket nøgle, der tilbagekaldes på fem minutter, er en fodnote; en, der får leve en weekend, kan være en krise. Hastigheden ER beredskabet – og den kommer af, at nøglelisten fra forrige afsnit findes, så ingen skal lede efter, hvor man tilbagekalder hvad.
Én pr. integration – hverken færre (genbrug ødelægger sporbarhed og oprydning) eller flere (ubrugte nøgler er åbne døre). Antallet skal matche listen over aktive integrationer præcist.
Nej – en læsenøgle til ordrer kan lække kundedata, hvilket er en persondatahændelse. Men den kan ikke ÆNDRE noget – derfor er read-only stadig den rigtige standard, hvor skrivning ikke er nødvendig.
Altid ved mistanke og ved afgang af folk med adgang; årligt for nøgler med skriveadgang til ordrer og priser. Og ryd op kvartalsvis – sletning af ubrugte nøgler er den billigste rotation.
