重奪資料主權：Nextcloud 企業私有雲演講

Jason Cheng 發布 2026.10.31 瀏覽 29 次

Graylog Nextcloud OxOffice Wazuh 協同編輯密碼管理系統管理網路硬碟資訊安全企業應用開源軟體

本文目錄

議程資訊
既有檔案伺服器的過渡架構
SMB 存取身分的取捨
文件協作的分工
資安機制與部署模式
PHP2Shell 的啟示
更新週期與備份
實際遇到的取捨
AI 文件問答的限制
結論
參考資料

2026/10/31 我在 ISC2 Taipei Chapter 的「共益資安共榮台灣」資訊安全研討會，分享 Nextcloud 打造企業私有雲的經驗。企業常見的矛盾是員工要方便，公司要掌控：外出要能拿檔案、要一起改文件、要交付給客戶，同時又希望資料留在公司、分享可以撤銷、誰改了什麼查得到。

現實的限制是沒有預算換系統，既有的檔案伺服器也不能停。這場我用社群版加上 Apps 與周邊工具，說明怎麼組合、可以做到哪裡，以及哪些事它做不到。

這篇不逐頁轉寫 70 頁簡報，只整理我認為最值得帶走的部分，完整內容請看文末的簡報連結。

議程資訊

項目	內容
活動	ISC2 Taipei Chapter 2026 年第三屆第一次會員大會暨「共益資安共榮台灣」資訊安全研討會
主辦	台灣國際認證資安專家協會
時間	2026/10/31 10:30～11:10
地點	臺大醫院國際會議中心
題目	重奪資料主權：Nextcloud 打造安全可控的企業私有雲經驗分享
簡報	slide.jason.tools/nextcloud-isc2-20261031
活動頁	isc2taipei.kktix.cc/events/2026agm

既有檔案伺服器的過渡架構

多數企業的起點是一台用了很多年的 Windows 檔案伺服器：資料、AD 權限、直接讀寫共用資料夾的舊系統，還有大家習慣的網路磁碟機。IT 最怕的就是要換系統，工作又不能停。

我的做法是不要求先搬完資料，而是先在前面加一個 Web 入口：瀏覽器連 Nextcloud，Nextcloud 再用外部儲存（External storage）連到原本的檔案伺服器。資料留在原位，過渡期仍需直連的舊系統也不用動，之後再逐步縮小直連 SMB 的範圍。

這樣改善的是存取方式：單一 HTTPS 入口可以放在 VPN、WAF、雙因素驗證後面；分享有期限、密碼；活動記錄可以集中；版本與垃圾桶在保留期限內可以救回誤改的檔案。

注意，這個效果要到目標狀態才完整：使用者不再掛接網路磁碟機，只有 Nextcloud 主機與核准的舊系統能連 SMB。只加在前面、直連還開著，等於多一個入口。它也不能防勒索，同步端被加密的檔案一樣會同步上來，要有乾淨的版本才救得回，經 SMB 直接覆寫或刪除的檔案也不能指望 Nextcloud 的版本。

過渡期還要留意雙邊寫入。Nextcloud 的檔案索引要掃描才會更新，直接在 SMB 上重新命名會被視為刪除加新增，舊項目的分享、標籤與活動記錄都會消失。官方建議重新命名都透過 Nextcloud 進行。SMB 另有變更通知（update notifications）可以處理，但要持續執行 occ files_external:notify、需要 smbclient 執行檔，官方也寫明只有 Windows SMB 伺服器才可靠，且不支援「save in session」。同一個檔案也要避免同時從兩個入口編輯，驗收時要把這些情境測過。

同樣的做法也適用於不能廢除的 FTP：Nextcloud 接到 FTP，使用者改由瀏覽器或手機取檔，FTP 只留在內網給設備與舊系統使用。FTP 本身不加密，內網這段也建議改用 FTPS。

SMB 存取身分的取捨

