Odoo 19 უსაფრთხოების არქიტექტურა: ბრანდმაუერის, 2FA-ს, უფლებებისა და Web RBL-ის სწორი შეხამება

Odoo ჩვენს ხუთ ვებგვერდზე ღია ინტერნეტიდან ხელმისაწვდომია და ეს გამონაკლისი კი არა, ნორმაა: ვინც შეთავაზებას, მაღაზიას ან კლიენტის შესვლას ამუშავებს, საჯარო სერვერი ჰყავს. ერთი მოწყვლადი პაროლი, ერთი დავიწყებული კონფიგურაციის ფაილი ან ზედმეტად გულუხვად მინიჭებული უფლება საკმარისია, რომ საჯარო სერვერი ღია სერვერად იქცეს.

ეს სტატია გაჩვენებთ, როგორ დავიცვათ Odoo 19 სწორად — არა ერთი ღონისძიებით, არამედ რამდენიმე ფენით, რომლებიც ერთმანეთს ავსებენ: ბრანდმაუერი და reverse proxy, ჩვენი ღია კოდის მოდული Web RBL, ორფაქტორიანი ავთენტიფიკაცია, პაროლის პოლიტიკა და უფლებები — და რომელ თავდასხმის მცდელობებს აჩერებს რეალურად თითოეული მათგანი. ბოლოს მოცემულია ეტაპობრივი ინსტრუქცია, რომლითაც ნებისმიერი საკუთარი Odoo ინსტალაციის გამოსწორება შეიძლება.

ღრმა თავდაცვა: რატომ არასდროს კმარა ერთი ღონისძიება

უსაფრთხოების ყოველ ღონისძიებას ხარვეზი აქვს. ბრანდმაუერი ვერ ხედავს, რა ხდება Odoo-ს შესვლის ფორმაში. ძლიერი პაროლი არ იცავს, თუ ის სხვაგან უკვე მოიპარეს. უფლებების სტრუქტურა არაფერს შველის თავდამსხმელის წინააღმდეგ, რომელიც ჯერ საერთოდ არ შესულა. პრინციპს, რომელიც ამ ხარვეზებს ხურავს, ეწოდება ღრმა თავდაცვა (defense in depth): რამდენიმე დამოუკიდებელი ფენა, რომელთაგან თითოეული ცალკე აღებული გვერდის ავლით შეიძლებოდა — მაგრამ ყველა ერთად არა.

ჩვენთან ოთხი ფენაა, თითოეულს განსხვავებული ამოცანა აქვს:

• ბრანდმაუერი / reverse proxy — აშკარად მავნეს ჯერ კიდევ მანამ აშორებს, სანამ ის სერვერამდე მიაღწევდეს
• Web RBL — აკავშირებს ორივე მხარეს: Odoo საკუთარი აპლიკაციის ჟურნალიდან სწავლობს იმას, რასაც ბრანდმაუერი საერთოდ ვერ ხედავს, და უკან მას აწვდის
• თავად Odoo — ორფაქტორიანი ავთენტიფიკაცია, პაროლის პოლიტიკა, უფლებები, სესიების მართვა
• მონაცემთა ბაზა & ექსპლუატაცია — სარეზერვო ასლი, მართვაზე წვდომის დაცვა, საიდუმლოებები ყველა ჟურნალის გარეთ

შემდეგი განყოფილებები თითოეულ ფენას ცალ-ცალკე განიხილავს.

ფენა 1: ბრანდმაუერი და reverse proxy

ბრანდმაუერი პირველი ინსტანციაა, რომელიც მოთხოვნას ხედავს, და ერთადერთი, რომელსაც შეუძლია თავდამსხმელი სერვერზე ნებისმიერი სერვისისგან დააშოროს — არა მხოლოდ ვებგვერდისგან, არამედ ფოსტის სერვერისგან, VPN წვდომისგან და მართვის საკუთარი ინტერფეისისგანაც. რისი ჩართვაა აქ გონივრული, მწარმოებელზეა დამოკიდებული, მაგრამ ფორმები OPNsense-ის, pfSense-ის, HAProxy-ის, FortiGate-ის, Sophos-ის ან Check Point-ის შემთხვევაში იგივეა:

RBL სიები: სტანდარტული გზა, რომლითაც რეპუტაცია მიეწოდება

RBL ნიშნავს Real-time Blackhole List, ტერმინი ფოსტის სამყაროდან: ერთი მისამართი თითო სტრიქონზე, HTTP-ით ხელმისაწვდომი, რეგულარულად ხელახლა ჩატვირთვადი. პრაქტიკულად ყველა ბრანდმაუერს შეუძლია ასეთი სიის წაკითხვა და მისგან წესების შექმნა — OPNsense და pfSense როგორც URL Table Alias, HAProxy როგორც ACL ფაილი, FortiGate როგორც External Block List, Palo Alto როგორც External Dynamic List, Cisco, Sophos, Juniper და MikroTik ამავე პრინციპისთვის საკუთარი სახელებით.

სწორედ აქ ერთვება ჩვენი საკუთარი მოდული — და სწორედ აქ იწყება მეორე ფენა.

ფენა 2: Web RBL — ხიდი აპლიკაციასა და ბრანდმაუერს შორის

ბრანდმაუერი პაკეტებს ხედავს და არა აპლიკაციის ლოგიკას. მან არ იცის, რომ მოთხოვნა /xmlrpc/2/common-ზე შესვლის მცდელობაა, რომ ოცი განსხვავებული გზა თოთხმეტ წამში სკანერია, ან რომ მისამართმა სწორედ ახლა წარმატებით გამოიცნო პაროლი. ყოველივე ამას მხოლოდ თავად Odoo იცის. Web RBL, ჩვენი საკუთარი ღია კოდის მოდული (AGPL-3), ამ ცოდნას გამოსადეგს ხდის — თავად Odoo-სთვის და, RBL სიის სახით მიწოდებით, მის წინ მდგარი ბრანდმაუერისთვისაც.

საფრთხეების სიები მუდმივად შედარებულია, თითოეული საკუთარი დონით.

მოკლედ შეჯამებულია ის, რაც წინა სტატიაში დეტალურად არის აღწერილი:

• შაბლონების ამოცნობა გზებში: .env ფაილები, .git დირექტორიები, კონფიგურაციის ფაილები, WordPress და PHP ზონდები, გზის გადაკვეთა (path traversal), ბრძანებების შესრულება ახალი AI ინტერფეისებით
• შესვლისგან დაცვა, რომელიც გადატვირთვებს მიღმაც ითვლის — Odoo-ს საკუთარი, ოპერატიულ მეხსიერებაში მცხოვრები მრიცხველისგან განსხვავებით
• თითოეული მისამართის შეფასება 0-დან 100-მდე, დასაბუთებით მარტივი ტექსტით
• არასწორი კონფიგურაციები (QNAP, Autodiscover, Synology) ამოიცნობა და არასდროს იბლოკება, რადგან ბლოკირება ხარვეზს არ ასწორებს, მხოლოდ მალავს
• უცხო საფრთხეების სიები, როგორიცაა Spamhaus, FireHOL და Tor-ის გამომავალი კვანძები, მუდმივად შედარებული
• თეთრი სია მისამართებისთვის, რომლებიც არასდროს უნდა დაიბლოკოს

ამ სტატიისთვის ორი თვისება განსაკუთრებით მნიშვნელოვანია, რადგან ისინი უშუალოდ ბრანდმაუერთან და შესვლასთან არის დაკავშირებული.

ინერტული სია არის სია, რომელსაც ენდობი

თეთრი სია — მისამართები, რომლებიც არასდროს იბლოკება, მაგალითად საკუთარი ფილიალების კავშირები — როგორც წესი, იშვიათად იცვლება. სწორედ ეს არის მისი ღირებულება და არა ნაკლი: როცა წყნარი სია დღეების განმავლობაში თითქმის არ იცვლება, ყოველი იშვიათი ცვლილება მაშინვე შესამჩნევია. ყოველდღიური ავტომატური განახლება იმიტომ არ არსებობს, რომ ბევრი რამ შეიცვლებოდა, არამედ იმისთვის, რომ იშვიათი ცვლილება ხელით არ უნდა შეიტანონ — და სწორედ ეს არის წერტილი, სადაც ამას ივიწყებენ. გასულ თვეს ჩვენი საკუთარი არასწორი კონფიგურაციებიდან ერთი ზუსტად ასე შეგვატყობინა თავი: არა ბევრი მოვლენით, არამედ იმ ერთით, რომელიც არავინ იცოდა, სანამ კლიენტის QNAP ვებ-API შეცდომით არ დაიბლოკა. მას შემდეგ QNAP არასწორი კონფიგურაციების სიაშია, რომლებიც არასდროს იბლოკება, მხოლოდ გადაიცემა შეტყობინებით.

