Odoo 安全性政策
你的資料安全對我們非常重要!這裡總結了我們為確保你的資料在 Odoo 是安全保管,而每天所做的工作,並且我們在寄存版本 Odoo 雲端版上應用了的最佳安全實踐。
• 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 et al. 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 客戶及使用者披露。