Slik går du gjennom fjerntilgang og API-nøkler på bedriftens nettside

En bedriftsnettside har flere innganger enn innloggingsskjemaet. Dashbordet byrået oppdaterer utvidelser fra, en butikkapp med tilgang til ordrer, et Cloudflare-token i et skript som tømmer hurtigbufferen og en deploy-nøkkel på serveren gir alle tilgang uten administratorpassord. To hendelser i oktober 2026 viste hva som skjer når slike nøkler havner hos feil person. Denne guiden går gjennom hvordan du lister opp tilgangene, trekker tilbake det som ikke trengs og bytter resten, uansett om du bruker WordPress, WooCommerce, Shopify eller egenutviklet kode.

#Hva skjedde med UpdraftCentral

I hendelsesvarselet fra TeamUpdraft skriver selskapet at det oppdaget uautorisert tilgang til teamupdraft.com helgen 17. og 18. oktober, og at det mener kundedatabasen ble lest. Den inneholdt navn, e-postadresser, hashede passord, innstillinger for tofaktorinnlogging og tilkoblingsnøklene for UpdraftCentral, UpdraftVault og UpdraftClone. Kortdata lagrer selskapet ikke. Angriperen brukte tilkoblingen til kundenes nettsteder til å opprette administratorkontoer og installere skadelige utvidelser, og TeamUpdraft varslet senere om et mønster av uventede kontoer med rollen redaktør. UpdraftPlus 1.26.13 (gratis) og 2.26.13 (Premium), utgitt 19. oktober, kobler fra alle UpdraftCentral-tilkoblinger opprettet før 18. oktober kl. 13.07 britisk tid.

Analysen fra Patchstack forklarer hvorfor vanlige sperrer ikke hjalp. Kommandoene var signert med ekte dashbordnøkler, så alle kontroller i utvidelsen godtok dem. Et tilkoblet nettsted kjører alle signerte kommandoer med rettighetene til brukeren som opprettet tilkoblingen, og ingen godkjenner enkeltkommandoer. Mange eiere valgte aldri dette selv: da de koblet til en TeamUpdraft.com-konto, var boksen som meldte nettstedet inn i UpdraftCentral krysset av på forhånd. Nøklene utløp heller ikke, og Patchstack så nøkler fra november 2025 som fortsatt virket i oktober 2026. Bakdørskontoene så ut som redaktører, men hadde rettighetene manage_options og install_plugins, så en gjennomgang av administratorlisten fant dem ikke.

Noen dager før skrev Rank Math at PRO 3.0.123 lastet ned mellom 15. oktober kl. 20.02 UTC og 16. oktober kl. 07.12 UTC inneholdt skadevare. Versjon 3.0.124 er ren, og gratisversjonen fra WordPress.org var ikke rammet. Har du aktivert den infiserte versjonen, skal du gå ut fra at alle hemmeligheter på nettstedet er lekket, og bytte WordPress-passord, databasetilgang, nøkler og salter i wp-config.php, nøkler til betalingsløsninger, SMTP-tilgang, andre API-nøkler og tilgang til webhotell, FTP og SSH, i tillegg til å sjekke tofaktorinnstillingene for administratorer. Det større bildet finner du i artikkelen om forsyningskjedeangrep mot WordPress i 2026.

#Sjekkliste for tilganger til nettside og nettbutikk

#Hvordan sjekke hvem som har tilgang til nettsiden

Nøkler går begge veier. Nettstedet lagrer nøkler til andres systemer (betaling, e-post, sikkerhetskopier), og andres systemer lagrer nøkler til nettstedet ditt (dashbord, apper, utrulling). Listen fra Rank Math gjelder den første retningen, UpdraftCentral-saken den andre.

Oversikten henter du fra tre steder: selve nettstedet (brukere, utvidelser eller apper, innstillinger), bedriftens kontoer (fakturaer, passordbehandleren, innboksen der registreringsbekreftelser havner) og infrastrukturen (DNS, CDN, kontrollpanelet hos webhotellet, kodelageret). For hver oppføring noterer du tjenesten, hva den kan gjøre, hvem som opprettet nøkkelen, hvor nøkkelen ligger i begge ender, når den sist ble brukt og hvem i bedriften som eier den. En oppføring uten eier er første kandidat for sletting.

#Dashbord for drift av flere nettsteder

