Odoo Security

Backup / Pemulihan Bencana

• Kami menyimpan 14 backup penuh untuk setiap database Odoo sampai dengan 3 bulan; 1/hari untuk 7 hari, 1/minggu untuk 4 minggu, 1/bulan untuk 3 bulan.
• Backup akan direplikasi dalam setidaknya 3 data center yang berbeda, pada setidaknya 2 benua yang berbeda.
• Lokasi asli dari pusat data kami diterangkan pada Kebijakan Privasi.
• Anda juga dapat mengunduh backup manual dari live data Anda kapan pun juga menggunakan control panel.
• Anda dapat menghubungi Meja bantuan kami untuk memulihkan backup manapun pada database live Anda (atau di samping).
• Hardware failover: untuk layanan yang di-hosting pada logam telanjang, di mana kegagalan hardware bisa terjadi, kami mengimplementasikan replikasi hot-standby lokal, dengan monitoring dan prosedur fallover yang membutuhkan waktu kurang dari 5 menit.
• Pemulihan bencana: apabila terjadi bencana total, dengan pusat data yang sepenuhnya down untuk periode yang berkelanjutan, mencegah fallover ke hot-standby lokal (ini belum pernah terjadi, ini adalah rencana untuk kasus terburuk), kami memiliki tujuan-tujuan berikut:
  • RPO (Recovery Point Objective) = 24j. Ini berarti Anda dapat kehilangan maksimal 24j pekerjaan Anda bila data tidak dapat dipulihkan dan kita harus memulihkan backup harian terakhir Anda.
  • RTO (Recovery Time Objective) = 24j untuk langganan berbayar, 48j untuk free trial, tawaran edukasi, user freemium, dsb. Ini adalah waktu yang dibutuhkan untuk memulihkan layanan di pusat data yang berbeda bila terjadi bencana dan pusat data sepenuhnya down.
  • Bagaimana ini dilakukan: kami secara aktif memonitor backup harian kami, dan mereka akan direplikasi di berbagai lokasi pada benua-benua yang berbeda. Kami memiliki penyediaan otomatis untuk memasang layanan kami di lokasi hosting baru. Memulihkan data berdasarkan backup hari sebelumnya dapat dilakukan dalam beberapa jam (untuk cluster terbesar), dengan prioritas untuk langganan berbayar.
    Kami secara rutin menggunakan backup harian dan provisioning script untuk pengoperasian harian, supaya masing-masing bagian dari prosedur pemulihan bencana selalu diuji.

Keamanan Database

• Data pelanggan akan disimpan dalam database yang khusus - tidak akan ada sharing data di antara klien.
• Peraturan kontrol akses data mengimplementasikan isolasi penuh di antara database pelanggan yang bekerja di cluster yang sama, tidak ada akses yang dapat terjadi dari satu database ke lainnya.

Keamanan Password

• Password pelanggan dilindungi dengan enkripsi standar industri PBKDF2+SHA512 (salted + stretched untuk ribuan rounds).
• Staf Odoo tidak memiliki akses ke password Anda, dan tidak dapat memberikannya ke Anda, satu-satunya pilihan Anda bila Anda lupa adalah untuk reset password.
• Kredensial login akan selalu dikirim secara aman melalui HTTPS.
• Administrator database pelanggan bahkan memiliki opsi untuk mengonfigurasi waktu yang membatasi dan durasi cooldown untuk percobaan login yang berulang-ulang.
• Kebijakan password: administrator database memiliki pengaturan yang memaksakan panjang minimal password user. Kebijakan password lainny seperti tipe karakter yang diperlukan secara default tidak digunakan karena mereka telah dibuktikan kontrakproduktif. Lihat contoh [Shay et al. 2016]), dan juga NIST SP 800-63b.

Akses Staf

