資訊安全 on Eric 個人部落格

威脅模型範本（Threat Model Template）

Mon, 18 May 2026 00:00:00 +0000

威脅模型範本（Threat Model Document）

參照標準：Microsoft STRIDE / OWASP Threat Modeling / ISO/IEC 27005:2022
文件用途：系統性識別、分析、評估與處置系統面臨的安全威脅
適用階段：系統設計階段（Design Phase）— Security by Design

📋 章節目錄

文件資訊
系統概述
資料流程圖（DFD）
信任邊界識別
STRIDE 威脅分析
威脅風險評估
緩解措施
殘餘風險
威脅追溯矩陣
附錄

1. 文件資訊

📝 範本

項目	內容
文件編號	TM-{專案代碼}-{序號}
文件名稱	{系統名稱} 威脅模型
版本	v{主版本}.{次版本}
狀態	草稿 / 審核中 / 核定
建立日期	{YYYY-MM-DD}
撰寫者	{姓名/角色}
資安審核者	{資安人員姓名}
威脅建模方法	STRIDE / PASTA / LINDDUN
分析範圍	{描述分析涵蓋的系統邊界}

📖 使用說明

威脅模型在架構設計完成後、開發實作前進行
建議組成跨功能團隊：架構師 + 資安人員 + 開發者 + QA
STRIDE 是微軟提出的分類法，覆蓋六大威脅類型
本文件需與安全需求清單（SecurityRequirements）互相參照

💡 範例

項目	內容
文件編號	TM-HRM-001
系統名稱	人力資源管理系統（HRMS）
威脅建模方法	STRIDE
分析範圍	Web 前端、API Gateway、微服務層、資料庫層、外部整合（AD/Email）

2. 系統概述

📝 範本

2.1 系統架構摘要

元件	技術	角色描述
{元件名稱}	{技術/框架}	{職責說明}

2.2 資產識別

資產 ID	資產名稱	資產類型	敏感等級	擁有者
ASSET-{xxx}	{名稱}	資料/服務/基礎設施	高/中/低	{團隊}

📖 使用說明

系統架構摘要提供技術棧全貌，協助識別攻擊面
資產識別需列出需保護的有價值目標（攻擊者感興趣的）
資產敏感等級決定威脅分析的優先順序

💡 範例

2.1 系統架構摘要

元件	技術	角色描述
Web SPA	React 18 + TypeScript	使用者介面
API Gateway	Kong 3.x	請求路由、速率限制、認證
Auth Service	.NET 8 + IdentityServer	身分認證與 Token 核發
HR Core Service	.NET 8 Web API	員工/薪資/假勤核心邏輯
PostgreSQL	v16	關聯式資料儲存
Redis	v7	Session/Cache 快取
Active Directory	Windows Server 2022	企業帳號整合

2.2 資產識別

資產 ID	資產名稱	資產類型	敏感等級	擁有者
ASSET-001	員工個資（身分證/地址/緊急聯絡人）	資料	高	HR 部門
ASSET-002	薪資明細（薪資/獎金/扣款）	資料	高	財務部
ASSET-003	認證 Token / Session	資料	高	系統
ASSET-004	API Gateway	服務	中	IT 維運
ASSET-005	資料庫加密金鑰	基礎設施	高	資安團隊

3. 資料流程圖（DFD）

📝 範本

Level 0 - 系統環境圖

外部實體 → [系統邊界] → 外部實體

Level 1 - 子系統分解

DFD 元素	符號	說明
外部實體	矩形	系統範圍外的使用者/系統
處理程序	圓形	系統內部邏輯處理
資料儲存	平行線	資料庫/檔案
資料流	箭頭	資料移動方向
信任邊界	虛線框	安全等級分界

📖 使用說明

DFD 是威脅建模的核心輸入，透過視覺化理解資料流向
Level 0 呈現系統與外部互動全貌
Level 1 展開各子系統，識別每個資料流的信任邊界
建議使用工具：Microsoft Threat Modeling Tool、OWASP Threat Dragon

💡 範例

Level 1 - HRMS 子系統分解

