外觀
警政資訊系統與資安概念
本頁整合 7/02～7/03 的學習主線。我原本以為資訊系統就是一套軟體，看下來才知道服務、資料、身分、資安與維運得綁在一起管。實際拓樸、設備、帳號與流程不公開。
先講重點
大型公務系統要分層，是因為服務、資料和權限的風險不一樣，擺開才好保護、也才查得動。資安治理的起點是把資產和風險盤出來，控制、監測、應變、稽核、改善全接在這份清單上。零信任我一開始想得太玄，它就是不預設任何人、裝置、連線天生可信。韌性最實用的一句：有備份不算數，要問多久能接回服務、最多能掉多少資料。
一、系統治理的五個面向
佐證：資通安全責任等級、維護計畫、稽核與事件應變可對照 《資通安全管理法》第 7、13、15、17 條。
服務面問系統要支持什麼業務與使用情境，做法是把服務目標、使用者與例外流程定義清楚。資料面問敏感度、用途與保存責任，對應分類、最小必要、品質管理與保存規則。身分與權限問誰在什麼情況下可以存取哪些資源，靠身分驗證、角色授權、權限複核與必要日誌撐住。
資安與韌性問怎麼降低入侵、竄改、外洩與中斷的風險，分區、更新、備份、監控、應變與演練都算在這一格。維運與改善問上線之後怎麼知道系統還是安全、可用、符合需求，答案是稽核、回饋、事件檢討與持續改善。
列完才反應過來，「系統能不能用」問的是制度、責任跟使用情境搭不搭得起來，技術只佔一格。這對資訊背景的人是陷阱：五格裡我最熟的就是技術，也最容易把整題化約成技術題。
二、架構設計：先看服務與風險，再選擇元件
大型架構的基本思路：
text
業務需求 → 資料與風險盤點 → 邏輯分區 → 身分與流量控管 → 監測、備援與改善| 設計原則 | 意義 | 不應誤解為 |
|---|---|---|
| 網路分區 | 依用途與敏感度隔離服務與資料，限制不必要互通。 | 所有區域完全隔絕、無法支援業務。 |
| 縱深防禦 | 以多層控制降低單一防線失效的風險。 | 只要設備越多就一定更安全。 |
| 三層式服務 | 將使用者介面、應用邏輯與資料存取分開管理。 | 任一實作都必須使用固定技術或拓樸。 |
| 收口與可追溯 | 將重要出入口與管理行為集中到可控、可記錄的位置。 | 只記錄日誌就能解決所有資安問題。 |
| 最小權限 | 只提供完成工作所需的存取範圍。 | 一次授權後永遠不需要檢視。 |
這五條會互相打架的是「網路分區」和「收口與可追溯」：分區切越細，跨區正常流量越多要開例外，例外一多，收口點等於自己長回來。真要排順序，我會先把收口和日誌做紮實再慢慢細分。沒有紀錄的分區，出事時說不出是哪一段破的。
三、資安治理是一條持續循環
佐證：資通安全的定義涵蓋機密性、完整性與可用性，見 《資通安全管理法》第 3 條。
盤點先確認有哪些服務、資料、使用者與相依關係，產出是資產與責任清單。評估挑出最值得優先處理的威脅、弱點與失效情境，產出風險排序與改善計畫。控制回答怎麼降低未授權存取、竄改、外洩與中斷，落成管理、技術與人員三類措施。監測與應變要能及早發現異常並協調處置，靠日誌、告警、通報與應變流程。稽核與改善確認措施有效、避免同類問題重複發生，留下稽核結果、改善追蹤與演練紀錄。
這一圈裡我最有感的是盤點。清單過期一年，後面四段都在對著已經不存在的資產做事，而清單沒人排時間維護多半就會過期，跟長年沒更新的架構圖是同一種東西。
四、資料與權限治理：便利性必須受目的限制
佐證：公務機關蒐集、處理與利用個人資料，須符合特定目的與必要範圍，見 《個人資料保護法》第 5、15、16 條。
資料治理不等於一律鎖死。合法、必要、事後查得回來，撐住這三件，資料才能支援業務：
目的限制問為什麼需要這筆資料、跟法定職務或明確服務目的合不合。最小必要問是不是只給了完成任務所需的欄位、期間與人員範圍。權限分級問不同角色是不是只看得到自己工作要用的部分。查得回來問重要的查詢、修改與匯出有沒有留下必要的紀錄與稽核。生命週期問資料怎麼保存、更新、限制使用，以及依規定刪除。
這五題跟資料庫權限設計遇到的是同一批問題，差別在預設答案。寫後端習慣先開一組能查全表的權限、之後再慢慢收，公務資料反過來，開出去容易，外洩之後收不回來。
五、零信任與韌性：兩個互補的觀點
零信任問這次存取還值不值得信任；韌性問另一端：擋不住、服務斷了，影響壓不壓得住、多久接得回來。兩題湊起來，安全才從「守住某個點」變成要一直做的事。
零信任問這一次存取的身分、裝置、位置與行為符不符合風險條件，方向是持續驗證、分段存取、最小權限與必要日誌。高可用性問單一設備或服務失效時關鍵服務撐不撐得住，做法是消除單點故障、備妥替代路徑、把切換責任講明。備份與復原問資料誤刪、毀損或事件之後回不回得來，重點在可驗證的備份、還原測試與復原順序。異地韌性問區域性事件發生時還有沒有可行的服務與資料復原策略，得依業務需求規劃替代場域並演練。
四項裡我最不信任的是備份與復原，因為只有它會出現「每天都在跑、真要用時才發現不能用」。
RTO 和 RPO 的用途，是讓業務端和資訊端對「多久要恢復」「最多能掉多少資料」講同一組數字。少了它，備援很容易變成採購清單上的一個品項。我會更進一步說：沒定過 RTO/RPO 的備份等於沒驗過的程式碼，看起來寫好了，跑下去才知道會不會炸。
六、系統落地與委外治理
佐證：公務機關委外辦理資通系統建置、維運或服務時，應監督受託者的資安管理機制，見 《資通安全管理法》第 10 條。
系統上線不是終點。比較完整的落地循環是：
- 釐清業務問題與成功條件。
- 小範圍試辦，確認流程、例外與使用者負擔。
- 把權限、資料品質、資安、維運與責任寫進規格和契約。
- 上線後看使用情況、事件、稽核與回饋。
- 依風險持續修正，上線只是其中一個檢查點。
七、資料共享與 API 治理
跨系統資料共享，串得起來通常不是最難那關。難的是串之前要先講清楚目的、誰負責、出事怎麼收：
何種資料可以共享，要先盤點資料敏感度、法定依據與去識別化的可能性。誰能使用，以角色、用途、授權與必要性限制存取。如何確保品質，得建立資料定義、更新責任、錯誤更正與版本管理。如何發現濫用，留存必要日誌，並建立異常檢視與稽核機制。
自己寫過介接之後，我覺得最容易被跳過的是品質那題。沒人負責品質的 API 不會壞在串接當下，會壞在半年後某個欄位悄悄改了語意——兩邊都回 200，錯的資料一路傳下去，等有人發現已經很難回推從哪一版開始歪。
這篇的分層結構
讀這篇的順序是先問要保護什麼、最後問壞掉怎麼收，中間每一層都拿上一層的清單當輸入：
text
第 1 層 業務目的與資產風險盤點
問什麼：系統要支持什麼業務、有哪些服務與資料、誰需要存取、能承受多久中斷
產出：資產與責任清單、資料敏感度分類、風險排序與改善計畫
↓ 清單決定下面每一層要做多細
第 2 層 架構分區與收口
問什麼：哪些用途該隔開、重要出入口收在哪、單一防線失效怎麼辦
產出：依用途與敏感度切出的邏輯分區、集中的出入口與管理行為紀錄點
↓ 框架擺好了，接下來是誰能進來、碰得到什麼
第 3 層 身分、權限與資料治理
問什麼：誰在什麼情況下存取哪些資源、給出去的欄位與期間是不是只到必要
產出：身分驗證與角色授權、權限複核紀錄、目的限制與保存刪除規則
↓ 授權給出去了，怎麼知道它沒被濫用
第 4 層 監測、應變與稽核
問什麼：異常多久發現得了、誰處置、同類問題有沒有再犯
產出：日誌與告警、通報與應變流程、稽核結果與改善追蹤紀錄
↓ 發現得了，也擋不住的時候呢
第 5 層 韌性、委外與共享治理
問什麼：多久接得回來、最多能掉多少資料、受託者與介接方由誰監督
產出：寫下來的 RTO 與 RPO、驗過的還原測試、契約裡的資安與品質責任第 1 層：清單先立起來。 盤點要確認有哪些服務、資料、使用者與相依關係，產出是資產與責任清單；評估再挑出最值得優先處理的威脅、弱點與失效情境。五個治理面向也從這裡起手：服務目標、使用者與例外流程要定義清楚，資料要講敏感度、用途與保存責任。這層我最有感的是清單會過期，過期一年，後面四層都在對著已經不存在的資產做事。
第 2 層：先收口再細分。 網路分區依用途與敏感度隔離服務與資料，縱深防禦用多層控制降低單一防線失效的風險，三層式服務把使用者介面、應用邏輯與資料存取分開管理。這層我一開始也把分區讀成完全阻絕，要的其實是受控互通。分區和收口會互相打架：切越細，跨區正常流量越多要開例外；例外一多，收口點等於自己長回來。沒有紀錄的分區，出事時說不出是哪一段破的。
第 3 層：預設答案要反過來。 目的限制問這筆資料跟法定職務或明確服務目的合不合，最小必要問欄位、期間與人員範圍有沒有超出，權限分級問各角色是不是只看得到自己工作要用的部分。這幾題跟資料庫權限設計是同一批問題，差別在預設答案：寫後端習慣先開一組能查全表的權限再慢慢收，公務資料開出去容易，外洩之後收不回來。零信任也落在這層，不預設任何人、裝置、連線天生可信，每次存取重新判一遍。
第 4 層：讓控制被驗證。 監測與應變要能及早發現異常並協調處置，靠日誌、告警、通報與應變流程；稽核與改善確認措施有效，留下稽核結果、改善追蹤與演練紀錄。這層的價值在於它是唯一會回頭修改上面三層的地方，事件檢討的結論要能改清單、改分區、改權限，否則就只是留檔。看下來最容易空轉的是日誌：記了沒人看，等於花成本養一份沒人讀的紀錄。
第 5 層：承認擋不住的那天。 高可用性問單一設備或服務失效時關鍵服務撐不撐得住，備份與復原問資料誤刪毀損之後回不回得來，異地韌性問區域性事件之後還有沒有可行策略。四項裡我最不敢只看報表的是備份，只有它會出現「每天都在跑、真要用時才發現不能用」。RTO 與 RPO 要白紙黑字寫下來，業務端與資訊端才會對同一組數字說話。委外與資料介接也收在這層，受託者的資安管理與資料品質責任要寫進規格和契約。
層與層之間的拉扯最明顯的是第 3 層與第 4 層。權限收得越緊，日常業務越常需要例外授權，而例外授權多半沒人回頭複核，稽核那層看到的就只剩一堆「已核准」；權限開寬一點，日誌反而看得出誰在什麼時候動了什麼。我的排法是先把重要出入口與管理行為的紀錄做紮實，再逐步收權限，因為收得動的前提是先知道誰真的在用。
這條線換到的是事後說得清楚。每一層都留下能被第三人檢視的東西：清單、規則、紀錄、稽核結果、還原測試。代價是全程都在花時間維護，而維護沒有上線那種看得見的成果。邊界在規模：承載全國性資料的機關划得來，小型系統照抄五層會被治理成本壓垮。
往下可以展開的追問：資產清單過期到什麼程度，後面四層就開始白做？權限例外累積到多少，稽核那層等於失效？「控制有沒有效」在內外稽核意見不一致的時候，為什麼、又在哪一刻應該以外部意見為準？
我的反思
《資通安全管理法》第 10 條 的委外治理、第 13 條 的維護計畫、第 17 條 的事件通報與應變，我是分三次讀到的。擺一起才看出它們指向同一件事：受託者、資料、權限、維運、演練、改善要接成一圈。「買到設備」跟「完成資安」差的就是這圈。
資料共享我放回 《個人資料保護法》第 5、15、16 條 的目的與必要性看。介接成功只是第一步，難答的是：為什麼要共享、誰能用、何時該停、濫用時誰先發現。這幾題靠技術文件答不了，得問業務端。
現在讀一個資訊系統，我會先問五件事：要保護什麼、資料怎麼流、控制能不能驗證、出錯誰處理、斷線怎麼恢復。這組比看設備型錄有用。不過「控制有沒有效」該由誰認定、內外稽核對不上時聽哪邊，我還沒想清楚。
核心結論
「連得通」只是最低標。要撐住的是安全、可用、事後查得回來、壞了救得回來，而且跟業務目的對得上。這幾項同時成立，系統才算長期可用。