Odoo 19 segurtasun-arkitektura: suebakia, 2FA, baimenak eta Web RBL ondo konbinatu

Odoo gure bost webguneetan Internet irekitik eskuragarri dago, eta hori ez da salbuespena, ohiko kasua baizik: eskaintza bat, denda bat edo bezeroen saio-hasiera bat darabilenak zerbitzari publiko bat du. Pasahitz ahul bakar batek, ahaztutako konfigurazio-fitxategi batek edo gehiegi eskuzabal emandako baimen batek aski du zerbitzari publiko bat zerbitzari ireki bihurtzeko.

Artikulu honek erakusten du nola babestu Odoo 19 behar bezala — neurri bakar batekin ez, elkar osatzen duten hainbat geruzarekin baizik: suebakia eta reverse proxy, gure kode irekiko modulua Web RBL, bi faktoreko autentifikazioa, pasahitz-politika eta baimenak — eta horietako bakoitzak zer eraso-saiakera geldiarazten duen benetan. Amaieran urratsez urratseko gidaliburu bat dago, norberaren Odoo instalazio guztietan jarraitzeko modukoa.

Sakoneko defentsa: zergatik ez den inoiz neurri bakar bat aski

Segurtasun-neurri bakoitzak zulo bat du. Suebakiak ez du ikusten Odoo-ren saio-hasierako orrian gertatzen dena. Pasahitz sendo batek ez du babesten beste nonbait lapurtu bada. Baimen-egitura batek ez du ezer laguntzen oraindik saioa hasi ere egin ez duen erasotzaile baten aurka. Zulo horiek ixten dituen printzipioa sakoneko defentsa da (defense in depth): hainbat geruza independente, horietako bakoitza bere kabuz saihestu daitekeena — baina denak batera, ez.

Gure kasuan lau geruza dira, bakoitzak zeregin desberdin batekin:

• Suebakia / Reverse proxy — nabarmen maltzurra denari ateak itxten dizkio zerbitzarira iritsi aurretik
• Web RBL — bi aldeak lotzen ditu: Odoo-k bere aplikazio-erregistrotik ikasten du suebakiak ezin duena ikusi, eta berari itzultzen dio
• Odoo bera — bi faktoreko autentifikazioa, pasahitz-politika, baimenak, saio-kudeaketa
• Datu-basea & eragiketak — segurtasun-kopia, kudeaketarako sarbide-babesa, sekretuak edozein erregistrotik kanpo

Hurrengo ataletan geruza bakoitza banan-banan aztertzen da.

1. geruza: suebakia eta reverse proxy

Suebakia eskaera bat ikusten duen lehen instantzia da, eta erasotzaile bat zerbitzariko zerbitzu guztietatik urrun mantendu dezakeen bakarra — webgunetik ez ezik, posta-zerbitzaritik, VPN sarbidetik eta kudeaketa-interfaze propiotik ere. Une horretan zer aktibatzea zentzuzkoa den fabrikatzailearen araberakoa da, baina oinarrizko moldeak berdinak dira OPNsense, pfSense, HAProxy, FortiGate, Sophos edo Check Point-en:

RBL zerrendak: ospea banatzeko bide estandarra

RBL Real-time Blackhole List da, posta-munduko termino bat: helbide bat lerro bakoitzeko, HTTP bidez eskuragarri, aldiro berriro kargatua. Ia suebaki guztiek irakur dezakete halako zerrenda bat eta horretatik arauak sor ditzakete — OPNsense eta pfSense URL Table Alias gisa, HAProxy ACL fitxategi gisa, FortiGate External Block List gisa, Palo Alto External Dynamic List gisa, Cisco, Sophos, Juniper eta MikroTik printzipio beraren izen propioekin.

Hemen sartzen da gure modulu propioa — eta hemen hasten da bigarren geruza.

2. geruza: Web RBL — aplikazioaren eta suebakiaren arteko zubia

Suebakiak paketeak ikusten ditu, ez aplikazio-logika. Ez daki /xmlrpc/2/common eskaera bat saio-hasierako saiakera bat denik, hogei bide desberdin hamalau segundotan eskaner bat direnik, edo helbide batek pasahitz bat asmatu berri duenik. Hori guztia Odoo-k bakarrik daki. Web RBL, gure kode irekiko modulu propioak (AGPL-3), ezagutza hori erabilgarri egiten du — Odoo berarentzat eta, RBL zerrenda gisa banatuta, aurrean dagoen suebakiarentzat ere.

