保護部署流水線#

本章探討如何保護部署流水線，以及如何在我們的控制環境中達成安全與合規目標，包括變更管理（Change Management）和職責分離（Separation of Duty）。

將安全與合規整合到變更審批流程中#

幾乎所有具一定規模的 IT 組織都有既有的變更管理流程，這些流程是降低營運和安全風險的主要控制手段。合規經理和安全經理依賴變更管理流程來滿足合規要求，通常需要所有變更都經過適當授權的證據。

如果我們正確建構了部署流水線，大多數部署都是低風險的，不需要經過人工變更審批流程，因為我們已將控制建立在自動化測試和主動的生產監控之上。

ITIL 將變更分為三類：

• 標準變更（Standard changes）：低風險變更，遵循已建立和核准的流程，可以預先審批。包括應用程式稅率表更新、網站內容和樣式變更等。變更提議者無需在部署前獲得批准，變更部署可以完全自動化，但應記錄以確保可追溯性
• 一般變更（Normal changes）：較高風險的變更，需要變更授權單位（如 CAB）的審查或批准。CAB 通常會有定義明確的 RFC（Request for Change）表單，包含預期的商業成果、計畫的效用與保證、風險與替代方案的商業案例，以及建議的時程
• 緊急變更（Urgent changes）：緊急且高風險的變更，必須立即投入生產（如緊急安全修補、恢復服務）。通常需要高階管理層批准，但允許事後補件

DevOps 實踐的一個關鍵目標是簡化一般變更流程，使其也適用於緊急變更，從而減少需要特殊處理的情境。

將低風險變更重新分類為標準變更#

理想情況下，透過建立可靠的部署流水線，我們已經為快速、可靠且平穩的部署贏得了聲譽。此時應該：

• 尋求 Operations 和相關變更授權單位的同意，證明我們的變更已被證實為低風險，可以定義為標準變更
• 展示一段重要時期內（如數月或數季）的變更歷史，以及同期間的生產問題清單
• 如果能展示高變更成功率和低 MTTR，就能證明我們有一個有效防止部署錯誤並能快速偵測和修正問題的控制環境

即使變更被歸類為標準變更，仍需在變更管理系統中記錄（如 Remedy、ServiceNow）。理想情況下，部署由組態管理和部署流水線工具（如 Puppet、Chef、Jenkins）自動執行，結果自動記錄。

我們可以自動將變更請求記錄連結到工作規劃工具中的項目（如 JIRA、Rally），連結到功能缺陷、生產事件或使用者故事，提供更多變更背景。

建立可追溯性和背景應該簡單且不會對工程師造成過度負擔。連結到使用者故事、需求或缺陷已經足夠 – 過多的細節（如為每次版控提交開一張工單）可能沒有用處且會造成顯著的摩擦。

當變更被歸類為一般變更時該怎麼做#

對於無法被歸類為標準變更的變更，將被視為一般變更，需要 CAB 的部分成員批准。我們的目標仍然是確保能快速部署：

• 確保提交的變更請求（RFC）盡可能完整和準確
• 可以幾乎完全自動化 RFC 的建立，例如自動建立 ServiceNow 變更工單，附上 JIRA 使用者故事連結、建置清單和部署流水線工具的連結
• 描述變更的背景：為什麼要做這個變更、受影響的人、將要變更的內容
• 分享給予我們信心的證據和構件，證明變更將按設計運作
• 持續展示成功變更的優良記錄，最終獲得變更授權單位的同意，將自動化變更歸類為標準變更

案例研究：Salesforce.com 的自動化基礎設施變更（2012）#

Salesforce 成立於 2000 年，到 2007 年已有超過 59,000 家企業客戶。然而他們的發布能力嚴重退化 – 2006 年有四次主要客戶發布，到 2007 年只能做一次。

透過實施 DevOps 原則和實踐，到 2013 年部署前置時間從六天縮短到五分鐘，能處理每天超過十億筆交易。

Salesforce 轉型的主要成果：

• 品質工程成為每個人的工作，無論是 Development、Operations 還是 Infosec
• 將自動化測試整合到應用程式和環境建立的所有階段，以及 CI/CD 流程中
• 開始常態性地執行破壞性測試（destructive testing），在持續增加的負載下測試服務直到崩潰，以了解故障模式
• 資訊安全從專案最早期就與品質工程合作

關鍵成果是被變更管理群組告知：「透過 Puppet 進行的基礎設施變更將被視為標準變更」，大幅減少甚至無需 CAB 的額外批准。