┌─────────────────── 信任邊界：Internet ───────────────────┐
│ │
│ [員工/主管] ────→ Web SPA (React) │
│ │
└─────────────────────────────────────────────────────────┘
│ HTTPS (JWT)
┌────────────────── 信任邊界：DMZ ────────────────────────┐
│ ▼ │
│ (API Gateway - Kong) │
│ │ │
└───────────────────────────┼──────────────────────────────┘
│ mTLS
┌────────────────── 信任邊界：Internal ───────────────────┐
│ ▼ │
│ (Auth Service) ←── (HR Core Service) │
│ │ │ │
│ ▼ ▼ │
│ [Redis Cache] [PostgreSQL DB] │
│ │
└─────────────────────────────────────────────────────────┘
│ LDAPS
┌────────────────── 信任邊界：Enterprise ─────────────────┐
│ ▼ │
│ [Active Directory] │
│ │
└─────────────────────────────────────────────────────────┘

4. 信任邊界識別

📝 範本

邊界 ID	邊界名稱	起點	終點	跨越邊界的資料	保護機制
TB-{xxx}	{邊界名稱}	{元件}	{元件}	{資料描述}	{保護}

📖 使用說明

信任邊界是安全等級不同的兩個區域之間的分界線
跨越信任邊界的資料流是威脅分析的重點（攻擊最可能發生處）
每條跨邊界的資料流都需要相應的保護機制

💡 範例

邊界 ID	邊界名稱	起點	終點	跨越邊界的資料	保護機制
TB-001	Internet → DMZ	Web SPA	API Gateway	HTTP 請求 + JWT	TLS 1.3、WAF、Rate Limit
TB-002	DMZ → Internal	API Gateway	HR Core Service	API 呼叫 + 使用者上下文	mTLS、服務網格
TB-003	Internal → DB	HR Core Service	PostgreSQL	SQL 查詢 + 個資	連線加密、最小權限
TB-004	Internal → Enterprise	Auth Service	Active Directory	LDAP 認證請求	LDAPS (636 port)

5. STRIDE 威脅分析

📝 範本

STRIDE 分類說明

類型	英文	說明	違反的安全屬性
S	Spoofing	身份冒充	認證（Authentication）
T	Tampering	資料竄改	完整性（Integrity）
R	Repudiation	否認行為	不可否認性（Non-Repudiation）
I	Information Disclosure	資訊洩露	機密性（Confidentiality）
D	Denial of Service	阻斷服務	可用性（Availability）
E	Elevation of Privilege	權限提升	授權（Authorization）

威脅列表

威脅 ID	STRIDE	目標元件	威脅描述	攻擊場景
THR-{xxx}	S/T/R/I/D/E	{元件}	{威脅描述}	{攻擊者如何利用}

📖 使用說明

逐一對每個 DFD 元素（處理程序、資料儲存、資料流）套用 STRIDE
外部實體通常只分析 S（Spoofing）和 R（Repudiation）
資料儲存通常分析 T、I、D
處理程序所有 STRIDE 類型都適用
每個威脅需具體描述攻擊場景（非泛泛而談）

💡 範例

威脅 ID	STRIDE	目標元件	威脅描述	攻擊場景
THR-001	S	API Gateway	偽造 JWT Token 冒充合法使用者	攻擊者取得 JWT Secret 或使用弱演算法偽造 Token
THR-002	T	HR Core Service	竄改薪資計算邏輯	內部人員修改薪資計算 API 參數，增加自己薪資
THR-003	R	HR Core Service	管理員否認執行薪資調整操作	管理員調整薪資後聲稱未進行此操作
THR-004	I	PostgreSQL	員工個資大量外洩	SQL Injection 或未加密備份遭竊
THR-005	D	API Gateway	DDoS 癱瘓打卡/請假功能	攻擊者以大量請求衝擊 API Gateway
THR-006	E	Auth Service	一般員工提升至 Admin 權限	利用 IDOR 漏洞修改角色欄位
THR-007	I	Redis Cache	Session 資料從快取洩露	未加密的 Redis 連線被中間人竊聽
THR-008	S	Active Directory	暴力破解 AD 帳號密碼	對 LDAP 認證端點進行字典攻擊

6. 威脅風險評估

📝 範本

風險評分標準（DREAD 或自訂）

評分維度	1（低）	2（中）	3（高）
影響程度（Impact）	非敏感資料	部分敏感資料	核心/大量敏感資料
發生可能性（Likelihood）	需高階技術+內部存取	中等技術+外部存取	低門檻+自動化工具
可利用性（Exploitability）	無公開漏洞	有概念驗證	有公開利用工具

風險評估結果

