開發(fā)團(tuán)隊面臨的三大安全挑戰(zhàn)
應(yīng)用安全不能只依靠防火墻，必須要在應(yīng)用開發(fā)階段采取適當(dāng)?shù)陌踩刂拼胧?，使得?yīng)用在發(fā)布上線前就具備較好的安全性，避免人為失誤造成安全隱患。
不少企業(yè)早就意識到了這一點，然而理想和現(xiàn)實之間還隔著幾十個安全漏洞，尤其是那些采用敏捷或者精益開發(fā)模式的團(tuán)隊，在具體的實踐過程中，幾乎無可避免的會遭遇到下面幾個挑戰(zhàn)。
挑戰(zhàn)1：一次性的安全檢查無法匹配持續(xù)性的交付
為確保團(tuán)隊開發(fā)出來的應(yīng)用具有足夠的安全性，最常見的選擇是對其進(jìn)行全方位的安全滲透測試。無論這樣的測試是由企業(yè)自己的安全團(tuán)隊執(zhí)行，還是購買外部第三方服務(wù)，最終都會得到一份詳細(xì)的安全報告，團(tuán)隊接下來需要做的就是基于這份報告所揭露的漏洞，對應(yīng)用進(jìn)行相應(yīng)的調(diào)整，直到安全漏洞被修復(fù)為止。
持續(xù)交付是敏捷、精益開發(fā)團(tuán)隊的核心能力之一，這意味著團(tuán)隊可以做到每周甚至任意時刻發(fā)布產(chǎn)品，持續(xù)性的從真實環(huán)境中獲取市場反饋，然后基于這些反饋對產(chǎn)品進(jìn)行調(diào)整。一個可以參考的案例是，早在2014年的時候，亞馬遜平均每秒有一次以上的產(chǎn)品部署，每天如此。
與此同時，安全滲透測試卻沒有這么高的“交付”速度。由于滲透測試的特殊性，雖然有大量的自動化漏洞掃描工具可以使用，但是一次全面、高質(zhì)量的滲透測試依然需要人工參與，幾天甚至一兩周之后才能得到測試報告是普遍現(xiàn)象。
那么問題來了，一方面開發(fā)團(tuán)隊持續(xù)性的每周都有新功能上線和舊功能調(diào)整，另一方面滲透測試卻沒辦法在這么短的時間里完成，它只能是階段性、或者定期性的進(jìn)行，例如每個季度測試一次。
這種情況下，開發(fā)團(tuán)隊該何去何從?如果要安全，那么就得等著做滲透測試，而且一旦發(fā)現(xiàn)安全漏洞還要花額外的時間去修復(fù)，產(chǎn)品發(fā)布必定會延期。如果要效率，那么就只能冒著風(fēng)險發(fā)布，因為誰也不知道當(dāng)前應(yīng)用有沒有安全漏洞，萬一被黑客發(fā)現(xiàn)并且加以利用，后果不堪設(shè)想。
問題的關(guān)鍵在于，開發(fā)團(tuán)隊是在持續(xù)的發(fā)布應(yīng)用到生產(chǎn)環(huán)境，然而滲透測試卻是個相當(dāng)耗時的一次性活動，它沒辦法跟上這么快的交付速度。
挑戰(zhàn)2：缺乏自動化、自助化的支持，安全實踐落地難
開發(fā)團(tuán)隊其實明白安全對于應(yīng)用而言至關(guān)重要，也知道在開發(fā)過程中就應(yīng)當(dāng)通過運用各種安全最佳實踐來主動消除安全問題，把安全風(fēng)險降至最低。不過現(xiàn)狀卻是，不少安全實踐要么無法落地實施，要么有流于形式的傾向。
一個真實的案例
一個開發(fā)團(tuán)隊在做完業(yè)務(wù)需求梳理后，立即進(jìn)入了開發(fā)階段。安全團(tuán)隊雖然在項目啟動時提出過安全要求，例如要求團(tuán)隊采用威脅建?；顒樱R別出應(yīng)用面臨的安全威脅，并制定應(yīng)對措施。然而由于該項目交付壓力大，時間緊任務(wù)重，再加上團(tuán)隊成員對于威脅建模并不熟悉，最后這個活動被一拖再拖，直到應(yīng)用開發(fā)完畢進(jìn)行上線前的審批時，才發(fā)現(xiàn)沒有做威脅建模，而此刻為了能讓應(yīng)用按時上線，只好回過頭來臨時補一份威脅建模的文檔，僅用于應(yīng)付安全部門的要求。這種情況下，安全威脅根本得不到全面的分析和應(yīng)對，風(fēng)險由此而生。
在項目前期的設(shè)計階段是進(jìn)行威脅識別的最佳時刻，開發(fā)團(tuán)隊只要在這時做一次威脅建模，就能識別出潛在的安全風(fēng)險，并且在接下來的開發(fā)過程中采取適當(dāng)?shù)拇胧┘右詰?yīng)對。但是開發(fā)團(tuán)隊卻仿佛是懶癌晚期患者，硬是拖到上線前才把威脅建模補上，而此時它早已失去意義。
為何開發(fā)團(tuán)隊一邊認(rèn)同安全的重要性，一邊卻又對安全實踐如此怠慢呢?本質(zhì)原因在于，某些安全實踐需要大量人工參與，或者對人員安全技能有很高的要求，與此同時又缺乏自動化、自助化的支持，因此在開發(fā)團(tuán)隊看來，這些實踐的采納成本太高，在面臨交付壓力的情況下選擇性的忽略，或者認(rèn)認(rèn)真真的走個形式，就成了再正常不過的結(jié)果。
挑戰(zhàn)3：高聳的部門墻讓開發(fā)和安全團(tuán)隊難以進(jìn)行高效的協(xié)作
隨著敏捷、精益開發(fā)模式的普及，再加上DevOps轉(zhuǎn)型的助推，不少企業(yè)已經(jīng)開始組建全功能開發(fā)團(tuán)隊，團(tuán)隊中各個角色有著共同的目標(biāo)，相互協(xié)作以更高的效率交付應(yīng)用。但是安全團(tuán)隊卻依然隸屬于一墻之隔的安全部門。
別小看了這堵墻，說它是萬惡之源有點太夸張，但它的存在確確實實阻礙了企業(yè)實現(xiàn)其業(yè)務(wù)價值最大化。墻的這邊，開發(fā)團(tuán)隊竭盡所能的以最快的速度完成應(yīng)用開發(fā)，以求盡快上線獲取反饋;墻的另一邊，安全團(tuán)隊只關(guān)心應(yīng)用是否安全，至于是否急著上線，那不是他們關(guān)心的問題。但是他們都忽略了一個事實，那就是企業(yè)的成功需要兩者共同高效的協(xié)作。
小結(jié)
敏捷、精益團(tuán)隊一方面要保持快速的交付速度，一方面還要提高應(yīng)用的安全質(zhì)量，看上去這是魚和熊掌不可兼得的事情，然而事實上我們依然有辦法解決這些挑戰(zhàn)。
開發(fā)團(tuán)隊可以通過自動化，顯著降低安全實踐的實施難度和成本，把一次性的安全檢查轉(zhuǎn)變?yōu)槌掷m(xù)性的安全質(zhì)量反饋。對于安全團(tuán)隊，也應(yīng)當(dāng)向著開發(fā)團(tuán)隊邁進(jìn)一步，打通開發(fā)和安全部門之間的隔離，以更加緊密和高效協(xié)作的方式，共同確保應(yīng)用具備更高的安全質(zhì)量。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
