Odoo 19 -tietoturva-arkkitehtuuri: palomuurin, 2FA:n, käyttöoikeuksien ja Web RBL:n oikea yhdistäminen

Odoo on viidellä verkkosivustollamme tavoitettavissa avoimesta internetistä, eikä tämä ole poikkeus vaan normaalitapaus: jokaisella, joka tarjoaa tarjouksen, verkkokaupan tai asiakaskirjautumisen, on julkinen palvelin. Yksi haavoittuva salasana, yksi unohtunut määritystiedosto tai yksi liian avokätinen käyttöoikeus riittää, jotta julkisesta palvelimesta tulee avoin.

Tämä artikkeli näyttää, miten Odoo 19 suojataan oikein — ei yksittäisellä toimenpiteellä, vaan useilla toisiaan täydentävillä kerroksilla: palomuuri ja käänteinen välityspalvelin, avoimen lähdekoodin moduulimme Web RBL, kaksivaiheinen todennus, salasanakäytäntö ja käyttöoikeudet — sekä se, mitä hyökkäysyrityksiä kukin niistä todella torjuu. Lopussa on vaiheittainen ohje, jonka avulla jokaisen oman Odoo-asennuksen voi saattaa samalle tasolle.

Syvyyssuuntainen puolustus: miksi yksi toimenpide ei koskaan riitä

Jokaisessa yksittäisessä tietoturvatoimenpiteessä on aukko. Palomuuri ei näe, mitä Odoon kirjautumislomakkeessa tapahtuu. Vahva salasana ei suojaa, jos se on jo varastettu jostain muualta. Käyttöoikeusrakenteesta ei ole apua hyökkääjää vastaan, joka ei ole vielä lainkaan kirjautunut. Periaate, joka sulkee nämä aukot, on nimeltään syvyyssuuntainen puolustus (defense in depth): useita toisistaan riippumattomia kerroksia, joista jokainen yksinään olisi kierrettävissä — mutta kaikki yhdessä eivät.

Meillä kerroksia on neljä, ja jokaisella on eri tehtävä:

• Palomuuri / käänteinen välityspalvelin — pitää ilmeisen haitallisen liikenteen loitolla jo ennen kuin se edes saavuttaa palvelinta
• Web RBL — yhdistää molemmat puolet: Odoo oppii omasta sovelluslokistaan sen, mitä palomuuri ei voi lainkaan nähdä, ja syöttää tiedon takaisin palomuurille
• Odoo itse — kaksivaiheinen todennus, salasanakäytäntö, käyttöoikeudet, istunnonhallinta
• Tietokanta & käyttö — varmuuskopiointi, hallinnan pääsynsuojaus, salaisuudet pois kaikista lokeista

Seuraavissa osioissa käydään läpi jokainen kerros erikseen.

Kerros 1: palomuuri ja käänteinen välityspalvelin

Palomuuri on ensimmäinen taho, joka näkee pyynnön, ja ainoa, joka voi pitää hyökkääjän poissa jokaisesta palvelimen palvelusta — ei pelkästään verkkosivustolta, vaan myös sähköpostipalvelimelta, VPN-yhteydeltä ja omalta hallintakäyttöliittymältä. Se, mitä tässä kohdassa kannattaa ottaa käyttöön, riippuu valmistajasta, mutta perusratkaisut ovat samat OPNsensessä, pfSensessä, HAProxyssä, FortiGatessa, Sophosissa tai Check Pointissa:

RBL-luettelot: vakiotapa, jolla maine toimitetaan

RBL tulee sanoista Real-time Blackhole List, joka on sähköpostimaailmasta peräisin oleva käsite: yksi osoite riviä kohden, haettavissa HTTP:llä, ladataan säännöllisesti uudelleen. Käytännössä jokainen palomuuri osaa lukea tällaisen luettelon ja rakentaa siitä sääntöjä — OPNsense ja pfSense URL Table Aliasina, HAProxy ACL-tiedostona, FortiGate External Block Listinä, Palo Alto External Dynamic Listinä, Cisco, Sophos, Juniper ja MikroTik omilla nimillään samalle periaatteelle.

Juuri tähän oma moduulimme tarttuu — ja juuri tässä toinen kerros alkaa.

Kerros 2: Web RBL — silta sovelluksen ja palomuurin välillä

