外觀
2026-07-02 警政網路架構入門
🏛️ 實習單位：內政部警政署（警政資訊與資通安全）｜實習第一天。
本日從大型公務機關的網路架構入門，看資安要求、跨機關業務與個資保護怎麼變成架構原則。以下只整理可公開的通用方法；實際節點、線路、設備與規則一律不寫。
今日目標
- 讀懂一張大型機關網路架構示意圖的整體邏輯。
- 建立「網路分區 ＋ 縱深防禦」的設計直覺。
- 弄懂三層式（Web－AP－DB）為什麼是核心。
- 用「保守、可查核」的方式做架構筆記，不把內部配置寫死。
示意：網路分區、層層閘門與最內層的防護核心。此圖僅為概念示意，不代表任何實際系統或作業流程。
一、為什麼大型機關要用複雜的網路架構
佐證：資安治理與主管機關可對照 《資通安全管理法》。
第一眼看到架構圖，我只覺得線太多。這個複雜度是被三件事逼出來的：高資安要求、大量跨機關業務，加上個資與偵查資料要保護。任何一個對外出入口、任何一條內部連線，都得先被設計過、能控管、事後查得到。這點想通，後面每一層才看得懂。
二、架構設計的思考順序
把整張圖的邏輯拉直，是一條主線：先講為什麼這樣設計，再一層層收斂到實作與維運。
起點是背景與原因：大型機關需要複雜架構，是被高資安要求、跨機關業務與個資保護三件事逼出來的。接著才輪到設計原則，也就是分層防禦（縱深防禦）、最小權限與受控互通；再來是需求與風險分析，先盤點業務需求與威脅，才決定分區怎麼切、管控要多強。
有了這三步，圖上的框才排得出來。網路分區依用途切成內網、外網、收口區、資料區、測試區等邏輯區塊；防火牆控管走正面表列、預設拒絕，而且它保護的是「資料區」而非資料庫本體；三層式架構讓請求依 Web－AP－DB 流動，使用者不直連資料庫；收口與身分控管把出入口收斂到少數受控節點，統一做身分驗證與紀錄；跨機關連線則透過政府骨幹網路與專線受控連外。最後一環是備援維運：HA、備份、異地備援，目的是消除單點故障，並用 RTO／RPO 衡量容災目標。
九個環節裡，看下來比較容易被跳過的是第三步的需求與風險分析。它不對應圖上任何一個框，畫不出來也交不出圖，可是少了它，分區要切幾塊、防火牆該開哪幾條就只能憑感覺決定。
架構審查的五個問題
與其先背設備名稱，我後來會先回答這五個問題：
要保護什麼？ 要講清楚關鍵服務、資料類型與可承受的中斷程度，這一題決定資料怎麼分區、備援與保護做到多強。誰需要存取？ 使用者角色、管理者、系統服務與外部合作對象都要列出來，對應到身分驗證、最小權限與權限複核的設計。資料怎麼流動？ 把從使用者、應用服務到資料儲存的必要路徑攤開，受控互通、日誌與介面邊界才有依據可以劃。
後兩題往失效那端問。哪裡可能失效？ 盤點單點故障、權限濫用、設定錯誤與外部攻擊面，決定分層防禦、監控與復原策略放在哪幾層。發生問題後怎麼辦？ 偵測、通報、切換、還原與事後檢討的方式，決定可觀測性、演練與維運責任怎麼分配。
五題裡我覺得第三題最難。「必要路徑」的重點在「必要」，要答得出來，等於得有人指出哪幾條現有連線其實可以砍掉——那通常牽涉到別人的系統，沒人想當提這件事的人，於是路徑只會越加越多。
這五題把網路圖從「元件清單」變成「風險與服務的設計說明」，也擋掉「技術很新所以想用」的衝動。
三、網路分區與縱深防禦
- 內外網「受控互通」，不是完全阻斷：該通的走指定通道，該擋的預設擋掉。
- 邏輯分區：依用途切成內網、外網、收口區、資料區、測試區；一區被攻破，不會直接波及其他區。
- 防火牆「正面表列 ＋ 最小權限」：預設拒絕，只明列允許的流量；而且它保護的是資料區，不是資料庫本體。
- 總原則是分層防禦（縱深防禦）：不靠單一防線，攻擊者每前進一步都要再突破一層。
四、三層式架構（Web－AP－DB）
整張圖的核心之一是 Web－AP－DB 三層式架構：請求先到 Web 層、再到應用（AP）層，最後才由 AP 層存取資料庫（DB），使用者永遠不直連資料庫。資料庫收在最內層，攻擊面小；每次存取都經過應用層，才有機會被記錄與控管。
五、身分與收口控管
透過代理（Proxy）、目錄服務、位址配發與網路存取控制（NAC），做到「誰能連、從哪連、連去哪」都可控可查。核心是收口：把出入口收斂到少數受控節點，再統一做身分驗證與紀錄。事後稽核與究責都靠這些集中的紀錄點。
六、跨機關連線
機關之間透過政府骨幹網路與專線做受控連外（政府網際服務網 GSN 即屬此類公開已知的政府網路）。至於具體節點、線路與防火牆規則屬於內部資訊，本筆記一律不記錄。
七、維運韌性：HA ≠ 備份 ≠ 異地備援
- 高可用（HA）不是萬靈丹：它讓服務在單點故障時仍能運作，但不等於資料有備份，更不等於異地備援。
- 三者要分清楚：備份（資料可還原）≠ 備援（服務可接手）≠ 異地備援（機房級災難仍可復原）。
- 核心思維：找出單點故障（SPoF），用 RTO（可容忍中斷時間）／RPO（可容忍資料遺失量）衡量容災目標。
將韌性落成可驗證的目標
有備份不等於有韌性。要答的是故障當下服務怎麼運作、多久接得回來。我整理成一份最小檢核：
- 單一設備或鏈路故障：會不會中斷關鍵服務？要看有沒有替代路徑、接手機制與明確告警。
- 資料誤刪或毀損：能不能還原到可接受的資料狀態？要看備份是否可讀、可還原並定期測試。
- 機房或區域性事件：服務能不能在其他位置持續或復原？要看異地備援、作業切換與復原演練是否可驗證。
- 資安事件：能不能限制擴散並保留查證依據？要看分區、權限、日誌與應變流程有沒有協同運作。
四項裡我的感覺是第二項最容易過關、也最容易出事。備份任務回報成功，跟備份檔真的還原得回來，是兩件事，中間差的就是那次沒人排時間做的還原測試。
RTO 與 RPO 白紙黑字寫下來，業務、資訊與管理三邊才會對「何時必須恢復、最多可遺失多少資料」講同一套標準。沒寫的時候，三邊心裡的數字通常差很多。
八、公開整理架構筆記的三個原則
架構筆記本身也可能被拿去利用，所以我整理公開版本時守三個原則：
- 不寫死內部配置：IP、線路、VPN 節點、防火牆規則、設備廠牌與拓撲一律不寫；學的是原理，不是「某機關怎麼接」。
- 用保守的報告用語：寫「受控互通」而不寫「完全不通」；寫「具高度資安要求」，不去斷言某機關屬於哪個責任等級。
- 關鍵事實標來源：只寫公開可查證的內容，數字與等級以主管機關核定或官方公告為準。
這三點就是本站筆記一律「只保留可公開的通用概念、全面去識別化」的理由。寫的當下就在做資安判斷，不會寫完再回頭刪。
法規與官方來源
完整來源見 法規與官方來源索引。
| 主題 | 依據／來源 | 重點 |
|---|---|---|
| 資通安全治理 | 《資通安全管理法》 | 責任等級由高至低分 A、B、C、D、E 級（個別機關實際等級以主管機關核定為準） |
| 零信任架構 | 國家資通安全研究院 ZTA | 身分／設備鑑別、信任推斷，與「收口 ＋ 最小權限」相呼應 |
這一天的分層結構
把這天的內容從風險盤點疊到失效那天，每一層都在回答上一層留下的問題：
text
第 0 層 業務需求與風險盤點
問什麼：要保護什麼、誰需要存取、能承受多久中斷、可容忍多少資料遺失
產出：關鍵服務與資料清單、風險排序、RTO／RPO 目標值
↓ 這幾個數字決定下面每一層要做多強
第 1 層 網路分區與邊界控管
問什麼：哪些用途該分開、區與區之間哪些流量必須放行
產出：內網／外網／收口區／資料區／測試區的邏輯切分、正面表列規則
↓ 區塊切好了，區內的服務要怎麼擺
第 2 層 服務三層 Web-AP-DB
問什麼：請求怎麼流動、資料庫該收在哪一層
產出：使用者不直連資料庫的呼叫路徑、集中在應用層的存取紀錄點
↓ 服務擺好了，誰可以進來
第 3 層 身分與收口控管
問什麼：誰能連、從哪連、連去哪，事後查不查得到
產出：少數受控出入口、集中的身分驗證與存取紀錄
↓ 進得來也擋得住，那壞掉的時候呢
第 4 層 維運韌性
問什麼：單點故障在哪、多久接得回來、最多能掉多少資料
產出：HA／備份／異地備援的分工，以及寫下來的 RTO、RPO
圖示對應上方五層，只是概念示意，不代表任何實際系統或作業流程。
**重點：**這張警政網路架構圖攤成五層：第 0 層先定要保護什麼、能忍多久中斷，畫不出框卻決定其餘四層強度；第 1 層把爆炸半徑切小，分區是受控互通，防火牆正面表列、保護的是資料區而非資料庫本體；第 2 層 Web－AP－DB 讓使用者不直連 DB，每次存取都留得下紀錄；第 3 層收口，把出入口收斂到查得到的少數節點；第 4 層分清備份、備援、異地備援，用寫下來的 RTO／RPO 衡量容災。整條線換到的是出事時說得清楚，成本現在付、好處等失效那天才兌現。拉扯在分區越細跨區例外越多、收口等於自己長回來，而備份最容易回報成功卻還原不回來。
往下追問：這五層裡哪一層失效的影響最難收拾、為什麼？RTO 與 RPO 沒寫下來的時候，業務端與資訊端心裡的數字通常差多少，這個落差會在哪一刻爆出來？
今日結論
第一天收穫都在觀念上：網路架構的通用設計邏輯（分區、縱深防禦、三層式、收口、受控互通、維運韌性）、一條從背景收斂到備援的思考順序，還有做筆記本身就要去識別化。最後那點最不像技術，卻決定我後面每天的筆記能寫成什麼樣。至於分區要切多細才夠，我還沒有答案，猜本來就沒有標準解。
我的反思
《資通安全管理法》第 3 條 對資通安全的定義，加上 第 7 條 對責任等級與防護措施的要求，我第一次讀完沒什麼感覺，覺得都是原則性的話。對著架構圖再看才發現，分區、權限控管、備援回答的是同一組問題：這批資料多機敏、這項業務多重要、機關能承受多少風險。之後我看架構圖會先找「它要保護什麼、失效時影響誰」，設備最後才問。
國家資通安全研究院的零信任架構資料 我來回看了兩遍。收穫是把零信任當成每次都要重問的問題：這次存取真的需要嗎、身分與裝置條件合不合理、萬一其中一個控制失效，影響壓不壓得住。用這個角度回頭看「收口」，才知道它在整條設計裡的位置。
我讀起來，這套架構是拿效率換可查核性。分區、收口、三層式每多一層，延遲和維運成本都跟著上去，跨區要資料對開發者也很煩。我覺得這筆帳在承載全國性資料的機關算得過來，一次外洩的代價太高；照抄到小型系統就過重了。這是我自己推的，還沒看過成本數字，可能想得太簡單。
我自己的理解是，架構設計就是在分配信任：預設能互通、能看見、能操作的範圍越大，出錯時外溢的成本就越高。至於要收多緊才合理，我沒有答案，只覺得業務資產、信任邊界、失效影響要一起看，光比速度或設備數量會漏掉最貴的那塊。
本日對應主題
- 警政資訊系統與資安概念
- 資通安全法規體系與事件應變：把架構與治理概念對應到實際條號、責任等級與應辦事項。