本文要點
- 遵守IaaS安全性和合規性意味着在安全性和正常運行時間方面，雲供應商必須滿足某些法律和行業標準 。
- 在正常運行時間和冗餘方面，即使是最可靠的數據中心也比不上主要的雲平臺。是時候採取行動了。
- 首先審計我們的雲計算棧，並考慮在何處以及如何集成不同的業務系統。
- 檢查我們和雲供應商的合同，查看如果受到攻擊哪些故障保護是到位的。配置IAM，給所有用戶分配級別訪問權限。
- 即使是最周密的計劃也會失敗。用戶會犯錯（如：上傳私鑰、無法使用VPN等等）。定期測試集成是確保基礎設施安全的關鍵。
根據定義，DevSecOps是DevOps的進化。這個不斷髮展的理念本身還未完全成型，還有很多東西有待定義。對於任何人來說，任何接近完全成型的最佳實踐或規則都實現了對自身及對該理念超載。這應該是預料之中的事，因爲相對而言DevSecOps還是個新生事物。
這就是DevOps的本質，總的來說，它總是在改進，永不停滯。
作爲一個過程，DevOps本身並不古老。在很大程度上，它已經被認爲是促進IT部門中各個團隊之間合作的一種手段，否則這些團隊可能在很大程度上仍然相互隔絕。
在完全成型的DevOps過程中，IT開發團隊直接和運維團隊協作。這使得編碼和直接軟件開發能夠與傳統基礎設施（如：設備管理、網絡維護和服務檯功能）協同工作。
DevOps旨在允許讓這些方面以自動化和精簡的方式相遇、交流，並更容易改進彼此的工作。而其中有一個重要方面卻被丟到了一旁，那就是安全。
安全是一個不斷髮展的問題，不可能突擊上一段時間就能解決掉。它是個令人頭痛的問題，需要包含在DevOps過程中以在組織內部產生長遠的影響。
只能在整個項目進行過程中來解決項目的安全問題。
保持DevOps心態
DevOps的核心是一種經營理念，是構建和組織公司IT文化的方式。在這一理念背後的一大賣點是，它有助於創建軟件、測試它並更快地把它推向市場。儘管這確實是事實，但還不是全部。
如果生產出來的產品質量不高，那麼快速地創建和發佈軟件就沒什麼意義。在質量控制中忽略DevOps的作用將無法理解其真正的重要性和意圖。有效的DevOps允許開發和運維部門協調一致，並儘可能快地創建高水平和質量受控的軟件。
DevOps一直都在發展，隨着它的不斷髮展，很明顯可以看到，這些流程、服務和所需的工具要包含的遠遠不止軟件開發和運維管理。隨着大規模數據泄露及其災難性結果的新聞不斷地出現，網絡安全迅速成爲任何IT生態系統的重要組成部分。這種認識導致了DevSecOps的產生。
過渡到DevSecOps，並擁抱它
目標是讓安全成爲開發工作流的一部分。
如上所述，DevSecOps是DevOps的自然擴展。該過程旨在做兩件事情：它可以利用DevOps帶給IT部門開發和運維團隊的好處並把它們擴展到安全團隊，或者可以把需要完成的安全過程集成到DevOps團隊中。
在DevOps，如果生產出來的產品質量不高，那麼快速地創建和發佈軟件就沒什麼意義。如果生產出來的產品不安全，那又有多大的意義呢？
安全在過程中被忽視了，其實，從邏輯上來說，它應該是重要的組成部分。公司確實不能再忽視這個問題了。
- 作爲一系列確保DevOps過程的技術協議，如：多因素身份驗證或零信任。無休止的驗證會讓人感到疲憊不堪，但是，不經過檢查就不要讓任何東西通過，這是阻止來自外部幾乎所有威脅爲數不多的方法之一。該過程幾乎總能從內部診斷到威脅。
- 作爲一系列指示何時及如何對我們在DevOps中所執行的一切操作進行安全檢查的過程。特定場景比其他場景需要更多的安全檢查。識別並指出哪個過程比其他過程需要更多的安全關注，這可以消除大多數安全威脅。
- 作爲合作和共享所有權的理念，我們的開發、運維和安全團隊中的成員一起協作，每個人都負責一些通常不在其職權範圍內的事情。
由於DevOps的基礎是協作，因此這是DevSecOps最重要的方面。幾乎可以肯定的是，引入其他關注點會遇到來自團隊成員的阻力，但是，考慮到帶來的長期好處，值得這麼做。
這三種看待DevSecOps的方法最終會改善不同IT團隊部門之間的合作。尤其是，從DevOps到DevSecOps的過渡改善了團隊在開發過程中更早地檢測到威脅並進行緩解的能力。
採用所有這三種選擇可確保竭盡全力，在解決需要解決的安全問題的同時，維持當前開發目標，甚至進一步提高。目標不是把一切都拆掉，而是授權。
實際採用DevSecOps理念
DevSecOps不可能僅僅通過正常的日常DevOps過程來實現。我們不能告訴團隊成員只需要對安全有更多的關注就能期望得到更好的結果。安全團隊成員不能隨便就“蹦進”開發過程，期望跟開發人員“稱兄道弟”。
那麼，DevSecOps實際上是不是真的有用？DevSecOps的理念是一回事，而DevSecOps的實踐是另一回事。本質上，DevOps的這個新迭代有三個主要元素：
基於微服務的基礎設施
剖析整個基礎設施可能是個非常煩瑣的過程。一旦真正完成，整個過程（開發軟件、配置基礎設施和運行安全檢查）就被分解成微小的部分，每個部分都具有特定功能。這讓我們的基礎設施變成一臺平滑的機器。
在一切都變得超級專業化、細分和明確定義後，就更容易監控過程的每個步驟，並逐步進行必要的升級。
這還允許每個人或那些小團隊將流程申明爲自己的流程。團隊之間不會互相指責，團隊合作將達到更高的水平。DevSecOps對團隊的依賴程度與DevOps的相同，甚至可能更高。
再說一次，目標不是把一切都拆掉。整個基礎設施的剖析都是在紙上完成的。一旦剖析完畢，公司可以找到如何以有效的方式進行專業化和細分，儘可能地減少實踐中造成的破壞。
持續反饋
首先，拆掉基礎設施需要反饋。每個團隊以及可能每個團隊成員都應該有對組織的假設剖析有發言權。在一個基於反饋的系統上從零開始是理想的方式。
在DevSecOps調優環境中，開發人員接收有關其系統狀態的持續反饋。這種不斷更新的信息流讓我們的團隊瞭解它和安全威脅的關係。藉助安全的混入，每個人獲得最新的信息，並能夠有效地實施必要的安全補丁和更新。
如果沒有持續的反饋，新流程會讓團隊中的個別成員感到畏懼。持續的反饋對於保持IT團隊的專注及獲得靈感是必要的。當任務長時間（有時候要幾年時間）以相同的方式完成時，那麼持續反饋就是保持高效和熟練的必要條件。
要牢牢記住一個關鍵細節：反饋不僅源於管理層。反饋應該來自DevSecOps過程中的每個團隊。如果團隊在開發、安全和運維方面確實是隔離的，那麼每個團隊對其他團隊都要負責，並應該每天來回地提供多次反饋。
自動化
人工智能和機器學習都有潛力簡化幾乎所有事情、減少人爲錯誤並顯著加快速度。關鍵是，它必須恰當地應用於我們的安全檢查及其他過程。自動化很好，但是，如果不恰當地實施，就會出現問題。
大多數DevOps過程都灌輸了大量的自動化。從底層開始的團隊應該慢慢來，以避免被壓垮及在團隊中引起混亂。自動化不僅僅意味着人工智能。在我們的團隊中推廣使用最高質量的基本軟件（如：惡意軟件掃描程序、VPN和雙因素身份驗證工具）可以幫助你立即加強安全實踐。
如果開發人員必須主動開始掃描，那麼，他們很可能會放棄掃描工具。雙因素身份驗證已經增加了一點任務處理時間，在訪問任何內容時應該是自動的。一個好的規則是，不要打攪開發人員。
爲了不過度考慮基本安全性，並將自動化視爲充滿高級人工智能的複雜工具，我們不應該忽視這些基礎。很多時候，自動化確實包括高級人工智能。但是，簡單來說，它接受一項要花時間的任務，並把它變成一個不需要像之前那樣花那些時間就能完成的任務。
除了這些基礎之外，人工智能和機器學習在網絡安全方面提供的幫助尤其寶貴，因爲它們不僅自動執行這些基礎和基本安全協議，而且，實際上能夠學習、進化並適應新出現的威脅。
DevOps工具已經存在一段時間了。也已經有專門爲DevSecOps創建的工具，但是受到了一些批評。一些人把DevSecOps工具稱爲多此一舉的DevOps。應該鼓勵大家要有耐心，以培育DevSecOps社區，因爲隨着時間的推移會出現一些新的工具。
在安全編碼方面培訓開發人員
DevSecOps的起源並不具體，但是，其起源大約可以追溯到簡單的一句話：安全即代碼。問題是，安全即代碼不是大多數開發人員首先學習的東西。
在安全編碼方面重新培訓整個開發團隊不僅僅是再培訓方面的挑戰，而且價格高昂。有時間和錢來完成這種培訓是非常罕見的。確保從DevOps平穩地過渡到DevSecOps是必要的。
主要問題是，開發人員不瞭解或不認爲他們的代碼有問題。安全即代碼通常不是開發團隊擔心的首要問題。要使DevSecOps過程站穩腳跟，這一點亟需改變。
避免過渡到DevOps或DevSecOps的困難
儘管有效的DevSecOps在質量控制、增強合作及效率方面的優勢巨大，但是，DevSecOps與其他任何東西一樣，跟人有關。
即使是在最好的團隊中，有時候人和人之間也有摩擦。給團隊成員介紹一種組織他們合作的新方法（跟他們習慣的工作方式有顯著的不同），那麼會在以下方面產生問題：
- 學習如何適應開發人員的工作方式，不要進行大規模的重組。DevSecOps的實施可以減少代碼中的錯誤，但是，可能會遭受來自實際實施這些代碼人員的阻力。這被視爲不信任開發團隊，並會招致不滿。
通過溝通和妥協解決這類問題。像託管服務的選擇這樣簡單的事可以巧妙地解決。開發人員可能希望使用“開發者雲（developer cloud）”託管服務，即一個對開發人員友好的產品生態系統的服務，如：Salesforce所有的Heroku或廣受歡迎的DigitalOcean雲託管。
確保開發人員希望使用的每個服務都是安全的，這給安全團隊帶來了很多工作。這可能導致安全專家選擇經過驗證的真實服務。對特定的以開發人員爲中心的服務進行安全審覈，然後再使用所述服務是一種妥協的方法。
- IT部門不同團隊之間的信任問題導致合作不理想。與適應開發人員類似，組織的每個部分都有其他團隊的意見。偏見會導致安全團隊的成員不信任開發人員或開發人員不信任處理基礎設施進程的人員。
對於DevOps來說，這些都不是新鮮事，並且和其他團隊的合併會產生更多的問題。這就需要來自不同學科的團隊成員並肩合作了。把來自不同團隊的成員整合到新的交叉團隊中，可以形成社區。
- 過度依賴人工智能和自動化使人類不再盡職。隨着DevSecOps獲得成功，自動化軟件也在迅猛發展。不管聽哪個DevOps領域中專家的演講，我們都會聽到對自動化過度依賴的警告。總有一天，整個過程可能都由機器完成。就目前來講，人類仍然是DevSecOps進程的運動機制。
必須緩慢而謹慎地完成自動化。如果一臺自動化機器出問題，那麼，整個系統會受到影響。從基礎開始做，然後從那裏開始。
這些是可以克服的難題。部門間信任的缺乏和糟糕的合作正是DevSecOps要克服的問題。只要有足夠的時間和堅持，就會自然而然產生需要的信任。實施新流程的一個經過驗證的真正策略是，讓團隊以漸進階段的方式輕鬆地進入DevSecOps，避免超負荷工作。
檢查與供應商的關係
藉助DevOps的安全部分，更容易實施預防措施。這是預先檢查和持續保持警惕之間的不同，要不就等着出現混亂局面失控，直到那時纔來嘗試解決問題，但通常爲時已晚。
在當今互相交織的互聯網上，大量的安全風險來自第三方合作伙伴，他們提供服務並和我們的組織共享數據及資源。我們的公司和網絡的強大程度取決於最脆弱的鏈接部分。最近有個例子，跟託管服務有關，是谷歌雲斷電了，引起了大規模的斷網。像油管、Gmail、Snapchat和Shopify等等公司都受到了嚴重的影響。
爲了便於理解，我們來看看對Shopify的影響。因爲整個Shopify網絡集中在一個主機（谷歌雲）上，並且很顯然沒有好的後備計劃，這次停電使175個國家或地區的80萬家商店銷售停滯的時間長達7小時。最可怕的是，對於那些受託保護網站的人來說，這次停電可能是一次黑客攻擊，谷歌服務器被迫下線，而惡意軟件在聯盟商店的客戶數據中漫遊，挖掘其能找到的任何內容。
出現這樣的事故使我們主要關注託管供應商的正常運行時間/停機時間，將其視爲關鍵網絡安全指標。我們需要知道供應商的電話號碼。根據https://hostingcanada.org/ \l web-hosting-reviews">最近對網站託管運行時間的調查表明，小型公司無法接受任何低於99.9%的運行時間，更不用提像Shopify這樣上萬中小企業所依賴的大企業了。
前面提到的例子說明了供應商關係中固有的危險，這只是機會世界中的一個孤例。想一想我們網站所依賴或允許訪問的每個供應商。其中任何一個都可能成爲嚴重的安全問題。我們是否做好了準備？
理解DevSecOps規則
要在組織中使用DevSecOps時達到最高水平的生產效率，可以嘗試採用以下方式：
- 從一開始就爲每個人集成最佳網絡安全實踐，如定期更新軟件和硬件、滲透測試和對員工進行VPN最佳實踐（虛擬私有網絡）的強制性培訓，他們在任何時間連接互聯網都要通過VPN。
- 優先考慮安全性。不要讓人爲錯誤或疏忽毀掉我們。DevSecOps存在的原因是經常發生人爲錯誤。目標是把錯誤的數量控制在限定範圍內，並在錯誤發生後，把協議設置好以捕捉錯誤。
- 監控所有的軟件並持續檢查代碼，以便我們修補安全漏洞，併力爭比黑客領先一步。這包括定期實施代碼依賴性檢查，如：OWASP依賴性檢查。
- 把任務分解成可以管理的小任務塊。每個任務越小越簡單，整個過程就越可能正確地完成。
- 設置一鍵式合規性報告，以便我們有一份清楚記錄軟件開發流程中每一個步驟的日誌。
- 鼓勵IT部門不同團隊成員保持聯繫並討論他們所擔心的事。極力地確保每天由團隊來引導話題，就像強制要求流程中不同團隊之間召開會議一樣。
與新社區一起成長
DevSecOps成爲主流是該進程每個支持者所設想的。一個新興社區正處於組織創新的最前沿。
【DevSecOps的每個支持者都希望，該流程能夠成爲主流。一個新興的社區正將自己置身於組織創新的最前沿】
DevSecOps日（DevSecOps Day）是一個爲期1到2天的全球系列會議，有助於教育、發展和探索開發安全即代碼的概念。隨着這個運動的發展，社區也增強了學習和改進的能力。InfoQ參加了一場倫敦會議，發現它對組織大有裨益。
隨着這一運動的發展，會涌現出更多的組織，他們爲企業家、小企業和大企業帶來更多的活動和學習機會。
是時候演進了
如今的現實是，網絡安全威脅無處不在。任何打算在網上生存和發展的組織都需要爲此做好準備。這種準備工作的主要部分是站在DevOps思想的最前線，那就是DevSecOps。
這種理念的轉變確保組織有恰當的協議來有效地評估、預防、抵抗或抵禦威脅。適當的DevSecOps實施可能是我們今年要做的最重要的事。
作者介紹：
Sam Bocetta曾是安全分析師，作爲網絡工程師爲美國海軍服務多年。目前，他處於半退休狀態，爲公衆提供有關安全和隱私技術的教育。Sam的很多工作涉及滲透測試彈道系統。他分析我們的網絡尋找入口點，然後根據自己的發現出具安全漏洞評估。此外，他幫助計劃、管理和執行復雜的“道德”黑客行爲，以識別漏洞並減少美國海軍使用的企業網絡 （包括在陸地上和海上使用的）的風險狀況。
他的大部分工作集中於識別、預防應用程序和網絡威脅、減少攻擊矢量區域，消除漏洞和一般性報告。他能夠發現弱點並制定新的策略，以加強我們的網絡來抵禦一系列網絡威脅。Sam與架構師和開發人員密切合作，確定對跨應用程序識別的漏洞的緩解控制，執行安全評估以模擬各種威脅的策略、技術和過程。請通過Linkedin賬號聯繫他。
原文鏈接：