軟體工程

威脅模型範本（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） 參照標準：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% 📌 範本使用注意事項 ...

標準作業程序範本（Standard Operating Procedure, SOP） 參照標準：ISO 9001:2015（Quality Management）/ ISO/IEC 20000-1:2018 / ITIL 4 文件用途：標準化維運操作流程，確保操作一致性、降低人為錯誤、加速新人上手 適用階段：維運監控階段（Operations Phase）— Operational Excellence 📋 章節目錄 文件資訊 目的與範圍 角色與職責 前置條件 操作步驟 驗證與確認 異常處理 安全注意事項 相關文件 變更歷史 1. 文件資訊 📝 範本 項目 內容 文件編號 SOP-{類別代碼}-{序號} 文件名稱 {操作名稱} 標準作業程序 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 / 作廢 建立日期 {YYYY-MM-DD} 生效日期 {YYYY-MM-DD} 下次審核日期 {YYYY-MM-DD}（至少每年） 撰寫者 {姓名/角色} 審核者 {姓名/角色} 核准者 {姓名/角色} 適用系統 {系統/服務名稱} 機密等級 一般 / 限閱 / 機密 📖 使用說明 SOP 編號慣例：SOP-{類別}-{流水號} 類別代碼範例：DEP（部署）、INC（事件處理）、BAK（備份）、MON（監控） 每份 SOP 需定期審核（ISO 9001 要求），避免過時 狀態管理：草稿 → 審核中 → 核定（可執行）→ 作廢（新版取代） 機密等級決定誰可以存取此 SOP 💡 範例 項目 內容 文件編號 SOP-BAK-001 文件名稱 HRMS 資料庫每日備份標準作業程序 版本 v2.0 生效日期 2026-05-01 下次審核日期 2027-05-01 適用系統 HRMS PostgreSQL 16 (Azure Database) 2. 目的與範圍 📝 範本 2.1 目的 {說明此 SOP 為何存在、解決什麼問題} ...

