Ovatko itse isännöidyt testit turvallisia?

Epäonnistunut regressiotesti on ärsyttävä. Kuvakaappaus sisäisestä ERP-järjestelmästä, joka päätyy hallitsemattomasti ulkoiseen palveluun, on tietoturvapoikkeama. Juuri siksi QA-johtajat ja IT-vastaavat kysyvät itseltään: are self hosted tests secure? Rehellinen vastaus on: ne voivat olla huomattavasti turvallisempia kuin pilvipohjaiset vaihtoehdot, mutta vain jos toimintaa otetaan yhtä vakavasti kuin itse testejä.

Itse isännöity testiautomaatio siirtää hallinnan suorituksesta, testidatasta, kuvakaappauksista, lokeista, ja käyttöoikeuksista omaan infrastruktuuriin. Se vähentää riippuvuuksia ja tarpeettomia datareittejä. Se ei kuitenkaan korvaa tietoturva-arkkitehtuuria. Huonosti ylläpidetty sisäinen testipalvelin pysyy huonosti ylläpidettynä palvelimena.

Ovatko itse isännöidyt testit turvallisempia kuin pilvitestit?

Ratkaiseva ero ei ole siinä, ajetaanko testi paikallisesti vai automatisoidusti. Se on missä dataa käsitellään, kuka pääsee siihen käsiksi, ja mitkä tekniset rajat pätevät.

Ulkoisesti ylläpidetyn testauspalvelun kohdalla yritys menettää usein useita artefakteja: testitilien kirjautumistiedot, sisäisten sovellusten URL-osoitteet, DOM-sisältöä, kuvakaappauksia, testiajojen videoita, virhelokeja, ja mahdollisesti tietokantaotteita. Vaikka toimittaja täyttäisi korkeat tietoturvastandardit, syntyy lisäksi luottamus- ja sopimussuhde. Sovelluksille, joissa on asiakas-, henkilöstö-, tuotanto-, tai talousdataa, tämä voi olla merkittävä este.

Itse isännöity järjestelmä voidaan ajaa oman verkon tai selkeästi rajatun EU-ympäristön sisällä. Testi-instanssi käyttää suoraan staging-, hyväksyntä-, tai eristettyjä testijärjestelmiä. Testitodisteet pysyvät siellä, missä myös sovellus ja sen operatiivinen vastuu sijaitsevat. Tämä on erityisen järkevää testattaessa Windows-työpöytäsovelluksia, sisäisiä verkkoportaaleja, tai järjestelmiä, joissa on arkaluontoista prosessidataa.

Mutta itse isännöinti ei ole automaattisesti turvallisempaa. Se, joka ylläpitää testipalvelinta avoimella etäyhteydellä, jaetuilla ylläpitäjätileillä, ja pysyvästi voimassa olevilla salasanoilla, on vain siirtänyt riskit. Kysymys ei siis ole vain: pilvi vai paikallinen? Vaan: onko testiympäristö todistettavasti suojattu ja pysyvästi ylläpidettävissä?

Are self hosted tests secure? Ratkaisevaa ovat nämä rajat

Turvallinen testausalusta tarvitsee selkeät tekniset ja organisatoriset rajat. Pienille ja keskisuurille yrityksille tämän ei tarvitse näyttää konserniohjelmalta. Se täytyy vain toteuttaa johdonmukaisesti ja dokumentoida.

Erottele testiympäristö tuotannosta

Automatisoitujen testien tulee löytää virheitä, ei laukaista tilauksia, muuttaa lähetysluetteloita, tai kirjata varastoliikkeitä. Siksi testit tarvitsevat erillisen ympäristön omilla rajapinnoilla, testivuokralaisilla, ja testidatalla. Missä täydellistä tuotannon kopiota ei tarvita, se on usein jopa tarpeettoman riskialtis.

Varasto- tai tilausportaalille se voi tarkoittaa: testikäyttäjät saavat kirjata tavaran vastaanottoja ja luoda lähetystarroja, mutta syntyvät asiakirjat eivät mene todelliselle tulostimelle eivätkä todelliselle huolitsijalle. API-avaimet osoittavat hiekkalaatikko-päätepisteisiin. Sähköpostin lähetys siepataan tai rajoitetaan sisäisiin vastaanottajiin. Näin testi pysyy merkityksellisenä tuottamatta operatiivisia seurauksia.

