背景
這份實習筆記整理自警政機關資安教育課程的投影片與講師口述補充。主軸是：政府機關資安防護不是單靠防火牆或防毒軟體，而是一套結合法規制度、責任分級、事件通報、技術防護、監控聯防與人才培育的完整治理架構。核心概念是資通安全三要素（CIA：機密性、完整性、可用性），並以《資通安全管理法》及其子法為母法，落實到警政機關的實務防護與應變流程中。
知識架構圖
政府機關（警政機關）資通安全防護與管理
├─ 一、為什麼需要資通安全？
│ ├─ 政府機關高度依賴資訊系統
│ ├─ 警政系統保存大量個資、機敏資料、治安資料與公務資料
│ ├─ 系統遭攻擊可能造成：資料外洩／竄改、系統停擺、影響勤務與偵查
│ └─ 因此需要制度化、分級化、技術化的資安防護
│
├─ 二、核心觀念：CIA 三要素
│ ├─ 機密性 Confidentiality：資料不能被未授權者看到或外洩
│ ├─ 完整性 Integrity：資料不能被竄改、破壞或銷毀
│ └─ 可用性 Availability：系統須在需要時能正常運作
│
├─ 三、法規基礎
│ ├─ 《資通安全管理法》（母法，主管機關：數位發展部）
│ │ └─ 定義資通安全、資安事件、公務機關、關鍵基礎設施
│ ├─ 資通安全管理法施行細則
│ ├─ 資通安全責任等級分級辦法（A～E 五級）
│ ├─ 資通安全事件通報應變及演練辦法（事件一～四級）
│ ├─ 資通安全維護計畫實施情形稽核辦法
│ └─ 資通安全情資分享辦法
│
├─ 四、責任等級與管理對象
│ ├─ 責任等級由高至低：A、B、C、D、E
│ ├─ 若符合多項判準，原則上列為最高等級
│ ├─ A 級判準舉例：國家機密、外交國防、國土安全、全國性民眾服務、
│ │ 跨機關共用系統、全國性個資檔案、全國性關鍵基礎設施
│ ├─ 管理對象分兩類：公務機關 / 特定非公務機關（含關鍵基礎設施提供者、
│ │ 公營事業、受政府控制之特定財團法人等）
│ └─ 各縣市警察局之主管機關為各縣市政府，警政署對其僅為督導關係
│
├─ 五、資安事件分級（一～四級）
│ ├─ 判斷五個面向：
│ │ ├─ 是否核心業務／非核心業務
│ │ ├─ 是否核心資通系統／非核心系統
│ │ ├─ 是否涉及關鍵基礎設施
│ │ ├─ 洩漏／竄改程度（輕微 vs 嚴重）
│ │ └─ 是否可於可容忍中斷時間內恢復
│ └─ 通報與應變時限：
│ ├─ 知悉後 1 小時內通報
│ ├─ 一二級事件：受通報機關 8 小時內完成等級審核；重大事件 2 小時內
│ ├─ 一二級事件：72 小時內完成損害控制或復原；重大事件 36 小時內
│ └─ 事後 1 個月內提出調查、處理及改善報告
│
├─ 六、平時防護四大策略
│ ├─ 策略 1：進不來（阻擋入侵）
│ │ └─ 防火牆、郵件防毒閘道、垃圾郵件過濾、目標式郵件偵測、
│ │ 漏洞修補、限縮管理者權限、可攜式儲存媒體掃毒、高敏系統網段隔離
│ ├─ 策略 2：出不去（阻止外傳）
│ │ └─ Proxy 代理伺服器、IPS 入侵防禦、NAC 網路存取控制、
│ │ 異常流量偵測、外連控管與告警
│ ├─ 策略 3：打不開（保護資料本身）
│ │ └─ 文件加密、公務電腦資料加密、傳輸加密、TLS/SSL 加密通道
│ └─ 策略 4：看得見／查得到（監控與追蹤）
│ └─ GCB、VANS、EDR、OSSIM、Splunk、SOC／N-SOC
│
├─ 七、技術工具與平台
│ ├─ GCB（Government Configuration Baseline）：統一政府設備安全設定基準
│ ├─ VANS（Vulnerability Analysis and Notice System）：資產與弱點通報管理
│ ├─ 零信任架構 ZTA：不預設信任，每次存取皆須驗證設備與人員風險
│ ├─ OSSIM：整合流量側錄、規則偵測與事件告警的聯防平台
│ ├─ Arkime（原 Moloch）：大規模封包側錄、索引與查詢
│ ├─ Suricata／Snort：規則式入侵偵測與流量比對
│ ├─ Splunk：集中收集各設備 log，建立儀表板與關聯分析（資安監控中心）
│ └─ NPA CDX：資安攻防演練平台（雲端化、虛擬化，不影響真實業務系統）
│
├─ 八、實際案例：106 年警用資訊系統強化案
│ └─ 多層防護：Internet → DDoS 防護 → Firewall → WAF → Load Balancer →
│ Web/DNS/Proxy/外部交換區 → Splunk 資安監控中心
│ （可對應四大策略：進不來＝DDoS/Firewall/WAF；出不去＝Proxy/流量控管；
│ 打不開＝資料與傳輸加密；看得見＝Splunk 集中監控）
│
├─ 九、資通安全維護計畫（13 項內容，依施行細則第 9 條）
│ ├─ 1. 核心業務及其重要性
│ ├─ 2. 資通安全政策及目標
│ ├─ 3. 資通安全推動組織
│ ├─ 4. 專職人力及經費之配置
│ ├─ 5. 資通安全長之配置
│ ├─ 6. 資通系統盤點，標示核心系統及相關資產
│ ├─ 7. 資通安全風險管理
│ ├─ 8. 資通安全防護及控制措施
│ ├─ 9. 資通安全事件通報、應變及演練機制
│ ├─ 10. 資通安全情資之評估及因應機制
│ ├─ 11. 資通系統或服務委外辦理之管理措施
│ ├─ 12. 所屬人員辦理資安事項之考核機制
│ └─ 13. 維護計畫與實施情形之持續精進及績效管理機制
│
├─ 十、警政署資訊室組織分工
│ ├─ 作業設計科：系統開發專案管理（決策分析、案件管理、刑案、日誌稽核等）
│ ├─ 前瞻應用科：新興應用（M-Police、警政服務 APP、XR、交通事故繪圖等）
│ ├─ 系統管理科：基礎設施（虛擬主機、網路架構、資料庫、單一簽入系統）
│ └─ 資訊安全科：資安政策、管理面、技術面與綜合行政
│
└─ 十一、人才與攻防演練
├─ 資安工具需要人操作、判讀、追蹤與改善
├─ NPA CDX：主機安全檢測、日誌與事件紀錄分析、網路安全分析、
│ 網頁應用系統檢測、資安事件調查
├─ 警政內部資安工房：分享研究、參與競賽、紅隊／藍隊實作訓練
└─ 資安團隊需要技術能力、實作經驗、熱情與跨科合作能力串聯邏輯：為什麼會這樣設計？
政府機關（警政機關）每天靠資訊系統處理大量公務、個資、治安與機敏資料 → 因此資安的基本目標是保護機密性、完整性、可用性（CIA） → 制度面用《資通安全管理法》與子法規定誰要負責（責任等級 A～E）、怎麼分級、怎麼通報 → 事件發生時依核心業務／系統／關鍵基礎設施／損害程度／復原能力，分為一至四級並依時限通報應變 → 平時則用「進不來、出不去、打不開、看得見」四層技術策略防護 → 以 GCB 統一設備安全設定、以 VANS 管理弱點與資產風險、以零信任架構強化存取驗證 → 以 OSSIM、Arkime、Suricata、Splunk 等工具做流量側錄、規則偵測與集中監控 → 以 NPA CDX 平台訓練人員進行攻防演練 → 資訊室各科（作業設計、前瞻應用、系統管理、資訊安全）分工支撐系統開發、應用、維運與資安 → 最後透過資通安全維護計畫（13 項內容）與人才培育，形成「預防、偵測、應變、復原、改善」的持續治理循環。
重點摘要（可放入實習心得）
本次課程讓我理解，政府機關（尤其是警政機關）的資安防護並非單一工具或單一科室的責任，而是一套結合法規制度、責任分級、技術控制、監控應變與人才培育的完整治理架構。依《資通安全管理法》，資通安全的核心在於防止資通系統或資訊遭未授權存取、使用、控制、洩漏、破壞、竄改或銷毀，並確保機密性、完整性與可用性；因此資安不只是防止資料外洩，也包含防止資料被竄改，以及確保系統不中斷。
在制度設計上，政府機關以資安法為母法，透過責任等級分級辦法（A～E 級）、事件通報應變及演練辦法（事件一至四級）、稽核辦法與情資分享辦法等子法，建立完整的責任、分級、通報與應變機制。事件發生時並非只用「嚴重／不嚴重」二分判斷，而是要看是否涉及核心業務、機密資訊、關鍵基礎設施，以及能否在可容忍中斷時間內恢復。
在技術落地方面，「進不來、出不去、打不開、看得見」四大策略是最好記也最實用的防護邏輯：進不來擋入口、出不去擋外傳、打不開保資料、看得見做監控。106 年警用資訊系統強化案（DDoS 防護、Firewall、WAF、Load Balancer、Splunk 監控中心）正是這套邏輯的具體落地案例。
最後，資安不只是設備與工具的堆疊，更需要組織分工（作業設計科、前瞻應用科、系統管理科、資訊安全科）與人才培育（NPA CDX 攻防演練平台、資安工房、紅藍隊訓練）共同配合，才能形成從預防、偵測、應變到持續改善的完整資安治理循環。也因為 AI 加速了漏洞挖掘與攻擊工具開發（如近期出現的多起 Linux 漏洞被指出與 AI 輔助分析有關），資安人員面對的挑戰只會越來越多，這也讓「用 AI 學習與整理資料」成為現階段學生的一項優勢，但更重要的仍是自己要有架構、判斷力與 know-how，而不是全盤依賴 AI 產出的內容。
事實查核表
| 口述／投影片重點 | 核實結果 | 報告寫法建議 |
|---|---|---|
| 資安核心是機密性、完整性、可用性 | 正確，與《資通安全管理法》第 3 條定義相符 | 可寫 CIA 三要素，並加註正式法條文字 |
| 資安法主管機關是「數位發展部」（口述誤稱「罰部」「突發部」等） | 已修正 | 正式名稱為數位發展部；業務執行由其指定之資安專責機關（資通安全署）辦理 |
| 資安事件分為一至四級 | 正確，《資通安全事件通報應變及演練辦法》明定四級分類 | 投影片表格為簡化版，正式報告應註明實際仍依法規細項判斷 |
| 責任等級為 A、B、C、D、E 五級 | 已修正（口述曾誤稱 A/B/C 三級） | 由高至低為 A～E，符合多項判準者列為最高等級 |
| GCB 是政府組態基準（口述誤稱 GCD、GCDC） | 正確 | Government Configuration Baseline，統一政府設備安全設定 |
| VANS 是弱點通報機制（口述誤稱 Avan、A Van） | 正確 | Vulnerability Analysis and Notice System，結合資產管理與弱點管理 |
| 零信任架構（口述誤稱「零時間」「李信任」） | 正確 | Zero Trust Architecture，任何存取皆不預設信任，須驗證設備與人員風險 |
| TLS 1.0、1.1 已不建議使用 | 正確 | IETF RFC 8996 已正式廢止 TLS 1.0 與 1.1，建議採 TLS 1.2 以上 |
| OSSIM 可作資安聯防或集中監控平台 | 大方向正確 | 開源 SIEM，功能含事件蒐集、正規化與關聯分析；若為內部平台，不宜寫成全國通例 |
| Moloch 現稱 Arkime | 需修正名稱 | 開源大規模封包擷取、索引與查詢系統 |
| Suricata、Snort 可做規則偵測 | 正確 | 開源網路分析與威脅偵測軟體／規則式入侵偵測 |
| 後量子密碼離實務尚遠 | 需修正 | NIST 已發布後量子密碼標準；實務上應先盤點密碼資產與規劃遷移 |
| 個資管理委員會（口述用語） | 應為「個人資料保護委員會（個資會）」 | 個資會需組織法完成立法始正式具備法定職掌；施行日期由行政院另定 |
| 資通安全維護計畫應包含 13 項內容 | 正確，依施行細則第 9 條 | 可完整列出 13 項（見知識架構圖），不宜省略 |
三個反思點
- 資安治理是「法規＋管理＋技術＋人」的整合，不是單一工具的堆疊。 從責任分級、事件通報時限，到進不來／出不去／打不開／看得見的技術策略，每一層都需要制度與人員配合才能落地。
- 口述逐字稿中大量的專有名詞誤聽（GCB、VANS、零信任、Arkime 等）提醒我，第一線學習資安知識時務必查證正式名稱與法條依據，不能只靠聽打稿或口語轉述。
- AI 時代讓資安攻防的門檻同時對雙方都降低：學習者可以更快查資料、寫報告，但攻擊者也能更快挖掘漏洞。 這代表資安人才的核心價值正在從「會不會寫程式／背法規」轉向「有沒有架構判斷力與 know-how」。