Suures plaanis võib Riigipilve IaaS teenusega seotud võrguteenused ja -teemad jagada kolme gruppi:

• IaaS teenuses sisalduvad võrguteenused (Riigipilve omateenused);

• IaaS võrguteenustega seonduvad lisateenused (Riigipilve omateenused ja vahendatud lisateenused);

• Toetatud võrgutopoloogiad IaaS teenuses (ehk raamistik “teen ise” rätsepalahendused).

Riigipilve IaaS teenuses sisalduvad võrguteenused

Kliendi poolt Riigipilve IaaS standardteenuses loodud virtuaalse privaatpilve ehk VPC ressurssipaketis sisalduvad järgmised võrguteenused:

• Kõrgkäideldav virtuaalne ruuter (VPC vRouter);

• Üks või mitu kõrgkäideldavat privaatvõrku (VPC LAN);

• Kõrgkäideldavad DHCP/IPAM/Metadata teenused VPC privaatvõrkudes;

• Port security turbereeglid igal VPC võrgupordil;

• Kliendi poolt hallatavad tulemüürireeglid igal VM-i võrgupordil (Security Groups).

Vaikimisi (flat) VPC võrgutopoloogia on näha järgneval diagrammil:

VPC vRouter pakub VPC privaat- ehk sisevõrkudele mitmeid erinevaid teenuseid. Kõige tavapärasemad neist on järgmised NAT teenused: SNAT (Masquerade) teenus vahendamaks turvaliselt VPC sisevõrgus asuvatele virtuaalmasinatele välisvõrku (jagades nende vahel vRouteri välisvõrgu IP aadressi) ning 1:1 NAT ehk Floating IP teenus, mis võimaldab reserveerida ja siduda välisvõrgu IP aadressi konkreetse sisevõrgus asuva võrgupordi/VM-iga. Samuti on võimalik VPC vRouteri abil liiklust marsruutida nii VPC sisevõrkude kui ka privaatühenduse lisateenuse kaudu kättesaadavate kliendi võrkude vahel. vRouter on kõrgkäideldavuse tagamiseks kolmekordselt dubleeritud (master-slave tüüpi klaster).

VPC sisevõrgud on üksteisest Layer2 tasemel eraldatud, seega sisevõrkude aadressiruumi osas Riigipilv piiranguid ei sea (st kõik on lubatud, RFC1918 piires). Sobiva aadressiruumi saab ise määrata iga võrgu loomisel. Kui on plaanis sisevõrkude vahel liiklust marsruutida, siis tuleks kohe alguses tagada, et marsruuditavate sisevõrkude aadressiruumid omavahel ei kattuks.

Igal VPC sisevõrgul on oma IPAM ehk IP Address Management teenus, mis pakub sisevõrgus loodavatele võrguportidele eelseadistatud aadressivahemikust IP aadresse. DHCP teenus võimaldab VM-i sees opsüsteemi poolt tuvastatud võrguliidestel ennast automaatselt seadistada. DHCP pakub võrguliidesele IPAM poolt võrgupordile eraldatud staatilist IP aadressi - ehk siis läbi DHCP jagatud võrguliidese IP aadress ei muutu pordi eluajal. Lisaks IPAM ja DHCP teenustele on VPC sisevõrkudes kättesaadav ka metadata teenus, mis võimaldab automatiseerida VM-ides seadistusprotsesse VM-i bootimisel (cloud-init) või hilisemas etapis. Võrgupõhise metadata kättesaamiseks on vajalik sisevõrgu ühendus vRouter-iga, selle puudumisel (ehk disconnected network puhul) on VM metadata kättesaadav config-drive meetodil (väike virtuaalne kõvaketas VM metadata andmetega, mis nähtav VM-i sees). Kõik VPC võrguteenustega seotud füüsilise infrastruktuuri sõlmed on Riigipilves kõrgkäideldavuse tagamiseks loodud liiasusega.

