Uudised, sündmused ja blogi

CENTR arendus - "kõik registrid pilve" ja isikuandmed ehk R&D11

Teatavasti jagunevad registrid kaheks - need, kes arvavad, et register ei peaks domeeni taga toimuvasse sekkuma ja need, kes ei näe teist võimalust. EIS kaldub pigem esimesse gruppi. Domeeni taga toimuva jälgimise eesmärk on tavaliselt tuvastada ja tõkestada ebasoovitavat tegevust nagu pahavara levitamine. Meil pole selleks piisavalt kompetentsi ja ressurssi võrreldes politsei ja CERT-ga. Samal ajal otsivad aga registrid, kes domeenide taga toimuvaga ennast kursis hoidmist ei pelga, sellele infole uusi rakendusi. Tegeletakse nö veebi roomamisega (web crawling), mille käigus kaardistatakse oma tsoonis domeenid, mille taga kodulehte pole, mida lihtsalt pargitakse ja grupeeritakse valdkondade põhiselt toimivad kodulehed. Eesmärk on ühelt poolt turunduslik, et tunda paremini oma klienti ja sihtida turundustegevusi. Teiselt poolt on see sisendiks domeeni registreeringute prognoosimiseks - on ju domeenid, kus taga midagi ei toimu väiksema tõenäosusega pikendatavad. Kuna iga register kipub omaette vastavaid töövahendeid arendama, siis tuli selles seltskonnas jutuks, kuidas neid pingutusi ühtlustada ja panustada pigem ühiselt ühe ja väga hea tarkvara arendamisele. 

Nii belglased kui rootslased on nõuks võtnud siseriiklike nimeserveri pilvede (anycast) arendamise selliselt, et võrku kuuluvad nimeserverid paiknevad kohalike internetiteenuse pakkujate (ISP) juures. Nii tagatakse eeldatavasti kiirem ja kvaliteetsem DNS-teenus nende ISP-de klientidele. Idee, mille peale meilgi oleks nutikas mõelda. Siiski tundub, et oma nimeserveri ISP juurde asetamise asemel oleks ehk mõistlikum sõlmida nendega leping ja jätta serverihaldusega seonduv vastava ISP hooleks.

Domeeniregistritest on GDRP-ga kõige kaugemale jõudnud Holland - neil on paigas 3-liikmeline isikuandmete kaitse komisjon, mis tegeleb vastavate protseduuride väljatöötamise ning täitmise järelvalvega. Holland tõi välja oma senise töö tulemusena tehtud järeldused - "õigus olla unustatud" ei ole absoluutne ja ei puuduta näiteks arhiveeritud andmeid. Samuti juhtisid nad tähelepanu, et kui tegemist on ühemehe firmaga, mille nimi sisaldab selle isiku nime, võib registripidaja, aga ka ükskõik millise teise ettevõtte, puhul olla tegemist isikuandmetega. Küsimusega, kas IP-aadress on isikuandmed või mitte, hollandlased enam ei tegele kustutades logidest allika IP-aadressid. Paljud registrid hoiavad ja töötlevad näiteks ka DNS-logisid igavesti. Saab olema huvitav näha, kuidas nad seda tulevikus põhjendavad, sest küllalt raske on argumenteerida, miks peaks logisid hoidma alles enam kui kaks kuud.

Taani register on haaramas või on juba haaranud meilt Euroopa kõige kõvema isikutuvastusega registri tiitli. Mäletatavasti on Taanis registrile seadusega pandud kohustus tagada Taani eraisikute ja äriühingute andmete korrektsus oma andmebaasis. Selle tulemusena on kõik Taani era- ja juriidilisest isikust domeeni kontaktid pidevalt kontrollitud vastu kohalikke registreid. Trooni me niisama lihtsalt ära veel ei annaks, sest meie üldlevinud elektrooniline ID tagab tugevama isikutuvastuse, kuid seda vaid registreerimise protseduuri läbiviiva isiku üle. Kahjuks jätab aga esitatavate andmete tõepärasuse kontroll selles kontekstis meil veel palju soovida. Taani register püüab leida head lahendust ka välismaiste kontaktide andmete kontrolliks. Hetkel suuresti käsitööna toimuva protsessi käigus vaadatakse läbi kõik sissetulevad registreeringud ning antakse neile semafori stiilis hinnang: roheline - pole põhjust andmetes kahelda, registreering viiakse lõpuni; kollane - andmed tekitavad kahtlusi, registreering viiakse küll lõpuni (domeen lisatakse tsooni), kuid registreerijal on ette antud aeg esitada enda isiku tõendamiseks vajalik dokumentatsioon; punane - dokumentatsiooni nõutakse enne domeeni registreerimise lõpule viimist. Seega lasub põhikoormus isikutuvastuse ja dokumentatsiooni kontrolli üle registril, mis on põhimõtteliselt erinev meie ja enamiku teiste registrite lähenemisest, kus kõik vastavad toimingud viib läbi registripidaja. Meie puhul on registripidaja lisaks kohustatud osa sellest materjalist tõendina registrile edastama. Taani on oma lähenemiselt kõige lähemal meie poliitikale, mistõttu jälgime nende tegemisi suure hoolega.

