Odoo 19-ի անվտանգության ճարտարապետություն. firewall-ի, 2FA-ի, իրավասությունների և Web RBL-ի ճիշտ համադրում

Odoo-ն մեր հինգ կայքերում հասանելի է բաց ինտերնետից, և դա բացառություն չէ, այլ նորմալ դեպք. ով առաջարկ, առցանց խանութ կամ հաճախորդների մուտք է գործարկում, ունի հանրային սերվեր։ Մեկ խոցելի գաղտնաբառը, մեկ մոռացված կարգավորման ֆայլը կամ չափից ավելի առատաձեռն իրավասությունը բավական է, որպեսզի հանրային սերվերը դառնա բաց։

Այս հոդվածը ցույց է տալիս, թե ինչպես ճիշտ պաշտպանել Odoo 19-ը — ոչ թե մեկ միջոցառմամբ, այլ մի քանի շերտերով, որոնք փոխլրացնում են միմյանց՝ firewall և reverse proxy, մեր բաց կոդով մոդուլը Web RBL, երկգործոն նույնականացում, գաղտնաբառերի քաղաքականություն և իրավասություններ — և թե հարձակման որ փորձերն է իրականում կանգնեցնում դրանցից յուրաքանչյուրը։ Վերջում քայլ առ քայլ ուղեցույց է, որի օգնությամբ կարելի է կարգավորել ցանկացած սեփական Odoo տեղադրում։

Խորացված պաշտպանություն. ինչու մեկ միջոցառումը երբեք բավարար չէ

Անվտանգության յուրաքանչյուր առանձին միջոցառում ունի բացթողում։ Firewall-ը չի տեսնում, թե ինչ է կատարվում Odoo-ի մուտքի ձևում։ Ուժեղ գաղտնաբառը չի պաշտպանում, եթե այն արդեն գողացվել է մեկ այլ տեղում։ Իրավասությունների կառուցվածքը ոչինչ չի օգնում այն հարձակվողի դեմ, որը դեռ ընդհանրապես չի մտել համակարգ։ Այս բացթողումները փակող սկզբունքը կոչվում է խորացված պաշտպանություն (defense in depth)՝ մի քանի անկախ շերտեր, որոնցից յուրաքանչյուրը առանձին վերցրած կարելի է շրջանցել — բայց բոլորը միասին՝ ոչ։

Մեզ մոտ չորս շերտ կա, յուրաքանչյուրը՝ տարբեր խնդրով.

• Firewall / reverse proxy — նկատելիորեն վնասակարը հեռու է պահում՝ նախքան այն կհասնի սերվերին
• Web RBL — կապում է երկու կողմերը. Odoo-ն սեփական հավելվածի մատյանից սովորում է այն, ինչ firewall-ը ընդհանրապես չի կարող տեսնել, և այն հետ է փոխանցում նրան
• Odoo-ն ինքը — երկգործոն նույնականացում, գաղտնաբառերի քաղաքականություն, իրավասություններ, սեսիաների կառավարում
• Տվյալների բազա & շահագործում — պահուստավորում, կառավարման հասանելիության պաշտպանություն, գաղտնիքներ՝ ցանկացած մատյանից դուրս

Հաջորդ բաժիններում յուրաքանչյուր շերտ քննարկվում է առանձին։

Շերտ 1. Firewall և reverse proxy

Firewall-ը առաջին օղակն է, որը տեսնում է հարցումը, և միակը, որը կարող է հարձակվողին հեռու պահել սերվերի ցանկացած ծառայությունից — ոչ միայն կայքից, այլև փոստային սերվերից, VPN մուտքից և սեփական կառավարման միջերեսից։ Թե ինչն է այս կետում նպատակահարմար ակտիվացնել, կախված է արտադրողից, բայց կառուցվածքային տարրերը OPNsense-ի, pfSense-ի, HAProxy-ի, FortiGate-ի, Sophos-ի կամ Check Point-ի դեպքում նույնն են.

