Odoo 19 təhlükəsizlik arxitekturası: şəbəkə ekranı, 2FA, səlahiyyətlər və Web RBL-i düzgün birləşdirmək

Bizim beş veb saytımızda Odoo açıq internetdən əlçatandır və bu, istisna deyil, adi haldır: xidmət təqdim edən, onlayn mağaza və ya müştəri girişi olan hər kəsin internetə açıq serveri var. Tək bir zəif parol, unudulmuş konfiqurasiya faylı və ya həddindən artıq geniş verilmiş icazə kifayətdir ki, internetə açıq server müdafiəsiz serverə çevrilsin.

Bu məqalə Odoo 19-u necə düzgün qorumağı göstərir — tək bir tədbirlə deyil, bir-birini tamamlayan bir neçə qatla: təhlükəsizlik divarı və əks proksi, açıq mənbəli modulumuz Web RBL, iki faktorlu autentifikasiya, parol siyasəti və giriş icazələri — həmçinin bunların hər birinin hansı hücum cəhdlərinin qarşısını həqiqətən aldığını izah edir. Sonda isə istənilən Odoo quraşdırmasında bu tədbirləri tətbiq etmək üçün addım-addım təlimat verilir.

Çoxqatlı müdafiə: niyə bir tədbir heç vaxt kifayət etmir

Hər bir təhlükəsizlik tədbirinin boşluğu var. Təhlükəsizlik divarı Odoo giriş formasında nə baş verdiyini görmür. Güclü parol başqa bir yerdə artıq oğurlanıbsa, qoruma təmin etmir. Giriş icazələri strukturu hələ sistemə daxil olmamış hücumçuya qarşı kömək etmir. Bu boşluqları bağlayan prinsip çoxqatlı müdafiə (defense in depth) adlanır: bir neçə müstəqil qatın hər birini ayrılıqda aşmaq mümkün olsa da, hamısını birlikdə aşmaq mümkün olmur.

Bizdə hərəsi fərqli vəzifə daşıyan dörd qat var:

• Təhlükəsizlik divarı / əks proksi — aşkar zərərli trafiki hələ serverə çatmamış dayandırır
• Web RBL — iki tərəfi birləşdirir: Odoo öz tətbiq jurnalından təhlükəsizlik divarının görə bilmədiyi məlumatları əldə edir və onları təhlükəsizlik divarına ötürür
• Odoo-nun özü — iki faktorlu autentifikasiya, parol siyasəti, giriş icazələri, sessiyaların idarə edilməsi
• Verilənlər bazası & istismar — ehtiyat nüsxələr, idarəetməyə girişin qorunması, məxfi məlumatların heç bir jurnala yazılmaması

Növbəti bölmələrdə hər qat ayrıca nəzərdən keçirilir.

Qat 1: Təhlükəsizlik divarı və əks proksi

Sorğunu ilk görən təhlükəsizlik divarıdır. O, hücumçunu serverdəki bütün xidmətlərdən — təkcə veb saytdan deyil, poçt serverindən, VPN girişindən və öz idarəetmə interfeysindən də uzaq saxlaya bilən yeganə vasitədir. Burada hansı funksiyaları aktivləşdirməyin məqsədəuyğun olduğu istehsalçıdan asılıdır, lakin OPNsense, pfSense, HAProxy, FortiGate, Sophos və Check Point-də əsas yanaşmalar eynidir:

RBL siyahıları: reputasiya məlumatlarının standart paylaşılma üsulu

RBL e-poçt sahəsindən gələn Real-time Blackhole List ifadəsinin qısaltmasıdır: hər sətirdə bir ünvan olan, HTTP üzərindən əldə edilən və müntəzəm yenidən yüklənən siyahı. Demək olar ki, hər təhlükəsizlik divarı belə siyahını oxuyub onun əsasında qaydalar yarada bilir — OPNsense və pfSense bunu URL Table Alias, HAProxy ACL faylı, FortiGate External Block List, Palo Alto isə External Dynamic List kimi istifadə edir. Cisco, Sophos, Juniper və MikroTik eyni prinsip üçün öz adlarından istifadə edir.

