Shopify-sovellusten tietoturva: valmistaudu vuoden 2027 token-määräaikaan

Shopify App Security: Prepare for the 2027 Token Deadline

Shopify-sovellusten tietoturva kuuluu nyt verkkokaupan arjen suunnitteluun. Shopify on vahvistanut, että Admin APIa käyttävien julkisten sovellusten on siirryttävä vanheneviin offline-käyttöoikeustokeneihin 1. tammikuuta 2027 mennessä. Kauppiaat eivät yleensä hallinnoi näitä tokeneita itse, mutta monet kaupan toiminnot tarvitsevat niiden myöntämiä käyttöoikeuksia. Näin selvität toimittajiesi valmiuden, annat kehittäjille selkeän toimeksiannon ja vältät tulkitsemasta App Storen määräaikaa sovellusten välittömäksi sulkemiseksi.

Shopify-sovellusten tietoturva: mikä muuttuu tammikuussa 2027?

Shopifyn lokakuun tietoturvatiedote vahvistaa siirtymävaatimuksen ja kertoo sen vaiheittaisesta toimeenpanosta. Soveltamisalalla on merkitystä: ilmoitettu määräaika koskee Admin APIa käyttäviä julkisia sovelluksia. Älä oleta, että kaikilla yrityksesi integraatioilla on sama jakelumalli tai siirtymävelvoite.

1. tammikuuta 2027: vaatimuksia täyttämättömät sovellukset poistetaan Shopify App Storen valikoimasta, ja niiden uudet asennukset estetään. Olemassa olevat asennukset toimivat tässä vaiheessa edelleen.
15. tammikuuta 2027: kyseisiä sovelluksia käyttävät kauppiaat näkevät varoituksen Shopifyn hallintapaneelissa.

Nämä ovat eri seurauksia. Se, että olemassa oleva asennus toimii tammikuussa, ei todista toimittajan saaneen siirtymää valmiiksi. Shopifyn tietoturvatiedotteessa kerrotaan myös myöhemmistä toimista. Pyydä kehittäjää tarkistamaan koko ajantasainen aikataulu ennen julkaisusuunnitelman hyväksymistä.

Suosittelemme hankkimaan näytön valmiudesta ennen määräaikaa sen sijaan, että odottaisit hallintapaneelin varoitusta. Liiketoiminnalle kriittisen sovelluksen vaihtaminen kiireessä on harvoin mutkatonta, varsinkaan silloin, kun myös sen tiedot on siirrettävä.

Mikä on vanheneva offline-käyttöoikeustoken?

Offline-käyttöoikeustoken antaa sovellukselle pääsyn Shopifyn Admin APIin ilman, että kauppias käyttää sovellusta aktiivisesti. Esimerkiksi ajastettu tietojen synkronointi voi tarvita tätä käyttöoikeutta.

Vanheneva offline-käyttöoikeustoken on voimassa rajatun ajan. Sovelluksen on huolehdittava valtuutetun pääsyn jatkumisesta sen sijaan, että se olettaisi saman tunnisteen toimivan loputtomasti. Kauppiaan kannalta olennainen kysymys on, jatkuvatko automaattiset taustatehtävät myös tunnisteen vanhennuttua.

Shopifyn siirtymää koskevassa tiedotteessa esitellään myös uusi client credentials -käyttöoikeusmenetelmä. Taustajärjestelmä voi hakea uuden, lyhytikäisen käyttöoikeustokenin sovelluksen yksityisellä avaimella allekirjoitetulla pyynnöllä ilman refresh tokenia. Shopifyn mukaan näin käyttöoikeus voidaan palauttaa odottamatta, että kauppias avaa sovelluksen uudelleen.

Tämä on hyödyllistä, mutta palautusmekanismin olemassaolo ei takaa, että sovellus hyödyntää sitä oikein. Onnistunut kirjautumistesti kertoo vain vähän yön aikana ajettavasta tehtävästä. Pyydä kehittäjiä testaamaan sovellusta myös silloin, kun se ei ole kenelläkään avoinna.

Lisää tietoturva osaksi sovellusvertailua