RBL ցուցակներ. ստանդարտ ճանապարհ, որով տրամադրվում է հեղինակությունը

RBL-ը նշանակում է Real-time Blackhole List՝ փոստի աշխարհից եկած եզրույթ. մեկ հասցե մեկ տողում, հասանելի HTTP-ով, պարբերաբար նորից բեռնվող։ Գործնականում ցանկացած firewall կարող է կարդալ նման ցուցակ և դրանից կանոններ կազմել — OPNsense-ը և pfSense-ը՝ որպես URL Table Alias, HAProxy-ն՝ որպես ACL ֆայլ, FortiGate-ը՝ որպես External Block List, Palo Alto-ն՝ որպես External Dynamic List, Cisco-ն, Sophos-ը, Juniper-ը և MikroTik-ը՝ նույն սկզբունքի համար սեփական անուններով։

Հենց այստեղ է կիրառվում մեր սեփական մոդուլը — և հենց այստեղ է սկսվում երկրորդ շերտը։

Շերտ 2. Web RBL — կամուրջ հավելվածի և firewall-ի միջև

Firewall-ը տեսնում է փաթեթներ, ոչ թե հավելվածի տրամաբանություն։ Այն չգիտի, որ /xmlrpc/2/common-ին դիմումը մուտքի փորձ է, որ տարբեր քսան ուղի տասնչորս վայրկյանում սկաներ է, կամ որ ինչ-որ հասցե հենց նոր հաջողությամբ գուշակել է գաղտնաբառ։ Այս ամենը գիտի միայն Odoo-ն ինքը։ Web RBL, մեր սեփական բաց կոդով մոդուլը (AGPL-3), այս գիտելիքը դարձնում է օգտագործելի — Odoo-ի համար և, որպես RBL ցուցակ տրամադրվելով, նաև նրա առջևի firewall-ի համար։

Սպառնալիքների ցուցակները շարունակաբար համադրվում են, յուրաքանչյուրը՝ իր մակարդակով։

Համառոտ այն մասին, ինչ մանրամասն նկարագրված է նախորդ հոդվածում.

• Ձևանմուշների ճանաչում ուղիներում՝ .env ֆայլեր, .git դիրեկտորիաներ, կարգավորման ֆայլեր, WordPress և PHP զոնդեր, path traversal, հրամանների կատարում նոր AI միջերեսներով
• Մուտքի պաշտպանություն, որը հաշվում է վերագործարկումների միջով՝ ի տարբերություն Odoo-ի սեփական, օպերատիվ հիշողության մեջ գործող հաշվիչի
• Յուրաքանչյուր հասցեի գնահատական 0-ից 100՝ պարզ տեքստով հիմնավորմամբ
• Սխալ կարգավորումները (QNAP, Autodiscover, Synology) ճանաչվում են և երբեք չեն արգելափակվում, քանի որ արգելափակումը թերությունը չի շտկում, այլ միայն թաքցնում է
• Օտար սպառնալիքների ցուցակներ, ինչպես Spamhaus-ը, FireHOL-ը և Tor-ի ելքային հանգույցները, շարունակաբար համադրվող
• Թույլատրելի ցուցակ այն հասցեների համար, որոնք երբեք չպետք է արգելափակվեն

Այս հոդվածի համար երկու հատկություն հատկապես կարևոր է, քանի որ դրանք անմիջականորեն կապված են firewall-ի և մուտքի հետ։

Ծույլ ցուցակը այն ցուցակն է, որին կարելի է վստահել

