大家好,我是 Liberogic 的 CTO 大塚。
「VPN,好像快到極限了」
如果你在小公司兼任資訊系統負責人,相信應該不只一次有過這樣的想法吧。
我們公司也正是如此。
零信任、SASE、脫VPN……
這些詞常常看到,但總覺得是大企業的話題,也不太知道該從哪裡開始。
在這樣的情況下,約十人規模的網頁製作公司Liberogic Inc.,從VPN轉換為零信任架構。
本文將完整說明為何轉換、改變了什麼,以及弱點,分享我們實際操作的經驗。
VPN 已達「極限」的警訊
我們公司長久以來都是使用辦公室路由器的 VPN 功能。
這是一種常見的架構:從自家或外出地點先進入公司內網,再由公司連上網際網路。
不過,這幾年我們一直有以下幾點顧慮。
- 「在公司外工作前,請先連上 VPN」這項規定,最後仍只是一句提醒
- 咖啡廳、出差地點或客戶辦公室的 Wi-Fi,有時無法透過 VPN 連線。
- 視訊會議和雲端檔案同步全都要經過公司網路,速度很慢
- 路由器的工作是負責傳輸通訊,並不會阻擋危險網站。
如果符合其中任何一項,或許就是重新檢視的好時機。
最讓我在意的是「無法強制所有人都使用 VPN」這一點。
macOS 內建的 VPN 每次啟動都需要自行連線。
忘記連線的裝置,其通訊會在毫無防護的情況下,直接經由當下的網路對外傳送。
不可信網路的風險正在升高
另外,也順帶介紹一則最近的事件。
2026年10月,已確認印度憑證機構 eMudhra 的 8 個中繼憑證私密金鑰遭到外洩。
根據 Cloudflare 的說明,這些金鑰本身強度不足,任何網域的偽造憑證都可能被製作出來。
補充一點,這些憑證是瀏覽器與作業系統廣泛信任的對象。
過去在連接陌生 Wi-Fi 時,我認為現在多數網站都採用 HTTPS 而非 HTTP,因此風險相對較低。但看到這部分後,我覺得需要重新思考這個判斷。
零信任 / SASE / ZTNA 的差異簡述
開始研究時,首先就會在這裡感到混淆。對於小型公司來說,只要掌握這些程度,我認為就已經足夠。
術語 | 簡單來說 |
|---|---|
零信任 | 不因「身處公司內部就是安全的」而信任,而是每次連線都進行驗證的理念 |
ZTNA | 透過確認人員與裝置身分後,才允許連線至公司內部系統或應用程式的機制,可取代VPN |
SWG | 檢查網際網路連線,並阻擋危險網站的機制 |
SASE | 將網路與資安功能整合,並以雲端方式統一提供的理念 |
零信任是一種理念的名稱,實現它的服務形式包括ZTNA與SWG,而將這些整合起來的完整架構則是SASE,三者之間是這樣的關係。
與其一開始就想著「非導入SASE不可」,我認為對小型公司來說,更適合的做法是先從您在VPN上遇到什麼困擾,以及想解決什麼問題開始思考。
我們公司幾乎沒有內部業務系統
一般來說,VPN的主要用途,不就是從外部存取公司內部的業務系統或檔案伺服器嗎?
不過,我們公司內部幾乎沒有這類機制。工作上使用的工具大多是雲端服務,因此並沒有「該如何取代內部系統入口」的煩惱。
如果貴公司內部有業務系統,這很可能會是評估的核心。
遷移時最容易卡關的是「固定 IP」
以製作公司的情況來說,客戶伺服器的管理介面或 SSH 常會設定「只允許從特定 IP 位址連線」的限制。這是為了安全考量,也是非常正確的做法。
而我們多年來,也向許多客戶請求「請允許本公司的固定 IP」。可以說,這項設定是我們長期累積下來的資產。
零信任類服務也具備從固定 IP 發出連線的功能。
Cloudflare 也提供「專用 egress IP」功能,但需要 Enterprise 方案的附加服務,且以大型企業合約為前提。
對於像我們這樣的小公司來說,一直不好使用。
此外,一旦出口 IP 變更,就得請所有客戶重新更改設定。
這並不實際。
也就是說,我們想要的是以下三點。
- 無論身在何處,都不遺漏連線,守護所有成員
- 一般流量不想特地經過公司網路
- 但對於需要的目的地,仍希望維持從公司固定 IP 連出
我們的選擇:防護交給雲端,只有出口維持現有固定 IP
我們選擇的是 Cloudflare One。
- 在每台電腦安裝名為 WARP 的軟體:開機後會自動連線,比較不會忘記連線。
- Gateway 會阻擋連往危險網站的連線:依公司統一規則,阻斷與惡意軟體、釣魚網站相關的連線。
- 一般流量直接從 Cloudflare 送往外部:不經過公司的網路線路。
- 只有客戶的伺服器從公司固定 IP 出去:在公司內部放置一台小型設備,透過名為 Cloudflare Tunnel 的通道與 Cloudflare 連接。
最後這一點是我們決定性的理由。可以針對每個目的地指定「這個目的地只經過公司內部網路送出」。
對客戶來說,存取時使用的仍是原本的固定 IP,因此對方不需要變更任何設定。
而且公司內部的機器只會主動連線到 Cloudflare,不需要開放路由器的連接埠,因此不會增加從外部進入公司網路的入口。
當中間憑證之類的問題發生時,不必只依賴人員的注意力,這也是一大優點。
關於 eMudhra 的事件,Cloudflare 也說明:只要使用 Gateway 與最新版用戶端,就會自動受到保護。
有哪些改變
過去 | 現在 | |
|---|---|---|
在外工作 | 先連接 VPN 再工作 | 只要打開電腦 |
忘記連線 | 發生 | 難以發生 |
危險網站 | 依賴各台電腦的資安軟體 | 依全公司規則封鎖 |
網路會議與雲端服務 | 全部都會經過公司的網路線路 | 不經過公司 |
客戶的伺服器 | 從公司的固定 IP 連線 | 從公司的固定 IP 連線(不變更) |
WARP 會在 Mac 開機的同時啟動並自動連線。員工不需要記住 VPN 的連線步驟,也不用在意細部設定。 加強資安通常會增加現場的負擔,但這次反而減少了工作量。 這種 UX 的優點,是我們實際導入後最令人驚訝的地方。
也能建立只能透過 WARP 開啟的內部應用程式
Cloudflare One 提供 Access 功能,可以限制哪些人或哪些裝置能開啟網頁應用程式。運用此功能,就能建立只能從已透過 WARP 連上公司 Cloudflare One 的裝置開啟的應用程式。
例如,只有同時滿足以下兩個條件時,才允許存取。
- 已使用公司電子郵件地址登入
- 透過 WARP 連線至公司的 Cloudflare One
即使網址外洩,不符合條件的裝置也無法開啟。等同於不需要 VPN,就能建立與「將內部系統置於 VPN 之內」相近的保護形式。
公司內部伺服器上運行的應用程式,只要透過 Cloudflare Tunnel 連接,也能在不開放連接埠的情況下,以相同方式加以保護。
接下來介紹的管理應用程式,也是以這種方式加以保護。
秉持 DIY 精神,我們也開發了小型管理應用程式
仍留下一個課題。每當客戶的伺服器增加,就需要登錄「此目的地使用固定 IP 輸出」的設定,但 Cloudflare 的管理畫面充滿專業術語,設定錯誤時會影響所有人的連線。也不能將管理員權限交給每一位成員。
因此,我們開發了一款內部應用程式,讓員工只要選擇目的即可完成登錄。
- 誰在何時、為了什麼目的而註冊,都會留下紀錄。
- 無法註冊的對象包括全公司使用的服務,以及範圍過大的項目。
- 註冊完成後,可以當場確認設定是否確實生效。
Cloudflare 的設定可以透過 API 操作,因此也能開發這類公司內部工具。我們平時就在開發網頁應用程式,這方面正是我們的擅長領域。
關於費用
Cloudflare One 提供最多 50 位使用者的免費方案。
這與用於內部工具登入管理的 Cloudflare Access 採用相同的使用者額度,因此已在使用 Access 的公司,更可以輕鬆試用。
超過 50 位使用者時需改用付費方案,公開定價為每位使用者每月 7 美元。
固定 IP 的網路線路可以直接沿用目前的設定。
另外只需要在公司內放置一台長時間運作的機器。
我們準備了一台專用的小型電腦。
老實說,它並非萬能
只談優點也不夠客觀,因此在這裡也列出需要注意的地方。
- 若通道中斷,將無法透過固定 IP 對外連線:一旦公司內的小型電腦或網路線路停止運作,就無法連線到客戶的伺服器。一般網站仍可瀏覽,但必須設置能及時察覺中斷的通知機制。
- 對 Cloudflare 的依賴會增加:驗證與連線路徑都會集中到同一家公司。這是便利性的代價。
- 每台電腦都需要安裝:WARP 與憑證設定需要在每台裝置上各做一次。智慧型手機需要的手動作業也會增加。
- 與客戶指定的 VPN 併用需要事先確認:視路由與 DNS 設定而定,Gateway 的防護可能會失效。我們在連線手冊中說明了操作步驟。
- 並不會檢查通訊內容本身:我們不進行 TLS 解密。若需要對所有通訊進行細緻檢查,則需另行評估。
- 免費方案並不代表支援完善:問題基本上需要自行查找原因。此外,免費方案的日誌保存期限最長為 24 小時。
適合與不適合的公司
我們認為以下這類公司較適合。
- 員工數為數人至數十人,且有人在外部或遠端工作
- 無法放棄以固定 IP 限制存取
- 以雲端服務為主,內部伺服器較少
- 至少有一位熟悉的人在身邊,可以邊查邊試。
反之,若遇到以下情況,建議也可考慮其他產品,或諮詢專業公司。
- 產業規範要求長期保存日誌,或需要詳細檢查通訊內容
- 公司無法管理的裝置很多,無法安裝軟體
- 隧道停止時,沒有人能夠應對
總結
過去只是請大家在 Mac 上安裝防毒軟體,並未指定詳細的設定。這次結合 Cloudflare One 的導入,我們在公司內部統一整備了 macOS 的各項設定,包括防毒軟體的設定。
然而,針對開發者與製作者的攻擊日益激烈,需要守護的不只這些。Liberogic 也正在著手處理以下這些事項。
依賴套件管理
鑑於針對開發者的供應鏈攻擊日益增加,我們不再只是「先更新到最新版」,而是重新檢視套件的引入方式與確認流程。
機密資訊的管理
API 金鑰與 SSH 金鑰依 1Password 規範進行管理,並盡可能避免在開發環境中以明文保存。
權限最小化與定期盤點
客戶環境及各項服務的帳號、金鑰與權限,都限縮在必要範圍內,並確保專案結束後不留存。
分享學習心得
我們以實際公開的資安事故作為內部讀書會的題材,並將其套用到自家環境來思考:「如果是我們,會不會受到影響?」
當然,我們會小心避免發生重大資安事故。不過,以公司規模來看,我們與大型客戶的往來相當頻繁,因此必須持續確保一定的資安標準。
這些都不是什麼引人注目的事,但我們一直踏實地累積能做到的事情。
如果這些經驗能為同樣煩惱的公司提供一些參考,我們將深感榮幸。
Liberogic 技術部門的支柱。聽到「要是有這種東西就好了」、「有這個就方便了」這類話,就會憑著過人的智慧加上附加價值,轉眼間就完成實作。溝通能力高、深受客戶喜愛,是公司的寶貝,也是個超愛貓的人。
大塚 翔
董事 CTO / 首席工程師 / 合同會社貓穴 代表 / 年輕得很沒道理