Odoo 보안

백업 및 재해 복구

• 각 Odoo 데이터베이스의 14개 전체 백업을 최대 3개월 동안 유지합니다: 7일 기준 1일, 4주 기준 1주, 3개월 기준 1개월
• 최소 2개 지역의 다른 지역의 대륙에 위치한 최소 3개 이상의 데이터 센터로 백업을 복제 관리하고 있습니다.
• 데이터 센터의 실제 위치는 다음 내용에 지정되어 있습니다 개인정보 처리방침.
• 언제든지 제어판을 통하여 라이브 데이터 백업을 수동으로 다운로드 받을 수 있습니다.
• 헬프데스크로 문의하시면 해당되는 라이브 데이터베이스 (또는 사이드 데이터베이스) 백업을 복원하실 수 있습니다.
• 하드웨어 장애 조치: 하드웨어 장애가 발생할 수 있는 베어메탈 환경에서 호스팅 서비스를 제공하는 경우, 모니터링과 함께 수동 장애 조치 절차를 통하여 로컬 핫 스탠바이 조치로 복제를 구현하여 5분 이내에 완료할 수 있습니다.
• 재해 복구: 심각한 재해가 발생하여 데이터 센터가 장기간동안 완전히 다운되어, 로컬 핫 스탠바이의 장애 조치가 지원되지 않는 경우 (지금까지 발생한 사례가 없으며, 최악의 상황을 고려하는 계획임), 다음과 같은 내용을 목표로 하게 됩니다:
  • RPO (복구시점목표, Recovery Point Objective) = 24시간. 즉 데이터 복구가 불가능하거나 최근의 일일 백업을 복구해야 하는 상황의 경우에는 최대 24시간 동안의 작업이 손실 될 수 있습니다.
  • RTO (Recovery Time Objective: 복구시간목표) = 유료 구독의 경우 24시간, 무료 평가판이나 교육 연수, 무료 사용자의 경우 48시간. 재해가 발생하여 데이터 센터가 완전히 다운된 경우 다른 데이터 센터에서 서비스를 복원하는 시간입니다.
  • 수행되는 방법: 당사에서는 적극적으로 일일 백업을 모니터링하고 각기 다른 대륙에 위치한 여러 지역으로 복제합니다. 새로운 호스팅 위치에 서비스를 배포하기 위하여 프로비저닝을 자동화를 완료하였습니다. 전날의 백업 자료를 기반으로 데이터를 복원하는 작업은 몇 시간 내에 완료가 가능하며 (가장 대형 클러스터의 경우), 유료 구독에 우선 순위를 두고 진행됩니다.
    일상 작업을 위해 일일 백업 및 프로비저닝 스크립트 양쪽을 정기적으로 실행하므로 해재 복구 절차에서 항상 두 부분 모두를 테스트하고 있습니다.

데이터베이스 보안

• Customer data is stored in a dedicated database - no sharing of data between clients.
• Data access control rules implement complete isolation between customer databases running on the same cluster, no access is possible from one database to another.

Password Security

• Customer passwords are protected with industry-standard PBKDF2+SHA512 encryption (salted + stretched for thousands of rounds).
• Odoo staff does not have access to your password, and cannot retrieve it for you, the only option if you lose it is to reset it.
• Login credentials are always transmitted securely over HTTPS.
• Odoo 12.0부터 고객 데이터베이스 관리자는 다음과 같은 옵션도 있습니다:configure the rate limiting and cooldown duration for repeated login attempts.
• Password policies: as of Odoo 12 database administrators have a built-in setting for enforcing a minimum user password length. For older versions it is possible to achieve the same effect through customization. Other password policies like required character classes are not supported by default because they have been proven counter-productive - see e.g. [Shay et al. 2016]).

Staff Access

• Odoo helpdesk staff may sign into your account to access settings related to your support issue. For this they use their own special staff credentials, not your password (which they have no way to know).
• This special staff access improves efficiency and security: they can immediately reproduce the problem you are seeing, you never need to share your password, and we can audit and control staff actions separately!
• Our Helpdesk staff strives to respect your privacy as much as possible, and only access files and settings needed to diagnose and resolve your issue.

System Security

• All Odoo Cloud servers are running hardened Linux distributions with up-to-date security patches.
• Installations are ad-hoc and minimal to limit the number of services that could contain vulnerabilities (no PHP/MySQL stack for example).
• Only a few trusted Odoo engineers have clearance to remotely manage the servers - and access is only possible using an encrypted personal SSH keypair, from a computer with full-disk encryption.

Physical Security

Odoo Cloud servers are hosted in trusted data centers in various regions of the world (e.g. OVH, Google Cloud), and they must all exceed our physical security criterions:

• Restricted perimeter, physically accessed by authorized data center employees only.
• Physical access control with security badges or biometrical security.
• Security cameras monitoring the data center locations 24/7.
• Security personnel on site 24/7.

Credit Card Safety

• We never store credit card information on our own systems.
• Your credit card information is always transmitted securely directly between you and our PCI-Compliant payment acquirers (see the list on our 개인정보 처리방침 페이지).

데이터 암호화

