威脅模型範本(Threat Model Template)

威脅模型範本(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 殘餘風險核准接受 📌 範本使用注意事項 ...

May 18, 2026 · 6 min · 1071 words · Eric Cheng

安全需求清單範本(Security Requirements Checklist Template)

安全需求清單範本(Security Requirements Checklist) 參照標準:OWASP ASVS 4.0.3(Application Security Verification Standard)/ ISO/IEC 27001:2022 Annex A 文件用途:定義系統應滿足的安全需求,確保設計與開發階段納入安全考量 適用階段:需求分析階段(Requirements Phase)— Security by Design 📋 章節目錄 文件資訊 安全需求概述 認證需求 授權與存取控制 資料保護需求 輸入驗證與輸出編碼 Session 管理 日誌與監控需求 通訊安全 組態安全 合規性需求 附錄 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% 📌 範本使用注意事項 ...

May 18, 2026 · 6 min · 1135 words · Eric Cheng