這是導入時最容易講錯的地方。要分開看三層：Nextcloud 的登入身分、Nextcloud 連 SMB 用的身分、檔案伺服器上的共用權限與 NTFS 權限。接上 AD 只解決第一層，不代表 SMB 會自動沿用同一個人的身分。

官方文件列出的限制很明確：

Log-in credentials, save in session
依賴登入工作階段提供憑證，所以無法分享、無法背景掃描與清理版本，用權杖驗證的桌面與行動用戶端也存取不到；Collabora Online 這類另外取檔的編輯服務開不了，也不能與 SAML/SSO 併用
個別使用者憑證
Nextcloud 無法跨連線辨識檔案鎖定，使用者無法在上面協作編輯
Global credentials
外部儲存要協作時，官方指定用這一種。所有使用者共用同一組連線，權限要在 Nextcloud 這一層重新設計，不能說後端還是逐人套用原本的 ACL

所以「每個人沿用原本的 NTFS 權限」和「所有資料都能多人共編」無法無條件同時成立。可行的分法是既有檔案維持個別權限存取，需要共編的專案改放 Nextcloud 管理的空間，或用共用帳號的外部儲存。

上線前我建議用可編輯、唯讀、不可存取三種測試身分，分別從 Web 與原本的 SMB 驗證讀取、修改、刪除，不要只看設定畫面。

文件協作的分工

Nextcloud 本身不編輯 Office 文件，要接一套線上 Office。分工是 Nextcloud 管檔案入口、授權、分享與版本，編輯器負責開啟、編輯與共編。

可以自建的有 OxOffice Online、Collabora Online、ONLYOFFICE Docs、Euro-Office、Thinkfree Office，以及微軟的 Office Online Server。不過微軟已宣布 Office Online Server 於 2026/12/31 終止支援，現在不建議當成新的長期方案。

只有雲端的方案則要留意：Google 的整合只能匯入檔案，無法在 Nextcloud 上共編；Microsoft 365 網頁版目前只看到 Sendent 的商業整合，限符合資格的託管服務商，編輯時工作副本由微軟處理，不屬於資料留在地端的做法。

我這場用的是台灣原廠的 OxOffice Online，透過 Nextcloud Office (Collabora) 這個 App（App ID 是 richdocuments）整合。App 商店目前另有一個名稱就叫 Nextcloud Office 的 eurooffice，安裝時不要裝錯。簡報的示範畫面接的是原廠展示站，正式環境要另外部署。Office 格式也不能承諾完全一致，導入前請用公司實際的文件測試。

資安機制與部署模式

內建或可加裝的機制不少，只要逐項設定就有明顯效果：

登入
接 AD/LDAP、強制雙因素驗證（可限定群組）、可疑登入提醒
密碼政策
複雜度、到期、失敗鎖定；外洩比對使用 Have I Been Pwned，只送雜湊的前 5 碼。到期只適用本機帳號，AD 帳號的密碼政策仍在 AD 端設定；失敗鎖定是直接停用帳號，不會自動解鎖
暴力嘗試防護
預設開啟；反向代理後面要設好 trusted_proxies 與 forwarded_for_headers，否則記到的都是代理的位址；設錯還可能讓用戶端偽造來源 IP
分享設定
強制連結密碼與到期日、限制可分享的群組與帳號搜尋範圍
條件存取
File access control 依群組、來源 IP、檔案標籤阻擋存取
上傳掃毒
Antivirus for files 接 ClamAV 或支援 ICAP 的引擎；直接寫入 SMB 的檔案不會經過這一關

加密常被混為一談。傳輸加密、磁碟加密、Nextcloud 伺服器端加密、端對端加密各自只蓋住資料路徑上的某幾段，不能互相取代。

架構上我整理了四種部署模式，差別在入口與信任邊界，要依對象與風險選擇：

