[研究]SSDLC 那些工作應該由不同人擔任？為什麼？

[研究]SSDLC 那些工作應該由不同人擔任？為什麼？

2025-10-21

SSDLC 那些工作應該由不同人擔任？為什麼？

ChatGPT

非常好的一題。這正是 SSDLC（Secure Software Development Life Cycle，安全軟體開發生命週期） 中「職務分離原則（Separation of Duties）」的重要應用。

下面我幫你整理出各階段常見角色分工、以及為什麼應該分開由不同人擔任的理由。

🔐 一、SSDLC 各階段與主要角色

SSDLC階段	主要工作	角色（應不同人）	為什麼要分開
1. 需求分析	定義業務需求、功能需求、安全需求	需求分析師 / 系統分析師	負責定義業務與安全需求的人，不應同時負責設計或開發，避免為了方便開發而弱化安全需求。
2. 系統設計	架構設計、資料流程、安全控制設計	系統架構師 / 安全設計師	設計者不能同時是需求提出者或開發者，以確保設計有被第三方審視、避免盲點。
3. 開發實作	撰寫程式、實作安全控制	開發工程師	實作人員不應同時負責測試或上線，以免在測試階段「放水」或跳過弱點修正。
4. 測試與驗證	功能測試、安全測試、程式碼稽核	測試工程師 / 安全稽核員	測試人員必須獨立於開發人員，確保測試結果客觀、公正。開發者不能自己審自己的程式。
5. 部署與維運	系統上線、帳號權限設定、監控	系統管理員 / DevOps / SecOps	維運人員不應有修改原始程式的權限，以防止惡意或誤操作造成安全風險。
6. 監控與應變	弱點管理、日誌監控、事件處理	資安監控人員 / Incident Response Team	負責偵測異常的人不應同時是系統維運者，以避免利益衝突與隱匿問題。

⚖️ 二、核心原則：職務分離 (Separation of Duties)

目的：避免「單一人員能夠獨立完成並通過所有安全關卡」，導致錯誤、舞弊或惡意行為無法被發現。

典型分離範例：

功能	不應由同一人負責	理由
開發 vs 測試	開發者不測自己寫的程式	測試偏差或漏測風險高
測試 vs 上線	測試人員不負責上線	避免跳過正式部署程序
開發 vs 生產環境維運	開發者無生產環境寫入權限	防止直接修改、繞過審核
稽核 vs 維運	稽核人員不能修改系統設定	保持稽核獨立性
需求 vs 設計	需求方不直接決定安全設計	避免功能導向壓倒安全考量

🧩 三、常見的安全失誤（未分職導致）

狀況	結果
開發者同時上線	跳過安全檢查，部署未驗證版本
測試者修改程式碼	測試偏向通過而非找問題
維運可改程式	系統被植入惡意程式或竄改紀錄
無獨立稽核	弱點永遠不會被揭露

✅ 四、實務建議

1.建立角色與權限矩陣 (RACI Matrix)

• 明確界定每個階段的責任、執行、審核、知情角色。

2.自動化流程（CI/CD + 安全閘口）

• 自動化部署時加入安全掃描與審核節點，減少人為干擾。

3.最小權限原則 (Least Privilege)

• 各角色僅擁有完成職責所需的最少權限。

(完)