Palomuuri näkee paketteja, ei sovelluslogiikkaa. Se ei tiedä, että pyyntö osoitteeseen /xmlrpc/2/common on kirjautumisyritys, että kaksikymmentä eri polkua neljässätoista sekunnissa on skanneri tai että jokin osoite on juuri onnistuneesti arvannut salasanan. Kaiken tämän tietää vain Odoo itse. Web RBL, oma avoimen lähdekoodin moduulimme (AGPL-3), tekee tästä tiedosta hyödynnettävää — Odoolle itselleen ja RBL-luettelona toimitettuna myös sen edessä olevalle palomuurille.

Uhkaluettelot jatkuvasti vertailtuina, kullakin oma tasonsa.

Lyhyt yhteenveto siitä, mikä on kuvattu yksityiskohtaisesti edellisessä artikkelissa:

• Kuviontunnistus poluissa: .env-tiedostot, .git-hakemistot, määritystiedostot, WordPress- ja PHP-luotaimet, polkujen läpikäynti, komentojen suoritus uusien tekoälyrajapintojen kautta
• Kirjautumisen torjunta, joka laskee uudelleenkäynnistysten yli — toisin kuin Odoon oma, keskusmuistissa elävä laskuri
• Jokaisen osoitteen arvosana 0–100, perusteluineen selkokielellä
• Virhemääritykset (QNAP, Autodiscover, Synology) tunnistetaan ja niitä ei koskaan estetä, koska esto ei korjaa vikaa vaan ainoastaan piilottaa sen
• Vieraat uhkaluettelot, kuten Spamhaus, FireHOL ja Tor-poistumissolmut, jatkuvasti vertailtuina
• Sallittujen luettelo osoitteille, joita ei koskaan saa estää

Tässä artikkelissa kaksi ominaisuutta on erityisen tärkeää, koska ne liittyvät suoraan palomuuriin ja kirjautumiseen.

Hidasliikkeinen luettelo on luettelo, johon voi luottaa

Sallittujen luettelo — osoitteet, joita ei koskaan estetä, esimerkiksi omat toimipisteyhteydet — muuttuu yleensä harvoin. Juuri se on sen arvo, ei puute: kun rauhallinen luettelo ei liiku päivien aikana juuri lainkaan, jokainen harvinainen muutos huomataan heti. Päivittäinen automaattinen päivitys ei ole olemassa siksi, että paljon muuttuisi, vaan jotta harvinaista muutosta ei tarvitse kirjata käsin — ja juuri siinä kohdassa sen unohtaa. Yksi omista virhemäärityksistämme viime kuussa huomattiin juuri näin: ei monien tapahtumien, vaan sen yhden perusteella, josta kukaan ei tiennyt, ennen kuin asiakkaan QNAP-verkkorajapinta estettiin virheellisesti. Siitä lähtien QNAP on virhemääritysten luettelossa, joita ei koskaan estetä vaan ainoastaan ilmoitetaan.

Kirjautuminen on paikka, jota palomuuri ei näe

Palomuuri voi estää osoitteen. Se ei voi tietää, onko kirjautuminen onnistunut, saati sitä, tuliko se osoitteesta, joka oli hetkeä aiemmin vielä etsimässä tunnuksia. Web RBL tietää: säädettävästä kynnysarvosta alkaen arvosana kieltää kirjautumisen kokonaan, ja epäilyttävästä osoitteesta tuleva onnistunut kirjautuminen ilmoitetaan — tämä on yhdyssiteenä seuraavaan kerrokseen.

Kerros 3: Odoon suojaaminen itse

Kaksivaiheinen todennus: toinen salaisuus, jota ei voi käyttää uudelleen

Salasanojen suurin ongelma ei ole niiden laatu, vaan niiden uudelleenkäyttö. Toisessa palvelussa varastettu salasana toimii meillä aivan yhtä hyvin, kunhan se on sama. Kaksivaiheinen todennus (2FA, kutsutaan myös TOTP:ksi) asettaa sen vastapainoksi toisen salaisuuden: kuusinumeroisen koodin, joka vaihtuu kolmenkymmenen sekunnin välein ja lasketaan salaisuudesta, jonka tuntee vain oma älypuhelin. Pelkkä varastettu salasana ei siten enää riitä.

Odoo 19 Community sisältää tämän valmiina — asennettavana moduulina Two-Factor Authentication (TOTP), jota täydentää sähköpostin varavaihtoehto. Jokainen käyttäjä ottaa sen käyttöön itse QR-koodilla millä tahansa yleisellä todennussovelluksella:

Käyttöönotto: skannaa QR-koodi, vahvista kuusinumeroinen koodi kerran, valmis.

Tämä auttaa kuitenkin vain niitä, jotka ottavat sen itse käyttöön — ja kokemus osoittaa, että ilman pakkoa heitä on vähemmistö. Siksi Odoossa on pakottamiskäytäntö: joko vain työntekijöille (sisäiset käyttäjät) tai kaikille, portaalikäyttäjät mukaan lukien. Ilman käyttöön otettua toista salaisuutta kukaan ei enää pääse kirjautumislomakkeen ohi vahvistamatta itseään vähintään sähköpostikoodilla.

Salasanakäytäntö: vähimmäispituus ei ole itsestäänselvyys

Ilman lisämoduulia Odoo Community ei edellytä salasanoille mitään vähimmäispituutta — käyttäjä voi antaa kolmen merkin salasanan, jos kukaan ei estä häntä. Oma Password Policy -moduulimme sulkee juuri tämän aukon: vähimmäispituus, joka pakotetaan palvelimella eikä vain ehdoteta selaimessa. Se, joka haluaa enemmän — pakotetun voimassaoloajan, historian uudelleenkäyttöä vastaan — tarvitsee siihen OCA-moduulin tai kolmannen osapuolen moduulin; Community-versio on tarkoituksella pidetty kevyenä.

Käyttöoikeudet: pääsy vain sille, joka sitä tarvitsee

Odoo erottaa oletuksena kolme tasoa: portaalikäyttäjät (vain oma asiakas- tai toimittajaportaali), sisäiset käyttäjät (taustajärjestelmä, oikeudet sovelluskohtaisesti) ja ylläpitäjät (rajoittamaton pääsy teknisine asetuksineen). Yleisin virhe ei ole liian heikko salasana, vaan liian avokätisesti myönnetty ylläpitäjän rooli: se, jonka tarvitsee vain luoda laskuja, ei tarvitse pääsyä järjestelmäasetuksiin.

Kaksi periaatetta kantaa suurimman osan taakasta:

Molemmat voi tarkistaa samassa näkymässä, jossa myös kaksivaiheinen todennus otetaan käyttöön:

Yksi yleiskatsaus, neljä vipua: salasana, toinen tekijä, API-avaimet, kirjautuneet laitteet.

Istunnot ja laitteet: kuka on parhaillaan kirjautuneena

Sama näkymä näyttää myös, miltä laitteilta tili on parhaillaan kirjautuneena — ja sallii yksittäisen tai kaikkien laitteiden uloskirjaamisen kerralla. Kadonneen kannettavan tai salasanan vaarantumisen epäilyn jälkeen se on nopein tehokas toimenpide: istunto päättyy heti riippumatta siitä, onko salasana jo vaihdettu.

Kerros 4: tietokanta ja käyttö

Neljäs kerros on vähiten näkyvä ja samalla anteeksiantamattomin, koska virhe täällä voi mitätöidä kaiken aiemmin rakennetun.

• Säännölliset, tarkistetut varmuuskopiot, tallennettuina erilleen itse palvelimesta. Varmuuskopio, jota ei ole koskaan palautettu, on oletus eikä varmuuskopio.
• Salaisuudet eivät kuulu mihinkään lokitiedostoon. Salasanat, API-avaimet, lisenssitiedot — se, joka kirjoittaa omia laajennuksia, kohdelkoon niitä kuten itse pääsalasanaa: älä kirjaa niitä minnekään, ei edes ”vain virheenjäljitystä varten”.
• Pidä moduulit ajan tasalla, myös ja erityisesti kolmannen osapuolen moduulit. Vapaat lisämoduulit (OCA ja muut) laahaavat luonnollisesti uusien Odoo-versioiden perässä; ennen jokaista asennusta kannattaa katsoa, mitä riippuvuuksia tulee automaattisesti mukana.

Kirjautumisreitti kokonaisuutena

Neljä kerrosta eivät toimi peräkkäin erillisissä huoneissa, vaan saman pyynnön kimpussa vaihe vaiheelta. Kirjautuminen on tästä selkein esimerkki:

Viisi kohtaa, joissa haitallinen pyyntö voi päättyä ennen kuin se saavuttaa varsinaisen kohteen — ja vain yksi, jossa oikeutettu käyttäjä läpäisee ne kaikki.

Hyökkäysskenaariot ja niiden torjunta

