Odoo 19 turvaarhitektuur: tulemüür, 2FA, õigused ja Web RBL õigesti kombineerida

Odoo on meie viiel veebilehel kättesaadav avatud internetist ja see ei ole erand, vaid tavaline olukord: kes pakub teenust, poodi või kliendi sisselogimist, sellel on avalik server. Üks ainus haavatav parool, üks unustatud konfiguratsioonifail või liiga helde õigus on piisav, et avalikust serverist saaks avatud server.

See artikkel näitab, kuidas Odoo 19 õigesti turvata — mitte ühe üksiku meetmega, vaid mitme üksteist täiendava kihiga: tulemüür ja pöördvaheserver (reverse proxy), meie avatud lähtekoodiga moodul Web RBL, kaheastmeline autentimine, paroolipoliitika ja õigused — ning milliseid ründekatseid kumbki neist tegelikult tõrjub. Lõpus on samm-sammuline juhend, mille abil saab iga oma Odoo paigalduse samale tasemele viia.

Kaitse sügavuti: miks ühest meetmest kunagi ei piisa

Igal üksikul turvameetmel on lünk. Tulemüür ei näe, mis Odoo sisselogimisvormis toimub. Tugev parool ei kaitse, kui see on mujal juba varastatud. Õiguste struktuur ei aita midagi ründaja vastu, kes pole veel üldse sisse loginud. Põhimõtet, mis need lüngad sulgeb, nimetatakse kaitseks sügavuti (defense in depth): mitu sõltumatut kihti, millest iga üks eraldi võetuna oleks mööda pääsetav — aga kõik koos mitte.

Meil on neli kihti, igaühel erinev ülesanne:

• Tulemüür / pöördvaheserver — hoiab ilmselgelt pahatahtliku eemal, enne kui see serverini jõuabki
• Web RBL — ühendab mõlemad pooled: Odoo õpib oma rakenduselogist, mida tulemüür üldse näha ei saa, ja annab selle tulemüürile tagasi
• Odoo ise — kaheastmeline autentimine, paroolipoliitika, õigused, sessioonihaldus
• Andmebaas & töökorraldus — varundus, halduse ligipääsukaitse, saladused väljaspool igat logi

Järgmised lõigud käivad iga kihi eraldi läbi.

1. kiht: tulemüür ja pöördvaheserver

Tulemüür on esimene instants, mis päringut näeb, ja ainus, mis suudab ründaja eemal hoida igast serveri teenusest — mitte ainult veebilehest, vaid ka e-posti serverist, VPN-i ligipääsust ja haldusliidesest endast. Mida siin mõistlikult aktiveerida, sõltub tootjast, kuid ehitusviisid on OPNsense'i, pfSense'i, HAProxy, FortiGate'i, Sophose või Check Pointi puhul samad:

RBL-nimekirjad: standardne viis, kuidas mainet edastatakse

RBL tähendab Real-time Blackhole List, mõiste e-posti maailmast: üks aadress rea kohta, kättesaadav HTTP kaudu, korrapäraselt uuesti laaditav. Praktiliselt iga tulemüür oskab sellist nimekirja sisse lugeda ja sellest reegleid koostada — OPNsense ja pfSense kui URL Table Alias, HAProxy kui ACL-fail, FortiGate kui External Block List, Palo Alto kui External Dynamic List, Cisco, Sophos, Juniper ja MikroTik oma nimedega sama põhimõtte jaoks.

Just siin alustab meie enda moodul — ja just siin algab teine kiht.

2. kiht: Web RBL — sild rakenduse ja tulemüüri vahel

Tulemüür näeb pakette, mitte rakenduseloogikat. Ta ei tea, et päring aadressile /xmlrpc/2/common on sisselogimiskatse, et kakskümmend erinevat teed neljateistkümne sekundi jooksul on skanner või et mõni aadress on parajasti edukalt parooli ära arvanud. Seda kõike teab ainult Odoo ise. Web RBL, meie enda avatud lähtekoodiga moodul (AGPL-3), teeb selle teadmise kasutatavaks — Odoo enda jaoks ja, RBL-nimekirjana väljastatuna, ka selle ees oleva tulemüüri jaoks.

