[研究]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)
- 各角色僅擁有完成職責所需的最少權限。
(完)
沒有留言:
張貼留言