事件報告與根因分析範本(Incident Report & RCA Template)

事件報告與根因分析範本(Incident Report & Root Cause Analysis) 參照標準:ITIL 4(Incident Management & Problem Management)/ ISO/IEC 20000-1:2018 / SRE Postmortem 文件用途:記錄生產環境事件、分析根本原因、制定改善行動,防止問題再次發生 適用階段:維運監控階段(Operations Phase)— Continuous Improvement 📋 章節目錄 事件摘要 時間軸 影響評估 根因分析 解決方案 改善行動計畫 經驗教訓 附錄 1. 事件摘要 📝 範本 項目 內容 事件編號 INC-{YYYYMMDD}-{序號} 事件標題 {一句話描述事件} 嚴重等級 SEV1(Critical)/ SEV2(Major)/ SEV3(Minor)/ SEV4(Low) 事件狀態 調查中 / 已解決 / 已關閉 發生時間 {YYYY-MM-DD HH:MM} (UTC+8) 偵測時間 {YYYY-MM-DD HH:MM} 解決時間 {YYYY-MM-DD HH:MM} 事件持續時間 {N} 分鐘/小時 MTTD {偵測時間 - 發生時間} MTTR {解決時間 - 偵測時間} 受影響系統 {系統/服務名稱} 受影響使用者 {人數/比例} 事件負責人 {Incident Commander} 報告撰寫者 {姓名} 報告日期 {YYYY-MM-DD} 📖 使用說明 嚴重等級定義: SEV1:核心業務完全中斷,影響全部使用者 SEV2:核心功能嚴重降級,影響大部分使用者 SEV3:非核心功能異常,影響部分使用者 SEV4:輕微異常,幾乎不影響使用者 MTTD(Mean Time To Detect):衡量監控能力 MTTR(Mean Time To Resolve):衡量恢復能力 事件報告需在事件解決後 3-5 個工作日 內完成 Blameless 原則:報告聚焦系統與流程改善,不歸咎個人 💡 範例 項目 內容 事件編號 INC-20260520-001 事件標題 HRMS 薪資查詢 API 持續回傳 500 Error 嚴重等級 SEV2(核心功能嚴重降級) 發生時間 2026-05-20 10:15 偵測時間 2026-05-20 10:18(Grafana 告警) 解決時間 2026-05-20 10:28(回滾完成) 事件持續時間 13 分鐘 MTTD 3 分鐘 MTTR 10 分鐘 受影響使用者 ~200 人(薪資查詢功能不可用) 事件負責人 張 SRE 2. 時間軸 📝 範本 時間 (UTC+8) 事件 執行者 備註 {HH:MM} {發生/偵測/行動/解決} {人員} {補充說明} 📖 使用說明 時間軸是事件報告最有價值的部分,需精確到分鐘 涵蓋:事件發生 → 偵測 → 通知 → 診斷 → 緩解 → 解決 → 驗證 資料來源:監控日誌、Slack 訊息時間戳、告警記錄 時間軸讓團隊復盤流程效率,找出可改善的環節 💡 範例 時間 (UTC+8) 事件 執行者 備註 10:12 v2.1.0 部署完成,新版上線 DevOps 林 K8s Green deployment 完成 10:15 薪資計算排程 CronJob 啟動(與 API 衝突) System 排程被新設定觸發 10:15 DB Lock 衝突開始,API 回應逾時 System PostgreSQL row-level lock 10:18 Grafana 告警:5xx rate > 5% Alert System #hrms-alerts 頻道 10:19 SRE 張確認告警,開始調查 SRE 張 檢查 Pod 日誌 10:21 確認問題:DB Lock contention SRE 張 pg_stat_activity 發現 lock wait 10:23 聯繫 Tech Lead 決策:啟動回滾 SRE 張 → Tech Lead 王 Slack 通訊 10:24 Tech Lead 確認回滾,授權執行 Tech Lead 王 10:25 開始執行回滾腳本 SRE 張 ./rollback-hrms-v2.1.0.sh 10:27 流量切換至 v2.0.3 完成 SRE 張 Blue deployment 10:28 健康檢查通過,冒煙測試通過 SRE 張 + QA 陳 服務恢復 10:30 通知團隊:服務已恢復 SRE 張 Slack + Email 10:45 通知受影響使用者:服務已恢復 PM 林 系統公告 3. 影響評估 📝 範本 3.1 業務影響 影響維度 評估 受影響功能 {功能清單} 受影響使用者數 {人數/比例} 收入損失 {金額/無法計量} 資料損失 {是/否,描述} SLA 違反 {是/否,影響 SLA 指標} 信譽影響 {高/中/低} 3.2 技術影響 影響維度 評估 受影響服務 {服務清單} 相依服務影響 {是否連鎖影響} 資料一致性 {是否受影響} 安全性影響 {是否有安全疑慮} 📖 使用說明 影響評估用於確認嚴重等級是否正確、作為改善優先級依據 業務影響由 PM/產品團隊提供;技術影響由工程團隊評估 SLA 違反需記錄,可能涉及客戶賠償或內部 KPI 💡 範例 3.1 業務影響 影響維度 評估 受影響功能 薪資查詢、薪資條下載 受影響使用者數 ~200 人(嘗試查詢薪資的員工) 收入損失 無直接收入損失(內部系統) 資料損失 無 SLA 違反 否(SLA 99.5% 月度,本月仍在 SLA 內) 信譽影響 低(事件持續 13 分鐘,非上班尖峰) 4. 根因分析 📝 範本 4.1 根本原因 Root Cause Statement: ...

