舊版網站不敢升級，也不能裸奔：用 HAProxy 與 Authelia 建立雙因素認證防線

技術筆記｜適用於內部知識庫、歷史相簿、舊版 PHP 與不對外提供服務的網站

本文以虛構的通用部署情境說明技術選型，未包含任何真實主機名稱、IP、網域、網路拓樸或組織資訊。設定片段為示意，正式部署應依版本文件調整。

一、問題從哪裡來：舊網站有價值，舊環境卻有風險

許多企業或個人都保存著運作十幾年的內部網站，例如早期的 PHP 相簿、工作紀錄庫或文件管理系統。資料可能具有長期保存價值，但底層作業系統、PHP 與套件早已停止安全更新。直接升級可能遇到資料庫格式、字元編碼、函式相容性與檔案上傳流程等問題；完全重寫又耗費時間。

如果這類網站只供少數授權者使用，問題不一定是「如何把每個 HTTP 參數過濾到毫無風險」，而是「如何在請求接觸舊程式之前，先確認來訪者有權使用」。這是將防護重心從內容偵測移到入口存取控制。不過，入口認證並不等於修補漏洞，後端仍應隔離、備份並限制網路權限。

二、為何不一定要自行開發 Go 過濾代理？

一種直覺方案是在反向代理後再放一層 Go 服務，逐一檢查 GET、POST、查詢字串、上傳檔案及其他 HTTP 內容。這可以實作白名單，但維護成本容易被低估。搜尋欄位可能包含引號、括號、特殊符號或多國語言；圖片上傳涉及 multipart/form-data、檔名、MIME 類型與大檔串流。過於嚴格的規則會誤擋正常使用，過於寬鬆又可能漏掉攻擊。

內容過濾並非沒有價值；當系統必須接受大量陌生訪客時，WAF、檔案掃描、請求大小限制與應用層驗證仍有必要。但對少數人使用的封閉網站，優先建立可靠的身分認證、來源限制與網路隔離，通常更符合成本效益。即使採用認證，也不能信任所有已登入者的輸入，更不能把認證當作防止惡意檔案或程式漏洞的萬靈丹。

三、HAProxy 原生能做什麼？

HAProxy 是反向代理與負載平衡軟體，可終止 HTTPS、依網域與路徑路由、套用 ACL、限制來源 IP，並使用 userlist 與 HTTP Basic Authentication 建立基本帳密門檻。對固定少數使用者，Basic Auth 加上 IP 白名單已是低成本的第一道防線。

但 Basic Auth 的瀏覽器提示較簡單，沒有完整的登入頁面、裝置工作階段管理或原生 TOTP 雙因素流程。HAProxy 也不是一般用途的 SQL 帳號管理系統；若想查詢 MariaDB/MySQL 的自訂使用者資料表，通常需要外部認證服務或自行開發 API，而不是只設定資料庫連線字串。

另一種方式是 mTLS：由反向代理要求瀏覽器出示受信任 CA 簽發的用戶端憑證。它不必讓使用者每次輸入密碼，安全性也很強；代價是每部手機、平板、筆電或工作電腦都要管理憑證。建議每台裝置簽發獨立憑證，以便個別撤銷。對頻繁跨裝置使用的人，這種管理負擔可能不小。

四、Authelia 是什麼？它不是 HAProxy 外掛

Authelia 是免費、開源、可獨立部署的身分認證與授權服務。它可以運行在 Linux 主機或 Docker 容器中，搭配 HAProxy、Nginx 等反向代理保護既有網站。它不是安裝進 HAProxy 程序內的外掛，也不需要取代原有網站。

其核心能力包括帳號密碼登入、TOTP 雙因素驗證、Session Cookie、存取控制政策，以及與外部認證後端的整合。少量帳號可使用檔案式使用者資料庫；持久化狀態可採 SQLite 等受支援儲存方式。要特別區分：Authelia 能使用 SQL 資料庫儲存自身狀態，不代表可以直接拿任意既有 MariaDB 使用者資料表作為登入來源。若要共用企業帳號，應先評估 LDAP 等正式支援的認證後端。

五、典型架構與請求流程

手機／平板／筆電／桌機
          │ HTTPS
          ▼
     HAProxy 入口
          │
          ├── 一般公開網站 → 原有後端（不套用登入）
          │
          └── 受保護網站 → 查詢 Authelia 認證狀態
                                  │
                          未登入 → 登入頁面
                                  │ 帳密 + TOTP
                          已登入 → 放行至舊版網站

使用者先造訪受保護的網站。HAProxy 透過外部授權整合向 Authelia 確認 Session 與存取政策；若未登入，瀏覽器會被引導至認證入口。完成帳號密碼及第二因素後，瀏覽器持有相應 Cookie，後續請求經檢查即可轉送到原有應用程式。舊版 PHP 不需要知道 TOTP 如何運作，也不必改寫既有的圖片搜尋或上傳功能。