Igal VPC sisevõrgus loodud pordil rakenduvad vaikimisi “Port Security” turbereeglid, mis lubavad porti läbida vaid liiklusel, kus antud võrguport on üheks osapooleks (source või destination rollis). Samuti rakendatakse igal loodud VM-i võrgupordil automaatselt “default” tulemüürireeglite grupp, mis lubab VM-ist kogu väljuva liikluse ja lubab samas subnetis asuvatest VM-idest lähtuva sissetuleva liikluse ning keelab kõik muu. Kliendil on võimalik VPC skoobis koostada uusi tulemüürireeglite gruppe ja muuta olemasolevaid, sh asendada “default” reeglite grupp endale sobivama reeglistikuga. Meeles tasuks pidada, et keelates VM-ist kogu väljuva liikluse, ei ole võimalik vastata ka muidu lubatud sissetulevatele päringutele. VPC skoobis koostatud tulemüürireeglite grupid valitakse ja rakendatakse iga VM-i (ja selle pordi või portide) põhiselt. Ehk siis IaaS Security Groups teenuse puhul on põhimõtteliselt tegemist nö lihtsa laialijagatud tulemüüri ehk distributed firewall teenusega.

Võimekamaid tulemüüri ja võrgulüüsi lahendusi on võimalik saada nii lisateenusena Riigipilve teenuste turuplatsilt või luues endale ise sobivaid rätsepalahendusi, järgides Riigipilve IaaS teenuse poolt toetatud võrgutopoloogiaid, mida on lähemalt kirjeldatud järgnevates peatükkides.

IaaS võrguteenustega seonduvad lisateenused

Riigipilve teenuste turuplatsilt leiab mõned lisateenused, mis on seotud Riigipilve IaaS teenusega ning mis pakuvad võimalust realiseerida keerukamaid võrgutopoloogiaid ja võimekamaid tulemüüri/võrgulüüsi lahendusi.

Nende lisateenuste nimekirja kuuluvad:

• IP privaatühendus (Riigipilve omateenus)

• VPC otseühendus (Riigipilve omateenus)

• Check Point virtuaalne tulemüür (vahendatud lisateenus, Santa Monica Networks)

IP privaatühenduse teenus

Nimetatud teenus on mõeldud marsruutimaks turvaliselt liiklust kliendi Riigipilve IaaS teenuses asuvate sisevõrkude ja kliendi enda, nt väljaspool Riigipilve asuva infrastruktuuri vahel. Kliendi infrastruktuuri ja Riigipilve vaheline ühendus realiseeritakse kas füüsiliselt eraldatud fiiberühendusena või siis alternatiivina IPSec VPN tunneli näol üle avaliku võrgu. Füüsiline või tunneldatud privaatühendus termineeritakse ühte või siis mõlemasse Riigipilve IaaS teenuse asukohta (mis ühtlasi tagab ühenduse kõrgkäideldavuse). Teenusega ühendatakse kliendi poolt soovitud VPC sisevõrgud - sõltumata nende asukohast - ehk siis privaatühenduse teenus toimib ka Riigipilve IaaS saitide vahel. Privaatühenduse teenust on võimalik lisada kõigile Riigipilve IaaS teenuse poolt toetatud võrgutopoloogiatele.

Privaatühenduse näidistopoloogia on toodud järgneval diagrammil:

Millal ja milleks kasutada IP privaatühenduse teenust?

• Turvaliseks liikluse marsruutimiseks Riigipilve IaaS teenuses olevate sisevõrkude ja oma andmekeskuse/kontori/vms infra vahel;

• Turvaliseks liikluse marsruutimiseks Riigipilve IaaS teenuses olevate erinevate VPC-de sisevõrkude vahel, sh sõltumata nende VPC-de asukohast;

• Riigipilve IaaS teenuse kasutamiseks ilma välisvõrguta (kliendi enda ruuter kui default gateway).

VPC otseühenduse teenus

Tegemist on nö stretched VLAN teenusega vähemalt kahe erineva VPC vahel, olenemata nende VPC-de asukohast. Teenus on eelkõige mõeldud lahendamaks neid kasutusjuhte, millele marsruuditud privaatühendus ei sobi: nt mittemarsruuditavatel võrguprotokollidel põhinevad klastrite membership lahendused või missioonikriitilised andmete replitseerimismehhanismid.

Millal ja milleks kasutada VPC otseühenduse teenust?

• Kahe IaaS saidi vaheliste klasterlahenduste ehitamiseks, mis nõuavad oma toimimiseks jagatud Layer2 võrku (nt VRRP);

• Andmete replitseerimiseks või sünkroniseerimiseks, kasutades Layer2 otseühendust kahe erineva VPC vahel, olenemata nende asukohast.