May 18, 2026 · 5 min · 951 words · Eric Cheng

使用案例文件範本(Use Case Document Template)

使用案例文件範本(Use Case Document Template) 適用標準:ISO/IEC/IEEE 29148:2018、UML 2.5.1(Unified Modeling Language) 適用階段:需求分析階段(Requirements Phase) 負責角色:系統分析師(SA)、業務分析師(BA) 📑 章節目錄 文件資訊 系統範圍與參與者 使用案例圖(Use Case Diagram) 使用案例清單 使用案例規格(逐案詳述) 業務規則 非功能性需求對應 追溯矩陣 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 使用案例文件 文件編號 [專案代碼]-UCD-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 撰寫者 [BA/SA 姓名] 審核者 [技術主管 / 業務主管] 版本歷程 版本 日期 修改人 修改內容 v1.0 [YYYY-MM-DD] [姓名] 初版發布 2. 系統範圍與參與者 2.1 系統邊界 項目 說明 系統名稱 [系統全名] 系統目的 [一句話描述系統核心價值] 系統範圍 [包含/不包含的功能範疇] 2.2 參與者(Actors)清單 參與者 ID 名稱 類型 說明 相關角色/系統 ACT-001 [名稱] [人/系統/時間] [簡述] [實際角色] ACT-002 [名稱] [人/系統/時間] [簡述] [實際角色] 3. 使用案例圖(Use Case Diagram) graph LR subgraph "System Boundary: [系統名稱]" UC1([UC-001: 使用案例名稱]) UC2([UC-002: 使用案例名稱]) UC3([UC-003: 使用案例名稱]) end Actor1[/Actor 1\] --> UC1 Actor1 --> UC2 Actor2[/Actor 2\] --> UC2 Actor2 --> UC3 UC2 -.->|include| UC1 UC3 -.->|extend| UC2 4. 使用案例清單 UC ID 使用案例名稱 主要參與者 優先級 複雜度 狀態 UC-001 [名稱] [Actor] [High/Medium/Low] [High/Medium/Low] [Draft/Review/Approved] UC-002 [名稱] [Actor] [High/Medium/Low] [High/Medium/Low] [Draft/Review/Approved] 5. 使用案例規格(逐案詳述) UC-[NNN]: [使用案例名稱] 項目 內容 Use Case ID UC-[NNN] 名稱 [使用案例名稱] 簡述 [一句話描述目的] 主要參與者 [Primary Actor] 次要參與者 [Secondary Actors,若無填 N/A] 觸發條件 [什麼事件啟動此使用案例] 前置條件 [執行前必須滿足的條件] 後置條件(成功) [成功完成後系統/資料狀態] 後置條件(失敗) [失敗時系統/資料狀態] 優先級 [High / Medium / Low] 頻率 [每日 N 次 / 每週 N 次] 主要流程(Main Flow): ...

May 18, 2026 · 3 min · 625 words · Eric Cheng

使用者手冊範本(User Manual Template)

使用者手冊範本(User Manual Template) 適用標準:ISO/IEC/IEEE 26514:2022(系統與軟體使用者文件設計) 適用階段:專案管理 — 交付階段 負責角色:Technical Writer、BA、PM 📑 章節目錄 文件資訊 前言 系統概述 快速入門 功能操作說明 系統管理功能 常見問題(FAQ) 錯誤訊息與排除 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 使用者手冊 文件編號 [專案代碼]-UM-[版本號] 版本 v[X.Y] 適用系統版本 [系統版本號] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 作者 [Technical Writer / BA] 審核者 [PM / PO] 版本歷程 版本 日期 修改內容 修改者 v1.0 [日期] 初版 [姓名] v1.1 [日期] [修改說明] [姓名] 2. 前言 2.1 文件目的 本手冊提供 [系統名稱] 的完整操作指引,協助使用者了解系統功能並正確使用各項功能。 ...

May 18, 2026 · 3 min · 602 words · Eric Cheng

回滾計畫範本(Rollback Plan Template)

