VPS hosting 安全嗎？你真正能控制的風險

VPS hosting 安全嗎？簡短答案

是。VPS hosting 對大多數使用情境而言都很安全，而且相較於 shared hosting 確實有所改善。VPS（virtual private server）是一部擁有自身 kernel、memory、disk 和 user accounts 的 virtual machine，而執行該 virtual machine 的 hypervisor 會將其他客戶隔離在這四項資源之外。在同一部實體主機上租用鄰近 VPS 的使用者，無法讀取你的檔案、列出你的程序、登入你的伺服器或查看你的 network traffic。

坦白說，答案分成兩個部分。供應商負責硬體和 hypervisor。你負責 virtual machine 內的一切，而幾乎所有實際的安全事件都從這裡開始。伺服器通常是因為開放的埠、薄弱的 SSH 密碼、長期未更新的套件，或發布出去的檔案中含有 secret 而遭到入侵。透過 hypervisor 入侵的情況則極為少見。

虛擬機器監控程式實際隔離的內容

虛擬機器監控程式是在單一實體主機上執行虛擬機器的軟體。在 KVM VPS 上（KVM 代表 kernel based virtual machine，是 Linux 主機的標準方案），你的伺服器是完整的虛擬機器。它會啟動自己的 kernel。主機會配置固定的實體記憶體區域給它，而處理器的記憶體管理單元會拒絕任何超出該區域的存取。因此，其他 guest 中執行的程式碼完全無法存取你的 RAM。系統之間沒有共用檔案系統，也沒有共用使用者資料表，因此鄰近伺服器上的檔案權限對你的伺服器沒有任何作用。

共用主機的運作方式不同。許多網站位於同一個 operating system 中，使用同一個 web server 和同一個 PHP 安裝，並以一般使用者帳號執行。唯一的隔離邊界是檔案權限。因此，權限設定錯誤，或以可讀取過多資料的使用者身分執行的易受攻擊 plugin，都可能存取其他帳號的檔案。這就是 從共用主機移轉至 VPS 所能消除的隔離缺口。

請確認你購買的方案內容，因為並非所有標示為 VPS 的方案都是虛擬機器。以容器為基礎的方案（OpenVZ、LXC、Virtuozzo）會共用主機的 kernel，並使用 namespaces 和 cgroups 隔離客戶端，而不是使用硬體虛擬化。這種隔離邊界較弱，因為主機上的 kernel 漏洞也會成為你伺服器中的 kernel 漏洞。這類方案也無法載入 kernel modules，因此有些軟體無法使用。KVM 是較安全的預設選擇。付款前，請先確認你取得的是哪一種方案。

鄰居租戶可能對你造成的影響

與其他租戶共用實體主機會降低速度，除此之外不會造成其他影響。同一台主機上的客體會共用實體 CPU 與磁碟。當 CPU 忙於處理其他租戶的工作時，你的虛擬 CPU 會等待，而 Linux 會將這段等待回報為 steal time：也就是 %st 中的 top 與 vmstat 欄位。若 steal time 連續數小時高於幾個百分點，表示主機的資源配置超額。這不表示有人正在讀取你的資料。解決方式是改用其他方案或其他供應商；在決定前，你可以先測量實際取得的 CPU 與磁碟資源。

有一項跨租戶影響值得了解，但它不是安全漏洞。如果你從 VPS 寄送電子郵件，你的 IP 位址會位於其他租戶也使用的網段中。鄰居租戶若寄送垃圾郵件，可能導致該網段的一部分被列入封鎖清單，讓你的郵件因非你造成的原因而落入垃圾郵件資料夾。會積極處理濫用行為的供應商通常擁有信譽較好的網段。如果電子郵件對你很重要，請向供應商詢問這項資訊。

惡意鄰居無法做什麼，以及他們少數能做到的情況

同一台主機上的其他客戶無法存取你的檔案。他們看不到你的程序、無法掛載你的磁碟，也無法在你的伺服器上開啟 shell，因為這些項目都不存在於他們的虛擬機器中。只有一個例外值得特別說明：應將供應商的 private network 視為與陌生人共用的網路。不要假設其中的流量不可見，通過該網路傳送的資料都應加密。