模式	做法	代價
只走 VPN	Nextcloud 不對外開放，外出先連 VPN	客戶與合作夥伴連不到，要給外部的檔案另設對外站
兩站聯盟	內站放公司文件，給客戶的檔案實體放外站，由外站以聯盟分享給內站同仁	聯盟端點也是對外入口；兩站的帳號與記錄各自管理
集團多公司聯盟	各公司接自己的 AD，互加信任站台並交換使用者目錄	同上；查得到的是對方 Nextcloud 提供的目錄，不是整個 AD
兩站獨立	兩站不聯盟、不共用帳號，中間不留連線	檔案要手動搬，帳號、記錄、更新與備份都是兩份

聯盟端點的風險不是假設。2026/10/27 公告的 CVE-2026-77167（CVSS 3.1 評分 7.5）就是不用登入、經由聯盟分享端點寫入資料造成阻斷服務，暫時的處置是關閉接收聯盟分享。

只比較內外兩站的話，兩站獨立最保險，也最不方便。外站被打穿時沒有路通到內站的前提，是防火牆、管理通道與共用服務都確實隔離。

PHP2Shell 的啟示

這場我多加了最近的案例。2026/10/21 PHP 發佈 8.5.12、8.4.27、8.3.36、8.2.35，修補 CVE-2026-109618 與 CVE-2026-109619（外界稱 PHP2Shell），CVSS v4.0 都是 9.2，可以在不登入的情況下遠端執行程式。php.net 指出所有處理網頁請求的 PHP 都有風險，包含 PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeed，其中 mod_php 的風險最高。

簡報定稿後情勢又往前走：CISA 在 2026/10/26 把這兩個漏洞列入已知遭利用漏洞目錄（KEV）。PHP 8.1 以前沒有官方修補版本，安全團隊只為 7.4、8.0、8.1 提供原始碼層級的修補；php.net 也寫明緩解措施只能降低特定攻擊路徑的風險，更新才是完整的解法。10/23 官方另公布 CVE-2026-115560，只影響特定的 session 設定組合，建議在後續修補版本發佈前，先關閉 session upload progress，所以更新後這項設定仍要保留。

對 Nextcloud 管理者來說，重點是雙因素驗證、暴力嘗試防護、File access control 都管不到這一層。更新 Nextcloud 也不會更新 PHP，PHP 要跟著作業系統或映像檔另外更新。所以防護要假設每一層都可能被突破：

層	建議做法
防火牆	IPS（Suricata）、威脅情資封鎖清單、L7 應用控管
反向代理	依國家限制連入、正確還原真實來源位址、WAF 先記錄再轉阻擋
PHP	找出落後的主機（發行版可能回補修正，要對照套件的安全公告，不能只看版本號）、依官方建議關閉上傳進度並重新啟動 worker（php.ini 用 `session.upload_progress.enabled=0`，FPM pool 用 `php_admin_value[session.upload_progress.enabled]=0`）、定期檢查設定
Nextcloud	設定 `trusted_proxies`、啟用 `admin_audit` 並確認有寫入、強制雙因素驗證
主機	Wazuh 檔案完整性監控（FIM）盯程式碼，監控帳號與排程變更，新檔案比對惡意雜湊

萬一懷疑被打穿，先隔離主機並保全證據，確認入侵入口。接著從乾淨的管理環境更換資料庫、LDAP、SMB 服務帳號、寄信帳號與 API 金鑰，再用確認未受污染的備份與安裝來源重建，並修補入口。記錄集中到 Graylog、用 LibreNMS 監測服務狀態與憑證也是這一環，要留意 admin_audit 以 INFO 等級寫入，預設的 WARN 等級會把它濾掉，官方建議用 log.condition 處理；輸出預設是獨立的 audit.log，收集時不要只讀 nextcloud.log。

更新週期與備份

Nextcloud 每四個月一個大版，每個大版支援一年，期間每月出維護版，還在支援的各版同一天發佈。目前 33、34、35 的最新版是 2026/10/15 的 33.0.10、34.0.5、35.0.2，下一次排在 2026/11/12。

值得注意的是修補與公告的順序。前面提到的 CVE-2026-77167，2026/07/23 的 34.0.2、33.0.7、32.0.13 就修好了，安全公告到 10/27 才發佈。這個案例中，每月更新的人公告時早已修補完成；落後幾個月的人，公告一出等於攻擊方向被公開。官方沒有承諾修補一定早於公告，PHP2Shell 就是修補與公告同日。