Uusissakin sovellusoppaissa painottuvat usein ominaisuudet ja hinta. Esimerkiksi AiTrillionin vertailussa arvioita, keskeisiä toimintoja ja alkaen-hintoja tarkastellaan rinnakkain. Ne auttavat rajaamaan vaihtoehtoja, mutta sovellustoimittajan laatima vertailu ei ole riippumaton testi.

Jos sovellus tarvitsee pääsyn Admin APIin, lisää hankintakriteereihin vielä yksi vaatimus: näyttö siitä, että toimittaja pystyy ylläpitämään käyttöoikeutta turvallisesti Shopifyn tietoturvamuutosten läpi. Pitkä ominaisuuslista ei vastaa tähän kysymykseen. Ei myöskään korkea arvostelukeskiarvo.

Emme hylkäisi toimittajaa vain siksi, että siirtymä on vielä kesken. Huolestuttavaa olisi sen sijaan, jos toimittaja ei osaisi kertoa, mitä tunnistautumismenetelmää muutos koskee, tai esittää julkaisu- ja testaussuunnitelmaa. Avoin tekninen vastaus on arvokkaampi kuin yleinen vakuuttelu siitä, että kaikki on hoidossa.

Tämä vaikuttaa myös uuden verkkokaupan sovellushankintoihin. Olemassa olevaan kauppaan jo asennettu sovellus voi jatkaa toimintaansa ensimmäisessä vaiheessa, vaikka uusi asennus ei enää onnistuisi. Jos laajentuminen perustuu samoihin sovelluksiin, varmista erikseen, että ne voidaan ottaa käyttöön myös uudessa kaupassa.

Kokoa Shopify-sovellusten tietoturvan valmiusrekisteri

Aloita integraatioista, joiden vikaantuminen keskeyttäisi toiminnan. Aseta tilausten toimituksia hoitava integraatio etusijalle kaupan ulkoasua täydentävän lisäosan sijaan. Tarkoitus on turvata jatkuvuus, ei vaihtaa kaikkia käytössä olevia ratkaisuja.

Käytä yhteistä dokumenttia ja nimeä jokaiselle integraatiolle vastuuhenkilö. Kirjaa siihen:

Liiketoimintariippuvuus: mikä pysähtyy tai muuttuu virheelliseksi, jos integraatio menettää API-käyttöoikeutensa.
Tekninen vastuu: tunnistautumisesta vastaava toimittaja tai oma kehittäjä.
Vaatimuksen soveltuminen: onko integraatio Admin APIa käyttävä julkinen sovellus, ja onko vastuuhenkilö vahvistanut asian.
Näyttö siirtymän valmiudesta: toimittajan kirjallinen tilannetieto, suunniteltu julkaisu ja olennaiset testitulokset.
Varasuunnitelma: hyväksytty manuaalinen toimintatapa tai palautusmenettely taustatehtävien keskeytyessä.

Tee epävarmuudet näkyviksi. ”Odottaa toimittajan vahvistusta” on hyödyllinen tilatieto. ”Todennäköisesti kunnossa” ei ole. Jos integraatio ei kuulu ilmoitetun julkisia sovelluksia koskevan vaatimuksen piiriin, kysy kehittäjältä, mitä tietoturvasääntöjä siihen sovelletaan. Älä jätä sitä kokonaan tarkastelun ulkopuolelle.

Lähetä toimittajille kysymys, johon voi vastata täsmällisesti

Käyttääkö sovelluksenne Shopifyn Admin APIa offline-käyttöoikeustokeneilla, ja koskeeko tammikuun 2027 siirtymävaatimus sitä? Jos koskee, vahvistattehan siirtymän tilanteen, miten taustatehtävien käyttöoikeus palautuu ilman, että kauppias avaa sovelluksen, sekä miten testaus kattaa nykyisen asennuksemme ja uudet asennukset.

Pyydä vastaus kirjallisesti ja liitä se integraation tietoihin. Kaupan toiminnasta vastaava tiimi tarvitsee tukikanavan ja varasuunnitelman. Se ei tarvitse pääsyä yksityisiin avaimiin tai varsinaisiin tokeneihin.

