CSA STAR 第1级别

Odoo 参与了云安全联盟（CSA）的安全、信任、保证和风险 (STAR) 计划。 查看我们对 CAIQv3.1 问卷的回答

— Odoo 云端版（该平台）—

备份/灾难修复

  • 我们为每个 Odoo 数据库保留 14 份完整备份，长达 3 个月： 每天备份 1 次，保留 7 天；每周备份 1 次，保留 4 周；每月备份 1 次，保留 3 个月。
  • 备份至少在2个大洲的 3 个数据中心进行复制保存。
  • 有关数据中心的实际位置，请参阅我们的 隐私政策.
  • 你还可以在任何时候使用控制面板下载实时数据的手动备份。
  • 您可以联系我们的服务台以在您的实时数据库来恢复这些备份（或在侧面）。
  • 硬件故障转移：对于裸机托管的服务，如果硬件出现故障，我们会实施本地热备复制，并持续监控，故障时手动转移程序，整个过程不超过 5 分钟。
  • 灾难恢复: 在完全灾难的情况下，一个数据中心在很长一段时间内完全瘫痪，无法故障切换到我们的本地热备（到目前为止从未发生过，这是最坏的情况下的计划），我们有以下目标。
    • RPO（恢复点目标）= 24 小时。这意味着，如果数据无法恢复，我们需要恢复最近的每日备份，您最多可能损失之前 24 小时的工作。
    • RTO（恢复时间目标）= 24 小时（付费订阅），48 小时（免费试用、教育优惠、免费用户等）。如果发送灾难、数据中心完全瘫痪，这是在其他数据中心恢复服务所需的时间。
    • 如何做到这一点：我们积极监控每日备份，并在不同大洲的多个地点进行复制。我们有自动配置功能，可以在新的托管地点执行我们的服务。复制前一天的备份恢复数据可在几小时内完成（对于最大的群组），优先考虑付费订阅。
      我们在日常操作中经常使用每日备份和配置程序码，因此灾难恢复程序的两个部分一直都在接受测试。

数据库安全

  • 客户数据存储在专用数据库中。客户之间不会共享数据。
  • 数据访问控制规则会在同一群组上运行的客户数据库之间完全隔离，用户无法从一个数据库访问另一个数据库。

密码安全

  • 客户密码采用行业标准的 PBKDF2+SHA512 加密算法（加盐 + 延伸数千轮）进行保护。
  • Odoo 工作人员无法访问您的密码，也无法为您找回密码，如果您丢失了密码，唯一的办法就是重新设置。
  • 登录凭证始终通过 HTTPS 安全传输。
  • 客户数据库管理员甚至可以选择为登录速率设置限制，及设定尝试重复登录的冷却时间。
  • 密码策略：数据库管理员进行内置设置，可以强制要求最小用户密码长度。 其他密码策略，如 要求字符类别 默认不支持，因为事实证实效果适得其反。 例如，参见 [[Shay et al. 2016]。]), 和 NIST SP 800-63b.

员工访问

  • Odoo 技术支持人员可能会登录您的账户，访问与您所提出的技术支持问题的相关设置。为此，他们会使用自己的特殊员工凭证登入，而不会使用您的密码（他们无从得知）。
  • 这种特殊的员工访问权限提高了效率和安全性：员工可以立即重现您所看到的问题，而您永远不需要共享您的密码，我们也可以单独审计和监控员工的行为！
  • 我们的技术支持工作人员会尽可能尊重您的隐私，只会访问诊断和解决问题所需的文件和设置。

系统安全

  • 所有 Odoo 云端服务器都运行经过强化的 Linux 发行版，并具有最新安全补丁。
  • 为了限制可能包含漏洞的服务数量（例如，系统没有采用 PHP/MySQL 堆栈），安装工作按需进行，并尽量采取最低限度安装。
  • 只有少数受信任的 Odoo 工程师才有远程管理服务器的权限，而且只能使用加密的个人 SSH 密钥对，从带有全盘加密功能的计算机进行访问。