Hypervisor escape 確實可能發生。虛擬化層的錯誤可能讓某個 guest 內的程式碼存取 host，接著從 host 存取其上的所有 guest。這類錯誤會被發現，並以 CVE（common vulnerabilities and exposures）識別碼公開及修補。託管供應商通常會迅速修補，因為其整個業務都建立在這個層面上。要利用這類錯誤，必須針對特定 hypervisor 版本取得可運作的 exploit。對小型託管帳戶而言，這是代價很高的攻擊方式。

跨 guest 的 side channel 也確實存在。Spectre 和 Meltdown 家族漏洞會利用共用的處理器快取，推測邊界另一側的少量資料。更新 microcode 與 kernel 可降低這些風險，而已發表研究中的洩漏速率非常低。已公開的案例屬於研究展示，不是大規模攻擊。風險並非為零，只是遠低於最可能造成損害的其他項目。

供應商的責任範圍與您的責任起點

供應商負責機房、主機硬體、hypervisor 與主機 kernel、實體網路，以及可啟動、停止、重建和建立 server snapshot 的控制面板。上述任何項目發生故障時，都應由供應商負責修復。

您負責作業系統以上的所有內容。這包括您安裝的套件、保持開放的連接埠、可登入的帳號與金鑰、套用的更新、備份，以及您自己的應用程式程式碼。大多數 VPS 方案都是 unmanaged，表示沒有人會替您修補 server，提交 support ticket 也不會有人代為處理。購買前值得先閱讀託管與非託管的區別，因為這會決定上述哪些責任落在您身上。

您負責的範圍中，有一項很容易被忽略：hosting 控制面板本身。持有該登入資訊的人，可以重建您的 server，或將您的磁碟連接至 rescue system，而不需要知道 server 內部的任何密碼。請在 hosting 帳戶啟用 two factor authentication (2FA)，並且不要在其他地方重複使用該密碼。

代管業者能看到你的資料嗎？

可以，原則上可以。這是 VPS 能提供的保障範圍，也是必須誠實面對的限制。你的磁碟映像檔存放在業者的儲存設備上。業者的主控台具備對虛擬機器的螢幕層級存取權限。救援模式可以在掛載你的磁碟後，啟動另一個系統。VPS 能防止其他客戶存取你的資料，但業者不在這項保障範圍內。

如果你持有必須讓主機業者無法讀取的資料，請在資料寫入前，先於應用程式中加密。Guest 內部的全磁碟加密，有助於防止靜態狀態下的磁碟映像檔遭複製；但伺服器執行期間，金鑰必須存放在記憶體中，因此仍無法排除業者的存取能力。你單獨租用的專用伺服器也具有相同的信任關係，只是少了一層共用環境。

實際上是什麼入侵 VPS

服務監聽所有網路介面。 資料庫、快取、訊息佇列與管理面板通常預設繫結至 0.0.0.0，這表示所有網路介面，包括公開介面。網際網路上的掃描持續且自動進行，因此新的 IP 位址上線後，幾分鐘內就會收到第一次未經請求的探測。未設定密碼的 Redis、未經驗證的 Elasticsearch 節點、在 port 2375 開放的 Docker API，以及仍使用預設登入資訊的管理面板，都會以這種方式被發現，掃描器甚至不知道你是誰。只有本機需要使用的服務，請繫結至 127.0.0.1，其餘流量則在防火牆封鎖。

Docker 繞過你的防火牆。 發布容器 port 時，會寫入網路位址轉譯（NAT）規則。這些規則的評估順序早於 ufw（uncomplicated firewall）的規則，因此即使 ufw status 顯示該 port 已拒絕，容器仍可能從網際網路連線。許多人其他設定都正確，卻會在這裡出錯。在發布容器 port 前，值得先閱讀 Docker port 忽略 ufw 的原因。

SSH 啟用密碼登入。 在任何公開伺服器上讀取 /var/log/auth.log，都會看到類似 Failed password for root from 203.0.113.10 port 54312 ssh2 的行，每天日夜都有數千筆。機器人會嘗試常見的使用者名稱與密碼。密碼登入加上允許 root 帳號登入，就足以讓攻擊者入侵。只允許金鑰登入，並停用 root 登入，就能把這些流量變成可忽略的雜訊。

