技術與實務

前言 前陣子在 DevOpsDays Taipei 2023 參加了一場 OST，該場討論的主題是《DevOps 與資安的平衡（ISO 27001）》，當中聊到了 DevSecOps 成熟度模型（DSOMM）時，有位與會者提到兩年前有人成功運行了 DSOMM，但現在那個方法已經失效，不確定現在組織要怎麼自己架設 DSOMM 的網站… （…突然感受到我該更新兩年前所寫的 DSOMM 文章了…🧐）於是這篇文章就出現啦！ 不過 DSOMM 的概念與組織如何運用與先前的介紹差異不大，所以本篇不會太著墨在 DSOMM 介紹，對於 DSOMM 有興趣的讀者可以先參考之前的介紹文：DEVSECOPS 成熟度模型（DSOMM）。而本篇主要會針對以下幾個變化進行介紹： DevSecOps 的成熟度級別 ISO 27001:2022 的對照 基於團隊的評估 自行架設 DSOMM 網站 一、DevSecOps 的成熟度級別 如同大多數的成熟度模型（例如：CMMI、DMM）將成熟度分為五個級別，今年 DSOMM 亦將成熟度從四個級別重新劃分為五個級別1：

啊哈！DevOps Handbook 第二版 DevOps Handbook 是 DevOps 領域的經典書籍，同時也是 EXIN DevOps Professional 國際認證的核心教材，不論技術者或管理者，對於任何想學習 DevOps 核心概念與實踐的人來說，這本書就是最好的起點，也是大家書櫃上不能錯過的一本好書。 最近 Nicole Forsgren 博士（另一本 DevOps 經典書籍 «Accelerate» 的作者之一）為本書第二版添加了新的內容，包括： 15 個案例分享 近年來 DORA1、Puppet2 «State of DevOps Report» 的調研結果 «Accelerate» 所提及的關鍵指標 當前適用的技術工具 …等其他有趣的主題 當中，最主要新增的篇幅為 15 個案例分享，而這些案例多是來自企業在 DevOps Enterprise Summit (DOES)3 上精彩的分享。由於篇幅限制與章節分佈，因此有些案例在書中只能呈現部分的內容。我們將這些原始內容的相關資訊作了整理，並且提供十分扼要的註解。讓大家可以很快地找到感興趣的主題，然後前往觀看4 :sunglasses:

前言 隨著企業提升響應市場變化的速度，不管企業的規模為何，抑或屬於哪一種產業，DevOps 儼然成為現代 IT 的重要典範。但在快速迭代的業務發展下，由於傳統的安全治理較為繁瑣，也使企業在導入 DevOps 的過程中，從需求、設計、實作，到後續的監控和改善，較難看見充分的安全實踐，組織亦缺乏在每個流程階段，衡量當前安全的成熟狀況。 什麼是 OWASP DSOMM？ DSOMM 2 的全名為 DevSecOps Maturity Model（DevSecOps 成熟度模型），或許大家較耳熟能詳 OWASP 的另一個軟體安全的成熟度模型 SAMM（Software Assurance Maturity Model，軟體保證成熟度模型），SAMM 針對五個業務功能（治理、設計、實作、驗證、維運）定義了一系列的安全實踐及評量指標，協助組織將安全覆蓋至全軟體開發生命週期。SAMM 為較高層級的規範性模型，而 DSOMM 則為更具體的 DevSecOps 實踐。

安全的運行環境對於雲端服務來說，是個重要的議題，而對於使用者來說更為重要。 因此，對實體或虛擬主機進行弱點檢查與監測，能為雲端服務提供一個安全的基礎，也能滿足組織對於資安的基本要求。然而，安全威脅多樣，且各式作業系統的組態設定又各有巧妙，要如何才能有效率地完成這個工作，對於維運人員來說是相當令人頭疼的事情。 SCAP2 (Security Content Automation Protocol) 是由美國國家標準暨技術研究院(National Institute of Standards and Technology, NIST3)所維護與制定的協定，主要用意是為主機的組態設定與安全需求提供一個共同交互與發展的基礎。同時也為 NIST 800-53 關於運行主機的安全要求與最佳實踐提供一個自動化的基礎。 OpenScap4 則是基於 SCAP 的具體實作，它主要透過使用 SCAP 裡的 XCCDF5(Extensible Configuration Checklist Description)與 OVAL6(Open Vulnerability and Assessment Language)。XCCDF 透過 XML 形式的描述語言具體地提供評估與檢查一個主機時，應該進行的項目列表。測項可能是一些安全需求下的組態設定的檢查，也可能來自 OVAL 所識別的弱點測試。