Թույլատրելի ցուցակը — հասցեներ, որոնք երբեք չեն արգելափակվում, օրինակ՝ սեփական տարածքային միացումները — փոխվում է, որպես կանոն, հազվադեպ։ Հենց դա է նրա արժեքը, ոչ թե թերությունը. երբ հանգիստ ցուցակը օրերով գրեթե չի շարժվում, ցանկացած հազվադեպ փոփոխություն անմիջապես աչքի է ընկնում։ Ամենօրյա ավտոմատ թարմացումը գոյություն ունի ոչ թե այն պատճառով, որ շատ բան կփոխվի, այլ որպեսզի հազվադեպ փոփոխությունը չպետք լինի ձեռքով մուտքագրել — և հենց դա է այն կետը, որտեղ մարդը մոռանում է։ Անցյալ ամսվա մեր սեփական սխալ կարգավորումներից մեկը հենց այդպես է նկատվել. ոչ թե բազմաթիվ իրադարձություններով, այլ այն մեկով, որը ոչ ոք չգիտեր, մինչև հաճախորդի QNAP վեբ API-ն սխալմամբ արգելափակվեց։ Այդ ժամանակից QNAP-ը գտնվում է սխալ կարգավորումների ցուցակում, որոնք երբեք չեն արգելափակվում, այլ միայն հաղորդվում են։

Մուտքը այն տեղն է, որը firewall-ը չի տեսնում

Firewall-ը կարող է արգելափակել հասցե։ Այն չի կարող իմանալ, արդյոք մուտքը հաջողվել է, առավել ևս՝ արդյոք այն եկել է մի հասցեից, որը քիչ առաջ դեռ մուտքի տվյալներ էր փնտրում։ Web RBL-ը կարող է. կարգավորելի շեմից սկսած գնահատականը լիովին արգելում է մուտքը, իսկ կասկածելի հասցեից հաջող մուտքը հայտնվում է — սա կապող օղակն է հաջորդ շերտի հետ։

Շերտ 3. Odoo-ի սեփական պաշտպանությունը

Երկգործոն նույնականացում. երկրորդ գաղտնիք, որը հնարավոր չէ կրկին օգտագործել

Գաղտնաբառերի ամենամեծ խնդիրը նրանց որակը չէ, այլ կրկնակի օգտագործումը։ Մեկ այլ ծառայությունում գողացված գաղտնաբառը մեզ մոտ նույն կերպ է աշխատում, քանի դեռ այն նույնն է։ Երկգործոն նույնականացումը (2FA, կոչվում է նաև TOTP) դրան հակադրում է երկրորդ գաղտնիք՝ վեցանիշ կոդ, որը փոխվում է յուրաքանչյուր երեսուն վայրկյանը մեկ և հաշվարկվում է մի գաղտնիքից, որը գիտի միայն սեփական սմարթֆոնը։ Գողացված գաղտնաբառը միայնակ այլևս բավական չէ։

Odoo 19 Community-ն դա տրամադրում է ներկառուցված՝ որպես տեղադրվող Two-Factor Authentication (TOTP) մոդուլ՝ լրացված էլ. փոստով պահուստային տարբերակով։ Յուրաքանչյուր օգտվող այն կարգավորում է ինքը՝ QR կոդով, ցանկացած տարածված Authenticator հավելվածով.

Կարգավորումը. սկանավորել QR կոդը, մեկ անգամ հաստատել վեցանիշ կոդը, պատրաստ է։

Սակայն սա օգնում է միայն նրանց, ովքեր դա կարգավորում են ինքնուրույն — իսկ փորձը ցույց է տալիս, որ առանց հարկադրանքի դրանք փոքրամասնություն են մնում։ Այդ պատճառով Odoo-ն ունի պարտադիրության քաղաքականություն՝ կա՛մ միայն աշխատակիցների (ներքին օգտվողների) համար, կա՛մ բոլորի համար, ներառյալ պորտալի օգտվողները։ Առանց կարգավորված երկրորդ գաղտնիքի ոչ ոք այլևս չի անցնում մուտքի ձևից՝ առանց այն գոնե էլ. փոստի կոդով հաստատելու։

Գաղտնաբառերի քաղաքականություն. նվազագույն երկարությունը ինքնին հասկանալի չէ