Check Point virtuaalse tulemüüri teenus

Nimetatud teenus on mõeldud eelkõige nendele klientidele, kes vajavad rohkem kontrolli, lisafunktsionaalsust ja paremat ülevaadet oma VPC võrgulüüsi üle (kui seda pakuvad IaaS teenuses vaikimisi sisalduvad võrguteenused nagu vRouter ja Security Groups). Check Point virtuaalse tulemüüri lahendus on realiseeritud nö traditsioonilise gateway VM-i näol, mis pakub järgnevat funktsionaalsust: L3 gateway, IP firewall, IPS/IDS, IPSec VPN, DoS/DDoS kaitse. Lahenduse võimalikud võrgutopoloogiad on põhjalikumalt lahti seletatud järgmises peatükis ning tellimise valikutes on ka sama VPC piires klasterdatud Check Point lahenduse võimalus.

Toetatud võrgutopoloogiad IaaS teenuses

Riigipilve IaaS teenuses vaikimisi kasutatavast Flat VPC võrgutopoloogiast oli juba põhjalikult juttu eespool, kus VPC sisevõrkudest pärineva liikluse marsruutimiseks on kasutusel virtuaalne vRouter, mis lubab VPC sisevõrgud ühendada Riigivõrgu kaudu välismaailmaga ja pakub sisevõrkudes olevatele VM-idele avaliku IP teenust. Tulemüürireeglid kehtestatakse igal VM-i võrgupordil (distributed firewall).

Kui tahta kogu VPC võrguliiklust suunata läbi enda kontrolli all oleva lüüsi (vt allpool olevat “Enterprise” turvalüüs diagrammi), et seal rakendada täiendavat funktsionaalsust või lisavõimekusi (IPS, IDP, DoS, jne), siis on vajalik realiseerida nö custom gateway VM topoloogia kas ühe VPC piires või siis jagatud teenusena (kus üks gateway VM saab teenindada mitme erineva VPC sisevõrke). Alternatiivse lahendusena saab kasutada ka privaatühenduse teenust, et marsruutida kogu VPC-dest lähtuv liiklus enda olemasolevasse infrastruktuuri, kus on näiteks võimekamad turvalüüsi teenused juba varasemalt olemas (riistvaralised seadmed vms). Sel juhul peab arvestama, et Riigipilve Floating IP teenust ja sellega kaasnevaid Riigipilve poolt pakutavaid välisvõrke pole võimalik oma infras asuva turvalüüsiga samaaegselt kasutada, kuna need teenused vajavad oma toimimiseks VPC vRouter-it, mis oleks ühendatud Riigipilve välisvõrguga ja mis oleks VPC jaoks default gateway.

Lisaks täishallatud Check Point virtuaalse tulemüüri teenusele on Riigipilves klientide endi poolt edukalt rakendatud näiteks Fortigate, Sophos ja Mikrotik virtuaalsete tulemüüride tooteid. Oluline on siinjuures märkida, et hetkel on allpool kirjeldatud custom gateway VM topoloogiate rakendamiseks vajalik kasutada osaliselt ka Riigipilve OPS meeskonna abi, kuna mõned sammud nende topoloogiate seadistamisprotsessides vajavad täiendavaid privileege.

Üldised nõuded custom gateway VM topoloogiate rakendamiseks:

• üks VPC vRouteriga ühendatud sisevõrk gateway VM-i enda jaoks (ehk gw WAN);

• vähemalt üks VPC vRouterist lahtiühendatud (disconnected) sisevõrk loodavate virtuaalmasinate jaoks (ehk gw LAN);

• Openstack Dashboard ligipääs VPC võrguhalduseks (isikustatud konto saab tellida iseteeninduse kaudu VPC haldusmenüüst -> Request direct access);

• Tarkvaralist võrgulüüsi peab olema võimalik käitada VM-ina Riigipilve IaaS teenuses. Check Point virtuaalse tulemüüri toode on teenusena Riigipilves valideeritud ja toetatud lahendus ning teadaolevalt on kliendid edukalt kasutanud ka teiste tootjate (Fortigate, Sophos, Mikrotik) tarkvaralisi lahendusi, millele Riigipilv täna ise ametlikku tuge ei paku.