威脅 ID	影響	可能性	可利用性	總分	風險等級
THR-{xxx}	{1-3}	{1-3}	{1-3}	{N}	高/中/低

📖 使用說明

風險等級 = 影響 × 可能性 × 可利用性（或加總取平均）
高風險（7-9分）：必須在上線前處置
中風險（4-6分）：計畫性處理，可接受短期風險
低風險（1-3分）：記錄並持續監控
風險評估結果決定緩解措施的優先順序

💡 範例

威脅 ID	影響	可能性	可利用性	總分	風險等級
THR-001	3	2	2	7	高
THR-002	3	1	1	5	中
THR-003	2	2	3	7	高
THR-004	3	2	3	8	高
THR-005	2	3	3	8	高
THR-006	3	2	2	7	高
THR-007	2	1	2	5	中
THR-008	3	2	3	8	高

7. 緩解措施

📝 範本

威脅 ID	緩解措施	對應安全需求	實作方式	負責人	狀態
THR-{xxx}	{緩解描述}	SEC-{xxx}	{技術/流程手段}	{人員}	未開始/進行中/完成

📖 使用說明

每個高/中風險威脅都需要對應的緩解措施
緩解策略分為四種：
- 消除：重新設計，完全移除威脅（最佳）
- 緩解：降低影響或可能性（最常見）
- 轉移：轉移風險給第三方（保險/外包）
- 接受：記錄風險，不處理（需管理層核准）
緩解措施需連結到安全需求清單（SecurityRequirements）中的具體需求

💡 範例

威脅 ID	緩解措施	對應安全需求	實作方式	負責人	狀態
THR-001	使用 RS256 非對稱簽章 + 短效 Token	SEC-AUTH-006	JWT RS256 + 15min Expiry	後端組	完成
THR-003	所有薪資操作記錄不可竄改稽核日誌	SEC-LOG-001, SEC-LOG-004	Append-only audit log + 時間戳簽章	後端組	進行中
THR-004	個資欄位加密 + 參數化查詢 + WAF	SEC-DATA-001, SEC-INPUT-002	AES-256 + EF Core parameterized + ModSecurity	全端	完成
THR-005	API Rate Limiting + CDN + Auto-scaling	SEC-INPUT-005	Kong rate-limit plugin (100 req/min) + Azure CDN	DevOps	完成
THR-006	伺服器端角色驗證 + 單元測試覆蓋	SEC-AUTHZ-001, SEC-AUTHZ-003	[Authorize(Roles=“Admin”)] + IDOR 防護	後端組	完成
THR-008	帳號鎖定 + MFA + IP 白名單	SEC-AUTH-002, SEC-AUTH-003	AD 帳號鎖定策略 + Azure MFA	IT 維運	進行中

8. 殘餘風險

📝 範本

威脅 ID	殘餘風險描述	緩解後風險等級	接受理由	核准者	核准日期
THR-{xxx}	{緩解後仍存在的風險}	高/中/低	{為何可接受}	{管理層}	{日期}

📖 使用說明

殘餘風險 = 實施緩解措施後仍無法完全消除的風險
所有殘餘風險需經管理層正式核准（Risk Acceptance）
殘餘風險需定期重新評估（至少每季度）
高殘餘風險應有補償性控制措施

💡 範例

威脅 ID	殘餘風險描述	緩解後風險等級	接受理由	核准者	核准日期
THR-005	DDoS 超過 CDN 容量時仍可能影響可用性	低	CDN 已可承受 99% 場景，剩餘機率極低	CTO	2026-05-15
THR-007	Redis 若被直接存取仍可讀取 Session	低	Redis 位於 VPC 內網，無外部可達性	資安主管	2026-05-15

9. 威脅追溯矩陣

📝 範本

威脅 ID	DFD 元素	信任邊界	安全需求	緩解措施	測試案例
THR-{xxx}	{元件}	TB-{xxx}	SEC-{xxx}	{緩解}	TC-{xxx}

📖 使用說明

追溯矩陣確保每個威脅都能向前追溯到架構元素、向後追溯到測試案例
完整鏈路：DFD 元素 → 信任邊界 → 威脅 → 安全需求 → 緩解措施 → 測試驗證
若某威脅沒有對應的測試案例，代表測試覆蓋不足

💡 範例