UpdraftCentral, ManageWP, MainWP og Jetpack kobler seg til nettstedet via en komponent i WordPress: UpdraftPlus har UpdraftCentral-klienten innebygd, ManageWP bruker utvidelsen ManageWP Worker og MainWP utvidelsen MainWP Child. Den andre halvdelen av tilgangsdataene ligger hos leverandøren eller på en server byrået drifter. Gå gjennom listen over utvidelser, også fanen for must-use-utvidelser, og spør byrået hvilke dashbord det bruker. Lærdommen fra Patchstack gjelder alle produkter av denne typen: det holder ikke å fjerne nettstedet fra dashbordet, for nøkkelen som teller, ligger på nettstedet.

#Butikkapper og integrasjoner med API-tilgang

I Shopify åpner du innstillingene, delen for apper, og klikker på hver app. Ifølge dokumentasjonen fra Shopify viser appens side hvilke deler av butikken den kan lese eller endre, med dato for siste aktivitet i hver del. Tillatelser som ikke er brukt de siste 30 dagene, vises i en egen del for ubrukt tilgang. Tilgangen read_all_orders utvider rekkevidden utover standardvinduet med ordrer fra de siste 60 dagene (tilgangsomfang), så spør hvorfor appen trenger den. Eksporter det du trenger før du avinstallerer, for noen apper lagrer data som ikke kan hentes tilbake etterpå.

I WooCommerce ligger nøklene i WooCommerce-innstillingene under avansert, REST API. Hver nøkkel hører til en WordPress-bruker og har lese-, skrive- eller lese- og skrivetilgang, og hemmeligheten vises bare én gang (dokumentasjonen fra WooCommerce). Sjekk hvem hver nøkkel tilhører og om personen fortsatt jobber med deg. Det samme gjelder nøkler til Vipps MobilePay eller regnskapssystemet som står i innstillingene til en utvidelse.

#Applikasjonspassord og tekniske kontoer

Med applikasjonspassord logger et verktøy inn i REST API med Basic Auth. Du oppretter og trekker dem tilbake på redigeringssiden for brukeren. WordPress-kjernen begrenser ikke omfanget: integrasjonsguiden nevner begrensning som fremtidig arbeid, så et applikasjonspassord kan gjøre alt brukeren kan. WordPress registrerer siste bruk (nøyaktig innenfor ett døgn) og siste IP-adresse. Med WP-CLI:

wp user list --role=administrator
wp user list --role=editor
wp user application-password list 1 --fields=name,created,last_used,last_ip

Redaktørlisten hører med etter UpdraftCentral-saken, fordi bakdørskontoene hadde akkurat den rollen.

#Tokener for CDN og DNS

Et token med skrivetilgang til DNS er nok til å sende domenet eller e-postoppføringene et annet sted. I Cloudflare begrenser du et API-token til utvalgte tillatelser og soner, og i tillegg til IP-adresser og en levetid (opprette token). Den eldre Global API key har tilgang til alle ressursene til en bruker med brukerens fulle rettigheter, og Cloudflare fraråder den for nye oppsett (Global API key). Bruker en utvidelse, en CI-jobb eller et skript den fortsatt, bytter du til et token for én sone.

#Deploy-nøkler i GitHub

En deploy-nøkkel er en SSH-nøkkel med tilgang til ett enkelt repo. Den kan bare lese som standard, og med skrivetilgang kan den det samme som et organisasjonsmedlem med administratorrettigheter. Ifølge dokumentasjonen fra GitHub har deploy-nøkler ingen utløpsdato, vanligvis ingen passordfrase, og de forblir aktive når personen som la dem til, fjernes fra repoet. Gå gjennom dem i innstillingene for repoet, under deploy-nøkler, slett dem du ikke kjenner igjen og godkjenn de gyldige.

#Nøkler til betaling, e-post og sikkerhetskopier

Stripe lar deg lage begrensede nøkler med tillatelser du velger selv, og når du bytter en nøkkel i dashbordet, bestemmer du når den gamle utløper: med en gang eller etter en frist som gir integrasjonen tid til å bytte (API-nøkler hos Stripe). SMTP-passordet eller API-nøkkelen til e-posttjenesten ligger i en utvidelse eller i wp-config.php; hvor, viser vi i SMTP-guiden.

En sikkerhetskopi inneholder hele databasen med kundedata og alle nøkler som er lagret i innstillingene. TeamUpdraft koblet alle nettsteder fra UpdraftVault og utstedte ny tilgang, og anbefalte nettsteder som ble åpnet via UpdraftCentral å godkjenne ekstern lagring (Google Drive, Dropbox, Amazon S3) på nytt og bytte tilgangsnøklene. Sjekk hvem som kan lese lagringen for sikkerhetskopier, og om verktøyet har rett til å slette gamle kopier.

#Nøkler til faktura- og ERP-systemer

