odoo安全性政策

https://www.odoo.com/zh_TW/security

##   备份 / 灾难修复

-   我们为每个Odoo数据库保存14个完整备份，长达3个月：每天1次的备份为期7天; 每周1次备份的为期4周; 每月1次的备份为期3个月。
-   备份会至少复制至2个不同大洲内最少3个不同数据中心保存。
-   有关数据中心的实际位置，请参阅我们的 [私隐政策](https://www.odoo.com/zh_TW/privacy).
-   你亦可随时使用控制台，下载实时数据的手动备份。
-   你可以联络我们的技术支持团队，以在你的正式运行数据库上（或分支）恢复任何这些备份。
-   **硬件故障转移：**对于寄存在可能发生硬件故障的裸机/硬盘上的服务，我们会采取本地热备份复制，并持续监控，故障时人手转移过程需时少于5分钟。
-   **灾难修复**：若发生严重灾难、数据中心长时间完全停运，导致无法执行故障转移至本地热备份时（迄今为止从未发生过，这是最坏情况的计划），我们有以下目标：
    -   恢复点目标（Recovery Point Objective，RPO）：24 小时。 这意味着如果无法修复数据，你可能最多失去之前 24 小时的工作，而我们需要恢复你最近的每日备份。
    -   恢复时间目标（Recovery Time Objective，RTO）：付费订户 24 小时; 免费试用客户、教育优惠、免费增值用户等48小时。 如果发生灾难并且数据中心完全停运，这是在另一数据中心恢复服务所需的时间。
    -   如何做到：我们紧密监控日常备份，并将它们复制到不同大洲的多个位置。 我们有自动配置，以在新的寄存位置执行我们的服务。 恢复前一天的备份数据可以在几个小时内完成（对于最大的群组），付费订户资料优先处理。  
        我们的例行日常运作会使用到每日备份及配置代码，因此这两个有关灾难修复程序的环节，都在经常测试。

## 数据库安全

-   客户数据是储存在专用数据库的。 客户之间不会共享资料。
-   资料访问控制规则会完全分隔在同一群组上运行的客户数据库，用户不可能在一个数据库中访问另一数据库的数据。

## 密码安全

-   客户密码以行业标准加密保护，即PBKDF2 + SHA512加密（加盐+延伸数千轮）。
-   Odoo 员工无法访问你的密码，亦无法为你寻回 / 读取密码。 如果你忘记或丢失密码，唯一选择是重置密码。
-   登录数据及凭证一定会透过 HTTPS 安全传送。
-   由Odoo 12.0开始，客户数据库管理员甚至可以选择[为登入速率设置限制](https://github.com/odoo/odoo/blob/326a44c3f7f754160c78649f7c6c69dc0c030d92/odoo/addons/base/models/ir_config_parameter.py#L23-L24)，及设定尝试重复登入之间的冷却时间。
-   **密码政策**：从 Odoo 12 开始，数据库管理员有一个内置设定，可以强制要求最低限度的用户密码长度。 旧版本可以通过自订功能，做到相同效果。 现时默认情况已不支持其他密码规限，例如**强制使用某些类别的字符**，因为已证实会适得其反-参见例如 [[Shay et al. 2016](https://www.archive.ece.cmu.edu/~lbauer/papers/2016/tissec2016-password-policies.pdf)]）.

## 员工存取

-   Odoo 技术支持人员可能会登入你的账户，以访问你所提出的技术支持问题的相关设置。 他们会使用自己的特殊员工凭证登入，不会使用你的密码（他们其实也无法知道）。
-   这种特殊的员工存取权限能提高效率和安全性：员工可以立即重现你看到的问题，而你永远不需要告诉他人你的密码，我们亦可以单独审计和监控员工的行为。
-   我们的技术支持员工会尽可能尊重你的私隐，只会在诊断和解决你提出的问题所需要时，才会存取相关文件和设置。

## 系统安全

-   所有Odoo云端服务器都以载有最新安全漏洞修补的强化版 Linux 发行版运行。
-   安装工作只在有需要时进行，并尽量采取最低限度安装，以限制可能包含漏洞服务的数量（举例，系统没有采用 PHP/MySQL 堆叠）。
-   只有少数受信任的 Odoo 工程师享有遥距管理服务器的权限，而且只限当使用加密的个人 SSH 密钥对，以及使用全硬盘加密的电脑时，才可进行访问。

## 实体安全

Odoo 云服务器在世界不同地域获信赖的数据中心寄存（例如 OVH、Google 云平台）。 这些中心须达致或超过我们要求的最低物理安全标准：

-   设立限制边界，仅允许获授权的数据中心员工进行物理存取（进出）。
-   对物理存取采取管制措施，例如使用保安徽章或生物识别安全认证。
-   设立保安监控镜头，全天候 24/7 监控数据中心位置。
-   派驻保安人员全天候 24/7 看守现场。

## 信用卡安全

-   我们不会在我们自己的系统上储存或保留信用卡资料。
-   你的信用卡数据必然通过安全途径传送，直接在你和我们所采用的[符合 PCI 标准（付款卡行业标准）](https://www.pcisecuritystandards.org/)的付款服务商之间传输。 （请参阅我们的 [私隐政策](https://www.odoo.com/zh_TW/privacy) 页面所载列表）。

## 资料加密

客户数据必定以加密形式传输和存储（在传输期间和完成传输的静止状态均会加密）。

-   与客户端实体进行的所有数据通信，都以先进的 256 位 SSL 加密技术（httpS）保护。
-   我们服务器之间的所有内部数据通信，亦是以先进的加密技术（SSH）保护。
-   我们的服务器受严格保安监管，并一直针对最新的SSL漏洞进行修补，时刻保持[A级](https://www.ssllabs.com/ssltest/analyze.html?d=www.odoo.com)SSL评级。
-   我们所有的SSL证书都使用强大的2048位模数和完整的SHA-2证书链。
-   所有客户数据（数据库内容及储存的档案），不论正式运行版本抑或备份，都会静态加密（AES-128 或 AES-256）存放。

## 网络防御

-   Odoo 云服务所使用的数据中心供应商，全部都拥有非常大的网络容量，而且他们的基础架构设计能够承受最猛烈的分布式阻断服务（DDoS）攻击。 他们的自动及人手排解系统，在攻击流量有机会干扰服务可用性之前，已能在分布多个大洲的网络的边缘，侦测并疏导攻击流量。
-   Odoo 云端服务器上的防火墙及入侵防御系统，协助侦测及堵截各种威胁，例如暴力破解密码攻击。
-   由Odoo 12.0开始，客户数据库管理员甚至可以选择[为登录速度设置限制](https://github.com/odoo/odoo/blob/326a44c3f7f754160c78649f7c6c69dc0c030d92/odoo/addons/base/models/ir_config_parameter.py#L23-L24)，及设定尝试重复登录之间的冷却时间。

#  Odoo

## 软件安全

Odoo 是开放源码（open-source）软件，所以整套代码编码库会持续受到全球 Odoo 用户及贡献者检查。 因此，社群回报的错误是收集保安相关回应的其中一个重要来源。 我们鼓励开发人员审核代码，并报告安全问题。

Odoo 的研发工序有代码审查步骤，包括审视安全方面的表现，会审查新编写及社群贡献的代码。

## 特意设计为安全至上

Odoo 在设计上，能够防止系统引入最常见的安全漏洞：

-   使用较高级别的应用程序接口（API），无需执行手动 SQL 查询，以防止 SQL 注入攻击。
-   使用高阶模板系统，自动转义外界输入的数据，以防止跨网站指令码（XSS）攻击。
-   系统架构防止以远程程序调用（RPC）访问私用方法，从而更难引入可利用的漏洞。

请亦参阅以下 [OWASP 最需要关注漏洞](https://www.odoo.com/zh_TW/security#owasp) 章节，了解 Odoo 从开始设计时，如何在设计上防止这些漏洞出现。

## 独立安全性审计

Odoo 受客户及潜在客户聘请的独立公司定期审计，以评核表现及进行渗透测试。 Odoo 安全团队会收到相关结果，并会在必要时采取适当的纠正措施。

但是，我们不能透露这些结果的任何部份，因为结果属机密资料及由委任测试的人所拥有。 所以，请不要问了 ;-）

Odoo 还有一个非常活跃的安全研究社区，由独立的研究人员组成，他们持续监控代码并与我们一起改进和加强 Odoo 的安全性。 有关我们的安全计划详情，请参阅我们的[尽责披露](https://www.odoo.com/page/responsible-disclosure)页面。

## OWASP 最需要关注漏洞

下文交代Odoo在网络应用程序的首要安全问题上，所采取的立场和处理手法。 这些安全问题是根据[开放网络应用程序安全计划（Open Web Application Security Project）](https://www.owasp.org/index.php/Main_Page) （简称 OWASP）所列举的：

-   **注入漏洞**：注入漏洞，尤其是 SQL 注入，在网络应用程序中很常见。 若把用户提供的数据，作为命令或查询那样发送到解释器，就会出现注入。 攻击者提供恶意资料，哄骗直译器执行未预期的指令，或窜改数据。
    
    Odoo 使用对象关联对应（object relational mapping，ORM）架构，将组建查询字句的过程抽象化，在设计上防止 SQL 注入出现。 开发人员通常不用靠人手编写SQL查询字句，字句会由ORM产生，当中的参数一定会经过适当转义。
    
-   **跨网站指令码（XSS）**：每当应用程序将用户提供的数据发送至网络浏览器，但未有先验证或将内容编码时，就会出现XSS漏洞。 XSS 让攻击者可以在受害者的浏览器中执行指令码，足以用作骑劫操作时段、将网站改头换面，甚至可能引入蠕虫等。
    
    Odoo 架构下，所有会以检视画面或网页形式呈现的表达式代码，默认都会经过转义，防止 XSS 攻击。 开发人员须特别将表达式标记为「安全」，才可将源代码放入呈现的页面内。
    
-   **跨网站请求伪造（CSRF）**：CSRF攻击是利用已登录的受害者，逼使其浏览器向有安全漏洞的网络应用程式，发送伪造的 HTTP 请求，包括受害者的操作时段 cookie 及任何其他自动包含在请求内的身份验证信息。 这允许攻击者强制受害者的浏览器产生请求，诱骗有安全漏洞的应用程序以为是来自受害者的正当请求。
    
    Odoo 的网站引擎包含内置 CSRF 保护机制，可防止任何 HTTP 控制器接收没有相应安全代码的 POST 请求。 此做法是目前推荐的 CSRF 预防技巧。 安全代码只会在用户真正到访相关网站表单时，才会存在及可被得知; 没有安全代码时，攻击者无法伪造请求。
    
-   **恶意执行档案**：易受远程档案包含（remote file inclusion，RFI）影响的代码，允许攻击者植入恶意代码及数据，可导致毁灭性攻击，例如服务器全面受损。
    
    Odoo 本身功能不开放作执行远程档案包含。 不过，系统允许特权用户通过加入自定义表达式，以自定义新功能。 这些表达式将通过系统评估，并只会在已净化及作沙盒处理、仅能访问已获批准功能的安全环境中进行评估。
    
-   **不安全地直接引用对象**：当开发人员将指向内部实施对象（例如档案、目录、数据库记项、密钥等）的引用参照，作为 URL 网址或表单参数公开时，便属直接引用对象。 攻击者可以操纵这些引用参照，在未经授权的情况下存取其他对象。
    
    Odoo 并非在用户界面层面执行访问控制，因此不会出现 URL 网址泄露内部对象引用参照的风险。 攻击者无法透过操纵引用参照来绕过存取控制层，因为每个请求仍必须通过数据存取验证层。
    
-   **不安全的加密存储**：网络应用程序很少能妥当运用加密功能去保护数据和凭证。 攻击者会利用保护薄弱的资料，盗用身份及作其他犯罪用途，例如信用卡欺诈。
    
    Odoo 使用行业标准的用户密码安全哈希（默认是PKFDB2+SHA-512，并采用密钥延伸）以保护存储的密码。 系统也可使用外部身份验证系统，例如 OAuth 2.0 或 LDAP 等，以完全避免本地存储用户密码。
    
-   **不安全的通讯**：当需要保护敏感通讯时，应用程序往往未能对网络流量进行加密。
    
    Odoo 云服务默认使用 HTTPS 运行。 对于离线安装版本，建议采用诸如Apache、Lighttpd或Nginx 等的网络服务器运行 Odoo，利用服务器加密及代理对 Odoo 发出的请求。 Odoo 的安装及推行指南包括一份 [安全检查清单](https://www.odoo.com/documentation/14.0/administration/install/deploy.html#security)，让公众进行较安全的安装。
    
-   **未能限制 URL 网址存取**：为保护敏感功能，应用程序通常只会禁止向未经授权用户显示相关链接或 URL 网址，但攻击者仍然可以利用此弱点，直接访问这些 URL 网址，以访问及执行未经授权操作。
    
    Odoo 并非在用户界面层面执行访问控制，系统安全不用依赖隐藏特殊 URL 网址。 攻击者无法通过重用或操纵任何 URL 网址来绕过访问控制层，因为每个请求仍必须通过数据访问验证层。  
      
    在极少数 URL 网址可让未经身份验证的用户访问敏感数据的情况下，例如客户用来确认订单的特殊 URL 网址，所用的 URL 网址会使用独一无二的代码进行数码签署，并只会通过电子邮件发送给预期收件人。

## 报告安全漏洞

若要报告安全漏洞，请前往我们的[尽责披露页面](https://www.odoo.com/zh_TW/security-report)。 该处报告的漏洞会获较高级优先处理，Odoo安全团队会与报告人合作，立即进行评估及解决问题， 然后以负责任的方式向Odoo客户及用户披露。