Ohunimekirju võrreldakse pidevalt, igaühel oma tase.

Lühidalt kokkuvõttes see, mida eelmises artiklis üksikasjalikult kirjeldati:

• Mustrituvastus teedes: .env-failid, .git-kataloogid, konfiguratsioonifailid, WordPressi ja PHP sondid, tee läbimine (path traversal), käskude täitmine uute tehisintellekti liideste kaudu
• Sisselogimiskaitse, mis loeb üle taaskäivituste — erinevalt Odoo enda mälus elavast loendurist
• Iga aadressi hindamine skaalal 0 kuni 100, põhjendusega selges keeles
• Valekonfiguratsioonid (QNAP, Autodiscover, Synology) tuvastatakse ja mitte kunagi ei blokeerita, sest blokeering ei kõrvalda defekti, vaid ainult peidab selle
• Võõrad ohunimekirjad nagu Spamhaus, FireHOL ja Tor-i väljumissõlmed, pidevalt võrreldud
• Lubatud nimekiri aadressidele, mida ei tohi kunagi blokeerida

Selle artikli jaoks on kaks omadust eriti olulised, sest need on otseselt seotud tulemüüri ja sisselogimisega.

Loid nimekiri on nimekiri, mida saab usaldada

Lubatud nimekiri — aadressid, mida ei blokeerita kunagi, näiteks oma asukohaühendused — muutub reeglina harva. Just see on selle väärtus, mitte puudus: kui rahulik nimekiri päevade jooksul peaaegu ei liigu, torkab iga harv muutus kohe silma. Igapäevane automaatne ajakohastamine ei ole olemas seetõttu, et palju muutuks, vaid selleks, et harva ette tulevat muutust ei peaks käsitsi järele lisama — ja just see on punkt, kus seda unustatakse. Üks meie enda valekonfiguratsioone eelmisel kuul tuli välja täpselt nii: mitte paljude sündmuste kaudu, vaid ühe kaudu, mida keegi ei tundnud, kuni kliendi QNAP-i veebi-API ekslikult blokeeriti. Sestsaadik on QNAP valekonfiguratsioonide nimekirjas, mida ei blokeerita kunagi, vaid millest ainult teatatakse.

Sisselogimine on koht, mida tulemüür ei näe

Tulemüür saab aadressi blokeerida. Ta ei saa teada, kas sisselogimine õnnestus, ja veel vähem seda, kas see tuli aadressilt, mis oli hetk varem veel pääsuandmeid otsinud. Web RBL saab: seadistatavast lävest alates hinne keelab sisselogimise täielikult ja kahtlasest aadressist õnnestunud sisselogimisest teatatakse — see on lüli järgmise kihi juurde.

3. kiht: Odoo enda turvamine

Kaheastmeline autentimine: teine saladus, mida ei saa taaskasutada

Paroolide suurim probleem ei ole nende kvaliteet, vaid taaskasutamine. Parool, mis varastati mõnes teises teenuses, töötab meil täpselt samamoodi, kui see on sama. Kaheastmeline autentimine (2FA, nimetatakse ka TOTP-ks) asetab sellele vastu teise saladuse: kuuekohalise koodi, mis muutub iga kolmekümne sekundi tagant ja arvutatakse saladusest, mida teab ainult oma nutitelefon. Varastatud parool üksi ei piisa enam.

Odoo 19 Community pakub seda sisseehitatult — paigaldatava moodulina Two-Factor Authentication (TOTP), täiendatuna e-posti varuvõimalusega. Iga kasutaja seadistab selle ise, QR-koodi abil, iga levinud autentimisrakendusega:

Seadistamine: skanni QR-kood, kinnita kuuekohaline kood üks kord, valmis.