威脅 ID	DFD 元素	信任邊界	安全需求	緩解措施	測試案例
THR-001	API Gateway	TB-001	SEC-AUTH-006	RS256 + 短效 Token	TC-SEC-001: Token 偽造測試
THR-004	PostgreSQL	TB-003	SEC-DATA-001, SEC-INPUT-002	加密 + 參數化查詢	TC-SEC-004: SQL Injection Pen Test
THR-005	API Gateway	TB-001	SEC-INPUT-005	Rate Limiting	TC-SEC-005: 壓力測試 + DDoS 模擬
THR-006	Auth Service	TB-002	SEC-AUTHZ-001	伺服器端授權	TC-SEC-006: IDOR 測試

10. 附錄

📝 範本

10.1 威脅建模會議記錄

日期	參與者	討論主題	決議
{日期}	{姓名,角色}	{主題}	{決議}

10.2 參考資料

資源	用途
OWASP Threat Modeling Cheat Sheet	威脅建模方法論參考
Microsoft STRIDE per Element	每元素類型適用的 STRIDE 分析
OWASP ASVS 4.0.3	安全需求對照標準
ISO/IEC 27005:2022	風險評估方法論

📖 使用說明

會議記錄保留威脅建模決策的可追溯性
建議威脅模型每個 Sprint 或重大架構變更時更新
工具推薦：Microsoft Threat Modeling Tool (免費)、OWASP Threat Dragon (開源)

💡 範例

10.1 威脅建模會議記錄

日期	參與者	討論主題	決議
2026-04-10	張架構師, 李資安, 王開發	Level 1 DFD 繪製與邊界確認	TB-001~TB-004 確認
2026-04-12	張架構師, 李資安, 陳 QA	STRIDE 分析（THR-001~008）	8 個威脅確認，6 個為高風險
2026-04-15	CTO, 資安主管, 張架構師	殘餘風險接受	THR-005, THR-007 殘餘風險核准接受

📌 範本使用注意事項

安全需求清單範本（Security Requirements Checklist Template）

Mon, 18 May 2026 00:00:00 +0000

安全需求清單範本（Security Requirements Checklist）

參照標準：OWASP ASVS 4.0.3（Application Security Verification Standard）/ ISO/IEC 27001:2022 Annex A
文件用途：定義系統應滿足的安全需求，確保設計與開發階段納入安全考量
適用階段：需求分析階段（Requirements Phase）— Security by Design

1. 文件資訊

📝 範本

項目	內容
文件編號	SR-{專案代碼}-{序號}
文件名稱	{系統名稱} 安全需求清單
版本	v{主版本}.{次版本}
狀態	草稿 / 審核中 / 核定
建立日期	{YYYY-MM-DD}
撰寫者	{姓名/角色}
資安審核者	{資安人員姓名}
ASVS Level	Level 1 / Level 2 / Level 3

📖 使用說明

依據 OWASP ASVS 4.0.3 標準，安全需求分為三個驗證等級：
- Level 1：所有應用程式的最低標準
- Level 2：處理敏感資料的應用程式
- Level 3：最高安全等級（金融、醫療、關鍵基礎設施）
本清單在需求階段制定，貫穿整個 SDLC（設計需遵循、開發需實作、測試需驗證）

💡 範例

項目	內容
文件編號	SR-HRM-001
系統名稱	人力資源管理系統
ASVS Level	Level 2（處理員工個資與薪資資料）

2. 安全需求概述

📝 範本

2.1 系統安全分類

項目	評估
資料敏感度	一般 / 敏感 / 高度敏感
系統曝露面	內部 / 外部 / 混合
使用者類型	內部員工 / 外部客戶 / 合作夥伴
法規要求	{適用法規}
安全等級	ASVS Level {1/2/3}

2.2 安全需求追溯矩陣

安全需求 ID	需求描述	ASVS 章節	對應 FRD	優先級
SEC-{xxx}	{描述}	V{x}.{x}	FR-{xxx}	高/中/低

📖 使用說明

安全分類決定應套用的 ASVS Level
追溯矩陣確保每個安全需求可連結到 FRD 需求與 ASVS 標準章節
優先級考量：法規強制 > 高風險 > 一般防護

💡 範例

2.1 系統安全分類

項目	評估
資料敏感度	高度敏感（身分證字號、薪資、銀行帳號）
系統曝露面	混合（內部網路 + VPN 遠端存取）
使用者類型	內部員工（全體） + HR 管理人員
法規要求	個人資料保護法、勞動基準法
安全等級	ASVS Level 2

3. 認證需求（Authentication）