備份不只是檔案，還有資料庫、設定、資料目錄、佈景主題、自訂 App 與外部儲存。這些要取自同一時間點，官方文件的做法是先進維護模式，但維護模式擋不住舊系統直接寫入 SMB，要另外協調。備份 Nextcloud 那一台也不會包含外部 SMB 的資料。

版本、垃圾桶與同步都不等於獨立備份。單一檔案誤刪、文件改錯，在保留期限內可以用垃圾桶與歷史版本救回，超出範圍或整台故障才用獨立備份；還原後要確認登入、檔案、權限、分享、Office 都正常，還原的備份若已過時，用戶端可能比伺服器新，官方建議評估執行 occ maintenance:data-fingerprint，避免遺失較新的資料。Proxmox Backup Server 的檔案層級備份可以參考我先前寫的〈PBS Client 備份主機與 VM、CT 內的檔案〉。

實際遇到的取捨

FIM 監控範圍

一開始容易想把整個 Nextcloud 目錄都交給 FIM。我的一台 Nextcloud 光是使用者檔案，就佔掉該主機 FIM 上限 200,000 筆中的 98,358 筆，將近一半的額度花在不是程式的檔案上。這個上限可以調整，Wazuh 預設是 100,000 筆。

後來的取捨是只盯 config、入口檔、程式碼與 PHP 設定，排除 data 目錄。另外 config 目錄不送內容差異，否則資料庫密碼會跟著差異送到 Wazuh Manager。相關規則整理在開源專案 jt-wazuh-mgr。

WAF 與大檔上傳

我用 ModSecurity v3 加 OWASP CRS 4（Paranoia Level 1）與 Nextcloud 排除規則實測。先只記錄一段時間再轉阻擋後，SQL 注入、XSS、指令注入、PHP-CGI 參數注入、上傳夾帶 PHP、Log4Shell、Shellshock、.env 與 .git 探測都有擋下，20 個正常請求全部通過，包含 WebDAV 與 200 MB 上傳。

代價在記憶體。ModSecurity 檢查時會把請求內容讀進記憶體，這次實測中一個 200 MB 的上傳讓 nginx worker 從 90 MB 漲到 473 MB，同時上傳的人數也要一起算。用戶端分塊上傳時單一請求較小，要依實際上傳方式量測。

記憶體真的不夠時，可以讓上傳路徑不經過 WAF，但例外要縮小到精確的路徑與方法，這些路徑也改靠 PHP 更新、請求大小限制、掃毒與後端偵測，這是要自己決定的取捨。

密碼管理工具的評估

我原本使用 KeeWeb，選它是因為直接相容 KeePass 的 .kdbx，和 KeePassXC 開的是同一個檔案，不用轉換。但上游從 2021 年後就沒有正式版，Nextcloud 上的 App 在 2026/10/13 標示為已棄用、專案封存，只支援到 Nextcloud 34，維護者也說明已知錯誤可能損毀 KDBX 4 資料庫。

所以我正在測試評估替代方案，考慮轉到 Passwords 或 KeePassNC，目前還沒有定案。

Passwords 不能直接開 .kdbx，要從 KeePassXC 匯出 CSV 再匯入，代價是失去同一個檔案兩邊通用的便利。依匯入程式的欄位對應，只會帶過群組、標題、帳號、密碼、網址、備註，TOTP、附件與歷史版本要另外處理，實際情況還要實測確認。CSV 是明文，匯入後請立刻刪除，也不要放在會同步的資料夾。

KeePassNC 是 KeeWeb 棄用後新出的 App，一樣直接開 .kdbx，只在瀏覽器解密，採 AGPL-3.0-or-later 授權。不過它 2026/10 才上架，搭配 SSO、雙因素登入與 Team Folders 的情境也還待驗證，驗證過才會決定是否用於正式環境。