回滾計畫範本(Rollback Plan) 參照標準:ITIL 4(Release and Deployment Management)/ ISO/IEC 20000-1:2018 文件用途:定義版本上線後若出現嚴重問題時的回復策略與操作步驟 適用階段:部署上線階段(Deployment Phase)— Change Enablement 📋 章節目錄 文件資訊 回滾觸發條件 回滾決策流程 回滾策略 回滾前準備 回滾執行步驟 資料庫回滾 回滾驗證 通知與溝通 回滾後行動 1. 文件資訊 📝 範本 項目 內容 文件編號 RP-{專案代碼}-{版本}-{序號} 文件名稱 {系統名稱} v{x.x.x} 回滾計畫 版本 v{主版本}.{次版本} 對應發佈版本 v{x.x.x} 建立日期 {YYYY-MM-DD} 撰寫者 {DevOps/SRE 姓名} 審核者 {Tech Lead / SM} 回滾時間窗口 上線後 {N} 小時內 最大容許停機 {N} 分鐘 回滾方式 Blue-Green / Canary Rollback / 全量回滾 📖 使用說明 回滾計畫是部署計畫的必要附件,每次上線都需準備 回滾時間窗口:超過此時間,資料可能已累積,回滾成本大幅增加 回滾方式取決於部署架構: Blue-Green:切換流量至舊版(秒級) Canary Rollback:停止灰度,流量回到舊版(秒級) 全量回滾:重新部署舊版 Image(分鐘級) 💡 範例 項目 內容 文件編號 RP-HRM-v2.1.0-001 對應發佈版本 v2.1.0 回滾時間窗口 上線後 4 小時內 最大容許停機 5 分鐘 回滾方式 Blue-Green(K8s Service 切換) 2. 回滾觸發條件 📝 範本 2.1 自動觸發(需設定監控告警) 條件 ID 觸發條件 監控指標 閾值 RT-AUTO-{xxx} {條件描述} {指標} {閾值} 2.2 人工判斷觸發 條件 ID 觸發條件 判斷依據 決策者 RT-MANUAL-{xxx} {條件描述} {判斷依據} {角色} 📖 使用說明 自動觸發:由監控系統偵測到異常時自動發起(或告警後快速決策) 人工判斷:需要人為判斷的複雜情境 觸發條件需事先定義並經團隊共識,避免上線時臨時爭論 💡 範例 2.1 自動觸發 條件 ID 觸發條件 監控指標 閾值 RT-AUTO-001 API 錯誤率飆升 HTTP 5xx Rate > 5% 持續 3 分鐘 RT-AUTO-002 回應時間嚴重惡化 P95 Latency > 5s 持續 5 分鐘 RT-AUTO-003 核心服務健康檢查失敗 Health Check 連續 3 次失敗 RT-AUTO-004 資料庫連線耗盡 DB Connection Pool > 95% 使用率持續 2 分鐘 2.2 人工判斷觸發 條件 ID 觸發條件 判斷依據 決策者 RT-MANUAL-001 核心業務流程異常(薪資計算錯誤) 使用者回報 + 日誌確認 Tech Lead RT-MANUAL-002 資安事件(疑似資料洩露) 資安告警 + SOC 確認 資安主管 RT-MANUAL-003 資料損壞(不一致/遺失) DB 檢查確認 DBA + Tech Lead 3. 回滾決策流程 📝 範本 偵測異常 → 通知值班人員 → 初步評估(5 分鐘內) │ ├── 可快速修復(Hotfix) → 修復並部署 → 持續觀察 │ └── 無法快速修復 → 啟動回滾決策 │ ├── 決策者確認回滾 → 執行回滾 │ └── 暫時降級(Feature Flag) → 持續觀察 決策權限矩陣 情境 決策者 升級時機 {情境} {角色} {超過 N 分鐘未解決時升級} 📖 使用說明 決策流程需在 5-15 分鐘內完成,避免長時間討論 權限矩陣確保深夜/假日也有人可做決策 Feature Flag 降級是比全量回滾更輕量的選項(如果有準備的話) 💡 範例 決策權限矩陣 情境 決策者 升級時機 上班時間(09-18) Tech Lead → PM 10 分鐘未決定 → VP Engineering 下班/假日 值班 SRE → On-call Tech Lead 15 分鐘未回應 → VP Engineering 資安事件 資安主管(不論時段) 立即通知 CTO 4. 回滾策略 📝 範本 4.1 回滾方式比較 方式 停機時間 適用場景 風險 {方式} {時間} {場景} {風險} 4.2 本次採用策略 項目 說明 回滾方式 {Blue-Green / Canary / Rolling / 全量} 回滾目標版本 v{x.x.x} 預計停機時間 {N} 分鐘 資料庫回滾 是/否(需要/不需要) Feature Flag 是/否(可局部降級) 📖 使用說明 選擇回滾策略需考量:停機影響、資料安全、回復速度 Blue-Green 最快(秒級切換)但需雙倍資源 有 DB Schema 變更時回滾最複雜,需額外評估 若有 Feature Flag,優先考慮關閉新功能而非全量回滾 💡 範例 4.1 回滾方式比較 方式 停機時間 適用場景 風險 Blue-Green 切換 < 30s K8s Service selector 切換 新舊版 DB Schema 需相容 Canary 回滾 < 30s 灰度比例回 0% 僅灰度階段可用 K8s Rolling Rollback 2-5 min kubectl rollout undo 過程中有混合版本 全量回滾 + DB Restore 15-30 min DB Schema 不相容時 停機長、可能丟失資料 4.2 本次採用策略 項目 說明 回滾方式 Blue-Green(K8s 保留舊版 Deployment) 回滾目標版本 v2.0.3 預計停機時間 < 1 分鐘 資料庫回滾 否(DB Migration 向後相容) Feature Flag 是(可先關閉 WebSocket 推播功能) 5. 回滾前準備 📝 範本 5.1 準備清單(部署前完成) # 準備事項 負責人 狀態 1 {準備事項} {人員} ☐ 2 {準備事項} {人員} ☐ 5.2 環境快照 項目 備份位置 備份時間 保留期限 {項目} {位置} {時間} {期限} 📖 使用說明 回滾準備必須在部署「前」完成,而非出問題才做 資料庫快照是最重要的準備(資料不可逆) 確認舊版 Image 仍可取得、舊版設定仍可存取 💡 範例 5.1 準備清單 # 準備事項 負責人 狀態 1 資料庫全量備份(pg_dump) DBA ☑ 2 保留舊版 Deployment(hrms-blue, replicas=0) DevOps ☑ 3 確認舊版 Image 可拉取:hrms:v2.0.3 DevOps ☑ 4 備份 Kong 路由設定 DevOps ☑ 5 確認 Feature Flag 可遠端關閉 後端組 ☑ 6 值班人員確認聯絡方式 SM ☑ 5.2 環境快照 項目 備份位置 備份時間 保留期限 PostgreSQL Full Backup Azure Blob / hrm-backup/ 部署前 30 分鐘 7 天 Redis RDB Snapshot Azure Blob / redis-backup/ 部署前 30 分鐘 3 天 Kong Config Export Git repo / infra/kong/ 部署前 commit 永久 K8s Manifest (old) Git repo / k8s/ 部署前 Tag 永久 6. 回滾執行步驟 📝 範本 6.1 執行步驟(依序執行) 步驟 動作 命令/操作 預期結果 執行者 1 {動作} {命令} {預期} {人員} 2 {動作} {命令} {預期} {人員} 6.2 回滾腳本 #!/bin/bash # Rollback Script - {系統名稱} v{x.x.x} → v{x.x.x} # 使用方式:./rollback.sh {腳本內容} 📖 使用說明 步驟需足夠詳細,讓非撰寫者也能執行 回滾腳本需事前測試(在 Staging 環境驗證) 每個步驟標明預期結果,便於判斷是否正確執行 腳本優先於手動操作(減少人為失誤) 💡 範例 6.1 執行步驟 步驟 動作 命令/操作 預期結果 執行者 1 確認決策 Slack 記錄回滾決策 決策者確認 SM 2 關閉新功能 Feature Flag LaunchDarkly: payroll-scheduler=OFF, ws-notification=OFF Flag 生效 後端組 3 切換流量至舊版 kubectl patch svc hrms -p '{"spec":{"selector":{"version":"v2.0.3"}}}' 流量轉到 Blue DevOps 4 Scale up 舊版 kubectl scale deploy hrms-blue --replicas=3 3 Pod Running DevOps 5 驗證舊版健康 curl https://hrms.internal/health HTTP 200 + version=v2.0.3 DevOps 6 Scale down 新版 kubectl scale deploy hrms-green --replicas=0 0 Pod DevOps 7 更新 Kong 路由 移除 /ws 路由 WebSocket 端點移除 DevOps 8 驗證完整功能 執行冒煙測試腳本 All Pass QA 6.2 回滾腳本 #!/bin/bash # Rollback Script - HRMS v2.1.0 → v2.0.3 # 使用方式:./rollback-hrms-v2.1.0.sh set -euo pipefail echo "=== HRMS Rollback: v2.1.0 → v2.0.3 ===" echo "開始時間: $(date -Iseconds)" # Step 1: Scale up old version echo "[1/5] Scaling up v2.0.3 (Blue)..." kubectl scale deploy hrms-blue --replicas=3 -n hrms kubectl rollout status deploy/hrms-blue -n hrms --timeout=120s # Step 2: Switch traffic echo "[2/5] Switching Service to v2.0.3..." kubectl patch svc hrms-api -n hrms \ -p '{"spec":{"selector":{"version":"v2.0.3"}}}' # Step 3: Verify health echo "[3/5] Verifying health..." sleep 5 HEALTH=$(curl -s -o /dev/null -w "%{http_code}" https://hrms.internal/health) if [ "$HEALTH" != "200" ]; then echo "ERROR: Health check failed! Manual intervention required." exit 1 fi # Step 4: Scale down new version echo "[4/5] Scaling down v2.1.0 (Green)..." kubectl scale deploy hrms-green --replicas=0 -n hrms # Step 5: Remove WebSocket route echo "[5/5] Removing WebSocket route from Kong..." curl -s -X DELETE http://kong-admin:8001/routes/hrms-websocket echo "=== Rollback Complete: $(date -Iseconds) ===" echo "請執行冒煙測試驗證: ./smoke-test.sh" 7. 資料庫回滾 📝 範本 7.1 DB Migration 相容性評估 Migration 描述 向後相容 回滾方式 {Migration 名稱} {描述} 是/否 {回滾方式} 7.2 資料庫回滾步驟(若需要) 步驟 動作 命令 風險 1 {動作} {命令} {風險} 📖 使用說明 向後相容的 Migration:新增欄位/表 → 不需回滾(舊版忽略新欄位即可) 不相容的 Migration:刪除/重命名欄位 → 必須回滾 資料庫回滾最危險,可能造成資料遺失,需事先做好備份 原則:盡量設計向後相容的 Migration(Expand-Contract Pattern) 💡 範例 7.1 DB Migration 相容性評估 Migration 描述 向後相容 回滾方式 AddNotificationLogs 新增 notification_logs 表 ✅ 是 不需回滾(舊版不使用此表) AddSchedulerColumns payroll 表新增 3 個 nullable 欄位 ✅ 是 不需回滾(舊版忽略) ✅ 本版所有 Migration 均為向後相容,無需資料庫回滾 ...

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