📝 範本

需求 ID	需求描述	ASVS 參照	Level	必須/建議	實作狀態
SEC-AUTH-001	{認證需求描述}	V2.{x}	L{N}	必須/建議	☐
SEC-AUTH-002	{認證需求描述}	V2.{x}	L{N}	必須/建議	☐

📖 使用說明

對應 OWASP ASVS V2（Authentication）章節
Level 1：基本密碼安全；Level 2：多因子認證（MFA）；Level 3：硬體認證
認證需求需涵蓋：密碼策略、帳號鎖定、MFA、SSO

💡 範例

需求 ID	需求描述	ASVS 參照	Level	必須/建議	實作狀態
SEC-AUTH-001	密碼長度至少 12 字元	V2.1.1	L1	必須	☑
SEC-AUTH-002	帳號連續 5 次登入失敗後鎖定 30 分鐘	V2.2.1	L1	必須	☑
SEC-AUTH-003	管理員帳號啟用多因子認證（MFA）	V2.8.1	L2	必須	☑
SEC-AUTH-004	整合企業 AD 實現 SSO 登入	V2.7.1	L2	必須	☑
SEC-AUTH-005	密碼不儲存明文，使用 bcrypt/Argon2 雜湊	V2.4.1	L1	必須	☑
SEC-AUTH-006	Token 過期時間 ≤ 15 分鐘（Access Token）	V2.8.5	L2	必須	☐

4. 授權與存取控制（Authorization）

📝 範本

需求 ID	需求描述	ASVS 參照	Level	必須/建議	實作狀態
SEC-AUTHZ-001	{授權需求描述}	V4.{x}	L{N}	必須/建議	☐

📖 使用說明

對應 OWASP ASVS V4（Access Control）章節
遵循最小權限原則（Principle of Least Privilege）
需求涵蓋：RBAC/ABAC 模型、水平/垂直權限控制、API 授權

💡 範例

需求 ID	需求描述	ASVS 參照	Level	必須/建議	實作狀態
SEC-AUTHZ-001	實施 RBAC 角色權限控制（Admin/Manager/Employee）	V4.1.1	L1	必須	☑
SEC-AUTHZ-002	使用者僅能存取自己的薪資/假勤資料（水平權限）	V4.1.2	L1	必須	☑
SEC-AUTHZ-003	API 端點實施授權檢查，拒絕未授權請求回傳 403	V4.1.3	L1	必須	☑
SEC-AUTHZ-004	管理功能（帳號管理、系統設定）限 Admin 角色	V4.2.1	L1	必須	☑
SEC-AUTHZ-005	所有權限變更需記錄稽核日誌	V4.3.1	L2	必須	☐

5. 資料保護需求（Data Protection）

📝 範本

需求 ID	需求描述	ASVS 參照	Level	必須/建議	實作狀態
SEC-DATA-001	{資料保護需求描述}	V6.{x}/V8.{x}	L{N}	必須/建議	☐

敏感資料識別

資料欄位	敏感等級	加密方式	遮罩方式	保留期限
{欄位}	高/中/低	{加密}	{遮罩}	{期限}

📖 使用說明

對應 OWASP ASVS V6（Stored Cryptography）與 V8（Data Protection）
敏感資料需先識別、再定義保護策略
保護措施包含：傳輸加密、靜態加密、資料遮罩、存取控制、保留/銷毀策略

💡 範例

敏感資料識別

資料欄位	敏感等級	加密方式	遮罩方式	保留期限
身分證字號	高	AES-256 (靜態)	A1234****9	離職後 5 年
銀行帳號	高	AES-256 (靜態)	--1234	離職後 5 年
薪資金額	高	AES-256 (靜態)	不遮罩（權限控制）	永久
手機號碼	中	無（權限控制）	09xx-xxx-789	離職後 2 年
Email	低	無	無	離職後 2 年

需求 ID	需求描述	ASVS 參照	Level	必須/建議
SEC-DATA-001	個資欄位靜態加密儲存（AES-256）	V6.2.1	L2	必須
SEC-DATA-002	所有傳輸使用 TLS 1.2+	V9.1.1	L1	必須
SEC-DATA-003	日誌中禁止記錄敏感資料明文	V8.3.1	L1	必須
SEC-DATA-004	資料庫備份亦需加密	V6.2.3	L2	必須

6. 輸入驗證與輸出編碼

📝 範本