Oppdatering, 24. oktober 2026. En WooCommerce-utvidelse eller Shopify-app som utsteder fakturaer i et eksternt system, lagrer API-nøkkelen til det systemet. I sitt varsel om hendelsen opplyste den polske fakturatjenesten Fakturownia at en uvedkommende fra 27. september 2026 (ca. kl. 3.20) til 28. september 2026 (ca. kl. 17.45) hadde tilgang til systemene og kopierte en stor del av databasen, blant annet API-tokener og integrasjonsnøkler lagret i kontoinnstillingene. Hendelsen gjelder alle kontoer. Natt til 29. september byttet selskapet kundenes API-tokener, og de gamle nøklene virker siden bare fra IP-adresser som brukerne av kontoen har brukt tidligere. Integrasjoner satt opp i fanen “Integracje i dodatki” (integrasjoner og tillegg) var ikke berørt. For de andre anbefaler Fakturownia å lage nye nøkler og legge dem inn i integrasjonene, og for integrasjoner fra eksterne leverandører først å avtale med leverandøren når det kan gjøres.

For kundedata som er lagt inn i kontoen, er virksomheten som bruker Fakturownia behandlingsansvarlig, og Fakturownia er databehandler. GDPR fordeler pliktene slik:

• databehandleren varsler den behandlingsansvarlige uten ugrunnet opphold etter å ha fått kjennskap til bruddet (artikkel 33 nr. 2); ifølge Fakturownia er e-posten til kontoeierne, sendt fra 1. oktober 2026, dette varselet,
• den behandlingsansvarlige melder bruddet til tilsynsmyndigheten (i Norge Datatilsynet) uten ugrunnet opphold og om mulig senest 72 timer etter å ha fått kjennskap til det, med mindre det er lite sannsynlig at bruddet vil medføre en risiko for fysiske personers rettigheter og friheter; meldes det ikke innen 72 timer, skal årsaken til forsinkelsen oppgis (artikkel 33 nr. 1),
• når bruddet sannsynligvis vil medføre en høy risiko for fysiske personers rettigheter og friheter, underretter den behandlingsansvarlige de registrerte uten ugrunnet opphold (artikkel 34 nr. 1),
• den behandlingsansvarlige dokumenterer alle brudd, også de som ikke meldes (artikkel 33 nr. 5).

I Norge melder den behandlingsansvarlige bruddet til Datatilsynet gjennom et skjema i Altinn. Den som melder, trenger fullmakt til tjenesten og elektronisk ID, og e-post eller vanlig post brukes bare når Altinn ikke er mulig. Har du ikke full oversikt innen 72-timersfristen, kan du melde trinnvis og skrive i første melding at utfyllende informasjon kommer.

I gjennomgangen bytter du nøkkelen til fakturasystemet etter hvert hendelsesvarsel fra leverandøren og sjekker om den kan begrenses til IP-adressen til butikkserveren din. Fakturownia innførte en slik begrensning for de gamle nøklene etter hendelsen.

#Hvordan trekke tilbake en API-nøkkel uten at nettsiden stopper

På et friskt nettsted er rekkefølgen denne: finn ut hva som bruker nøkkelen (beskrivelse, siste bruk, logger i verktøyet), lag en etterfølger med smalere tillatelser, legg den inn i verktøyet og test, og trekk først da tilbake den gamle. Følg med noen dager på mislykkede ordrer, manglende e-poster og feilet utrulling. Utløpsfristen hos Stripe finnes nettopp for dette byttet.

Etter et innbrudd snur du rekkefølgen: trekk tilbake først, og koble til integrasjonene som stopper på nytt etterpå. Slik er instruksene fra TeamUpdraft til UpdraftCentral-brukere bygget opp: logg inn direkte på hvert nettsted, oppdater, slett tilkoblingsnøkkelen, fjern ukjente kontoer og utvidelser, bytt administratorpassord og koble til på nytt til slutt. Har nøkkelen to ender, trekker du den tilbake i begge. En nøkkel som bare er slettet i leverandørens panel, kan fortsatt bli godtatt av nettstedet, og en nøkkel som bare er slettet på nettstedet, kan fortsatt ligge i leverandørens database.

#Når bør du bytte API-nøkler

Bytt når noe skjer, for en kalender alene hadde ikke hjulpet noen i oktober 2026. Disse utløserne bør stå i rutinene:

• en sikkerhetshendelse hos en leverandør som har en nøkkel til nettstedet ditt eller får en fra det,
• skadekode som har kjørt på nettstedet, altså alt på listen fra Rank Math over,
• en ansatt, frilanser eller et byrå som mister tilgangen,
• en nøkkel som dukker opp der den ikke skal være: i et repo, en supportsak, en e-posttråd eller et skjermbilde,
• en integrasjon som erstattes av et annet verktøy.

