Entä jos verkkopalvelin murretaan huomenna? Mitä muita laitteita siltä voi tavoittaa? Vastaus vaikuttaa siihen, rajautuuko häiriö yhteen palveluun vai vaarantaako se muitakin yrityksen osia. Korjauspäivitys suojaa tunnetulta haavoittuvuudelta. Hyvin suunniteltu verkko rajaa lisäksi mahdollisia seurauksia.
Esimerkkinä on kuvitteellinen asiakasportaali: käyttäjät kirjautuvat sisään, tarkastelevat tilauksia ja lataavat asiakirjoja. Sovellus tarvitsee määritellyn tietokantayhteyden. Se ei silti tarvitse pääsyä NAS-laitteen hallintaan, varmuuskopiointipalvelimelle tai virtualisointi-isäntään. Tämä ero on toteutettava teknisillä rajoituksilla.
Murrettu palvelu käyttää käytettävissä olevia reittejä
Haavoittuvuus voi mahdollistaa vieraan koodin suorittamisen verkkosovelluksen oikeuksilla. Jatkossa mahdolliset toimet riippuvat muun muassa verkkosäännöistä, palvelutileistä, tallennetuista tunnuksista ja muista haavoittuvuuksista. Verkkoyhteyden mahdollisuus ei vielä tarkoita onnistunutta pääsyä palveluun. Murrettu verkkopalvelin ei myöskään ota automaattisesti koko lähiverkkoa haltuunsa.
Riski kasvaa, kun tavoitettavat sisäiset palvelut yhdistyvät liian laajoihin oikeuksiin. Hyökkääjän on silloin ylitettävä vähemmän rajoja. Tällaista mahdollista etenemistä muihin järjestelmiin kutsutaan sivuttaisliikkeeksi. Verkon suunnittelussa onkin hyödyllistä olettaa, että jokin sovellus on jo murrettu.
Verkko A: portaali on tasaisessa yritysverkossa
Ensimmäisessä ratkaisussa portaali, tietokanta, tiedostotallennus ja hallintaliittymät ovat samassa verkossa. Verkon reunapalomuuri rajoittaa saapuvia yhteyksiä. Sisäisten järjestelmien välillä on kuitenkin laajoja sallivia sääntöjä tai puutteellinen erottelu. Verkkopalvelin voi siten tavoittaa enemmän järjestelmiä kuin sen tehtävä edellyttää.
Yhteinen ylläpitäjätili pahentaa tilannetta. Samoin tekevät kirjoitusoikeuksin liitetty varmuuskopiohakemisto tai sovellushakemistoon tallennetut laajat tunnukset. Toimivasta varmuuskopiosta on vähän hyötyä, jos murrettu palvelu voi muuttaa myös sen hallintaa tai kaikkia varmuuskopioita.
Verkko B: vyöhykkeet ja säännöt rajaavat yhteyksiä
Toisessa ratkaisussa internetliikenne päätyy ensin määriteltyyn edustapalveluun tai käänteiseen välityspalvelimeen. Se saa ottaa yhteyden tarvittavaan sovellukseen erillisessä verkkopalvelusegmentissä. Sovellukselle sallitaan vain välttämätön yhteys nimettyyn tietokantakohteeseen. Hallinta, varmuuskopiot ja muut sisäiset palvelut ovat eri vyöhykkeillä; tarpeeton pääsy verkkopalvelusegmentistä estetään.
VLAN jakaa verkon loogisesti. Yhteyksien hallinta ratkaisee, muodostuuko jaosta toimiva turvallisuusraja. Liian salliva VLANien välinen reititys yhdistää erotetut verkot jälleen laajasti toisiinsa. Myös saman VLANin sisällä voidaan tarvita lisäsuodatusta yksittäisten työkuormien välille.
OPNsense tai Sophos Firewall ovat mahdollisia alustoja sopiville säännöille, samoin muut tarkoitukseen soveltuvat tuotteet. Olennaisia ovat tarkat lähteet, kohteet, palvelut, vastuut ja todennettu toteutus. Käyttöliittymät ja käytettävissä olevat ominaisuudet eroavat alustoittain. Tuotenimi ei yksin kuvaa testattua turvallisuusarkkitehtuuria.
Käänteinen välityspalvelin ja WAF ovat osa suojausta
Käänteinen välityspalvelin voi keskittää julkiset yhteydet, käsitellä TLS-yhteyksiä ja ohjata pyynnöt valittuihin taustapalveluihin. HAProxy tukee tähän muun muassa HTTP- ja TCP-tiloja. Se ei tarkoita yleistä välitystoimintoa mille tahansa protokollalle. Eteen sijoitettu verkkosovelluspalomuuri eli WAF voi tunnistaa ja torjua tiettyjä haitallisia verkkopyyntöjä.
Nämä osat eivät korvaa turvallisia sovelluksia, oikea-aikaisia päivityksiä tai rajattua pääsyä taustapalveluihin. Virheelliset säännöt tai toinen tavoitettava sisääntuloreitti voivat ohittaa suojaukset. Siksi esimerkissä myös välityspalvelimen takana murretun sovelluksen tulee tavoittaa vain erikseen tarvitsemansa kohteet.
Huomioi myös ulospäin suuntautuva ja sisäinen liikenne
Ratkaisevaa ei ole vain se, kuka saa ottaa yhteyden verkkopalvelimeen. Mihin palvelin itse saa avata yhteyksiä? Voiko se tavoittaa NAS-laitteen hallintaliittymän? Onko sen päästävä mihin tahansa internetkohteeseen? Mitä sisäisiä palveluja muut kontit oikeasti tarvitsevat?
Ulospäin suuntautuvan liikenteen eli egressin suunnitteluun kuuluvat esimerkiksi nimenselvitys, ajan synkronointi, päivitykset ja ulkoiset rajapinnat. Tarvittavat kohteet sallitaan erikseen. Sisäisten järjestelmien välinen, usein itä-länsisuuntaiseksi kutsuttu liikenne tarvitsee myös selkeät säännöt. IPv6:n ja vaihtoehtoisten reittien tulee noudattaa samaa tavoiteltua erottelua.
Yhteyssuunnitelmaan kirjataan lähde, kohde, tarvittava palvelu, käyttötarkoitus ja vastuuhenkilö. Sallitut ja estetyt reitit testataan tämän jälkeen hallitusti. Lokien ja valvonnan tulee paljastaa sekä odottamattomat onnistuneet yhteydet että epäilyttävät estetyt yritykset. Sääntö, jonka vaikutusta ei ole tarkistettu, ei vielä ole luotettava todiste.
Virtuaalikoneet ja kontit tarvitsevat sopivat rajat
Virtuaalikoneella on oma vieraskäyttöjärjestelmä; kontit jakavat yleensä isäntänsä ytimen. Molemmat mallit tarvitsevat asianmukaiset verkko- ja käyttöoikeusasetukset. Proxmox VE tarjoaa palomuurisääntöjä isäntä- ja vierasjärjestelmille. Käytännössä toimivat tasot ja ominaisuudet riippuvat myös palomuuritaustajärjestelmästä ja siitä, mitä on todella otettu käyttöön.
Dockerissa saman bridge-verkon kontit voivat viestiä keskenään. Ulospäin avattavat yhteydet eivät automaattisesti rajoitu julkisiin kohteisiin. Julkaistut portit voivat luoda uusia sisääntuloreittejä. Host-verkkotilassa kontit jakavat isännän verkon nimiavaruuden, joten niillä ei ole erillistä verkkoeristystä.
Lisäoikeudet, tarpeettomasti liitetyt isännän hakemistot ja pääsy Docker-socketiin voivat laajentaa häiriön seurauksia huomattavasti. Erilliset sovellusverkot, vähimmäisoikeudet, sopivat isännän palomuurisäännöt sekä hallitut DNS- ja egress-reitit kuuluvat siksi yhteen. Tässäkin ratkaisee todellisuudessa toimiva kokoonpano.
Hallittava aloitus pienemmille yrityksille
- Kartoita palvelut: dokumentoi julkiset sovellukset, riippuvuudet ja vastuuhenkilöt.
- Määrittele vyöhykkeet: erota julkiset työkuormat, tiedot, hallinta ja varmuuskopiot suojaustarpeen mukaan.
- Perustele yhteydet: salli vain määritellyt lähteet, kohteet ja palvelut; estä muut, kun se on toiminnan kannalta tarkoituksenmukaista.
- Suojaa hallinta: käytä luotettuja pääsyreittejä, sopivia VPN- ja MFA-menetelmiä sekä erillisiä tilejä.
- Huomioi ylläpito: suunnittele päivitykset, keskitetyt lokit, hälytykset ja riippumattomasti suojatut varmuuskopiot sekä testattu palautus.
- Todenna vaikutus: tarkista säännöt säännöllisesti, aseta poikkeuksille määräaika ja testaa uudelleen muutosten jälkeen.
Muutokset vaativat valmistelua, sopivan huoltoikkunan ja palautussuunnitelman. Yleinen esto voi katkaista oikeutetut sovellusyhteydet tai oman hallintayhteyden. Kartoita siksi ensin riippuvuudet, tee muutos hallitusti ja hyväksytä liiketoiminnan toimivuus yhdessä vastuuhenkilöiden kanssa.
Yhden sovelluksen murto ei välttämättä kaada koko verkkoa
PHP2Shell-artikkelit PHP-haavoittuvuuksiin reagoimisesta ja tekoälyn tukemasta kartoituksesta antavat ajankohtaisen lähtökohdan. NAS-laitteiden, Dockerin ja julkisten palvelujen lisätarkistus johtaa pysyvään arkkitehtuurikysymykseen: mitä yhteyksiä ja oikeuksia kukin palvelu todella tarvitsee?
DAXS auttaa kartoituksessa, yhteyssuunnitelmassa, toteutuksessa ja todennettavassa ylläpidossa. Toimiipa sovellus paikallisesti, yksityisessä pilvessä tai julkisella pilvialustalla, suojausrajojen tulee vastata todellista tarvetta. Keskustellaan konkreettisesta ympäristöstäsi.
Lähteet: OPNsense: säännöt ja tilallinen suodatus · Sophos Firewall: vyöhykkeet, säännöt ja lokitus · HAProxy: HTTP- ja TCP-tilat · Docker: bridge-verkot · Docker: host-verkkotila · Docker: daemon, oikeudet ja turvallisuusrajat · Proxmox VE: palomuurin dokumentaatio · NCSC: leviämisen rajaaminen sekä hallinnan ja varmuuskopioiden suojaaminen.