需求 ID	需求描述	ASVS 參照	Level	必須/建議	實作狀態
SEC-INPUT-001	{輸入驗證需求}	V5.{x}	L{N}	必須/建議	☐

📖 使用說明

對應 OWASP ASVS V5（Validation, Sanitization and Encoding）
防禦 OWASP Top 10 中的注入攻擊（SQL Injection、XSS、Command Injection）
原則：永不信任使用者輸入，伺服器端必須驗證

💡 範例

需求 ID	需求描述	ASVS 參照	Level	必須/建議
SEC-INPUT-001	所有使用者輸入在伺服器端進行驗證（白名單）	V5.1.1	L1	必須
SEC-INPUT-002	使用參數化查詢防止 SQL Injection	V5.3.4	L1	必須
SEC-INPUT-003	HTML 輸出使用 Context-Aware 編碼防止 XSS	V5.3.3	L1	必須
SEC-INPUT-004	檔案上傳驗證副檔名、MIME Type、大小限制	V5.1.4	L1	必須
SEC-INPUT-005	API 輸入限制 Content-Length，防止 DoS	V5.1.5	L1	必須

7. Session 管理

📝 範本

需求 ID	需求描述	ASVS 參照	Level	必須/建議	實作狀態
SEC-SESS-001	{Session 管理需求}	V3.{x}	L{N}	必須/建議	☐

📖 使用說明

對應 OWASP ASVS V3（Session Management）
Session 管理攸關身份劫持風險
需求涵蓋：Session ID 強度、過期設定、Cookie 安全屬性

💡 範例

需求 ID	需求描述	ASVS 參照	Level	必須/建議
SEC-SESS-001	Session ID 長度 ≥ 128 bits，由加密安全亂數產生	V3.2.1	L1	必須
SEC-SESS-002	Cookie 設定 HttpOnly、Secure、SameSite=Strict	V3.4.1	L1	必須
SEC-SESS-003	閒置 30 分鐘後自動登出	V3.3.1	L1	必須
SEC-SESS-004	登入後重新產生 Session ID（防 Fixation）	V3.2.3	L1	必須
SEC-SESS-005	支援使用者查看與終止其他裝置 Session	V3.3.4	L2	建議

8. 日誌與監控需求

📝 範本

需求 ID	需求描述	ASVS 參照	Level	必須/建議	實作狀態
SEC-LOG-001	{日誌監控需求}	V7.{x}	L{N}	必須/建議	☐

稽核事件定義

事件類型	記錄內容	保留期限
{事件}	{需記錄的欄位}	{期限}

📖 使用說明

對應 OWASP ASVS V7（Error Handling and Logging）
日誌是事後追查與即時偵測的基礎
重點：記什麼、不記什麼（禁止記錄密碼/Token）、保存多久

💡 範例

需求 ID	需求描述	ASVS 參照	Level	必須/建議
SEC-LOG-001	記錄所有認證事件（登入成功/失敗/登出）	V7.1.1	L1	必須
SEC-LOG-002	記錄所有授權失敗事件	V7.1.2	L1	必須
SEC-LOG-003	日誌中禁止包含 Session Token、密碼、個資	V7.1.3	L1	必須
SEC-LOG-004	日誌保留 ≥ 90 天，不可竄改	V7.3.1	L2	必須
SEC-LOG-005	連續 5 次認證失敗觸發即時告警	V7.4.1	L2	必須

稽核事件定義

事件類型	記錄內容	保留期限
登入成功	時間、帳號、IP、User-Agent	180 天
登入失敗	時間、帳號、IP、失敗原因	180 天
權限變更	時間、操作者、變更內容	365 天
個資存取	時間、帳號、存取的個資類型	365 天
資料匯出	時間、帳號、匯出範圍、筆數	365 天

9. 通訊安全

📝 範本

需求 ID	需求描述	ASVS 參照	Level	必須/建議	實作狀態
SEC-COMM-001	{通訊安全需求}	V9.{x}	L{N}	必須/建議	☐

📖 使用說明

對應 OWASP ASVS V9（Communication）
保護傳輸中資料不被竊聽或竄改
涵蓋：TLS 版本、憑證管理、HSTS、內部通訊加密

💡 範例

