Glemte API-nøkler: Slik tilbakekaller du dem uten å stanse tjenesten

En intern gjennomgang hos OpenRouter fant over 1 000 aktive API-nøkler fordelt på 85 ansatte; 168 nøkler hadde ifølge selskapet ikke vært brukt på flere måneder. Dette er tall fra OpenRouters egen gjennomgang, ikke en uavhengig bransjeundersøkelse. Men selv som et enkeltstående eksempel illustrerer de en velkjent ingeniørfelle: Det er lett å glemme en nøkkel, men ikke nødvendigvis applikasjonen som er avhengig av den. Selskapet daterte kunngjøringen av Security Center til 28. september 2026.

Problemet handler ikke bare om å finne den eldste credentialen og slette den. Teamet må finne ut hvem som eier den, hvor nøkkelen brukes, og hvordan den kan erstattes uten å slå av en sjelden jobb eller en glemt tjeneste. Uten denne informasjonen blir tilbakekalling av tilgang et risikabelt eksperiment i stedet for opprydding.

Hva du kan se i Security Center – og hva det ikke beviser

Ifølge OpenRouters beskrivelse samler Security Center kontoens nøkler og viser eier, siste bruk, utgiftsgrense og utløpsdato. Organisasjonsadministratorer kan se alle nøkler, mens medlemmer kan se dem de selv har opprettet. For massehandlinger kan du velge opptil 500 nøkler og deaktivere eller arkivere dem, eller angi en utgiftsgrense. Deaktivering kan angres, mens arkivering ikke kan reverseres. Dette er egenskaper ved verktøyet slik leverandøren selv beskriver dem, ikke en uavhengig vurdering av hvor effektivt det er.

Det er særlig viktig å lese statusen «kan slettes» som en oppfordring til å undersøke, ikke som bevis på at det ikke finnes avhengigheter. Bruksdata viser tidligere forespørsler, men forklarer ikke nødvendigvis hvilken cron-jobb, beredskapsløsning eller sesongprosess nøkkelen tilhører. OpenRouter anbefaler selv at du bekrefter sletting med eieren; dokumentasjonen om sikkerhetsinnstillinger advarer også mot å deaktivere eller arkivere før du har kontrollert avhengighetene.

Nettverksbegrensninger har et eget forbehold: IP-allowlisting er tilgjengelig for administratorer på Enterprise-abonnementet og gjelder alle organisasjonens nøkler. Forespørsler fra adresser utenfor listen avvises med feilen 403, og endringer trer i kraft umiddelbart. Før du aktiverer begrensningen, må du derfor ta høyde for adressene til produksjonsservere, kontornettverk og CI-runners. Ellers kan sikkerhetstiltaket i seg selv avbryte legitime kall.

Rekkefølge for opprydding: Finn eieren før du tilbakekaller

1. Lag en oversikt. Registrer eier, formål, miljø, brukere, utgiftsgrense og utløpsdato for hver nøkkel. Hvis systemet bare viser en person som eier, bør du også utpeke et team eller en tjeneste som overtar ansvaret hvis personen slutter.
2. Kontroller bruk og avhengigheter. Sammenlign tidspunktet for siste forespørsel med tidsplaner for bakgrunnsjobber, beredskapsløsninger, utrullingspipeliner og eksterne integrasjoner. Manglende nylig aktivitet er en grunn til å spørre eieren, ikke tilstrekkelig grunnlag for å slette nøkkelen umiddelbart.
3. Reduser risikoen før migreringen. Der det støttes, angir du en fornuftig utgiftsgrense og utløpsdato. Følg prinsippet om minste privilegium og reglene for håndtering av hemmeligheter: OWAPs veiledning om hemmelighetsadministrasjon behandler oversikt, tilgang og livssyklus for credentials som egne deler av prosessen.
4. Opprett en erstatning og flytt brukerne over. Oppdater hemmeligheten i hemmelighetslageret eller utrullingskonfigurasjonen, og flytt deretter applikasjonene over trinnvis. Ikke lim nøkkelverdien inn i saker, logger eller kildekode.
5. Kontroller produksjonsmiljøet før tilbakekalling. Forsikre deg om at den nye nøkkelen fungerer for alle kjente brukere, inkludert CI og sjeldne jobber. Deaktiver deretter den gamle nøkkelen først, hvis dette kan angres. Arkiver eller slett den etter at migreringen er bekreftet og den avtalte observasjonsperioden er over.

Rekkefølgen «opprett en ny nøkkel → flytt applikasjonene over → kontroller at alt fungerer → slett den gamle» samsvarer med OpenRouters veiledning for nøkkelrotasjon. Dette er anbefalt fremgangsmåte, ikke en garanti mot nedetid: Resultatet avhenger av om du har funnet alle systemene som bruker credentialen.

Tjenestenøkler er ikke alle organisasjonens hemmeligheter

Et kontrollpanel fra en bestemt leverandør gjør det enklere å administrere nøkler for denne tjenesten, men samler ikke automatisk hemmeligheter fra skyen, databaser, CI/CD og andre API-er. OWASPs generelle anbefalinger om hemmeligheters livssyklus dekker sentralisert lagring, tilgangskontroll, revisjon, rotasjon og tilbakekalling. Googles anbefalinger for Google Cloud råder også til å begrense hva nøkler kan brukes til, fjerne unødvendige credentials og følge med på bruken.

OpenRouter hevder også at Security Center bruker metadata om nøkler, utgifter og utløpsdatoer, og ikke leser prompter eller svar. Dette er leverandørens egen påstand; vi fant ingen uavhengig teknisk kontroll i kildene som ble gjennomgått. Og det at et kontrollpanel finnes, beviser ikke i seg selv at teamet har redusert antallet hendelser eller utgiftene: Vi fant ingen offentliggjorte resultater etter lanseringen i materialet vi undersøkte.