See aga aitab ainult neid, kes selle ise seadistavad — ja kogemus näitab, et ilma sunnita jääb see vähemuseks. Odoos on seetõttu jõustamispoliitika: kas ainult töötajatele (sisemised kasutajad) või kõigile, sealhulgas portaalikasutajatele. Ilma seadistatud teise saladuseta ei pääse keegi sisselogimisvormist mööda, kinnitamata seda vähemalt e-posti koodiga.

Paroolipoliitika: miinimumpikkus ei ole iseenesestmõistetav

Ilma lisamoodulita ei tugine Odoo Community paroolide miinimumpikkusele — kasutaja võib määrata kolmetähelise parooli, kui keegi teda selles ei takista. Oma Password Policy moodul sulgeb just selle lünga: miinimumpikkus, mida jõustatakse serveri poolel, mitte ainult ei soovitata brauseris. Kes tahab rohkemat — kohustuslikku aegumisaega, ajalugu taaskasutamise vastu — vajab selleks OCA või kolmanda osapoole moodulit; Community versioonis on see teadlikult lihtsana hoitud.

Õigused: ligipääs ainult sellel, kes seda vajab

Odoo eristab algusest peale kolme taset: portaalikasutajad (ainult oma kliendi- või tarnijaportaal), sisemised kasutajad (backend, õigustega rakenduse kaupa) ja administraatorid (piiramatu ligipääs koos tehniliste seadetega). Kõige sagedasem viga ei ole liiga nõrk parool, vaid liiga helde administraatorirolli andmine: kes peab ainult arveid koostama, ei vaja ligipääsu süsteemiseadetele.

Kaks põhimõtet kannavad suurema osa koormusest:

Mõlemat saab kontrollida samas vaates, kus seadistatakse ka kaheastmeline autentimine:

Üks ülevaade, neli hooba: parool, teine faktor, API-võtmed, sisseloginud seadmed.

Sessioonid ja seadmed: kes on parajasti sisse loginud

Sama vaade näitab ka, millistest seadmetest on konto parajasti sisse logitud — ja võimaldab ühe või kõik korraga välja logida. Pärast kaotatud sülearvutit või kahtlust, et parool on kompromiteeritud, on see kiireim toimiv samm: sessioon lõpeb kohe, sõltumata sellest, kas parool on juba muudetud.

4. kiht: andmebaas ja töökorraldus

Neljas kiht on kõige vähem nähtav ja samas andestamatuim, sest viga siin võib hävitada kõik varem ülesehitatu.

• Korrapärased, kontrollitud varukoopiad, mida hoitakse serverist eraldi. Varukoopia, mida pole kunagi tagasi laaditud, on oletus, mitte varukoopia.
• Saladused ei kuulu ühtegi logifaili. Paroolid, API-võtmed, litsentsiandmed — kes kirjutab oma laiendusi, peaks neid kohtlema nagu peaparooli ennast: mitte kuskile kirja panema, isegi mitte „ainult silumiseks“.
• Hoidke moodulid ajakohased, ka ja just kolmanda osapoole moodulid. Vabad lisamoodulid (OCA ja teised) jäävad uutest Odoo versioonidest loomulikult maha; enne iga paigaldust tasub vaadata, millised sõltuvused automaatselt kaasa tulevad.

Sisselogimistee tervikuna

Neli kihti ei tööta järjest eraldi ruumides, vaid ühe ja sama päringu juures, aste astmelt. Kõige selgemini on seda näha sisselogimise näitel:

Viis kohta, kus pahatahtlik päring võib lõppeda, enne kui see tegeliku sihini jõuab — ja ainult üks, kus õigustatud kasutaja need kõik läbib.

Ründestsenaariumid ja nende vastumeetmed

Järgmine ülevaade seob tegelikud ründemustrid kihtidega, mis neid tegelikult peatavad. Mitu neist ei ole teooria, vaid meie enda tähelepanekud seitsmeteistkümne päeva tegelikust liiklusest meie viiel veebilehel.