Öz modulumuz məhz burada işə düşür — ikinci qat da elə burada başlayır.

Qat 2: Web RBL — tətbiqlə təhlükəsizlik divarı arasında körpü

Təhlükəsizlik divarı paketləri görür, tətbiqin iş məntiqini isə görmür. O bilmir ki, /xmlrpc/2/common ünvanına sorğu giriş cəhdidir, on dörd saniyədə iyirmi müxtəlif yola müraciət skanerin işidir və ya hansısa ünvan indicə parolu düzgün tapıb. Bütün bunları yalnız Odoo özü bilir. Web RBL, öz açıq mənbəli modulumuz (AGPL-3), bu məlumatdan istifadə etməyə imkan verir — həm Odoo-nun özündə, həm də RBL siyahısı şəklində təqdim etməklə onun qarşısındakı təhlükəsizlik divarında.

Təhdid siyahıları ilə davamlı tutuşdurma aparılır, hər siyahının ayrıca səviyyəsi var.

Əvvəlki məqalədə ətraflı təsvir edilənlərin qısa xülasəsi:

• Yollarda nümunələrin aşkarlanması: .env faylları, .git qovluqları, konfiqurasiya faylları, WordPress və PHP yoxlama sorğuları, yol keçidi hücumları, yeni süni intellekt interfeysləri üzərindən əmrlərin icrası
• Zərərli giriş cəhdlərindən müdafiə: Odoo-nun yalnız operativ yaddaşda saxlanan öz sayğacından fərqli olaraq, sayğac yenidən başladılmalardan sonra da saxlanılır
• Hər ünvanın aydın mətnlə əsaslandırılmaqla 0-dan 100-ə qədər qiymətləndirilməsi
• Yanlış konfiqurasiyalar (QNAP, Autodiscover, Synology) aşkarlanır və heç vaxt bloklanmır, çünki bloklama nasazlığı aradan qaldırmır, sadəcə gizlədir
• Spamhaus, FireHOL və Tor çıxış qovşaqları kimi kənar təhdid siyahıları ilə davamlı tutuşdurma
• Heç vaxt bloklanmamalı ünvanlar üçün icazə siyahısı

Bu məqalə üçün iki xüsusiyyət xüsusilə vacibdir, çünki onlar birbaşa təhlükəsizlik divarı və giriş prosesi ilə bağlıdır.

Az dəyişən siyahıya etibar etmək olar

İcazə siyahısı — məsələn, öz filiallarımızın bağlantıları kimi heç vaxt bloklanmayan ünvanlar — adətən nadir hallarda dəyişir. Bu, onun çatışmazlığı deyil, üstünlüyüdür: siyahı günlərlə demək olar ki, dəyişməyəndə hər nadir dəyişiklik dərhal nəzərə çarpır. Gündəlik avtomatik yenilənmənin səbəbi çoxlu dəyişiklik olması deyil; məqsəd nadir dəyişiklikləri əl ilə əlavə etmək məcburiyyətini aradan qaldırmaqdır — çünki məhz bu iş unudulur. Ötən ay öz yanlış konfiqurasiyalarımızdan biri də elə belə üzə çıxdı: çoxlu hadisə sayəsində deyil, müştərinin QNAP veb API-si səhvən bloklanana qədər heç kimin bilmədiyi tək bir hadisə sayəsində. O vaxtdan QNAP heç vaxt bloklanmayan, yalnız haqqında bildiriş verilən yanlış konfiqurasiyalar siyahısındadır.

Giriş prosesi təhlükəsizlik divarının görmədiyi yerdir

Təhlükəsizlik divarı ünvanı bloklaya bilər. O, girişin uğurlu olub-olmadığını, xüsusən də az əvvəl giriş məlumatları axtaran bir ünvandan gəlib-gəlmədiyini bilə bilməz. Web RBL isə bilir: ünvanın balı təyin edilə bilən həddə çatdıqda giriş tamamilə qadağan edilir, şübhəli ünvandan uğurlu giriş olduqda isə bildiriş verilir — növbəti qatla əlaqəni bu yaradır.

