Kartoita ja hallitse verkkosivuston ulkoiset riippuvuudet

Rakenna yksi ylläpidettävä riippuvuusrekisteri tärkeiden käyttäjäpolkujen ympärille. Täytä se kahdessa kierroksessa: havainnoi ensin selaimessa polun eri vaiheissa käynnistyvät pyynnöt ja sovita havainnot sitten yhteen arkkitehtuurin, asetusten, hankintojen, sopimusten, toimittajatietojen ja vastuuhenkilöiden tiedon kanssa. Näin näkyviin tulevat sekä sivulle ladattavat resurssit että esimerkiksi nimipalvelu-, tunnistus-, alusta- ja jatkotoimittajariippuvuudet. Rekisterin tehtävä on tehdä tarkoitus, omistajuus, tietovirta, mitattu kustannus, häiriövaikutus, varareitti ja seuraava päätös tarkistettaviksi samassa paikassa.

Mikä on verkkosivuston ulkoinen riippuvuus ja miten se löydetään?

Ulkoinen riippuvuus on organisaation ulkopuolella hallittu koodi, sisältö, palvelu, infrastruktuuri, tunniste, tietolähde tai toimittajasuhde, jonka muutos, viive, häiriö, vaarantuminen tai tietojen käsittely voi olennaisesti vaikuttaa tarkasteltavaan käyttäjäpolkuun. Eri alkuperä tai verkkotunnus on hyödyllinen löytövihje, mutta ei määritelmä: ulkoinen palvelu voidaan välittää oman verkkotunnuksen kautta, ja saman konsernin palvelulla voi olla erillinen omistaja sekä vikaraja. Kyse on käyttäjäpolun riippuvuuskartasta, ei lähdekoodipakettien luettelosta.

Aloita selaimesta ja suorita edustava polku sen merkittävissä tiloissa. Tallenna ensilatauksen lisäksi navigointi, lomakkeet, suostumusvalinnat, upotusten avaaminen, kirjautuminen ja mahdollinen vahvistus sekä tarpeelliset laite- ja verkkotilanteet. Vuorovaikutus tai tagien käynnistyminen voi tuoda uusia pyyntöjä näkyviin vasta myöhemmin. Selaimen verkkoloki voi näyttää pyynnön tilan, tyypin, käynnistäjän, koon, keston ja paikan vesiputouksessa sekä auttaa jäljittämään pyyntöjen välisiä suhteita. Jaa tarkastelu etukäteen nimettyihin vaiheisiin: saapuminen, tiedonhaku, valinta, lomakkeen täyttö, lähetys ja vahvistus. Merkitse jokaisessa vaiheessa myös se, mikä käyttäjän toimi pyynnön käynnisti ja oliko riippuvuus aktiivinen vain tietyllä suostumuksella tai kirjautumistilassa. Tämä erottaa jatkuvasti läsnä olevan perusriippuvuuden ehdollisesti aktivoituvasta palvelusta ja auttaa löytämään tagien käynnistämät jälkipyynnöt. Säilytä havainnon yhteydessä testin päivämäärä, selain, laite, verkkotilanne ja välimuistin tila, jotta myöhempi katselmus voi verrata samanlaista tilannetta. Älä päättele palvelun merkitystä pelkästä siirtomäärästä: yhteysajan, suoritustyön, renderöinnin ja vuorovaikutuksen vaikutus voi olla aivan toisenlainen. Jos jotakin odotettua riippuvuutta ei näy, tarkista aktivoituuko se vasta toisessa tilassa sen sijaan, että merkitsisit sen automaattisesti käyttämättömäksi.

• Kirjaa resurssin lisäksi sen käynnistäjä, polun vaihe, aktivointiehto ja mahdolliset jatkopyynnöt.
• Mittaa ulkopuolisten komentosarjojen verkko-, suoritus- ja renderöintivaikutus määritellyssä tilanteessa; älä päättele kustannusta pelkästä toimittajan nimestä.
• Toista havainto tarvittaessa eri suostumusvalinnalla, välimuistin tilalla, laitteella tai kirjautumistilalla.

Käsittele HAR-tiedostoja ja yksityiskohtaisia pyyntölokeja mahdollisesti arkaluonteisena operatiivisena aineistona. Niihin voi sisältyä otsakkeita, tunnisteita, parametreja tai tallennettua dataa, eikä sanitointi takaa kaiken jäljelle jääneen aineiston olevan jakokelpoista. Rajaa keruu tarpeelliseen, käytä työkalun tarjoamaa sanitointia, tarkista sisältö ennen tallentamista ja jaa aineisto vain niille, jotka tarvitsevat sitä analyysiin. Rekisteriin riittää usein jalostettu havainto raakakaappauksen sijasta.

