DevOps流水線與持續合規

所謂持續合規旨在持續維持 IT 系統的合規性

DevOps流水線的目的在於

  1. 盡早的有回饋 — 這個build有可能發佈嗎?
  2. 快速失敗 — 在進入生產環境前盡早偵測到Bug
  3. 在check in時就有品質 — 靠的是自動化測試和品質檢查工具
  4. 快速上線— 軟體的佈署是快速且持續

CI (持續整合)是一種軟體開發實踐,團隊成員經常整合他們的工作,通常每個人至少每天整合一次,從而導致每天多次整合。 每個整合都透過自動建置(包括測試)進行驗證,以盡快偵測整合上的錯誤。 許多團隊發現這種方法可以顯著減少整合問題,並允許團隊更快地開發選擇性軟體。

持續部署(Continuous Deployment)意味著每個變更都會通過流水線並自動投入生產環境,從而每天都會進行許多次的生產環境部署。 持續交付(Continuous Delivery)只是意味著組織能夠進行頻繁的部署,但可能會選擇不這樣做,通常是因為業務需求上更喜歡緩慢的部署速度。 為了進行持續部署,我們必須進行持續交付

持續交付是指能夠以可持續的方式安全、快速地將所有類型的變更(包括新功能、配置變更、錯誤修復和實驗)投入生產或交給使用者。 我們的目標是使部署(無論是大規模分散式系統、複雜的生產環境、嵌入式系統或應用程式)成為可預測的、可隨時執行的例行事務。

流水線的危險

  1. 流水線的運作取決於其效用 — 流水線中各項工具產生的結果的準確性至關重要
  2. 留意流水線膨脹 — 太多的工具可能會產生太少的價值
  3. 無人看守的流水線 — 誰要為什麼負最終責任?
  4. 脆弱的流水線 — hardcoded, credentials, Unhardened host or environment

規劃一個DevOps流水線

  1. 流水線的架構
    把正確的利害關係人都拉進來 — 架構師、DevOps團隊、資安、業務負責人
  2. 流水線的產出
    把正確的利害關係人都拉進來 — 架構師、DevOps團隊、資安、業務負責人

流水線本身

  1. Notification
    Email/Dashboard/Chatops
  2. Health
    Status/Available Agents / Capacity Monitoring
  3. Architecture
    VM/容器/PaaS模式

規劃流水線的產出

  1. 甚麼是需要被Build的?
    — 軟體開發會用到的技術與framework stack
    — Dependency
  2. 非功能性需求
    — 效能
    — 合規
    — 安全
  3. 核准的工具
    — 要錢的?還是免錢的
  4. Build time
    — 要多久?
Azure DevOps範例

具有簡約安全檢查的流水線作業

Lint checks是對原始代碼的代設計和代碼風格錯誤的自動檢查。

透過建置流水線確保軟體安全

工具做得好的地方在:

  • 已知的缺陷 — 已公開的CVE
  • 尋找CEW(common software weakness)
  • 自動重複的安全檢查 — 檢查錯誤配置(misconfiguration)
  • Fuzz testing和長時間運行的安全作業

而工具需要優化的地方在於:

  • 業務邏輯流程 — 例如第二次退費這件事
  • 授權缺陷 — 例如特權提升
  • 掃描結果的正確性

自動化安全檢查與工具

  1. 靜態的 — SAST(Static Application Security testing)
    分析原始碼或編譯的二進位檔案,以及 SCA(Software composition analysis) 和 CSA
  2. 動態的 — DAST(Dynamic Application security testing)
    分析正在運行的Application
  3. 混和的 — IAST(Interactive Application Security Testing)/RASP(Real Time Application Self-Protection)
    Agent安裝在伺服器中,可以進行動態與靜態的檢查
  4. 軟體構成/分析SCA
    根據依賴框架和函式庫分析軟體的組成部分,這是便宜的方法。

工具選擇的標準

  1. 與SDLC的整合
    -如構建系統、Bug追蹤系統、IDE與Fuzzing/Regression testing
  2. APIs
    — 用於自訂自動化與調整
    — 用於檢索特定漏洞類別
    — 用於檢索特定風險
  3. 掃描時間 — 增量掃描的速度
  4. 與維運的整合 — SIEM與弱點管理的整合
  5. 發布頻率
  6. 簽章更新頻率
  7. 學習/客製/調整的時間
  8. 開發人員的可用性
  9. 支援系統
  10. 偵測正確性
  11. 地端或SaaS
  12. 語言、框架、技術支援
  13. 可自訂的漏洞規則和簽章

持續合規

而合規團隊需要在系統設計和開發過程中儘早與開發和維運人員互動,也就是左移。CaC(Compliance as code) 有助於將合規性要求自動化為代碼,以促進協作、可重複性和持續合規性。例如CHEF的Inspec這一類的免費工具,當然還有付費版的。詳細介紹請參閱本部落格"CHEF自動化 — IT的六個標準差工具"一文。

使用 CaC、安全策略、基準、稽核和監控可以實現持續合規性。而管理合規性要求的期望並識別合規性偏差是實現持續合規性的關鍵重點領域。例如以下範例,使用CHEF insepc對AWS做合規性檢查。

如果是商業版的就有Dashboard與指標可以檢視(如下圖)。

SIEM(Security Information and Event Management)

根據Wikiedia的說明:
SIEM 是電腦安全領域的一個分支,其中軟體產品和服務結合了 SIM(Security Information Management) 和 SEM(Event Management)。 它們提供對應用程式和網路硬體產生的安全告警的即時分析。SIEM可以協助我們:

  • 對威脅來源進行量化
  • 對資安事件的可能性進行量化
  • 提供某一類的資安情資
  • 針對應用程式、資料庫與網路提供重要的資料安全分析,但基本上現在可以是任何種類的資料與日誌
  • 可以將資訊回饋到風險管理
  • 幫助 DevOps 和安全團隊建立適當的多層次防禦
DevSecOps流水線範例

--

--

運用"雲端服務"加速企業的數位轉型願景
運用"雲端服務"加速企業的數位轉型願景

Written by 運用"雲端服務"加速企業的數位轉型願景

我們協助您駕馭名為"雲端運算"的怪獸,馴服它為您所用。諮詢請來信jason.kao@suros.com.tw. https://facebook.com/jason.kao.for.cloud

No responses yet