实体安全

Odoo 云端服务器托管在全球各地获信赖的数据中心（如OVH、谷歌云端平台），它们都必须超过我们要求的物理安全标准：

  • 设立限制边界，仅允许经授权的数据中心员工进入。
  • 使用安全徽章或生物识别安全技术，进行物理访问控制。
  • 设立安全摄像头，全天候监控数据中心位置。
  • 派驻安保人员全天候值守。

信用卡安全

  • 我们不会在自己的系统中存储或保留信用卡信息。
  • 您的信用卡信息始终在您和我们之间安全地直接传输；符合 PCI 标准 支付收单方（请参阅我们的 隐私政策 页面）。

数据加密

客户数据始终以加密形式传输和存储（传输期间和完成传输的静止状态均会加密）。
  • 在客户端实际进行的所有数据通信，均采用最先进的 256 位 SSL 加密技术（HTTPS）保护。
  • 我们服务器之间的所有内部数据通信，也都采用最先进的加密技术（SSH）进行保护。
  • 我们的服务器受严格安全监控，并始终对最新的 SSL 漏洞进行修补，始终享有 A级 SSL 评级。
  • 我们的所有 SSL 证书均使用强大的 2048 位模数和完整的 SHA-2 证书链。
  • 所有客户数据（数据库内容和存储文件）在生产和备份时均已静态加密（AES-128 或 AES-256）。

网络防御

  • Odoo云端服务所使用的数据中心供应商，都拥有非常大的网络容量，其基础架构设计能够抵御最强的分布式拒绝服务（DDoS）攻击。他们的自动和手动缓解系统，在攻击流量有机会破坏服务可用性之前，已在多个大洲网络边缘检测并疏导攻击流量。
  • Odoo 云端服务器上的防火墙和入侵防御系统，有助于检测和阻止暴力破解密码攻击等威胁。
  • 客户数据库管理员甚至可以选择 为登录速率设置限制 ，及设定尝试重复登录的冷却时间。

— Odoo（该软件）—

软件安全

Odoo 是开放源代码软件，整个代码库会持续受到世界各地 Odoo 用户和贡献者的检查。因此，社区错误报告是安全反馈的一个重要来源。我们鼓励开发人员审核代码，并报告安全问题。

Odoo 研发流程有代码审查步骤，包括审查新代码和贡献代码安全方面的表现。

安全始于设计

Odoo 的设计可防止系统引入最常见的安全漏洞：

  • 通过使用高级应用程序接口（API），无需执行手动 SQL 查询，可防止 SQL 注入。
  • 通过使用自动转义注入数据的高级模板系统，可以防止XSS攻击。
  • 系统框架防止远程过程调用（RPC）访问私有方法，从而使引入可利用的漏洞变得更加困难。

另请参阅 OWASP 最需要关注漏洞 部分，了解 Odoo 如何从设计之初就防止此类漏洞出现。

独立安全性审计

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

不过，我们不能透露结果的任何内容，因为这些结果属于保密资料，由委任测试的人所拥有。请勿询问;-)

Odoo 还拥有一个非常活跃的独立安全研究人员社区，他们持续监控源代码，并与我们合作改进和加强 Odoo 的安全性。有关安全计划详情，请参阅我们的 责任信息披露 页。

OWASP 最需要关注漏洞

