Appearance
警政資訊系統與資安概念
這是將實習中學到的通用（教科書級）資安與網路架構觀念，整理而成的一份通用技術主題筆記。授課提及的內部實際配置屬敏感資料，本筆記一律實施去識別化，不記錄任何特定機關的實際 IP、設備型號、線路數、VPN 節點、實際防火牆規則或異地備援地點，僅保留可公開的原則與防護架構。
一、 資通安全的防護核心：CIA 三要素與 STRIDE 威脅模型
佐證：政府機關資安治理可對照 《資通安全管理法》第 3 條 對資通系統、資通服務與資安事件的定義。
資訊安全的基本目標是維護資訊系統與資料的機密性、完整性與可用性。為了系統性防禦，實務上常結合 STRIDE 威脅模型 進行架構檢視。
（一） 三要素與威脅對照表
佐證：個資機密性與最小必要可對照 《個人資料保護法》第 5 條；資安事件處理可對照 《資通安全管理法》第 16 條。
| CIA 三要素 | STRIDE 威脅項目 | 威脅定義 | 警政/公務機關實務防護手段 |
|---|---|---|---|
| 機密性（Confidentiality） | 資訊洩漏（Information Disclosure） | 未授權者取得機密個資或刑案紀錄。 | 角色存取控制（RBAC）、多因子驗證（MFA）、資料行加密（AES-256）、日誌審計。 |
| 完整性（Integrity） | 竄改（Tampering） 否認（Repudiation） | 惡意修改筆錄數據、竄改系統Log，或事後否認登入查詢行為。 | 數位簽章、SHA-256 雜湊值校驗、不可抹除之集中式日誌儲存（WORM 介質）。 |
| 可用性（Availability） | 拒絕服務（Denial of Service） | 110報案系統或派遣系統因 DDoS 攻擊或斷電癱瘓。 | 負載平衡、抗 DDoS 流量清洗服務、雙機備援（HA）、異地機房。 |
| 身分與權限（Auth） | 身分冒用（Spoofing） 權限提升（Elevation of Privilege） | 冒用同仁帳密登入，或一般帳號提升至系統管理員權限。 | 零信任身分鑑別（FIDO2）、設備合規性核驗、定期特權帳號盤點。 |
二、 我國資通安全法規體系與國家資安治理
佐證：法制主軸可對照 《資通安全管理法》全條文。
我國已建立完整的《資通安全管理法》法規體系，以規範政府機關與特定非公務機關之資安作為。
（一） 國家級組織權責分工
佐證：主管機關可對照 《資通安全管理法》第 2 條；技術支援與官方資源可對照 國家資通安全研究院。
- 主管機關：**數位發展部（數發部）**負責國家級資通安全政策之制定與整體規劃。
- 執行機關：**數位發展部資通安全署（資安署）**負責政府機關資安稽核、防護監督、事件通報與應變演練之落實執行。
- 技術支援機構：**國家資通安全研究院（資安院）**提供國家資安威脅情資分析、新型防護技術研究及資安事件技術調查支援。
（二） 資通安全責任等級（A～E 級）之判定基準
佐證：責任等級屬資安法與相關子法體系，主法可先對照 《資通安全管理法》第 7 條。 政府機關依據業務屬性、個資保有量、跨機關資訊系統之多寡等客觀指標，核定為不同的資安責任等級：
- A 級：涉及國家安全、外交、國防，或維護關鍵基礎設施（CI）核心系統，或提供全國性跨機關共用系統、全國性個人資料庫（如戶役政、警政核心庫）。
- B 級：保有大規模個人資料（如數十萬筆以上），或提供區域性跨機關共用系統者。
- C、D、E 級：依業務範圍侷限於機關內部、保有小規模個資或不具備核心資通系統等指標，依序由高至低核定。
- 實務注意：較高責任等級機關（A、B 級）必須建立內部專責資安單位，定期實施紅隊演練、資安弱點掃描、導入 ISMS（ISO/IEC 27001）驗證，並全面導入零信任架構（ZTA）。
（三） 資安事件分級定義與法定通報時限
佐證：資安事件通報與應變可對照 《資通安全管理法》第 16 條。
國家資通安全事件分級簡表
| 事件級別 | 影響範疇定義 | 核心判定標準 |
|---|---|---|
| 一級事件 | 輕微影響 | 非核心業務系統受損，且未涉及個資或機密外洩。 |
| 二級事件 | 中度影響 | 非核心系統癱瘓，或外洩一般性個人資料（非機密個資）。 |
| 三級事件 | 嚴重影響 | 核心資通系統停擺、關鍵基礎設施局部受損，或外洩大規模個資/機密資料。 |
| 四級事件 | 極嚴重影響 | 涉及國家安全、國防外交機密外洩，或關鍵基礎設施全面停擺。 |
- 法定通報應變時限：
知悉資安事件 ──> [1 小時內] 網路平台完成資安通報 ──> [依事件等級，如 36 小時內] 實施復原與損害控制 ──> [1 個月內] 提報正式調查、處理及改善報告 (結案)
三、 政府資安防護框架與四大防護策略
佐證：GCB 對照 國家資通安全研究院 GCB 專區；VANS 對照 資安署 FAQ；ZTA 對照 資安院 ZTA 專區。
結合防禦縱深，公務機關建置之資安防護框架可整理為「進不來、出不去、打不開、查得到」四大面向：
| 防護策略 | 核心目標 | 警政/公務機關通用技術工具與運作原理 |
|---|---|---|
| 進不來 | 阻絕威脅於邊界外 | 1. 防火牆（Firewall）/ WAF：過濾未授權之網路與 Web 攻擊封包。 2. GCB（政府組態基準）：強制終端實施最低安全設定（如限制密碼強度、停用不安全服務）。 3. VANS（弱點通報系統）：將機關資訊資產與 CVE 漏洞資料庫自動對照，掌握漏洞修補進度。 |
| 出不去 | 防止內部洩密與惡意橫向移動 | 1. Proxy（代理伺服器）：管控內部上網流量，阻斷惡意中繼站（C2）連線。 2. NAC（網路存取控制）：自動比對設備特徵，未經准入核可之設備無法接入內網。 3. 即時入侵偵測（IPS/IDS）：偵測惡意掃描與橫向移動流量。 |
| 打不開 | 確保資料縱使外洩也無法解讀 | 1. 傳輸加密：全網實施 HTTPS，採用 TLS 1.2/1.3 加密傳輸通道。 2. 儲存加密：資料庫實施資料行加密（Column-level Encryption）與文件加密。 |
| 查得到 | 留存軌跡以供稽核與案情還原 | 1. SIEM（安全資訊和事件管理）：集中收集防火牆、伺服器、AD 日誌進行關聯分析。 2. SOC（資安監控中心）：委託專業團隊進行 24 小時監控與異常告警。整個 SOC 生命週期包含：日誌採集 ─> 正規化解析 ─> 關聯規則比對 ─> 告警產生 ─> 分析師研判 ─> 事件應變。 3. 封包側錄（如 Arkime）：在網路核心點側錄完整封包流量，防止駭客擦除系統 Log。 |
零信任架構（Zero Trust Architecture, ZTA） 依據 NIST SP 800-207 標準，零信任架構強調「永不信任，持續驗證」。防護分為三大階段/支柱：
- 身分鑑別（Identity）：採用多重因素驗證（MFA）與 FIDO 免密碼認證，確保使用者身分。
- 設備鑑別（Device）：核驗登入設備之組態合規性（如是否安裝防毒、是否修補弱點）。
- 信任推斷（Trust/Policy）：每次存取皆依動態原則（Policy Decision Point, PDP）進行存取授權，避免一次登入、終身通行的資安盲點。
四、 大型公務機關網路架構之通用設計原則
佐證：架構分區、准入與日誌控管可回到 《資通安全管理法》第 10 條 的資通安全維護計畫概念。
為兼顧資訊安全與業務維運，大型機關的網路必須實施嚴格的分區、分層防禦。
（一） 實體與邏輯隔離
佐證：隔離與權限控管屬資安維護計畫的一部分，可對照 《資通安全管理法》第 10 條。
- 網段隔離：內網（辦公網）與外網（網際網路）原則上實施邏輯隔離。在實務上，常透過虛擬區域網路（VLAN）進行邏輯劃分，並利用虛擬路由轉發（VRF）技術，在同一台核心交換器上實現路由表的完全獨立與隔離。
- 正面表列（White-list）：內外網之間的任何資料交換，嚴禁全面互通，必須經由特定防火牆並實施正面表列（限制特定來源 IP、目的 IP 與特定的通訊協定埠 Port）。
（二） 縱深防禦與網路分區（Segmentation）
佐證：資安事件防護、通報與應變可對照 《資通安全管理法》第 16 條。
- DMZ（非軍事區）：放置對網際網路提供服務之伺服器（如公開網站、郵件閘道器）。
- 內部辦公區：放置內部人員之辦公終端（PC/行動載具）。
- 資料庫核心區（DB Zone）：放置核心資料庫伺服器，此區必須處於最內層，嚴禁與外部網路直接連線。
（三） 三層式實體/邏輯架構（3-Tier Architecture）
佐證：此為通用架構設計原則；若涉及政府機關維運，仍需納入 《資通安全管理法》第 10 條 維護計畫。
網際網路 / 使用端 ──> Web Server (展示層) ──> AP Server (應用程式層) ──> DB Server (資料庫層)- Web Server：僅負責接收使用者請求與靜態網頁呈現，不得存放任何業務資料。
- AP Server：負責運算業務邏輯與權限核驗。展示層的請求必須交由 AP Server，由 AP Server 進行安全過濾（防範 SQL Injection, XSS 等攻擊）。
- DB Server：僅接受來自 AP Server 授權 IP 之查詢請求。Web Server 與 DB Server 之間嚴格禁止任何直接連線，且 AP 與 DB 之間須再加設一道內部防火牆進行安全阻絕。
（四） 統一收口與准入管理
佐證：零信任與准入驗證可對照 國家資通安全研究院 ZTA 專區。
- 統一對外閘道：所有對外網路連線、郵件收發集中至特定對外收口區，便於進行 DPI（深層封包檢測）與防毒過濾。
- 身分與設備控制：以活動目錄（AD）集中管理用戶帳號與群組原則；以網路存取控制（NAC）核驗存取設備之 MAC Address，不合規設備（如未裝防毒、外來筆電）自動導向隔離區（Quarantine Zone）。
五、 系統可用性與維運韌性設計
佐證：可用性與備援屬資安維護與營運持續的一部分，可對照 《資通安全管理法》第 10 條、第 16 條。
資安不只防駭，更要確保系統「在遭受打擊後能快速站起來」。
（一） 備份 vs. 備援 vs. 異地備援之層次定義
備 份 (Backup) ──> 重點在於「資料保存」。(僅將資料拷貝備份，服務中斷時無法立即接手運作。)
│
備 援 (Redundancy) ──> 重點在於「設備/服務接手」。(如防火牆 HA 雙機，當主設備損壞，備用設備自動 Failover。)
│
異地備援 (Disaster) ──> 重點在於「區域容災」。(主機房因地震或火災停擺，位於異地的備用機房可接手服務。)（二） 業務連續性指標與防禦評估
為了量化系統的維運韌性，必須定義兩個核心指標：
- RPO（復原點目標，Recovery Point Objective）：系統損毀時，允許流失的最長資料時間。例如 RPO 設定為 1 小時，代表資料備份頻率必須小於等於 1 小時，若系統損毀，最多僅流失過去 1 小時內產生的資料。
- RTO（復原時間目標，Recovery Time Objective）：系統中斷後，恢復服務所需的最長時間。
備援站台類型與指標對照表
| 站台類型 | 架構描述與資料同步機制 | RTO (回復時間) | RPO (允許流失資料) |
|---|---|---|---|
| 熱備援 (Hot Site) | 異地站台與主站台完全同步運作，資料即時鏡像鏡像同步（Replication）。 | 數秒至數分鐘 (自動切換) | 趨近於零 |
| 暖備援 (Warm Site) | 異地設備已建置但未啟用服務，資料採定時（如每小時）非同步備份傳輸。 | 數小時 | 視備份頻率而定 (例如1小時) |
| 冷備援 (Cold Site) | 僅有異地實體空間與網路線路，無備用主機或僅有未安裝系統之空機，資料需由磁帶或離線雲端還原。 | 數天 | 視離線備份週期而定 (例如24小時) |
- 單點故障（Single Point of Failure, SPoF）分析：在架構設計中，必須對每一段連線（使用者 ─> 防火牆 ─> 交換器 ─> 伺服器 ─> 儲存設備）進行單點故障評估，導入高可用性（HA）架構，確保無任何單一硬體失效會導致整體系統停擺。
- 定期演練：備份檔案若無回復演練即形同虛設；異地備援機房必須定期進行切換演練，確保資料庫同步時間（RPO）與系統回復時間（RTO）符合公務機關服務水準協定（SLA）要求。
六、 資料中心治理與智慧化維運
佐證：資料中心的營運持續、備援與稽核仍回到 《資通安全管理法》第 10 條 的資通安全維護計畫；管理制度面可對照 ISO/IEC 27001 資訊安全管理系統。
（一） 「機房」與「資料中心」的差別
一個容易被忽略、但很關鍵的觀念是：機房是放設備的房間，資料中心是一套治理制度。真正的資料中心不是「一間有很多伺服器的房間」，而是把重要資訊系統放在一個可管理、可監控、可稽核、可復原的環境裡，需要同時考量多個面向：
| 面向 | 治理重點 |
|---|---|
| 實體環境 | 建築空間、機櫃配置、冷熱通道分離 |
| 電力 | 市電、UPS 不斷電系統、發電機 |
| 冷卻 | 空調、水冷、散熱效率 |
| 消防 | 火災偵測、滅火設備、消防紀錄 |
| 門禁 | 管制區域、進出紀錄、權限控管 |
| 監控 | 儀表板、資源監測、異常告警 |
| 備援 | 備份、異地備援、災害復原演練 |
| 資安 | ISMS、稽核紀錄、存取控制 |
國際上有 TIA-942、Tier 分級等資料中心設計標準可作為參照；本筆記僅記錄通用治理觀念，不涉及任何特定機關的實際規模、設備型號或配置。
（二） 電力與冷卻的設計意義
- UPS 與發電機的真正目的不是「永不停電」，而是在斷電時爭取時間：讓系統維持短時間運作、進行安全降載，必要時讓伺服器正常關機，避免硬斷電造成設備或資料損壞。一句話記：UPS 是緩衝，發電機是延長時間，目標是避免硬斷電。
- 冷卻不是一次建好就永遠夠用。隨著伺服器運算密度與 AI 運算需求提高，發熱量增加，原本的冷卻設計可能需要調整。這也是資料中心邁向 AI 化時的重要課題——AI 伺服器通常更耗電、更高溫、更需要有效散熱。
（三） ISMS 是「制度」，不是一張證書
錄音課程中反覆強調的 ISMS（資訊安全管理系統，對應 ISO/IEC 27001），重點不是買設備、也不是拿一張證書，而是讓機關在日常維運中持續管理資安風險：系統有沒有盤點？帳號有沒有定期清查？權限是否符合最小權限原則？離職或調職人員帳號有沒有停用？是否有定期備份、弱點修補、事故應變流程與演練稽核紀錄？核心精神是——資安不是出事才處理，而是平常就要有制度、有紀錄、有檢查、有改善。
（四） 從標準化到智慧化維運：務實的導入順序
在人力有限、系統與資料量成長的現實下，維運自動化不只是「效率選項」，而是維持服務品質的必要手段。但導入有其務實順序，不能跳過中間直接談 AI：
流程標準化 ──> 作業自動化 ──> AI 輔助化 ──> 智慧化維運
（先把流程、 （把固定重複、 （用 AI 協助 （智慧監控、
權限、資料 可規則化的 產腳本、寫 自動告警分類、
定義清楚） 事交給工具） SOP、整理文件） 預測性維護、IaC）關鍵心得：流程不清楚時導入 AI，只會把混亂放大；流程標準化後導入 AI，才有機會真正提升效率。
- 帳號生命週期管理：帳號的建立、權限異動、定期清查、異常登入通報、離職停用與權限回收，是 ISMS 最重視的環節之一——帳號就像進入系統的鑰匙，鑰匙太多、沒回收、沒紀錄就是資安風險。
- Infrastructure as Code（IaC）：把環境設定寫成程式碼／設定檔，讓部署結果一致、可重複、可版本控管、容易稽核，減少人為錯誤。
- 導入 AI 的資料敏感限制：由於警政資料高度敏感，不能把內部真實資料直接送到外部 AI 平台。較務實的做法是用 AI 協助產生程式邏輯或腳本，回到機關內部環境、以範例或去識別化資料測試，並由人員檢查後再執行。
七、 數位警政策略（S.M.A.R.T.）與科技計畫治理
佐證：本節屬公開之政府數位政策與計畫治理概念；資安相關要求仍回到 《資通安全管理法》。
（一） 從「科技化」到「智慧化」
警政科技早期重點是讓警察工作科技化（行動載具、影像分析、勤務與查詢系統）；近年則走向智慧警政，把 AI、資料中心、資安防護與異地備援整合起來。差別可以理解為：以前是「讓員警有工具可以用」，現在是「讓整個警政體系可以智慧化運作」。
（二） 數位警政策略：S.M.A.R.T. 五面向
公開的數位警政策略常以 S.M.A.R.T. 統整五個面向：
| 面向 | 英文 | 重點 |
|---|---|---|
| S | Security | 強化資訊安全管理，保護警政系統與資料 |
| M | Mobility | 警政行動服務升級，讓勤務在現場也能處理 |
| A | AI | 情資再造、AI 輔助分析與辦案 |
| R | Resilience | 擴增系統與科技偵查韌性，出事仍能運作 |
| T | Training | 厚植數位警政訓練，讓人員會用科技工具 |
心得：S.M.A.R.T. 不是口號，而是提醒——警政科技若只重視設備，卻忽略資安、備援與人員訓練，就無法真正落地。
（三） 政府科技計畫的治理流程
科技建設不是「想做就能做」。實務上一項計畫要走完一整套治理流程，才可能落地：
先期作業（必要性、經費、效益、可行性審查）
──> 預算審查與編列
──> 系統建置（標案、開發、驗收）
──> 管考（進度填報、期中/期末績效、核銷）- 計畫有不同類型：同樣是警政科技建設，可能因經費來源與性質不同，分屬科技計畫、社會發展計畫或公共建設計畫，管考重點各異。
- 「計畫通過」不是結束，而是開始：真正花時間的是後續執行、進度管考、預算核銷與績效呈現。作業計畫（年度工作進度表）可以超前，但不能落後，因此編寫時通常保守一點。
（四） AI 在警政的未來與限制
未來 AI、API、Agent 都可能導入警政，但核心不是炫技，而是 安全、準確、可控、可追溯：警政資料敏感、不宜隨意上雲、模型需要安全環境、權限控管要嚴格、回答不能幻覺且必須能追溯資料來源。實務上也發現，政府資訊化最大的難點往往不是「會不會寫系統」，而是能不能取得、整合、合法使用跨機關資料——涉及各機關是否願意提供、API 規格是否一致、格式是否可用，以及權限、資安與法規限制。
八、 公部門資料開放與 API 治理
佐證：政府資料開放原則可對照 政府資料開放平臺 與數位發展部相關作業原則；去識別化與個資邊界對照 《個人資料保護法》第 5、16 條。
（一） API 是公部門資料的「自動化窗口」
把機關資料做成 API，等於開一個自動化資料窗口：過去要下載 Excel、查網站、寄公文或人工索取，導入 API 後外部系統可用固定網址、固定格式自動取得資料。因此 API 不只是程式技術，而是公部門資料治理、行政效率與跨機關協作的基礎。公部門資料 API 大致分兩類：
- 公開資料 API：如統計、法規、交通、氣象等，重點是開放格式、機器可讀、可重複利用。
- 機關間介接 API：機關之間同步資料，重點是身分驗證與存取控管（如來源 IP、API Key、驗證機制）。
（二） 從資料到 API 的六層流程
資料來源
──> 資料整理與去識別化
──> 資料庫與資料品質管理
──> API 設計與介接
──> 資安與權限控管
──> 文件、維運與服務管理- 第一步不是寫程式，而是資料盤點與可否開放的判斷：公部門資料常涉及個資、偵查不公開、內部作業或資安敏感資訊，不能直接公開原始資料。例如「各單位案件統計」通常可開放，但含被害人姓名、電話、地址、案件細節的原始資料就不能——必須先判斷哪些可公開、哪些須去識別化、哪些只能機關內部使用。
- API 的資料必須乾淨、固定、可讀，並提供清楚的 API 文件（等於使用說明書）。
- 資安控管概念：API Key 像通行證，Rate Limit（流量限制）像排隊叫號，避免單一使用者把服務塞爆；並留存存取紀錄以供稽核。
心得：這個主題和整份筆記的核心一致——資料的價值在於「能被安全、標準化地使用」，而「去識別化」與「判斷什麼能開放」永遠是第一道關卡。
法源對照
| 筆記細節 | 主要佐證來源 | 使用方式 |
|---|---|---|
| 資通安全治理、主管機關與資安責任 | 《資通安全管理法》全條文、第 2 條主管機關、第 3 條定義 | 對照「國家資安治理」章節，避免只用口語印象描述法規架構。 |
| 維護計畫、通報應變、稽核 | 《資通安全管理法》第 10 條、第 16 條、第 17 條 | 佐證資安維運不是單次建置，而是計畫、通報、稽核與改善循環。 |
| 個資保護、最小必要與外洩通知 | 《個人資料保護法》第 2 條、第 5 條、第 12 條、第 15 條、第 16 條 | 對照 RBAC、稽核日誌、資料外洩通報與公務機關資料利用邊界。 |
| 政府組態基準 GCB | 國家資通安全研究院 GCB 專區、數位發展部資安署 GCB FAQ | 佐證「一致性安全設定」與端點、伺服器、網通設備基準化設定。 |
| 資通安全弱點通報機制 VANS | 數位發展部資安署 VANS FAQ | 對照資訊資產盤點、弱點比對頻率、修補紀錄與後續追蹤。 |
| 零信任架構 ZTA | 國家資通安全研究院 ZTA 專區、ZTA 相關資料 | 佐證「永不信任、必須驗證」以及身分、設備、信任推斷的導入思路。 |
更多連結統一整理於 法規與官方來源索引。
延伸閱讀
官方來源
- 全國法規資料庫：資通安全管理法、資通安全管理法施行細則、公務人員保障法、個人資料保護法。
- 國際資安標準：ISO/IEC 27001（資訊安全管理系統要求）、NIST SP 800-207（零信任架構規範）；資料中心設計標準 TIA-942／Tier 分級（僅作觀念參照）。
- 政府資料開放：政府資料開放平臺、數位發展部政府資料開放相關作業原則。
- 相關對話原文（未公開，含敏感提醒）：
notes/raw_dialogues/07、08、10；第六～八節之補充材料出自 2026-07-03 補充對話（行動化查詢、智慧化維運、科技計畫、開放資料 API），僅萃取可公開之通用概念，明細見notes/raw_dialogues/index.md。
補充筆記
本篇整理重點
- 詳述 CIA 三要素在警政系統（如戶役政、防竄改筆錄系統、110受理）之實務應用場景，加強機密性、完整性與可用性之學理與實務結合。
- 補充《資通安全管理法》組織權責（數發部、資安署、資安院）之分工細節與責任等級（A～E 級）判定之客觀基準。
- 補齊資安事件分級（一～四級）定義，並以流程圖方式說明 1 小時內通報、復原及 1 個月內結案提交改善報告之時限。
- 將政府資安防護框架（GCB、VANS、零信任 ZTA）及監控工具（SIEM、SOC、Arkime 封包側錄）之運作原理深入闡明，並補足 NIST SP 800-207 零信任三大支柱。
- 詳述三層式架構（展示層 Web、應用層 AP、資料庫層 DB）之數據處理權限校驗與防火牆二次阻絕原理。
- 釐清備份、備援、異地備援在系統連續性上的本質差異，並補充 SPoF（單點故障）分析與 SLA 復原指標（RTO、RPO）。
主要參考來源類型
- 中華民國法規（資通安全管理法及其子法）。
- 國際標準與指南（ISO/IEC 27001 資訊安全管理、NIST SP 800-207 零信任架構、ITIL 維運架構）。
後續需查證
- 隨著政府各機關轉型雲端（如政府公有雲 G-Cloud 政策），特定核心系統之異地備援是否朝向雲端多區域（Multi-Region）備份或雲端備援演進，其實施細節屬各單位規劃，需個別查證各專案之招標規格。
知識結構圖
本篇重點的結構示意圖：