需求 ID	需求描述	ASVS 參照	Level	必須/建議
SEC-COMM-001	所有外部通訊使用 TLS 1.2 以上	V9.1.1	L1	必須
SEC-COMM-002	啟用 HSTS（max-age ≥ 1 年）	V9.1.2	L1	必須
SEC-COMM-003	伺服器憑證由受信任 CA 簽發	V9.2.1	L1	必須
SEC-COMM-004	服務間（微服務）通訊使用 mTLS	V9.2.2	L2	建議
SEC-COMM-005	禁用 SSL 3.0、TLS 1.0/1.1	V9.1.3	L1	必須

10. 組態安全

📝 範本

需求 ID	需求描述	ASVS 參照	Level	必須/建議	實作狀態
SEC-CFG-001	{組態安全需求}	V14.{x}	L{N}	必須/建議	☐

📖 使用說明

對應 OWASP ASVS V14（Configuration）
安全組態確保系統不因錯誤設定而暴露弱點
涵蓋：預設帳號、除錯模式、HTTP 安全標頭、依賴管理

💡 範例

需求 ID	需求描述	ASVS 參照	Level	必須/建議
SEC-CFG-001	正式環境禁止開啟除錯模式 / 詳細錯誤訊息	V14.1.1	L1	必須
SEC-CFG-002	移除或停用所有預設帳號與密碼	V14.1.2	L1	必須
SEC-CFG-003	設定安全 HTTP Headers（CSP, X-Frame-Options 等）	V14.4.1	L1	必須
SEC-CFG-004	第三方依賴無已知 High/Critical CVE	V14.2.1	L1	必須
SEC-CFG-005	機敏設定（DB 連線字串、API Key）使用 Secret Manager	V14.1.5	L2	必須

11. 合規性需求

📝 範本

法規/標準	適用條款	系統需求對應	實作狀態
{法規名稱}	{條款}	{系統需滿足的具體需求}	☐

📖 使用說明

列出系統需遵循的法規、產業標準、企業政策
每條法規要求需轉化為可驗證的技術需求
常見法規：個人資料保護法、GDPR、PCI DSS、ISO 27001

💡 範例

法規/標準	適用條款	系統需求對應	實作狀態
個人資料保護法	第 27 條（安全維護措施）	個資加密儲存、存取控制、稽核日誌	☑
個人資料保護法	第 11 條（當事人權利）	提供個資查詢、更正、刪除功能	☑
ISO 27001:2022	A.8.3（存取控制）	RBAC 實作	☑
ISO 27001:2022	A.8.24（密碼學使用）	TLS 1.2+、AES-256 加密	☑
公司資安政策	密碼政策 v3.0	12 字元 + 複雜度 + 90 天更換	☐

12. 附錄

📝 範本

12.1 安全需求完成度統計

類別	總需求數	已實作	未實作	完成率
認證（AUTH）	{N}	{N}	{N}	{%}
授權（AUTHZ）	{N}	{N}	{N}	{%}
資料保護（DATA）	{N}	{N}	{N}	{%}
輸入驗證（INPUT）	{N}	{N}	{N}	{%}
Session（SESS）	{N}	{N}	{N}	{%}
日誌監控（LOG）	{N}	{N}	{N}	{%}
通訊安全（COMM）	{N}	{N}	{N}	{%}
組態安全（CFG）	{N}	{N}	{N}	{%}
合計	{N}	{N}	{N}	{%}

12.2 OWASP ASVS 對照表

ASVS 章節	主題	本文件對應章節
V2	Authentication	第 3 章
V3	Session Management	第 7 章
V4	Access Control	第 4 章
V5	Validation	第 6 章
V6	Stored Cryptography	第 5 章
V7	Error Handling & Logging	第 8 章
V8	Data Protection	第 5 章
V9	Communication	第 9 章
V14	Configuration	第 10 章

📖 使用說明

完成度統計用於追蹤安全需求落實進度
所有「必須」等級的需求需在上線前 100% 實作
ASVS 對照表協助資安審核人員快速定位驗證範圍

💡 範例

12.1 安全需求完成度統計

類別	總需求數	已實作	未實作	完成率
認證（AUTH）	6	5	1	83%
授權（AUTHZ）	5	4	1	80%
資料保護（DATA）	4	4	0	100%
輸入驗證（INPUT）	5	5	0	100%
Session（SESS）	5	4	1	80%
日誌監控（LOG）	5	3	2	60%
通訊安全（COMM）	5	5	0	100%
組態安全（CFG）	5	4	1	80%
合計	40	34	6	85%

📌 範本使用注意事項