以下是 Odoo 在网络应用程序首要安全问题上的立场。这些立场是根据 开放式Web应用程序安全项目 （OWASP）所列出的：

  • 注入漏洞：注入漏洞，尤其是 SQL 注入，在网络应用程序中很常见。当用户提供的数据，作为命令或查询的一部分发送到解释器时，就会发生注入。攻击者提供恶意数据会诱使解释器执行非预期的命令或更改数据。

    Odoo 依赖于对象关系映射（ORM）框架，该框架可对查询构建抽象化，并在默认情况下防止 SQL 注入。开发人员通常不会手动创建 SQL 查询，而是由 ORM 生成，而且参数一定会经过适当转义。

  • 跨站脚本 (XSS)：当应用程序获取用户提供的数据并将其发送到网络浏览器时，如果没有事先对内容进行验证或编码，就会出现 XSS 漏洞。攻击者会在受害者的浏览器中执行脚本，从而劫持用户会话、恶意篡改网站、甚至植入蠕虫病毒等。

    Odoo 框架默认会转义所有呈现到视图和页面中的表达式，以防止 XSS 攻击。开发人员必须特别将表达式标记为"安全"，以便将原始程式码放入呈现的页面内。

  • 跨站请求伪造 (CSRF)： CSRF 攻击指盗用已登录的受害者身份，利用浏览器向网络应用程序发送伪造的 HTTP 请求，其中包括受害者的会话 cookie 和任何其他自动包含在请求内的身份验证信息。攻击者能迫使受害者的浏览器生成请求，而应用程序会误认为是来自受害者的合法请求。

    Odoo 网站引擎内置 CSRF 保护机制。它可防止任何 HTTP 控制器接收没有相应安全令牌的 POST 请求。此做法是目前推荐的防止 CSRF 预防技术。只有当用户真正访问相关网站表单时，安全令牌才会存在并被知晓，攻击者无法伪造没有安全令牌的请求。

  • 恶意文件执行： 易受远程文件包含（RFI）影响的代码，允许攻击者植入恶意代码和数据，从而导致破坏性攻击，如服务器完全崩溃。

    Odoo 不提供执行远程文件包含的功能。不过，系统允许特权用户通过添加自定义表达式来定制功能。这些表达式将由系统评估，并只会在已净化及作沙箱处理、仅能访问已获批准功能的安全环境中进行评估。

  • 不安全的直接对象引用：当开发人员将内部执行对象（如文件、目录、数据库记录或键）的引用，作为 URL 或表单参数公开时，就会发生直接对象引用。攻击者可以利用这些引用，在未经授权的情况下访问其他对象。

    Odoo 并非在用户界面层实现访问控制，因此不会有 URL 泄露内部对象的引用风险。攻击者无法通过操纵引用来规避访问控制层，因为每个请求都必须经过数据访问验证层。

  • 不安全的加密存储 ：网络应用程序很少正确使用加密功能来保护数据和凭证。攻击者利用保护薄弱的数据，盗用身份、进行犯罪活动，如信用卡欺诈。

    Odoo 使用行业标准的用户密码安全散列（默认为 PBKDF2 + SHA-512，并采用密钥延伸）来保护存储的密码。为了避免在本地存储用户密码，还可以使用 OAuth 2.0 或 LDAP 等外部验证系统。

  • 不安全的通信：当需要保护敏感通信时，应用程序往往未对网络流量进行加密。

    Odoo 云端服务默认使用 HTTPS 运行。对于离线安装版本，建议 采用例如 Apache、Lighttpd 或 nginx等的网络服务器运行Odoo，利用服务器加密及代理对Odoo发出的请求。 Odoo 的安装及推行指南包括一份 安全检查清单 ，以确保安装更安全。

  • 未能限制URL的访问:通常一个应用程序只通过防止向未经授权的用户显示链接或URL来保护敏感功能。攻击者可以利用这一弱点，通过直接访问这些URL来访问和执行未经授权的操作。

    Odoo 并非在用户界面层实现访问控制，系统安全性也不用依赖隐藏特殊 URL 网址。攻击者无法通过重复使用或操纵任何 URL 来规避访问控制层，因为每个请求仍必须经过数据访问验证层。在极少数情况下，URL 会提供未经验证的敏感数据访问权限，例如客户用于确认订单的特殊 URL，这些 URL 会使用独一无二的代码进行数字签名，并仅通过电子邮件发送给目标收件人。

报告安全漏洞

如果您需要报告安全漏洞，请访问我们的 责任信息披露页面. 将优先处理该类报告, Odoo 安全团队将与报告人合作，立即评估并解决问题， 然后以负责任的方式向 Odoo 客户和用户发布。