Legg til én fast gjennomgang i året der du sletter alle nøkler ingen kan forklare. Nøkler uten utløpsdato, som deploy-nøkler i GitHub eller UpdraftCentral-nøklene Patchstack undersøkte, gjelder til noen fjerner dem.

#Hvordan rotere API-nøkler i Stripe, Shopify, Cloudflare og GitHub

Rekkefølgen over gjelder overalt, men hver plattform har sine egne brytere. Stegene under er hentet fra leverandørenes dokumentasjon slik den så ut i oktober 2026.

#Stripe

På siden for API-nøkler åpner du menyen ved nøkkelen og velger visning av forespørselslogger. Workbench viser da hvilke systemer som fortsatt kaller Stripe med nøkkelen. Velg så rotering og sett når den gamle nøkkelen skal utløpe. Ifølge Stripes dokumentasjon kan gammel og ny nøkkel virke side om side i opptil 7 dager etter en rotering i dashbordet. Trenger du lenger tid, lager du en ny nøkkel manuelt og lar den gamle utløpe når byttet er ferdig. Stripe anbefaler å la den gamle utløpe først når den har hatt null forespørsler i noen timer eller dager.

Gi hver live-nøkkel en tilgangspolicy. Den låser nøkkelen til IPv4-adresser eller CIDR-områder, eller til et ASN og et land for servere som skalerer dynamisk, og den kan blokkere anonyme VPN-er, offentlige proxyer og Tor-utgangsnoder. Forespørsler som bryter policyen, blokkerer Stripe og varsler deg om. Stripe anbefaler begrensede nøkler (rk_) for de fleste integrasjoner og anbefaler ikke lenger ubegrensede hemmelige nøkler til nye. Signeringshemmeligheter for webhooks er atskilt fra API-nøklene og endres ikke ved rotering.

#Shopify

Fra 1. januar 2026 lages og administreres egne apper i Dev Dashboard, mens egne apper opprettet i administrasjonen før denne datoen fortsatt styres der som eldre apper (egne apper). Det avgjør hvordan du roterer. Ifølge Shopifys veiledning får en app i Dev Dashboard ny klienthemmelighet under Settings, Credentials, Rotate, og den gamle virker til du trekker den tilbake. Shopify signerer webhooks med den eldste hemmeligheten som ikke er trukket tilbake, så appen må godta begge signaturene mens byttet pågår. Tokener fra client credentials varer i 24 timer. Trekk tilbake den gamle hemmeligheten først når alle lagrede tokener er byttet, for tokener som er knyttet til den, slutter å virke i samme øyeblikk. En eldre app laget i administrasjonen kan ikke rotere hemmeligheten sin: for å endre tilgangsdataene må butikken avinstallere og installere appen på nytt. Blir en hemmelighet misbrukt akkurat nå, sier Shopify at du skal trekke den tilbake med en gang og godta at appen står til den nye er på plass.

#Cloudflare

Når du lager det nye tokenet, fyller du ut de to valgfrie feltene mange hopper over. Filtrering på klientens IP-adresse: uten regel kan alle IP-adresser bruke tokenet, en Is in-regel begrenser det til oppgitte adresser eller CIDR-områder, og Is not in unntar enkeltadresser fra et område. TTL: en startdato (notBefore) og en sluttdato (notAfter). Et token uten sluttdato utløper aldri, og datoene gjelder fra kl. 00.00 UTC den valgte dagen (begrense tokener).

#GitHub

Et fine-grained personal access token når ressursene til én bruker eller én organisasjon og kan begrenses til utvalgte repositorier. Utløpstiden settes til mellom 1 og 366 dager eller ingen, standard er 30 dager, og en organisasjonspolicy kan forby tokener uten utløp. Tokener som ikke er brukt på et år, fjerner GitHub selv (administrere tokener). Sletter du et token som ble brukt til å lage en deploy-nøkkel, forsvinner deploy-nøkkelen også. Organisasjonseiere kan se og trekke tilbake fine-grained tokener, men ikke klassiske, og et klassisk token beholder tilgangen til det utløper, med mindre organisasjonen har begrenset klassiske tokener (gjennomgå tokener i en organisasjon).

#Hva du stenger når en ansatt eller et byrå slutter

Gå gjennom listen samme dag som tilgangen skal opphøre:

1. WordPress: slett personens applikasjonspassord, avslutt øktene, slett kontoen og overfør innleggene til en annen bruker (WP-CLI):