測試報告範本（Test Report） 參照標準：ISO/IEC/IEEE 29119-3:2021（Test Completion Report） 文件用途：彙整測試執行結果，評估軟體品質，提供上線/不上線的決策依據 適用階段：測試驗證階段（Testing Phase）— Test Completion 📋 章節目錄 文件資訊 執行摘要 測試範圍 測試環境 測試執行結果 缺陷分析 覆蓋率分析 風險與未解決項目 品質評估與建議 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TR-{專案代碼}-{迭代/版本}-{序號} 文件名稱 {系統名稱} 測試報告 版本 v{主版本}.{次版本} 測試版本 {受測軟體版本號} 測試類型 單元/整合/系統/UAT/回歸/效能/安全 測試週期 {YYYY-MM-DD} ~ {YYYY-MM-DD} 撰寫者 {QA 負責人} 審核者 {PM/Tech Lead} 發佈日期 {YYYY-MM-DD} 📖 使用說明 每個重要測試里程碑（Sprint 結束、版本發佈前）產出測試報告 測試類型依實際執行的測試活動填寫，可為複合型（如「系統 + 效能」） 測試版本需明確對應 Git Tag / Build Number，確保可追溯 💡 範例 項目 內容 文件編號 TR-HRM-v2.1-001 系統名稱 人力資源管理系統 測試版本 v2.1.0-rc.1 (Build #487) 測試類型 系統測試 + 回歸測試 + 效能測試 測試週期 2026-05-01 ~ 2026-05-15 2. 執行摘要 📝 範本 2.1 整體結論 項目 結果 上線建議 ✅ 建議上線 / ⚠️ 有條件上線 / ❌ 不建議上線 品質等級 優良 / 合格 / 不合格 主要風險 {簡述主要殘餘風險} 2.2 關鍵指標概覽 指標 數值 目標 達標 測試案例通過率 {%} ≥ {%} ✅/❌ 缺陷密度（Defect/KLOC） {N} ≤ {N} ✅/❌ 嚴重缺陷（Critical/High）未解決 {N} 0 ✅/❌ 需求覆蓋率 {%} ≥ {%} ✅/❌ 程式碼覆蓋率 {%} ≥ {%} ✅/❌ 效能指標達標率 {%} 100% ✅/❌ 📖 使用說明 執行摘要是最重要的章節，決策者可能只看這部分 上線建議需有客觀數據支持，非主觀判斷 「有條件上線」需明確列出條件（如：特定功能暫不開放、需加監控） 關鍵指標的目標值應在測試計畫中事先定義 💡 範例 2.1 整體結論 項目 結果 上線建議 ⚠️ 有條件上線 品質等級 合格 主要風險 2 個 Medium 缺陷待修、大量匯出效能未達標 2.2 關鍵指標概覽 指標 數值 目標 達標 測試案例通過率 96.8% ≥ 95% ✅ 缺陷密度 2.3/KLOC ≤ 5/KLOC ✅ 嚴重缺陷未解決 0 0 ✅ 需求覆蓋率 98% ≥ 95% ✅ 程式碼覆蓋率 82% ≥ 80% ✅ 效能指標達標率 90% 100% ❌ 3. 測試範圍 📝 範本 3.1 測試項目（In Scope） 模組/功能 測試類型 優先級 執行狀態 {模組名稱} {測試類型} 高/中/低 完成/部分/未執行 3.2 排除項目（Out of Scope） 模組/功能 排除原因 {模組名稱} {原因} 📖 使用說明 明確列出本次測試涵蓋與不涵蓋的範圍 排除原因需合理（如：未修改的模組、下一版本範圍） 執行狀態若為「部分」或「未執行」，需在風險章節說明影響 💡 範例 3.1 測試項目 模組/功能 測試類型 優先級 執行狀態 員工資料管理（CRUD） 系統測試 + 回歸 高 完成 薪資計算引擎 系統測試 + 回歸 高 完成 請假/加班申請流程 系統測試 + 回歸 高 完成 報表匯出（PDF/Excel） 系統測試 + 效能 中 完成 SSO 登入整合 整合測試 高 完成 API 效能（並發） 效能測試 中 完成 3.2 排除項目 模組/功能 排除原因 行動 App v2.2 規劃範圍，本版未開發 第三方薪轉介接（銀行 API） 銀行端 UAT 環境未就緒 4. 測試環境 📝 範本 項目 規格 環境名稱 {SIT/UAT/Staging/Performance} 作業系統 {OS 版本} 應用伺服器 {Server + 版本} 資料庫 {DB + 版本} 測試資料 {描述：模擬資料量/來源} 測試工具 {工具清單} 與正式環境差異 {列出差異} 📖 使用說明 測試環境資訊確保結果可重現 必須列出與正式環境的差異（差異可能影響結果有效性） 效能測試環境應盡量接近正式規格 💡 範例 項目 規格 環境名稱 Staging (Azure AKS) 作業系統 Ubuntu 22.04 (K8s Node) 應用伺服器 .NET 8 Kestrel + Kong 3.5 資料庫 PostgreSQL 16.2 (Azure Database) 測試資料 模擬 10,000 員工、3 年歷史資料 測試工具 xUnit, Playwright, JMeter 5.6, SonarQube 與正式環境差異 節點數 3（正式 6）、資料量為正式 20% 5. 測試執行結果 📝 範本 5.1 測試案例執行統計 狀態 數量 百分比 通過（Pass） {N} {%} 失敗（Fail） {N} {%} 阻塞（Blocked） {N} {%} 未執行（Not Run） {N} {%} 總計 {N} 100% 5.2 按模組分佈 模組 總案例 通過 失敗 阻塞 通過率 {模組} {N} {N} {N} {N} {%} 5.3 效能測試結果（如適用） 場景 指標 目標 實際 達標 {場景} {指標} {目標值} {實際值} ✅/❌ 📖 使用說明 統計數據需與測試管理工具（如 Azure DevOps Test Plan）數據一致 失敗案例需逐一追蹤到缺陷 ID 阻塞案例需說明阻塞原因（環境問題？依賴未就緒？） 效能測試報告重點指標：回應時間、吞吐量、錯誤率 💡 範例 5.1 測試案例執行統計 狀態 數量 百分比 通過（Pass） 242 96.8% 失敗（Fail） 5 2.0% 阻塞（Blocked） 2 0.8% 未執行（Not Run） 1 0.4% 總計 250 100% 5.2 按模組分佈 模組 總案例 通過 失敗 阻塞 通過率 員工資料管理 65 64 1 0 98.5% 薪資計算 80 78 2 0 97.5% 請假/加班 55 54 0 1 98.2% 報表匯出 30 28 2 0 93.3% SSO 登入 20 18 0 1 90.0%* 5.3 效能測試結果 場景 指標 目標 實際 達標 登入（100 concurrent） P95 回應時間 ≤ 500ms 320ms ✅ 員工查詢（200 concurrent） P95 回應時間 ≤ 1000ms 780ms ✅ 薪資計算批次（10,000筆） 總處理時間 ≤ 5min 3.2min ✅ 報表匯出（5,000筆 Excel） 回應時間 ≤ 30s 45s ❌ API 持續壓力（1hr, 500 TPS） 錯誤率 ≤ 0.1% 0.05% ✅ 6. 缺陷分析 📝 範本 6.1 缺陷統計 嚴重度 發現 已修復 未修復 已驗證 Critical {N} {N} {N} {N} High {N} {N} {N} {N} Medium {N} {N} {N} {N} Low {N} {N} {N} {N} 總計 {N} {N} {N} {N} 6.2 缺陷明細（未解決） 缺陷 ID 嚴重度 模組 描述 狀態 處置方式 {ID} {等級} {模組} {描述} {狀態} 下版修復/暫時方案/接受 6.3 缺陷趨勢 累計發現 vs 累計解決 趨勢圖（收斂曲線） 📖 使用說明 Critical/High 未解決 = 不建議上線（除非有合理的暫時方案） 缺陷趨勢圖需呈現「收斂」趨勢（發現率下降、解決追上發現） 缺陷明細只列未解決的，已解決的在附錄提供完整清單 處置方式需經 PM/Tech Lead 核准 💡 範例 6.1 缺陷統計 嚴重度 發現 已修復 未修復 已驗證 Critical 1 1 0 1 High 3 3 0 3 Medium 8 6 2 6 Low 5 3 2 3 總計 17 13 4 13 6.2 缺陷明細（未解決） 缺陷 ID 嚴重度 模組 描述 狀態 處置方式 BUG-142 Medium 報表匯出 Excel 匯出超過 5000 筆時超時 (45s > 30s) Open v2.2 修復（分頁匯出） BUG-145 Medium 報表匯出 PDF 頁首日期格式錯誤 Open v2.1.1 Hotfix BUG-148 Low 員工管理 姓名超過 50 字元時 UI 顯示截斷 Open v2.2 修復 BUG-150 Low 薪資計算 計算說明欄位未支援多語系 Open v2.2 修復 7. 覆蓋率分析 📝 範本 7.1 需求覆蓋率 需求類型 總需求數 已覆蓋 未覆蓋 覆蓋率 功能需求（FR） {N} {N} {N} {%} 非功能需求（NFR） {N} {N} {N} {%} 安全需求（SEC） {N} {N} {N} {%} 7.2 程式碼覆蓋率 模組 行覆蓋率 分支覆蓋率 方法覆蓋率 {模組} {%} {%} {%} 📖 使用說明 需求覆蓋率：確保每個需求至少有一個測試案例覆蓋 程式碼覆蓋率：通常由 CI/CD 工具（SonarQube、Istanbul）自動產出 目標值：需求覆蓋率 ≥ 95%、行覆蓋率 ≥ 80%、分支覆蓋率 ≥ 70% 未覆蓋的需求需說明原因 💡 範例 7.1 需求覆蓋率 需求類型 總需求數 已覆蓋 未覆蓋 覆蓋率 功能需求（FR） 45 44 1* 97.8% 非功能需求（NFR） 12 12 0 100% 安全需求（SEC） 40 38 2** 95% *FR-032（行動 App 推播）排除於本版 **SEC-SESS-005、SEC-COMM-004 為建議等級，計畫 v2.2 驗證 ...

測試案例範本（Test Case Template） 參照標準：ISO/IEC/IEEE 29119-3:2021（取代 IEEE 829-2008）/ ISO/IEC/IEEE 29119-4:2021（Test Techniques） 文件用途：定義測試案例的標準格式，確保測試設計完整、可追溯、可重複執行 適用階段：測試設計與執行階段 📋 章節目錄 文件資訊 測試案例識別規範 測試案例格式定義 測試案例撰寫規範 測試案例分類 測試案例清單範本 測試案例詳細格式 測試資料規劃 測試執行紀錄 缺陷報告格式 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TC-{專案代碼}-{模組}-{序號} 文件名稱 {系統名稱} {模組名稱} 測試案例 版本 v{主版本}.{次版本} 對應測試計畫 {TP 文件編號} 對應需求 {FRD 文件編號} 撰寫者 {姓名} 審核者 {姓名} 建立日期 {YYYY-MM-DD} 📖 使用說明 測試案例文件承接測試計畫（Test Plan），為各測試項目設計具體的驗證步驟 每個功能模組可獨立一份測試案例文件，或匯整於單一文件中 文件需經 QA Lead 或測試經理審核後方可執行 💡 範例 項目 內容 文件編號 TC-HRM-LV-001 文件名稱 HRMS 假勤管理模組 測試案例 對應測試計畫 TP-HRM-001 對應需求 FRD-HRM-001 v2.1 2. 測試案例識別規範 📝 範本 2.1 編號規則 TC-{專案}-{模組}-{序號} 欄位 說明 範例 TC 固定前綴（Test Case） TC {專案} 專案代碼（2-5 字元） HRM {模組} 模組縮寫（2-5 字元） LV（Leave） {序號} 三位數流水號 001 2.2 命名規範 測試案例名稱格式：[測試類型] {功能描述} - {情境描述} ...

測試計畫範本（Test Plan） 參照標準：ISO/IEC/IEEE 29119-3:2021（取代 IEEE 829-2008） 文件用途：定義測試範圍、策略、資源、時程與風險，指導整體測試活動 適用階段：測試準備階段（Test Planning Phase） 📋 章節目錄 文件資訊 測試計畫識別 引言 測試項目 測試策略與方法 通過與失敗標準 暫停與恢復準則 測試交付物 測試環境需求 職責分工 時程與里程碑 風險與緩解措施 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 TP-{專案代碼}-{序號} 文件名稱 {系統名稱} 測試計畫 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 核定 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 撰寫者 {姓名/角色} 審核者 {姓名/角色} 對應 FRD {FRD 文件編號} 測試層級 {Unit / Integration / System / UAT} 版本歷程 版本 日期 修改人 修改內容摘要 v0.1 {YYYY-MM-DD} {姓名} 初版建立 📖 使用說明 依據 ISO/IEC/IEEE 29119-3:2021 第 7 節「Test Plan documentation」 測試計畫可依測試層級分開撰寫（如 SIT 測試計畫、UAT 測試計畫） 一個專案可有多份測試計畫，也可合併為一份主測試計畫（Master Test Plan） 💡 範例 項目 內容 文件編號 TP-HRM-001 文件名稱 人力資源管理系統 系統整合測試計畫 測試層級 System Integration Test (SIT) 對應 FRD FRD-HRM-001 v2.1 2. 測試計畫識別 📝 範本 項目 內容 專案名稱 {專案正式名稱} 受測系統 {系統名稱及版本} 測試階段 {SIT / UAT / Performance / Security} 測試期間 {起始日期} ~ {結束日期} 測試團隊 {團隊名稱} 📖 使用說明 明確識別「測什麼」、「測多久」、「誰來測」 測試期間需與專案整體時程對齊 💡 範例 項目 內容 專案名稱 人力資源管理系統建置專案 受測系統 HRMS v1.0.0 測試階段 SIT（系統整合測試） 測試期間 2026-09-01 ~ 2026-09-30 測試團隊 QA 品質保證組 3. 引言 📝 範本 3.1 測試目的 {描述本次測試活動的目標} ...

版本發行說明範本（Release Notes） 參照標準：Keep a Changelog 1.1.0 / SemVer 2.0.0 / ISO/IEC/IEEE 12207:2017（Release Management） 文件用途：正式記錄每個版本的變更內容，供開發、維運、使用者了解版本差異 適用階段：部署上線階段（Deployment Phase）— Release Management 📋 章節目錄 文件資訊 版本摘要 新增功能（Added） 變更項目（Changed） 修復項目（Fixed） 棄用項目（Deprecated） 移除項目（Removed） 安全性修復（Security） 已知問題（Known Issues） 升級指南 相容性說明 1. 文件資訊 📝 範本 項目 內容 產品名稱 {系統名稱} 版本號 v{MAJOR}.{MINOR}.{PATCH} 發佈日期 {YYYY-MM-DD} 版本類型 Major / Minor / Patch / Hotfix 發佈人 {Release Manager 姓名} Git Tag {tag name} Build Number #{build} 對應里程碑 {Sprint/Milestone 名稱} 📖 使用說明 版本號遵循 SemVer 2.0.0： MAJOR：不相容的 API 變更 MINOR：向後相容的新功能 PATCH：向後相容的 Bug 修復 每次正式發佈（含 Hotfix）都需要 Release Notes Git Tag 與 Build Number 確保可從 Release Notes 追溯到原始碼 💡 範例 項目 內容 產品名稱 人力資源管理系統（HRMS） 版本號 v2.1.0 發佈日期 2026-05-20 版本類型 Minor 發佈人 林 DevOps Git Tag v2.1.0 Build Number #489 對應里程碑 Sprint 12 2. 版本摘要 📝 範本 概述 {用 2-3 句話描述本版本的核心主題與重要變更} ...

系統需求規格書範本（System Requirements Document, SRD） 參照標準：ISO/IEC/IEEE 29148:2018（Systems and Software Engineering — Requirements Engineering） 文件用途：定義系統層級的完整需求（功能、效能、安全、介面），作為設計與驗證的基準 適用階段：需求分析階段（Requirements Phase）— System-Level Requirements 📋 章節目錄 文件資訊 系統概述 系統功能需求 系統介面需求 效能需求 安全需求摘要 可靠性與可用性 限制條件 需求追溯矩陣 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 SRD-{專案代碼}-{版本} 文件名稱 {系統名稱} 系統需求規格書 版本 v{主版本}.{次版本} 狀態 草稿 / 審核中 / 基線化 建立日期 {YYYY-MM-DD} 撰寫者 {系統分析師} 審核者 {Tech Lead / 架構師} 核准者 {PM / 產品負責人} 基線版本 {基線化日期，變更需走 CR 流程} 📖 使用說明 SRD 位於需求文件階層的中間層： BRD（商業需求）→ SRD（系統需求） → FRD（功能需求） SRD 將商業需求轉化為系統可實作的技術需求 「基線化」後的變更需經正式變更控制流程（Change Request） 依 ISO/IEC/IEEE 29148:2018 Section 6.2（System Requirements Specification） 💡 範例 項目 內容 文件編號 SRD-HRM-v1.0 系統名稱 人力資源管理系統（HRMS） 版本 v1.0 基線版本 2026-04-01（Sprint 10 結束） 2. 系統概述 📝 範本 2.1 系統目的 {描述系統存在的理由與欲解決的核心問題} ...

變更日誌範本（CHANGELOG Template） 參照標準：Keep a Changelog 1.1.0 / Semantic Versioning 2.0.0 文件用途：記錄專案每個版本的顯著變更，讓使用者與開發者了解版本間的差異 適用階段：專案全生命週期（每次發版皆需更新） 📋 章節目錄 文件資訊 格式規範 變更類別定義 版本編號規則 撰寫規範 CHANGELOG 完整範本 自動化產生 附錄 1. 文件資訊 📝 範本 項目 內容 文件名稱 CHANGELOG.md 位置 專案根目錄 格式 Markdown（Keep a Changelog 格式） 維護者 {Release Manager / 開發團隊} 更新時機 每次版本發布（Release） 📖 使用說明 CHANGELOG.md 置於專案根目錄，與 README.md 並列 每次 Release 前更新，不是每個 Commit 都記錄 記錄「對使用者有意義的變更」，非所有技術細節 💡 範例 CHANGELOG.md 通常長這樣的開頭： # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). 2. 格式規範 📝 範本 # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - {新功能描述} ## [{版本號}] - {YYYY-MM-DD} ### Added - {新增功能} ### Changed - {變更項目} ### Deprecated - {即將移除的功能} ### Removed - {已移除的功能} ### Fixed - {修復的問題} ### Security - {安全性修復} [Unreleased]: {repo-url}/compare/v{版本}...HEAD [{版本號}]: {repo-url}/compare/v{前版本}...v{版本} 📖 使用說明 [Unreleased] 區塊永遠在最上方，收集尚未發布的變更 發版時將 [Unreleased] 內容移至新版本區塊 版本由新到舊排列（最新在最上面） 底部的連結區塊提供版本間的 diff 比較連結 💡 範例 見第 6 節完整範本。 ...

運維手冊範本（Runbook） 參照標準：ITIL 4 Service Operation / ISO/IEC 20000-1:2018 第 8.5 節「Service delivery」 文件用途：提供系統日常維運、告警處理、故障排除的標準化操作程序 適用階段：營運維護階段（Operations & Maintenance） 📋 章節目錄 文件資訊 系統概述 常見操作程序 告警處理 故障排除決策樹 緊急聯絡人 SLA 與 SLO 維護窗口與排程作業 備份與還原 附錄 1. 文件資訊 📝 範本 項目 內容 文件編號 RB-{專案代碼}-{序號} 文件名稱 {系統名稱} 運維手冊 版本 v{主版本}.{次版本} 建立日期 {YYYY-MM-DD} 最後更新 {YYYY-MM-DD} 維護者 {姓名/團隊} 適用環境 Production / Staging / All 版本歷程 版本 日期 修改人 修改內容 v1.0 {日期} {姓名} 初版 📖 使用說明 Runbook 為活文件，需隨系統變更持續更新 任何維運操作變更需同步更新本文件 建議每季審閱一次，確保內容與現況一致 💡 範例 項目 內容 文件編號 RB-HRM-001 文件名稱 HRMS 運維手冊 維護者 DevOps 團隊 — 周維運 適用環境 Production 2. 系統概述 📝 範本 2.1 系統架構 {架構圖 — 包含所有元件與連接關係} 2.2 元件清單 元件名稱 技術堆疊 部署位置 端點 用途 {元件} {技術} {位置} {URL/IP} {說明} 2.3 相依服務 外部服務 用途 端點 擁有者 SLA {服務} {用途} {端點} {團隊} {SLA} 2.4 存取方式 環境 入口 認證方式 備註 {環境} {URL/方式} {認證} {備註} 📖 使用說明 系統概述幫助值班人員快速了解系統全貌 元件清單需包含所有運行中的服務（含背景 Worker、排程任務等） 相依服務標明擁有者，出問題時知道找誰 💡 範例 2.2 元件清單 元件名稱 技術堆疊 部署位置 端點 用途 hrms-api .NET 8 Web API AKS hrms-prod ns https://hrms-api.internal:443 後端 API hrms-web React 18 + Nginx AKS hrms-prod ns https://hrms.company.com 前端 SPA hrms-worker .NET 8 Worker Service AKS hrms-prod ns N/A（內部處理） 背景排程任務 PostgreSQL v16 Azure DB for PostgreSQL hrms-db.postgres.database.azure.com:5432 主資料庫 Redis v7 Azure Cache for Redis hrms-cache.redis.cache.windows.net:6380 Session + Cache 3. 常見操作程序 📝 範本 3.1 {操作名稱} 項目 內容 操作目的 {為什麼要做} 執行頻率 手動觸發 / 每日 / 每週 / 每月 預估時間 {分鐘} 影響範圍 {影響說明} 所需權限 {權限} 步驟： ...