Qat 3: Odoo-nun özünü qorumaq

İki faktorlu autentifikasiya: təkrar istifadə edilə bilməyən ikinci sirr

Parolların ən böyük problemi keyfiyyəti deyil, təkrar istifadə edilməsidir. Başqa bir xidmətdən oğurlanmış parol burada da eynidirsə, bizdə də işləyir. İki faktorlu autentifikasiya (2FA, TOTP də adlandırılır) buna qarşı ikinci bir sirr tələb edir: hər otuz saniyədən bir dəyişən və yalnız istifadəçinin öz smartfonunun bildiyi məxfi məlumat əsasında hesablanan altırəqəmli kod. Beləliklə, təkcə oğurlanmış parol artıq kifayət etmir.

Odoo 19 Community-də bu imkan quraşdırıla bilən Two-Factor Authentication (TOTP) modulu kimi mövcuddur və e-poçt vasitəsilə ehtiyat təsdiqləmə seçimi ilə tamamlanır. Hər istifadəçi onu QR kod vasitəsilə, geniş yayılmış istənilən autentifikator tətbiqindən istifadə edərək özü üçün qurur:

Quraşdırma: QR kodu skan edin, altırəqəmli kodu bir dəfə təsdiqləyin, hazırdır.

Ancaq bu, yalnız onu özləri üçün quranlara kömək edir — təcrübə göstərir ki, məcburi olmadıqda bunu edənlər azlıqda qalır. Buna görə Odoo-da məcburi tətbiq siyasəti var: ya yalnız əməkdaşlar (daxili istifadəçilər), ya da portal istifadəçiləri daxil olmaqla hamı üçün. İkinci məxfi amili qurmayan heç kəs ən azı e-poçt kodu ilə təsdiqləmə aparmadan giriş mərhələsini keçə bilmir.

Parol siyasəti: minimum uzunluq hər zaman tələb olunmur

Əlavə modul olmadan Odoo Community parollar üçün minimum uzunluq tələb etmir — qarşısı alınmasa, istifadəçi üç simvolluq parol təyin edə bilər. Odoo-nun öz Password Policy modulu məhz bu boşluğu aradan qaldırır: minimum uzunluq sadəcə brauzerdə tövsiyə edilmir, server tərəfində məcburi tətbiq olunur. Daha çox imkan — məcburi etibarlılıq müddəti və ya təkrar istifadənin qarşısını alan parol tarixçəsi — istəyənlərə OCA və ya üçüncü tərəf modulu lazımdır; Community versiyasında bu imkanlar qəsdən sadə saxlanılıb.

Giriş icazələri: yalnız ehtiyacı olana giriş verilir

Odoo standart olaraq üç səviyyəni ayırır: portal istifadəçiləri (yalnız öz müştəri və ya təchizatçı portalı), daxili istifadəçilər (hər tətbiq üçün ayrıca icazələrlə idarəetmə hissəsi) və administratorlar (texniki parametrlər daxil olmaqla məhdudiyyətsiz giriş). Ən çox rast gəlinən səhv zəif parol deyil, administrator rolunun həddindən artıq geniş verilməsidir: yalnız hesab-faktura yaratmalı olan şəxsin sistem parametrlərinə girişə ehtiyacı yoxdur.

Əsas yükü iki prinsip daşıyır:

Hər ikisini iki faktorlu autentifikasiyanın qurulduğu eyni ekranda yoxlamaq olar:

Bir ekran, dörd idarəetmə vasitəsi: parol, ikinci faktor, API açarları, hesaba daxil olmuş cihazlar.

Sessiyalar və cihazlar: hazırda kim sistemə daxil olub