基礎設施架構設計文件範本(Infrastructure Architecture Document Template)

基礎設施架構設計文件範本(Infrastructure Architecture Document Template) 適用標準:ISO/IEC/IEEE 42010:2022(架構描述)、TOGAF ADM、C4 Model、ISO/IEC 27001:2022(資安) 適用階段:系統設計階段(Design Phase) 負責角色:系統架構師(SA)、基礎設施工程師(Infra Engineer)、雲端架構師 📑 章節目錄 文件資訊 架構設計目標與約束 系統架構總覽 網路架構設計 運算資源配置 儲存與資料庫架構 高可用與災難復原設計 安全架構設計 監控與可觀測性架構 CI/CD 部署架構 容量規劃與擴展策略 環境規劃 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 基礎設施架構設計文件 文件編號 [專案代碼]-IAD-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 最後更新 [YYYY-MM-DD] 撰寫者 [架構師姓名] 審核者 [技術主管] 核准者 [專案經理 / CTO] 版本歷程 版本 日期 修改人 修改內容 v1.0 [YYYY-MM-DD] [姓名] 初版發布 關聯文件 文件名稱 文件編號 關係 系統架構文件(SAD) [編號] 邏輯架構來源 非功能性需求規格 [編號] NFR 輸入 安全需求清單 [編號] 安全設計依據 資料庫設計文件 [編號] 資料層設計 2. 架構設計目標與約束 2.1 設計目標 品質屬性 目標 衡量指標 可用性(Availability) [目標 SLA %] Uptime ≥ [N]% 效能(Performance) [回應時間目標] P95 < [N]ms, TPS ≥ [N] 延展性(Scalability) [擴展能力] 支援 [N] 並發用戶 安全性(Security) [合規要求] 符合 [法規/標準] 可維護性(Maintainability) [維護便利性] MTTR < [N] min 成本效益(Cost) [預算限制] 月費 < [N] USD 2.2 設計約束 約束類型 約束內容 來源 技術約束 [指定雲端平台 / 技術堆疊] [組織政策] 法規約束 [資料落地區域 / 合規要求] [法規名稱] 預算約束 [月度/年度預算上限] [專案預算] 時程約束 [上線日期限制] [專案時程] 組織約束 [現有團隊技能 / 維運能量] [人力限制] 2.3 架構決策記錄(ADR) ADR# 決策標題 狀態 日期 ADR-001 [選用 Kubernetes 作為容器編排平台] Accepted [YYYY-MM-DD] ADR-002 [採用 Multi-AZ 部署策略] Accepted [YYYY-MM-DD] ADR 格式: ...