Առանց լրացուցիչ մոդուլի Odoo Community-ն գաղտնաբառերի համար նվազագույն երկարության վրա չի հիմնվում — օգտվողը կարող է սահմանել երեք նիշանոց գաղտնաբառ, եթե ոչ ոք նրան չի խանգարում։ Սեփական Password Policy մոդուլը փակում է հենց այս բացը՝ նվազագույն երկարություն, որը պարտադրվում է սերվերի կողմից, այլ ոչ միայն առաջարկվում է դիտարկչում։ Ով ավելին է ուզում — պարտադիր ժամկետ, կրկնակի օգտագործման դեմ պատմություն — դրա համար պետք է OCA կամ երրորդ կողմի մոդուլ. Community տարբերակում դա միտումնավոր թեթև է պահվել։

Իրավասություններ. հասանելիություն ստանում է միայն նա, ով դրա կարիքն ունի

Odoo-ն լռելյայն տարանջատում է երեք մակարդակ՝ պորտալի օգտվողներ (միայն սեփական հաճախորդի կամ մատակարարի պորտալը), ներքին օգտվողներ (backend՝ յուրաքանչյուր հավելվածի իրավունքներով) և ադմինիստրատորներ (անսահմանափակ հասանելիություն՝ տեխնիկական կարգավորումներով հանդերձ)։ Ամենահաճախ սխալը չափազանց թույլ գաղտնաբառը չէ, այլ չափից ավելի առատաձեռն տրված ադմինիստրատորի դերը. ով պետք է միայն հաշիվներ ստեղծի, համակարգային կարգավորումներին հասանելիության կարիք չունի։

Երկու սկզբունք կրում է հիմնական բեռը.

Երկուսն էլ կարելի է ստուգել նույն տեսքում, որտեղ կարգավորվում է նաև երկգործոն նույնականացումը.

Մեկ ակնարկ, չորս լծակ՝ գաղտնաբառ, երկրորդ գործոն, API բանալիներ, մուտք գործած սարքեր։

Սեսիաներ և սարքեր. ով է հիմա մուտք գործած

Նույն տեսքը ցույց է տալիս նաև, թե որ սարքերից է հաշիվը հիմա մուտք գործած — և թույլ է տալիս դուրս գալ մեկից կամ բոլորից միանգամից։ Կորած նոութբուքից հետո կամ գաղտնաբառի փոխզիջման կասկածի դեպքում սա ամենաարագ արդյունավետ քայլն է. սեսիան ավարտվում է անմիջապես՝ անկախ այն բանից, արդյոք գաղտնաբառն արդեն փոխվել է։

Շերտ 4. Տվյալների բազա և շահագործում

Չորրորդ շերտը ամենաքիչ տեսանելին է և միաժամանակ ամենաներելին, քանի որ այստեղ սխալը կարող է ոչնչացնել նախկինում կառուցված ամեն ինչ։

• Կանոնավոր, ստուգված պահուստային պատճեններ, սերվերից առանձին պահվող։ Պահուստային պատճենը, որը երբեք չի վերականգնվել, ենթադրություն է, ոչ թե պահուստային պատճեն։
• Գաղտնիքները ոչ մի մատյանի ֆայլում տեղ չունեն։ Գաղտնաբառեր, API բանալիներ, լիցենզիայի տվյալներ — ով սեփական ընդլայնումներ է գրում, պետք է դրանց վերաբերվի այնպես, ինչպես հենց հիմնական գաղտնաբառին. ոչ մի տեղ չգրանցել, նույնիսկ «միայն վրիպազերծման համար»։
• Մոդուլները թարմ պահել, այդ թվում և հատկապես երրորդ կողմի մոդուլները։ Անվճար լրացուցիչ մոդուլները (OCA և այլք) բնականաբար հետ են մնում Odoo-ի նոր տարբերակներից. յուրաքանչյուր տեղադրումից առաջ արժե նայել, թե որ կախվածություններն են ավտոմատ ավելանում։