Anna kehittäjille hyväksymistestit, älä pelkkää määräaikaa

”Päivitä tunnistautuminen” on liian epämääräinen toimeksianto liiketoiminnalle kriittiseen integraatioon. Sopikaa todennettavista lopputuloksista ennen kuin kehittäjä ilmoittaa työn valmistuneeksi.

Testaa taustatehtävät ilman käyttäjää

Pyydä kehittäjää osoittamaan, että taustatehtävä toimii tokenin vanhennuttua ilman, että sovellus avataan käyttöoikeuden palauttamiseksi. Valitse kaupallesi tärkeä toiminto, kuten varastosaldojen synkronointi. Varmista, että tehtävä valmistuu ja että virheistä ilmoitetaan henkilölle, joka voi puuttua niihin.

Testaa keskeytyneiden tehtävien jatkaminen

Tunnistautuminen voi epäonnistua myös kesken tehtävän, ei vain ennen sen alkamista. Kysy, mitä osittain käsitellylle työlle tapahtuu. Voiko käsittely jatkua ilman päällekkäisiä tietueita tai väliin jääviä muutoksia? Tämä on suosittelemamme hyväksymiskriteeri, ei väite siitä, että Shopifyn tiedote edellyttäisi tiettyä uudelleenyritysten toteutustapaa.

Testaa käyttöoikeuden palautus ja avainten hallinta

Jos sovellus käyttää uutta, yksityisellä avaimella allekirjoitettuihin pyyntöihin perustuvaa palautusmenetelmää, kysy, missä avainta säilytetään ja kuka voi vaihtaa sen. Tunnistetietoja ei pidä sisällyttää tukipyyntöihin tai kuvakaappauksiin. Pyydä kehittäjää dokumentoimaan, miten toiminta palautetaan, jos allekirjoitukseen tarvittavat tunnistetiedot eivät ole käytettävissä tai ne on vaihdettava.

Kolmannen osapuolen sovelluksen kohdalla voit saada toimittajalta testiyhteenvedon sen sijaan, että suorittaisit tarkistukset itse. Se on järkevä käytäntö. Pyydä näyttöä suhteessa integraation merkitykseen: kriittinen varastoyhteys ansaitsee perusteellisemman tarkastelun kuin valinnainen lisäominaisuus.

IP-sallintalistat suojaavat, mutta voivat myös estää tarpeellisen liikenteen

Shopify on ottanut käyttöön myös Admin APIn IP-sallintalistat. Kehittäjät voivat lisätä palvelinosoitteita tai CIDR-osoitealueita Dev Dashboardiin, testata niitä viimeaikaista liikennettä vasten ja ottaa rajoitukset käyttöön. Shopify hylkää sallittujen alueiden ulkopuolelta tulevat GraphQL- ja REST Admin API -pyynnöt 403-vastauksella.

Shopify suosittelee tätä suojausta vahvasti sovelluksille, jotka lähettävät pyyntöjä kiinteistä IP-osoitteista. Meidän näkemyksemme on, että sitä kannattaa arvioida token-siirtymän yhteydessä, mutta ei ottaa käyttöön sokkona. Puutteellinen sallintalista voi estää tarpeelliset taustaprosessit yhtä tehokkaasti kuin ei-toivotun liikenteen.

Pyydä kehittäjää huomioimaan tuotannon taustaprosessit ja palautumiseen tarvittava infrastruktuuri ennen rajoitusten käyttöönottoa. Jos palvelinympäristön lähtevän liikenteen IP-osoitteet vaihtuvat, varmista ensin tuettu verkkoratkaisu. Älä oleta, että testissä havaittu IP-osoite pysyy samana.

Pyydä kehittäjiä erottamaan vianmääritysohjeissa verkkorajoitusten estämät pyynnöt vanhentuneiden tokenien aiheuttamista virheistä. Muuten tiimi saattaa käyttää aikaa tunnistetietojen vaihtamiseen, vaikka todellinen ongelma on pyynnön lähtöosoite.

