CSA STAR 第 1 級別

Odoo 參加了雲端安全聯盟（CSA）的安全、信任、保證及風險計劃（STAR）。
查看我們對 CAIQ 3.1 版本
問卷的回答

• Odoo 雲端版（該「平台」）

備份 / 災難修復

  • 我們為每個 Odoo 資料庫保存 14 個完整備份，最少 3 個月：每天 1 次的備份為期 7 天；每週 1 次的備份為期 4 週；每月 1 次的備份為期 3 個月。
  • 備份會至少複製至 2 個不同大洲內最少 3 個不同數據中心保存。
  • 有關數據中心的實際位置，請參閱我們的 私隱政策.
  • 你亦可隨時使用控制台，下載即時數據的手動備份。
  • 你可以聯絡我們的技術支援團隊，以在你的正式運行資料庫上（或分支）復原任何這些備份。
  • 硬件故障轉移：對於寄存在可能發生硬件故障的裸機 / 硬碟上的服務，我們會採取本地熱備份複製，並持續監控，故障時人手轉移過程需時少於 5 分鐘。
  • 災難修復：若發生嚴重災難、數據中心長時間完全停運，導致無法執行故障轉移至本地熱備份時（迄今為止從未發生過，這是最壞情況的計劃），我們有以下目標：
    • 恢復點目標（Recovery Point Objective，RPO）：24 小時。這意味著如果無法修復數據，你可能最多失去之前 24 小時的工作，而我們需要恢復你最近的每日備份。
    • 恢復時間目標（Recovery Time Objective，RTO）：付費訂戶 24 小時；免費試用客戶、教育優惠、免費增值用戶等 48 小時。如果發生災難並且數據中心完全停運，這是在另一數據中心恢復服務所需的時間。
    • 如何做到：我們緊密監控日常備份，並將它們複製到不同大洲的多個位置。我們有自動配置，以在新的寄存位置執行我們的服務。恢復前一天的備份數據可以在幾個小時內完成（對於最大的群組），付費訂戶資料優先處理。
      我們的例行日常運作會使用到每日備份及配置程式碼，因此這兩個有關災難修復程序的環節，都在經常測試。

資料庫安全

  • 客戶資料是儲存在專用資料庫的。客戶之間不會共享資料。
  • 資料存取控制規則會完全分隔在同一群組上運行的客戶資料庫，用戶不可能在一個資料庫中存取另一資料庫的數據。

密碼安全

  • 客戶密碼以行業標準加密保護，即 PBKDF2 + SHA512 加密（加鹽 + 延伸數千輪）。
  • Odoo 員工無法存取你的密碼，亦無法為你尋回 / 讀取密碼。如果你忘記或遺失密碼，唯一選擇是重設密碼。
  • 登入資料及憑證一定會透過 HTTPS 安全傳送。
  • 客戶資料庫管理員甚至可以選擇為登入速率設置限制，及設定嘗試重複登入之間的冷卻時間。
  • 密碼政策：資料庫管理員有一個內置設定，可強制要求使用者密碼達到一個最短長度。 預設情況下，不支援其他密碼政策（例如要求必須有特定字符種類），因為已證明它們會 適得其反。 參見例如 [Shay 等 2016]), 以及 NIST SP 800-63b.

員工存取

  • Odoo 技術支援人員可能會登入你的帳戶，以存取你所提出的技術支援問題的相關設置。他們會使用自己的特殊員工憑證登入，不會使用你的密碼（他們其實也無法知道）。
  • 這種特殊的員工存取權限能提高效率和安全性：員工可以立即重現你看到的問題，而你永遠不需要告訴他人你的密碼，我們亦可以單獨審計和監控員工的行為。
  • 我們的技術支援員工會盡可能尊重你的私隱，只會在診斷和解決你提出的問題所需要時，才會存取相關文件和設置。

系統安全

  • 所有 Odoo 雲端伺服器都以載有最新安全漏洞修補的強化版 Linux 發行版運行。
  • 安裝工作只在有需要時進行，並盡量採取最低限度安裝，以限制可能包含漏洞服務的數量（舉例，系統沒有採用 PHP/MySQL 堆疊）。
  • 只有少數受信任的 Odoo 工程師享有遙距管理伺服器的權限，而且只限當使用加密的個人 SSH 密鑰對，以及使用全硬碟加密的電腦時，才可進行存取。

實體安全

