---
# System prepended metadata

title: iPAS資訊安全工程師 - 規劃

---

## 《資通安全管理法施行細則》第 10 條
資通安全維護計畫應包括：

核心業務及其重要性

資通安全政策及目標

專責人力及經費之配置

資通安全管理措施及推動方式

資通安全事件通報與應變機制

持續改善機制

## 📌 SOD（職務區隔）的解釋

定義

將敏感或關鍵作業拆分給不同角色處理，避免單一人員可從頭到尾掌控。

核心理念：分權制衡。

常見應用範例

會計：請款、審核、撥款分屬不同人員。

資訊系統：

程式開發 ≠ 系統部署 ≠ 系統維護 ≠ 稽核

DBA ≠ 系統管理員

人資系統：人資主管（業務使用者） ≠ 系統維護人員

未落實 SOD 的風險

資料被竄改不易發現

舞弊（例如主管偷偷調整薪資或刪除紀錄）

資安事件偵測困難

## 📌 網路區隔（Network Segmentation）的資安知識整理
1. 為什麼要做網路區隔？

減少攻擊面：避免駭客入侵一台機器後能橫向移動到整個網路。

控制存取：不同部門（HR、財務、研發）的資料互相隔離。

提升效能：降低廣播範圍，減少不必要的封包傳播。

符合法規：例如個資/金融法規，敏感資料要與一般網路隔離。

2. 常見的區隔方式

**實體區隔（Physical Segmentation）**

使用不同實體交換器、網線，最安全但成本高。

**邏輯區隔（Logical Segmentation）**

VLAN：同一台交換器上劃分不同廣播網段。

VRF（Virtual Routing and Forwarding）：在路由器上虛擬多個邏輯路由實例。

**周界控制（Perimeter Control）**

防火牆（Firewall）、ACL（Access Control List）、Filtering Router。

典型案例：DMZ（Demilitarized Zone），把對外伺服器放在隔離區，與內部網路分離。

3. 無線網路的挑戰（跟本題 C 有關）

Wi-Fi 訊號難以劃定邊界，無法像實體網路那樣嚴格限制。

常見防護措施：

WPA3 加密

設定獨立的 Guest Wi-Fi VLAN

NAC（Network Access Control）驗證裝置身分

避免 Wi-Fi 直接連內部網路，建議經過 VPN 或防火牆。

4. 資安最佳實務

最小權限原則：區隔後，僅允許必要的存取。

零信任架構（Zero Trust Architecture）：即使在同一個區域，也要驗證身分。

持續監控：搭配 SIEM、IDS/IPS 偵測異常流量。

## Azure Storage 有四種主要備援機制：

LRS (Locally-redundant storage)

在同一個資料中心（同區域）內，保存 3 份複本。

只防止單一硬碟或伺服器故障，沒有異地備份。

ZRS (Zone-redundant storage)

在同一區域的 不同可用性區域 (Availability Zones) 複製 3 份。

抵禦資料中心等級的災害。

GRS (Geo-redundant storage)

在 主區域 (Primary region) 存放 3 份，並 非同步複製到 次區域 (Secondary region, 距離 >300 公里) 再 3 份。

共 6 份資料。

缺點：次區域無法直接讀取，只能在 Microsoft 進行 failover 後才能使用。

RA-GRS (Read-access GRS)

與 GRS 相同，但允許 直接讀取次區域資料。

適合需要「讀取可用性」的備援需求。