Suvel välja hõigati,, et Rootsi domeeniregister liigub järjekindlalt suunal saada belglaste järel teiseks pilves toimetavaks riigitunnusega tippdomeeni registriks. Sarnaselt Belgiale valisid ka nemad partneriks Amazoni. Rootsi vaatas konkureerivaid pakkumisi nii kohalikelt teenusepakkujatelt kui ka Googlelt ja Microsoftilt, aga leidis, et Amazoni pakkumine ja võimalused on täiesti omaette maailmast. Sihiks on jaanuaris 2018 lülitada oma serverid välja. Võrreldes belglastega jätavad nemad enda juurde veidi suurema hulga taristust, lisaks registriandmeid ja tarkvara hoidvale varukoopiate serverile ja .se domeeni teenindavatele nimeserveritele ka HSM-d DNSSEC-i võtmete hoidmiseks. Pilve kolimise põhjusena tõid nad välja nii oma arenduste kui kogu IT-taristu väga kõrgeks kerkinud hinna - väikese süsteemi osa muutmiseks tuli tunda kogu süsteemi, erinevate keskkondade ja süsteemi üleval hoidmiseks oli serveripark kasvanud juba enam kui 150 erineva serverini, mis tõi omakorda kaasa suure halduskoormuse. Rootslased küsisid endalt kui väga nad riistvara armastavad. Ja nii otsus sündis. Ühe eredama võiduna tõid nad välja näiteks andmebaaside erinevate süsteemi asukohtade vahelise sünkroniseerimise ja ümber lülitamise. Kui enne võttis see aega 2 päeva, siis Amazonis toimub see momentaalselt ühe nupuvajutusega. Lisaks annab korralik pilvelahendus palju parema vastupidavuse DDoS rünnetele.

Pilve kolimiseks muutis .se oluliselt oma tarkvaraarhitektuuri minnes üle mikroteenustele: lõppkasutajakiht, sõnumi kiht (RabbitMQ), süsteemikiht ja andmebaas. Andmebaasina otsustasid nad jätkata SQL-ga võttes kasutusele Amazoni versiooni MariaDB-st. Skaleerimise juurutamine oli rootslaste hinnangul suhteliselt lihtne. Konteinerid tagavad märkamatu tarkvara uuendamise - sisuliselt on tegemist blue-green mudeliga, kus uus versioon süsteemist pannakse valmis ja sobilikul hetkel suunatakse kogu liiklus lihtsalt ümber (zero downtime).

Rootslaste põhisüsteem hakkab paralleelselt jooksma kõigis kolmes Amazoni Iirimaa serveripargis (availabilty zone). Lisaks on kasutusel ka kaks Amazoni asukohta Frankfurdis, kus paikneb nn külm varukoopia süsteemist: andmebaasid on sünkroonis, kuid süsteem ise ootab, et vajaduse saabudes see lihtsalt käivitatakse. Ja et sellest veel väheks ei jääks, on üks nn viimase häda (Disaster recovery) asukoht ka Stockholmis (ei ole registri ruum ega serverid), kus on kohapeal absoluutne miinimum süsteemi tööks vajalikust. Lisa asukoha tagamõte on äri jätkusuutlikkus (business continuity), et maandada Amazonist tulenevaid riske. Koormuse jaotamiseks kasutavad Elastic Load Balanceri. Siin on palju mõtlemisainest ka meile.

Järgmise korrani.