資訊安全是每個人每天的工作#

「資訊安全與合規性不允許我們這麼做」是實施 DevOps 最常見的反對意見之一。然而，DevOps 可能是將資訊安全整合到技術價值流中每個人日常工作的最佳方式。

Infosec 作為孤島的問題#

當 Infosec 被組織為獨立於 Development 與 Operations 之外的孤島時，會產生許多問題。James Wickett 觀察到：

• 在典型的技術組織中，Development、Operations 與 Infosec 的工程師比例是 100:10:1
• 當 Infosec 人數嚴重不足時，若不依靠自動化並將資訊安全整合到 Dev 和 Ops 的日常工作中，Infosec 只能做合規性檢查（compliance checking），這與安全工程（security engineering）恰恰相反
• 這種做法不僅效果差，還會讓所有人都討厭 Infosec

James Wickett 與 Josh Corman 提倡將安全目標融入 DevOps 的實踐，稱為 Rugged DevOps。Capital One 團隊則將其稱為 DevOpsSec，將 Infosec 整合到 SDLC 的所有階段。

將安全整合到開發迭代展示中#

讓功能團隊盡早與 Infosec 互動的方法之一，是在每個開發迭代結束時邀請 Infosec 參加產品展示（demo）：

• Infosec 可以在組織目標的背景下理解團隊的目標
• 觀察實作過程中的安全考量
• 在專案最早期階段提供指導與回饋，此時修正成本最低

Justin Arbuckle（前 GE Capital 首席架構師）觀察到：「在資訊安全與合規性方面，我們發現專案末期的阻塞比初期昂貴得多。Compliance by demonstration 成為我們用來將所有複雜性提前到流程早期的儀式之一。」

讓 Infosec 成為團隊的一部分，即使只是被通知和觀察，也能讓他們獲得做出更好風險決策所需的商業背景。

將安全整合到缺陷追蹤與事後檢討中#

• 在 Dev 和 Ops 使用的同一個工作追蹤系統中追蹤所有安全問題，確保工作可見且能與其他工作一起排定優先順序
• 這與傳統做法大不相同 – 傳統上所有安全漏洞都存放在只有 Infosec 才能存取的 GRC 工具中

Nick Galbreath（Etsy 資訊安全負責人）的做法：

• 將所有安全問題放入 JIRA 中，分為 P1 或 P2，必須立即或在一週內修復
• 每次發生安全問題都會進行事後檢討（post-mortem），以教育工程師並轉移安全知識

將預防性安全控制整合到共享原始碼儲存庫中#

在共享原始碼儲存庫中加入確保應用程式和環境安全的機制與工具：

• 添加經過安全團隊認證的預建函式庫（如認證、加密函式庫）
• 與共享服務組織合作建立共享的安全相關平台（認證、授權、日誌記錄、稽核）
• 提供安全特定的設定配置（日誌記錄、認證、加密）

可包含的項目：

• 程式碼函式庫及其推薦配置（如 2FA 認證、bcrypt 密碼雜湊）
• 密鑰管理工具（如 Vault、sneaker、Keywhiz、credstash）
• OS 套件與建置（如安全版本的 OpenSSL、OSSEC、Tripwire）

將安全整合到部署流水線中#

過去的做法是在開發完成後才進行安全審查，產出的數百頁漏洞報告往往因為專案時程壓力而被完全忽略。現在我們要自動化盡可能多的資訊安全測試，讓它們與其他自動化測試一起在部署流水線中執行。

目標是讓 Dev 和 Ops 在提交可能不安全的變更時能得到最快的回饋，使他們能在日常工作中快速發現並修復安全問題。

確保應用程式的安全#

開發測試通常聚焦在正確性上（happy path），而有效的 QA、Infosec 和反詐欺從業者則關注sad path 和 bad path – 事情出錯時會發生什麼，特別是與安全相關的錯誤條件。

作為自動化測試的一部分，我們需要涵蓋：

• 靜態分析（Static analysis）：在非執行環境中檢查程式碼，尋找編碼缺陷、後門和潛在惡意程式碼。工具包括 Brakeman、Code Climate 等
• 動態分析（Dynamic analysis）：在程式執行中進行測試，監控系統記憶體、功能行為、回應時間等。工具包括 Arachni、OWASP ZAP 等
• 相依性掃描（Dependency scanning）：清點所有二進位檔和可執行檔的相依性，確保不含已知漏洞。工具包括 Gemnasium、OWASP Dependency-Check 等
• 原始碼完整性與程式碼簽名：所有版本控制的提交都應簽名，CI 流程產生的所有套件都應簽名並記錄雜湊值

OWASP 提供了大量實用的安全指導，例如 Cheat Sheet 系列，涵蓋密碼儲存、遺忘密碼處理、日誌記錄和防止 XSS 漏洞等主題。

案例研究：Twitter 的靜態安全測試（2009）#