Miten selaimelta piiloon jäävät riippuvuudet löydetään?

Selaimelta piiloon jäävät riippuvuudet löydetään toisella kartoituskierroksella, jossa tekniset havainnot sovitetaan organisaation omiin tietoihin. Käy läpi verkkotunnuksen rekisteröinti, auktoritatiivinen DNS, varmenteiden myöntäminen ja uusiminen, CDN- ja reunapalvelut, hosting, CMS, tunnistus, haku, lomakkeet, tapahtumaviestit, palvelinten väliset rajapinnat, havainnointi ja tilaviestintä. Hankintatiedot, sopimukset, arkkitehtuurikuvaukset, asetukset ja toimittajakeskustelut voivat paljastaa selainkaappauksesta puuttuvia alusta- ja alihankkijariippuvuuksia. Pidä toisen kierroksen tulokset samalla käyttäjäpolulla kuin selainhavainnot, jotta infrastruktuurin nimi ei jää irralliseksi toimittajaluetteloksi. Tunnista jokaisesta palvelusta se polun vaihe, jota se tukee, sekä henkilö, joka voi vahvistaa tarkoituksen, käytön, sopimuksen, arviointitilan tai poistovallan. Vertaa lähteitä keskenään: sopimus voi osoittaa palveluntarjoajan, määritys käytössä olevan ympäristön ja omistaja todellisen käyttötarkoituksen. Jos tiedot ovat ristiriidassa, merkitse epävarmuus avoimeksi toimeksi äläkä täytä aukkoa oletuksella. Jäljitä yhteiset jatkotoimittajat ensisijaisesti silloin, kun niiden menetys tai keskittyminen voisi vaikuttaa tärkeään polkuun. Tavoitteena ei ole täydellinen kuva koko toimittajamarkkinasta vaan riittävä näyttö verkkopalvelun omistajuutta, häiriövaikutusta ja päätöstä varten.

• Vertaa selainlokia arkkitehtuurikaavioihin, tagien asetuksiin, integraatioluetteloihin ja ympäristökohtaisiin määrityksiin.
• Tarkista hankinta- ja sopimustiedoista palveluntarjoaja, uusiminen, tukikanava, varmistustila ja poistamiseen oikeutettu päätöksentekijä.
• Kysy palvelun omistajalta, mitä käyttäjäpolkua palvelu tukee, mitä sen taustalla toimii ja kuka vahvistaa käyttötarkoituksen.

Toimittajaketjua ei tarvitse yrittää piirtää rajattomasti. Seuraa alihankkijoita ja yhteisiä jatkotoimittajia suhteessa käyttäjäpolun merkitykseen sekä mahdolliseen keskittymäriskiin. Toimittajakarttaan voidaan yhdistää palvelu, sen merkitys, tietovirrat, arviointitila, yhteyshenkilöt, alihankkijat ja yhteiset jatkotoimittajat. Jos usea kriittinen toiminto nojaa samaan näkymättömään alustaan, tieto on päätöksenteolle arvokkaampi kuin täydellinen selvitys jokaisesta vähämerkityksisestä toimittajasuhteesta.

Mitä riippuvuusrekisteriin kannattaa kirjata?

Riippuvuusrekisterin kannattaa yhdistää yhdelle riville tunnistetiedot, käyttäjäpolun rajaus, tarkoitus, vastuut, tietovirta, mitattu vaikutus, häiriökäyttäytyminen ja elinkaaripäätös. Kirjaa nimi, toimittaja, palveluluokka, olennaiset päätepisteet, käynnistäjä, jatkopalvelut, ympäristöt, sivut, komponentit, polun vaiheet, tilat, laitteet ja aktivointi- tai suostumusehdot. Lisää vastuullinen liiketoimintaomistaja, tekninen ylläpitäjä, tarvittava tietoturva- tai tietosuojakumppani, hankintayhteys ja muutoksen hyväksyjä. Lisää samalle riville polkukohtainen kriittisyys, käyttäjälle näkyvä häiriöoire, vaikutusalue, aikakatkaisukäyttäytyminen, varareitti tai vaihtoehtoinen kanava, valvontasignaali, häiriöyhteys ja viimeisin turvallinen testi. Elinkaaritietoihin kuuluvat sopimuksen tai uusimisen tila, viimeisin havaittu käyttö, viimeisin päätös, päätösomistaja, avoimet toimet ja seuraava tarkistustapahtuma. Näin rivistä ei tule pelkkää teknistä inventaariota, vaan päätösasiakirja, josta näkyy, miksi riippuvuus on mukana ja mitä sen muuttuessa tehdään. Pidä mittaushavainnot erillään hyväksynnästä: havaittu pyyntömäärä tai ajoitus kuvaa nimettyä testitilannetta, kun taas hyväksytty vaikutus on vastuullisen omistajan päätös suhteessa polun merkitykseen. Rekisterin tulee tukea myös myöhempää vertailua, joten kirjaa olosuhteet riittävän täsmällisesti mutta vältä yleispätevän pistemäärän keksimistä yksittäisestä havainnosta.