Samm-sammult: oma Odoo paigalduse turvamine

Järgnev järjekord on see, milles me ise tegutseksime — suurimast mõjust peenima seadistuseni.

1. Kaheastmelise autentimise jõustamine

1. Kui pole veel paigaldatud: avage Apps, otsige „Two-Factor Authentication“ ja paigaldage (mitme veebilehe korral soovitatakse lisaks „Two-Factor Authentication by Mail“ varuvõimalusena).
2. Avage Seaded → Üldseaded → Õigused.
3. Aktiveerige „Jõusta kaheastmeline autentimine“.
4. Valige poliitika: „Ainult töötajad“ sisemiste kasutajate jaoks, „Kõik kasutajad“, kui kaasata tuleb ka portaalikasutajad (ligipääsuga kliendid).
5. Salvestage. Järgmisest sisselogimiskatsest alates nõuab Odoo igalt kasutajalt, kellel pole teist saladust seadistatud, vähemalt e-posti koodi, kuni ta on autentimisrakenduse seadistanud.

2. Paroolide miinimumpikkuse määramine

1. Avage Apps, otsige „Password Policy“ ja paigaldage.
2. Avage Seaded → Üldseaded → Õigused.
3. Määrake „Parooli miinimumpikkus“ — kaksteist märki on mõistlik lähteväärtus.
4. Salvestage. Reegel kehtib kohe iga uue või muudetud parooli määramise korral, mitte tagasiulatuvalt olemasolevatele paroolidele.

3. Õiguste läbivaatamine

1. Avage Seaded → Kasutajad & ettevõtted → Kasutajad.
2. Avage iga kasutaja eraldi ja kontrollige vahekaarti rakenduste kaupa määratud juurdepääsuõigustega: kas see inimene vajab tõesti „Haldurit“ või „Administraatorit“ või piisab „Kasutajast“?
3. Kontrollige eriti: kellel on ligipääs „Seadetele“ endile? See peaks olema väga väike rühm.
4. Iga välise ühenduse (raamatupidamine, oma skriptid, ajaarvestus) jaoks looge vastava tehnilise kasutaja vahekaardil „Konto turvalisus“ oma API-võti, selle asemel et kasutaja parooli edasi anda.

4. Paigaldage Web RBL ja jälgige enne töölepanemist

1. Pange moodul aadressilt github.com/Alex0176/odoo-web-rbl lisamoodulite teele ja paigaldage.
2. Jälgige mõned päevad: menüü Web RBL → Analüüs näitab, millised mustrid tegelikult rakenduvad.
3. Alles pärast seda lülitage sisse web_rbl.sperren_aktiv (Seaded → Tehniline → Süsteemiparameetrid) — sellest hetkest lükatakse tuvastatud sondid tegelikult tagasi.
4. Lisage blokeerimisnimekiri tulemüüri RBL-nimekirjana moodulis näidatud, tokeniga kaitstud aadressi kaudu (OPNsense'i/pfSense'i puhul URL Table Alias, HAProxy puhul ACL-fail).

5. Tulemüüri enda turvamine

1. Tehke tulemüüri haldusliides kättesaadavaks ainult sisevõrgust, mitte kunagi samalt avalikult aadressilt nagu veebileht.
2. Aktiveerige tulemüüritarkvara automaatsed turvavärskendused, kui tootja seda pakub.
3. Kontrollige TLS-konfiguratsiooni: ainult ajakohased protokolliversioonid, aegunud krüptimismeetodid lülitage välja.
4. Kui võimalik: lisage tuntud mainenimekiri (näiteks Spamhaus DROP) otse tulemüürile — sõltumata Web RBL-ist, sest nii näeb tulemüür ka liiklust teenustele, mis Odoo-ni kunagi ei jõua.

6. Andmebaasi halduse sulgemine