შესვლა ის ადგილია, რომელსაც ბრანდმაუერი ვერ ხედავს

ბრანდმაუერს შეუძლია მისამართის დაბლოკვა. მან არ იცის, წარმატებული იყო თუ არა შესვლა, და მით უმეტეს, მოვიდა თუ არა ის მისამართიდან, რომელიც ცოტა ხნის წინ წვდომის მონაცემებს ეძებდა. Web RBL იცის: რეგულირებადი ზღვრიდან შეფასება შესვლას სრულად კრძალავს, ხოლო საეჭვო მისამართიდან წარმატებული შესვლა გადაიცემა შეტყობინებით — ეს არის რგოლი შემდეგ ფენასთან.

ფენა 3: თავად Odoo-ს დაცვა

ორფაქტორიანი ავთენტიფიკაცია: მეორე საიდუმლო, რომელიც ხელახლა გამოყენებადი არ არის

პაროლების უდიდესი პრობლემა მათი ხარისხი არ არის, არამედ ხელახალი გამოყენება. პაროლი, რომელიც სხვა სერვისზე მოიპარეს, ჩვენთანაც ზუსტად ისევე მუშაობს, სანამ იგივეა. ორფაქტორიანი ავთენტიფიკაცია (2FA, ასევე TOTP-ს უწოდებენ) ამას მეორე საიდუმლოს უპირისპირებს: ექვსნიშნა კოდს, რომელიც ყოველ ოცდაათ წამში იცვლება და გამოითვლება საიდუმლოდან, რომელიც მხოლოდ საკუთარმა სმარტფონმა იცის. მოპარული პაროლი მარტო ამგვარად აღარ კმარა.

Odoo 19 Community ამას ჩაშენებულად შეიცავს — დასაინსტალირებელი მოდულის სახით Two-Factor Authentication (TOTP), დამატებული ელფოსტით სარეზერვო ვარიანტით. თითოეული მომხმარებელი მას თავისთვის თავად აყენებს, QR კოდით, ნებისმიერი გავრცელებული Authenticator აპით:

გამართვა: QR კოდის სკანირება, ექვსნიშნა კოდის ერთხელ დადასტურება, და მზადაა.

ეს მარტო კი მხოლოდ მათ ეხმარება, ვინც მას თავისთვის თავად აყენებს — და გამოცდილება გვიჩვენებს, რომ იძულების გარეშე ისინი უმცირესობად რჩებიან. Odoo-ს ამიტომ აქვს იძულების პოლიტიკა: ან მხოლოდ თანამშრომლებისთვის (შიდა მომხმარებლები) ან ყველასთვის, პორტალის მომხმარებლების ჩათვლით. მეორე საიდუმლოს გამართვის გარეშე ვერავინ გაივლის შესვლის ფორმას ისე, რომ მას ელფოსტის კოდით მაინც არ დაადასტუროს.

პაროლის პოლიტიკა: მინიმალური სიგრძე თავისთავად არ იგულისხმება

დამატებითი მოდულის გარეშე Odoo Community პაროლების მინიმალურ სიგრძეს არ ითვალისწინებს — მომხმარებელს შეუძლია სამნიშნა პაროლი დააყენოს, თუ ვინმე ამას არ შეუშლის. საკუთარი Password Policy მოდული სწორედ ამ ხარვეზს ხურავს: მინიმალური სიგრძე, რომელიც სერვერის მხარეს ძალაში შედის და არა მხოლოდ ბრაუზერში იქნება შემოთავაზებული. ვისაც მეტი სურს — იძულებითი ვადა, ხელახალი გამოყენების საწინააღმდეგო ისტორია — ამისთვის OCA ან მესამე მხარის მოდული სჭირდება; Community ვერსიაში ეს შეგნებულად მსუბუქადაა დატოვებული.