wp user application-password delete 123 --all
wp user session destroy 123 --all
wp user delete 123 --reassign=2

2. WooCommerce: trekk tilbake alle REST API-nøkler som hører til brukeren. Nøkler som en integrasjon fortsatt trenger, lager du på nytt under en egen teknisk konto, med beskrivelse og smaleste tillatelse. Consumer secret vises bare én gang.
3. Shopify: fjern ansatt- eller samarbeidspartnerkontoen og se over appene den installerte. Egne apper krever tillatelsen App development, Develop, og samarbeidspartnerkontoer kan ikke bruke Dev Dashboard.
4. Cloudflare: slett tokenene personen laget, eller rull dem som en integrasjon fortsatt bruker, og les Audit Logs for perioden personen hadde tilgang. Cloudflare tar vare på dem i 18 måneder (revisjonslogger).
5. GitHub: fjern personen fra repositoriet eller organisasjonen, slett deploy-nøkler på servere vedkommende satte opp, og trekk tilbake fine-grained tokener. Den som laget tokenet, får e-post, og SSH-nøkler laget med et tilbaketrukket token virker videre, så de må slettes for seg.
6. Stripe: roter alle hemmelige og begrensede nøkler personen kunne se. Stripe nevner selv at et teammedlem slutter eller bytter rolle som grunn til rotering.
7. Fjernstyring og sikkerhetskopier: slett tilkoblingsnøkkelen på hver nettside og autoriser lagringen for sikkerhetskopier på nytt.

#Hvor ser du når en nøkkel sist ble brukt

• WordPress viser siste bruk av hvert applikasjonspassord (med et døgns nøyaktighet) og siste IP-adresse.
• Stripe har forespørselslogger per nøkkel og varsler når en tilgangspolicy blokkerer en forespørsel. Det er det eneste stedet her som sier fra av seg selv, så sett opp policyene først.
• Cloudflare samler endringer i konto og soner i Audit Logs.
• GitHub viser organisasjonseiere hvilke fine-grained tokener som har tilgang.
• Shopify viser på appens side siste bruk av hver tillatelse og tilganger som ikke er brukt på 30 dager.

Gå gjennom disse fem skjermbildene ved den årlige gjennomgangen og etter hver hendelse i listen over.

#Hva du bør kreve av byrå og programvareleverandører

Et byrå som drifter nettsiden din, oppretter nøkler på dine vegne. For virksomheter som omfattes av digitalsikkerhetsloven, som trådte i kraft 1. oktober 2025 sammen med digitalsikkerhetsforskriften og gjennomfører NIS1 i norsk rett, er oversikt over leverandørtilganger en del av sikkerhetsarbeidet. Hvordan loven treffer WordPress-leveranser, beskriver vi i artikkelen om WordPress i Norge etter NIS2. Uavhengig av det bør disse punktene stå i avtalen:

• et register over alle nøkler, tokener og kontoer byrået oppretter, med formål og eier, som leveres ved forespørsel og ved avtaleslutt,
• nøkler opprettet i dine egne kontoer der plattformen tillater det, for eksempel et Cloudflare-token i din konto begrenset til din sone, slik at tilbaketrekking ikke avhenger av byrået,
• én nøkkel per nettsted og verktøy, og personlige kontoer i stedet for én felles byråinnlogging,
• tilbaketrekking av all tilgang innen et avtalt antall dager etter avtaleslutt, bekreftet skriftlig,
• en varslingsfrist for hendelser. Et byrå med tilgang til kundedata er som regel databehandler, så du trenger en databehandleravtale etter artikkel 28 i personvernforordningen. Etter artikkel 33 skal databehandleren varsle deg uten ugrunnet opphold, og du har 72 timer, der det er mulig, til å melde bruddet til Datatilsynet. Skriv et konkret antall timer inn i avtalen.

Før du installerer noe med fjernfunksjoner, bør du spørre leverandøren om fjerntilkoblingen er slått på som standard og om nøklene utløper. For UpdraftCentral fant Patchstack en forhåndsavkrysset boks og nøkler uten utløpsdato.

Denne gjennomgangen gjør vi som del av en sikkerhetsrevisjon av WordPress, og nøkkelregisteret holder vi oppdatert i vedlikehold av WordPress-nettsider. For WooCommerce-butikker inngår den i planen for stabil nettbutikk, og i Shopify-butikker går vi gjennom apptillatelser som Shopify-utvikler. Hvordan oppdateringer av utvidelser når nettstedet, og hvor en manipulert versjon kan slippe gjennom, kan du lese om i artiklene om forsinkede oppdateringer fra WordPress.org og fire bakdører på en måned.