Eyni ekran hesabın hazırda hansı cihazlarda açıq olduğunu da göstərir və bir cihazda, yaxud hamısında birdən hesabdan çıxmağa imkan verir. Noutbuk itdikdə və ya parolun ələ keçirildiyindən şübhələndikdə bu, ən sürətli və təsirli addımdır: parolun artıq dəyişdirilib-dəyişdirilməməsindən asılı olmayaraq sessiya dərhal bitir.

Qat 4: Verilənlər bazası və istismar

Dördüncü qat ən az görünən, eyni zamanda səhvə ən az dözən qatdır, çünki buradakı bir səhv əvvəl qurulmuş hər şeyi puça çıxara bilər.

• Müntəzəm yaradılan və yoxlanılan ehtiyat nüsxələr serverin özündən ayrı saxlanılmalıdır. Heç vaxt bərpası yoxlanılmamış ehtiyat nüsxə ehtiyat nüsxə deyil, sadəcə bir fərziyyədir.
• Məxfi məlumatlar heç bir jurnal faylına yazılmamalıdır. Parollar, API açarları, lisenziya məlumatları — öz əlavələrini yazanlar bunlarla əsas parolun özü kimi davranmalıdır: heç yerdə qeydə almamalı, hətta “yalnız sazlama üçün” belə.
• Modulları aktual saxlayın, xüsusən də üçüncü tərəf modullarını. Sərbəst yayımlanan əlavə modullar (OCA və digərləri) təbii olaraq yeni Odoo versiyalarından geri qalır; hər quraşdırmadan əvvəl hansı asılılıqların avtomatik quraşdırılacağına baxmağa dəyər.

Giriş prosesinə ümumi baxış

Dörd qat ayrı-ayrı yerlərdə növbə ilə işləmir; onlar eyni sorğunu mərhələ-mərhələ yoxlayır. Bu, giriş nümunəsində daha aydın görünür:

Zərərli sorğunun həqiqi hədəfə çatmamış bitə biləcəyi beş yer — və səlahiyyətli istifadəçinin hamısından keçdiyi yalnız bir yer.

Hücum ssenariləri və onlara qarşı müdafiə

Aşağıdakı icmal real hücum nümunələrini onların qarşısını həqiqətən alan qatlarla əlaqələndirir. Bunların bir neçəsi nəzəriyyə deyil, beş veb saytımızda on yeddi günlük real trafikdə öz müşahidələrimizdir.

Addım-addım: öz Odoo quraşdırmasını qorumaq

Özümüz də aşağıdakı ardıcıllıqla hərəkət edərdik — ən böyük təsir göstərən tədbirdən ən incə tənzimləməyə doğru.

1. İki faktorlu autentifikasiyanı məcburi edin

1. Hələ quraşdırılmayıbsa: Apps açın, „Two-Factor Authentication" axtarın və quraşdırın (bir neçə veb sayt olduqda əlavə olaraq ehtiyat seçimi kimi „Two-Factor Authentication by Mail" tövsiyə olunur).
2. Parametrlər → Ümumi parametrlər → İcazələr bölməsini açın.
3. „İki faktorlu autentifikasiyanı məcburi et" seçimini aktivləşdirin.
4. Siyasəti seçin: daxili istifadəçilər üçün „Yalnız əməkdaşlar", portal istifadəçiləri (girişi olan müştərilər) də daxil edilməlidirsə „Bütün istifadəçilər".
5. Yadda saxlayın. Növbəti giriş cəhdindən etibarən Odoo ikinci məxfi autentifikasiya məlumatını hələ təyin etməmiş hər istifadəçidən autentifikator tətbiqini qurana qədər ən azı e-poçt kodunu tələb edəcək.

2. Parollar üçün minimum uzunluq təyin edin

1. Apps açın, „Password Policy" axtarın və quraşdırın.
2. Parametrlər → Ümumi parametrlər → İcazələr bölməsini açın.
3. „Parolun minimum uzunluğu" təyin edin — on iki simvol ağlabatan başlanğıc dəyərdir.
4. Yadda saxlayın. Qayda dərhal qüvvəyə minir və bundan sonra yaradılan və ya dəyişdirilən bütün parollara tətbiq olunur; mövcud parollara geriyə qüvvəsi yoxdur.