Mehatxu-zerrendak etengabe alderatuak, bakoitza bere mailarekin.

Laburbilduz, aurreko artikuluan zehatz-mehatz deskribatzen dena:

• Bideetako patroi-detekzioa: .env fitxategiak, .git direktorioak, konfigurazio-fitxategiak, WordPress eta PHP zundak, bide-zeharkaldia, AA interfaze berrien bidezko komando-exekuzioa
• Saio-hasierako defentsa, berrabiarazteak gainditzen dituena zenbatzen — Odoo-ren kontagailu propioak ez bezala, hura memorian bizi baita
• Helbide bakoitzaren balorazioa 0tik 100era, arrazoiketa testu argian
• Konfigurazio-akatsak (QNAP, Autodiscover, Synology) antzematen dira eta inoiz ez dira blokeatzen, blokeoak ez baitu akatsa konpontzen, ezkutatu baizik
• Kanpoko mehatxu-zerrendak, hala nola Spamhaus, FireHOL eta Tor irteera-nodoak, etengabe alderatuak
• Inoiz blokeatu behar ez diren helbideentzako zerrenda zuria

Artikulu honetarako bi ezaugarri bereziki garrantzitsuak dira, suebakiarekin eta saio-hasierarekin zuzenean lotuta daudelako.

Zerrenda geldoa fidagarria den zerrenda da

Zerrenda zuria — inoiz blokeatzen ez diren helbideak, adibidez gure kokaleku-konexioak — oso gutxitan aldatzen da. Hori bera da bere balioa, ez bere gabezia: zerrenda lasai bat egunetan zehar ia mugitzen ez bada, aldaketa arraro bakoitza berehala nabaritzen da. Eguneroko eguneraketa automatikoa ez dago asko aldatuko delako, aldaketa arraroa eskuz gehitu behar izan ez dadin baizik — eta hori da, hain zuzen, ahazten den puntua. Joan den hilean gure konfigurazio-akats bat hala nabaritu zen: ez gertaera askorengatik, inork ezagutzen ez zuen batengatik baizik, bezero baten QNAP web-APIa oker blokeatu zen arte. Ordutik QNAP ez da inoiz blokeatzen: jakinarazi baino ez den konfigurazio-akatsen zerrendan dago.

Saio-hasiera suebakiak ikusten ez duen lekua da

Suebakiak helbide bat blokea dezake. Ezin du jakin saio-hasiera bat arrakastatsua izan den, are gutxiago aurretik sarbide-datuak bilatzen ari zen helbide batetik etorri den. Web RBL-k bai: doitu daitekeen atalase batetik gorako balorazio batek saio-hasiera erabat debekatzen du, eta helbide susmagarri batetik egindako saio-hasiera arrakastatsua jakinarazi egiten da — hori da hurrengo geruzarako lotura.

3. geruza: Odoo bera babestu

Bi faktoreko autentifikazioa: berrerabili ezin den bigarren sekretu bat

Pasahitzen arazorik handiena ez da haien kalitatea, berrerabilera baizik. Beste zerbitzu batean lapurtutako pasahitz batek gurean berdin funtzionatzen du, berbera den bitartean. Bi faktoreko autentifikazioak (2FA, TOTP ere deitua) bigarren sekretu bat jartzen dio aurrez aurre: hogeita hamar segundoro aldatzen den sei digituko kode bat, norberaren telefono adimendunak bakarrik ezagutzen duen sekretu batetik kalkulatua. Lapurtutako pasahitz batek bakarrik ez du jada aski.

Odoo 19 Community-k hori integratuta dakar — instalagarria den Two-Factor Authentication (TOTP) modulu gisa, posta elektronikoko babes-aukerarekin osatua. Erabiltzaile bakoitzak berak konfiguratzen du, QR kodearen bidez, edozein Authenticator aplikazio arruntekin:

Konfigurazioa: QR kodea eskaneatu, sei digituko kodea behin berretsi, eta kitto.

