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 使用行业标准的用户密码安全散列(默认情况下为 PKFDB2 + 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 客户和用户发布。