Odoo 雲端伺服器在世界不同地域獲信賴的數據中心寄存（例如 OVH、Google 雲端平台）。這些中心須達致或超過我們要求的最低物理安全標準：

  • 設立限制邊界，僅允許獲授權的數據中心員工進行物理存取（進出）。
  • 對物理存取採取管制措施，例如使用保安徽章或生物識別安全認證。
  • 設立保安監控鏡頭，全天候 24/7 監控數據中心位置。
  • 派駐保安人員全天候 24/7 看守現場。

信用卡安全

  • 我們不會在我們自己的系統上儲存或保留信用卡資料。
  • 你的信用卡資料必然透過安全途徑傳送，直接在你和我們所採用的符合 PCI 標準（付款卡行業標準）的付款服務商之間傳輸。（請參閱我們的 私隱政策 頁面所載列表）。

資料加密

客戶資料必定以加密形式傳輸和儲存（在傳輸期間和完成傳輸的靜止狀態均會加密）。
  • 與客戶端實體進行的所有數據通訊，都以先進的 256 位元 SSL 加密技術（HTTPS）保護。
  • 我們伺服器之間的所有內部數據通訊，亦是以先進的加密技術（SSH）保護。
  • 我們的伺服器受嚴格保安監管，並一直針對最新的 SSL 漏洞進行修補，時刻保持 A 級 SSL 評級。
  • 我們所有的 SSL 證書都使用強大的 2048 位元模數和完整的 SHA-2 證書鏈。
  • 所有客戶資料（資料庫內容及儲存的檔案），不論正式運行版本抑或備份，都會靜態加密（AES-128 或 AES-256）存放。

網絡防禦

  • Odoo 雲端服務所使用的數據中心供應商，全部都擁有非常大的網絡容量，而且他們的基礎架構設計能夠承受最猛烈的分散式阻斷服務（DDoS）攻擊。他們的自動及人手排解系統，在攻擊流量有機會干擾服務可用性之前，已能在分佈多個大洲的網絡的邊緣，偵測並疏導攻擊流量。
  • Odoo 雲端伺服器上的防火牆及入侵防禦系統，協助偵測及堵截各種威脅，例如暴力破解密碼攻擊。
  • 客戶資料庫管理員甚至可以選擇 為登入速率設置限制 ，及設定嘗試重複登入之間的冷卻時間。

• Odoo（該「軟件」）

軟件安全

Odoo 是開放源碼（open-source）軟件，所以整套程式碼編碼庫會持續受到全球 Odoo 用戶及貢獻者檢查。因此，社群回報的錯誤是收集保安相關回應的其中一個重要來源。我們鼓勵開發人員審核程式碼，並報告安全問題。

Odoo 的研發工序有程式碼審查步驟，包括審視安全方面的表現，會審查新編寫及社群貢獻的程式碼。

特意設計為安全至上

Odoo 在設計上，能夠防止系統引入最常見的安全漏洞：

  • 使用較高級別的應用程式介面（API），無需執行手動 SQL 查詢，以防止 SQL 注入攻擊。
  • 使用高階範本系統，自動轉義外界輸入的資料，以防止跨網站指令碼（XSS）攻擊。
  • 系統架構防止以遠端程序呼叫（RPC）存取私用方法，從而更難引入可利用的漏洞。

請亦參閱以下 OWASP 最需要關注漏洞 章節，了解 Odoo 從開始設計時，如何在設計上防止這些漏洞出現。

獨立安全性審計

Odoo 受客戶及潛在客戶聘請的獨立公司定期審計，以評核表現及進行滲透測試。Odoo 安全團隊會收到相關結果，並會在必要時採取適當的糾正措施。

但是，我們不能透露這些結果的任何部份，因為結果屬機密資料及由委任測試的人所擁有。所以，請不要問了 ;-)

Odoo 還有一個非常活躍的安全研究社群，由獨立的研究人員組成，他們持續監控程式源碼並與我們一起改進和加強 Odoo 的安全性。有關我們的安全計劃詳情，請參閱我們的 盡責披露 頁面。

OWASP 最需要關注漏洞

下文交代 Odoo 在網絡應用程式的首要安全問題上，所採取的立場和處理手法。這些安全問題是根據 開放網絡應用程式安全計劃（Open Web Application Security Project） （簡稱 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 使用行業標準的用戶密碼安全雜湊（預設是 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 客戶及使用者披露。