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 võimalik 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.

 

Ettevaatust! Vana pettus uues kuues

Euroopa Liidu tippdomeeni registrit pidav EURid hoiatab eksitavaid kauplemisvõtteid kasutavate agressiivsete petturite eest, kes üritavad rahvuslikes tippdomeenides (nagu .EE) domeene omavatele isikutele kaubamärgi kaitsmise kattevarjus peale suruda EU-lõpulisi domeene.

Petturite skeem on lihtsakoeline ja meile jõudnud ilmselt Aasiast, kus seda praktiseeritud juba väga pikka aega. Lühidalt kokkuvõttes näeb see välja järgmine:

Ühel päeval saab ettevõtja, kes omab näiteks domeeni MILJONIVAADE.EE ootamatult kirja, milles end kaubamärkide ja intellektuaalse omandi kaitse spetsialistina tutvustav isik annab teada, et tema poole on pöördutud MILJONIVAADE.EU nimelise domeeni registreerimise sooviga, aga “heatahtlik” spetsialist on otsustanud esmalt pöörduda MILJONIVAADE.EE omaniku poole, et pakkuda hoopiski tollele võimalust .EU nimi mõistliku hinna eest endale saada. “Spetsialist” rõhutab, et aega selleks on aga vähe. Reaalsus on loomulikult see, et mingit tegelikku MILJONIVAADE.EU huvilist ei ole ja ka “mõistlik hind” ei pruugi kuigi soodne olla.

Tegemist on klassikalise ebaausa kauplemisvõttega, millesarnaste kirjeldusi leiab mitmeid näiteks meie Tarbijakaitse kodulehelt https://www.tarbijakaitseamet.ee/et/tarbijale/ebaausad-kauplemisvotted.

Mida on oluline aga tähele panna on see, et kuna pakkumine tehakse reeglina ettevõttele, siis Tarbijakaitse siinjuhul pärast enam tehingust taganeda ei aita. Sellegipoolest soovitab EURid sellise pettuse ohvritel teavitada sellest oma riigi ametivõime.

Loomulikult soovitab EURid kasutada domeenide registreerimiseks usaldusväärseid akrediteeritud registripidajaid, kelle hulka kuulub ka Zone.

P.S. Seda postitust üle lugedes tekkis tunne, et oleksin sellest nagu varem kirjutanud ning etskae – pea täpselt kümme aastat tagasi kirjutasin siinsamas hoiatuse Soome kohta, kus siis seda skeemi prooviti: https://blog.zone.ee/2008/04/07/rehepaplusest-domeeninimede-abil/ ja veelkord etskae – toona on teemat kommenteerinud keegi Peeter Marvet, kellest tänaseks on saanud meie blogi üks peamiseid kirjatsurasid! 🙂

30. juunist jõustub e-kaubanduse jaoks oluline HTTPS nõue

Käesolev blogipostitus on peatähtis läbi lugeda neil, kes tegelevad oma kodulehe vahendusel kaubandusega, kuid see on kindlasti oluline teadmiseks võtta ka teistele.

30. juunist ei luba Payment Card Industry Data Security Standard (PCI DSS) makseandmeid käsitlevate veebilehtede omanikel enam kasutada aegunud SSL/TLS turvastandardeid.

Selliste lehtede haldajad peaksid 30. juuniks veenduma, et nende HTTPS ühendused oleksid seadistatud järgmiselt:

1) SSL standardi kasutus peab olema täielikult keelatud;
2) kasutusel olev TLS protokoll peab olema vähemalt 1.1 või uuem.

Zone klientidel on hetkel seis selline:

1) SSL standardi kasutus on täielikult keelatud;
2) vaikimisi kasutusel olev TLS protokoll on 1.0 või uuem.

Rõhutan, jutt on konkreetselt SSL standardist! SSL-i terminit kasutatakse nii meil kui mujal (valesti) iseloomustamaks paljusid turvatud ühendusi, kuigi enamik neist põhineb tänapäeval juba TLS standardil.

Meie hoolsatel, turvateadlikel ja standardiga ühilduvust soovivatel klientidel on aga võimalus haldusliideses paari klikiga keelata vanemate TLS versioonide kasutamine. Selleks tuleb Virtuaalserveri haldusliideses Veebiserveri seadete alt muuta sätet “Luba aegunud TLS versioonide kasutamine”.