• All data communications to client instances are protected with state-of-the-art 256-bit SSL encryption (HTTPS).
• All internal data communications between our servers are also protected with state-of-the-art encryption (SSH).
• Our servers are kept under a strict security watch, and always patched against the latest SSL vulnerabilities, enjoying A 단계 SSL ratings at all times.
• All our SSL certificates use robust 2048-bit modulus with full SHA-2 certificates chains.
• All customer data (database content and stored files) is encrypted at rest, both in production and in backups (AES-128 or AES-256)

Network defense

• Odoo 클라우드에서 사용하고 있는 데이터센터 공급업체들은 초 대용량의 네트워크 용량를 보유하고 있는 업체들이며, 가장 심각한 수준의 DDoS (Distributed Denial of Service) 공격에도 막아낼 수 있는 인프라가 구축되어 있습니다. 보유 중인 대륙간 네트워크의 어느 부분에서라도 서비스 이용을 방해할 수 있는 공격이 발생하기 전에, 자동 및 수동 마이그레이션 시스템을 통해서 공격 트래픽을 감지하고 우회시킬 수 있습니다.
• Firewalls and intrusion prevention systems on Odoo Cloud servers help detect and block threats such as brute-force password attacks.
• Odoo 12.0 버전부터, 고객 데이터베이스 관리자는 다음과 같은 옵션을 선택할 수 있습니다 configure the rate limiting 및 로그인 시도 반복에 따른 대기 시간.

Software Security

Odoo is open source, so the whole codebase is continuously under examination by Odoo users and contributors worldwide. Community bug reports are therefore one important source of feedback regarding security. We encourage developers to audit the code and report security issues.

The Odoo R&D processes have code review steps that include security aspects, for new and contributed pieces of code.

Secure by design

Odoo is designed in a way that prevents introducing most common security vulnerabilities:

• SQL injections are prevented by the use of a higher-level API that does not require manual SQL queries.
• XSS attacks are prevented by the use of a high-level templating system that automatically escapes injected data.
• The framework prevents RPC access to private methods, making it harder to introduce exploitable vulnerabilities.

See also the OWASP 취약점 내역 section to see how Odoo is designed from the ground up to prevent such vulnerabilities from appearing.

Independent Security Audits

Odoo is regularly audited by independent companies that are hired by our customers and prospects to perform audits and penetration tests. The Odoo Security Team receives the results and takes appropriate corrective measures whenever it is necessary.

We can't however disclose any of those results, because they are confidential and belong to the commissioners. Please don't ask ;-)

Odoo also has a very active community of independent security researchers, who continuously monitor the source code and work with us to improve and harden the security of Odoo. Our Security Program is described on our Responsible Disclosure 페이지

OWASP 취약점 내역

Here is where Odoo stands on the top security issue for web applications, as listed by the Open Web Application Security Project (OWASP):

• Injection Flaws: Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.

  Odoo relies on an object-relational-mapping (ORM) framework that abstracts query building and prevents SQL injections by default. Developers do not normally craft SQL queries manually, they are generated by the ORM, and parameters are always properly escaped.

• Cross Site Scripting (XSS): XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.

  The Odoo framework escapes all expressions rendered into views and pages by default, preventing XSS. Developers have to specially mark expressions as "safe" for raw inclusion into rendered pages.

• Cross Site Request Forgery (CSRF): A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

  The Odoo website engine includes a built-in CSRF protection mechanism. It prevents any HTTP controller to receive a POST request without the corresponding security token. This is the recommended technique for CSRF prevention. This security token is only known and present when the user genuinely accessed the relevant website form, and an attacker cannot forge a request without it.

• Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise.

  Odoo does not expose functions to perform remote file inclusion. However it allows privileged users to customize features by adding custom expressions that will be evaluated by the system. These expressions are always evaluated by a sandboxed and sanitized environment that only allows access to permitted functions.

• Insecure Direct Object Reference: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

  Odoo access control is not implemented at the user interface level, so there is no risk in exposing references to internal objects in URLs. Attackers cannot circumvent the access control layer by manipulating those references, because every request still has to go through the data access validation layer.

• Insecure Cryptographic Storage: Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

  Odoo uses industry-standard secure hashing for user passwords (by default PKFDB2 + SHA-512, with key stretching) to protect stored passwords. It is also possible to use external authentication systems such as OAuth 2.0 or LDAP, in order to avoid storing user passwords locally at all.

• Insecure Communications: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

  Odoo Cloud runs on HTTPS by default. For on-premise installations, it is recommended to run Odoo behind a web server implementing the encryption and proxying request to Odoo, for example Apache, Lighttpd or nginx. The Odoo deployment guide includes a Security checklist for safer public deployments.

• Failure to Restrict URL Access: Frequently an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

  Odoo access control is not implemented at the user interface level, and the security does not rely on hiding special URLs. Attackers cannot circumvent the access control layer by reusing or manipulating any URL, because every request still has to go through the data access validation layer. In rare cases where a URL provides unauthenticated access to sensitive data, such as special URLs customers use to confirm an order, these URLs are digitally signed with unique tokens and only sent via email to the intended recipient.

Reporting Security Vulnerabilities

If you need to report a security vulnerability, please head over to our responsible disclosure page. These reports are treated with high priority, the problem is immediately assessed and solved by the Odoo security team, in collaboration with the reporter, and then disclosed in a responsible manner to Odoo customers and users.