Riik nõuab tegelikult turvaauku ka e-posti

Vaid kõige pühendunumale puhkajale võis mõne nädala eest jääda märkamata põgus “torm”, mis järgnes ajakirjanduse tähelepanekule, et siseministeerium soovib elektroonilise side seaduse sõnumsidet puudutavatesse nõudmiste hulka sokutada riiklikku turvaauku.

See kohustaks justkui Skype’i ja WhatsApp’i sarnaseid teenusepakkujaid varustama oma rakendusi tagauksega (loe: turvaauguga), mis laseks kriminaalmenetluse raames korrakaitseorganid ligi nende kasutajate omavahelise krüpteeritud sõnumite vabatekstile (Eesti Rahvusringhääling: ”Siseministeerium soovib krüpteeritud sõnumirakendustesse tagaust”).

E-post

Infotehnoloogia-, side- ja õigusspetsialistide reaktsioon on pea sajaprotsendiliselt olnud mõttelt sarnane – selline tagauks ei ole ühestki aspektist hea mõte (ERR: “Peeter P. Mõtsküla: tagauksega krüptoside — rumal ja õigusvastane idee”, “Rainer Ratnik: neli põhjust, miks tagaukse lubamine pole mõistlik”, Kaimar Karu: küberturbeteatri kordusetendus).

Nendele spetsialistide poolt juba esitatud seisukohtadele on raske midagi uut ja väärtust loovat lisada, kuid mulle jäi eelnõu seletuskirja ja algset Euroopa Komisjoni direktiivi lugedes siiski silma üks asjaolu, millele keegi seni konkreetset tähelepanu veel juhtinud ei ole:

see seaduseelnõu puudutab oma tänases sõnastuses ka e-posti.

Nimelt sedastab Eesti seaduseelnõu seletuskiri järgmist:

“ESS §-i 2 täiendatakse punktiga 91, kus sätestatakse isikutevahelise side teenuse mõiste, mis tuleneb sidedirektiivi artikli 2 punktist 5. Isikutevahelise side teenus on teenus, mis võimaldab isikutevahelist teabevahetust ja see jaguneb omakorda kaheks:

1) numbripõhine isikutevahelise side teenus –tavapärane häälkõne kahe isiku vahel (nt telefoni-, mobiiltelefoniteenus, Skype kõne);

2) numbrivaba isikutevahelise side teenus –igat liiki e-kirjad, sõnumiteenused ja grupivestlused (nt FB Messenger, Skype messenger jt).”

See tähendab, et tagauste loomist puudutavad nõudmised, ei puuduta mitte ainult “eksootiliste nimedega” rakendusi, mille loetlemine paneb seni suure osa ühiskonnast õlgu kehitama, vaid ühiskonna kõige populaarsemat isikutevahelise side teenust: e-posti.

Tõsi, e-post on vana ja robustne tehnoloogia, mille standardite esialgsetes versioonides ei pööratud turvalisusele kuigipalju tähelepanu, kuid aastate jooksul on neid täiustatud paljude funktsionaalsusetaga, mis on seda olukorda paljuski parandanud ja nüüd on krüptograafia muutunud e-posti pea lahutamatuks osaks. Seda kindlasti nendes teenuse osades, mida haldavad teenusepakkujad. On tõsi, et suur osa lõppkasutajatest ei ole e-posti turvalisusele seni väga suurt tähelepanu pööranud.

