在日前召開的互聯(lián)網(wǎng)安全大會上，幫助星巴克公司構建一個主要云計算項目的兩位安全和合規(guī)負責人發(fā)表了演講。幾年前，星巴克公司曾要求合規(guī)性自動化初創(chuàng)廠商Shujinko公司的創(chuàng)始人Matt Wells和Scott Schwan為其構建必要的團隊和流程，以支持星巴克公司開發(fā)的移動應用程序，采用完全符合支付卡行業(yè) （PCI） 的安全云架構，并根據(jù)互聯(lián)網(wǎng)安全中心（CIS）制定的標準進行衡量。

Shujinko公司首席技術官Matt Wells解釋說，“我們公司的20名工程師在大約9到12個月的時間里構建了一個高度自動化、可擴展、可重復的環(huán)境，星巴克公司可以用來支持他們想要推出的所有產(chǎn)品，他們以此為基礎然后開始將其他應用程序移至公共云?！?/p>

Shujinko公司首席技術官Matt Wells和首席執(zhí)行官Scott Schwan深入研究了他們?yōu)樾前涂说墓ぷ骷毠?jié)，并分享了有關如何將合規(guī)性納入企業(yè)的云計算架構以及在此過程中擴展DevSecOps的技巧。在此采用了他們自己的語言提出一些見解。

1.將合規(guī)要求放入“完成”的定義中

Matt Wells說，“對于一個工程團隊來說，將合規(guī)性要求納入‘完成’的定義中是非常重要的。很多時候，團隊沒有及早地開始對話和進行討論。因此，‘完成’的定義沒有包括與法規(guī)遵從性或安全性相關的內容。因此，為團隊建立這種聯(lián)系極為重要?！?/p>

2.讓工程師直接負責保護環(huán)境

Matt Wells說，“在特殊情況下，我們正在構建一個完整的云平臺，并且我們負責該平臺的安全性。能夠盡早設定期望，也就是說，‘這很重要：如果想加入這個團隊，將會使用一些非常好的技術，但是要對安全負責，要對合規(guī)性負責。如果沒有通過審核，那將是我們的團隊責任，而不是安全團隊或合規(guī)性團隊的責任?！?/p>

3.在云計算工程團隊和安全團隊之間建立緊密的聯(lián)系

Scott Schwan說，“我們確保從一開始就真正與安全領導保持一致。我確實相信DevSecOps的基本原則，因此，如果工程團隊了解他們正在建立的要求，他們可以對自己的職責負責這樣做，不再是安全團隊在項目的最后階段突然涌入，并試圖更改或阻止它們，因此，文化轉變的一部分是確保我們在團隊之間建立信任?！?/p>

4.在構建之前定義安全性程序和要求

Matt Wells 表示，“我們從安全團隊那里收集了要求，并且從業(yè)務組那里收集了必須支持的地理區(qū)域的合規(guī)性要求。我們擁有了必須遵守的所有合規(guī)性標準，這些標準有不同的要求。從那里我們定義了程序，那么我們要如何給服務器打補丁呢？我們將如何采用容器并部署代碼？

我們認為在擴建之前設置這些程序很重要，因為隨著工程師擴建基礎設施，有時這些程序會影響他們構建某些技術的方式。對我們來說，這就是設計階段。”

5.將安全專業(yè)知識嵌入并培訓工程團隊

Matt Wells 表示，“在設計之后，我們大量招聘工作人員，需要獲得一些短缺的技能，因此我們雇傭了一批安全人員、開發(fā)人員和運營人員，結果發(fā)現(xiàn)需要的開發(fā)人員比安全人員和運營人員多得多。我們非常專注于自動化和規(guī)模化，因此發(fā)現(xiàn)讓開發(fā)人員參與進來更容易，讓安全人員和運營人員與他們一起工作，定義開發(fā)人員將如何構建許多這些功能。我們并不是直接聘用專業(yè)安全人員，而是通過培訓開發(fā)人員使他們成為安全人員?！?/p>

6.遵照法規(guī)自動加固環(huán)境

Matt Wells 表示，“對我們來說，一個主要原則是自動強化我們構建的所有內容。我們要做的第一件事是我們使用Terraform自動化配置和強化AWS賬戶。我們花了一周的時間使用Terraform來構建AWS賬戶，而不是花一天或幾個小時來構建AWS賬戶、設置日志記錄、密碼策略等。但是從長遠來看，每次我們在AWS賬戶中設置新內容時，不必對工程師說，‘是否設置了密碼策略？’或者，“日志要去哪里？”我只想說，‘運行Terraform腳本進行加固了嗎？現(xiàn)在我們可以繼續(xù)工作?！?/p>

7.自動化護欄

Scott Schwan說，“我們使用了可以掃描新環(huán)境的支付卡行業(yè) （PCI）要求的供應商。因此，在運行腳本后，我們立即運行并向他們提供了報告。如果他們仍然遇到支付卡行業(yè) （PCI）方面的問題，我們將確保返回進入sprint，然后將它們添加到Terraform中的基礎設施代碼中，然后下次進行設置時，他們將不會遇到類似問題。

這是在AWS擁有他們現(xiàn)在擁有的一些工具和服務之前。在此之前，我們必須構建它，因為那不是他們所擁有的東西。我們確保將其納入團隊的精神之中。當時是，使用CIS基準測試，獲得良好的反饋，迅速進行補救，將其重新添加到其代碼中?！?/p>

8.將基于合規(guī)性的測試構建到單元測試中

Scott Schwan說，“我們總是必須驗證是否在運行合規(guī)代碼，其中一部分是通過基于合規(guī)性的測試。我們始終確保不會因為盡快行動而破壞合規(guī)性。

我們開始為代碼編寫單元測試，不僅是針對功能的單元測試，還涉及安全性和合規(guī)性。我們希望確保團隊每次部署新服務時都在測試合規(guī)性標準。他們是否設置了密碼策略，是否啟用了日志記錄？它是跨功能的。編寫這些單元測試的不僅僅是安全工程師。團隊隊員對此也需要負責?！?/p>

9.盡可能使用云原生控件

Matt Wells 表示，“我們在這里所做的一件事是盡可能使用云原生控件。云原生并不是說在云中提供控件。而是使用了構建于云中的控件，有時這意味著來自云計算提供商，有時則意味著來自供應商。這完全取決于情況?！?/p>

10.讓工程師在差距評估中扮演重要角色

Matt Wells 表示，“在構建階段結束時，我們專注于完成程序，以確保認為可以正常工作的東西有效。在大多數(shù)情況下可以實現(xiàn)，但是在某些情況下，我們必須更改程序。最重要的是，我們實際上已經(jīng)完成并驗證了程序。

這需要進行差距評估工作，我們把它交給構建它的工程師，并在團隊中分散了評估責任。他們比其他人更了解環(huán)境，因為他們擁有它的所有權，并且會說，‘是的，我們確實存在差距，我們必須解決這個問題?！?/p>