May 18, 2026 · 10 min · 2030 words · Eric Cheng

威脅模型範本(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 Scan Report Template)

安全測試與弱點掃描報告範本(Security Scan Report Template) 適用標準:OWASP Testing Guide v4.2、CVSS 3.1(Common Vulnerability Scoring System)、CWE 適用階段:測試驗證階段(Testing Phase) 負責角色:AppSec 工程師、資安測試人員、QA Lead 📑 章節目錄 文件資訊 測試摘要 測試範圍與方法 弱點總覽 弱點詳細報告 合規檢核結果 修復計畫 結論與建議 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 安全測試報告 文件編號 [專案代碼]-STR-[版本號]-[日期] 版本 v[X.Y] 測試日期 [YYYY-MM-DD] ~ [YYYY-MM-DD] 測試人員 [AppSec 團隊 / 外部廠商] 審核者 [CISO / 資安主管] 資料分級 Confidential 2. 測試摘要 項目 內容 測試類型 [SAST / DAST / SCA / Penetration Test / 組合] 受測版本 [Application version / Commit hash] 測試結果總評 [✅ PASS / ⚠️ CONDITIONAL PASS / ❌ FAIL] 上線決策 [可上線 / 修復後可上線 / 不可上線] 弱點統計 嚴重度 數量 已修復 待修復 接受風險 Critical [N] [N] [N] [N] High [N] [N] [N] [N] Medium [N] [N] [N] [N] Low [N] [N] [N] [N] Info [N] — — — Total [N] [N] [N] [N] 3. 測試範圍與方法 3.1 測試範圍 項目 內容 目標系統 [系統名稱 + URL/IP] 測試範圍 [In-scope modules / endpoints] 排除範圍 [Out-of-scope,如第三方元件] 認證帳號 [測試用帳號角色清單(不含密碼)] 3.2 測試方法 測試類型 工具 版本 說明 SAST(靜態分析) [SonarQube / Checkmarx / Semgrep] [ver] 原始碼分析 DAST(動態分析) [OWASP ZAP / Burp Suite Pro] [ver] 執行期掃描 SCA(套件分析) [Snyk / OWASP Dependency-Check / Trivy] [ver] 第三方套件弱點 手動測試 [Burp Suite / Custom scripts] — 邏輯弱點 Container Scan [Trivy / Aqua] [ver] 容器映像掃描 3.3 測試依據 標準/指南 涵蓋項目 OWASP Top 10 (2021) A01~A10 OWASP API Security Top 10 (2023) 全部 OWASP ASVS v4.0.3 [Level 1 / Level 2 / Level 3] CWE Top 25 (2023) 常見弱點 4. 弱點總覽 4.1 依嚴重度分佈 嚴重度 CVSS 分數範圍 修復 SLA 數量 Critical 9.0 – 10.0 24 小時 [N] High 7.0 – 8.9 7 天 [N] Medium 4.0 – 6.9 30 天 [N] Low 0.1 – 3.9 90 天 [N] Info 0.0 視需要 [N] 4.2 依類型分佈 弱點類型(CWE) 數量 嚴重度分佈 [CWE-XXX: 弱點名稱] [N] [C:N / H:N / M:N / L:N] [CWE-XXX: 弱點名稱] [N] [C:N / H:N / M:N / L:N] 4.3 依 OWASP Top 10 分佈 OWASP Category 弱點數量 最高嚴重度 A01: Broken Access Control [N] [Critical/High/…] A02: Cryptographic Failures [N] A03: Injection [N] A04: Insecure Design [N] A05: Security Misconfiguration [N] A06: Vulnerable Components [N] A07: Auth Failures [N] A08: Software & Data Integrity [N] A09: Logging & Monitoring Failures [N] A10: SSRF [N] 5. 弱點詳細報告 VULN-[NNN]: [弱點標題] 項目 內容 弱點 ID VULN-[NNN] 嚴重度 [Critical / High / Medium / Low] CVSS 分數 [N.N] CVSS Vector [CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] CWE CWE-[NNN]: [名稱] OWASP [A01 / A02 / …] 發現工具 [SAST / DAST / Manual] 受影響元件 [模組/檔案/API endpoint] 狀態 [Open / Fixed / Accepted / False Positive] 描述: ...