Erottelun tulisi päteä myös verkkotasolla. Testipalvelin tarvitsee vain ne yhteydet, joita se todella tarvitsee. Yleinen pääsy koko sisäiseen verkkoon on käytännöllistä, mutta harvoin perusteltavissa. Segmentointi rajoittaa vahinkoa, jos testitili tai järjestelmän osa vaarantuu.

Käsittele kirjautumistietoja kuten tuotantopääsyjä

Testiautomaatio tarvitsee usein kirjautumistietoja. Se on normaalia, mutta nämä tiedot eivät kuulu testiskripteihin, lähdekoodin konfiguraatiotiedostoihin, tai keskusteluhistoriaan. Salasanat, tokenit, ja sertifikaatit tulisi ladata hallitusta salaisuuksien hallinnasta. Testitilit saavat vain ne oikeudet, jotka konkreettinen prosessi vaatii.

Myös pääsy itse testausalustalle tarvitsee rooleja. Kehittäjän täytyy ehkä käynnistää testiajoja ja lukea tuloksia, mutta ei muuttaa verkkokonfiguraatiota. Liiketoimintayksikkö voi tarkastella raportteja, mutta ei tarvitse pääsyä tallennettuihin kirjautumistietoihin. Ylläpito-oikeuksien tulisi olla henkilösidonnaisia, ei yhteiseen tiliin kytkettyjä.

Lisäksi monivaiheinen tunnistautuminen, kohtuulliset salasanasäännöt, ja tilin lukitusvirrat kuuluvat vähimmäisstandardiin. Nimenomaan testijärjestelmiä käsitellään usein vähemmän kriittisinä. Hyökkääjät näkevät asian toisin: he käyttävät mielellään testiympäristöjä sisääntulopisteenä, koska siellä sijaitsevat pääsyt, sisäiset nimet, ja tekniset yksityiskohdat.

Minimoi testidata ja maskaa kohdennetusti

Yleisin virhe ei ole puuttuva salausmenetelmä, vaan liikaa todellista tietoa testikannassa. Useimmissa regressiotesteissä kukaan ei tarvitse todellisia asiakasnimiä, todellisia osoitteita, tai täydellisiä henkilöstökansioita. Synteettiset tietojoukot, maskatut kopiot, ja tietoisesti luodut erikoistapaukset riittävät usein.

Poikkeuksia on. Jotkin virheet ilmenevät vain todellisilla tietorakenteilla, epätavallisilla merkkijonoilla, tai monimutkaisilla oikeuskonstellaatioilla. Silloin hallittu, pseudonymisoitu kopio voi olla järkevä. Ratkaisevaa on, että tämä päätös tehdään tietoisesti ja sillä on poistoaikaraja. Testitietokantoja ei pitäisi ajaa vuosikausia unohdettuna varjokopiona tuotannosta.

Kuvakaappaukset ja videot ansaitsevat saman huomion. Ne ovat arvokkaita vianetsinnässä, mutta voivat näyttää tilitietoja, sisäisiä hintoja, tai henkilötietoja. Määritä, mitkä artefaktit tallennetaan, kuka saa nähdä ne, ja milloin ne poistetaan automaattisesti. Testiraportin ei tarvitse tallentaa jokaista näyttökuvaa ikuisesti ollakseen todistusvoimainen.

Ylläpidä palvelinta kuin tuotetta

Itse isännöity testipalvelin ei ole laite, jonka asennat kerran ja sitten unohdat. Toiminnan turvallisuus syntyy toistettavasta ylläpidosta: ajantasaiset tietoturvapäivitykset käyttöjärjestelmälle, selaimelle, testien suorittajalle, ja riippuvuuksille; salatut tallennusvälineet ja siirtoreitit; valvotut varmuuskopiot; keskitetty lokitus; sekä selkeä tapa käsitellä tietoturvatiedotteita.