Hori bakarrik, ordea, norberak konfiguratzen dutenei baino ez die laguntzen — eta esperientziak erakusten du, derrigortu gabe, gutxiengoa izaten dela. Odoo-k, beraz, derrigortze-politika bat du: langileentzat bakarrik (barne-erabiltzaileak) edo guztientzat, portal-erabiltzaileak barne. Bigarren sekretu konfiguraturik gabe, inork ez du saio-hasierako orria gaindituko, gutxienez posta-kodearen bidez berretsi gabe.

Pasahitz-politika: gutxieneko luzera ez da berez ulertzen den gauza

Gehigarri-modulurik gabe, Odoo Community-k ez du pasahitzentzako gutxieneko luzerarik exijitzen — erabiltzaile batek hiru karaktereko pasahitz bat jar dezake, inork galarazten ez badio. Password Policy modulu propioak zulo hori bera ixten du: zerbitzarian derrigortutako gutxieneko luzera bat, nabigatzailean proposatua soilik izan beharrean. Gehiago nahi duenak — derrigorrezko iraungitze-denbora, berrerabileraren aurkako historia — OCA edo hirugarrenen modulu bat behar du horretarako; Community bertsioan nahita mantentzen da arina.

Baimenak: behar duenak soilik jasotzen du sarbidea

Odoo-k berez hiru maila bereizten ditu: portal-erabiltzaileak (norberaren bezero- edo hornitzaile-portala soilik), barne-erabiltzaileak (backend-a, aplikazio bakoitzeko eskubideekin) eta administratzaileak (sarbide mugagabea ezarpen teknikoak barne). Akatsik ohikoena ez da pasahitz ahulegia, gehiegi eskuzabal emandako administratzaile-rola baizik: fakturak sortu besterik behar ez duenak ez du sistema-ezarpenetarako sarbiderik behar.

Bi printzipiok zama gehiena eramaten dute:

Biak ikuspegi berean egiaztatu daitezke, bi faktoreko autentifikazioa konfiguratzen den berean:

Ikuspegi bat, lau palanka: pasahitza, bigarren faktorea, API gakoak, saioa hasita duten gailuak.

Saioak eta gailuak: nor dago saioa hasita orain

Ikuspegi berak erakusten du, halaber, kontu bat zein gailutatik hasi den saioa une honetan — eta bakarra edo guztiak batera ixten uzten du. Ordenagailu eramangarri bat galdu ondoren edo pasahitz bat konprometituta dagoelako susmoa dagoenean, hori da urrats eraginkor azkarrena: saioa berehala amaitzen da, pasahitza dagoeneko aldatu den ala ez kontuan hartu gabe.

4. geruza: datu-basea eta eragiketak

Laugarren geruza gutxien ikusten dena da eta, aldi berean, barkaezinena, hemengo akats batek lehenago eraikitako guztia hutsean utz baitezake.

• Segurtasun-kopia erregularrak eta egiaztatuak, zerbitzaritik bereizita gordeak. Inoiz leheneratu gabeko segurtasun-kopia bat susmo bat da, ez segurtasun-kopia bat.
• Sekretuek ez dute inongo erregistro-fitxategian egon behar. Pasahitzak, API gakoak, lizentzia-datuak — luzapen propioak idazten dituenak maisu-pasahitza bera bezala tratatu beharko lituzke: inon ez erregistratu, ezta “arazketarako soilik” ere.
• Moduluak eguneratuta mantendu, hirugarrenen moduluak batez ere. Doako gehigarri-moduluak (OCA eta besteak) berez Odoo bertsio berrien atzetik ibiltzen dira; instalatu aurretik merezi du begiratzea zer mendekotasun datozen automatikoki.

Saio-hasierako bidea osotasunean

Lau geruzek ez dute elkarren segidan gela bereizietan lan egiten, eskaera berean baizik, maila bakoitzean. Saio-hasiera baten adibidean argien ikusten da:

Bost toki, eskaera maltzur batek amaitu dezakeenak benetako helburura iritsi aurretik — eta bakar bat, erabiltzaile baimendu batek guztiak gainditzen dituena.

Eraso-eszenatokiak eta haien aurkako defentsa

Hurrengo ikuspegiak benetako eraso-patroiak benetan geldiarazten dituzten geruzei esleitzen dizkie. Horietako askok ez dute teoria, gure bost webguneetako benetako trafikoaren hamazazpi egunetan egindako behaketa propioak baizik.