Seuraava yleiskatsaus yhdistää todelliset hyökkäysmallit kerroksiin, jotka ne todella pysäyttävät. Useat niistä eivät ole teoriaa, vaan omia havaintojamme seitsemäntoista päivän todellisesta liikenteestä viidellä verkkosivustollamme.

Vaihe vaiheelta: oman Odoo-asennuksen suojaaminen

Seuraava järjestys on se, jossa itse etenisimme — suurimmasta vaikutuksesta hienoimpaan säätöön.

1. Pakota kaksivaiheinen todennus

1. Jos sitä ei ole vielä asennettu: avaa Sovellukset, hae ”Two-Factor Authentication” ja asenna (useiden verkkosivustojen kanssa suositellaan lisäksi ”Two-Factor Authentication by Mail” varavaihtoehdoksi).
2. Avaa Asetukset → Yleiset asetukset → Käyttöoikeudet.
3. Ota käyttöön ”Pakota kaksivaiheinen todennus”.
4. Valitse käytäntö: ”Vain työntekijät” sisäisille käyttäjille, ”Kaikki käyttäjät”, jos mukaan halutaan ottaa myös portaalikäyttäjät (asiakkaat, joilla on pääsy).
5. Tallenna. Seuraavasta kirjautumisyrityksestä alkaen Odoo vaatii jokaiselta käyttäjältä, jolla ei ole käyttöön otettua toista salaisuutta, vähintään sähköpostikoodin, kunnes hän on ottanut todennussovelluksen käyttöön.

2. Määritä salasanoille vähimmäispituus

1. Avaa Sovellukset, hae ”Password Policy” ja asenna.
2. Avaa Asetukset → Yleiset asetukset → Käyttöoikeudet.
3. Aseta ”Salasanan vähimmäispituus” — kaksitoista merkkiä on järkevä lähtöarvo.
4. Tallenna. Sääntö on voimassa heti jokaiselle uudelle tai muutetulle salasanalle, ei takautuvasti olemassa oleville salasanoille.

3. Käy käyttöoikeudet läpi

1. Avaa Asetukset → Käyttäjät & yritykset → Käyttäjät.
2. Avaa jokainen käyttäjä erikseen ja tarkista välilehti, jossa on sovelluskohtaiset käyttöoikeudet: Tarvitseeko tämä henkilö todella ”Manager”- tai ”Ylläpitäjä”-oikeuden vai riittääkö ”Käyttäjä”?
3. Tarkista erityisesti: Kenellä on pääsy itse ”Asetuksiin”? Sen pitäisi olla hyvin pieni ryhmä.
4. Luo jokaista ulkoista liittymää (kirjanpito, omat skriptit, ajanseuranta) varten kyseisen teknisen käyttäjän ”Tilin tietoturva”-välilehdellä oma API-avain, sen sijaan että käyttäjän salasana annettaisiin eteenpäin.

4. Asenna Web RBL ja tarkkaile ennen kuin otat sen terävästi käyttöön

1. Moduuli osoitteesta github.com/Alex0176/odoo-web-rbl sijoitetaan addon-polkuun ja asennetaan.
2. Tarkkaile muutaman päivän ajan: valikko Web RBL → Analyysi näyttää, mitkä kuviot todella laukeavat.
3. Vasta sen jälkeen ota käyttöön web_rbl.sperren_aktiv (Asetukset → Tekniset → Järjestelmäparametrit) — tästä lähtien tunnistetut luotaimet todella hylätään.
4. Liitä estoluettelo palomuuriin RBL-luettelona moduulissa ilmoitetusta, tokenilla suojatusta osoitteesta (OPNsensessä/pfSensessä URL Table Aliasina, HAProxyssä ACL-tiedostona).

5. Suojaa itse palomuuri

1. Tee palomuurin hallintakäyttöliittymä tavoitettavaksi vain sisäisestä verkosta, älä koskaan samasta julkisesta osoitteesta kuin verkkosivusto.
2. Ota palomuuriohjelmiston automaattiset tietoturvapäivitykset käyttöön, jos valmistaja tarjoaa niitä.
3. Tarkista TLS-määritys: vain ajantasaiset protokollaversiot, poista vanhentuneet salausmenetelmät käytöstä.
4. Jos mahdollista: liitä tunnettu mainelista (esimerkiksi Spamhaus DROP) suoraan palomuuriin — riippumatta Web RBL:stä, sillä palomuuri näkee silloin myös liikenteen palveluihin, joita Odoo ei koskaan tavoita.

6. Sulje tietokannan hallinta