Võib kerkida küsimus, miks me TLS 1.0 kasutust üldiselt ära ei keela? Põhjus peitub selles, et interneti sügavustes eksisteerib veel mitu kihti internetti, üks neist on nö “asjade internet” ja teine “skriptide internet”. Need on internetikihid, millel püsib hoomamatu hulk meid ümbritsevaid protsesse ja milles iga suurem muudatus tähendab meie klientide jaoks ettearvamatuid tagajärgi.

Asjad, mis TLS 1.0 keelamisega võivad näiteks veebile ligipääsu kaotada:

* vanemad mobiiltelefonid;
* vanemad või odavamad käsiterminalid;
* vanemad või odavamad multimeediakeskused;
* vanemad operatsioonisüsteemid ja nende veebilehitsejad;
* vanemad skriptid ja programmid.

Ülevaatlikku tabelit erinevate seadmete TLS ühilduvusest üritab pakkuda muuhulgas GlobalSign.

Üks sarnane varasem iidvana protokolli toe lõpetamine on meie jaoks  näiteks lõppenud kõnega ühest logistikafirmast, mille käsiterminalid lõpetasid lennujaamas töö.

Erinevatel andmetel moodustab TLS 1.0 liiklus hetkel 5-11% kogu HTTPS-i abil turvatud ühenduste mahust.

Seetõttu oleme otsustanud, et jätame vanema TLS versiooni (TLS 1.0) kasutamise keelamise esialgu kliendi otsustada ning lükkame selle vaikimisi välja lülitamise veidi edasi, kuni teadlikkus on klientide hulgas veidi kasvanud.

Põhjus, miks PCI on otsustanud vanemate turvastandardite toetamise keelata peitub nende vanuses.