Verkkoyhteyksien määritykset ratkaisevat eri ongelman

Uuden shopify.app.toml-tiedoston verkkoyhteysosion avulla kehittäjät voivat määritellä ulkoiset kohdeosoitteet ja palvelimet. Määritettyihin navigointikohteisiin voidaan siirtyä ilman Shopifyn ulkoisen sivuston varoitusta. Palvelinmääritykset puolestaan auttavat Shopifyta tunnistamaan epäilyttävää toimintaa.

Nämä määritykset eivät korvaa token-siirtymää tai Admin APIn IP-sallintalistaa. Pyydä kehittäjää selittämään, mitä suojauskeinoa hän muuttaa ja miksi. Hyväksy navigointikohteiksi vain osoitteet, joita sovellus todella tarvitsee. Varoituksen poistamisen tulee perustua arvioon kohteen luotettavuudesta, ei haluun vähentää kaikkien ulkoisten linkkien varoituksia.

Tärkeimmät huomiot

Admin APIa käyttävien julkisten sovellusten on siirryttävä vanheneviin offline-käyttöoikeustokeneihin 1. tammikuuta 2027 mennessä.
Ensivaiheen poistaminen sovelluskaupan valikoimasta ja uusien asennusten estäminen eivät tarkoita, että olemassa olevat asennukset lakkaisivat heti toimimasta.
Pyydä toimittajilta näyttöä valmiudesta ja testaa taustatehtävät ilman käyttäjää etenkin kriittisissä integraatioissa.
Arvioi IP-sallintalistat huolellisesti ja käsittele verkkoyhteyksien määrityksiä erillisenä suojauskeinona.

Lähteet

Haluatko jättää tämän meidän hoidettavaksemme?

ZAGO on Shopify Premier Partner. Teemme päivittäin töitä verkkokauppojen suorituskyvyn, konversio-optimoinnin ja itsensä takaisin maksavien kauppatoteutusten parissa. Varaa maksuton verkkokaupan arviointi, niin näytämme kolme korjausta, jotka toteuttaisimme ensimmäiseksi.

Usein kysytyt kysymykset

Mikä on Shopifyn määräaika vanheneviin offline-käyttöoikeustokeneihin siirtymiselle?

Admin APIa käyttävien julkisten sovellusten on siirryttävä niihin 1. tammikuuta 2027 mennessä. Shopifyn mukaan vaatimuksia täyttämättömät sovellukset poistetaan tuolloin sovelluskaupan valikoimasta ja niiden uudet asennukset estetään. Olemassa olevat asennukset toimivat edelleen.

Lakkaavatko nykyiset Shopify-sovellukseni toimimasta 1. tammikuuta 2027?

Eivät Shopifyn tiedotteessa kuvatun ensimmäisen vaiheen perusteella. Olemassa olevat asennukset toimivat tässä vaiheessa edelleen, ja kyseisiä sovelluksia käyttävät kauppiaat näkevät hallintapaneelissa varoituksen 15. tammikuuta alkaen. Kysy toimittajaltasi siirtymävalmiudesta ja tarkista myöhemmät toimet Shopifyn koko aikataulusta.

Pitääkö kauppiaan vaihtaa Shopify-sovellusten tokenit itse?

Kolmannen osapuolen julkisissa sovelluksissa tunnistautumisen hallinta kuuluu yleensä sovellustoimittajalle. Kauppiaan kannattaa varmistaa toimittajalta, koskeeko vaatimus sovellusta ja missä vaiheessa siirtymä on. Omassa ylläpidossa olevat integraatiot on annettava niistä vastaavan kehittäjän tarkistettaviksi.

Mitä Shopifyn Admin APIn IP-sallintalista tekee?

Se rajaa sovelluksen tokeneilla tehtävät pyynnöt määritettyihin IP-osoitteisiin tai CIDR-osoitealueisiin. Shopify hylkää näiden alueiden ulkopuolelta tulevat pyynnöt 403-vastauksella. Kehittäjien tulee testata tarvittava liikenne ennen rajoitusten käyttöönottoa.