Մուտքի ամբողջ ճանապարհը

Չորս շերտերը գործում են ոչ թե հաջորդաբար՝ առանձին սենյակներում, այլ նույն հարցման վրա՝ քայլ առ քայլ։ Դա ամենահստակ երևում է մուտքի օրինակով.

Հինգ կետ, որտեղ վնասակար հարցումը կարող է ավարտվել՝ նախքան իր իրական թիրախին հասնելը — և միայն մեկ, որտեղ իրավաչափ օգտվողն անցնում է դրանք բոլորը։

Հարձակման սցենարներ և դրանց դեմ պաշտպանությունը

Հետևյալ ակնարկը իրական հարձակման ձևանմուշները դասավորում է այն շերտերին, որոնք իրականում դրանք կանգնեցնում են։ Դրանցից մի քանիսը տեսություն չեն, այլ մեր սեփական դիտարկումներն են՝ մեր հինգ կայքերի վրա տասնյոթ օրվա իրական երթևեկությունից։

Քայլ առ քայլ. սեփական Odoo տեղադրման պաշտպանություն

Հետևյալ հաջորդականությունն այն է, որով մենք ինքներս կգործեինք՝ ամենամեծ ազդեցությունից մինչև ամենանուրբ կարգավորումը։

1. Երկգործոն նույնականացումը դարձնել պարտադիր

1. Եթե դեռ տեղադրված չէ. բացել Apps-ը, որոնել «Two-Factor Authentication» և տեղադրել (մի քանի կայքի դեպքում լրացուցիչ խորհուրդ է տրվում «Two-Factor Authentication by Mail»՝ որպես պահուստային տարբերակ)։
2. Բացել Կարգավորումներ → Ընդհանուր կարգավորումներ → Իրավասություններ։
3. Ակտիվացնել «Պարտադրել երկգործոն նույնականացումը»։
4. Ընտրել քաղաքականությունը. «Միայն աշխատակիցներ»՝ ներքին օգտվողների համար, «Բոլոր օգտվողները», եթե պետք է ներառվեն նաև պորտալի օգտվողները (հաճախորդներ՝ մուտքով)։
5. Պահպանել։ Մուտքի հաջորդ փորձից սկսած Odoo-ն պահանջում է յուրաքանչյուր օգտվողից, ով չունի կարգավորված երկրորդ գաղտնիք, առնվազն էլ. փոստի կոդը՝ մինչև նա կարգավորի Authenticator հավելվածը։

2. Սահմանել գաղտնաբառերի նվազագույն երկարություն

1. Բացել Apps-ը, որոնել «Password Policy» և տեղադրել։
2. Բացել Կարգավորումներ → Ընդհանուր կարգավորումներ → Իրավասություններ։
3. Սահմանել «Գաղտնաբառի նվազագույն երկարություն» — տասներկու նիշը խելամիտ սկզբնական արժեք է։
4. Պահպանել։ Կանոնն անմիջապես գործում է յուրաքանչյուր նոր կամ փոփոխված գաղտնաբառի համար, հետադարձ ուժով՝ գոյություն ունեցող գաղտնաբառերի վրա չի տարածվում։

3. Վերանայել իրավասությունները

1. Բացել Կարգավորումներ → Օգտվողներ & ընկերություններ → Օգտվողներ։
2. Բացել յուրաքանչյուր օգտվողին առանձին և ստուգել հավելվածների գծով հասանելիության իրավունքների ներդիրը. արդյոք այս անձին իսկապես պետք է «Մենեջեր» կամ «Ադմինիստրատոր», թե՞ «Օգտվող»-ը բավական է։
3. Հատկապես ստուգել. ո՞վ ունի հասանելիություն հենց «Կարգավորումներ»-ին։ Դա պետք է շատ փոքր խումբ լինի։
4. Յուրաքանչյուր արտաքին միացման համար (հաշվապահություն, սեփական սկրիպտներ, ժամանակի հաշվառում) համապատասխան տեխնիկական օգտվողի «Հաշվի անվտանգություն» ներդիրում ստեղծել առանձին API բանալի՝ օգտվողի գաղտնաբառը փոխանցելու փոխարեն։