Ka Zone on arendanud omal väiksel kombel e-posti kui platvormi arengut ja turvalisust, panustades näiteks sellistesse platvormidesse nagu ZoneMTA (https://github.com/zone-eu/zone-mta ja Wildduck IMAP (https://github.com/nodemailer/wildduck). Mõlemad on valminud e-posti võluri Andris Reinmani taktikepi all ja demonstreerivad innovatsiooni, mida ka Eestis on võimalik selles väga spetsiifilises valdkonnas teostada.

Meie plaanides on kindlasti jätkata panustamist arendustesse, mis ühel hetkel võiks ju kulmineeruda sellega, et e-post oleks vaikimisi palju konfidentsiaalsem tehnoloogia, kui ta on seda täna, tänu sõnumite läbivale vaikimisi krüpteerimisele.

Kasutajatel on täna selleks endapoolne võimalus olemas, näiteks läbi PGP juurutamise, kuid selle kasutuselevõtu künnis on nii kõrge, et selle murrangut massidesse me vaevalt kunagi näeme, kui teenusepakkujad seda kõvasti allapoole ei too.

Mõte sellest, et peaksime siis nõudma arendajatelt ja uuendajatelt oma loomingu määrimist kohustuslike turvaaukudega, on pehmelt öeldes vastik.

Tõenäosus, et selline arendus toimub just mõne meiesuguse väikese kontori juures, on seejuures ebaproportsionaalselt suur. Nimelt erinevalt hiiglaslikest teenusepakkujatest, kes teenivad kasumit oma klientide kirjade sisu nägemisest (suunates nende baasil reklaame või koostades kasutajate kohta profiile), meid see absoluutselt ei huvita.

Aus tõdemus on, et minu käsi tõrguks arendajaile ette kirjutamast, et selliste projektide terviklus ja usaldusväärsu tuleks kompromiteerida, sest keegi on riigis teinud rumalaid otsuseid. Tõenäolisem on, et see osa innovatsiooni jääks siis kas üldse tegemata või tehtaks seda siis väljaspool Eestit. Millest oleks kahju.

Teeme postkastid suuremaks

Paras aeg on põrmustada pisikesi pehkinud paradigmasid, parandades põhimõtteid mille alusel veebimajutusteenuse klientidele e-posti pakume.

Umbes aasta tagasi kirjutasin siin Zone poolt kasutusele võetud unikaalsest e-posti platvormist, mille abil muutus meie vastav infrastruktuur töökindlamaks, turvalisemaks ja efektiivsemaks. Täna on samuti põhjust kritseldada olulisest muutusest, mille üheks võimaldajaks seesama platvorm.

Lühidalt, edaspidi saavad kõik meie klientide loodud postkastid juba vaikimisi olema neile teenuspaketis ette nähtud maksimumsuurusega. Teenuspakettide hind ja muud tingimused jäävad samaks, aga postkastide lisamine ja haldamine muutub lihtsamaks.

Lisaks saavad professionaalsed e-posti kasutajad enda käsutusse kaks uut, just neile sobivat postkastitüüpi, mis võimaldavad neile pakutavaid ressursse veelgi kasvatada. Virtuaalserveri teenuses vaikimisi sisalduvast postkastist eristab neid suurem andmemaht ja asjaolu, et see maht on individuaalne – see ei ole kuidagi mõjutatud veebimajutusteenusest ega avalda tollele mingit mõju.

Kõik uuel platvormil postkastid on kindluse huvides jätkuvalt kolmekordse liiasusega mitme andmekeskuse vahel hajutatud.

Miks me seda teeme?

Ajalooliselt oleme pidanud oluliseks, et klientidel oleks võimalik äärmise täpsusega oma ressursse lõppkasutajate, kes postkaste reaalselt kasutavad, vahel jagada. Selle mõtte juured peituvad ajastus, mil interneti eesmärk oli ühendada akadeemilisi organisatsioone – nende UNIX süsteemides olid kõik tudengitele ja teaduritele eraldatavad ressursid rangelt arvel ja kõik neile kulutatud sendid täpselt loetud. Kuna Zone sisekultuur tuleneb omal moel samuti sellest ajastust, oleme endale teadvustamata seda traditsiooni edasi kandnud.

Juba mõnda aega on siiski selge, et meie kliendid ei soovi enam tegeleda infotehnoloogiliste ressursside peenhäälestusega. IT vahendid on pilvetehnoloogiate arengu ja ühiskonna üldise heaolu kasvu toel muutunud odavamaks kui aeg, mis nende täpsele tuunimisele kuluks.

Seepärast olemegi täheldanud, et granulaarne postkasti mahu sättimine ei leia enam kasutust.

Viskame siis oma pehkinud põhimõtte ajaloo prügikasti. Edaspidi pole vaja virtuaalserverite haldajatel käia postkastide piirmäärasid arvutamas, jagamas ja seadistamas. Iga postkast saab vaikimisi endale täpselt teenuspaketis ette nähtud maksimumpiirmäära. Lisaks, kui postkasti kasutaja soovib midagi enamat, piisab vaid ühest lisaklikist ja väikese lisatasu eest voolab individuaalset andmemahtu juurde, nagu küllusesarvest.

Suure postkasti illustratsioon

Veel üks asi…

Suuremad postkastid esitavad loomulikult palju suuremaid nõudmiseid e-posti klientidele millega neid kasutada. Muuhulgas on ka see pannud meid tööle selles suunas, et arendada asendus tänasele Zone veebipõhisele e-posti kliendile. See pingutus on nüüd kandmas esimesi vilju, mis valmis lõppkasutajatele tutvumiseks ja aadressil https://webmail.ee on võimalik meie uue e-posti platvormi kasutajatel sellega vaikselt tutvust teha.

Uuest veebipõhisest e-posti lugemise kogemusest peagi veidi pikemalt.

Kui tahad kontrollida, kas oled Zone uue e-posti platvormi kasutaja, saad seda teha aadressil https://help.zone.eu/kb/e-posti-serverid/. Uuel platvormil klientidel on IMAP serveri nimeks imap.zone.eu.

Kuuldused e-posti surmast on jätkuvalt liialdatud

E-post võis küll hiljuti tähistada oma 47. sünnipäeva, kuid pakub jätkuvalt uusi rakendusi ning väljakutseid.

Sõltumata regulaarsetest uutest e-posti killeritest on e-post, nagu me seda tunneme, püsinud enam-vähem samasugusena juba aastakümneid. Loomulikult on juurde tulnud uusi võimalusi nagu näiteks manuste kasutamine või täpitähtede tugi, mida e-posti esimesed versioonid sugugi ei tunnistanud, kuid see on reeglina alati olnud olemasoleva lahenduse raamides toimetamine, mitte millegi päriselt uue lisamine (manusega kiri oleks täiesti loetav ka manuse-eelse ajastu e-posti kliendiga, see lihtsalt näeks kummaline välja). Samal ajal on Google Wave, Slack, Facebook, WhatsApp ja teised e-posti alternatiivid lisanud loetamatul hulgal täiendusi, nii kasutajakogemuse kui turvalisuse vallas, mida e-postis kas senini ei ole või ei saagi kunagi olema.

E-posti areng on väljastpoolt vaadates kohutavalt aeglane, viimaste aastate suurim täiendus e-posti standardites on olnud täpitähtede tugi e-posti aadressi kasutajanime osas (domeeni osas olid täpitähed juba varem lubatud), näiteks андрис@уайлддак.орг on nende uuenduste alusel täiesti korrektne ja toimiv aadress. Samas suurem osa e-posti servereid selliseid aadresse endiselt ei toeta, kuna vastav standard on “alles” 6 aastat vana.

E-post elab ikka veel

Miskipärast ei ole e-posti kasutamine, hoolimata selle piiratud võimalustest ja üliaeglasest muutumisest kuhugi kadunud – vastupidi, selle tähtsus on ajas aina kasvanud. Tõsi, korrespondentsi laad ei ole võibolla püsinud päris sama. Täna me ei leia oma e-postkastist mitte niivõrd otsesuhtlust oma sõprade või lähedastega (selle jaoks on välksuhtlusrakendused tõesti paremad), vaid uudiskirju, paroolimeeldetuletusi, elektrooniliste teenuste kviitungeid, kõikvõimalikke teavitusi, tuttavate tehtud fotosid ühistest üritustest jmt.

Lisaks muutunud sisule on e-postkast sarnaselt päris postkastiga muutunud rohkem globaalse identiteedi osaks, selmet olla vaid suhtluskanal – Jaan Tammesid võib olla maailmas palju, aga konkreetsel aadressil elab siiski neist vaid üks. Facebookis on samanimelisi inimesi palju, aga igaühel neist on unikaalne e-posti aadress. E-posti aadress on seega sarnane läänemaailma kurikuulsate gaasiarvetega, mida tahetakse pangakonto avamisel näha. Kuigi e-post pole selleks üldse mõeldud ja riiklikult täiesti sanktsioneerimata, on praktikas tegu identiteedi tunnusega.

Failisüsteemi rõõmud ja mured

Muutunud sisu on jätnud oma jälje ka kasutaja e-postkasti majutavale ressursile. Uudiskirja peen HTML kood ja kujundus on mahult hoopis erinev välkteatest sõbrale. Kirjade kustutamise asemel kuhjatakse need erinevatesse kaustadesse, nii et mõnes kaustas on varasema 200 asemel 200 000 kirja. Moodsa telefoniga saadetud foto on suurem, kui kunagi ammu olid mitme aasta kirjad kokku. Mis siis veel sellest rääkida, kui see foto saadetakse mitte ühele inimesele, vaid kõikidele samal üritusel viibinutele. Mäletan isegi kuidas kunagises töökohas saatis postiserveri administraator kõigile kurja kirja, kui inimesed töökaaslastele ühte ja sedasama koerapilti edastasid ning sellega serveri töövõime ohtu seadsid.

Samas, kui nüüd vaadata, et kuidas on e-posti serveri tarkvara (eelkõige pean silmas kõigile kättesaadavat avatud lähtekoodil põhinevat tarkvara) nende muutustega kaasas käinud, siis selgub, et väga nagu ei olegi. Riistvara on odavam ja kiirem kui varem, seega piisab reeglina lihtsalt tarkvara seadistuses määrata endise 10MB postkasti suuruse asemel 10GB ning ongi nagu kõik korras. Enamikel juhtudel ongi korras, kümne inimese 10GB postkastide jaoks läheb serveris vaja kuni 100GB kõvaketast, mis ei ole tänapäeval mingi suurus. Probleemid tekivad siis, kui tegu on juba suurema hulga kui toatäie inimeste postkastide majutamisega. 1000 inimese postkastide majutamiseks läheb vaja 10TB kõvakettaruumi, 10 000 inimese jaoks juba 100TB jne.

Reeglina ei ole inimestel postkast kogu aeg servani täis, mis annab mõningase võimaluse paigutada serverisse rohkem postkaste, kui sinna tegelikult mahuks. Samas aga tähendab see pidevat monitoorimist, et kui täis või tühi mingi server tegelikult on ja vajadusel migreerida kasutajaid, tuleb liigutada suuri postkaste tühjematesse serverisse ja teha muid sarnaseid tegevusi. Klassikaliselt asuvad kasutaja kõik kirjad kas ühesainsas failis (mbox formaat) või ühes kaustas (maildir formaat), igal juhul tähendab kasutaja migreerimine, et ümber ei tule kolida mitte neid kirju, mis serverisse ära ei mahu, vaid terve postkast koos saba ja sarvedega.

Mõningase leevenduse annavad teinekord skaleeruvad võrgupõhised failisüsteemid nagu GlusterFS, kuid sõltuvalt kasutatud tarkvarast võib tekkida ootamatuid ja seletamatuid probleeme – tarkvara eeldab failisüsteemilt reeglina sellist käitumist, milleks võrgupõhine kuidagi võimeline pole, st. et süsteem peaks olema korraga kiire ja usaldusväärne. Failisüsteemi toimingud (näiteks faili ümbernimetamine, mis on maildir puhul väga tüüpiline tegevus) teostatakse koheselt ja enam-vähem konstantse kiirusega ning üldiselt need toimingud ka õnnestuvad, võrk aga on tunduvalt ebakindlam. Tavaliselt kõik toimib, aga siis, ühel hetkel, võtab faili ümbernimetamine aega 10 sekundit. Iseenesest mis siis sellest, aga kui tavaliselt võib lugeda sellise tegevuse kestust pigem milli- või isegi mikrosekundites, siis 10 sekundit on sellest 10 000 korda aeglasem. Lisame patta veel samal ajal kuhjuvad muud ootel tegevused (ka kõik ülejäänud kasutajad tahavad samal ajal oma postkastis muudatusi teha) ja saamegi tulemuseks väikese kaose.

Üks häda ja viletsus

IMAP protokoll, mille abil kasutajad oma e-kirju serverist alla laevad, on algselt disainitud olema skaleeruv, kus eeldatakse, et kasutaja võib ühenduda korraga erinevate serverite pihta kuna e-posti server ei pea otseselt olema seotud kirjade hoiustamisega. Selline disain tuli reaktsioonina ülimalt piiratud POP3 protokollile, kus, vähe sellest, et ei saa sama kasutaja paralleelselt pöörduda erinevate serverite poole, ei saa kasutaja paralleelselt üldse midagi teha ning peab piirduma üheainsa ühendusega. Samas praegused IMAP implementatsioonid on tavaliselt jäigalt failisüsteemiga seotud ja nendes implementatsioonides ei saa kasutaja päringuid hajutada, kuigi protokoll seda isegi võimaldaks. Ka Dovecot Director puhul, mis on kättesaadavatest lahendustest senini parim, satuvad sama kasutaja paralleelsed ühendused alati samasse serverisse (kuigi tõsi, see server võib aja jooksul vahelduda).

Veel üks keeruline küsimus e-posti puhul on autentimine. Esiteks on autenditavaid kohti palju – veebimeil, IMAP, POP3, SMTP ning kõiki neid tuleks kuidagi eraldi kohelda. Kui me tahame pakkuda veel kahefaktorilist autentimist, rakendusepõhiseid paroole, autentimislogi, ajas uuenevat parooliräsi algoritmi jmt. siis, kuigi võimalik, tähendab see olemasolevate rakenduste korralikku häkkimist.

Meilirakenduste monitoorimine on samuti olnud üldiselt paras peavalu. Loomulikult on olemas kõiksugu tööriistad e-posti järjekordade haldamiseks, kuid suures osas tähendab see failisüsteemis perioodilist failide ülelugemist või paremal juhul meiliserveri logifailide analüüsimist. Tõenäoliselt jääb meile meiliserveri kõhus toimuv siiski parajaks mustaks auguks. Siin tuleb jälle mängu sama kana ja muna probleem, et meilisüsteem asub reeglina ainult ühes masinas. Sellises seadistuses on ühes masinas loomulikult ka logifailid ja seega, kuigi võib-olla ebamugav, on neid logifaile võimalik töödelda standardsete utiliitidega nagu grep, awk ja sõbrad. Jaotame aga meilinduse mitmesse serverisse laiali ja kohe ongi pilt eest läinud, et mis täpselt toimub.

Üks tüüpiline puudujääk e-posti serverite tarkvaras on muutuste jälgimine kasutaja kontol. Näiteks kui kasutaja loob ühes meilirakenduses IMAP protokolli kaudu uue kausta, või veel hullem – nimetab mõne olemasoleva kausta ümber, siis sama kasutaja teine seade ei saa sellest mitte kuidagi teada. Muutused kaustadega ilmnevad üsna pea, sest reeglina teevad meilikliendid peale uue ühenduse avamist kaustade listingu, kuid esiteks võtab see aega ning teiseks, ümbernimetamiste puhul see ei aita, meilikliendi jaoks paistab selline kaust olevat uus kaust uute kirjadega, mis tuleb jälle alla tõmmata, samas kui ümbernimetatud kaust koos selles olnud kirjadega kustutatakse ära. Hea küll, IMAP klient on piiratud kasutatava protokolliga, aga sama kandub üle ka veebimeili rakendustele, mis reeglina on samuti taustal IMAP kliendid.

Ning kui veebimeil juba jutuks tuli, siis veebimeil üle IMAP protokolli on paras kaos. Heal juhul istub veebimeili rakenduse ja IMAP serveri vahel mingisugune kolmas rakendus, mis hoiab ühendusi IMAP serveri suunas lahti, aga reeglina tähendab siiski iga uus päring kliendi poolelt kogu IMAP tsirkuse taasmängimist – ühenduse avamine (sh. TLS “käepigistus”), serveri võimaluste küsimine, kasutaja autentimine, kausta avamist ning alles seejärel toimingut kirjaga (näiteks selle loetuks märkimist). IMAP protokolli kasutamine ning RFC822 vormingus e-kirjade haldamine teeb veebimeili arenduse ülimalt keerukaks ja aeganõudvaks. Populaarse veebimeili tarkvara Roundcube uue versiooni arenduseks mõeldud rahakogumise kampaania lõppes edukalt juba 3 aastat tagasi, aga siiani peame leppima vana versiooni kasutamisega.

Mida siis teha?

Väikestel pakkujatel taolisi skaleeruvusprobleeme, kus kasutajad enam ühte või paari serverisse ära ei mahu, üldiselt ei ole ning nemad saavad vabavara peal hakkama. Suured e-posti teenuse pakkujad on lahendanud skaleeruvusprobleemid ennekõike omaenda vajadustele vastava tarkvara arendusega, kus failisüsteemi asemel on kohe kasutuses skaleeruvad võrgusüsteemid ning tarkvara ei oota failisüsteemi tavapäraseid garantiisid, kuid need ei ole siis enam vabavaralised lahendused. Zone, kus postkastide arvu loetakse kuuekohalise numbriga, on selles suhtes olnud veidi õnnetus positsioonis, et tegu ei ole ammu enam väikese pakkujaga, aga maailma mastaabis ka mitte suurega. Olemasolevad vabavaralised lahendused jäävad kitsaks, kuid suurte poolt kasutatavad e-posti lahendused jäävad käeulatusest välja. Ainus mõeldav variant kuni senimaani oleks olnud Dovecoti kommertslahendus koos Dovecoti Directori ning object storagega.

Zones läksime siiski teist teed ning ka meil on nüüd kasutusel maja sees ehitatud (kuid siiski vabavaraline) e-posti süsteem, mis vastab paremini reaalsetele nõudmistele.

Featuuridest, seekord positiivse noodiga

Kirju ei hoita enam failisüsteemis, vaid need on laiali suures MongoDB sharditud klastris. See tähendab, et kui kasutaja rakendus teeb kirjade listingut, siis osad kirjad sellest listingust võivad asuda ühes, aga osad hoopis teises shardis. Samuti on kirjad ise osadeks jaotatud, kus manused on serveri pool kirjadest eraldatud ning võivad asuda hoopis mujal. Alles kliendi päringu peale otsitakse need erinevad jupid klastris pealt kokku ja esitatakse kasutajale tavalise e-kirjana. Selle kohta võiks öelda, et tegu on üsna tüüpilise pilve-mudelil töötava lahendusega.

Veebimeili puhul võib IMAP protokolliga seonduva osa täiesti vahele jätta ning saame meiliserverist küsida andmeid üle standardse REST API. Kusjuures kogu töö e-posti vormindusega jääb serveri kanda, nii et veebimeil ei pea midagi teadma MIME-kodeeringutest ega sellest, et kuidas manuseid kirjadest kätte saada. Sama API annab koheselt teada ka kõikidest kontol toimunud muutustest, sealhulgas siis kaustade ümbernimetamisest ning kirjade lisandumistest/kustutamisest.

Keskne autentimissüsteem võimaldab granulaarset haldust, kus kasutajal võib olla mitu erinevat parooli ning igal paroolil saavad olla erinevad õigused mingite toimingute teostamiseks. Samuti võimaldab see paremini paroolide kasutamist logida ning seda logi kasutajale vajadusel ka näidata.

Küberrünnak Zone.ee e-posti süsteemide pihta? Ei, täiesti tavapärane pilt 60 sekundi jooksul mõõdetud automaatsete skännerite katsetest kasutajate postkaste üle võtta. Niiviisi need Minunimi123 tüüpi paroolidega kaitstud kontod langevadki

Iga tegevuse kohta on võimalik saata struktureeritud infot kas Greylogi või muusse sarnasesse logiserverisse, väljuvate kirjade queue seis on loetav Prometheuse formaadis, nii et sisepilt e-posti serveri töösse on tunduvalt parem ning anomaaliad kergemini tuvastatavad.

Lõpetuseks

Kõiki lisandunud võimalusi ei hakkagi üles lugema, muidu ei jää uuteks blogipostitusteks enam materjali. Kokkuvõtvalt võib küll tõdeda, et sellise e-posti süsteemi arendus ei ole olnud lihtne, see on võtnud kaua aega, aga loodetavasti on tulemus seda väärt. Siiani ei ole keskmise suurusega e-posti teenuse pakkujatele sobivat platvormi leidunud, eelkõige mõeldes siis muutunud kasutajaharjumuste ning postkastide suuruse peale, nüüdsest võibolla siis on.

Tööd alustas uus e-posti platvorm

Zone on tasa ja targu asunud klientide ette tooma ühe viimaste aastate suurema väljakutse vilja, milleks on kaasaegsem e-posti platvorm.

Uue platvormiga välja tuleku juures on meil üks olulisi eesmärke võimalikult vähe häirida oma klientide igapäevatööd, mistõttu saavad alguses vaikimisi selle kasutajateks meie uued kunded.

Neil, kes Zone infosüsteemi juba tarbivad, on peagi võimalik ise valida hetk, mil soovitakse oma postkastid uuele platvormile üle tõsta. Kuna paljude lõppkasutajatega klientide jaoks ei ole see triviaalne ülesanne, siis esialgu me kedagi tagant kiirustada ei kavatse.

Järgnevalt proovin kirjeldada meie uue e-posti platvormi võtmeomadusi, mis võiksid ahvataleda kõiki seda kasutama.

Uuel platvormil on kolmekordne töökindlus

Interneti olelusteenuste (veebimajutuse jms) kontekstis on e-post paljude teenusepakkujate ja kasutajate silmis teenimatult teisejärguline teenus, mille töökindlusele erilist tähelepanu ei pöörata ning millelt oodatakse ainult vaikselt taustal tiksumist. Pahatihti hoitakse kasutajate postkaste lausa veebiserveris, mis meie nägemuses on lubamatu.

Meil on alati e-posti teenindamise jaoks olnud eraldi füüsiline serveripark, milles igale infosüsteemi rollile on omad serverid (e-posti vastuvõtjad, välja saatjad, rämpspostifiltrid, antiviirused, proksid, postkastide säilitamine jne) ning enamus neist dubleeritud.

Nüüd astume sammukese veel edasi. Kasutaja postkasti säilitab tulevikus korraga mitte üks või kaks, vaid lausa kolm serverit, mis saavad talitluspidevuse säilitamise eesmärgil olema hajutatud mitme andmekeskuse vahel.

See tähendab, et isegi ühe või kahe serveri täieliku häivimise korral ei pea me kliendi teenuse taastamiseks veel kasutama varukoopiaid, vaid lihtsalt suunama päringud ümber kolmandale serverile.

Varukoopiatest ei pääse loomulikult üle ega ümber, neid jääme jätkuvalt tegema. Mitmeid teenuse üldise jätkusuutlikkusega seotud riske on võimalik maandada vaid varukoopiate abil.

Uus platvorm on vaikimisi turvalisem

Nende aastakümnete jooksul, mil oleme e-posti teenuse pakkumisega tegelenud, on ühiskonna ootused andmete privaatsusele muutunud palju nõudlikumaks ning e-posti puudutav seadusandlus samuti karmistunud.

Seetõttu on meie uues platvormis läbivalt kasutusel krüpteeritud ühendused TLS (Transport Layer Security) tehnoloogial, maandamaks salasõnade või kasutaja andmete lekkega seotud riske.

NB! Pane nüüd hästi tähele! See tähendab järgmist:

  • POP3 ja IMAP protokollid on ligipääsetavad ainult nende krüpteeritud vormides POP3S (TCP port 995) ja IMAPS (TCP port 993);
  • SMTP ühendus on samuti ligipääsetav ainult selle krüpteeritud vormis, kasutusel on SMTPS (TCP port 465) ja SMTP STARTTLS (TCP port 587).

Kuna sisuliselt käsitletakse pea igas postkastis isikuandmeid, siis on selline lähenemine nende kaitse kontekstis igati õigustatud. Nii aitame oma klientidel vältida mitmete elementaarsete riskide realiseerumist ja vähendada nendega seotud võimalikke kahjusid.

Rämpsposti ja pahavara eemaldamine on efektiivsem

Rämpspostifilter tegutseb nüüd efektiivsemalt, konkreetsemalt ja lausa 10x kiiremini.

Rämpspost pannakse edaspidi vaikimisi serveri pool hoitavasse eraldi kausta. Kui seni võisid rämpsuks klassifitseeritud kirjad märgistatuna jõuda ka kasutaja sisenevasse postkasti (inbox), siis uues platvormis hoitakse seda puhtamana.

Tähelepanu! Oluline on teada, et 30 päeva peale rämpskirja saabumist kustutakse see serveri poolt automaatselt ära.

Rämpsposti märgistamine kirja pealkirjas või sisus lõpeb aga ära. Erinevalt praegusest ei muudeta tulevikus enam rämpspostiks loetava kirja sisu ega pealkirja, need jäävad samaks. Kogu kirja rämpsuks klassifitseerimist puudutav täiendav info lisatakse kirja päistesse. Kiri pannakse rämpsposti kausta oma algse välimusega.

Rämpsposti tõkestamine muutub personaalsemaks.

Rämpsposti tuvastamise tundlikkuse seadistamisel võetakse senise domeenipõhise punktisüsteemi asemel kasutusele uus süsteem, mille “rangust” iseloomustab neli taset, mida saab määrata igale postkastile eraldi.

Need tasemed on:

  • deaktiveeritud
  • madal
  • keskmine
  • kõrge.

Vaikimisi seadistatakse rämpsposti tuvastustundlikkus keskmisel tasemel.

Arvestades globaalseid trende, ei ole pahavara tõkestamisega tegelevat antiviirust võimalik uues e-posti infosüsteemis ka enam välja lülitada.

Rakendustele või seadmetele spetsiifilised salasõnad pakuvad täiendavaid riskide maandamise võimalusi

Lisaks postkasti peasalasõnale on uues infosüsteemis võimalik luua täiendavaid salasõnu, mida saab kasutada erinevates rakendustes või seadmetes.

See võimaldab näiteks kasutada üht salasõna oma lauaarvutis, teist sülearvutis, kolmandat mobiilseadmes ja neljandat mõnes pilveteenuses. Salasõna lekkimisel on nii võimalik lihtsalt tuvastada kust see “jalutama läks”.

Samuti ei ole ühe salasõna kustutamisel või muutmisel kõik ligipääsud e-postile kadunud.

Täiendavaid salasõnu saab hetkel lisada veebipõhise e-posti vahendusel.

Kirju saab uues platvormis filtreerida ka serveri poolel

Lõpuks on saanud teoks paljude meie kasutajate poolt pikisilmi oodatud võimalus. Nüüd on võimalik lasta sisenevaid kirju filtreerida meie serveritel, mitte e-posti klienttarkvaral.

Kui kasutaja on seadistanud endale filtreid, siis serverid tähistavad, liigutavad, edastavad ja kustutavad kirjad vastavalt nendes kirjeldatud instruktsioonidele juba enne, kui need kliendi seadmesse jõuavad.

See tähendab, et enam pole vaja luua eraldi filtreid igas seadmes, kust neid loetakse. Samuti töötavad filtrid ühtmoodi sõltumata sellest, kuidas kasutaja oma kirjade poole pöördub – olgu selleks siis POP3, IMAP või veebipõhine e-posti klient.

Serveripoolseid filtreid saab täna seadistada veebipõhise e-posti kliendi seadetes.

(Kasutajaliides filtrite loomiseks pole tõesti hetkel just kõige mugavam, aga see paraneb peagi.)

E-posti seadistamine on kiirem ja dünaamilisem

Postkastide lisamine ja e-posti sätete muutmine muutub palju kiiremaks ja platvorm reageerib muudatustele dünaamilisemalt. Lisatud e-posti aadressid hakkavad edaspidi normaalolukorras tööle kohe peale haldusliideses nupu vajutamist ja muud e-posti sätete muudatused jõustuvad samuti hetkega.

Postkasti kustutamine samas ei toimu enam hetkega – kustutamisele järgneb nüüd 14 päevane karantiiniperiood, mille möödudes postkast hävitatakse. Selle perioodi jooksul on serveri haldajal võimalik otsustada postkasti taastada või see kohe hävitada.  See viimane tähendab kogu postkasti sisu kadumist –  kadunud andmeid pole enam võimalik taastada isegi varukoopiast, sest ka need hävitatakse.

Teenused saavad uued aadressid

Selleks, et mitte sundida olemasolevaid kasutajaid kohe oma seadistusi muutma, oleme otsustanud, et uue e-posti platvormi poole pöördumisel tuleb kasutada uusi teenuste aadresse.

Iga e-posti protokolli jaoks on see nüüd unikaalne:

  • SMTP teenuse leiab aadressilt smtp.zone.eu;
  • IMAP teenuse leiab aadressilt imap.zone.eu;
  • POP3 teenuse leiab aadressilt pop3.zone.eu.

Iseenesest lihtne, kuid nõuab kindlasti harjumist, sest praegused aadressid on kasutusel olnud juba väga pikka aega ja paljudel nö “käe sees”.

Senised aadressid jäävad seotuks praegu tarbitava platvormiga.

Selleks, et e-posti seadistamine oleks lihtsam, oleme klientprogrammide seadistamise juhistele lisanud võimaluse tuvastada konkreetsele domeenile kehtivad sätted.

Postkastile nime valimine läheb lihtsamaks

E-posti aadresside loomisel ettevõttes moodustatakse see reeglina kasutaja ees- ja perenimest, seejuures eksisteerib kaks koolkonda – ühed kirjutavad need kokku (jaantamm@domeen.tld) ja teised eraldavad punktiga (jaan.tamm@domeen.tld).

Toome need leerid omavahel kokku ja muudame punkti postkasti nimes valikuliseks. Uuel platvormil viivad ühte postkasti nii aadressidele jaantamm@domeen.tld, jaan.tamm@domeen.tld kui ka j.a.a.n.t.a.m.m@domeen.tld saadetud kirjad.

IMAP kataloogipuu on lihtsam ja ühildub paremini rakendustega

Senine, mõnedele IMAP protokolli kasutajatele veidi segadust tekitanud, INBOX prefix kaob uute postkastide nimeruumist ära. Kõik alam-postkastid tehakse tulevikus vaikimisi postkasti juurkataloogi. See lahendus ühildub paremini kaasagsete kolmandate osapoolte rakenduste ning pilveteenustega.

 

Kas saaksid kiiresti ühe maksekorralduse teha?

Umbes sellise küsimusega hakkab pihta enamus CEO-kelmuse kirjavahetustest – ja viimastel päevadel on nende hulk järsult kasvanud. Suvi, firmades on osa inimesi puhkamas ning suhtlevad teistega äärmise vajaduse korral lühikeste, mobla-ekraanilt tipitud sõnumitega.

Kontorisse jäänutel on aga puhkajate asendamistega käed-jalad tööd täis ning olukord natuke uus ja ilma sisse harjunud käitumisreegliteta.

Näiteks võiks reedel, napilt enne lõunapausi, assistent Anne postkasti saabuda selline kiri tegevjuht Tiiult:

Ääremärkus: see ja järgmised kirjad on pärit ühe meie turvateadliku kliendi suhtlusest päris kelmidega. Nimed ja aadressid muudetud, fiktiivse firma nimi pärit ühest sotsmeedia-eksperimendist. Igaks juhuks ka tavakohane hoiatus “don’t try that at home work” – vaevalt, et neil sind maksma petta õnnestub… aga äkki võtab keegi trollimist südamesse ja leiab mõne turvaprobleemi mille ärakasutamise-katseks sa veel valmis pole.

Raamatupidaja on puhkusel, aga lõunalt naasnud Anne ülesandeks on kontor iga ilmaga toimivana hoida ja Tiiu saab peagi täpsustava küsimuse:

Viis minutit hiljem tuleb talt vastus:

Samuel on ilmselt rahamuul, kes on “töökuulutuse” peale olnud nõus oma kontole saabuvast rahast 90% sulas välja võtma ja Western Union’i kaudu edasi saatma.

Anne jääb hetkeks kirja uurima – aga peagi on postkastis järgmine kiri Tiiult, kellel ilmselt on maksega kiire:

Mistahes kelmuse puhul on oluline sundida ohver enne tegutsema ja alles siis mõtlema. “Ja-jaa, juba jooksen,” ohkab Anne – aga ta ei saa ju niisama maksta, sest raamatupidaja peaks selle kuidagi algdokumendiga kokku viima:

Ja saab vastuseks:

Nagu näha, sai Google Translate jälle natuke tööd teha ning kellegi nobedad näpud kopeerisid vastused Outlook’i.

Järgmine kord ei pruugi aga pettus nii kergesti märgatav olla, sest suhtluse kulg on üsnagi etteaimatav ja pole keeruline paarkümmend tüüpvastust inimtõlgilt tellida. Tegemist on ikkagi levinud kelmuseliigiga ja küllap leiab selle läbiviimiseks asjakohastest veebidest nii õpetusi kui ka tekstinäiteid. Brian Krebs’il on hea lugu veidi erinevast pettuseliigi ehk “vene kohtinguteenusest” toimimisest.

Jätame aga Tiiu ja Anne omavahel suhtlema ning vaatame…

Kuidas selline kelmus töötab?

Keerulisemate CEO-kelmuste puhul on tegemist ühe osapoole e-postikonto ülevõtmise ning päris arve võltsimisega. Sellist näidet kirjeldab Andris postituses Tõestisündinud lugu e-posti võltsimise tõttu kaotatud rahast ja ühte banaalselt lihtsat postikontosse sissemurdmist lahkas Ardi loos “Paha Panda” varastab postkaste.

Sedapuhku pole aga tegemist konkreetse firma vastu suunatud kuluka harpuunimisega ning Tiiu ja Anne kontaktid leiti pigem firma kodulehelt:

Veebifragment kelmidega kirjavahetust arendanud firma kodulehelt, pildid “Anna Malvara” loo juurest. Olgu lisatud, et mõlemad on 100% sünteetilised ehk 3D-renderdatud – Tiiu on pärit Renderpeople galeriist ja Anne leidsin üles ühest 3ds Max’i õpetusest.

Robotid skannivad tuhandete firmade veebe, korjates kokku e-posti-aadressid ning nendega seotud nimed ja rollid. Keegi hoolas inimene puhastab andmed ja müüb need kena Exceli-tabelina ahela järgmisele lülile maha – hinnajärk ilmselt sent per firma.

Ja see järgmine lüli saadab laiali spämmi, kus saatja real on kenasti From: Tiiu Kask <tiiu@malvara.ee>, kiri on saadetud mõne pahaaimamatu firma serverist (Return-Path: <vd@somehackedwebsite.com>) ja Outlook’i vms e-postikliendi puhul vastamisel kasutatav Reply-To aadress viitab kolmandale, samuti kelmi kontrolli all olevale serverile, kus kasutajanimest sõltumatult jõuavad kõik kirjad “operaatori” postkasti (Reply-To: "Tiiu Kask" <tiiu@vd-scammersdomain.org>):

Anne saab kogu suhtluse käigus kirju, kus saatjaks oleks justnagu õige Tiiu – aga tehes Reply läheb vastus vale-Tiiule.

Kuidas ennast selliste pettuste eest kaitsta?

Ma heameelega räägiks siinkohal vajadusest lisada oma domeenile SPF-kirje, mis võimaldab postiserveritel kontrollida, et malvara.ee kirju tohib saata ainult see üks ja õige server (loe: 3 tehnoloogiat, mis aitavad kirjad kindlalt kohale toimetada ja Kuidas kontrollida väljuva e-posti SPF+DKIM+DMARC toimimist?)… aga kuigi see on 100% mõistlik liigutus, peitub tegelik võti ikka meie endi peas – valmisolekus kelmust ära tunda ja kokkulepitud käitumisreeglites:

  • tea, et kiirusele rõhumine on sageli märk soovist sind tavapärasest erinevalt käituma panna ja e-posti on lihtne võltsida
  • vähimagi kahtluse korral kontrolli saatja tegelik soov üle, kasutades selleks alternatiivset sideviisi (loe: helista sulle teadaolevale, mitte kirjas toodud numbrile) või kasuta vastamise (Reply-To) asemel edastamist (Forward) sisestades teise osapoole aadress ise To-lahtrisse
  • sellise kelmuse ohvriks sattujad ei ole rumalad või hooletud – teine pool on suhtluse üles ehitanud lähtudes väga heast inimpsühholoogia tundmisest ning iga sammu läbi mõelnud, praktiseerides sellist tegevust “üheksast viieni” ehk põhitööna

Tänud kõigile, kes on võtnud vaevaks meile kirjanäidiseid saata ning eriti uudishimulikule “Annele”, kes tahtis teada mis toimub peeglitaguses maailmas 🙂