• Staff meja bantuan Odoo dapat log in ke akun Anda untuk mengakses pengaturan terkait masalah bantuan Anda. Untuk ini mereka akan menggunakan kredensial khusus staf mereka sendiri, bukan password Anda (yang mana mereka tidak akan ketahui).
• Akses khusus staf ini meningkat efisiensi dan keamanan: mereka dapat secara langsung membuat ulang masalah yang Anda lihat, Anda tidak perlu membagikan password Anda sama sekali, dan kami dapat mengaudit dan mengontrol tindakan staf secara terpisah!
• Staf Mejabantuan kami berusaha untuk menjaga privasi Anda sebisa mungkin, dan hanya mengakses file dan pengaturan yang dibutuhkan untuk mendiagnosis dan menyelesaihkan masalah Anda.

Keamanan Sistem

• Semua server Odoo Cloud menjalankan hardened Linux distribution dengan security patch yang up-to-date.
• Penginstalan bersifat ad-hoc dan minim untuk membatasi jumlah layanan yang dapat memiliki kerentanan (contohnya tidak ada PHP/MySQL stack)
• Hanya beberapa engineer terpercaya Odoo yang memiliki izin untuk secara jarak jauh menangani server - dan akses hanya bisa dilakukan menggunakan kunci pasangan SSH pribadi yang dienkripsi, dari komputer dengan enkripsi full-disk.

Keamanan Fisik

Server Odoo Cloud di-hosting di pusat data terpercaya di beragam daerah di dunia (contohnya OVH, Google Cloud), dan mereka semua harus melebihi kriteria keamanan fisik kami:

• Pembatasan perimeter, diakses secara fisik hanya oleh karyawan pusat data yang sah.
• Kontrol akses fisik dengan lencana keamanan atau keamanan biometrik.
• Kamera sekuriti memonitor lokasi pusat data 24/7.
• Personil keamanan di tempat 24/7.

Keamanan Kartu Kredit

• Kita tidak pernah menyimpan informasi kartu kredit untuk sistem kita sendiri.
• Informasi kartu kredit Anda selalu dikirim secara aman langsung dari antara Anda dan kami PCI-Compliant pengakuisisi pembayaran (lihat daftar pada Kebijakan Privasi ).

Enkripsi Data

• Semua data komunikasi ke client instance akan dilindungi dengan enkripsi 256-bit SSL (HTTPS) terbaik.
• Semua data komunikasi internal di antara server kami juga dilindungi dengan enkripsi terbaik (SSH).
• Server kami selalu di bawah pengawasan keamanan yang ketat, dan selalu di-patch terhadap kerentanan SSL terkini, sehingga selalu memiliki Grade A SSL rating.
• Semua sertifikat SSL menggunakan 2048-bit modulus yang kuat dengan SHA-2 certificate chain.
• Semua data pelanggan (konten database dan file yang disimpan) akan dienkripsi saat dalam rest, baik dalam produksi dan dalam backup (AES-128 atau AES-256)

Perlindungan network

• Semua penyedia pusat data yang digunakan oleh Odoo Cloud memiliki kapasitas network yang sangat besar, dan infrastruktur mereka telah dirancang untuk menghadapi serangan Distributed Denial of Service (DDoS) yang paling kuat. Sistem migitasi otomatis dan manual dapat mendeteksi dan mengalihkan traffic penyerang di ujung network multi-benua mereka, sebelum penyerang memiliki kesempatan untuk merusak ketersediaan layanan.
• Firewall dan sistem pencegah instrusi pada server Odoo Cloud membantu mendeteksi dan memblokir ancaman seperti penyerangan brute-force terhadap password.
• Administrator database pelanggan bahkan memiliki opsi untuk mengonfigurasi waktu yang membatasi dan durasi cooldown untuk percobaan login yang berulang-ulang.

Keamanan Software

Odoo bersifat open source, yang berarti seluruh codebase secara terus menerus akan diperiksa oleh user Odoo dan kontributor di seluruh dunia. Oleh karena itu laporan bug komunitas merupakan satu sumber penting untuk feedback keamanan. Kami menyarankan developer untuk mengaudit kode dan melaporkan masalah keamanan.

