# 將公開 Web 邊緣與應用程式分離 | SwissOctet 深入解析 https://swissoctet.com/zh-tw/insights/separate-the-web-edge-from-the-app/ SwissOctet / 深入解析 / Web 與 onion Web 與 onion 實務應用 · 4 分鐘閱讀 將公開網頁邊緣與應用程式分開 為網頁伺服器、反向代理與應用程式賦予不同職責，並刻意設定來源存取、TLS、請求限制與事件處理路徑。 由 SwissOctet 編輯部撰寫 儲存指南 複製連結 本頁內容 01 一個 Web 請求會跨越數項職責 02 使用邊緣來組織 HTTP 行為 03 反向代理不會消除來源的暴露風險 04 在應用程式內套用存取決策 05 在多個層級規劃阻斷服務防護 06 將復原納入發布流程 您的實用檢查清單 來源與延伸閱讀 返回資料庫 直接答案 將 HTTP 發布與應用程式執行及持久性資料分離。反向代理可以組織路由與限制，但來源存取、應用程式授權、上游容量與復原各自需要專屬的控制措施。 01 一個 Web 請求會跨越數項職責 Web 伺服器接收 HTTP 請求，並可提供靜態檔案。應用程式處理程序執行專案的動態行為，例如檢查帳戶或查詢資料庫。反向代理代表該處理程序接收請求，並將其轉送至上游。一個程式可能同時扮演多種角色，但將職責分離可讓設定與復原更容易理解。 追蹤一個請求從主機名稱解析到回應的過程。記錄 TLS 在哪裡結束、哪個處理程序選擇路由，以及哪個元件可以讀取應用程式資料。對管理請求也做同樣的追蹤。這項練習經常會揭露某個為了測試而建立、卻意外仍可觸及的監聽器或主機名稱。圖表應描述實際部署的路徑，而不是你希望建立的架構。 02 使用邊緣來組織 HTTP 行為 NGINX 的文件同時說明了提供靜態內容與將請求轉送至上游。其 worker 架構與 HTTP 模組提供了設定機制，但特定設定仍決定實際行為。請審慎定義主機名稱、上游與檔案系統根目錄。限制可提供的檔案，讓設定、認證資訊與儲存庫中介資料永遠不會因為恰好位於應用程式附近而變成可下載。 根據應用程式為請求主體、逾時與連線設定適當的限制。將快取視為資料決策：與使用者或權限相關的內容，未經審查不能安全地沿用共用快取規則。一起測試驗證與快取行為。保留可重現的設定，並在重新載入服務前驗證變更，同時確保有一條已知路徑可回到先前可運作的版本。 層級 有用的職責 上線前檢查 公開 Web 邊緣 TLS、主機名稱路由與 HTTP 限制 憑證、根目錄與預定主機名稱 應用程式處理程序 業務邏輯與授權 驗證、輸入檢查與相依性失敗 內部資料服務 持久性應用程式狀態 受限存取與經過測試的還原 上游供應商網路 合約所涵蓋的網路服務 保護範圍與升級路徑 03 反向代理不會消除來源的暴露風險 如果來源仍可公開觸及，用戶端可能不經預定的代理路由而直接觸及它。當部署需要該邊界時，請透過網路設計與應用程式設定限制來源存取。在同一台機器上，後端通常可以監聽 loopback 或本機 socket。跨機器時，請使用明確的受限路由，並為上游連線提供適當保護。 轉送標頭也需要信任規則。只接受來自受信任中介者的原始用戶端資訊，並防止任意呼叫者提供應用程式視為權威的值。決定存取日誌與錯誤報告中會出現什麼。代理可以改變各層可取得的資訊；它不會抹除帳戶識別碼，也不會讓應用程式對其自身操作者匿名。 04 在應用程式內套用存取決策 NIST 的零信任架構著重於資源的存取決策，而非僅根據網路位置給予隱含信任。具體套用該原則：驗證呼叫者、授權所請求的操作，並只賦予服務帳戶所需的範圍。來自內部子網路的請求不應自動成為管理員請求。 在實務可行時，將公開與管理功能分離。當使用者存取記錄時重新檢查權限，而不是只依賴初始登入。讓代理、應用程式與資料庫的認證資訊保持各自獨立。以可測試的階段逐步導入變更，從範圍狹窄的敏感路徑開始。將部署稱為零信任，不如證明禁止的操作確實會在負責該操作的元件上遭到拒絕。 05 在多個層級規劃阻斷服務防護 飽和的網路連結與昂貴的應用程式請求會在不同地方失敗。Web 邊緣的速率限制可能有助於約束請求模式，而應用程式限制則可界定搜尋、上傳或匯出等工作。NGINX 的請求限制模組提供了一種機制；鍵值與閾值必須符合真實使用者，並經過測試以避免拒絕合法流量。 OWASP 的阻斷服務指引也處理應用程式行為中的資源耗盡問題。為昂貴的工作設定時間與大小限制、使用有界佇列，並監控失敗訊號。本機控制無法在已經飽和的上游連結中創造容量。確認所選方案中包含的特定網路保護，並準備升級路徑。切勿假設型錄中的 Layer 3–4 保護也能證明對每個 HTTP 工作負載的保護。 06 將復原納入發布流程 從外部用戶端使用其預定主機名稱檢查網站。驗證 HTTPS、重新導向、靜態資源、登入與具代表性的應用程式交易。確認管理監聽器與私人檔案仍無法觸及。模擬上游停止運作，並檢查邊緣是否傳回受控的失敗，而不是暴露內部細節或無限制地等待。 對於 Canvas，請閱讀主機帳戶內可用的控制措施。對於 VPS，請將 Web 邊緣與應用程式納入你自己的營運計畫中維護。大型網路埠是容量規格，並不證明應用程式能維持該輸送量。將監控、還原與供應商聯絡資訊保留在操作手冊中。只有在實際請求路徑與可行的復原路徑都已驗證後才發布。 付諸行動 您的實用檢查清單。 ✓ 追蹤一個公開請求與一個管理請求。 ✓ 定義所服務的根目錄與上游監聽器。 ✓ 只信任來自已核准中介者的轉送標頭。 ✓ 測試授權與快取邊界。 ✓ 為網路與應用程式失敗準備限制與升級措施。 下載檢查清單 常見問題 重要細節。 Web 伺服器也能同時作為反向代理嗎？ + 可以。NGINX 是一個有文件記載的例子。其角色取決於設定，而應用程式仍需要自己的授權與維護。 反向代理會自動隱藏來源嗎？ + 不會。除非路由、防火牆與監聽器設定強制執行預定的邊界，否則來源可能仍可觸及。 請求限制能阻止每一次 DDoS 攻擊嗎？ + 不能。它處理的是特定的 HTTP 請求模式。網路飽和其他資源失敗需要適當的上游與應用程式控制。 主要參考資料 前往來源。 這些參考資料支持本指南中的技術概念。在變更生產系統之前，請遵循最新文件。 NGINX：入門指南 nginx.org NGINX：HTTP 請求限制 nginx.org NIST SP 800-207：零信任架構 nvlpubs.nist.gov OWASP：阻斷服務防護 cheatsheetseries.owasp.org 由 SwissOctet 提供的編輯指引。範例僅供說明。服務規格、可用選項與合約條件必須另行驗證。 連結知識 相關基礎架構。 Canvas Web 瑞士 Vector VPS 瑞士 Pulse NVMe 瑞士 Transit 40 瑞士 保持脈絡 您的下一份實地筆記。 探索所有指南 實地筆記 / 01 + 第二天營運 實務應用 可持續維護的 Linux VPS 強化基準 安全地管理、只暴露必要的服務，並建立更新與復原機制，同時避免把自己鎖在外面。 6 分鐘閱讀 閱讀指南 實地筆記 / 02 + Web 與 onion 基礎 網頁代管或 VPS：選擇你想負責的工作 比較應用程式需求、控制權與維護責任，而不是把 VPS 當成每個網站的必然下一步。 6 分鐘閱讀 閱讀指南 實地筆記 / 03 + Web 與 onion 實務應用 新伺服器的網域、DNS 與 TLS 切換操作手冊 一併準備主機名稱路由、憑證與回滾，讓遷移能更換伺服器，而不破壞網站的識別或安全連線。 4 分鐘閱讀 閱讀指南