## 備援方式差異
| 類型                                | 定義                                                                     | 成本 | 啟動時間          | 可用性 (RTO/RPO)      | 適用情境                |
| --------------------------------- | ---------------------------------------------------------------------- | -- | ------------- | ------------------ | ------------------- |
| **冷備援 (Cold Backup / Cold Site)** | 災難發生時，只有「基本硬體設備」(如機房空間、電力、冷卻)，但沒有事先安裝系統或同步資料。災難時需從頭安裝系統、還原資料。          | 最低 | 最長 (幾天～幾週)    | RTO、RPO 都很差        | 小型公司、低預算，對業務連續性要求不高 |
| **暖備援 (Warm Backup / Warm Site)** | 災難前已準備好「基本系統、網路與部分資料」，但不是完全即時同步。發生災難時可快速載入最近一次的備份。                     | 中等 | 中等 (數小時～1-2天) | RTO/RPO 中等         | 中小型企業，允許有限停機時間      |
| **熱備援 (Hot Backup / Hot Site)**   | 災難發生時有 **完整的即時鏡像系統**，包含作業系統、應用程式與資料，且與主系統幾乎 **即時同步**。可立即切換 (Failover)。 | 最高 | 最快 (幾分鐘內)     | RTO、RPO 都最佳 (接近 0) | 金融業、電商、銀行，不能停機      |


## RTO & RPO

RTO (Recovery Time Objective, 復原時間目標)
👉 系統發生災難後，允許 最長停機時間。
（換句話說：多久內一定要復原？）

RPO (Recovery Point Objective, 復原點目標)
👉 系統發生災難後，允許 最大資料遺失量。
（換句話說：最久能接受回復到多久前的備份？）

備份時間間隔 (Backup Interval)
👉 系統多久做一次備份，例如每天一次、每小時一次。

🔹 RPO 與備份時間的關係

📌 RPO ≤ 備份時間間隔

例子：

如果 每天備份一次 (24 小時)，那最壞情況是今天出事，資料只能回復到昨天 → RPO = 24 小時。

如果要求 RPO ≤ 1 小時，就必須 至少每小時備份一次，或做即時同步 (熱備援)。

👉 所以：RPO 決定你要多頻繁備份。

🔹 RTO 與備份時間的關係

RTO 跟「備份時間」沒有直接大小關係，但有實務影響：

RTO = 2 小時 → 代表你必須在 2 小時內把系統與資料恢復。

如果你的備份檔太大、存放在磁帶庫，要花 5 小時才抓回來 → 就不符合 RTO。

所以 備份方式、儲存位置會影響 RTO：

傳統冷備援：RTO 長 (幾天)

雲端快照、熱備援：RTO 短 (幾分鐘)

👉 RTO ≠ 備份時間，但 RTO 會受備份還原效率影響。

🔹 總結

RPO 要小於或等於備份週期
（想少掉資料，就得多做備份）

RTO 與備份時間無必然數值關係
（但還原效率若拖太久，就會超過 RTO）


## 🔹 ISO/IEC 27001 資安事件處理流程

（對應標準控制項 A.16 – 資安事件管理）

1️⃣ 事件偵測與回報 (Detection & Reporting)

發現異常（例如：帳號被鎖定、流量異常、檔案被加密）

內部通報 → 資安官 / 資安主管 / CSIRT (Computer Security Incident Response Team)

記錄時間、來源、影響範圍

2️⃣ 初步分類與評估 (Assessment)

判斷事件嚴重程度（影響機密性、完整性、可用性？）

是否屬於重大資安事件？

決定要不要 通報主管機關 / 第三方

3️⃣ 控制 (Containment)

採取臨時措施避免擴大，例如：

封鎖惡意 IP

斷開受感染主機網路

關閉異常服務（如 OWA）

目的：先「止血」

4️⃣ 根除與復原 (Eradication & Recovery)

移除惡意程式 / 修補漏洞 / 更新密碼策略

恢復正常服務（含驗證環境安全性）

可能需重建部分系統

5️⃣ 後續檢討 (Lessons Learned)

做 事件報告

分析根因 (Root Cause Analysis)

更新資安防護措施（如：增加 VPN、限制白名單、加強監控）

納入 持續改善 (PDCA)


## 四大風險處理方式 (Risk Treatment Options)
1. Avoid (避免 / 規避)

📌 情境：

風險發生的可能性高

衝擊也高（會造成重大損失 / 法規違規 / 無法承受）
👉 最好的方式是乾脆不要做這件事，直接移除風險來源。

例子：

發現某應用程式漏洞太多 → 決定停用該系統。

某服務涉及法規風險 → 公司決定不進入該市場。

2. Mitigate (降低 / 緩解)