在所有地方使用同一把私密金鑰。 將同一把金鑰複製到每台筆電與每台伺服器，表示只要有一台筆電遭竊，所有系統都會被解鎖。而且 SSH 金鑰不會過期，因此兩年前交給承包商的金鑰，今天仍然有效。每位人員與每台機器各使用一把金鑰 不需額外成本，也能限制單一遭竊金鑰可存取的範圍。

沒有人更新的套件。 針對你的 Web 伺服器或應用程式框架發布的 CVE，等同於一份公開的攻擊指示。掃描器會在幾天內開始測試該漏洞。安全性更新是可用成本最低的防禦措施，也可以自動執行：請參閱 Ubuntu 的自動安全性更新。

外洩的 secret。 資料庫密碼與 API 金鑰會存放在 .env 檔案中，而這些檔案可能被提交至公開 repository，或因 Web 伺服器指向錯誤的目錄而被提供給外部存取。貼入 AI coding agent context 的任何內容，也可能出現在日誌中。這是另一個需要處理的主題：避免讓 agent 存取 secret。

所有程式都以 root 執行。 應用程式以 root 執行時，其中一個錯誤就可能取得整台機器的控制權，因為伺服器內部已沒有任何邊界能阻止它擴散。

你負責的部分

以下工作都不是 hypervisor 的範疇。這些工作全部由你負責，而且會直接影響 VPS 是否安全。

• 正確完成第一個小時的設定：新 VPS 的前 10 分鐘涵蓋非 root 使用者與防火牆設定。
• 限制遠端存取：強化 VPS 上的 SSH。
• 關閉未使用的連接埠：ufw 防火牆基礎。
• 僅授予每項服務所需的存取權限：VPS 上的最小權限使用者。
• 降低暴力登入速度：Ubuntu 24.04 上的 fail2ban。
• 保留至少成功還原過一次的備份：VPS 的 restic 備份。

供應商負責的部分會在伺服器啟動時完成。你負責的部分在第一天約需 1 小時，之後每月只需幾分鐘。如果你仍在比較不同選項，VPS 的實際用途涵蓋了這些設定背後的基礎概念。

FAQ

同一台實體伺服器上的其他客戶可以讀取我的檔案嗎？

不可以，KVM VPS 不會有這個問題。您的伺服器是具備自身 kernel 與虛擬磁碟的虛擬機器，並使用主機分配給它的一段實體記憶體；處理器會阻止任何超出該記憶體範圍的存取。各 guest 之間沒有共用檔案系統，因此鄰近伺服器內的檔案權限，在您的伺服器內沒有作用。OpenVZ 和 LXC 等以 container 為基礎的方案會共用主機 kernel，隔離邊界較弱，因此購買前請確認方案類型。

VPS 比 shared hosting 更安全嗎？

就隔離性而言，是的。在 shared hosting 中，許多網站執行於同一個作業系統內，唯一的隔離邊界是檔案權限，因此其他帳號的設定錯誤有時可能導致檔案暴露。在 VPS 中，隔離邊界是虛擬機器。代價是 shared hosting 由主機商負責修補，而 unmanaged VPS 則由您負責修補。只有在您確實套用更新並關閉不必要的連接埠時，VPS 才會更安全。

hosting provider 可以讀取我的資料嗎？

原則上可以，任何 VPS 產品都無法改變這點。磁碟映像檔儲存在 provider 的硬體上，主控台可對執行中的機器提供螢幕層級的存取，而 rescue mode 可以使用附加了您磁碟的其他系統開機。若某些資料必須讓 host 無法讀取，請在寫入前於應用程式中先行加密。guest 內的磁碟加密在伺服器執行期間仍會將 key 保留在記憶體中，因此無法將 provider 排除在信任範圍之外。

VPS 最常以哪種方式遭到入侵？

以暴露的服務或脆弱的 SSH 登入為主，遠高於其他方式。自動化掃描器會持續探測所有公開 IP 位址，因此繫結至 0.0.0.0 且沒有密碼的資料庫，或仍使用預設認證資訊的管理面板，通常幾分鐘內就會被找到，而不是數個月後才被發現。任何公開伺服器上的 /var/log/auth.log 都能顯示 SSH 攻擊的一半情況：來自全球各地位址的重複 Failed password for root 行。Hypervisor escape 確實存在，但這類研究等級的攻擊主要針對高價值目標，不是一般伺服器遭到入侵的常見原因。