Tietovirran arvioinnissa on tunnistettava toimijat, tietotyypit, vastaanottajat ja käyttötarkoitukset, eikä käsittelyn delegointi poista ensimmäisen osapuolen vastuuta. Kirjaa lähetettävä ja vastaanotettava tieto, aktivointiehto, kohde sekä tarkastettu sopimus- tai tietosuojatietue. Tietojen minimointi, käyttötarkoituksen rajaus ja läpinäkyvyys ovat hyödyllisiä päätöskysymyksiä. Rekisteri ei kuitenkaan ratkaise oikeudellista vaatimustenmukaisuutta; ilmoituksia, suostumusta, säilytystä, siirtoja ja käyttäjän oikeuksia koskevat vaatimukset tarvitsevat asiantuntevan tapauskohtaisen arvion.

Suorituskykyhavainnot on sidottava nimettyyn käyttäjäpolkuun, laitteeseen, verkkotilanteeseen, välimuistin tilaan ja päivämäärään. Resource Timing voi tarjota resurssien ajoitus- ja kokotietoja, mutta eri alkuperien käytännöt ja muut alustaehdot voivat rajoittaa yksityiskohtia. Tallenna saatavilla olevat pyyntömäärät, siirto- ja puretut koot, yhteys- ja pyyntöajoitukset, pääsäikeen työ sekä renderöinti- tai vuorovaikutushavainnot. Älä tiivistä niitä yleispäteväksi pistemääräksi, joka kadottaa mittausolosuhteet.

Miten riippuvuuden häiriötä testataan turvallisesti?

Riippuvuuden häiriö testataan turvallisessa testiympäristössä tai erikseen hyväksytyllä selaintyökalulla, yksi hallittu ehto kerrallaan. Määritä ennen koetta, millainen käyttäjälle käyttökelpoinen tila on, ja estä tai heikennä sitten yksi havaittu pyyntö tai komponentti. Älä aiheuta hyväksymätöntä tuotantohäiriötä. Yhden pyynnön estäminen voi paljastaa käyttäjälle näkyvän vian, mutta se ei jäljittele kaikkia viiveitä, virheellisiä vastauksia, palvelinpuolen vikoja tai tuotanto-olosuhteita. Arvioi koetta koko käyttäjäpolun kautta, ei vain estetyn päätepisteen tilana. Tarkista säilyvätkö sisältö, navigointi, ohjeet, lomakkeet, validointi, tunnistus, vahvistus, vaihtoehtoinen yhteydenotto ja saavutettava käyttö odotetulla tasolla. Kirjaa erikseen käyttäjän havaitsema oire, ylläpidon saama signaali, tarvittu palautustoimi ja suunnitellun varareitin todellinen toiminta. HTTP-vastaus tai toimittajan saatavuusnäkymä on vain yksi havainto, eikä se todista liiketoimintapolun käyttökelpoisuutta. Luokittele tulos vain nimetylle polulle ja kokeillulle ehdolle. Sama riippuvuus voi estää yhden polun, heikentää toista ja vaikuttaa kolmannessa vain mittaukseen. Selainesto ei myöskään kata kaikkia todellisen palveluhäiriön muotoja, joten rajoitus kuuluu testituloksen yhteyteen.

1. Valitse edustava polku ja määritä odotettu käyttökelpoinen lopputila.
2. Kokeile tarvittaessa ja turvallisesti viivettä, epäonnistumista, suostumuksen epäämistä, tyhjää vastausta tai vanhentunutta tietoa.
3. Tarkkaile sisältöä, navigointia, lomakkeita, validointia, tunnistusta, vahvistuksia, saavutettavuutta, aikakatkaisuja ja vaihtoehtoisia yhteydenottotapoja.
4. Kirjaa käyttäjän näkemä oire, operatiivinen signaali, palautustoimi ja se, toimiko suunniteltu varareitti.

