先畫流量路徑，再決定子網與防火牆
實務上，我們不會先問要切幾個子網，而是先列出系統的流量路徑：網際網路如何進入公開服務、公開服務會呼叫哪些內部 API、API 需要存取哪些資料庫，以及維運人員與部署流程從哪裡進入。每條路徑都應標明來源、目的地、通訊埠、協定、驗證方式與負責團隊。這份清單會直接轉化為路由、防火牆規則、服務身分與監控需求。
一個常見基線是分成公開入口層、應用與 API 層、資料層，以及管理與共用服務層。公開入口層可放負載平衡器、API Gateway 或反向代理；應用層執行 Web 後端、工作程序與內部 API；資料層放資料庫、快取與訊息系統；管理層則容納跳板機、VPN、DNS、日誌或部署代理。這些是安全邊界，不只是命名規則。即使都在同一個雲端虛擬網路內，也應使用不同子網、路由表與安全規則。
- 預設拒絕：每個區域只開放已知且必要的流量，不以整段私有網段互相信任。
- 單向依賴：公開層可以呼叫指定 API，但資料層不應主動連回公開層。
- 縮小範圍：規則優先綁定服務身分、安全群組或特定工作負載，而非寬鬆的 CIDR。
- 保留可觀測性：流量日誌、DNS 查詢與拒絕事件必須能被集中檢索。
公開服務只公開入口，不公開整個應用
需要被使用者存取的通常只是 HTTPS 入口，不代表應用主機必須持有公開 IP。較穩健的做法是讓 CDN、WAF、負載平衡器或 API Gateway 接收網際網路流量，再將請求送到私有子網中的服務。入口層負責 TLS、基本限流與常見攻擊防護；應用層則只接受入口元件送來的流量。如此能減少可掃描的端點，也讓憑證與外部政策集中管理。
但並非所有系統都需要堆疊全部元件。流量單純的內部工具可能只需要受身分保護的代理；面向大量外部整合的 API，則通常需要明確的版本、配額、金鑰或 OAuth 政策。選擇時要看威脅模型、延遲、成本與團隊是否有能力維護規則。WAF 不是應用程式驗證的替代品，私有子網也不會自動修補權限過大的服務帳號。
公開工作負載的對外連線同樣要設計。若所有私有主機都能透過 NAT 任意上網，遭入侵的服務就可能下載工具或外傳資料。可以依需求限制出口目的地，讓雲端服務走私有端點，並將套件下載、映像檔存取與第三方 API 列入允許清單。出口控制會增加維運工作，因此應先涵蓋資料層與高敏感工作負載，再逐步擴大。
內部 API 與資料庫要建立兩道不同邊界
內部 API 不應因為使用私有 IP 就被視為可信。跨服務呼叫仍需驗證服務身分，並針對敏感操作做授權。雲端原生環境可使用工作負載身分、短效權杖或雙向 TLS，避免把長期金鑰放在程式碼與設定檔。若 API 同時服務 LINE、ERP、CRM 或 IoT 平台，建議讓外部整合先進入受控的整合層，再由該層呼叫核心服務，避免合作系統直接穿越到內部網段。
資料庫邊界應更嚴格：不配置公開位址，只接受指定應用身分或安全群組的連線，管理連線則走獨立的 VPN、零信任存取代理或受稽核的工作階段。應用不需要的資料庫連接埠一律關閉；讀寫帳號、唯讀帳號與遷移帳號分開；密碼與憑證由秘密管理服務提供並定期輪替。備份、複寫與監控流量也要列入設計，不能為了讓維運功能運作而臨時放寬整段網路。
微服務數量增加後，逐條管理網路規則可能變得困難。服務網格或集中式 API 管理可以提供一致的加密與政策，但也帶來代理資源、憑證生命週期與除錯複雜度。若團隊規模或服務數量尚小，清楚的安全群組加上工作負載身分往往更容易維護；當跨叢集、跨帳號或多團隊政策開始重複時，再導入更集中化的控制通常較合理。
跨環境、維運與驗證決定設計能否長期運作
正式、測試與開發環境應至少使用不同的帳號、專案或虛擬網路邊界，避免只靠子網名稱區分。正式資料不應因測試方便而直接開放給非正式環境；若確實需要資料，應採用去識別化副本或受控的資料交換流程。跨雲、地端 ERP 與雲端服務之間的 VPN 或專線，也不應建立成全面互通。路由只公告必要網段，防火牆只允許明確服務，並處理好重疊 CIDR、DNS 解析與故障切換。
維運通道是分區設計最容易被繞過的地方。比起長期開放 SSH 或資料庫管理埠，更適合使用具多因素驗證、短效授權與工作階段記錄的存取方式。緊急權限必須可追蹤且有到期時間。部署系統也只應取得完成部署所需的網路與雲端權限，不應因為方便而成為所有區域的永久管理者。
最後，必須用測試證明隔離真的存在。除了驗證允許的路徑，也要自動測試禁止的路徑，例如公開層無法直接連資料庫、開發環境無法讀取正式資料、一般工作負載無法進入管理網段。將路由、安全群組與防火牆規則納入基礎設施即程式碼及變更審查，並定期檢查未使用規則、異常出口與流量拒絕紀錄。若整合範圍涵蓋多個雲端與企業系統，讓網路、身分與應用團隊共同維護同一份流量矩陣，通常比各自修補連線問題更可靠。