1. Kontrollige, kas /web/database/manager on väljastpoolt kättesaadav — kui jah, seadke Odoo konfiguratsioonis list_db = False või blokeerige tee tulemüüri tasemel.
2. Määrake andmebaasi halduse peaparool pikaks ja juhuslikuks ning ärge pange seda kirja ühtegi kohta, mida keegi teine lugeda saab.

7. Kontrollige varukoopiat, mitte ainult ei seadista seda

1. Seadistage automaatne, korrapärane varundus, mida hoitakse Odoo serverist eraldi.
2. Laadige vähemalt kord tegelikult tagasi ja kontrollige, kas taastamine töötab — kontrollimata varukoopia on oletus.

Ükski neist sammudest ei asenda teist. Kes rakendab ainult ühe, on tugevdanud ühe ukse ja jätnud kõik teised lahti — kes rakendab kõik seitse, on saanud kaitse, mis peab vastu ka siis, kui üksik kiht ebaõnnestub.

Mida see arhitektuur ei asenda

Ükski kirjeldatud meetmetest ei muuda hoolsust üleliigseks. Moodul, mis .env-sonde tagasi lükkab, ei muuda kogemata avaldatud .env-faili ohutuks. Kaheastmeline autentimine ei kaitse kasutaja eest, kes loeb oma koodi telefonis helistajale ette. Ja tulemüür ei asenda otsust selle üle, kes tegelikult millist õigust vajab. Turvaarhitektuur loob tingimused, mille korral üksik viga ei muutu kohe intsidendiks — see ei võta kelleltki hoolsust ära.

Korduma kippuvad küsimused

Kas tugev parool on Odoo 19 turvamiseks piisav?

Ei. Parooli võib mujal varastada, täiesti sõltumata selle kvaliteedist, ja siis töötab see igas teenuses, mis sama parooli aktsepteerib. Alles kombinatsioon kaheastmelise autentimise, eesoleva tulemüüri ja mõistliku õiguste struktuuriga annab kaitse, mis peab vastu ka pärast varastatud parooli.

Kuidas aktiveerida kaheastmeline autentimine Odoo 19-s?

Paigaldage moodul „Two-Factor Authentication (TOTP)“ rakenduste halduse kaudu, seejärel aktiveerige jõustamine kohas Seaded → Üldseaded → Õigused ja valige „Ainult töötajad“ ja „Kõik kasutajad“ vahel. Iga kasutaja seadistab seejärel oma teise faktori QR-koodi abil.

Mis on RBL-nimekiri ja miks Odoo seda vajab?

RBL (Real-time Blackhole List) on HTTP kaudu kättesaadav aadressinimekiri, mida praktiliselt iga tulemüür oskab sisse lugeda. Odoo ise sellist nimekirja kaasa ei anna — meie moodul Web RBL sulgeb selle lünga, tuvastades ründeliikluse oma rakenduselogist ja andes selle RBL-nimekirjana tagasi ees olevale tulemüürile.

Kas Odoo 19 Community on ilma lisamoodulita piisavalt turvatud?

Mitte täielikult. Ilma mooduli Password Policy puudub paroolide miinimumpikkus, ilma Two-Factor Authentication-ita puudub teine faktor ja ilma sellise mooduli nagu Web RBL-ita ei tuvasta Odoo ei sondeerimiskatseid ega korduvaid sisselogimiskatseid üle taaskäivituse. Kõik neli saab tasuta järele paigaldada.

Saadavus

Web RBL on AGPL-3 all avalikult kättesaadav ja töötab meil toodangus viiel veebilehel:

github.com/Alex0176/odoo-web-rbl

Täielik funktsioonide kirjeldus kõigi mustrite, hindamise ja ohunimekirjadega on eelmises artiklis: Web RBL – blokeerimisnimekiri ründeliikluse vastu oma veebilehtedel.

Küsimusi, märkusi ja veateateid võtame hea meelega vastu — kõige meelsamini Issue'na GitHubis.