May 18, 2026 · 4 min · 770 words · Eric Cheng

安全設計文件範本(Security Design Document Template)

安全設計文件範本(Security Design Document Template) 適用標準:OWASP SAMM 2.0、ISO/IEC 27034(應用安全)、NIST SP 800-53、ISO/IEC 27001:2022 適用階段:系統設計階段(Design Phase) 負責角色:資安架構師、系統架構師(SA)、AppSec 工程師 📑 章節目錄 文件資訊 安全設計目標 身分驗證設計(Authentication) 授權與存取控制(Authorization) 資料保護設計 API 安全設計 Session 管理 輸入驗證與輸出編碼 日誌與稽核設計 安全組態基線 安全測試策略 📝 範本 1. 文件資訊 項目 內容 文件名稱 [系統名稱] 安全設計文件 文件編號 [專案代碼]-SDD-[版本號] 版本 v[X.Y] 建立日期 [YYYY-MM-DD] 撰寫者 [資安架構師] 審核者 [CISO / 資安團隊] 資料分級 [Confidential / Internal] 關聯文件 文件 關係 威脅模型(Threat Model) 風險識別來源 安全需求清單 需求依據 系統架構文件(SAD) 架構背景 2. 安全設計目標 2.1 安全原則 原則 說明 實施方式 Defense in Depth 多層防禦 [每層防護機制] Least Privilege 最小權限 [RBAC + 預設拒絕] Fail Secure 安全失敗 [錯誤處理不暴露資訊] Separation of Duties 職責分離 [設計/部署/維運分離] Zero Trust 零信任 [每次存取都驗證] 2.2 合規需求 法規/標準 適用條款 設計對應 [個資法 / GDPR] [條款] [§5 資料保護] [ISO 27001] [A.8 / A.9] [§3, §4] [OWASP Top 10] [全部] [§6, §8] [PCI DSS] [條款,如適用] [§5] 3. 身分驗證設計(Authentication) 3.1 驗證機制 項目 設計 驗證協定 [OAuth 2.0 + OIDC / SAML 2.0 / Custom] IdP 選擇 [Azure AD / Keycloak / Auth0 / 自建] MFA 策略 [強制 / 條件式 / 僅特權帳號] MFA 方式 [TOTP / SMS / Push / FIDO2] 密碼政策 [長度/複雜度/歷史/鎖定策略] 3.2 密碼儲存 項目 設計 Hash 演算法 [bcrypt / Argon2id / PBKDF2] Cost Factor [rounds / iterations] Salt [Per-user random salt] 3.3 Token 設計 Token 類型 格式 有效期 儲存位置 備註 Access Token [JWT / Opaque] [N min] [Memory / HttpOnly Cookie] Refresh Token [Opaque] [N days] [HttpOnly Secure Cookie] 單次使用 ID Token [JWT] [N min] [Memory] 不傳給後端 API 3.4 驗證流程圖 sequenceDiagram participant U as User participant C as Client App participant IDP as Identity Provider participant API as API Server U->>C: 點擊登入 C->>IDP: Authorization Request (PKCE) IDP->>U: 顯示登入頁面 U->>IDP: 輸入帳號/密碼 + MFA IDP->>C: Authorization Code C->>IDP: Token Exchange (code + code_verifier) IDP->>C: Access Token + Refresh Token + ID Token C->>API: API Request + Access Token (Bearer) API->>API: Validate Token (signature + claims) API->>C: Response 4. 授權與存取控制(Authorization) 4.1 存取控制模型 項目 設計 模型 [RBAC / ABAC / ReBAC / 混合] 角色層級 [平面 / 階層式] 權限粒度 [功能級 / 資料級 / 欄位級] 4.2 角色定義 角色 ID 角色名稱 說明 預設權限 [ROLE_ID] [名稱] [角色描述] [權限摘要] 4.3 權限矩陣 功能/資源 [角色A] [角色B] [角色C] [Admin] [功能1] R CRUD R CRUD [功能2] — R CRUD CRUD [功能3] RU (own) RU (dept) CRUD CRUD 4.4 資料級權限 規則 描述 實施方式 Row-Level Security [使用者只能看自己的資料] [DB RLS / Application Filter] Column-Level Security [敏感欄位依角色遮罩] [View / API 過濾] 部門隔離 [只能存取所屬部門資料] [tenant_id / dept_id filter] 5. 資料保護設計 5.1 加密策略 場景 方法 演算法 金鑰管理 傳輸中(In Transit) TLS [TLS 1.3 / 1.2] [憑證管理方式] 靜態儲存(At Rest) [TDE / Application-level] [AES-256-GCM] [KMS / Vault] 欄位加密 Application-level [AES-256-GCM] [KMS / Vault] 備份加密 File-level [AES-256] [KMS] 5.2 金鑰管理 項目 設計 KMS 工具 [AWS KMS / Azure Key Vault / HashiCorp Vault] 金鑰輪換 [每 N 天自動輪換] 金鑰存取控制 [IAM Policy / RBAC] 金鑰備份 [異地備份策略] 5.3 個資處理 個資欄位 蒐集目的 保留期限 匿名化方式 刪除策略 [欄位] [用途] [N 年] [Masking / Hashing / Tokenization] [Hard delete / Crypto-shred] 6. API 安全設計 6.1 API 認證授權 項目 設計 認證方式 [Bearer Token (JWT) / API Key / mTLS] 授權檢查點 [API Gateway / Application / Both] Scope/Permission [resource:action 格式] 6.2 API 防護 防護措施 設計 工具 Rate Limiting [N requests / minute per user] [API Gateway / Redis] Request Size Limit [N MB] [Nginx / Gateway] IP Whitelist(如適用) [特定 API 限制來源 IP] [WAF / NSG] CORS [Allowed origins 清單] [Application config] API Versioning [URL path / Header] [設計規範] 6.3 OWASP API Security Top 10 對策 風險 對策 Broken Object Level Authorization [每次存取驗證資源所有權] Broken Authentication [Token 正確驗證 + MFA] Broken Object Property Level Authorization [回應過濾敏感欄位] Unrestricted Resource Consumption [Rate limit + pagination] Broken Function Level Authorization [角色權限矩陣嚴格檢查] Server Side Request Forgery [禁止 URL 參數直接存取內部資源] Security Misconfiguration [安全組態基線檢核] Lack of Protection from Automated Threats [Bot detection + CAPTCHA] 7. Session 管理 項目 設計 Session 機制 [Stateless (JWT) / Stateful (Server-side)] Session 有效期 [Idle: N min / Absolute: N hr] Session 儲存 [Redis / Database / Memory] Cookie 設定 HttpOnly, Secure, SameSite=Strict, Path=/ 並行 Session [允許 N 個裝置 / 新登入踢出舊 Session] Session Fixation 防護 [登入後重新產生 Session ID] 登出機制 [清除 Token + Server-side invalidation] 8. 輸入驗證與輸出編碼 8.1 輸入驗證策略 驗證層 位置 方式 Client-side 前端 UI 即時驗證(UX 用途,非安全邊界) Server-side API Controller 必須:Whitelist 驗證 + Schema validation Database DB Layer 型別約束 + Check constraints 8.2 常見攻擊防護 攻擊類型 防護措施 SQL Injection Parameterized queries / ORM XSS Output encoding (context-aware) + CSP CSRF SameSite cookie + CSRF token (if needed) Path Traversal 白名單驗證路徑,禁止 ../ XXE 停用 external entity parsing Deserialization 不接受不信任的序列化資料 8.3 Content Security Policy Content-Security-Policy: default-src 'self'; script-src 'self' [trusted CDN]; style-src 'self' 'unsafe-inline'; img-src 'self' data: [image CDN]; connect-src 'self' [API domain]; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; 9. 日誌與稽核設計 9.1 安全事件日誌 事件類型 記錄內容 儲存位置 保留期 登入成功/失敗 UserID, IP, Timestamp, UserAgent [SIEM / Log store] [N 年] 權限變更 Who, What, When, Previous/New value [Audit DB] [N 年] 資料存取 UserID, Resource, Action, Timestamp [Audit DB] [N 年] 敏感操作 [詳細描述] [Audit DB] [N 年] 9.2 日誌安全 項目 設計 日誌不得包含 密碼、Token、PII 明碼、信用卡號 日誌完整性 [HMAC / Append-only storage] 日誌存取控制 [僅 Security Team + Auditor 可存取] 竄改偵測 [Hash chain / WORM storage] 10. 安全組態基線 10.1 HTTP Security Headers Header 值 說明 Strict-Transport-Security max-age=31536000; includeSubDomains HSTS X-Content-Type-Options nosniff 防 MIME 嗅探 X-Frame-Options DENY 防 Clickjacking X-XSS-Protection 0 由 CSP 取代 Referrer-Policy strict-origin-when-cross-origin Permissions-Policy camera=(), microphone=() 限制瀏覽器功能 10.2 TLS 組態 項目 設計 最低版本 TLS 1.2(建議 TLS 1.3) 允許 Cipher Suites [列出安全的 cipher suites] 憑證類型 [RSA 2048+ / ECDSA P-256+] HSTS Preload [是/否] 11. 安全測試策略 測試類型 工具 頻率 負責人 SAST [SonarQube / Checkmarx / Semgrep] 每次 CI build Dev Team DAST [OWASP ZAP / Burp Suite] 每個 Sprint AppSec SCA [Snyk / Dependabot / OWASP Dep-Check] 每次 CI build Dev Team Penetration Test [外部廠商] [每年/每版本] AppSec Security Review Code Review + Design Review 每個 PR + 每階段 AppSec + Dev 📖 使用說明 各章節填寫指引 章節 填寫時機 負責人 重點說明 §2 安全目標 專案啟動時 資安 對齊合規需求 §3 身分驗證 設計初期 SA/資安 從威脅模型導出需求 §4 授權控制 配合功能設計 SA 權限矩陣需業務確認 §5 資料保護 設計階段 SA/DBA/資安 PII 處理需法務確認 §6 API 安全 API 設計時 SA/FE/BE 配合 API Spec §7-8 Session/驗證 詳細設計 BE 遵循 OWASP 建議 §9 稽核 設計階段 SA/資安 法規保留需求 §10 組態基線 部署前 DevOps/資安 定期掃描驗證 §11 測試策略 開發啟動前 資安/QA 整合至 CI/CD 💡 範例(以 HRMS 人力資源管理系統為例) 範例:角色與權限矩陣 功能 員工 主管 HR 系統管理員 查看個人資料 R (own) R (dept) R (all) R (all) 編輯個人資料 U (partial) — U (all) U (all) 申請請假 CRU (own) CRU (own) CRUD (all) CRUD (all) 審核請假 — U (dept) U (all) U (all) 查看薪資 R (own) — R (all) R (all) 管理員工 — — CRUD CRUD 系統設定 — — — CRUD 範例:API 安全設計 API Endpoint 認證 授權 Rate Limit 備註 POST /auth/login Public — 5/min per IP 防暴力破解 GET /api/employees/{id} Bearer JWT own or dept_manager or HR 100/min Row-level check POST /api/leave-requests Bearer JWT Employee role 10/min PUT /api/leave-requests/{id}/approve Bearer JWT Manager of requestor 30/min 層級驗證 GET /api/salary/{id} Bearer JWT own or HR 20/min 敏感資料加密回傳 DELETE /api/employees/{id} Bearer JWT Admin only 5/min Soft delete + 稽核 範例:稽核日誌設計 { "timestamp": "2026-04-10T08:30:15.123Z", "event_type": "DATA_ACCESS", "user_id": "EMP-001", "user_role": "HR", "action": "VIEW", "resource": "employee.salary", "resource_id": "EMP-042", "source_ip": "10.0.10.45", "user_agent": "Mozilla/5.0...", "result": "SUCCESS", "metadata": { "fields_accessed": ["base_salary", "bonus"], "reason": "Monthly payroll processing" } } 📌 審閱重點 ...