降低對職責分離的依賴#

數十年來，職責分離（Separation of Duty）一直是軟體開發流程中降低詐欺或錯誤風險的主要控制手段。傳統做法要求開發者的變更必須提交給程式碼管理員審查和批准，再由 IT Operations 推送到生產環境。

然而，職責分離經常會：

• 減緩工程師收到工作回饋的速度
• 阻止工程師對其工作品質承擔完全責任
• 降低組織建立組織學習的能力

我們應盡可能避免使用職責分離作為控制手段。相反，應選擇結對程式設計（pair programming）、持續的程式碼檢入檢查（continuous inspection of code check-ins）和程式碼審查（code review）等控制方式。這些控制能提供工作品質的必要保證，同時不會犧牲流動性和回饋速度。

案例研究：Etsy 的 PCI 合規與職責分離的警示（2014）#

Etsy 的支付應用程式 ICHT（“I Can Haz Tokens”）因處理持卡人資料而受 PCI DSS 規範。團隊為了滿足合規要求：

• 將 ICHT 應用程式在實體和邏輯上與 Etsy 其他組織完全隔離
• 由獨立的跨功能團隊（開發者、DBA、網路工程師、維運工程師）管理
• 每位團隊成員配備兩台筆電 – 一台用於 ICHT（不使用時鎖在保險箱中），一台用於 Etsy 其他工作
• 指定變更批准者負責部署所有生產變更

結果雖然通過了 PCI DSS 合規，卻產生了嚴重的副作用：

• 團隊內部出現了**區隔化（compartmentalization）**問題
• 實施職責分離後，沒有人能成為全端工程師
• 部署和維護充滿了恐懼和不情願
• 在 Dev 和 Ops 之間形成了一堵不可穿透的牆

這個案例研究說明，即使是擁有共同經驗和高信任度的高績效 DevOps 團隊，當引入低信任的控制機制時，也可能開始陷入困境。合規是可能的，但需要謹慎設計控制方式，避免破壞 DevOps 的核心文化。

為稽核人員和合規官員確保文件與證據#

隨著越來越多組織採用 DevOps 模式，IT 與稽核之間的緊張關係也在加劇。DevOps 的新模式挑戰了傳統的稽核、控制和風險緩解思維。

Bill Shinn（AWS 首席安全解決方案架構師）指出幾個關鍵挑戰：

• 稽核人員受過的訓練方法不太適合 DevOps 工作模式 – 例如當基礎設施即程式碼、自動擴展讓伺服器隨時出現和消失時，傳統的抽樣方法不再適用
• 需要替代方法來呈現資料，清楚地向稽核人員展示我們的控制正在運作且有效
• 應將所有資料發送到遙測系統（如 Splunk 或 Kibana），讓稽核人員能自助式地搜尋所需的稽核證據

案例研究：在受監管環境中證明合規（2015）#

Shinn 的做法：

• 與稽核人員在控制設計過程中合作，採用迭代方式，每個 sprint 分配一個控制項
• 將法規要求轉化為工程需求，例如將 HIPAA 的「技術保障措施和稽核控制」需求轉化為可實作的控制
• 使用 AWS CloudWatch 實作控制，並能以一個命令列驗證控制是否運作
• 將所有日誌推送到日誌框架中，將稽核證據與實際控制要求連結

DevOps Audit Defense Toolkit 描述了合規和稽核流程的端到端敘事，從組織目標、商業流程、頂級風險到控制環境，展示管理層如何成功證明控制存在且有效。

案例研究：ATM 系統的生產遙測#

一家大型美國金融服務機構的 DevOps 負責人觀察到，資訊安全、稽核人員和監管者往往過度依賴程式碼審查來偵測詐欺。然而，當一名開發者在 ATM 程式碼中植入後門時，詐欺並不是透過程式碼審查發現的，而是在例行的營運檢討會議上被偵測到 – 有人注意到某城市的 ATM 在非預定時間進入維護模式。

這個案例說明了：詐欺可能在有職責分離和變更審批流程的情況下仍然發生，但能透過有效的生產遙測被快速偵測和糾正。生產監控控制應該與程式碼審查和審批一起使用，而不是僅依賴後者。

結論#

本章討論了讓資訊安全成為每個人日常工作的實踐方法。將所有資訊安全目標整合到價值流中每個人的日常工作中，能顯著提升控制的有效性，更好地預防安全事件、更快地偵測和恢復，並大幅減少準備和通過合規稽核所需的工作量。