Pelkkä palveluntarjoajan päätepisteen vastaus tai HTTP 200 ei osoita käyttäjäpolun toimivan. Luokittele testattu tulos nimetylle polulle ja ehdolle esimerkiksi kriittiseksi, heikentyneeksi, valinnaiseksi tai vain mittaukseen vaikuttavaksi. Nämä neljä luokkaa ovat yhteistä priorisointia varten laadittu toimituksellinen malli, eivät yleinen riskistandardi. Myös käyttäjälle näkymätön mittauskatko voi olla operatiivisesti tärkeä, jos hälytys-, attribuutio- tai kokeilutietoa tarvitaan päätöksissä.

Ajatellaan hypoteettista ajanvarauskomponenttia. Selainkaappaus paljastaa ajanvarausvaiheessa iframe-elementin ja sen käynnistämät pyynnöt, minkä jälkeen toimittajatiedot osoittavat palvelun omistajan ja taustalla olevan toimittajaketjun. Kun komponentti estetään valtuutetussa kokeessa, sivun sisältö ja saavutettava vaihtoehtoinen yhteydenottoreitti säilyvät, mutta välitön ajanvaraus katoaa eikä nykyinen valvonta huomaa menetystä. Tulos kirjataan kyseiselle polulle heikentyneeksi, ja päätökseen viedään sekä puuttuva hälytys että testattu vaihtoehtoinen reitti.

Riippuvuuskartta on hyödyllinen vasta, kun se näyttää kutsujen lisäksi sen, mitä käyttäjät ja ylläpitäjät kokevat riippuvuuden pettäessä.

Miten riippuvuuden jatkosta päätetään?

Riippuvuuden jatkosta päätetään vertaamalla dokumentoitua tarkoitusta ja omistajuutta mitattuun kustannukseen, tietovirtaan, häiriövaikutukseen, varareittiin ja käyttäjäpolun merkitykseen. Säilytä, korvaa, eristä, lykkää, itseisännöi ja poista ovat käytännöllisiä päätösvaihtoehtoja, eivät yleispätevä standardi. Ajanvarausesimerkissä säilyttämispäätös voidaan ehdollistaa polkutason valvonnan lisäämiselle, testatun saavutettavan vaihtoehtoreitin säilyttämiselle ja nimetylle uudelleentarkistustapahtumalle. Perustele valittu vaihtoehto rekisteriin sillä näytöllä, joka päätöshetkellä on käytettävissä: nykyinen tarkoitus, vastuullinen omistaja, mitattu kustannus, tietovirta, häiriöoire, vaikutusalue, varareitti ja valvonta. Merkitse myös päätöksen ehdot ja tapahtuma, joka avaa asian uudelleen. Korvaaminen edellyttää varmennetun vaihtoehdon vertailua, eikä itseisännöinti poista päivitys-, lisenssi-, eheys-, yksityisyys- tai tukivastuuta. Eristäminen voi pienentää pääsyä tai vaikutusaluetta, mutta sen sopivuus riippuu integraatiosta ja toiminnallisista seurauksista. Lykkääminen sopii vain valinnaiseen toimintoon, jonka julkisivu, aktivointi, suostumustila ja saavutettavuus on testattu. Poistaminen on perusteltu silloin, kun nykyistä tarkoitusta tai arvoa ei voida puolustaa, ei vain siksi, että palvelu sijaitsee eri verkkotunnuksessa.

• Säilytä, kun nykyinen tarkoitus ja omistaja ovat selvät ja havaitut kustannukset, tietovirta sekä häiriökäyttäytyminen hyväksytään suhteessa polun merkitykseen.
• Korvaa, kun kykyä tarvitaan edelleen mutta varmennettu vaihtoehto parantaa kestämätöntä kustannusta, hallintaa, tukea, tietokäytäntöä, häiriökäyttäytymistä tai keskittymäriskiä.
• Eristä, kun tarvittavan integraation pääsyä tai vaikutusaluetta on syytä rajata ja tekninen sekä tietoturva-arvio hyväksyvät ratkaisun toiminnalliset seuraukset.
• Lykkää, kun valinnaista upotusta ei tarvita ennen merkityksellistä sisältöä tai vuorovaikutusta ja aktivoitu kokemus voidaan testata toimivaksi sekä saavutettavaksi.
• Itseisännöi vain, kun organisaatio pystyy laillisesti ja operatiivisesti omistamaan toimituksen, päivitykset, eheyden, lisensoinnin, yksityisyyden, ylläpidon ja tuen.
• Poista, kun nykyistä tarkoitusta ei voida perustella, riippuvuus on käyttämätön tai päällekkäinen taikka hyväksytty arvo ei enää oikeuta havaittua kustannusta ja riskiä.