📌 情境：

衝擊高但可能性低 → 建立控制措施來降低衝擊。

或 衝擊低但可能性高 → 降低發生的機率。
👉 透過技術 / 管理控制，把風險降到可接受範圍。

例子：

員工密碼外洩風險高 → 導入 MFA (多因子驗證)。

系統可能常被攻擊，但影響有限 → 加強監控、增加異常警示。

3. Transfer (移轉 / 分攤)

📌 情境：

風險存在，但可以交由第三方承擔（通常是財務或責任）。
👉 常見作法是透過 保險、外包、契約，把風險轉嫁給他人。

例子：

系統上雲 → 簽 SLA，讓雲端供應商負責服務中斷。

買資安保險 → 當發生資安事件，由保險理賠部分損失。

4. Accept (接受 / 承受)

📌 情境：

衝擊低 + 發生機率低

或 處理成本大於風險本身
👉 直接承擔，不額外採取措施，但要記錄並納入風險登錄表。

例子：

一台老舊非關鍵電腦可能中毒 → 公司決定不修，因影響有限。

系統可能偶爾 downtime 1 分鐘，但不影響業務 → 接受。

| 衝擊 (Impact)    | 發生可能性 (Likelihood)               | 建議處理方式                |
| -------------- | -------------------------------- | --------------------- |
| 高衝擊 ＋ 高可能性     | **Avoid**（避免，直接停掉或改變業務模式）        |                       |
| 高衝擊 ＋ 低可能性     | **Mitigate**（降低衝擊，例如異地備援、災難復原計畫） |                       |
| 低衝擊 ＋ 高可能性     | **Mitigate**（降低機率，例如加強控管、增加監控）   |                       |
| 低衝擊 ＋ 低可能性     | **Accept**（接受，記錄即可）              |                       |
| **可透過契約或保險處理** | 不論高低                             | **Transfer**（移轉 / 分攤） |



## 不同單位的責任分級
我國《資通安全責任分級辦法》
A 級：關鍵基礎設施（如國防、金融核心系統），影響國家安全或重大經濟利益。

B 級：重要單位，影響社會秩序或公共利益，若遭受資安事件會造成較大影響。

C 級：一般單位，影響範圍較小，事件造成損害有限。

D 級：非關鍵單位，影響最小。

## 備份方法
1️⃣ 完整備份（Full Backup）

定義：備份系統中所有選定資料的完整副本。

優點：

還原時只需要一個備份集（最快）。

備份結構最簡單。

缺點：

備份時間長。

佔用大量儲存空間。

適用情境：

週期性完整備份（例如每週一次）作為基礎。

2️⃣ 增量備份（Incremental Backup）

定義：只備份自上一次備份（完整或增量）後有變動的資料。

優點：

備份速度快。

節省儲存空間。

缺點：

還原時需要最初的完整備份 + 所有後續增量備份（較慢，步驟多）。

若某個增量備份損毀，之後的資料可能無法完整還原。

適用情境：

每日備份小量變動的資料，搭配週期性完整備份。

3️⃣ 差異備份（Differential Backup）

定義：備份自上一次完整備份後所有變動的資料。

優點：

還原比增量簡單，只需完整備份 + 最新差異備份。

備份速度比完整備份快。

缺點：

隨時間增加，每次差異備份會越來越大。

比增量佔用更多儲存空間。

適用情境：

需要快速還原，但又不想每天完整備份的情況。


## 資安控制措施的類型

1️⃣ 控制措施分類

管理的（Administrative）控制

由政策、規範、程序或訓練實施。

例子：資安政策、教育訓練、簽署保密協議。

技術的（Technical）控制

由技術手段自動執行。

例子：防火牆、加密、存取控制系統。

2️⃣ 控制目的分類

預防性（Preventive）

目的是阻止事件發生。

例子：設定密碼策略、防毒軟體阻擋病毒。

偵測性 / 威嚇性（Detective / Deterrent）

偵測性：用來發現事件或異常。

威嚇性：用來警告或提醒，讓人不想違規。

例子：登入提醒、告示牌、監控標語。