Surfshark ilmoitti 9. syyskuuta 2026, että tuntematon ulkopuolinen pääsi käsiksi yhtiön sisäiseen testipalvelimeen. Yhdeksän päivää myöhemmin yhtiö julkisti Deloitten vahvistuksen siitä, että se noudattaa omaa “ei lokeja” -käytäntöään. Ajoitus on herättänyt kysymyksiä siitä, kuinka paljon VPN-auditointeihin voi oikeastaan luottaa, kun tilintarkastusyhtiön raportti ja tietoturvapoikkeama julkaistaan käytännössä samalla viikolla.
Tapaus koskettaa suoraan Suomea ja muita Pohjoismaita, joissa VPN-palveluiden käyttö on kasvanut voimakkaasti EU:n ikätarkistusvaatimusten ja lisääntyneen verkkovalvonnan myötä. Surfshark kuuluu Nord Security -konserniin, samaan yhtiöön kuin NordVPN, ja sillä on miljoonia käyttäjiä myös Pohjoismaissa. Kun yksi konsernin brändeistä joutuu selittämään tietoturvapoikkeamaa samalla kun se markkinoi riippumattoman tilintarkastajan vahvistamaa lokittomuutta, koko toimialan luottamusmalli joutuu suurennuslasin alle.
Seuraavassa käydään läpi tapahtumien aikajana, se mitä Surfshark on itse vahvistanut, mitä riippumaton media on raportoinut, ja miksi lokittomuusauditoinnin ja tietoturvapoikkeaman samanaikaisuus on herättänyt keskustelua koko VPN-alan läpinäkyvyydestä.
Mitä Surfsharkin testipalvelimella tapahtui
Surfsharkin oman tapahtumaraportin mukaan yhtiön tietoturvan valvontajärjestelmät havaitsivat epätavallista toimintaa 31. elokuuta 2026. Kaksi päivää myöhemmin, 2. syyskuuta, yhtiö vahvisti, että ulkopuolinen taho oli päässyt käsiksi sisäiseen testipalvelimeen, ja eristi vaikutuksen alaisen ympäristön saman päivän aikana. Surfshark kertoi omassa tiedotteessaan: “On the 2nd of September we confirmed an unusual activity within one of our internal test servers and immediately began our response.” (Surfshark, syyskuu 2026)
Yhtiö jatkoi: “After identifying that the server has been accessed by an unauthorized party, we contained the incident on the same day.” Loppusiivous, mukaan lukien altistuneiden tunnistetietojen ja avainten vaihtaminen, saatiin valmiiksi 5. syyskuuta. Julkinen tiedote tapahtumasta tuli ulos vasta 9. syyskuuta, eli viikko ja kaksi päivää havainnon jälkeen.
Syynä palvelimen altistumiselle oli Surfsharkin mukaan inhimillinen virhe: sisäinen kehitystestipalvelin oli väärin konfiguroitu, minkä seurauksena se oli tavoitettavissa julkisesta internetistä. Palvelimelta altistui rajoitetusti sisäistä kehitysmateriaalia, osia järjestelmän binääritiedostoista, eräiden palveluiden sisäisiä konfiguraatioita ja joitakin koodihistoriassa esiintyneitä build-tunnistetietoja. Mukana oli myös erillinen, eristetty VPS-palvelin, jota käytettiin sisällön saatavuuden optimointiin eli käytännössä välityspalvelimena.
Surfshark korosti, ettei tutkinnassa löytynyt viitteitä siitä, että tapaus olisi vaikuttanut asiakastietoihin, VPN-liikenteeseen, käyttäjien IP-osoitteisiin, salausavaimiin tai itse VPN-palvelun toimintaan. Yhtiön tiedotteen keskeinen lause kuului: “Based on our investigation, we have confirmed that no user data and VPN services were affected.” (Surfshark, syyskuu 2026)
BleepingComputerin ja TechRadarin raportit tapahtumasta
Tietoturva-alan uutissivustot tarttuivat tapaukseen nopeasti. BleepingComputer raportoi 10.-11. syyskuuta, että altistunut testi-infrastruktuuri sisälsi myös erillisen välityspalvelimen, ja lainasi Surfsharkin tarkempaa selitystä siitä, mitä palvelimella oli ja mitä ei. Yhtiön mukaan “Personal information was never held and accessible from here [the breached server], VPN traffic and browsing activity are not logged or retained in the first place, and the apps and browser extensions on your devices were not altered in any way.” (BleepingComputer, syyskuu 2026)
TechRadar nosti esiin samat seikat: kyseessä oli väärin konfiguroitu kehityspalvelin, altistunut materiaali oli rajallista ja sisäistä, ja Surfsharkin mukaan asiakastiedot ja VPN-palvelut säilyivät koskemattomina. CyberInsider raportoi tarkan aikajanan, 31. elokuuta havainnosta 2. syyskuuta eristämiseen. Yhtäkään nimettyä riippumatonta tietoturvatutkijaa, joka olisi tehnyt oman forensisen analyysin tapauksesta, ei toistaiseksi ole julkisesti tunnistettu. Suurin osa jatkoraportoinnista on toistanut tai analysoinut Surfsharkin omaa tiedotetta, mikä on tyypillistä tapauksissa, joissa yhtiö itse hallitsee tiedonkulkua.
On syytä huomata, ettei kukaan ulkopuolinen taho ole toistaiseksi vahvistanut Surfsharkin väitettä riippumattomasti. Tämä ei tarkoita, että väite olisi virheellinen, mutta se tarkoittaa, että lukijan on tällä hetkellä luotettava yhtiön omaan kertomukseen tapahtuneesta.
Deloitten “ei lokeja” -vahvistus yhdeksän päivää myöhemmin
Noin viikkoa myöhemmin Surfshark nosti esiin toisen tiedotteen: Deloitte, yksi niin kutsutuista Big Four -tilintarkastusyhtiöistä, oli vahvistanut yhtiön noudattavan omassa lokittomuuskäytännössään antamiaan sitoumuksia. Surfsharkin luottamuskeskuksen (trust center) sivuilla asia muotoillaan näin: “Deloitte, one of the Big Four auditing firms, confirmed that we adhere to the commitments made in our no-logs policy.” (Surfshark Trust Center)
Käytännössä lokittomuussitoumus tarkoittaa, ettei Surfshark väitä tallentavansa pysyvästi selaushistoriaa, käytettyä kaistanleveyttä, verkkoliikennettä, istuntotietoja, yhteyksien aikaleimoja tai IP-osoitteita. Palveluntarjoajien kuten VPN.comin ja Security.orgin mukaan Surfshark saattaa käsitellä käyttäjätunnuksen, yhteystiedon tai IP-osoitteen väliaikaisesti aktiivisen istunnon aikana, ja IP-osoite poistetaan raportoidusti noin 15 minuutin kuluessa yhteyden katkeamisesta.
Julkisesti saatavilla olevat tiedot eivät riitä vahvistamaan tarkkaa päivämäärää tälle uusimmalle Deloitte-katselmukselle, sen virallista luokitusta (täysimittainen auditointi vai suppeampi “agreed-upon procedures” -tyyppinen varmennustoimeksianto), testausmetodologiaa tai tarkkaa otettua infrastruktuuria. Surfshark on aiemmin viitannut myös Cure53:n tekemiin tietoturva-auditointeihin sekä varhaisempiin Deloitte-katselmuksiin, mutta saatavilla oleva aineisto ei riitä vahvistamaan tarkkaa lukumäärää siitä, montako erillistä auditointia yhtiölle on tehty vuosien varrella.
Ajoituksen ongelma: murto ja auditointi samalla viikolla
Journalistisesti kiinnostavin osa tarinaa ei ole yksittäinen tietoturvapoikkeama sinänsä, vaan ajoitus. Surfshark vahvisti luvattoman pääsyn testipalvelimelle 2. syyskuuta ja julkisti asian 9. syyskuuta. Vain yhdeksän päivää myöhemmin yhtiö nosti julkisuuteen Deloitten vahvistuksen lokittomuudesta. Kahden uutisen lähekkäisyys ei tarkoita, että ne liittyisivät suoraan toisiinsa teknisesti, mutta se luo kuluttajan näkökulmasta hämmentävän kokonaiskuvan: samaan aikaan kun yhtiö selittää, miksi hakkeri pääsi sisäiseen palvelimeen, se markkinoi riippumattoman tilintarkastajan sinettiä luottamuksen rakentamiseksi.
Tämä nostaa esiin laajemman kysymyksen VPN-alan auditointikulttuurista. Lokittomuusauditointi vastaa kapeaan kysymykseen: tallentaako palveluntarjoaja pysyvästi käyttäjädataa. Se ei vastaa kysymykseen, onko yhtiön sisäinen infrastruktuuri, testiympäristöt ja kehitysprosessit tietoturvallisia. Surfsharkin tapaus osoittaa juuri tämän aukon: lokittomuus saattoi pitää paikkansa, mutta se ei estänyt väärin konfiguroitua testipalvelinta päätymästä julkiseen internetiin.
VPN-auditointien kirjo: mitä ne oikeasti mittaavat
VPN-toimialalla “auditointi”-sana kattaa useita erilaisia toimeksiantoja, joita ei pitäisi niputtaa yhteen. Lokittomuusauditointi (no-logs audit) tarkastaa palveluntarjoajan palvelinkonfiguraatiot ja käytännöt sen varmistamiseksi, ettei käyttäjädataa tallenneta pysyvästi. Sovellusturvallisuusauditointi (application security audit), jonka tyyppiesimerkki on Cure53:n tekemä penetraatiotestaus, etsii konkreettisia haavoittuvuuksia sovelluskoodista. Infrastruktuuriauditointi tarkastaa palvelinarkkitehtuurin ja pääsynhallinnan laajemmin.
Nämä kolme auditointityyppiä eivät ole keskenään vertailukelpoisia, ja yhtiöt hyödyntävät tätä markkinoinnissaan valitsemalla mieluiten sen auditointityypin, joka antaa parhaan tuloksen julkaistavaksi. Kun yhtiö kertoo läpäisseensä “auditoinnin”, lukijan kannattaa aina kysyä: minkä tyyppisen, minkä laajuisen, ja kuinka tuoreen.
| Auditointityyppi | Mitä tarkastetaan | Mitä se EI kerro |
|---|---|---|
| Lokittomuusauditointi (esim. Deloitte) | Tallennetaanko käyttäjädataa pysyvästi | Sovellusten tai infrastruktuurin haavoittuvuudet |
| Sovellusturvallisuusauditointi (esim. Cure53) | Sovelluskoodin ja asiakasohjelmien haavoittuvuudet | Palvelinten lokituskäytännöt |
| Infrastruktuuriauditointi | Palvelinarkkitehtuuri, pääsynhallinta, verkkosegmentointi | Yksittäiset koodihaavoittuvuudet |
| Tietoturvapoikkeamaraportti (incident report) | Yksittäisen tapahtuman laajuus ja vaikutus | Yleinen tietoturvataso tai tulevat riskit |
Tekninen analyysi: miksi testipalvelimet altistuvat niin usein
Testiympäristöjen altistuminen julkiseen verkkoon on yksi ohjelmistoteollisuuden toistuvimmista tietoturvaongelmista, eikä se rajoitu VPN-yhtiöihin. Kehitystiimit pystyttävät usein testipalvelimia nopeasti uusien ominaisuuksien kokeilua varten, ja näiden palvelimien verkkosäännöt, palomuurikonfiguraatiot ja pääsynhallinta jäävät helposti vähemmälle huomiolle kuin tuotantoympäristössä. Tuotantopalvelimille on tyypillisesti olemassa tarkat tarkistuslistat ja automatisoidut tietoturvatarkistukset ennen käyttöönottoa, kun testiympäristöt rakennetaan usein kiireessä ja väliaikaisiksi tarkoitettuina.
Surfsharkin tapauksessa väärin konfiguroitu palvelin oli tavoitettavissa suoraan julkisesta internetistä, mikä viittaa siihen, että verkkosegmentointi tai pääsynhallintasäännöt eivät toimineet suunnitellusti kyseisessä ympäristössä. Tällaiset virheet syntyvät tyypillisesti kolmella tavalla: palomuurisäännön unohtamisella käyttöönoton yhteydessä, pilvi-infrastruktuurin oletusasetusten jättämisellä muuttamatta, tai testiympäristön kytkemisellä vahingossa tuotantoverkon kanssa samaan aliverkkoon. Yhtiö ei ole julkisesti erittelenyt, mikä näistä skenaarioista vastasi tätä nimenomaista tapausta.
Se, että palvelimelta löytyi koodihistoriassa esiintyneitä build-tunnistetietoja, on erityisen opettavainen yksityiskohta. Tunnistetietojen jääminen versionhallintaan tai build-lokeihin on yleinen ongelma, joka toistuu ohjelmistoalalla jatkuvasti, vaikka siihen on olemassa vakiintuneita teknisiä ratkaisuja, kuten salaisuuksien erillinen hallinta ja automaattinen skannaus ennen koodin julkaisua. Surfsharkin tapaus on näin ollen muistutus siitä, että yksittäinen inhimillinen virhe testiympäristössä voi paljastaa tietoa, joka ei koskaan ollut tarkoitettu julkiseksi, vaikka itse tuotantopalvelu säilyisi koskemattomana.
Vertailu: Surfshark, NordVPN ja Mullvad
Surfshark ei ole ainoa Pohjoismaissa suosittu VPN-palveluntarjoaja, joka on viime aikoina joutunut selittämään auditointejaan tai tietoturvatapahtumiaan julkisuudessa. Sisarbrändi NordVPN on käynyt läpi useita riippumattomia lokittomuusauditointeja vuosien varrella, ja Mullvad on raportoinut aiemmin tänä vuonna rajallisen määrän löydettyjä haavoittuvuuksia omissa auditoinneissaan, mikä on itse asiassa osoitus toimivasta prosessista: haavoittuvuuksien löytyminen ja korjaaminen on auditoinnin tarkoitus, ei sen epäonnistumisen merkki.
Ero Surfsharkin tapauksessa on se, että kyse ei ollut auditoinnin löydöksestä vaan todellisesta, ulkopuolisen tahon tekemästä luvattomasta pääsystä tuotantoympäristön lähellä olevaan testijärjestelmään. Tämä on eri riskiluokka kuin auditoinnissa havaittu teoreettinen haavoittuvuus, joka korjataan ennen kuin sitä kukaan ehtii hyödyntää. Lukija löytää tarkemman erittelyn Nord Securityn ja Mullvadin viimeisimmistä auditointituloksista VPN-auditointeja käsittelevästä aiemmasta artikkelistamme.
| Palveluntarjoaja | Omistus | Viimeisin julkinen auditointi/tapahtuma 2026 | Tyyppi |
|---|---|---|---|
| Surfshark | Nord Security | Testipalvelimen murto (2.9.) + Deloitte-vahvistus (~18.9.) | Tietoturvapoikkeama + lokittomuusauditointi |
| NordVPN | Nord Security | Toistuva riippumaton lokittomuusauditointi | Lokittomuusauditointi |
| Mullvad | Itsenäinen (Ruotsi) | Auditoinnissa löytyi rajallinen määrä korjattuja ongelmia | Sovellusturvallisuusauditointi |
| ProtonVPN | Proton AG (Sveitsi) | Säännölliset julkaistut auditointiraportit | Infrastruktuuri- ja sovellusauditointi |
Miksi tämä koskettaa suomalaisia ja pohjoismaisia käyttäjiä
VPN-palveluiden käyttö on kasvanut Suomessa ja muualla Pohjoismaissa merkittävästi viime vuosina, osittain EU:n ikätarkistusvaatimusten ja yleisen verkkovalvonnan tiukentumisen myötä. Nord Security, Surfsharkin ja NordVPN:n emoyhtiö, on yksi alan suurimmista toimijoista maailmanlaajuisesti, ja sillä on huomattava käyttäjäkunta myös Pohjoismaissa. Kun yksi konsernin brändeistä kokee tietoturvapoikkeaman, kysymys kuuluu luonnollisesti, koskeeko riski myös sisarbrändin käyttäjiä.
Surfshark ja NordVPN ovat erillisiä tuotebrändejä, joilla on omat tekniset ympäristönsä, mutta ne jakavat saman emoyhtiön ja osin samaa liiketoimintakulttuuria. Kuluttajan kannalta tämä tarkoittaa, että yhden brändin tietoturvakäytännöt ja läpinäkyvyys tapahtumien raportoinnissa heijastuvat väistämättä koko konsernin maineeseen. Suomalaiselle VPN-käyttäjälle keskeinen opetus on, ettei pelkkä auditointimerkki sivustolla riitä: kannattaa tarkistaa, minkä tyyppinen auditointi on kyseessä, kuka sen on tehnyt ja milloin se on julkaistu.
Historiallinen konteksti: VPN-alan luottamuskriisit
VPN-toimiala on kärsinyt luottamusongelmista jo vuosia. NordVPN joutui vuonna 2018 tapahtuneen palvelintason tietoturvaloukkauksen julkisuuteen vasta 2019, mikä johti pitkäaikaiseen maineen korjaamistyöhön ja sarjaan julkisia auditointeja. Tämä historiallinen tapaus on osaltaan syy siihen, miksi Nord Security -konserni on panostanut voimakkaasti juuri lokittomuusauditointeihin markkinointiviestinnässään: se on suora vastaus menneisyyden kritiikkiin.
Surfsharkin syyskuun 2026 tapaus muistuttaa siitä, että auditointihistoria ei poista uusien tietoturvapoikkeamien riskiä. Yhtiö voi läpäistä lokittomuusauditoinnin toistuvasti ja silti kohdata väärin konfiguroidun testipalvelimen, koska näissä kahdessa asiassa testataan eri asioita. Toimiala on viimeisen kahden vuoden aikana siirtynyt yhä läpinäkyvämpään suuntaan julkaisemalla trust center -sivuja ja yksityiskohtaisia tapahtumaraportteja, mutta kuluttajan kyky erottaa markkinointipuhe teknisestä todellisuudesta on edelleen rajallinen.
Markkinavaikutus: luottamus on VPN-alan valuutta
VPN-palvelut myyvät käytännössä yhtä asiaa: luottamusta siihen, ettei kukaan muu näe käyttäjän verkkoliikennettä. Kun tämä luottamus joutuu kyseenalaiseksi, vaikutus näkyy ensin kilpailijoiden markkinoinnissa. On todennäköistä, että muut toimijat, kuten ProtonVPN ja Mullvad, käyttävät tilaisuuden korostaa omaa läpinäkyvyyttään ja mahdollisesti riippumattomampaa omistusrakennettaan markkinointiviestinnässään lähikuukausina.
Toisaalta on syytä huomata, että Surfsharkin oman kertomuksen mukaan käyttäjädataa tai VPN-palvelua ei vaarannettu. Jos tämä pitää paikkansa eikä mitään uutta tietoa ilmene, tapauksen pitkän aikavälin vaikutus Surfsharkin liiketoimintaan jää todennäköisesti rajalliseksi. VPN-ala on nähnyt aiemminkin tietoturvapoikkeamia, joista on toivuttu nopeasti, kunhan yhtiö on kommunikoinut avoimesti ja nopeasti. Yhdeksän päivän viive havainnosta julkistamiseen on kuitenkin pidempi kuin monet tietoturva-asiantuntijat suosittelisivat kriittisissä tapauksissa, vaikka Surfshark luokittelee tapauksen itse rajalliseksi ja matalan riskin tapahtumaksi.
VPN-markkina on myös poikkeuksellisen kilpailtu, ja Pohjoismaissa kuluttajien valintaa ohjaavat yhä enemmän juuri tietoturvaväitteet eivätkä vain nopeus tai hinta. Kun Surfshark, ProtonVPN, Mullvad ja NordVPN kilpailevat samoista asiakkaista, auditointisinetit ja läpinäkyvyysraportit ovat muuttuneet keskeiseksi myyntiargumentiksi, ei vain tekniseksi yksityiskohdaksi pienellä painatuksella. Tämä selittää myös sen, miksi Surfshark halusi nostaa Deloitte-vahvistuksen julkisuuteen pian tietoturvatapahtuman jälkeen: yhtiö pyrkii todennäköisesti palauttamaan kuluttajien luottamuksen mahdollisimman nopeasti positiivisella uutisella negatiivisen vastapainoksi.
Mitä VPN-käyttäjän kannattaa tarkistaa auditointiväitteistä
Kun VPN-palveluntarjoaja mainostaa auditointia, kannattaa kiinnittää huomiota muutamaan konkreettiseen seikkaan. Ensin kannattaa selvittää auditoinnin tyyppi: onko kyse lokittomuuskatselmuksesta, sovellusturvallisuustestistä vai laajemmasta infrastruktuuriauditoinnista. Näiden välillä on suuri ero siinä, mitä ne todella todistavat.
Toiseksi kannattaa tarkistaa auditoinnin päivämäärä ja julkaisija. Vanha auditointi ei kerro mitään nykyisestä infrastruktuurista, ja epäselvästi nimetty “riippumaton tarkastaja” ei ole samaa kuin nimetty, tunnettu tilintarkastusyhtiö tai tietoturvafirma. Kolmanneksi kannattaa katsoa, julkaiseeko yhtiö koko auditointiraportin, vai ainoastaan yhteenvedon tai markkinointitiedotteen tuloksesta. Täysi raportti mahdollistaa riippumattoman arvioinnin, kun yhteenveto vaatii luottamista yhtiön omaan tulkintaan.
Ennusteet: mihin VPN-auditointikäytäntö on menossa
Toimialan kehityssuunnan perusteella on mahdollista hahmotella muutamia todennäköisiä kehityskulkuja seuraaville 12-18 kuukaudelle.
- VPN-palveluntarjoajat todennäköisesti alkavat erottaa markkinoinnissaan selvemmin lokittomuusauditoinnit ja sovellusturvallisuusauditoinnit toisistaan, koska kuluttajien tietoisuus näiden erosta kasvaa juuri tämäntyyppisten tapausten myötä.
- Tietoturvapoikkeamien julkistamisajat tulevat todennäköisesti lyhenemään sääntelypaineen alla, sillä EU:n kyberturvallisuussääntely on siirtymässä yhä tiukempiin ilmoitusaikatauluihin useilla sektoreilla.
- Kilpailijat, erityisesti pienemmät ja riippumattomat toimijat kuten Mullvad, tulevat todennäköisesti korostamaan omaa avoimempaa raportointikäytäntöään kilpailuetuna isompia konserneja vastaan.
- On odotettavissa, että yhä useampi VPN-palveluntarjoaja alkaa julkaista myös testi- ja kehitysympäristöjensä tietoturva-auditointeja erillään tuotantoympäristön lokittomuusauditoinneista, jotta vastaavia tapauksia voidaan ehkäistä.
- Pohjoismaissa, missä VPN-käyttö on kasvanut voimakkaasti, kuluttajasuojaviranomaiset ja tietoturva-toimittajat tulevat todennäköisesti kiinnittämään aiempaa enemmän huomiota siihen, miten VPN-yhtiöt kommunikoivat tietoturvapoikkeamista, ei vain siihen, tapahtuuko niitä.
Mitä tästä opitaan verkkoturvallisuudesta yleisemmin
Surfsharkin tapaus on hyödyllinen esimerkki laajemmasta ilmiöstä: testiympäristöt ovat usein heikommin suojattuja kuin tuotantoympäristöt, mutta ne voivat silti sisältää arkaluontoista materiaalia, kuten tunnistetietoja tai koodihistoriaa. Monessa yrityksessä tietoturvabudjetti ja valvonta keskittyvät ensisijaisesti tuotantojärjestelmiin, kun testi- ja kehitysympäristöt jäävät vähemmälle huomiolle, vaikka ne on usein helpompi altistaa vahingossa julkiseen verkkoon.
Tämä pätee VPN-yhtiöihin yhtä hyvin kuin mihin tahansa muuhun ohjelmistoyritykseen. Inhimillinen virhe, kuten Surfsharkin tapauksessa väärin konfiguroitu palvelin, on edelleen yksi yleisimmistä tietoturvapoikkeamien syistä alasta riippumatta. Tämä on myös syy, miksi puhtaasti lokittomuuteen keskittyvä auditointi ei koskaan voi kattaa koko yrityksen tietoturvariskiä: se on kapea mittari laajassa riskikentässä.
Suomalaiselle ja pohjoismaiselle lukijalle tästä seuraa käytännön ohje: kannattaa suhtautua VPN-yhtiön omaan tiedotteeseen samalla tavalla kuin minkä tahansa muun yrityksen kriisiviestintään. Tiedote kertoo, miten yritys itse haluaa tapahtuman ymmärrettävän, ei välttämättä kaikkea, mitä riippumaton tutkija löytäisi samasta tapauksesta. Tämä ei tarkoita, että Surfsharkin kertomukseen pitäisi suhtautua epäluuloisesti ilman perustetta, vaan sitä, että terve kriittisyys kannattaa säilyttää, kunnes asia on vahvistettu useammasta riippumattomasta lähteestä.
Mitä Surfshark lupaa tehdä jatkossa
Surfsharkin julkistuksen mukaan yhtiö kierrätti tai mitätöi kaikki altistuneet tunnistetiedot ja salaisuudet sekä katkaisi ulkoiset yhteydet osana jatkotoimenpiteitä, jotka valmistuivat 5. syyskuuta. Yhtiö ei ole julkisesti kertonut yksityiskohtaisesti, millaisia rakenteellisia muutoksia se tekee estääkseen vastaavien testiympäristöjen altistumisen tulevaisuudessa, mutta tapahtumaraportin julkaiseminen sinällään viittaa siihen, että yhtiö pyrkii säilyttämään läpinäkyvyyden osana kriisinhallintaansa.
VPN-palvelua valitsevan kuluttajan kannalta olennaisinta on seurata, julkaiseeko Surfshark tulevina kuukausina lisätietoa siitä, miten testiympäristöjen valvontaa on parannettu, ja tuleeko ulkopuolinen, nimetty tietoturvayhtiö vahvistamaan korjaustoimien riittävyyden. Tähän mennessä julkinen tieto perustuu yksinomaan yhtiön omaan kertomukseen.
Toimialan seuraajien kannattaa myös pitää silmällä, nostavatko kilpailijat tapauksen esiin omassa markkinoinnissaan seuraavien kuukausien aikana. Tällainen reaktio olisi alalla tavallista, ja se saattaa osaltaan kiihdyttää koko VPN-sektorin siirtymää kohti yksityiskohtaisempaa ja useammin toistettua auditointikäytäntöä, josta hyötyvät viime kädessä kaikki kuluttajat riippumatta siitä, mitä palvelua he päättävät käyttää.
Usein kysytyt kysymykset
Vaikuttiko Surfshark-tapaus käyttäjien VPN-liikenteeseen tai IP-osoitteisiin?
Surfshark on itse kertonut, ettei tutkinnassa löytynyt viitteitä siitä, että käyttäjädata, IP-osoitteet, salausavaimet tai VPN-palvelun toiminta olisivat vaarantuneet. Riippumatonta ulkopuolista vahvistusta tälle väitteelle ei toistaiseksi ole julkisesti saatavilla.
Mikä testipalvelin altistui, ja miksi se oli julkisessa internetissä?
Surfsharkin mukaan kyseessä oli sisäinen kehitys- ja testipalvelin, joka altistui väärän konfiguraation vuoksi. Mukana oli myös erillinen, sisällön saatavuuden optimointiin käytetty VPS-palvelin.
Miksi Surfshark julkisti tapahtuman vasta yhdeksän päivää havainnon vahvistamisen jälkeen?
Surfshark ei ole julkisesti selittänyt tarkkaa syytä viiveelle. Yleisesti ottaen tietoturvapoikkeamien tutkinta ja korjaustoimenpiteiden toteuttaminen vie aikaa ennen julkistamista, mutta yhdeksän päivän viive on silti pidempi kuin monissa nopean ilmoittamisen parhaissa käytännöissä suositellaan.
Mitä Deloitten auditointi todellisuudessa todistaa?
Deloitten varmennus koskee ainoastaan sitä, noudattaako Surfshark omassa lokittomuuskäytännössään antamiaan sitoumuksia eli jättääkö se tallentamatta pysyvästi käyttäjän selaushistoriaa, liikennetietoja ja yhteystietoja. Se ei ole yleinen tietoturva-auditointi eikä se kattanut sisäisiä testiympäristöjä, joissa syyskuun tapahtuma sattui.
Onko Surfshark turvallinen valinta VPN-palveluksi tämän tapauksen jälkeen?
Tapaus itsessään ei Surfsharkin oman kertomuksen mukaan vaarantanut käyttäjädataa. Päätös VPN-palvelun valinnasta kannattaa perustaa useisiin tekijöihin: auditointien tyyppiin ja ajantasaisuuteen, yhtiön läpinäkyvyyteen tietoturvapoikkeamista, omistusrakenteeseen ja siihen, missä maassa palveluntarjoaja toimii.
Mitä eroa on Surfsharkin ja NordVPN:n tietoturvassa, kun ne kuuluvat samaan konserniin?
Surfshark ja NordVPN ovat Nord Security -konsernin erillisiä tuotebrändejä, joilla on omat tekniset ympäristönsä ja infrastruktuurinsa. Syyskuun 2026 tapaus koski yksinomaan Surfsharkin sisäistä testipalvelinta, ei NordVPN:n järjestelmiä.
Kuinka usein VPN-palveluntarjoajien kannattaisi teettää auditointeja?
Alan parhaana käytäntönä pidetään vuosittaista tai puolivuosittaista lokittomuusauditointia yhdistettynä säännöllisiin sovellusturvallisuustesteihin. Yksittäinen auditointi muutaman vuoden takaa ei kerro juurikaan nykyisestä tietoturvatasosta.
Mistä suomalainen käyttäjä löytää ajantasaista tietoa VPN-palveluiden tietoturvasta?
Palveluntarjoajien omat trust center -sivut, tietoturvauutissivustot kuten BleepingComputer ja riippumattomien tilintarkastajien julkaisemat täydet auditointiraportit ovat parempia lähteitä kuin pelkät markkinointitiedotteet tai yhteenvedot.