Erityisesti selainohjatuissa testeissä päivitysrytmi on relevantti. Vanhentuneet selainmoottorit ja automaatiokirjastot voivat sisältää tunnettuja haavoittuvuuksia tai tehdä testeistä epäluotettavia. Molemmat vievät aikaa. Dokumentoidut käyttöönotot ja kiinteät huoltoikkunat eivät siksi ole byrokraattinen lisä, vaan perusta toistettaville tuloksille.

Myös omistautuneelle tekoälytestauspalvelimelle kuten COCO, pätee sama. Paikallinen suoritus ei suojaa arkaluontoista sovellussisältöä taikuudella. Se luo hallinnan siitä, missä tekoälyavusteista arviointia, kuvakaappauksia, ja testilokeja käsitellään. Tämä hallinta täytyy täyttää korjaustiedostojen hallinnalla, oikeuksilla, verkon erottelulla, ja selkeillä säilytyssäännöillä.

Missä itse isännöinnillä on rajansa

Pilvipalvelut eivät ole määritelmällisesti turvattomia. Erikoistunut toimittaja voi tarjota enemmän tietoturvahenkilöstöä, kypsempää valvontaa, ja ammattimaisempaa redundanssia kuin yritys, jolla on yksi ylikuormitettu IT-rooli. Se, jolla ei ole kapasiteettia ylläpitoon, päivityksiin, ja häiriötilanteiden hallintaan, voi luoda suuremman riskin huonosti ylläpidetyllä itse isännöidyllä järjestelmällä.

Toisaalta monet ulkoiset testausalustat eivät yksinkertaisesti sovi prosessiltaan hyvin sisäisiin erikoissovelluksiin. Jos sovellus on tavoitettavissa vain yrityksen verkossa, jos testiajot näyttävät luottamuksellisia maskeja ja asiakirjoja, tai jos data ei saisi poistua omalta hallinta-alueelta, paikallinen toiminta on usein selkeämpi ratkaisu.

Järkevä päätös riippuu suojaustarpeesta ja toimintakyvystä. Julkiselle markkinointisivustolle ilman arkaluontoisia kirjautumisia pilvitestauspalvelu voi olla sopiva. Sisäiselle jakelujärjestelmälle, asiakasportaalille henkilötiedoilla, tai Windows-sovellukselle tuotantoverkossa moni asia puhuu hallitun, itse isännöidyn ympäristön puolesta.

Käytännöllinen tietoturvatarkastus ennen aloitusta

Ennen kuin automatisoidut testit otetaan käyttöön, vastuuhenkilön tulisi pystyä vastaamaan näihin kysymyksiin arvailematta:

• Mihin järjestelmiin, tietokantoihin, ja rajapintoihin testipalvelin saa päästä?
• Mitä dataa näkyy kuvakaappauksissa, videoissa, lokeissa, ja tekoälyarvioinneissa?
• Missä kirjautumistiedot sijaitsevat, ja milloin ne vaihdetaan?
• Kuka saa käynnistää testiajoja, lukea tuloksia, ja ylläpitää järjestelmiä?
• Kuinka nopeasti kriittiset päivitykset asennetaan, ja miten se tarkistetaan?
• Milloin testiartefaktit ja tarpeettomat tiedot poistetaan?

Nämä kysymykset tuntuvat asiallisilta. Juuri se on niiden arvo. Turvallisuus syntyy harvoin yhdestä ainoasta työkalusta tai vaikuttavasta arkkitehtuurikaaviosta. Se syntyy, kun vastuualueet, datavirrat, ja tekniset rajat pysyvät tarkistettavissa arjessa.

Sen, joka rakentaa testiautomaatiota, tulisi ensin selventää sovelluksen suojaustarve ja sitten valita pienin järkevä arkkitehtuuri. Siististi rajattu testipalvelin muutamalla valtuutetulla tilillä on usein arvokkaampi kuin ylikuormitettu alusta, jota kukaan ei voi luotettavasti ylläpitää. Boring, provable reliability voittaa testauksessakin näyttävän mutta läpinäkymättömän ratkaisun.