一千萬個為什麽

搜索

持續交付DevOps的控制框架?



我一直在閱讀 Jim Bird的DevOpsSec 書, 第4章 - 作為代碼的安全性中的一個聲明是如下:

敏捷的理念和原則 - 在文檔上運行軟件,頻繁交付,面對面協作以及專註於卓越技術和自動化 - 構成了DevOps的基礎。 持續交付是DevOps的控制框架,它也建立在基本的敏捷開發實踐之上:持續集成。 (O'Reilly 2016,ISBN 9781491971413)

我對控制框架的理解是它聲明了某些控制目標,例如:

  • 付款僅限於獲得授權的產品和服務。

這可以通過系統內置的一些流程來滿足,並且可能會有一些制衡。但是,您不會說該進程 Control Framework。

對我來說,這句話應該是這樣的:“持續交付滿足”。

我完全錯了嗎?持續交付DevOps的控制框架?

或者,我是否正確並且持續交付不是DevOps的控制框架?

轉載註明原文: 持續交付DevOps的控制框架?

一共有 2 個回答:

在我看來,你是對的,持續交付(CD)不是Devops的控制框架,至少它不是唯一可能的控制框架。

但是在你引用這本書的背景下,當你開始將安全基線和評估作為交付產品的一部分時,它會得到最多使用的可能性。

在安全上下文中,您將在後期部署階段添加煙霧測試,以確保您的應用程序不受XSS或Sql註入的影響。如果任何測試失敗,請阻止其他環境中的任何部署,請將部署標記為失敗並最終回退到以前的版本 這樣就可以滿足安全規則,並以這種方式充當控制框架,以確保生產部署對已知漏洞“安全”。

在'安全為代碼'的情況下,我會說'是',例如:

正如作者所言,如果我持續交付,這意味著我有持續集成,這意味著我可以輕松整合並在整個系統中傳播更改,這可能是由於基於規範的基於代碼的配置。

僅此一項就可以成為一種控制形式,因為您可以輕松地在整個基礎架構中傳播合規性相關更改

不過,我認為配置管理在devops生命周期中體現了合規性控制。看看Chef \ DSC和InSpec \ ServerSpec。您可以在烘烤階段運行配置管理以設置初始配置,然後在部署之後按計劃運行它作為合規形式以消除漂移。 InSpec \ ServerSpec工具位於CM之外並“審核”系統的狀態,以確保CM正在完成其工作。