3. Səlahiyyətləri nəzərdən keçirin

1. Parametrlər → İstifadəçilər & Şirkətlər → İstifadəçilər bölməsini açın.
2. Hər istifadəçini ayrıca açın və hər tətbiq üzrə giriş hüquqları olan vərəqi yoxlayın: Bu şəxsə həqiqətən „Manager" və ya „Administrator" lazımdır, yoxsa „İstifadəçi" kifayətdir?
3. Xüsusilə yoxlayın: Kimin „Parametrlər"-in özünə girişi var? Bu çox kiçik qrup olmalıdır.
4. Hər xarici inteqrasiya (mühasibatlıq, öz skriptləriniz, vaxt uçotu) üçün müvafiq texniki istifadəçinin „Hesab təhlükəsizliyi" vərəqində istifadəçi parolunu ötürmək əvəzinə ayrıca API açarı yaradın.

4. Web RBL-i quraşdırın və bloklamanı aktivləşdirməzdən əvvəl işini müşahidə edin

1. Modulu buradan github.com/Alex0176/odoo-web-rbl Əlavələr qovluğuna yerləşdirin və quraşdırın.
2. Bir neçə gün müşahidə edin: Web RBL → Təhlil menyusu hansı şablonların həqiqətən işlədiyini göstərir.
3. Yalnız bundan sonra web_rbl.sperren_aktiv parametrini aktivləşdirin (Parametrlər → Texniki → Sistem parametrləri) — bu andan etibarən aşkarlanan yoxlama cəhdləri faktiki olaraq rədd ediləcək.
4. Modulda göstərilən, tokenlə qorunan ünvandakı bloklama siyahısını şəbəkə ekranına RBL siyahısı kimi əlavə edin (OPNsense/pfSense-də URL Table Alias, HAProxy-də isə ACL faylı kimi).

5. Şəbəkə ekranının özünü qoruyun

1. Şəbəkə ekranının idarəetmə interfeysinə yalnız daxili şəbəkədən girişi təmin edin; onu heç vaxt veb-saytla eyni açıq ünvan üzərindən əlçatan etməyin.
2. İstehsalçı belə imkan təqdim edirsə, şəbəkə ekranı proqramı üçün avtomatik təhlükəsizlik yeniləmələrini aktivləşdirin.
3. TLS konfiqurasiyasını yoxlayın: yalnız aktual protokol versiyalarından istifadə edin, köhnəlmiş şifrələmə üsullarını söndürün.
4. Mümkündürsə, tanınmış reputasiya siyahısını (məsələn, Spamhaus DROP) birbaşa şəbəkə ekranına əlavə edin — Web RBL-dən asılı olmayaraq, çünki şəbəkə ekranı digər xidmətlərə yönələn və Odoo-ya heç vaxt çatmayan trafiki də görür.

6. Verilənlər bazasının idarəetmə interfeysinə xarici girişi bağlayın

1. /web/database/manager ünvanının xaricdən əlçatan olub-olmadığını yoxlayın — əlçatandırsa, Odoo konfiqurasiyasında list_db = False təyin edin və ya həmin yolu şəbəkə ekranı səviyyəsində bloklayın.
2. Verilənlər bazasının idarə edilməsi üçün uzun və təsadüfi əsas parol təyin edin və onu başqasının oxuya biləcəyi heç bir yerdə qeyd etməyin.

7. Ehtiyat nüsxələməni sadəcə qurmayın, yoxlayın

1. Müntəzəm avtomatik ehtiyat nüsxələmə qurun və nüsxələri Odoo serverindən ayrı saxlayın.
2. Ən azı bir dəfə ehtiyat nüsxədən faktiki bərpa aparın və prosesin işlədiyini yoxlayın — yoxlanılmamış ehtiyat nüsxəyə güvənmək sadəcə fərziyyədir.

