給DevOps加點料——融入安全性的DevSecOps

陳琦聊測試發表於2020-09-07

從前,安全防護只是特定團隊的責任,在開發的最後階段才會介入。當開發週期長達數月、甚至數年時,這樣做沒什麼問題;但是現在,這種做法現在已經行不通了。採用 DevOps 可以有效推進快速頻繁的開發週期(有時全程只有數週或數天),但是過時的安全措施則可能會拖累整個流程,即使最高效的 DevOps 計劃也可能會放慢速度。

DevSecOps是什麼

在 DevOps 協作框架下,安全防護是整個 IT 團隊的共同責任,需要貫穿至整個生命週期的每一個環節。這個理念非常重要,因此催生出了“DevSecOps”一詞,即在開發和運維緊密結合的基礎上再強調了Security,強調必須為 DevOps 計劃打下紮實的安全基礎。enter image description here

DevSecOps 意味著從一開始就要考慮應用和基礎架構的安全性;同時還要讓某些安全閘道器實現自動化,以防止 DevOps 工作流程變慢。選擇合適的工具來持續整合安全防護(比如在整合開發環境(IDE)中整合安全防護功能)有助於實現這些目標。但是高效的 DevOps 安防需要的不僅是新工具。它更需要整個公司實現 DevOps 文化變革,從而儘早整合安全團隊的工作。

DevSecOps目標及原因

DevSecOps的目的和意圖是建立在“每個人都對安全負責”的思想基礎上,目標是在不犧牲所需安全性的前提下,將安全決策快速、大規模地分發給擁有最高階別上下流的人員。

如今,也是同樣的原因致使傳統的安全領導者竭力爭取自己在行政會議上的一席之地。雖然這一席之地能夠保證安全決策有效性的提高,但由於價值創造過程中缺乏所需安全技能的供應,導致成果在產出過程中摩擦增多、速度減緩。如果沒有足夠的人手,企業經營者就無法達到業務運營商所期望的速度,也就意味著他們必須改變安全價值的貢獻方式,否則風險就會增加。enter image description here

隨著DevOps、敏捷和公共雲服務的業務需要,傳統的安全流程已成為需要削減的主要目標。但可悲的是,這又是最容易忽略的一點。傳統安全性的出發點是,一旦設計了系統,便可以由安全人員確定系統的安全缺陷,並由業務運營商在釋出系統之前對其進行糾正。這一原則允許流程將有限的安全技能應用於結果,並且不必在大型系統中額外增加安全環境。但是,這樣設計的流程只有在業務活動的速度是瀑布式的並且得到各方同意的情況下才有效。更糟的是,在迭代中引入認為安全必須以這種方式執行的想法是有缺陷的,也會在系統內增加固有風險。因為業務決策需要內聯平衡並以較快的速度解決。因此,這一方式尚未得到實現。

DevSecOps優勢及實施

在價值創造生命週期的最後階段,安全團隊幾乎不可能擁有呈現安全決策所需的所有資訊。而且,隨著價值創造過程加快提供迭代價值,以便緊密地聯絡客戶的需求,更可能的是,一次性完成整個系統的測試實際上對結果具有破壞性。實際上,以這種方式做出的大多數安全決策很少有效,經常被業務領導人否決,並且通常會在事件或破壞發生時受到質疑。enter image description here

因此,隨著DevOps的不斷變化,傳統的安全性不再是一種選擇。在通過迭代構建的系統的設計和釋出中,協作已經太晚了。但是,隨著DevSecOps的引入,業務運營商或安全人員都沒有必要放棄降低風險的措施;相反,組織內的每個人都應該擁抱並改進它,使其得到那些有能力為系統貢獻安全價值的人的支援。有個很棒的說法是,如果沒有刻意的內建安全控制,系統故障是肯定的,因為僅僅是避免安全就會給系統帶來更多風險。因此,認為價值創造與安全性不能合作的觀點是非常荒謬的。

DevSecOps建立的思維模式包括為業務運營商提供了工具和決策,幫助他們進行安全決策,以及為安全人員提供使用、調整這些工具的支援,這非常適合協作型團隊。在這種情況下,安全工程師與DevSecOps宣言保持一致,該宣言表明了安全從業者必須提供的價值,以及他們必須做出的更改,以使安全價值能夠提供給更大的生態系統。通過這種方式,DevSecOps工程師為系統提供的價值是在非合作的攻擊者發現缺陷之前持續監視、攻擊並確定缺陷。這需要業務生態系統中的所有人,包括安全人員,為迭代的價值創造做出貢獻,並不需要為了團隊中安全從業者的缺失而過度焦慮。

DevSecOps作為一種思維方式和安全性轉換,有助於流程與其他安全更改合作。換句話說,如果您認為需要將安全性新增到“開發”或“運營”或某些其他業務流程中,那就沒關係了!需要將安全性新增到所有業務流程中,並且需要建立一個專門的團隊來建立對業務的理解、發現缺陷的工具、持續的測試,以及預測作為業務操作人員如何做出決策的科學。此外,為了實現全面的轉型,DevSecOps需要執行管理層和董事會參與提供相關資訊,這些資訊是業務如何在當今經濟所代表的競爭日益激烈的低信任度環境中運營和保護團隊的關鍵指標。

作者:資深敏捷測試顧問,作為國內知名專案管理軟體——禪道的團隊成員,主要負責開源自動化測試管理框架——ZTF的開發工作。擁有十多年的敏捷過程實踐經驗,現致力於測試自動化和DevOps相關領域的實踐和研究。

相關文章