Proses-proses Litbang Odoo memiliki langkah peninjauan kode yang termasuk aspek keamanan, untuk bagian-bagian kode yang baru dan lama.

Dirancang aman

Odoo dirancang sedemikian rupa untuk mencegah masknya kerentanan keamanan yang paling umum:

• SQL injection dicegah dengan penggunaan API tingkat-tinggi yang tidak membutuhkan query SQL manual.
• Serangan XSS akan dicegah dengan menggunakan sistem templating tingkat tinggi yang secara otomatis lolos dari data yang di-inject.
• Framework mencegah akses RPC ke metode privat, sehingga lebih sulit untuk menghasilkan kerentanan yang dapat dieksploitasi.

Lihat juga bagian Kelemahan Utama OWASP untuk melihat bagaimana Odoo dirancang dari bawah ke atas untuk mencegah munculnya kerentanan-kerentanan tersebut.

Audit Keamanan Independen

Odoo secara reguler diaudit oleh perusahaan independen yang disewa oleh pelanggan untuk melakukan audit dan tes penetrasi. Tim Keamanan Odoo menerima hasil dan mengambil langkah-langkah korektif yang sesuai kapanpun dibutuhkan.

Namun kami tidak dapat mengungkapkan hasil apapun dari aduit tersebut, karena mereka bersifat rahasia dan milik komisaris. Jadi jangan tanya ;-)

Odoo juga memiliki komunitas peneliti keamanan independen yang sangat aktif, yang secara terus menerus memonitor source code dan bekerja dengan kami untuk memperbarui dan memperkuat keamanan Odoo. Program Keamanan Kami diterangkan pada halaman Pengungkapan Bertanggungjawab .

Kelemahan Utama OWASP

Di sini Odoo berdiri di atas masalah keamanan terburuk untuk aplikasi website, seperti yang dicantumkan oleh Buka Project Keamanan Aplikasi Web (OWASP):

• Injection Flaw: Injection flaw, terutama SQL injection, termasuk umum di aplikasi website. Injection terjadi saat data yang disediakan user dikirim ke interpreter sebagai bagian dari command atau query. Data agresif penyerang menipu interpreter untuk menjalankan comman yang tidak benar atau merubah data.

  Odoo tergantung pada framework object-relational-mapping (ORM) yang membuat query building menjadi abstrak dan secara default mencegah SQL injection. Developer biasanya tidak membuat query SQL secara manual, mereka dibuat oleh ORM, dan parameter akana selalu secara diloloskan dengan benar.

• Cross Site Scripting (XSS): Kecacatan XSS muncul kapanpun aplikasi menggambil data yang disediakan user dan mengirimkannya ke browser website tanpa terlebih dahulu memvalidasi atau mengkode data tersebut. XSS memungkinkan penyerang untuk menggunakan script di browser korban yang dapat membajak sesi user, menghapus website, menaruh worm, dsb.

  Framework Odoo mencegah XSS dengan melakukan escape pada semua expression yang secara default di-render menjadi view dan page. Developer harus secara khusus menandai expression sebagai "safe" supaya mendapatkan raw inclusion ke halaman yang di-render.

• Cross Site Request Forgery (CSRF): Serangan CSRF memaksa browser korban yang sudah log in untuk mengirimkan permintaan HTTP yang palsu, termasuk cookie sesi dan segala informasi autentikasi tambahan lainnya yang tercantum, ke aplikasi website yang lemah. Ini memungkin penyerang untuk memaksa browser korban untuk membuat permintaan yang aplikasi lemah tersebut pikir merupakan permintaan yang sah dari korban.

  Engine website Odoo termasuk mekanisme pelindung CSRF bawaan. Ini akan mencegah controller HTTP apapun untuk menerima request POST tanpa token keamanan yang sesuai. Ini adalah teknik yang direkomendasikan untuk mencegah CSRF. Token keamanan ini hanya diketahui dan ditunjukkan saat user secara asli mengakses form website yang relevan, dan penyerang tidak dapat memalsukan request tanpanya.