Bu addımların heç biri digərini əvəz etmir. Onlardan yalnız birini yerinə yetirən şəxs bir qapını möhkəmləndirib qalanlarını açıq qoymuş olur — yeddisini də yerinə yetirən isə ayrı-ayrı müdafiə qatlarından biri sıradan çıxanda belə dayanıqlığını qoruyan müdafiə əldə edir.

Bu arxitektura nəyi əvəz etmir

Təsvir olunan tədbirlərin heç biri diqqətli davranmaq zərurətini aradan qaldırmır. .env faylını axtaran sorğuları rədd edən modul səhvən açıq yayımlanmış .env faylını təhlükəsiz etmir. İki faktorlu autentifikasiya öz kodunu telefonla zəng edən şəxsə oxuyan istifadəçini qorumur. Şəbəkə ekranı da kimin hansı səlahiyyətə həqiqətən ehtiyacı olduğunu müəyyənləşdirməyi əvəz etmir. Təhlükəsizlik arxitekturası tək bir səhvin dərhal təhlükəsizlik hadisəsinə çevrilmədiyi şərait yaradır — heç kəsi diqqətli davranmaq məsuliyyətindən azad etmir.

Tez-tez verilən suallar

Odoo 19-u qorumaq üçün güclü parol kifayətdirmi?

Xeyr. Parol nə qədər güclü olsa da, başqa bir yerdə oğurlana bilər və bundan sonra həmin parolu qəbul edən hər bir xidmətdə işləyər. Yalnız iki faktorlu autentifikasiya, sistemin qarşısında yerləşdirilmiş şəbəkə ekranı və düzgün qurulmuş səlahiyyət strukturu birlikdə parol oğurlandıqdan sonra da davam gətirən müdafiə yaradır.

Odoo 19-da iki faktorlu autentifikasiyanı necə aktivləşdirə bilərəm?

Tətbiqlərin idarə edilməsi bölməsindən “Two-Factor Authentication (TOTP)” modulunu quraşdırın, sonra Parametrlər → Ümumi parametrlər → İcazələr bölməsində məcburi tətbiqi aktivləşdirin və “Yalnız əməkdaşlar” ilə “Bütün istifadəçilər” arasında seçim edin. Bundan sonra hər istifadəçi QR kod vasitəsilə öz ikinci faktorunu qurur.

RBL siyahısı nədir və Odoo-ya nə üçün lazımdır?

RBL (Real-time Blackhole List) HTTP üzərindən əldə edilə bilən və demək olar ki, hər bir şəbəkə ekranının oxuya bildiyi ünvan siyahısıdır. Odoo-nun özündə belə bir siyahı yoxdur — Web RBL modulumuz tətbiqin öz jurnalından hücum trafikini aşkarlayıb onu RBL siyahısı kimi ön tərəfdə yerləşdirilmiş şəbəkə ekranına ötürməklə bu boşluğu doldurur.

Odoo 19 Community əlavə modullar olmadan kifayət qədər qorunurmu?

Tam olaraq yox. Password Policy modulu olmadan parollar üçün minimum uzunluq, Two-Factor Authentication olmadan ikinci faktor yoxdur; Web RBL kimi bir modul olmadan isə Odoo yenidən başladıldıqdan sonra əvvəlki yoxlama cəhdlərini və təkrarlanan giriş cəhdlərini tanımır. Dördünün hamısını pulsuz əlavə etmək mümkündür.

Əlçatanlıq

Web RBL AGPL-3 lisenziyası ilə açıq şəkildə təqdim olunur və bizdə beş veb-saytda işlək mühitdə istifadə edilir:

github.com/Alex0176/odoo-web-rbl

Bütün nümunələr, qiymətləndirmə və təhdid siyahıları daxil olmaqla funksiyaların tam təsviri əvvəlki yazıda verilib: Web RBL – öz veb-saytlarınızdakı hücum trafiki üçün bloklama siyahısı.

Suallarınızı, qeydlərinizi və xəta bildirişlərinizi məmnuniyyətlə qəbul edirik — ən yaxşısı GitHub-da Issue açmaqdır.