Custom gateway VM topoloogia kasutuselevõtul tuleks ära otsustada, et kas loodav lahendus on mõeldud teenindamaks vaid ühte VPC-d või kui eksisteerib võimalus, et tulevikus soovitakse võrgulüüsi teenust jagada ka erinevate VPC-de/projektide vahel, siis tuleks kohe alguses valida multi VPC lahenduse variant.

Traditsiooniline “Enterprise” turvalüüs (single VPC variant)

Nimetatud võrgutopoloogia korral lisatakse vaikimisi kasutatavale Flat VPC võrguskeemile tarkvaraline võrgulüüsi lahendus virtuaalmasina kujul ning luuakse üks või rohkem VPC sisevõrku, mis ei ole vRouter-iga ühendatud (disconnected subnet). Loodud sisevõrku tekitatakse gateway VM-i jaoks võrguport ning subnet tasemel määratakse antud gateway VM-i võrguliides sisevõrgu jaoks vaikimisi lüüsiks ja edaspidi käib kogu väljuv liiklus läbi kliendi kontrolli all oleva gateway VM-i. Siinjuures vajab äramärkimist asjaolu, et kuna Riigipilve Floating IP (1:1 NAT) teenus on realiseeritud VPC vRouteri juures, siis custom gateway VM taga olevatele VM-idele otse enam avaliku võrgu IP-sid lisada ei saa. Küll aga saab custom gateway VM-il endal olla mitu Floating IP-d ning nendelt avaliku võrgu IP aadressidelt sissetulevat liiklust saab ise edastada sisevõrgu VM-ideni port forward või 1:1 NAT reeglite abil. Kirjeldatud võrgutopoloogia loogiline skeem on kujutatud alljärgneval diagrammil:

Oluline on siinkohal meelde tuletada, et vaikimisi rakendatud “Port Security” turbereeglid gateway VM-i võrguportidel (diagrammil kui GW Port # elemendid) lubavad neid porte läbida vaid liiklusel, kus konkreetse võrgupordi IP ja mac aadress on üheks osapooleks (source või destination rollis). Lüüside puhul (nagu seda on ruuterid või nt VPN serverid) läbib lüüsi võrguporte liiklus, mille puhul võrguportide endi IP/mac aadressid ei ole ei source ega ka destination rollis - seega vaikimisi neid pakette ei edastata. Selleks, et nende pakettide edastamist pordil lubada, tuleb “Port Security” reeglid pordil tervenisti välja lülitada või lisada pordi “Allowed address pair” tabelisse whitelistitud võrgumaski(d).

NB! “Port Security” väljalülitamisel või pordil “Allowed address pair” whitelisti võrgumaski lisamisel tuleb kindlasti meeles pidada, et sellisel juhul antud pordil “Security Groups” tulemüürireeglid ei rakendu! “Allowed address pair” võrgumaski lisamisel ei rakendu reeglid ainult whitelistitud maskiga seotud liiklusele ja “Port Security” täielikul väljalülitamisel ei ole pordil “Security Groups” tulemüürireegleid enam üldse võimalik rakendada. Mis on antud juhul täiesti soovitud tulemus - sest võrguliikluse turbereegleid võiks lüüside puhul rakendada ja hallata ainult lüüsis endas, selmet neid dubleerida veel ka iga gateway pordi “Security Groups” ja “Port Security” reeglistikes.

Turvalüüs “kui jagatud teenus” (multi VPC variant)

Juhul kui on plaanis rakendada custom gateway VM topoloogiat ja on soov jagada oma tulemüüri mitme projekti/VPC vahel, siis tuleks kohe alguses seadistada turvalüüs “kui jagatud teenus” mudelit kasutades (vt järgnevat diagrammi).

Peamine erinevus eelpool kirjeldatud traditsioonilise “Enterprise” turvalüüsi topoloogiaga seisneb selles, et turvalüüs rajatakse eraldi VPC-sse ning sellele võimaldatakse ligipääs teistes kliendi VPC-des loodud sisevõrkudele (valikuliselt). Oma sisevõrkudele ligipääsu jagamine erinevate VPC-de vahel ei ole täna veel kliendi enda poolt iseteeninduslikult tehtav protseduur ning selle sooviga tuleb pöörduda Riigipilve kasutajatoe poole, kes korraldab tellitud muudatused.

Autor: Andres Toomsalu (Riigipilve arhitekt, Opennode OÜ)