Mahdollinen arkinen tilanne: lomake näkyy yhä, mutta sen jälkeinen rajapinta ei enää vastaanota pyyntöjä. Tai yöllinen tuonti pysähtyy, koska tunnistautuminen ei enää kelpaa. Riippuvuudet huomataan usein vasta liiketoimintaprosessin jäädessä toteutumatta.
API-tunniste tarvitsee siksi muutakin kuin turvallisen säilytyspaikan. Vastuu, voimassaolo, vaihtotapa ja todellisen toiminnan tarkistus kuuluvat yhteen. Tämä koskee API-avaimia, OAuth-asiakastunnisteita, palvelutilejä ja varmenteita, joilla on eri säännöt.
Vanheneminen, kierto ja peruminen ovat eri tapahtumia
Kiinteä vanhenemispäivä voi teknisesti estää jatkokäytön. Kiertosääntö puolestaan kertoo, milloin tunniste tulisi vaihtaa. Palveluntarjoaja voi pakottaa sen tai siitä sovitaan käytössä. Peruminen lopettaa käyttöoikeuden tietystä syystä ja voi koskea vielä voimassa olevaa tunnistetta.
Kaikilla avaimilla ei automaattisesti ole sama käyttöikä. Google esimerkiksi dokumentoi käyttäjän luomille palvelutiliavaimille oletuksena rajattoman voimassaolon; organisaation käytännöt voivat muuttaa tätä. Microsoft Entran asiakassalaisuuksilla on sen sijaan määritelty voimassaolo. Kirjataan todellisen myöntäjän sääntö eikä oleteta samaa aikaväliä kaikille palveluille.
OAuthissa pääsytunniste, mahdollinen päivitystunniste ja sovelluksen tunnistetiedot ovat eri asioita. Niiden elinkaaria ei saa yhdistää yhdeksi ”API-avaimeksi” luettelossa. Palvelutilin identiteetti ei myöskään ole sama kuin sen yksittäinen avain.
Luettelo tarvitsee vastuut, ilman selväkielisiä salaisuuksia
Jokaisesta tärkeästä integraatiotunnisteesta kirjataan vähintään palvelu, projekti, riippuvainen prosessi, myöntäjä ja tunnistetyyppi. Lisäksi vastuuhenkilö tai rooli, varahenkilö ja tavoitettava eskalointireitti. Varoituksen vastaanottajan on tiedettävä riippuvainen liiketoimintaprosessi.
- Sääntö: Myöntämispäivä, todellinen vanheneminen tai nimenomainen vanhenemattomuus, suunniteltu kierto ja tarjoajan mahdolliset muutokset.
- Riippuvuudet: Tunnistetta käyttävät sovellukset, ajot, asennukset ja erilliset ympäristöt.
- Säilytys: Viite hyväksyttyyn salaisuuksien säilöön ja sen hallintaan; ei raaka-arvoja luetteloon.
- Vaihto: Testimenetelmä, ennakkoaika, hyväksyntä, paluureitti ja viimeisen onnistuneen testin päivä.
Salaisuussäilön päiväys ja myöntäjän teknisesti soveltama voimassaolo tarkistetaan erikseen. Metatiedon ylläpito ei itsessään uusi tunnistetta tarjoajalla.
Varoita ajoissa ja testaa todellinen toiminta
Varoituksen on jätettävä aikaa hyväksyntään, valmisteluun ja testiin. Ennakkoaika riippuu tarjoajasta, riskistä ja järjestelyistä. Vastaanottaja ilman varahenkilöä tai varoitus ongelmallisen integraation kautta luo tarpeettoman riippuvuuden.
Seurataan myös odotettua toimintaa: tulevatko pyynnöt perille? Toimiiko tuonti? Käsitelläänkö tarkoitettu mallipyyntö? Virheasteet, puuttuvat ajot ja toistettavat testit paljastavat poikkeamia ilman lähestyvää vanhenemistakin. Tarkistuksen tulisi tuottaa mahdollisimman vähän lisädataa ja kustannuksia.
Epäonnistunut kutsu ei automaattisesti tarkoita vanhentunutta avainta. Oikeudet, kiintiöt, laskutus tai maksutila, tarjoajamuutokset ja tekninen saavutettavuus tutkitaan erikseen. Virhe ja sen vaikutus määräävät seuraavan toimen.
| Tapahtuma | Merkitys | Sopiva valmistelu |
|---|---|---|
| Tekninen vanheneminen | Tunniste päättyy myöntäjän säännön mukaan. | Tarkista päivä, vaihda ajoissa ja testaa toiminta. |
| Suunniteltu kierto | Nykyinen tunniste vaihdetaan suunnitelman mukaan. | Tunne kaikki käyttäjäjärjestelmät, testaa siirtymä ja paluu. |
| Peruminen tai poistaminen | Käyttöoikeus lopetetaan tarkoituksellisesti. | Huomioi syy, tunnisteet ja käynnissä olevat toiminnot. |
| Muu integraatiovirhe | Esimerkiksi oikeudet, kiintiö, maksutila tai saavutettavuus. | Tutki tarkka syy ja liiketoimintaprosessi erikseen. |
Suunnittele vaihto yhtenä kokonaisuutena
Jos tarjoaja tukee useita yhtä aikaa voimassa olevia tunnisteita, uuden voi valmistella vanhan yhä toimiessa. Microsoft kuvaa periaatteen esimerkiksi kahden avaimen resursseille. Tämä on tarjoajakohtainen mahdollisuus, ei lupaus jokaiselle APIlle.
- Valmistele: Tarkista oikeudet ja kaikki käyttäjäjärjestelmät, toimita uusi tunniste tarkoitettuun turvalliseen säilöön.
- Testaa: Varmista oikeasti tarvittavat toiminnot uudella tunnisteella sopivassa testiympäristössä tai hallitussa laajuudessa.
- Vaihda: Päivitä sovellukset ja ajot järjestyksessä; huomioi latauskäyttäytyminen ja mahdolliset välimuistit.
- Seuraa: Tarkista toiminta ja virheiden kehitys. Selvitä, tarvitseeko huomaamatta jäänyt käyttäjäjärjestelmä yhä vanhaa tunnistetta.
- Viimeistele: Peru vanha tunniste vahvistetun vaihdon jälkeen ja päivitä luettelo sekä käyttöohjeet.
Jos vain yksi tunniste voi olla voimassa, vaihto vaatii tarkempaa koordinointia. Sovittu huoltoikkuna voi auttaa. Paluureitti määritellään etukäteen; vaarantunutta tai peruttua vanhaa tunnistetta ei vain aktivoida uudelleen.
Vähennä pysyvien avainten tarvetta mahdollisuuksien mukaan
Sopivat alustat tarjoavat sovelluksille hallittuja identiteettejä tai federoitua tunnistautumista. Ne voivat vähentää itse jaettujen pitkäikäisten salaisuuksien käsittelyä. Soveltuvuus, kohdeoikeudet, voimassaolo ja palautus tarkistetaan silti. Varmenteellakin on elinkaari.
Salaisuusskanneri täydentää suojausta tunnistamalla mahdollisesti julkaistuja tunnistetietoja. Se ei ylläpidä käytön riippuvuusluetteloa eikä vaihda tunnistetta kaikissa käyttäjäjärjestelmissä. Vuotojen etsintä ja voimassaolon hallinta ovat eri tehtäviä.
Aloita liiketoimintakriittisistä yhteyksistä
DAXS kirjaa tärkeät rajapinnat ja vastuut, tarkistaa varoitusreitit ja luo toistettavan vaihdon. Pilotti voi alkaa lomakelähetyksestä, tuonnista tai malliyhteydestä. Ne ovat mahdollisia testejä, eivät väitteitä asiakkaiden häiriöistä.
Meidän kehitys- ja integraatiopalvelumme sekä MCP- ja rajapintasivu selittävät liittämisen. Meidän artikkelimme projektikohtaisista MCP-oikeuksista täydentää hallittua pääsyä. Voit pyytää integraatiotunnisteidesi kartoitusta.
Usein kysytyt kysymykset
Onko jokainen API-avain luotava säännöllisesti uudelleen?
Kaikille tarjoajille ei ole yhtä sääntöä. Voimassaolo, myöntäjän säännöt, riski ja vaihtoprosessi tarkistetaan tapauskohtaisesti. Avain ilman kiinteää vanhenemista tarvitsee yhä järjestelmällistä hallintaa.
Riittääkö sähköposti vähän ennen vanhenemista?
Varoitus auttaa vain, jos vastuu, varahenkilö ja testattu prosessi on olemassa. Myös riippuvaisen toiminnon todellisen toiminnan tulee näkyä.
Voiko kierto aina tapahtua keskeytyksettä?
Se riippuu tarjoajasta, rinnakkain käytettävistä tunnisteista ja sovellusten latauskäytöksestä. Jos päällekkäinen vaihto ei onnistu, suunnitellaan koordinoitu menettely ja sopiva huoltoikkuna.
Lähteet: Google Cloud: palvelutiliavaimet ja vanheneminen (ulkoinen linkki) · Microsoft: sovellustunnisteet ja kierto (ulkoinen linkki) · Microsoft: vaihto kahdella tunnisteella (ulkoinen linkki) · Microsoft: kierto yhdellä tunnisteella (ulkoinen linkki) · IETF: OAuth-tunnisteet ja sovelluksen tunnistautuminen (ulkoinen linkki) · OWASP: salaisuuksien elinkaari (ulkoinen linkki) · GitHub: salaisuusskannauksen laajuus (ulkoinen linkki)
Mahdollisia tilanteita ja yksinkertaistettuja prosesseja; tarkat säännöt ja vaihtotavat riippuvat tarjoajasta ja sovelluksesta. Kaavio ja kuvituskuva eivät esitä asiakkaan kokoonpanoa.