Suoraan sivulle liitetty ulkopuolinen JavaScript voi muuttua organisaation oman julkaisuprosessin ulkopuolella ja suorittua sivun kontekstissa. Iframe-raja, sandbox-määritykset, Content Security Policy, yhteensopiva eheystarkistus ja palvelinvälitteinen tietovirta voivat rajata joitakin integraatioita, mutta eivät poista toimittajariskiä. Subresource Integrity tarkistaa tuettujen aliresurssien odotettuja tavuja, ei kaikkia palveluja, API-vastauksia, iframe-elementtejä tai liiketoimintatoimintoja. Kevyt julkisivu voi lykätä upotusta käyttäjän aktivointiin, mutta sekä julkisivu että aktivoitu palvelu on testattava.

Miten riippuvuuskartta pidetään ajan tasalla?

Riippuvuuskartta pidetään ajan tasalla liittämällä sen tarkistus verkkopalvelun tavallisiin muutoksiin ja päätöksiin. Käynnistä katselmus julkaisusta, tagien muutoksesta, uudesta komponentista, hankinnasta tai sopimuksen uusimisesta, toimittajan muutos- tai poistumisilmoituksesta, häiriöstä, tietosuojakatselmuksesta ja hyväksytystä polkutarkistuksesta. Yhtä yleistä aikaväliä ei tarvita kaikille riippuvuuksille. Päivitä tapahtuman yhteydessä viimeisin havaittu käyttö, sopimus- tai arviointitila, päätösomistaja, avoimet toimet ja seuraava tarkistustapahtuma. Jokaisen katselmuksen ei tarvitse toistaa koko kartoitusta. Kohdista työ tapahtuman muuttamaan näyttöön ja tärkeimpiin polkuihin: julkaisu voi muuttaa käynnistäjiä, sopimuksen uusiminen omistajuus- ja ehtotietoja ja häiriö testattua vaikutusta tai varareittiä. Päivitä samalla viimeisin havaittu käyttö, arviointi- ja sopimustila, viimeisin päätös, päätösomistaja, avoimet toimet sekä seuraava tarkistuksen käynnistävä tapahtuma. Kytke valvonta käyttäjälle näkyviin oireisiin ja havaittuihin mittausaukkoihin; pelkkä toimittajan tai päätepisteen saatavuus ei korvaa polun ja varareitin testausta. Suhteuta katselmuksen syvyys riippuvuuden merkitykseen, äläkä määrää samaa tarkistusväliä, varareittiä tai palautumissitoumusta jokaiselle palvelulle. Uudelle riippuvuudelle asetettavat hyväksymisehdot tuovat tarkoituksen, omistajan, tietovirran, odotetun kustannuksen, häiriökäyttäytymisen, varareitin, valvonnan ja tarkistustapahtuman näkyviin ennen käyttöönottoa. Näin rekisteri palvelee sekä muutospäätöstä että myöhempää operatiivista seurantaa. Puuttuva tieto merkitään avoimeksi toimeksi eikä hiljaiseksi oletukseksi.

1. Valitse ensimmäisellä viikolla yksi liiketoiminnalle tärkeä käyttäjäpolku ja rajaa sen olennaiset tilat.
2. Tallenna selainhavainnot ja sovita ne tunnettuihin alusta-, sopimus- ja toimittajatietoihin.
3. Luo ensimmäiset rekisteririvit, nimeä alustavat omistajat ja merkitse puuttuvat tiedot avoimiksi toimiksi.
4. Suunnittele yksi valtuutettu häiriökoe sekä käyttökelpoisen tilan ja varareitin tarkistus.

Yhdistä valvonta käyttäjälle näkyviin oireisiin ja tunnistettuihin mittausaukkoihin, sillä toimittajan saatavuustieto ei korvaa polun ja varareitin testausta. Aseta myös uusille riippuvuuksille hyväksymisehdot: tarkoitus, omistaja, tietovirta, odotettu kustannus, häiriökäyttäytyminen, vaihtoehtoinen reitti, valvonta ja tarkistustapahtuma käsitellään ennen käyttöönottoa. Tietoturvan, tietosuojan, juridiikan, hankinnan, saavutettavuuden ja jatkuvuuden asiantuntijat osallistuvat oman toimivaltansa mukaisesti. Tuotannon vikainjektio, tuhoava resilienssitestaus, toimittajavarmistus ja sitovat palautumislupaukset vaativat nimenomaisen valtuutuksen.