უფლებები: წვდომას მხოლოდ ის იღებს, ვისაც სჭირდება

Odoo თავისთავად სამ დონეს ყოფს: პორტალის მომხმარებლები (მხოლოდ საკუთარი კლიენტის ან მომწოდებლის პორტალი), შიდა მომხმარებლები (ბექენდი, უფლებებით თითოეული აპლიკაციის მიხედვით) და ადმინისტრატორები (შეუზღუდავი წვდომა ტექნიკური პარამეტრების ჩათვლით). ყველაზე ხშირი შეცდომა ზედმეტად სუსტი პაროლი არ არის, არამედ ზედმეტად გულუხვად მინიჭებული ადმინისტრატორის როლი: ვისაც მხოლოდ ანგარიშფაქტურების შექმნა ევალება, სისტემურ პარამეტრებზე წვდომა არ სჭირდება.

ორი პრინციპი ყველაზე დიდ დატვირთვას ატარებს:

ორივე შეიძლება შემოწმდეს იმავე ხედში, რომელშიც ორფაქტორიანი ავთენტიფიკაციაც ყენდება:

ერთი მიმოხილვა, ოთხი ბერკეტი: პაროლი, მეორე ფაქტორი, 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. ბლოკირების სია მოდულში მითითებულ, ტოკენით დაცულ მისამართზე ჩართეთ ბრანდმაუერში RBL სიის სახით (OPNsense/pfSense-ში როგორც URL Table Alias, HAProxy-ში როგორც ACL ფაილი).

5. თავად ბრანდმაუერის დაცვა

1. ბრანდმაუერის მართვის ინტერფეისი გახადეთ ხელმისაწვდომი მხოლოდ შიდა ქსელიდან, არასდროს იმავე საჯარო მისამართით, რომლითაც ვებგვერდია.
2. ჩართეთ უსაფრთხოების ავტომატური განახლებები ბრანდმაუერის პროგრამისთვის, თუ მწარმოებელი ამას გვთავაზობს.
3. შეამოწმეთ TLS კონფიგურაცია: მხოლოდ მიმდინარე პროტოკოლის ვერსიები, მოძველებული დაშიფვრის მეთოდები გამორთეთ.
4. თუ ხელმისაწვდომია: ცნობილი რეპუტაციის სია (მაგალითად Spamhaus DROP) პირდაპირ ბრანდმაუერზე ჩართეთ — Web RBL-ისგან დამოუკიდებლად, რადგან ბრანდმაუერი ამგვარად ხედავს ტრაფიკსაც სერვისებისკენ, რომლებამდეც Odoo არასდროს აღწევს.

6. მონაცემთა ბაზის მართვის დახურვა

1. შეამოწმეთ, არის თუ არა /web/database/manager გარედან ხელმისაწვდომი — თუ დიახ, Odoo-ს კონფიგურაციაში დააყენეთ list_db = False ან გზა ბრანდმაუერის დონეზე დაბლოკეთ.
2. მონაცემთა ბაზის მართვის ძირითადი პაროლი დააყენეთ გრძელი და შემთხვევითი და არ ჩაიწეროთ არც ერთ ადგილას, რომელსაც სხვა ვინმე წაიკითხავს.

7. სარეზერვო ასლის შემოწმება და არა მხოლოდ გამართვა

1. გამართეთ ავტომატური, რეგულარული სარეზერვო ასლი, Odoo სერვერისგან განცალკევებით შენახული.
2. მინიმუმ ერთხელ რეალურად აღადგინეთ და შეამოწმეთ, მუშაობს თუ არა აღდგენა — შეუმოწმებელი სარეზერვო ასლი ვარაუდია.

არცერთი ეს ნაბიჯი სხვა ნაბიჯს არ ცვლის. ვინც მხოლოდ ერთს ახორციელებს, ერთი კარი გააძლიერა და ყველა სხვა ღია დატოვა — ვინც შვიდივეს ახორციელებს, აქვს თავდაცვა, რომელიც მაშინაც გაუძლებს, როცა ერთი ფენა ჩავარდება.

