Joulun lounaskeskusteluissa minulle tarjottiin uudenkarheaa NGFW-palomuurilaitteistoa testiin. Totesin mielelläni tutustuvan tuotteeseen ja sen API-integraatioihin, joskaan en usko palomuurilla olevan roolia tulevaisuuden verkkopalveluissa. Vastaukseni sai aikaiseksi hämmennystä. Onhan palomuuri verkkojen legenda, joka toimii monen yrityksen tietoturvan kivijalkana. Palomuureilla ollut merkittävä rooli myös omalla urallani. Matkalla olen seurannut sovellusarkkitehtuurien ja digitalisaation vaatimusten muuttuvan suuntaan, jossa palomuuria on hankala soveltaa. Siksi väitän, että palomuurit kuolevat 2030-luvulla tarpeettomana.
HPC ja AWS™ tulevaisuus
Yksi merkittävä signaali on High Performance Computing (HPC) vaatimus nopealle tiedonsiirrolle. Konesalin optiset verkot mahdollistavat suuret siirtonopeudet, mutta TCP/IP-protokolla muodostuu pullonkaulaksi. Epäluotettavalle Internet-verkolle suunniteltu TCP-protokolla varmistaa IP-pakettien saapuminen oikeassa järjestyksessä, mutta aiheuttaa suuren siirtoviiveen. Siirtoviiveen aikana HPC on tyhjäkäynnillä. Toinen ongelma on TCP Single-path arkkitehtuuri, joka estää tiedonsiirron skaalautumisen usealle optiselle yhteydelle. AWS™ kehittämässä SRD-protokollassa nämä ongelmat on eliminoitu. AWS™ ENA Express konseptissa ei käytetä TCP/IP-protollaa.
Minkälaisen palomuurisäännön teet, jos käytössä ei ole TCP/IP-protokollaa?
Palomuurin säännöstö on perustunut IP-osoitteiden ja TCP/UDP-porttien rajoittamiseen. Mikäli käytössä ei ole TCP/IP, ei nykyisillä palomuureilla tee mitään. Vastaavasti suuri osa palomuurin lisäpalveluista perustuu TCP/IP:n ympärillä tapahtuvaan analysointiin.
HTTP/3 ja Windows 2022 server
Samasta suorituskykyhaasteesta HPC kanssa kärsivät lähes kaikki verkon palvelut. Siirtoviiveen pienentäminen ja tiedonsiirron nopeampi prosessointi vaatii kehittyneempiä protokollia. Käyttäjälle näkyvää siirtoviivetta ei merkittävästi voida parantaa muilla keinoin. Tähän haasteeseen on törmännyt myös 5G ja valokuituyhteyksien tarjoajat. Käyttökokemukseen vaikuttava end-to-and latenssi näkyy usein kohtuuttoman suurena sovellusten ja verkon analysoinnissa.
Tietoliikenneverkot ovat 40-vuodessa muuttuneet luotettaviksi ja nopeiksi verrattuna 80-luvun teknologiaan, kiitos optisen tiedonsiirron ja mikropiirikehityksen. Latenssia ei voida juurikaan parantaa verkoilla, vaikka se usein argumenttina esitetäänkin. Nopeita ratkaisuja palveluiden vasteajan parantamiseen on etsitty UDP (QUICK)-protokollasta. Se soveltuukin hyvin nykyiseen Internet-, ja yritysverkkoon ollen merkittävästi TCP-protokollaa nopeampi. Uudet http/3 ja Windows™ 2022 palvelimet osaavat hyödyntää protokollaa seuraten sosiaalisen median sovelluksia.
Palomuureille UDP on ongelma
Suurin osa palomuuriteknologian valmistajista on vuosia ohjeistanut estämään UDP (QUICK)-protokollan käyttämisen. Se kertoo ongelman vakavuudesta. Palomuurissa OSI-tasojen 4–7 packet inspection teknologia on kehitetty TCP-protokollalle ja HTTPS inspection SSL/TLS-protokollalle. UDP (QUICK) korvaa sekä TCP-, että TLS-protokollat. Palomuuri siten käytännössä rajoittaa digitaalisten palveluiden käyttäjäkokemusta yhä enemmän. Ennustuksestani huolimatta suosittelen päivittämään palomuurin tai siirtymään NaaS/Cloud Firewall. Jos hankit vielä oman laitteiston, varmista, että kapasiteetti ja ominaisuudet kattavat UDP (QUICK) parhaalla mahdollisella tasolla.
Sovelluskehitys vs. verkkotiimi – Molemmat oikeassa?
Oletko koskaan osallistunut keskusteluun, jossa todetaan: ”sovelluksen omistaja ei osaa määritellä palomuurisääntöjen edellyttämää tietoa verkkotiimille”, tai toisinpäin? Kumpikaan ei ole väärässä. Tietoliikenneverkot ja palomuurit eivät pääsääntöisesti ymmärrä sovelluksista mitään. Ne välittävät sokeasti IP-paketteja seuraavalle tuntemalleen laitteelle.
Hyvä yhteistyö sovellus- ja verkkotiimin kesken, vakioitu ja ammattimainen sääntöjen ylläpito sekä dokumentointi palomuurin säännöstön luomisessa on parhaimmillaan estänyt suuremmat katastrofit. Valitettavasti ulkoistus, henkilöstön jatkuva vaihtuminen, osaamisen puute, yritysjärjestelyssä kadotettu tieto, kommunikoinnin puute sekä sovellusten (päivitys) muutokset ovat aiheuttaneet hankalan tilanteen.
Kuinka moni verkkotiimi määrittelee API palomuuri sääntöjä Docker, Kubernets tai AWS ympäristössä?
Sovellukset ovat kehittyneet massiivisista monoliiteista mikropalveluihin, hajautettuihin ja dynaamisiin arkkitehtuureihin. Sovellukset elävät nyt missä tahansa julkisen, yksityisen tai hybridipilven yhdistelmässä. Tämä vaikeuttaa palomuurisäännöstön määrittelyä ja palomuurin soveltuvuutta entisestään. Kun kehitystiimit rakentavat sovelluksia integraatioineen, on palomuurin admin yhä useammin poissa kuvioista.
Onko palomuurilla kyvykkyyttä purkaa eri protokollien salaus, tunnistaa sovellukset ja API-kutsut luotettavasti, yhdistää sovellusten sessiot oikeisiin käyttäjiin tai prosesseihin? – Teoriassa ja vahva ehkä, mutta käytännön ulkoistetussa ja hajautuneessa ympäristössä palomuurisääntöjen ylläpitäjä tuskin koskee sääntöihin, ellei asiakas tee muutospyyntöä. Kuka tällaisen pyynnön osaa tehdä ja validioida, jos liikenne edes kulkee enään palomuurin kautta?
Tämän takia väitän, että palomuurit kuolevat 2030-luvulla.
Hannu Rokka, Senior Advisor
5Feet Networks Oy