遠端連線工具在企業 IT 與 MSP 日常中無所不在，但多數商用方案的連線中繼、帳號與稽核紀錄都放在廠商雲端。若客戶屬於上市櫃公司或受 ITGC 稽核範圍，遠端維護作業往往需要回答三個問題。誰在什麼時間連進哪台機器、做了什麼、證據放在哪裡。CyberQ 實作示範以 RustDesk 開源版 Server 部署在 QNAP NAS 的 Container Station 上，再把客戶端側錄功能與 NAS 的儲存機制串起來，建立一套可稽核的遠端維護作業流程。
一、為什麼要自建 RustDesk Server
RustDesk 分為兩個部分。用戶端完全開源，伺服器端則有免費的開源版（RustDesk Server OSS）與付費的 Pro 版兩種選擇。開源版採 AGPL-3.0 授權，本身不收費，但公網 IP、網域、頻寬、備份與維運成本仍由自建者承擔。
自建的好處在於連線中繼與中介資料完全留在自己的基礎設施內，不需經過 RustDesk 官方公共伺服器。對需要證明「資料未流出組織邊界」的單位而言，這一點在稽核時特別有用。
至於為何選擇 QNAP NAS 作為承載平台，理由很務實。多數中小企業與 MSP 客戶現場本來就有一台 NAS 常駐運作，Container Station 可直接跑 Docker Compose，而側錄檔案又天生需要大量、可快照、可異地備份的儲存空間，NAS 剛好一次滿足。
二、RustDesk Server 架構與連接埠
RustDesk Server 由兩個服務組成 。
hbbs 為 ID 註冊與訊號伺服器（rendezvous / signaling），監聽 TCP 21115、21116、21118（WebSocket）以及 UDP 21116。TCP 21114 僅 Pro 版用於 HTTP API。
hbbr 為中繼伺服器（relay），監聽 TCP 21117 與 21119（WebSocket）。
連線流程如下。只要用戶端在執行，就會持續向 hbbs 回報自己目前的 IP 與連接埠。當電腦 A 要連線到電腦 B，A 先向 hbbs 提出請求，hbbs 嘗試以打洞（hole punching）方式讓 A 與 B 直接連線。打洞失敗時，流量才會改走 hbbr 中繼。官方說明多數情況下打洞會成功，中繼伺服器並不會被用到 。
實務上要開放的最小連接埠集合為 TCP 21115 到 21117 與 UDP 21116。若不使用網頁版用戶端，官方明確建議 21118 與 21119 保持關閉。
三、QNAP 端前置準備
3.1 安裝 Container Station
從 App Center 安裝 Container Station。本文以 QuTS hero 6.0.2 為基準，QTS 5.x操作方式相同。
3.2 建立資料目錄
在 File Station 建立共享資料夾，例如 /share/Container/rustdesk-data。hbbs 首次啟動時會在這個目錄產生金鑰對與資料庫，包含以下檔案。
id_ed25519 為私鑰
id_ed25519.pub 為公鑰，需要分發給所有用戶端
db_v2.sqlite3 為自動產生的資料庫
blacklist.txt 與 blocklist.txt 為封鎖名單
私鑰檔案權限應維持 600，這組金鑰一旦遺失，所有用戶端都必須重新設定，因此務必納入備份範圍。
3.3 網路模式的選擇
RustDesk 官方文件建議 Linux 環境使用 network_mode: host，理由是 hbbs 與 hbbr 需要看到用戶端真實的來源 IP，而非 Docker 內部的橋接位址。若改用連接埠映射（-p）模式，官方明確指出 P2P 直連將無法運作，所有流量都會被迫走 hbbr 中繼，NAS 的上傳頻寬會成為瓶頸。
QNAP 的 Container Station 支援 host 網路模式，社群也有在 QNAP 上以 --network host 成功部署的案例。但要注意 host 模式下容器會直接佔用 NAS 主機的連接埠，部署前請確認 21115 到 21119 未被其他服務使用。
四、以 Docker Compose 部署
在 Container Station 的「應用程式」（Applications）功能中建立新應用程式，貼上以下 Compose 內容。這份設定以官方範例為基礎 ，並針對合規需求做了三處調整。
services:
hbbs:
container_name: rustdesk-hbbs
image: rustdesk/rustdesk-server:1.1.15
command: hbbs -k _
environment:
- ALWAYS_USE_RELAY=N
volumes:
- /share/Container/rustdesk-data:/root
network_mode: "host"
depends_on:
- hbbr
restart: unless-stopped
hbbr:
container_name: rustdesk-hbbr
image: rustdesk/rustdesk-server:1.1.15
command: hbbr -k _
volumes:
- /share/Container/rustdesk-data:/root
network_mode: "host"
restart: unless-stopped三處調整說明如下。
固定映像檔版本。 官方範例使用 latest 標籤，但為了確保容器重建時不會無聲升級到新版本，建議釘選特定版本並主動追蹤 release 頁面 。
強制金鑰驗證。 -k _ 參數要求用戶端必須持有正確公鑰才能連上伺服器，未帶金鑰的用戶端會被拒絕。這是防止陌生用戶端註冊到自家 ID Server 的第一道門檻 [9]。
中繼策略。 ALWAYS_USE_RELAY=Y 會強制所有流量走中繼。這麼做可以確保所有連線都經過 NAS，方便在 NAS 端做流量監控，代價是頻寬消耗全部落在 NAS。本文預設 N，若合規需求要求「所有連線必須經過組織控管的中繼點」，可改為 Y。
部署完成後，在 Container Station 查看 hbbs 的紀錄，應該會看到類似以下輸出，其中的 Key 即為要分發給用戶端的公鑰。
hbbs | Key: <BASE64_PUBLIC_KEY>
hbbs | Listening on tcp/udp :21116, tcp :21115/21118
hbbr | Listening on tcp :21117/21119若 ARM 架構的 QNAP 機種需使用 rustdesk/rustdesk-server:latest-arm64v8 映像檔。
五、防火牆與對外曝露
在 NAS 前端的防火牆或路由器上，只開放 TCP 21115 到 21117 與 UDP 21116。
若日後需要網頁版用戶端而必須開啟 21118 與 21119，官方文件有一項重要安全警告需要留意。hbbs 與 hbbr 在 WebSocket 模式下會信任 X-Real-IP 與 X-Forwarded-For 標頭來判定用戶端真實 IP，而且不做驗證。任何能直接連到 21118 或 21119 的人都可以偽造標頭，繞過以 IP 為基礎的速率限制與封鎖，並偽造紀錄中的來源 IP 。RustDesk 官方建議的做法是 WebSocket 連接埠只透過會自行設定 X-Real-IP 的反向代理對外，並以防火牆限制只有反向代理能連到這兩個連接埠。
對於側錄合規情境，紀錄中的來源 IP 是稽核證據的一部分，這項風險直接影響證據的可信度。若沒有明確需求，維持 21118 與 21119 關閉是最省事的選擇。
六、用戶端設定
在用戶端的「設定」中找到 ID / 中繼伺服器選項，填入以下內容。
ID Server 填 NAS 的對外網域或 IP
Relay Server 可留空，會自動使用相同主機的 21117
Key 填 id_ed25519.pub 的內容
設定完成後，用戶端底部狀態應顯示綠燈與「就緒」（ready）。
Windows 環境可以把設定內建在安裝檔中批次部署，方式是將安裝檔重新命名為包含伺服器參數的檔名，這對 MSP 一次要佈署數十台端點特別方便，具體命名格式請參考 RustDesk 官方文件。
七、畫面側錄：功能現況與限制
這是本文的核心，也是最需要釐清讀者期待的段落。
7.1 側錄發生在用戶端，不在伺服器
RustDesk 的畫面側錄是用戶端功能，錄影檔存在用戶端本機。官方 Pro 版討論區有一則功能請求明確指出，目前錄影檔只儲存在發起連線的一方。伺服器端（無論 OSS 或 Pro）並不會集中保存錄影。這表示側錄檔案要進 NAS，必須靠用戶端設定加上檔案同步機制，而不是伺服器自動收集。
7.2 可用的自動側錄選項
根據 RustDesk 官方進階設定文件，用戶端提供以下與側錄相關的設定。
自動錄製連入工作階段（Automatically record incoming sessions）
自動錄製連出工作階段（Automatically record outgoing sessions）
隱藏遠端工作階段中控制端的錄影按鈕。文件特別說明這不會停用錄影，若已開啟自動連出錄影，工作階段仍會被錄製，只是使用者無法從工具列停止
錄影儲存目錄（video-save-directory），路徑必須為絕對路徑，空值或相對路徑會被忽略並改用預設目錄
Windows 服務模式下的受控端錄影目錄（windows-service-video-save-directory），用於以已安裝的 Windows 服務執行的受控端錄影
預設儲存位置在 Windows 為 %USERPROFILE%\Videos\RustDesk，Linux 為 ~/Videos/RustDesk。
「隱藏錄影按鈕但持續錄製」這個組合對合規場景很關鍵。它讓維護人員無法在操作過程中關掉側錄，符合「側錄不可由被稽核者自行中止」的控制要求。
7.3 該在哪一端錄
以 MSP 維護客戶機器的情境來說，有兩種選擇。
在控制端（工程師電腦）錄
開啟「自動錄製連出工作階段」並隱藏錄影按鈕。優點是設定集中在工程師端，容易管理。缺點是錄影檔存在工程師的電腦上，證據的產生與保管落在同一個人手中，稽核上會被質疑獨立性。
在受控端（客戶機器）錄
開啟「自動錄製連入工作階段」，並把儲存目錄指向客戶端可存取的 NAS 共享資料夾。優點是證據由被維護的一方產生，工程師無法竄改。缺點是要在每台受控端做設定，且需要處理 Windows 服務模式下的儲存目錄設定。
從稽核角度，受控端錄製加上 NAS 集中保存是比較站得住腳的做法。若條件允許，兩端同時錄製可以互相比對，但要注意儲存用量會加倍。
7.4 檔案格式與儲存估算
RustDesk 側錄的儲存用量與畫面解析度、位元率、工作階段長度直接相關，建議先在測試環境錄製一小時，實際量測後再推算保存期限對應的容量需求。
八、把側錄檔案送進 QNAP NAS
側錄檔案存在用戶端後，需要一套機制把它們集中到 NAS，並確保進入 NAS 後不被竄改。以下是搭配 QNAP 內建功能的建議做法。
8.1 集中收集
受控端若與 NAS 在同一內網，可將錄影目錄直接設為 SMB 掛載的 NAS 共享資料夾，錄影完成即落地
受控端在遠端時，可透過 Qsync 用戶端將本機錄影目錄同步到 NAS
也可以用排程指令碼（Windows 工作排程器加 robocopy）定時推送
無論採用哪種方式，都要注意錄影目錄不應該讓一般使用者帳號有刪除權限。
8.2 保護證據完整性
為側錄共享資料夾設定快照排程，快照本身只有管理員可以刪除
若 NAS 機種支援 WORM（一次寫入多次讀取）共享資料夾，可考慮把側錄目錄設為 WORM 以防止任何人修改或提前刪除。
以 HBS 3 排程把側錄資料夾異地備份到另一台 NAS 或物件儲存
側錄資料夾的存取權限採最小授權，只有稽核與資安角色能讀取，維護工程師本人不應有讀取權限
8.3 保存期限
保存期限沒有放諸四海皆準的數字，要看客戶所屬產業的法規與內部政策，在 ISO 的實務中，常見的態樣是保存個半年要有。建議在部署前就與客戶的稽核單位確認期限，並把自動刪除規則寫進快照與備份政策，避免「永久保存」變成儲存空間與個資風險的雙重負擔。
九、連線稽核紀錄：OSS 版與 Pro 版的落差
側錄畫面回答「做了什麼」，但「誰在什麼時間連進哪台機器」需要靠連線紀錄。這裡是 OSS 版與 Pro 版差異最大的地方。
Pro 版的網頁主控台提供完整的稽核紀錄功能，包含遠端連線、檔案傳輸、管理操作與安全警示四類。連線紀錄的欄位包括連線類型（遠端桌面、檔案傳輸、連接埠轉送、檢視攝影機、終端機、未登入）、受控裝置 ID 與名稱、控制端使用者與裝置與 IP、開始與結束時間與持續時間、驗證方式（含二階段驗證資訊）。工程師也可以在工作階段中透過「備註」功能為該次連線加上說明，例如對應的工單編號。
OSS 版沒有內建的稽核主控台與保存期限管理功能，OSS 自建版缺乏企業級稽核介面，側錄與可供 SIEM 使用的證據包也比商用方案單薄。
值得注意的是 2026 年 7 月發布的用戶端 1.4.9 版本新增了「回報控制端使用者」的能力。受控端現在可以告訴伺服器是誰在控制它，伺服器再將控制端使用者 ID、連線起訖時間、檔案傳輸等資訊寫入紀錄。這項功能需要伺服器與受控端同時更新到新版，控制端則不需要。
因此對 OSS 使用者來說，一個務實的替代方案是在 NAS 端用 Docker 的日誌功能把 hbbs 與 hbbr 的容器輸出導出到檔案，再以 QNAP 的 QuLog Center 或外部 syslog 集中保存。這能取得連線事件的時間與 IP，但無法達到 Pro 版的欄位完整度。若客戶的稽核要求明確需要「使用者身分」層級的連線紀錄，Pro 版授權會是比較直接的解法。
十、合規對應參考
以下以 ISO 27001:2022 附錄 A 控制措施為例，說明本文各項設定對應的控制目標。控制編號以 2022 版為準，具體適用範圍請依客戶的適用性聲明（SoA）判斷。
| 控制措施 | 本文對應做法 |
|---|---|
| A.5.15 存取控制 | 伺服器強制金鑰驗證，只有持有公鑰的用戶端能註冊 |
| A.8.5 安全驗證 | 用戶端啟用密碼與二階段驗證（Pro 版可集中管理） |
| A.8.15 日誌記錄 | 受控端自動側錄，容器日誌導出至 NAS 集中保存 |
| A.8.16 監控活動 | ALWAYS_USE_RELAY=Y 時所有流量經過 NAS 可供監控 |
| A.8.13 資訊備份 | 側錄資料夾快照與 HBS 3 異地備份 |
| A.5.37 文件化作業程序 | 遠端維護 SOP 明訂側錄範圍、保存期限與存取權限 |
ITGC 稽核情境下，遠端維護通常歸在「程式變更」與「電腦作業」兩個領域的存取控制項目，側錄與連線紀錄就是回應「特權存取是否被監督」的證據。
十一、個資與告知義務
畫面側錄必然會錄到受控端螢幕上的內容，其中可能包含客戶的個人資料。部署前有幾件事要處理。
與客戶簽訂的維護合約或作業規範中應明確載明側錄的目的、範圍、保存期限與存取對象
受控端使用者應在連線前被告知該次工作階段將被錄製，可利用 RustDesk 連線時的確認對話框或客戶內部公告達成
側錄檔案本身就是個資檔案，應納入客戶的個資盤點與風險評估範圍
以上是 CyberQ 針對一般性資安的實務建議，若涉及個人資料保護法的具體適用與告知格式，不同公司與客戶方面，需要再諮詢個別法務或個資保護專責人員確認。
十二、維運注意事項
金鑰對（id_ed25519 與 id_ed25519.pub）務必納入備份，且備份位置的存取權限要比側錄資料夾更嚴格
伺服器版本更新採手動釘選，每次更新前先閱讀 release note，並先在測試環境驗證用戶端相容性
定期檢視 blacklist.txt 與 blocklist.txt，將異常來源加入封鎖
每季抽查側錄檔案是否確實產生、能否正常播放、快照與異地備份是否完整。缺少抽查的側錄機制在稽核時等同不存在
延伸閱讀
RustDesk 官方文件，Self-host 總覽。https://rustdesk.com/docs/en/self-host/
The IT Guys，How to Install a Self-Hosted RustDesk Server on Debian with Docker，2026 年 8 月。https://theitguysfix.com/2026/08/17/self-host-rustdesk-server-debian-docker-step-by-step/
RustDesk 官方文件，Docker 部署。https://rustdesk.com/docs/en/self-host/rustdesk-server-oss/docker/
