Mitä sähköpostin heikko tietosuoja käytännössä tarkoittaa? Ainakin tietojenkalastelua ja identiteettivarkauksia, murrettuja sähköpostilaatikoita, tietoliikenteen salakuuntelua, ja viestien sisällön kyseenalaista luotettavuutta.
Lähettäjän näkökulmasta heikko tietosuoja tarkoittaa osittain käänteisiä riskejä mitä vastaanottajalle. Jos vastaanottajan ongelmana ovat tietojenkalasteluviestit väärällä identiteetillä, lähettäjän ongelmana on oikean identiteetin todistaminen.
Tässä artikkelissa käsitellään lyhyesti seitsemän sähköpostin tietosuojan ongelmakohtaa lähettäjän näkökulmasta.
- Lähettäjän identiteetin todistaminen
- Lähettäjän postilaatikon tietoturva
- Viestin sisällön tietosuoja
- Viestiliikenteen salaaminen
- Vastaanottajan postilaatikon tietoturva
- Tieto sähköpostin avaamisesta
- Vastaanottajan identiteetin tunnistaminen
Miksi näissä kohdissa sähköpostin oletusarvoinen tietosuoja on heikko? Tähän vastaamiseksi on etsittävä selityksiä sähköpostin tekniikasta ja sen historiasta. Jokaisen kohdan lopuksi esitetään vaihtoehtoja, joilla tietosuojaongelman voi ratkaista.
1. Lähettäjän identiteetin todistaminen
Ongelma
Kuka tahansa voi käyttää lähettäjän nimeä ja sähköpostiosoitetta tai organisaation visuaalista ilmettä.
Mediassa säännöllisesti varoitellaan tietojen kalasteluviesteistä, joissa tekeydytään tunnetuksi organisaatioksi, kuten finanssitaloksi tai internetjätiksi. Ehkä kuuluisin tapaus on kalasteluviesti John Podestan henkilökohtaiseen Gmail-osoitteeseen, josta tämän artikkelin otsikkokuva on peräisin. Podesta toimi kalasteluviestin vastaanottaessaan Hillary Clintonin 2016 presidentinvaalikampanjan puheenjohtajana. Loppu on kansainvälisen tiedustelun historiaa.
Ongelman taustaa
Sähköpostin formaatin ensimmäinen määrittely on RFC 733 vuodelta 1977. Määrittelyn mukaan From: -kentässä tulisi oletuksena olla työasemalle kirjautunut käyttäjä, RFC:n esimerkissä työasemalle Host kirjautunut käyttäjä Jones:
From: Jones at Host
Määrittelyssä kuitenkin korostetaan, että From: -kentässä tulisi olla viime kädessä viestin kirjoittajan, ei lähettäjän nimi.
Jos toisella henkilöllä (Sarah) ei ole omaa sähköpostilaatikkoa, hän voi määrittelyn mukaan käyttää sihteerin laatikkoa (Secy) viestien lähettämiseen, ja määritellä vastausviestien osoitteen (Jones) erikseen:
From: Sarah Friendly Sender: Secy at Host Reply-To: Jones at Host
Sähköpostilaatikoita pystyi tuohon aikaan käyttämään vain oman organisaation päätteillä. Tämä on hyvin käytännöllinen selitys, miksi From: -kentän sisältö voi olla vapaasti määriteltävissä.
Vasta paljon myöhempi RFC 2822 vuodelta 2001 yrittää vaikuttaa asiaan, mutta on auttamattomasti myöhässä:
In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message.
Ratkaisuja
- Sähköpostipalvelimien tunnistaminen. Lähettäjän nimipalvelussa määritellään SPF ja DKIM-tietueissa luotetut SMTP-palvelimet. Tällä tavoin voidaan validoida, että viesti on lähtenyt verkkotunnuksen (esim. gmail.com) luottamalta postipalvelimelta. Tässä ei siis identifioida lähettäjähenkilöitä, vaan organisaation sähköpostipalvelimia. Organisaation henkilö voi lähettää toisen henkilön nimissä viestejä, ja murretuista laatikoista lähetetyt viestit menevät domainin validoinnin läpi.
- Lähettäjä allekirjoittaa viestin digitaalisella allekirjoituksella. PGP ja S/MIME ovat tekniikkoja tähän.
- Lähettäjä käyttää hallinnassaan olevaa suojattua verkkopalvelua viestintään. Pankit ja vakuutusyhtiöt toimivat näin. Suojattua viestintäpalvelua ei kuitenkaan tarvitse rakentaa itse, vaan sen voi hankkia SaaS-palveluna. Esimerkiksi julkishallinnon Suomi.fi-viestit ja tietosi.fi -palvelut ovat tällaisia. Myös dokumenttien sähköiseen allekirjoitukseen tarkoitettuja verkkopalveluja voidaan hyödyntää.
2. Lähettäjän postilaatikon tietoturva
Ongelmat
- Viestit säilytetään työasemalla ja/tai postipalvelimella salaamattomina.
- Postilaatikkoon pääsee käsiksi heikolla salasanalla tai tietojenkalastelun seurauksena.
Ensimmäinen ongelma koskee työasemien fyysistä turvallisuutta. Jos sähköpostilaatikko on levyllä salaamattomana, työaseman varkaus tai luvaton pääsy levyyn voi johtaa viestien vuotamiseen. Toinen ongelma, heikot salasanat ja tietojenkalastelu eivät ratkea työaseman levynsalauksella. Vaikutus korostuu pilvipalveluna tarjottavassa sähköpostissa. Esimerkiksi Microsoft Office 365 -laatikot ovat kesällä ja syksyllä 2018 olleet aktiivisen tietojenkalastelun kohteena.
Ongelmien taustaa
Työasemien levyjen salaus yleistyi vasta 2000-luvulla, esim. tänä päivänä Windows-koneissa tavallisesti käytetty Bitlocker julkaistiin Windows Vistan ominaisuutena vuonna 2007. Salasanojen kompleksisuusvaatimus on kasvanut käytössä olevan laskentatehon lisääntymisen ja löydettyjen haavoittuvuuksien seurauksena, eikä postijärjestelmä välttämättä pakota riittävän vahvaa salasanaa tai aktiivisesti estä brute force -hyökkäyksiä. Tietojenkalastelun vaikuttavuus on kasvanut pilvipohjaisen sähköpostin yleistyttyä.
Ratkaisuja
- Postilaatikko salataan levyn salauksella.
- Käytetään monivaiheista tunnistautumista (multi-factor authentication, MFA) webmailiin. Esimerkiksi Viestintäviraston Kyberturvakeskus kehottaa kaikkia Office 365 -tuotteita käyttäviä yrityksiä ottamaan käyttöön kaksivaiheisen tunnistautumisen. Tämä hankaloittaa sähköpostin käytettävyyttä, mutta on ainoita suojautumiskeinoja kalasteluhyökkäyksiin.
- Käytetään postilaatikon viestit salaavaa sähköpostia kuten ProtonMail tai MailFence + kaksivaiheista tunnistautumista
- Käytetään omassa hallinnassa olevaa suojattua verkkopalvelua viestintään
3. Viestin sisällön tietosuoja
Ongelma
Sisältö luettavissa ja muutettavissa sähköpostia välittävillä palvelimilla.
Ongelman taustaa
Simple Mail Transfer Protocol (SMTP) -protokollan alkuperäinen määrittely (RFC 821) alkaa sanoilla:
The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.
SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel.
Jo nimensä puolesta sähköposti on tarkoitettu yksinkertaiseksi. Viestien salaaminen koko viestinvälitysinfrastruktuurissa ei kuulosta simppeliltä eikä valmistajariippumattomalta. SMTP-protokollassa sähköpostiviestejä välittävä palvelin näkee ja voi muuttaa viestien sisältöä samalla tapaa kuin välitysketjun alkupäässä oleva viestin lähettäjä. SMTP-palvelintoteutuksissa viestit monesti tallennetaan ainakin lyhyeksi aikaa salaamattomina postipalvelimien levylle postijonoihin.
Ratkaisuja
- Salataan ja digitaalisesti allekirjoitetaan viesti. PGP ja S/MIME ovat tekniikkoja tähän.
- Toimitetaan vain vastaanottokuittaus sähköpostiin, ja käytetään viestien lukemiseen web-clientia. Tämä toimintaperiaate on monelle tuttu perinteisessä "turvapostissa", jossa salaava sähköpostiyhdyskäytävä huolehtii ilmoitusviestien lähettämisestä.
- Vaihtoehto on, että salaavan yhdyskäytävän ja tavanomaisen sähköposticlientin sijaan viestintöän käytetään pelkästään omaa suojattua verkkopalvelua.
4. Viestiliikenteen salaaminen
Ongelma
Selväkielinen tietoliikenne on salakuunneltavissa.
Ongelman taustaa
SMTP-protokolla ja client-protokollat (POP/IMAP) ovat selväkielisiä. Vasta SMTP-protokollan ja client-protokollien laajennuksissa (RFC 3207, RFC 2595) on määritelty sähköpostin tietoliikenteen suojaaminen Transport Layer Security-protokollan (TLS) avulla.
Ratkaisuja
- Salataan tietoliikenne TLS-protokollalla. TLS:n pakottaminen on kuitenkin hankalaa, koska tällöin osa viesteistä ei mene perille. SMTP-protokollan STARTTLS -laajennus vaatii tuen sekä lähettävältä että vastaanottavalta osapuolelta, ja jos jompikumpi puuttuu niin tiedonsiirtoa ei voi salata. Googlen Transparency Reportin mukaan Googlen sähköpostipalveluissa tällä hetkellä yli 90 % vastaanotetuista viesteistä kulkee salattuna ja lähtevistä viesteistä yli 85 % voidaan välittää TLS-salattuna. Viestien sisällön lisäksi TLS salaa suuren osan metatietoa postipalvelimien välillä.
- Lähetetään sähköpostitse ainoastaan ilmoitusviestejä, ei salattavaa sisältöä. Luetaan viestit https-yhteydellä turvapostissa tai suojatussa verkkopalvelussa.
5. Vastaanottajan postilaatikon tietoturva
Ongelma
Lähettäjä ei voi vaikuttaa vastaanottajan postilaatikon suojaukseen.
Ongelman taustaa
Kyse on yleisemmästä digitaalisten aineistojen hallinnan ongelmasta. Kun vastaanottajalla on kopio viestistä, lähettäjä ei voi enää sen leviämiseen vaikuttaa.
Ratkaisu
Käytetään lähettäjän hallinnoimaa turvapostia tai suojattua verkkopalvelua, jossa viestin avaamista voi rajoittaa eri keinoin. Esimerkiksi viestin säilytysaikaa ja avauskertojen lukumäärää voidaan rajoittaa, ja sallia pääsy vain tietyistä IP-osoitteista. Tällä voidaan lieventää ongelmaa, mutta ei poistaa sitä, sillä vastaanottaja voi aina kopioida sisällön muualle talteen. Lähettäjä kuitenkin pystyy osoittamaan, että on tehnyt voitavansa asiassa.
6. Tieto sähköpostin avaamisesta
Ongelma
Lähettäjä ei saa kuittausta viestin vastaanottamisesta tai avaamisesta.
Ongelman taustaa
Sähköposti on best effort -tyyppinen teknologia, jossa ei ole takeita viestin perillemenosta. Vastaanottajalta pyydettävään kuittaukseen vastaaminen on
vapaaehtoista, jolloin sähköpostien vastaanotto ja avaaminen ei ole auditoitavissa.
Ratkaisu
Tieto viestin avaamisesta voidaan tallentaa turvapostin webmailissa tai suojatussa verkkopalvelussa.
7. Vastaanottajan identiteetin tunnistaminen
Ongelma
Lähettäjä ei tunnista vastaanottajaa kuin sähköpostiosoitteella. Tunnistamisen auktoriteettina on vastaanottajan sähköpostiosoitteen myöntänyt organisaatio. Tämä ei usein riitä henkilöllisyyden todentamiseen, esimerkiksi jos viestitään ennestään tuntemattomalle yksityishenkilöasiakkaalle tämän Gmail-osoitteeseen.
Ongelman taustaa
Henkilön tunnistaminen perustuu uskottavan auktoriteetin toteuttamiin vahvoihin tunnistautumistapoihin, jotka ovat tyypillisesti kansallisia, kuten Suomessa TUPAS-pankkitunnistautuminen ja mobiilivarmenne. Asiakasviestinnässä paras auktoriteetti on usein lähettäjä itse, jolla on vahva käsitys vastaanottajan osoitteen oikeellisuudesta.
Sähköpostiosoite on kuitenkin hyödyllinen vastaanottajan organisaation tunnistamisessa sähköpostidomainin perusteella. TLS-protokollaa käytettäessä voidaan lisäksi tarkastaa vastaanottavan SMTP-palvelimen varmenteen oikeellisuus.
Ratkaisuja
- Manuaalinen kaksivaiheinen tunnistus: salataan viesti tai sen liitteet ja toimitetaan salasana SMS-viestinä
- Tunnistetaan turvapostin vastaanottaja matkapuhelinnumerolla ja SMS-kertakäyttösalasanalla.
- Tunnistetaan suojatun verkkopalvelun käyttäjä vahvasti pankkitunnuksilla tai mobiilivarmenteella.
Lopuksi
Sähköpostin välittäminen sähköpostipalvelimien kesken perustuu SMTP-protokollaan, jonka ensimmäinen määrittely on peräisin vuodelta 1982 (RFC 821). Legendaarisen Jon Postelin alkuaan kehittämä protokolla on yksi internetin menestystarinoita. Sen toimintalogiikka on kuitenkin hyvin avoin, protokollaa ei yksinkertaisesti ole suunniteltu luottamukselliseen viestintään nykyisen kaltaisessa internetissä. Tästä johtuen tehokkaimmat ja helppokäyttöisimmät suojauskeinot yleensä perustuvat muuhun kuin oikeaan sähköpostiin.
Lisätietoa turvapostista löydät oppaastamme "Salattu sähköposti - Opas asiakasviestinnän suojaamiseen"
Luottamuksellisen tai henkilötietoja sisältävän sähköpostin lähettäminen salaamattomana on vähintääkin kiusallista. Tämän ILMAISEN oppaan avulla tunnistat sähköpostin ongelmakohdat ja osaat valita itsellesi parhaan salausratkaisun. Oppaassa käsitellään sähköpostin tietosuojaongelmat, suojaustekniikat ja vaihtoehdot sähköpostille. LATAA OPAS