SSL (Secure Sockets Layer) on standardina olnud maha kantud juba tükk aega tagasi, kuid lühend ise elab turvatud ühendusi sümboliseeriva terminina inimeste teadvuses veel edasi. Reaalsuses lasti selle standardi viimane suurem versioon välja 1996. aastal ning aastast 2015 on selle kasutus sisuliselt keelatud (https://tools.ietf.org/html/rfc7568).

SSL-i asendas 1999. aastal standard TLS (Transport Layer Security) versiooniga 1.0 ning sellele on järgnenud versiooniuuendused 1.1 (2006 aastal) ja 1.2 (2008 aastal). 2018. aasta märtsist eksisteerib, peale pikka ja vaidlusterohket arendustööd, standardi mustandina ka TLS versioon 1.3, kuid selle laiemasse kasutusse jõudmine võtab veel veidi aega.

Mõlemad on olnud haavatavad tänu mitmetele nõrkustele, mis kandnud vahvaid nimesid nagu POODLE, BEAST, FREAK, BREACH, CRIME jt ning nende ja muude selliste aukude lappimine ei ole lihtsalt jätkusuutlik.

Nüüd saadaval kauaoodatud .APP domeenid

Maailmas laineid lööv .APP tippdomeen on saadaval ka Zone.ee klientidele.

.APP (loe: äpp) tippdomeeni nimeruum on eelkõige suunatud veebi-, mobiili- või töölauarakenduste pakkujatele ja arendajatele. APP-lõpuliste domeenide registrit pidav Google loodab, et selline veebiaadress aitab inimestel lihtsamini ja kiiremini leida neile olulisi rakendusi ning saada nende kohta infot.

Ühtlasi on .APP üks esimestest tippdomeenidest, mis tunnistab vaikimisi vaid HTTPS (HTTP+TLS) tehnoloogia abil turvatud veebiühendusi. Nimelt on kogu tippdomeen kantud kõikidesse populaarsematesse veebilehtisejatesse eellaetud HSTS (HTTPS Strict Transport Security) poliitika nimekirja. Krüpteerimata veebiteenuseid ei ole sellises tippdomeenis sisuliselt võimalik avalikult pakkuda.

Eelnev teeb muuseas .APP tippdomeenist hea partneri meie Virtuaalserverile, mille puhul on turvalised ja krüpteeritud HTTPS ühendused juba pikemat aega teenuse vaikesätteks ning tasuta Let’s Encrypt TLS sertifikaat olemas igale veebisaidile.

Üleilmselt on .APP tippdomeen hästi vastu võetud, avalikule registreerimisperioodile eelneval piiratud ja kallil eelregistreerimiste etapil on juba registreeritud üle 8000 uue .APP domeeni. Lähipäevadel on ilmselt oodata kümneid tuhandeid uusi registreerimisi.

TÄHELEPANU! .APP domeenid on nüüd vabalt registreeritavad, kuid tulenevalt regulatsioonist peab registreerija oma domeenisoovi peale Zone lehe kaudu tellimuse esitamist ka täiendavalt kinnitama. Selleks jõuab registreerija postkasti Zone nimel inglisekeelne sõnum pealkirjaga “Authorization needed for application of the domain name”, millele tuleb kindlasti reageerida. Vastasel korral taotlus tühistatakse.

Uus arendajasõbralikum veebilogide haldamise kord

Veebiserveri logide haldamise kord on Zone tarkvaraplatvormis läbimas ulatuslikku reformi, mis loob meie arendajatest klientidele uusi väärtuslikke võimalusi. Käesolevas blogipostis kirjutan uuest korraldusest lähemalt.

Uue korra kohaselt on Virtuaalserveri teenuse kliendi käsutuses reaalajas uuenevad veebiserveri logid. Kui varasemalt uuenes reaalajas vaid probleemide tuvastamiseks vajalik vealogi (Error Log) ning päringute logi pakkusime arhiivina, siis nüüdsest on klientide käeulatuses reaalajas uuenev päringute logi (Access Log).

Veebiserveri logid leiab klient Virtuaalserveri ‘logs’ kataloogist. Logimisel tehakse vahet turvamata ja turvatud ühendustel, mis salvestatakse eraldi failidesse (apache.ssl.access.log ja apache.access.log).

Virtuaalserveri alamdomeenide vea- ja päringulogid kombineeritakse peadomeeniga. Päringuid on võimalik logis üksteisest eristada sedaläbi, et iga rida algab seda konkreetset päringut teenindanud hosti nimega.

Veebiserveri logi kirje formaat põhineb Apache Combined Log’il. Kasuliku ja unikaalse lisavõimalusena paneme me PHP päringute puhul logisse kirja ka selle unikaalse identifikaatori ning PHP koodi töötlemisele kulunud aja (‘wallclock’ sekundites). Need aitavad arendajatel oma rakenduste jõudlust paremini monitoorida ning meil ühiselt probleeme ‘troubleshoot’-ida.

Juhin tähelepanu asjaolulule, et logiridade kronoloogiline järjestus ei ole absoluutne – aeglasemad päringud võivad järjestuses sattuda oma noorematest, kuid kiirematest sõsaratest tahapoole.

Logisid roteeritakse endiselt Zone poolt, kuid vaikimisi säilitatakse kliendi Virtuaalserveris nüüd viimase nelja päeva logisid. Need asuvad failides mille nimed on kujul apache.ssl.access.log.[1-4].gz. Eelmise päeva logi on seega alati failis apache.ssl.access.log.1.gz.

Kui kliendil on soovi oma logisid arhiveerida, siis on tal võimalik neid endale kopeerida enda seadistatud crontab’i töö abil, mis käivituks näiteks kell 00:10, arhiveeriks nii HTTP kui HTTPS logid ka kustutaks logid mis vanemad kui 30 päeva:

mkdir -p [[$D2ND_A]]/logs-archive/ && cp [[$D2ND_A]]/logs/apache.access.log.1.gz [[$D2ND_A]]/logs-archive/apache.access.log.$(date +%Y%m%d).gz && cp [[$D2ND_A]]/logs/apache.ssl.access.log.1.gz [[$D2ND_A]]/logs-archive/apache.ssl-access.log.$(date +%Y%m%d).gz && find [[$D2ND_A]]/logs-archive/ -mtime +30 -delete

Alates PHP versioonist 7.0 logitakse meil sarnasel printsiibil ka PHP tegevust. Varasematesse PHP versioonidesse sellist logimise tuge meil ei tule, seega on viimane aeg PHP ‘retro’ versioonidest loobuda.

Vana korra järgi seadistatud klientidel on võimalik uuele logide kasutuskorrale üle minna vabatahtlikult Virtuaalserveri seadistuses tehtava valiku kaudu.

Uue logide haldamise korra opt-in

Ühel hetkel lõpetame vana korra toetamise ära, kuid see ajakava ei ole veel paigas.

UPDATE: Tasub veel ära mainimist, et muutunud on ka Apache vealogide (ErrorLog) nimetused on nüüd apache.error.log ja apache.ssl.error.log. Nende roteerimise kohta kehtib kõik ülaltoodu.