Urratsez urrats: norberaren Odoo instalazioa babestu

Hurrengo ordena gu geu jarraituko genukeena da — eraginik handienetik doikuntza finenera.

1. Bi faktoreko autentifikazioa derrigortu

1. Oraindik instalatuta ez badago: Apps ireki, “Two-Factor Authentication” bilatu eta instalatu (webgune bat baino gehiago badago, gomendagarria da gainera “Two-Factor Authentication by Mail” babes-aukera gisa).
2. Ezarpenak → Ezarpen orokorrak → Baimenak ireki.
3. “Bi faktoreko autentifikazioa derrigortu” aktibatu.
4. Politika hautatu: “Langileak soilik” barne-erabiltzaileentzat, “Erabiltzaile guztiak” portal-erabiltzaileak (sarbidea duten bezeroak) ere sartu nahi badira.
5. Gorde. Hurrengo saio-hasiera saiakeratik aurrera, Odoo-k bigarren sekretu konfiguraturik ez duen erabiltzaile bakoitzari gutxienez posta-kodea eskatuko dio, Authenticator aplikazioa konfiguratu arte.

2. Pasahitzentzako gutxieneko luzera ezarri

1. Apps ireki, “Password Policy” bilatu eta instalatu.
2. Ezarpenak → Ezarpen orokorrak → Baimenak ireki.
3. “Pasahitzaren gutxieneko luzera” ezarri — hamabi karaktere hasierako balio zentzuzkoa da.
4. Gorde. Araua aurrerantzean pasahitz berri edo aldatu guztiei aplikatzen zaie, ez atzera begira dauden pasahitzei.

3. Baimenak berrikusi

1. Ezarpenak → Erabiltzaileak & Enpresak → Erabiltzaileak ireki.
2. Erabiltzaile bakoitza banan-banan ireki eta aplikazio bakoitzeko sarbide-eskubideen fitxa egiaztatu: Pertsona honek benetan “Kudeatzailea” edo “Administratzailea” behar du, ala “Erabiltzailea” aski da?
3. Bereziki egiaztatu: Nork du “Ezarpenak” bertara sarbidea? Talde oso txikia izan beharko litzateke.
4. Kanpoko lotura bakoitzerako (kontabilitatea, script propioak, denbora-erregistroa), dagokion erabiltzaile teknikoaren “Kontuaren segurtasuna” fitxan API gako propioa sortu, erabiltzailearen pasahitza pasatu beharrean.

4. Web RBL instalatu eta behatu, martxan jarri aurretik

1. Modulua hemendik github.com/Alex0176/odoo-web-rbl addon-bidean jarri eta instalatu.
2. Egun batzuetan behatu: Web RBL → Analisia menuak erakusten du zein patroi jotzen duten benetan.
3. Horren ondoren bakarrik aktibatu web_rbl.sperren_aktiv (Ezarpenak → Teknikoa → Sistema-parametroak) — hemendik aurrera antzemandako zundak benetan baztertzen dira.
4. Blokeo-zerrenda moduluan adierazitako token bidez babestutako helbidean suebakian RBL zerrenda gisa txertatu (OPNsense/pfSense-n URL Table Alias gisa, HAProxy-n ACL fitxategi gisa).

5. Suebakia bera babestu

1. Suebakiaren kudeaketa-interfazea barne-saretik bakarrik eskuragarri egin, inoiz ez webgunearen helbide publiko berdinaren bidez.
2. Suebaki-softwarearen segurtasun-eguneraketa automatikoak aktibatu, fabrikatzaileak eskaintzen badu.
3. TLS konfigurazioa egiaztatu: protokolo-bertsio eguneratuak soilik, zifratze-metodo zaharkituak desaktibatu.
4. Erabilgarri badago: ospe-zerrenda ezagun bat (adibidez Spamhaus DROP) zuzenean suebakian txertatu — Web RBL-rekiko independente, suebakiak horrela Odoo-ra inoiz iristen ez diren zerbitzuetarako trafikoa ere ikusten baitu.

6. Datu-basearen kudeaketa itxi