• Malicious File Execution: Kode yang rentan terhadap penyertaan file jarak jauh (RFI) memungkinkan penyerang untuk menyertakan kode dan data yang agresif, berujung pada serangan yang menghancurkan, seperti kehancuran total server.

  Odoo tidak mengekspos function untuk melakukan remote file inclusion. Namun ini memungkinkan user dengan hak istimewa untuk mengustomisasi fitur dengan menambahkan custom expression yang akan dievaluasi sistem. Expression seperti ini akan selalu dievaluasi dalam environment sandbox yang bersih yang hanya mengizinkan akses ke function yang diizinkan.

• Insecure Direct Object Reference: Direct object reference terjadi saat developer menampakkan reference ke internal implementation object, seperti file, directori, rekaman database, atau key, seperti URL atau form parameter. Penyerang dapat memanipulasi reference tersebut untuk mengakses object-object lain tanpa izin.

  Kontrol akses Odoo tidak diimplementasikan pada level antarmuka user, supaya tidak ada risiko mengekspos reference ke internal object dalam URL. Penyerang tidak dapat melingkari akses kontrol layer dengan memanipulasi reference tersebut, karena setiap request masih harus melalui layer validasi akses data.

• Penyimpanan Kriptografi Tidak Aman: Aplikasi website jarang menggunakan fungsi kriptografi dengan benar untuk melindungi data dan kredensial. Penyerang menggunakan data yang tidak dilindungi benar untuk melakukan pencurian identitas dan kejahatan lainnya, seperti penipuan kartu kredit.

  Odoo menggunakan hashting pengaman standar industri untuk password user (secara default PBKDF2 + SHA-512, dengan key stretching) untuk melindungi password yang disimpan. Anda juga dapat menggunakan sistem otentikasi eksternal seperti OAuth 2.0 atau LDAP, untuk menghindari penyimpanan password user sama sekali.

• Komunikasi Tidak Aman: Aplikasi sering kali gagal untuk mengenkripsi lalu lintas jaringan walaupun penting untuk melindungi komunikasi sensitif.

  Odoo Cloud menggunakan secara default HTTPS. Untuk penginstalan on-premise, kami merekomendasikan pelaksanaan Odoo di belakang web server yang mengimplementasikan enkripsi dan proxy request ke Odoo, contohnya Apache, Lighttpd or nginx. Pedoman pemasangan Odoo memiliki daftar Keamanan untuk pemasangan publik yang lebih aman.

• Gagal untuk Membatasi Akses URL: Sering kali aplikasi hanya melindungi fungsionalitas sensitif dengan mencegah penampilan link atau URL ke user yang tidak sah. Penyerang dapat menggunakan kelemahan ini untuk mengakses and melakukan pengoperasian yang tidak sah dengan mengakses URL tersebut secara langsung.

  Kontrol akses Odoo tidak diimplementasikan pada level antarmuka user, dan keamanan tidak bergantung pada menyembunyikkan URL khusus. Penyerang tidak dapat melingkari akses kontrol layer dengan menggunakan ulang atau memanipulasi URL, karena setiap request masih harus melalui layer validasi akses data. Pada kasus langka dimana URL menyediakan akses tanpa izin ke data yang sensitif, seperti URL khusus yang pelanggan gunakan untuk mengonfirmasi order, URL ini akan secara digital ditandai dengan token unik dan hanya dikirim melalui email ke penerima yang dituju.

Melaporkan Kerentanan Keamanan

Bila Anda ingin melaporkan kelemahan pada keamanan, silakan gunakan halaman pengungkapan yang bertanggung jawab. Laporan-laporan ini diberikan prioritas tinggi, masalah yang terkait akan langsung diperiksa dan diselesaikan oleh tim keamanan Odoo, berkolaborasi dengan pelapor, dan akan diberitahukan dengan cara yang bertanggung jawab ke pelanggan dan user Odoo.