რას არ ცვლის ეს არქიტექტურა

აღწერილი ღონისძიებებიდან არცერთი გულმოდგინებას ზედმეტს არ ხდის. მოდული, რომელიც .env ზონდებს უარყოფს, შემთხვევით გამოქვეყნებულ .env ფაილს უსაფრთხოს არ ხდის. ორფაქტორიანი ავთენტიფიკაცია არ იცავს მომხმარებლისგან, რომელიც თავის კოდს ტელეფონზე მრეკავს უკითხავს. და ბრანდმაუერი არ ცვლის გადაწყვეტილებას იმის შესახებ, ვის რა უფლება რეალურად სჭირდება. უსაფრთხოების არქიტექტურა ქმნის პირობებს, რომლებშიც ერთი შეცდომა მაშინვე ინციდენტად არ იქცევა — ის არავის ათავისუფლებს გულმოდგინებისგან.

ხშირი კითხვები

საკმარისია ძლიერი პაროლი Odoo 19-ის დასაცავად?

არა. პაროლი შეიძლება სხვაგან მოიპარონ, მისი ხარისხისგან სრულიად დამოუკიდებლად, და მაშინ ის მუშაობს ყველა სერვისზე, რომელიც იმავე პაროლს იღებს. მხოლოდ ორფაქტორიანი ავთენტიფიკაციის, წინ მდგარი ბრანდმაუერისა და გონივრული უფლებების სტრუქტურის კომბინაცია იძლევა დაცვას, რომელიც მოპარული პაროლის შემდეგაც გაუძლებს.

როგორ ჩავრთო ორფაქტორიანი ავთენტიფიკაცია Odoo 19-ში?

დააინსტალირეთ მოდული „Two-Factor Authentication (TOTP)“ Apps-ის მართვიდან, შემდეგ პარამეტრები → ზოგადი პარამეტრები → უფლებები განყოფილებაში ჩართეთ იძულება და აირჩიეთ „მხოლოდ თანამშრომლები“ ან „ყველა მომხმარებელი“. ამის შემდეგ თითოეული მომხმარებელი QR კოდით თავის საკუთარ მეორე ფაქტორს აყენებს.

რა არის RBL სია და რატომ სჭირდება მას Odoo-ს?

RBL (Real-time Blackhole List) არის HTTP-ით ხელმისაწვდომი მისამართების სია, რომელიც პრაქტიკულად ყველა ბრანდმაუერს შეუძლია წაიკითხოს. თავად Odoo ასეთ სიას არ მოჰყვება — ჩვენი მოდული Web RBL ამ ხარვეზს ხურავს: ის თავდასხმის ტრაფიკს საკუთარი აპლიკაციის ჟურნალიდან ამოიცნობს და RBL სიის სახით წინ მდგარ ბრანდმაუერს უბრუნებს.

საკმარისად არის დაცული Odoo 19 Community დამატებითი მოდულების გარეშე?

არა სრულად. Password Policy მოდულის გარეშე პაროლებს მინიმალური სიგრძე არ აქვთ, Two-Factor Authentication-ის გარეშე მეორე ფაქტორი არ არსებობს, და Web RBL-ის მსგავსი მოდულის გარეშე Odoo არც გამოძიების მცდელობებს ამოიცნობს და არც განმეორებით შესვლის მცდელობებს გადატვირთვის მიღმა. სამივე უფასოდ შეიძლება დაემატოს.

ხელმისაწვდომობა

Web RBL AGPL-3-ით საჯაროდ არის ხელმისაწვდომი და ჩვენთან პროდუქციულად მუშაობს ხუთ ვებგვერდზე:

github.com/Alex0176/odoo-web-rbl

სრული ფუნქციების აღწერა ყველა შაბლონით, შეფასებითა და საფრთხეების სიებით წინა სტატიაშია: Web RBL – ბლოკირების სია თავდასხმის ტრაფიკისთვის საკუთარ ვებგვერდებზე.

კითხვებს, შენიშვნებსა და შეცდომების შესახებ ანგარიშებს სიამოვნებით მივიღებთ — უპირატესად GitHub-ზე Issue-ს სახით.