1. Tarkista, onko /web/database/manager tavoitettavissa ulkopuolelta — jos on, aseta Odoon määrityksessä list_db = False tai estä polku palomuuritasolla.
2. Aseta tietokannan hallinnan pääsalasana pitkäksi ja satunnaiseksi äläkä kirjaa sitä mihinkään paikkaan, jonka kuka tahansa muu voi lukea.

7. Tarkista varmuuskopio, älä vain ota sitä käyttöön

1. Ota käyttöön automaattinen, säännöllinen varmuuskopiointi, tallennettuna erilleen Odoo-palvelimesta.
2. Palauta varmuuskopio vähintään kerran oikeasti ja tarkista, toimiiko palautus — tarkistamaton varmuuskopio on oletus.

Yksikään näistä vaiheista ei korvaa toista. Se, joka toteuttaa vain yhden, on vahvistanut yhden oven ja jättänyt kaikki muut auki — se, joka toteuttaa kaikki seitsemän, saa puolustuksen, joka kestää silloinkin, kun yksittäinen kerros pettää.

Mitä tämä arkkitehtuuri ei korvaa

Mikään kuvatuista toimenpiteistä ei tee huolellisuutta tarpeettomaksi. Moduuli, joka hylkää .env-luotaimet, ei tee vahingossa julkaistusta .env-tiedostosta vaaratonta. Kaksivaiheinen todennus ei suojaa käyttäjältä, joka lukee koodinsa puhelimessa soittajalle. Eikä palomuuri korvaa päätöstä siitä, kuka todella tarvitsee mitäkin käyttöoikeutta. Tietoturva-arkkitehtuuri luo olosuhteet, joissa yksittäinen virhe ei heti muutu tietoturvapoikkeamaksi — se ei vapauta ketään huolellisuudesta.

Usein kysytyt kysymykset

Riittääkö vahva salasana Odoo 19:n suojaamiseen?

Ei. Salasana voidaan varastaa muualta täysin riippumatta sen laadusta, ja sitten se toimii jokaisessa palvelussa, joka hyväksyy saman salasanan. Vasta yhdistelmä kaksivaiheisen todennuksen, sen edessä olevan palomuurin ja järkevän käyttöoikeusrakenteen kanssa muodostaa suojauksen, joka kestää myös varastetun salasanan jälkeen.

Miten otan kaksivaiheisen todennuksen käyttöön Odoo 19:ssä?

Asenna moduuli ”Two-Factor Authentication (TOTP)” Sovellusten hallinnan kautta, ota sitten kohdassa Asetukset → Yleiset asetukset → Käyttöoikeudet käyttöön pakottaminen ja valitse ”Vain työntekijät” tai ”Kaikki käyttäjät”. Tämän jälkeen jokainen käyttäjä ottaa oman toisen tekijänsä käyttöön QR-koodilla.

Mikä on RBL-luettelo, ja miksi Odoo tarvitsee sellaisen?

RBL (Real-time Blackhole List) on HTTP:llä haettava osoiteluettelo, jonka käytännössä jokainen palomuuri osaa lukea. Odoo itse ei toimita tällaista luetteloa — moduulimme Web RBL sulkee tämän aukon tunnistamalla hyökkäysliikenteen omasta sovelluslokistaan ja palauttamalla sen RBL-luettelona edeltävälle palomuurille.

Onko Odoo 19 Community suojattu riittävästi ilman lisämoduuleja?

Ei täysin. Ilman Password Policy -moduulia salasanoille ei ole vähimmäispituutta, ilman Two-Factor Authentication -moduulia ei ole toista tekijää, ja ilman Web RBL:n kaltaista moduulia Odoo ei tunnista tiedusteluyrityksiä eikä toistuvia kirjautumisyrityksiä uudelleenkäynnistyksen yli. Kaikki neljä voi lisätä maksutta jälkikäteen.

Saatavuus

Web RBL on julkisesti saatavilla AGPL-3-lisenssillä ja toimii meillä tuotannossa viidellä verkkosivustolla:

github.com/Alex0176/odoo-web-rbl

Täydellinen toimintokuvaus kaikkine kuvioineen, arvosanoineen ja uhkaluetteloineen on edellisessä artikkelissa: Web RBL – estoluettelo hyökkäysliikenteelle omilla verkkosivustoilla.

Otamme mielellämme vastaan kysymyksiä, huomautuksia ja virheraportteja — mieluiten GitHubin issueina.