4. Տեղադրել Web RBL-ը և դիտարկել՝ նախքան սուր ռեժիմի անցնելը

1. Մոդուլը՝ github.com/Alex0176/odoo-web-rbl դնել addon ուղու մեջ և տեղադրել։
2. Դիտարկել մի քանի օր. Web RBL → Վերլուծություն մենյուն ցույց է տալիս, թե որ ձևանմուշներն են իրականում գործում։
3. Միայն դրանից հետո միացնել web_rbl.sperren_aktiv-ը (Կարգավորումներ → Տեխնիկական → Համակարգային պարամետրեր) — այստեղից սկսած ճանաչված զոնդերն իրականում մերժվում են։
4. Արգելափակման ցուցակը մոդուլում նշված, token-ով պաշտպանված հասցեով միացնել firewall-ին որպես RBL ցուցակ (OPNsense/pfSense-ի դեպքում՝ որպես URL Table Alias, HAProxy-ի դեպքում՝ որպես ACL ֆայլ)։

5. Պաշտպանել հենց firewall-ը

1. Firewall-ի կառավարման միջերեսը դարձնել հասանելի բացառապես ներքին ցանցից, երբեք՝ կայքի հետ նույն հանրային հասցեով։
2. Ակտիվացնել firewall ծրագրակազմի անվտանգության ավտոմատ թարմացումները, եթե արտադրողն այդպիսիք առաջարկում է։
3. Ստուգել TLS կարգավորումը. միայն ընթացիկ արձանագրության տարբերակներ, հնացած գաղտնագրման մեթոդներն անջատել։
4. Եթե հասանելի է. հայտնի հեղինակության ցուցակ (օրինակ՝ Spamhaus DROP) միացնել անմիջապես firewall-ում — անկախ Web RBL-ից, քանի որ դրանով firewall-ը տեսնում է նաև այն ծառայությունների երթևեկությունը, որոնց Odoo-ն երբեք չի հասնում։

6. Փակել տվյալների բազայի կառավարումը

1. Ստուգել՝ արդյոք /web/database/manager-ը հասանելի է դրսից — եթե այո, Odoo-ի կարգավորման մեջ սահմանել list_db = False կամ ուղին արգելափակել firewall-ի մակարդակում։
2. Տվյալների բազայի կառավարման հիմնական գաղտնաբառը սահմանել երկար և պատահական և ոչ մի տեղ չգրանցել, որտեղ որևէ մեկը կարող է կարդալ։

7. Ստուգել պահուստային պատճենը, ոչ միայն կարգավորել

1. Կարգավորել ավտոմատ, կանոնավոր պահուստավորում՝ Odoo սերվերից առանձին պահվող։
2. Առնվազն մեկ անգամ իսկապես վերականգնել և ստուգել՝ արդյոք վերականգնումն աշխատում է — չստուգված պահուստային պատճենը ենթադրություն է։

Այս քայլերից ոչ մեկը չի փոխարինում մյուսներին։ Ով իրականացնում է դրանցից միայն մեկը, ամրացրել է մեկ դուռ և բոլոր մյուսները թողել է բաց — ով իրականացնում է բոլոր յոթը, ունի պաշտպանություն, որը դիմանում է նույնիսկ այն ժամանակ, երբ առանձին շերտը ձախողվում է։

Ինչը այս ճարտարապետությունը չի փոխարինում

