很多企業涉及在線業務的時候，發現業務發展迭代太快，剛剛熟悉和實施DevOps（中文社區翻譯成：研發運營一體化），在落地過程中發現很難過安全這一關，尤其是上雲之後，一下子湧入的雲服務眼花繚亂，上線的安全基線和要求是什麼？既然我們的團隊轉型到研發運營一體化，那安全團隊如何適應和與時俱進，這確實是個難題。
時間回到2009年：Netflix從IDC走向公有云
Netflix 在2009年發表了一篇 100多頁的 PPT 講述他們企業的文化觀《自由與責任》該 PPT 被 Facebook 公司的 COO 桑德伯格稱為“硅谷最重要的文件”；任何團隊的轉型都離不開思考轉型的初心，什麼事情要做，什麼事情要避免；Netflix 文化中最重要的7個方面是：
- 我們所珍視之物成就我們的價值觀
- 高效能
- 情境管理而非掌控管理
- 緊密一致又松耦合的團隊
- 支付市場最高工資
- 提升和發展
當時 Netflix 正在從美國本土的一家 DVD 租賃公司要立志成為一個全球的在線流媒體服務商，業務的高速增長的挑戰是每月的API請求數的快速指數級增長，遠遠超過數據中心的容量，2011 年一個報道稱Netflix當時用戶高峰吃掉了全美 32%的帶寬，數據中心頻繁發生大規模不可用的事故，因此 Netflix走向全面的 AWS 雲優化之旅，從而追求更好的可用性，支持公司業務全球化快速增長，匹配公司文化的技術敏捷微服務轉型；
如何定位 Netflix 和 AWS 的關係？Netflix 定義了未來要實現的 “PaaS” 幾個基本原則：
- 儘可能利用 AWS 服務（因為 AWS 在雲服務上持續有巨大的投資，沒有必要重複造輪子）
- 最大化開發人員的生產率和敏捷度
- 接口化隔離應用和 AWS，避免和 AWS API 細節鎖定
- 雲是由開發者掌控的，Netflix的 IT 是 AWS API
- 傳統的很多 IT角色都轉型成開發者，誰開發誰運維
- 長期目標：當市場其他的雲計算玩家趕上AWS的時候滿足可移植性
基於這樣的原則，Netflix 目標構建一個全球的基於公有云 AWS 的 PaaS平臺，支持 AWS 全部區域和可用區，支持多 AWS 賬號體系，一鍵部署跨多可用區高可用，跨區域狀態數據複製和備份，動態細粒度的安全管理，自動化擴展到上千的計算實例，監控百萬級的各種指標；那新的面向雲 API 的工程師團隊有著怎樣的角色構成呢？
自下而上，我們可以看到，Netflix 定義了雲架構師，質量工程師，數據持久化工程團隊，安全團隊，核心平臺開發，SRE 團隊，雲創新方案團隊（監控，猴子軍團等等），工程師工具團隊負責比如編排，構建和部署等；為了內部團隊熟悉雲服務，Netflix定期舉行一天的雲服務訓練營，一半時間講解，一半時間做實驗，讓團隊快速基於Netflix 的 PaaS 構建 “HelloWorld” 雲應用，並且瞭解如何和安全、監控集成，如何使用 Cassandra 讀寫數據。
時間發展到2012年：安全團隊的思考-雲和安全合規
安全團隊接觸到公有云，第一個挑戰是，原來數據中心的安全流程和策略完全不能適應雲的大環境，雲服務給到用戶的印象是自由、敏捷、自服務、可擴展、自動化，而安全給到大家的第一印象是折磨、守門員、標準、控制以及集中化；因此，對於安全團隊而言，首先要定義一個“雲友好”的安全模型。
那數據中心和雲服務的主要差別在什麼地方呢？相比傳統數據中心，雲服務計算節點生命週期短，可動態彈性擴展，硬件、網絡存儲等都虛擬化成了服務，可編程的基礎設施並且原生支持常見的部署模式；一般的數據中心的網絡虛擬化程度低，硬件設備的維護更新，應用環境難以保持一致和快速重建；那公有云的安全有哪些挑戰呢？
- AWS共享責任模型，事件響應如何做？根因分析？合規？
- 能否直接利用熟悉的現有的數據中心安全工具？授權問題，不同的假設前提，彈性伸縮高可用挑戰，
- 秘鑰管理，基礎設施是否可信？自動化引導程序？硬件加密機？
Netflix 安全團隊思考這些差異和挑戰的基礎之上，定義出了幾個雲優化安全模型的基本原則：
（1）區別對待，識別不同的風險等級；不是所有的環境、應用或數據都是同等重要，理解哪些是重要的並定義恰當的優先順序，理解不同業務組織的風險偏好；
（2）利用並集成工具；持續集成和持續部署的管道是集成安全實踐的非常重要的一個環節，跟開發人員使用一樣的工具，思考哪些適合集成和什麼情況適合隔離；在Netflix 團隊實現自動化持續集成和發佈管道之後，所有的變更都是一次新的發佈，應用上線之後利用 AWS 彈性工作組結合自定義業務監控指標實現了自動的在線擴容和縮容，這樣的自動化對於運維的影響重大，沒有 CMDB，沒有專門管理基礎設施的系統，極少的登錄生成系統的需求，開發運維的界限消失了；對安全方面的影響是，自動集成文件的完整性檢查和監控，用戶行為監控，漏洞和補丁管理內置在黃金鏡像自動化製作環節。
（3）正確的事情一定要開發者友好簡化；開發人員“很懶”很難為業務之外的任務花費太多時間，合乎情理的默認安全設定，為通用但難以推廣的安全措施開發公共庫，發佈和推廣可重用的安全模式
（4）擁抱自服務，但允許例外發生；自服務是公有云的一個突破性優勢，將安全配置放置在最終用戶隨手可取的地方，比如SSL證書管理，某些防火牆規則，用戶和權限管理等等。
對於合規性，Netflix面臨多樣化的合規性挑戰比如PCI，數據隱私，SOX等等，傳統的一些合規做法對雲環境而言不是那麼有利，需要採取更保守的策略；在應對方面，Netflix團隊採取了隔離合規性敏感的業務系統，限制邊界訪問權限和增強日誌審計，並利用多種工具集成實現合規性檢查和管控。
實施可編程基礎設施的安全有哪些優勢？
AWS 完全 API 覆蓋和支撐的“可編程基礎設施”對於客戶的優勢就是非常方便實現自動化和可量化衡量，Netflix首創了混沌工程團隊，使用各種工具（如 Netflix 的 Simian Army、故障注入測試、ChAP 和 Gremlin），以遊戲日的方式讓大家參與演習，演練如何應對災難故障；同樣的理念被 Netflix 安全團隊採納，他們使用 Safestack AVA、Metasploit、AttackIQ和 SafeBreach等工具，嘗試主動攻擊系統，強制工程師們在可控範圍內做一些破壞性的行為。這種“建設性破壞”思路讓安全團隊對於各種安全事件及時測試和改進，進而將說不清道不明的“安全”原則和策略變得類似應用一樣可迭代發展，可驗證。
對於安全工程師而言，隨著業務發展，雲服務的大量使用以及微服務架構的流行，會遇到不少常見的技術挑戰。大量的用戶的訪問和內部服務交互；從各種數據源會產生大量不同格式的數據；太多的需要管理的邊界接口和“豎井”分離系統，相對的，可供選擇的自動化可擴展的安全方案卻很少。
實際日常項目中，想想你如何響應業務團隊的需求？比如增加一個用戶，查詢某個業務系統所佔用的資源，更新一個防火牆配置，幫一個業務系統打一個快照，禁用多因素認證等等；很多客戶哪怕上了雲，很多還是手工在操作響應業務方需求；最自然的開發者友好的方式當然是抽象、定義和實現這些操作接口如CreateUser(),DescribeInstances(), AuthSecurityGroup(), CreateSnapshot(), DeactiveMFADevice(),etc
Netflix猴子軍團：安全猴子
Netflix 在2011年的一篇博客中《TheNetflix Simian Army》中談到為了提升可靠性和可用性，他們發明了“混沌猴子”在上班時間，隨機下架生產系統的計算實例，以便測試他們的系統可以在這樣的故障中保持良好的健壯性而不影響最終用戶；由於混沌猴子的成功，Netflix團隊將類似的理念延伸到了安全等領域，用來確保系統的安全合規。
“安全猴子“被設計來支撐公司的自由和責任的文化，集成 AWS 的 API 和安全服務，提供一個統一雲環境安全合規監控和分析的框架，Web 應用的漏洞掃描，自動化監控SSL證書和秘鑰有效不過期，檢查防火牆、用戶、用戶組和權限策略等安全配置發現違規和漏洞，並終止有問題實例。
舉個例子來理解如何將“自由和責任”文化貫徹到安全設計中去，最小權限原則是 AWS 倡導的雲安全原則的很重要的一條準則，但實際客戶反饋，很難在實際項目中落地，業務最大，最後各種妥協和“無底線”；
在 AWS 上分配恰當的權限非常困難，因為到 2018年 AWS 上有3200種細粒度的權限條目，有100多種的雲服務，如何破？從需求出發，Netflix 安全團隊將服務的權限整個生命週期建模成創建、訪問行為分析、自動適應新功能新權限策略和清理四個階段；在創建階段，安全團隊提供了一個AWSIAM顧問工具Aardvark（https://github.com/Netflix-Skunkworks/aardvark）協助用戶自助設定恰當的權限，定期訪問AWSIAM的Access API更新並保存用戶的訪問行為；同時又開發了Repokid（https://github.com/Netflix/repokid）工具，利用Aardvark裡面記錄的訪問行為記錄，提醒並刪除不需要的服務授權；
AWS是否能提供雲安全諮詢實施服務？
答案是肯定的；根據企業風險管理分類（GSRC）指導，企業需要關注治理、安全、風險和合規四大塊，而信息安全領域最相關的是安全相關：數據安全，網絡安全、應用安全和安全響應；風險相關：技術和運營；合規對於所有的線上服務而言都要遵守國家和地區的法律法規，如《網絡安全法》，歐盟的《個人隱私保護條例》，其他根據客戶的行業屬性，有不同的合規要求，比如PCI-DSS等。
AWS 雲安全專業服務提供三步走路徑，分別為基礎與規劃，設計和構建，以及驗證和響應三步，每個步驟涉及的大概內容如下圖所示，僅供大家參考：
星星之火可以燎原：雲安全卓越小組
DevOps和DevSecOps都涉及到企業文化相關的發展變化，從AWS的經驗來看，成立一個2個披薩小團隊，領導整個公司的雲安全戰略，幫助業務及開發運維團隊落地和積累幾個成功的應用上線經驗，對企業的轉型之路非常有幫助；這個雲安全卓越小組有什麼特徵和職責呢？首先人數控制到10個人以下，包含不同的部門成員，有產品經理，架構師，基礎架構工程師，安全工程師，運維和開發工程師等；其次，該虛擬團隊以降低和消除DevSecOps轉型的風險為己任，全職投入；最後，該團隊要負責制定安全合規相關的原則，流程，可動手實現安全相關自動化工具，培訓和影響其他團隊採用最佳的安全實踐，制定和指導安全基線。
DevSecOps：安全是每個人的責任
安全是建立客戶信任的基礎，保護您的客戶應該是您的首要任務；沒有這個，你就沒有生意機會；在DevOps時代，每天都在發佈新版本，過去的時候審查方式已經無法保證系統的安全，對代碼改動和可能安全風險最清楚的應該是開發者，而不是旁部門的安全工程師；開發人員要有安全意識，應用的安全架構，安全編碼，安全工具等等，在持續集成和持續部署流程中嵌入自動化的安全檢查比如靜態代碼掃描，安全測試用例等等。
閱讀更多 假行家聊安全 的文章