1. Egiaztatu /web/database/manager kanpotik eskuragarri dagoen — baldin bada, Odoo konfigurazioan list_db = False ezarri edo bidea suebaki-mailan blokeatu.
2. Datu-basearen kudeaketaren maisu-pasahitza luze eta ausazko ezarri eta beste inork irakur dezakeen inongo tokitan ez apuntatu.

7. Segurtasun-kopia egiaztatu, ez soilik konfiguratu

1. Segurtasun-kopia automatiko eta erregularra konfiguratu, Odoo zerbitzaritik bereizita gordea.
2. Gutxienez behin benetan leheneratu eta egiaztatu leheneratzeak funtzionatzen duen — egiaztatu gabeko segurtasun-kopia bat susmo bat da.

Urrats hauetako batek ere ez du beste bat ordezkatzen. Horietako bakarra gauzatzen duenak ate bat indartu du eta beste guztiak ireki utzi ditu — zazpiak gauzatzen dituenak, aldiz, geruza bakar batek huts egiten duenean ere eusten duen defentsa du.

Arkitektura honek ordezkatzen ez duena

Deskribatutako neurrietako bakar batek ere ez du arretarik alferrikako bihurtzen. .env zundak baztertzen dituen modulu batek ez du nahi gabe argitaratutako .env fitxategi bat kaltegabe bihurtzen. Bi faktoreko autentifikazioak ez du babesten bere kodea telefonoz dei egiten dion bati irakurtzen dion erabiltzaile bat. Eta suebaki batek ez du ordezkatzen nork zer baimen behar duen benetan erabakitzea. Segurtasun-arkitekturak akats bakar bat berehala gertakari bihurtzen ez den baldintzak sortzen ditu — ez dio inori arretaren zama kentzen.

Maiz egiten diren galderak

Pasahitz sendo batek aski du Odoo 19 babesteko?

Ez. Pasahitz bat beste nonbait lapur daiteke, bere kalitatea kontuan hartu gabe, eta orduan pasahitz bera onartzen duen zerbitzu guztietan funtzionatzen du. Bi faktoreko autentifikazioaren, aurrean dagoen suebaki baten eta baimen-egitura zentzuzko baten konbinazioak bakarrik ematen du pasahitza lapurtu ondoren ere eusten duen babesa.

Nola aktibatu bi faktoreko autentifikazioa Odoo 19-n?

“Two-Factor Authentication (TOTP)” modulua Apps kudeaketatik instalatu, gero Ezarpenak → Ezarpen orokorrak → Baimenak atalean derrigortzea aktibatu eta “Langileak soilik” eta “Erabiltzaile guztiak” artean hautatu. Erabiltzaile bakoitzak ondoren bere bigarren faktorea QR kodearen bidez konfiguratzen du.

Zer da RBL zerrenda, eta zergatik behar du Odoo-k bat?

RBL (Real-time Blackhole List) HTTP bidez eskuragarri dagoen helbide-zerrenda bat da, ia suebaki guztiek irakur dezaketena. Odoo-k berak ez dakar halako zerrendarik — gure Web RBL moduluak zulo hori ixten du, eraso-trafikoa bere aplikazio-erregistrotik antzemanez eta aurrean dagoen suebakiari RBL zerrenda gisa itzuliz.

Odoo 19 Community gehigarri-modulurik gabe nahikoa babestuta dago?

Ez erabat. Password Policy modulurik gabe ez dago pasahitzentzako gutxieneko luzerarik, Two-Factor Authentication gabe ez dago bigarren faktorerik, eta Web RBL bezalako modulurik gabe Odoo-k ez ditu zundaketa-saiakerak ezta berrabiarazte batean zehar errepikatutako saio-hasiera saiakerak ere antzematen. Lau horiek doan gehi daitezke.

Erabilgarritasuna

Web RBL publikoki eskuragarri dago AGPL-3 lizentziapean eta gure sisteman produkzioan dabil bost webgunetan:

github.com/Alex0176/odoo-web-rbl

Funtzioen deskribapen osoa patroi, balorazio eta mehatxu-zerrenda guztiekin aurreko artikuluan dago: Web RBL – blokeo-zerrenda norberaren webguneetako eraso-trafikoarentzat.

Galderak, oharrak eta errore-txostenak pozik jasotzen ditugu — nahiago GitHub-en issue gisa.