外觀
2026-07-03 警政資訊系統與資安
🏛️ 實習單位：內政部警政署（警政資訊與資通安全）｜警政署階段第 2 天；前一天的架構基礎見 2026-07-02 日誌。
本日從治理角度看公務資訊系統：系統規劃、資通安全、資料保護與第一線使用情境怎麼互相影響。內容聚焦可公開的通用原則；個別系統配置、案件、帳號與流程細節均不納入筆記。
今天大致弄懂了什麼
我原本以為資訊單位就是把功能寫出來。實際上力氣多半花在把業務目的、法規、資料治理和使用情境揉成一個維運得動的服務。資安也不是做完一次檢測就結束，它是責任分級、維護計畫、應變、稽核、改善一路轉下去的循環。
電子化也一樣：把紙本搬到螢幕只是外觀，真正變的是流程、權限、紀錄與查核被一起標準化。越靠近第一線，目的限制、最小權限、裝置安全和事後稽核就越要在設計階段放進去。
示意：資安組態基準、弱點管理與零信任的日常把關。此圖僅為概念示意，不代表任何實際系統或作業流程。
一、資訊系統要當成治理服務來看
佐證：公務機關資通安全責任等級、維護計畫與事件應變可對照 《資通安全管理法》第 7、13、17 條。
公務資訊工作是把政策目標、法規、資料保護、資安控制和使用者流程整合成能長期運作的服務，寫程式只是其中一段。我自己判斷一套系統成不成功時，看有沒有上線沒意義，要看它有沒有被正確使用、查不查得動、救不救得回來。
系統治理的四個面向
業務與服務問的是這套系統要改善哪一項工作，回應方式是先把服務對象、流程瓶頸與成功條件定義清楚。資料與權限問的是哪些資料能由誰、在什麼目的下使用，靠分級授權、最小權限、目的限制與權限複核來收斂。資安與韌性問的是怎麼防止未授權存取、竄改、服務中斷與資料外洩，對應到身分驗證、日誌、分區、備份、應變與稽核。使用與維運問的則是第一線能不能在合理負擔下正確使用，做法是試辦、蒐集回饋、教育訓練、可用性設計與持續改善。
這四個面向看起來平行，我讀起來第二個是其他三個的地基。資料分級沒定下來，服務範圍講不清楚、日誌不知道要留哪些欄位、第一線也不知道自己看到的東西能不能轉給別人。
四個面向少一個都容易出事。只顧效率、放掉權限與稽核，濫用空間就出現；只顧安全、不管第一線怎麼用，使用者遲早繞過制度，那等於什麼都沒管到。
二、資通安全是持續治理，而非一次性專案
佐證：資通安全的定義涵蓋機密性、完整性與可用性；公務機關並須建立維護、稽核與應變機制，見 《資通安全管理法》第 3、13、15、17 條。
我原本以為資安就是防火牆加定期檢測。實際上是一條要一直轉下去的管理循環：
text
盤點服務與資料 → 評估風險 → 落實控制措施 → 監控與應變 → 稽核與改善盤點要答的是有哪些關鍵服務、資料與相依關係，做法是把資產、資料與權限的責任歸屬建立起來。防護要答哪些風險需要優先控制，落到身分驗證、權限控管、分區、更新與備份。偵測要答怎麼及早發現異常，靠的是保留必要日誌、設置告警並定期檢視。日誌只留不看，等於沒有偵測。
應變要答的是發生事件時由誰決策、通報與復原，這些流程必須事前談好，包括通報、處置、復原與對外溝通。最後是改善：怎麼避免同類問題再發生，以事件與稽核結果回頭更新控制措施與訓練內容。整條循環真正難的，我看是最後一段接回第一段，因為改善通常要動到當初的盤點結果，而那份清單多半已經沒人在維護了。
CIA 三要素我以前只當考題名詞背，順著這條循環走一遍才對得起來：機密性管誰看得到，完整性管紀錄還能不能信，可用性管需要時服務給不給得出正確結果。
三、勤務與行政電子化的真正價值
佐證：公務機關處理個人資料，應符合特定目的、必要性與正確性原則，見 《個人資料保護法》第 5、15、16 條。
電子化不只是把紙本表單改成線上填寫，真正的價值是讓流程規則、權限、紀錄與查核被一致執行。
流程一致讓欄位、核准與交接方式比較容易標準化，代價是規則訂得太死，第一線的例外情境就無處可去。紀錄可追溯能保留必要的時間、身分與處理歷程，但同一個機制很容易順手多蒐集、多保存一些超出目的所需的資料。權益可查核讓工時、交接或服務紀錄能依制度檢視，前提是資料正確性、權限與異常更正程序都講清楚。業務可持續則是在人員異動、裝置或網路出狀況時流程還接得下去，這仍然要靠備援、復原與使用者支援撐著。
四項的風險有個共同形狀：價值來自「把東西固定下來」，風險也來自同一個動作。我覺得例外處理是其中最該在設計階段就想的。例外沒有出口，使用者就會拿正常欄位硬填，結果那份看起來很完整的紀錄反而不能信。
所以「填得更快」只是最表面的一項。我更想問的是工作紀錄有沒有變完整、例外的處理過程看不看得見、出事時找不找得到該負責的人。
一個把制度接到權益的例子
佐證：津貼條件見行政院核定「警察、消防、移民及空中勤務機關輪班輪休人員深夜危勞性勤務津貼支給表」（113/5/17 核定、113/6/1 生效），可對照 內政部相關說明；地方層級的電子化案例見 臺北市政府警察局重大建設計畫。
深夜危勞性勤務津貼是我覺得最能說明「制度細節必須做對」的例子。它自 113 年 6 月 1 日起實施，每人每小時 100 元，但條件相當緊：對象限輪班輪休人員，勤務要在每日 0 時至 6 時、於駐地外實際執行、且無法休宿，不含督導勤務；勤務類型是巡邏、臨檢、守望、專案勤務及其他實際外出執行之勤務。時數以小時計，同一時段未滿 1 小時者以 1 小時計。
這幾個條件缺一不可，而它們全部得從勤務紀錄裡讀出來。輪班身分、時段、是否在駐地外、有沒有休宿、屬於哪一類勤務，任何一項在系統裡沒有對應欄位或填得不準，核算就接不上。從資料的角度看，津貼規則其實是一組必須被完整記錄的欄位規格，而不是事後拿報表加總就能算出來的東西。
我查資料時也踩到一個坑。一開始看到的整理把警、消、移民、空勤四類機關的例子混在一起寫，於是「救災救護」「空中飛行」也被列進警察的適用勤務裡，但那是消防與空勤總隊的部分。二手整理把不同機關的條件合併敘述，讀的人很難察覺，這也是為什麼津貼、加班費這種直接影響權益的規定，我後來一律回去找核定版本。
地方層級也有各自的做法，例如臺北市政府警察局把「建置應勤簿冊電子化系統」列為重大建設計畫，方向是把派出所常用簿冊電子化、讓員警用電腦或行動載具登載。至於中央層級的整合進度與各地方的建置情形，我沒有查到足以下判斷的公開資料，所以這裡只記錄查得到的部分。
四、從需求到維運：系統落地的五個步驟
關鍵多半在有沒有一開始就把第一線需求和資安要求一起放進來。上線後再補，成本高很多：
- 確認問題：找出真正的流程瓶頸與服務目標。
- 小範圍驗證：用試辦或情境測試檢查流程、介面與例外處理。
- 制度化控制：把權限、日誌、資料品質與應變責任寫進制度與系統。
- 觀察使用結果：看錯誤率、處理時間、使用者回饋與稽核結果。
- 持續修正：依新風險、新法規與實際使用情況調整。
這條線接得上前一天的「需求 → 風險 → 架構 → 韌性」。
第 3 步在我看來最容易被跳過。權限、日誌、資料品質不會讓 demo 好看，時程一緊就先砍，但它們正好是事後查得動、救得回來的唯一依據。我覺得該把它們當驗收條件，而不是「有空再補」的清單——實務上會不會被接受，我還不知道。
五、行動化與資料治理的共同邊界
走向行動化與跨機關協作，方便是真的方便，但資料摸得到的地方也變多。行動載具、跨系統查詢、資料介接最後都回到同一組問題：業務目的明不明確？給出去的是不是只有工作需要的那些？事後查不查得到？
四個治理原則放到行動化服務上都有各自的解讀。目的限制是每一次查詢與使用都要能對應到合法、明確的業務目的；最小權限是依角色與情境給出必要的那些資料，而不是全面開放；裝置與身分安全是讓人、裝置與連線三者都能被適當驗證與管理；可追溯性則是保留必要的操作與異常紀錄，供後續查核與改善。
前三項是事前的閘門，第四項是事後的證據。我目前的想法是，行動化真正加難度的是「情境」這個變數：同一個人、同一支裝置，在辦公室與在外面查同一筆資料，該不該一樣，我還沒想清楚要用什麼條件去判。
這一天的分層結構
這天的內容疊起來是一條從業務目的到權益核算的線，上一層沒定好，下一層就只能猜：
text
第 0 層 業務目的與服務對象
問什麼：這套系統要改善哪一項工作、服務誰、成功條件怎麼算
產出：服務對象與流程瓶頸的描述、上線後要看的成功條件
↓ 目的定下來，才知道要碰哪些資料
第 1 層 資料分級與權限
問什麼：哪些資料能由誰、在什麼目的下使用
產出：資料分級結果、角色與授權對照、權限複核的做法
↓ 範圍畫定了，控制措施才有對象
第 2 層 資安治理循環
問什麼：關鍵資產在哪、先控哪些風險、異常怎麼發現、出事誰決策
產出：資產與相依關係清單、日誌與告警設定、通報復原分工、改善事項
↓ 控制寫進系統，第一線怎麼用
第 3 層 電子化的流程與紀錄
問什麼：欄位、核准、交接怎麼固定下來，例外從哪裡走
產出：標準化的欄位與核准路徑、時間與身分的處理歷程、例外通道
↓ 紀錄固定了，能接到什麼
第 4 層 權益與查核
問什麼：哪些權益規定直接吃系統裡的欄位，算不算得出來
產出：把津貼這類條件翻成的欄位規格、核算時查得回去的依據
圖示對應上方五層，只是概念示意，不代表任何實際系統或作業流程。
**重點：**這天的資訊系統治理疊成五層：第 0 層先講清楚要改善哪件事、服務誰，這層不進系統圖卻框住其餘四層；第 1 層資料分級是其他三面的地基，分級沒收斂，服務範圍、日誌欄位、第一線能不能轉手都各憑感覺；第 2 層資安治理循環——盤點、防護、偵測、應變、改善，日誌只留不看等於沒有偵測，最難是改善接回盤點；第 3 層電子化把流程、權限、紀錄固定下來，價值和風險來自同一個動作，例外沒出口紀錄就失真；第 4 層權益規定其實是一組欄位規格，深夜危勞性勤務津貼的條件缺一不可、全得從勤務紀錄讀出來。整條換到查得動、救得回，代價是每層都在第一線加手續，落地五步裡第 3 步最容易被砍。
往下追問：例外情境該用什麼形式在系統裡留出口，才不會逼使用者拿正常欄位硬填？把權限、日誌與資料品質當成驗收條件，時程一緊的那一刻擋不擋得住？
今日結論
一天下來，我對「系統成熟」的判準整個換掉了。功能多寡幾乎沒有參考價值，能不能把業務目的、資料治理、資安控制和使用者情境串成一個會持續修正的服務才是差別。從昨天的架構到今天的電子化，被管的一直是同一件事：資料怎麼被正確使用、怎麼被保護、事後查不查得動。至於制度細到什麼程度會把第一線卡死，我還沒想清楚。
我的反思
《資通安全管理法》第 13 條 要求的維護計畫，配上 第 17 條 的通報與應變機制，讀完才意識到「上線後再補救」在公務機關根本行不通。計畫得先把資料種類、系統規模、責任分工和事件處理寫成別人看得懂的樣子；否則出事那一刻，光釐清誰判斷、誰處理、哪些紀錄要留就先耗掉最寶貴的時間。
再翻 《個人資料保護法》第 5 條、第 15 條 與 第 16 條，我覺得「行動化方不方便」這種問法太粗。拆開來應該是：這筆資料為什麼必要、誰在什麼情境下需要看見、欄位和保存期間能不能再縮、異常時查不查得回是誰動的。用這四題問一遍，比看功能表有感多了。而且這四題本來就是 schema 和權限設計要先回答的東西，只是法規把它寫成義務。
還有一點沒有結論。權責清不清楚、例外有沒有處理方式、使用者懂不懂系統的限制，這些都影響安全，卻不是程式或設備能解決的。這是我最不確定的部分——寫程式的人該不該承擔這一段。我暫時只能提醒自己，看電子化功能時把資料生命週期、角色分工和復原能力一起看，別把資安擺到最後一關。
法規與官方來源
- 法規與官方來源索引：回查資通安全治理與個人資料保護的現行官方依據。
本日對應主題
- 警政資訊系統與資安概念
- 資通安全法規體系與事件應變：責任等級、維護計畫 13 項與事件通報應變時限。
- 警政科技政策與計畫治理：政策與預算怎麼變成系統規格。
- 政府開放資料與API治理：資料要對外開放時的原則、授權與詮釋資料要求。
同系列日誌
知識結構圖
