企業在追求應用程式快速部署而導入DevOps，但同時安全性議題也不容被輕忽。叫車服務公司Lyft安全團隊在部落格發表文章，講述Lyft在DevOps環境如何兼顧應用程式安全性，不只是DevOps，而且是DevSecOps。
前維基百科安全工程師，現任的Lyft安全工程師Chris Steipp表示，Lyft開發程序是極度DevOps的環境。不同的團隊負責不同的產品，每個團隊都須達到各自的服務等級協定（Service-Level Agreement，SLA）以及回應時間等要求。每個團隊也都擁有完全控制自己產品的自由，包括決定產品建立以及執行的方式，甚至是產品更新的頻率，不少團隊選擇一天部署產品數次已增加新功能，不過在這個自由背後，隨之而來的責任是，這些團隊也必須為產品的安全性負責，像是確保安全性議題在時間內修補等工作。
Chris Steipp提到，在這樣的情況下，要在既有開發流程中，增加AppSec計畫是極度勞力密集的工作，不只要重新思考團隊如何互相配合，還要開發自動化整合安全工具，來整合現行的開發流。他認為，Lyft的AppSec計畫的成功，有三點值得拿出來分享，第一、每一件都需要被測量，第二、在對的時間發訊息給開發者，並尊重開發者的時間，第三、整個開發過程需持續性的回饋循環。
工具跟程序都需要可被測量，不僅僅是為了收集數據的目的，而是要讓團隊隨時注意指標，部分指標由AppSec團隊監控，但更有效率的方法則是由開發團隊自己監控，並對上面的數值負責。現在Lyft中每個開發團隊，都有一個以上的儀錶板，上面顯示著錯誤率、回應時間，或是符合SLA服務的百分比等數據。AppSec團隊的角色只在於提供儀錶板服務，以及追蹤過期卻未被修補的程序。
在AppSec計畫中，成功要素之二，在對的時間發訊息給開發者，並尊重開發者的時間。Chris Steipp指出，開發者每天都會收到來自各部門重要且有用的訊息，因此安全相關的訊息很容易被過濾掉，或是跟著其他訊息一樣，沉入待處理的工作堆中，直到前面工作被消耗完才會被注意到。
Chris Steipp也同意，作為有效率的開發者，的確需要設定許多訊息過濾條件以提高工作效率，但當AppSec團隊明確的告訴開發團隊本月是網路安全月，開發者就不應將XSS或是釣魚關鍵詞，作為訊息過濾條件。AppSec也應在適當的時機發出警告，像是在工程師開發新前端程式時，提醒他們要注意跨站腳本攻擊，或是他們在閱讀可疑郵件時，提醒他們網路釣魚攻擊。
在要求開發者重視安全性的同時，也必須尊重他們的時間，在不少時候，安全性工具在開發流程中可能造成訊息誤報，而導致後續作業受到阻礙。Chris Steipp說，曾經他們在GitHub上Pull Request前的統計分析系統，由於不精確的訊息回饋，造成工程師在合併程式碼時浪費許多時間，AppSec團隊收到反應後，為此開發了一套系統每30秒回饋系統狀態，大幅將每次程式碼合併的時間從1小時降到了7分鐘。尊重工程師的時間，AppSec團隊的安全性工作也才會被尊重。
第三點，整個開發過程需持續性的回饋循環。即使他們的AppSec團隊不大，但他們仍可以在開發流程中的13個時間點與開發者互動，這要歸功於高度自動化的工具，而且在實作自動化系統時，盡量讓上一個工具的輸出成為下一個工具的輸入。
像是他們讓開發團隊使用自動化評估問卷，以記錄團隊正在儲存資料的種類，以及儲存的地方，基於開發團隊自己的答案，如此在適當的時機提供反饋避免開發上的錯誤外，還能根據某些特徵，方便AppSec團隊進行稽核，並且將這些數據結果繪成數據圖，作為審查或外部安全評估之用。
from iThome 新聞 http://ift.tt/2saeyEx
沒有留言:
張貼留言