May 18, 2026 · 6 min · 1157 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

專案回顧報告範本(Retrospective Report Template)

專案回顧報告範本(Retrospective Report Template) 適用標準:Agile Retrospectives(Esther Derby & Diana Larsen)、SRE Postmortem Culture 適用階段:專案管理 — 任何迭代/里程碑/專案結束時 負責角色:Scrum Master / PM、全體團隊成員 📑 章節目錄 文件資訊 回顧概要 量化回顧(Metrics) 質性回顧(What Went Well / What Didn’t) 根因分析 改善行動項目 前次行動追蹤 團隊健康度 附錄 📝 範本 1. 文件資訊 項目 內容 文件名稱 [專案/Sprint 名稱] 回顧報告 文件編號 [專案代碼]-RETRO-[Sprint#/版本]-[日期] 版本 v[X.Y] 回顧日期 [YYYY-MM-DD] 迭代/里程碑 [Sprint N / Release X.Y / Phase Name] 引導者(Facilitator) [Scrum Master / PM] 參與者 [全體團隊成員名單] 2. 回顧概要 項目 內容 回顧範圍 [Sprint / Release / 專案整體] 迭代期間 [YYYY-MM-DD] ~ [YYYY-MM-DD] 主要交付 [本次迭代完成的主要功能/里程碑] 整體滿意度 [1-5 分,團隊平均] 一句話總結 [本次迭代最重要的一件事] 3. 量化回顧(Metrics) 3.1 交付指標 指標 計畫 實際 達成率 趨勢 Story Points (committed) [N] [N] (completed) [N]% [↑/↓/→] User Stories (完成/承諾) [N]/[M] [N/M] [N]% Bug 數量(新增/修復) —/— [N]/[M] — 技術債處理 [N] items [N] items [N]% 3.2 品質指標 指標 本次 前次 目標 趨勢 Escaped Bugs (上線後發現) [N] [N] 0 [↑/↓/→] Code Coverage [N]% [N]% ≥ [N]% Code Review 回饋速度 (avg) [N] hr [N] hr < [N] hr Build 成功率 [N]% [N]% ≥ 95% 3.3 流程指標 指標 本次 前次 目標 趨勢 Cycle Time (avg) [N] days [N] days < [N] days Lead Time (avg) [N] days [N] days < [N] days WIP 超標次數 [N] [N] 0 阻塞事項數 [N] [N] 儘量少 會議時間佔比 [N]% [N]% < 20% 4. 質性回顧 4.1 做得好的事(What Went Well / Keep) # 項目 影響 建議 1 [正面事項] [對團隊/產品的正面影響] [持續/強化] 2 [正面事項] [影響描述] [持續/推廣] 3 [正面事項] [影響描述] [持續] 4.2 需要改善的事(What Didn’t Go Well / Problems) # 項目 影響 嚴重度 備註 1 [問題描述] [對團隊/產品的負面影響] [High/Med/Low] 2 [問題描述] [影響描述] [High/Med/Low] 3 [問題描述] [影響描述] [High/Med/Low] 4.3 想要嘗試的事(Ideas / Try) # 想法 預期效果 成本/風險 決議 1 [新做法/工具/流程] [預期改善] [Low/Med/High] [採納/暫緩/拒絕] 2 [新做法] [預期改善] [Low/Med/High] [決議] 5. 根因分析 針對本次最重要的 1~2 個問題進行深入分析 ...

May 18, 2026 · 4 min · 657 words · Eric Cheng