Twitter 在 2009 年初遭遇兩次嚴重的安全事件（@BarackObama 帳號被入侵、管理員帳號遭暴力破解攻擊），導致 FTC 發出同意令。Infosec 團隊識別出幾個關鍵原則：

• 防止安全錯誤重複發生：修改工作系統和自動化工具來預防問題再次發生
• 將安全目標整合到現有開發者工具中：不能產生大型 PDF 報告寄給開發者，而是直接提供漏洞資訊給需要修復的開發者
• 維護開發團隊的信任：必須知道何時發送了誤報，以修正錯誤並避免浪費開發時間
• 透過自動化維持 Infosec 的快速流動
• 盡可能讓安全相關工作自助服務化
• 採取全面性方法：從原始碼、生產環境到客戶所見的各個角度進行分析

Twitter 的重大突破發生在一次全公司 hack week 期間，團隊將靜態程式碼分析（Brakeman）整合到 Twitter 的建置流程中。透過為開發者在撰寫不安全程式碼時提供快速回饋，Brakeman 將發現的漏洞率降低了 60%。

確保軟體供應鏈的安全#

Josh Corman 指出：「我們不再撰寫客製化軟體，而是從開源零件組裝所需的東西。」使用元件或函式庫時，我們不僅繼承了它們的功能，也繼承了它們的安全漏洞。

關鍵數據：

• Verizon PCI 資料外洩調查報告發現，10 個漏洞（CVE）佔了 2014 年研究案例中近 97% 的攻擊，其中 8 個漏洞已超過 10 年
• 典型組織依賴 7,601 個建置構件，使用 18,614 個不同版本
• 其中 7.5% 含有已知漏洞，超過 66% 的漏洞已存在兩年以上未修復

確保環境的安全#

確保環境處於強化的、降低風險的狀態：

• 透過自動化測試確認所有適當的設定已正確應用（設定強化、資料庫安全設定、金鑰長度等）
• 使用 Nmap、Metasploit 等工具掃描環境中的已知漏洞
• 將工具輸出放入構件儲存庫並與前一版本比較

案例研究：18F 為聯邦政府自動化合規#

18F 團隊建立了 Cloud.gov 平台即服務，運行在 AWS GovCloud 上。透過在基礎設施和平台層級處理大部分合規控制，大幅減少了獲得 Authority to Operate (ATO) 所需的時間。他們還開發了 compliance masonry 工具，將系統安全計畫資料以機器可讀的 YAML 格式儲存，自動轉換為文件。

將資訊安全整合到生產遙測中#

許多組織在安全事件發生後數月甚至數季才偵測到入侵，通常是由外部人員發現的。我們需要將安全遙測整合到 Dev、QA 和 Ops 使用的相同工具中。

應用程式層級的安全遙測包括：

• 成功與失敗的使用者登入
• 使用者密碼重設
• 使用者電子郵件地址重設
• 使用者信用卡變更

環境層級的安全遙測包括：

• OS 變更（如生產環境、建置基礎設施）
• 安全群組變更
• 設定變更（如 OSSEC、Puppet、Chef、Tripwire）
• 雲端基礎設施變更（如 VPC、安全群組、使用者與權限）
• XSS 嘗試、SQLi 嘗試
• Web 伺服器錯誤（如 4XX 和 5XX）

案例研究：Etsy 的環境監測（2010）#

Nick Galbreath 在 Etsy 並未建立獨立的詐欺控制或資訊安全部門，而是將這些責任嵌入整個 DevOps 價值流中。他建立的安全遙測與 Dev 和 Ops 的指標一起展示，包括：

• 異常的程式終止（如 segmentation fault、core dump）：這些是漏洞被利用的指標
• 資料庫語法錯誤：對資料庫語法錯誤採零容忍態度，因為它們可能啟用或是正在進行的 SQL Injection 攻擊
• SQL Injection 攻擊的跡象：只要在使用者輸入欄位中出現 ‘UNION ALL’ 就發出警報

保護部署流水線#

支撐 CI/CD 流程的基礎設施本身也是攻擊面。如果有人入侵了執行部署流水線的伺服器，可能竊取原始碼或注入惡意變更。

緩解策略包括：

• 強化 CI/CD 伺服器並確保能以自動化方式重建
• 審查所有進入版控的變更（透過結對程式設計或 code review）
• 偵測可疑的測試程式碼（如存取檔案系統或網路的單元測試）
• 確保每個 CI 流程在獨立的容器或 VM 中執行
• 確保 CI 系統使用的版控憑證為唯讀

結論#

本章描述了將資訊安全目標整合到日常工作各階段的方法：將安全控制整合到我們已建立的機制中、確保所有按需環境都處於強化狀態、將安全測試整合到部署流水線中、在預生產和生產環境中建立安全遙測。透過這樣做，我們能在提升開發者和維運生產力的同時，增加整體安全性。