Unohtuneet API-avaimet: näin perut ne pysäyttämättä palvelua

OpenRouterin sisäinen tarkastus löysi 85 työntekijältään yli 1 000 aktiivista API-avainta; yhtiön mukaan 168 avainta ei ollut käytetty kuukausiin. Nämä luvut ovat OpenRouterin omaa auditointia, eivät riippumaton toimialatutkimus. Yksittäisenä esimerkkinä ne kuitenkin havainnollistavat tuttua teknistä ansaa: avaimen voi unohtaa, mutta ei sovellusta, joka on siitä riippuvainen. Yhtiö päiväsi Security Centerin julkistuksen 28. syyskuuta 2026.

Ongelma ei ratkea etsimällä vanhin tunniste ja poistamalla se. Tiimin on selvitettävä omistaja ja avaimen käyttöpaikat sekä se, miten avain voidaan vaihtaa sammuttamatta harvoin suoritettavaa tehtävää tai unohtunutta palvelua. Ilman näitä tietoja käyttöoikeuden peruminen muuttuu siivouksen sijaan riskialttiiksi kokeiluksi.

Mitä Security Center näyttää – ja mitä se ei todista

OpenRouterin kuvauksen mukaan Security Center kokoaa tilin avaimet yhteen ja näyttää omistajan, viimeisimmän käytön, kulutusrajan ja vanhenemisajan; organisaation ylläpitäjät näkevät kaikki avaimet, kun taas jäsenet näkevät itse luomansa avaimet. Joukkotoimintoihin voi valita enintään 500 avainta: ne voi poistaa käytöstä, arkistoida tai niille voi asettaa kulutusrajan. Käytöstä poistamisen voi perua, arkistointia ei. Nämä ovat palveluntarjoajan itsensä kuvaamia työkalun ominaisuuksia, eivät riippumaton arvio sen tehokkuudesta.

Erityisen tärkeää on tulkita ”voidaan poistaa” -tilaa tarkistuskehotuksena, ei todisteena riippuvuuksien puuttumisesta. Käyttömittari kertoo aiemmista pyynnöistä, mutta ei välttämättä sitä, mille ajastetulle tehtävälle, häiriötilanteen toimintamallille tai kausittaiselle prosessille avain kuuluu. OpenRouter itse suosittelee varmistamaan asian omistajalta; myös tietoturva-asetusten dokumentaatio kehottaa tarkistamaan riippuvuudet ennen käytöstä poistamista tai arkistointia.

Verkkorajoituksiin liittyy erillinen huomio: IP-osoitteiden sallittujen luettelo on Enterprise-tilauksen ylläpitäjien käytettävissä, ja se koskee organisaation kaikkia avaimia. Luettelon ulkopuolisista osoitteista tulevat pyynnöt hylätään 403-virheellä, ja muutokset astuvat voimaan heti. Siksi tuotantopalvelinten, toimistoverkon ja CI-ajojen IP-osoitteet on huomioitava ennen rajoituksen käyttöönottoa; muuten suojaustoimi voi keskeyttää lailliset kutsut.

Avainten siivousjärjestys: ensin omistaja, sitten käytöstä poisto

1. Laadi luettelo. Kirjaa jokaisesta avaimesta omistaja, käyttötarkoitus, ympäristö, käyttäjät, kulutusraja ja vanhenemisaika. Jos järjestelmä näyttää omistajana vain henkilön, nimeä myös tiimi tai palvelu, joka ottaa vastuun hänen lähtiessään.
2. Tarkista käyttö ja riippuvuudet. Vertaa viimeisimmän pyynnön ajankohtaa taustatehtävien aikatauluihin, varajärjestelyihin, julkaisupipelineihin ja ulkoisiin integraatioihin. Viimeaikaisen aktiivisuuden puuttuminen on syy kysyä omistajalta, ei riittävä peruste välittömälle poistamiselle.
3. Pienennä riskiä ennen siirtoa. Aseta kohtuullinen kulutusraja ja vanhenemisaika, jos niitä tuetaan. Noudata vähimpien oikeuksien periaatetta ja salaisuuksien säilytyskäytäntöjä: OWASP:n salaisuuksien hallintaohje käsittelee tunnisteiden kirjanpitoa, käyttöoikeuksia ja elinkaarta prosessin erillisinä osina.
4. Luo korvaava avain ja siirrä käyttäjät. Päivitä salaisuus salaisuuksien hallintaan tarkoitettuun varastoon tai käyttöönoton asetuksiin ja siirrä sovellukset uuteen avaimeen vaiheittain. Älä liitä avaimen arvoa tiketteihin, lokeihin tai lähdekoodiin.
5. Varmista tuotantokäyttö ennen vanhan avaimen perumista. Varmista, että uusi avain toimii kaikissa tunnetuissa käyttökohteissa, myös CI:ssä ja harvoin suoritettavissa tehtävissä. Poista sitten vanha avain ensin käytöstä, jos se voidaan palauttaa käyttöön. Arkistoi tai poista se vasta, kun siirto on vahvistettu ja sovittu seuranta-aika on kulunut.

Järjestys ”luo uusi avain → siirrä sovellukset → varmista toiminta → poista vanha” vastaa OpenRouterin avainten kierrätysohjetta. Kyseessä on suositeltu toimintatapa, ei takuu katkottomuudesta: lopputulos riippuu siitä, löytyivätkö kaikki tunnistetta käyttävät järjestelmät.

Palvelun avaimet eivät kata organisaation kaikkia salaisuuksia

Yksittäisen palveluntarjoajan hallintapaneelilla voi hallita kyseisen palvelun avaimia, mutta se ei itsessään tuo yhteen pilvipalveluiden, tietokantojen, CI/CD:n ja muiden rajapintojen salaisuuksia. OWASP:n yleinen salaisuuksien elinkaarta koskeva ohje kattaa keskitetyn tallennuksen, käyttöoikeuksien hallinnan, auditoinnin, kierrätyksen ja käytöstä poistamisen. Myös Google Cloudin ohjeissa neuvotaan rajaamaan avainten käyttöalaa, poistamaan tarpeettomat tunnisteet ja seuraamaan niiden käyttöä.

OpenRouter kertoo myös, että Security Center käyttää avainten metatietoja, kulutusta ja vanhenemisaikoja eikä lue kehotteita tai vastauksia. Tämä on palveluntarjoajan oma väite; tarkastelluista lähteistä ei löytynyt riippumatonta teknistä varmennusta. Hallintapaneelin olemassaolo ei yleisesti todista, että tiimi olisi jo vähentänyt tietoturvapoikkeamia tai kuluja: tarkastelluista materiaaleista ei löytynyt julkisia käyttöönoton jälkeisiä tuloksia.