Նկարագրված միջոցառումներից ոչ մեկը խնամքն ավելորդ չի դարձնում։ Մոդուլը, որը .env զոնդերը մերժում է, չի դարձնում անվտանգ պատահաբար հրապարակված .env ֆայլը։ Երկգործոն նույնականացումը չի պաշտպանում այն օգտվողից, որը իր կոդը հեռախոսով կարդում է զանգահարողին։ Եվ firewall-ը չի փոխարինում այն որոշմանը, թե ում իրականում ինչ իրավասություն է պետք։ Անվտանգության ճարտարապետությունը ստեղծում է պայմաններ, որոնցում առանձին սխալը անմիջապես չի վերածվում միջադեպի — այն ոչ մեկին չի ազատում խնամքից։

Հաճախ տրվող հարցեր

Բավարա՞ր է ուժեղ գաղտնաբառը Odoo 19-ը պաշտպանելու համար

Ոչ։ Գաղտնաբառը կարող է գողացվել այլ տեղում՝ անկախ իր որակից, և այնուհետև աշխատում է յուրաքանչյուր ծառայությունում, որն ընդունում է նույն գաղտնաբառը։ Միայն երկգործոն նույնականացման, առջևի firewall-ի և նպատակահարմար իրավասությունների կառուցվածքի համադրությունն է տալիս պաշտպանություն, որը դիմանում է նույնիսկ գողացված գաղտնաբառից հետո։

Ինչպե՞ս ակտիվացնել երկգործոն նույնականացումը Odoo 19-ում

Apps կառավարման միջոցով տեղադրել «Two-Factor Authentication (TOTP)» մոդուլը, այնուհետև Կարգավորումներ → Ընդհանուր կարգավորումներ → Իրավասություններ բաժնում ակտիվացնել պարտադրումը և ընտրել «Միայն աշխատակիցներ» և «Բոլոր օգտվողները» տարբերակների միջև։ Դրանից հետո յուրաքանչյուր օգտվող իր երկրորդ գործոնը կարգավորում է QR կոդով։

Ի՞նչ է RBL ցուցակը, և ինչու՞ է այն պետք Odoo-ին

RBL-ը (Real-time Blackhole List) HTTP-ով հասանելի հասցեների ցուցակ է, որը կարող է կարդալ գործնականում ցանկացած firewall։ Odoo-ն ինքը նման ցուցակ չի տրամադրում — մեր Web RBL մոդուլը փակում է այս բացը՝ հարձակման երթևեկությունը ճանաչելով սեփական հավելվածի մատյանից և որպես RBL ցուցակ հետ տալով առջևում գտնվող firewall-ին։

Բավարա՞ր է պաշտպանված Odoo 19 Community-ն առանց լրացուցիչ մոդուլների

Ոչ լիովին։ Առանց Password Policy մոդուլի գաղտնաբառերի համար նվազագույն երկարություն չկա, առանց Two-Factor Authentication-ի՝ երկրորդ գործոն չկա, և առանց Web RBL-ի նման մոդուլի Odoo-ն չի ճանաչում ո՛չ զոնդավորման փորձերը, ո՛չ վերագործարկումից հետո կրկնվող մուտքի փորձերը։ Բոլոր չորսը կարելի է անվճար հավելել։

Հասանելիություն

Web RBL-ը AGPL-3 լիցենզիայով հանրային հասանելի է և մեզ մոտ արտադրական միջավայրում աշխատում է հինգ կայքերում՝

github.com/Alex0176/odoo-web-rbl

Բոլոր ձևանմուշներով, գնահատմամբ և սպառնալիքների ցուցակներով ամբողջական գործառույթների նկարագրությունը գտնվում է նախորդ հոդվածում՝ Web RBL – արգելափակման ցուցակ սեփական կայքերի դեմ հարձակման երթևեկության համար.

Հարցերը, դիտողություններն ու սխալների հաշվետվությունները ուրախությամբ ընդունում ենք — ամենից շատ՝ որպես issue GitHub-ում։