實作細節不能只寫一句「啟用 ForwardAuth」就結束。HAProxy 的整合方式與版本、Lua 支援、認證請求處理模組及回應轉址有關，應採用 Authelia 官方對應版本的 HAProxy 範例，先在測試環境驗證。認證服務故障時必須採取 fail closed：拒絕進入受保護網站，而非跳過驗證。

六、TOTP 與登入有效期：不必每三十秒驗證一次

TOTP 是基於時間的一次性密碼，常見驗證器會約每三十秒更新六位數代碼，例如 Google Authenticator 或 Microsoft Authenticator。這只是驗證碼更新週期，不是使用者每三十秒就要重新登入。

完成雙因素認證後，Authelia 會透過 Session 管理登入狀態。管理者可依版本支援的設定調整閒置逾時、一般有效期限與「記住我」期限。例如內部系統可評估八小時閒置逾時、七天一般有效期；個人受管裝置再考慮較長的記住登入期間。這些只是政策示例，不是產品固定預設值，也不保證所有選項可以任意疊加。

關閉瀏覽器是否要重新登入，取決於 Cookie 是否持久、瀏覽器是否清除資料、Session 是否過期，以及是否主動登出。共用電腦應採短期限且避免「記住我」；個人裝置則應配合螢幕鎖定、磁碟加密與裝置遺失處置。

七、部署規格與安全控制

建議以獨立容器部署 Authelia，保留既有 HAProxy 的公開網站路由，僅針對指定內部網站啟用認證。登入入口與受保護網站應使用 HTTPS，並規劃適當的 Cookie 網域與安全屬性。帳密不可明文保存，應使用官方支援的安全密碼雜湊；TOTP 密鑰、Session Secret、儲存加密金鑰等須以受控方式保存與備份。

最小部署可採一個 Authelia 服務、檔案式帳號後端及 SQLite 狀態儲存，但仍需依官方要求設定通知機制、加密金鑰與必要參數。部署前先確認容器版本、HAProxy 編譯功能、DNS、TLS 憑證、時間同步及備份策略。正式設定應依當時官方文件產生，避免直接複製過期 YAML。

更重要的是，舊版主機不能從其他網路路徑被直接連線。防火牆應限制只允許指定反向代理存取必要的服務埠；舊主機對內部網段與網際網路的主動連線也應遵循最小權限。對高風險歷史系統，還應考慮只讀資料、離線備份、虛擬機快照與可還原測試。快照不能取代獨立備份。

八、圖片上傳與表單相容性要測什麼？

外部認證的優點是不用逐字掃描搜尋欄位，也不必將圖片內容送進認證系統。已登入的正常 POST 原則上可直接轉送；但這不代表所有情況都必然無縫。若使用者編輯資料期間 Session 過期，送出表單時可能被導向登入頁面，原本的 POST 內容不一定能保留。大檔上傳還受代理逾時、要求大小限制與後端 PHP 設定影響。

因此測試清單至少包括：中文與特殊字元搜尋、圖片新增與修改、多檔及大檔上傳、長時間編輯後送出、Session 過期後重新登入、手機瀏覽器操作，以及 Authelia 停機時的拒絕行為。對公開網站也要做回歸測試，確保新的認證規則不會誤傷原有流量。

九、方案比較與選型

對於少數人、但經常跨手機與電腦使用的歷史網站，HAProxy 搭配 Authelia 與 TOTP 是值得優先驗證的折衷方案。如果環境允許，再加上 VPN 或來源限制，會比單靠登入頁面更穩健。

十、建議的導入順序

1. 盤點既有反向代理版本、TLS 設定、後端連線方式與資料備份。
2. 先部署獨立 Authelia 測試服務，建立一個測試帳號及 TOTP。
3. 使用官方 HAProxy 整合範例，僅保護測試網域或測試入口。
4. 驗證登入、登出、Session、圖片上傳、搜尋及故障時拒絕存取。
5. 完成防火牆隔離，封鎖繞過反向代理的直接連線。
6. 分階段切換正式網站，保留回復程序與監控紀錄。
7. 定期更新認證服務，檢查帳號、備份、日誌及憑證有效期。

結語：先確認誰能進門，再考慮門內的防護

維護舊版網站的關鍵，不一定是把所有程式重新寫過，也不是自行打造一個會檢查所有 HTTP 字串的安全代理。對不需公開的歷史系統，先將入口縮到最小、建立可信身分驗證，再配合網路隔離與備份，往往更能兼顧安全與既有功能。

Authelia 的價值，是把帳號、雙因素認證與 Session 管理從舊程式抽離，交給持續維護的獨立服務；HAProxy 則保留反向代理與存取控制的角色。兩者搭配能降低舊系統的暴露面，卻不能保證漏洞消失。真正可靠的設計，是認證、隔離、最小權限、監控與可還原備份一起落實。

參考資料

• Authelia 官方網站
• Authelia：HAProxy 整合
• Authelia：Docker 部署
• Authelia：設定文件
• HAProxy 官方文件

本文為技術選型與架構設計紀錄；實際指令、設定欄位與支援功能應以部署時所使用版本的官方文件為準。