1. 公有雲安全（AWS、Azure、Google）
早期：AWS， 租戶層面安全
AWS安全子產品化，安全最佳實踐，客戶的安全體系
AWS組織管理、VPC的安全架構管理、美國國防部做的SCCA安全架構
雲平台的SDL和内部的安全架構
Google的底層安全架構非常完善，虛拟化安全體系包括： KVM漏洞挖掘、QEMU代碼重構、業界第一個重構QEMU的沙箱、gVisor、業界第一個可信執行個體、Titan晶片、BeyondCorp、BeyondProd、 Zero Touch Prod、Zero Touch Network等等一些底層的安全實作思路（基礎設施安全）
Azure安全收入已經100億美金， Azure會減少跟AWS的收入差距甚至超越AWS.
Azure的安全架構整體安全思路和架構還是比較偏傳統廠商，内部的網絡安全架構、雲防火牆的架構， Azure這一架構符合Azure ToB、 ToG的業務場景， 是以做的架構比較傳統。
Azure的安全已經開始發力，Azure AD Conditional Access 、 Office 365安全、 Azure Active Directory、微軟終端安全、Sharepoint Online、Exchange Online、 Microsoft Teams安全、Azure Information Protection、 Azure Defender系列，都有強力的客戶需求， 這些需求都非常貼近實際需求的， 大部分的客戶上雲之後必須要跟Azure Active Directory 進行融合， 融合的過程中需要Azure AD Conditional Access 和針對SaaS的CASB等認證和DLP的需求。
另外上雲之後文檔、郵箱都開始使用Azure Sharepoint Online和Exchange Online等，OnPermises域和Azure Active Directory的域打通， 必須使用Azure Defender For Identity。Azure之後對于企業辦公包括聊天、檔案處理、檔案共享等辦公場景，還有終端安全保護、雲上的DLP、CASB、統一的身份認證等都非常完善了， AAG的雲特點讨論雲安全架構和雲安全技術的兩點。
雲安全面臨的風險：
1、國家級對抗風險
其實從我個人角度我發現，國家級對抗已經特别關注雲安全了，不管是SolarWinds針對微軟的攻擊（竊取Azure部分少量核心代碼）還是從一些公開途徑了解到的AWS的一些安全防護思路（假設美國也會攻擊、其他國家也會攻擊）的思路來做的全鍊路加密（針對光纖進行實體、鍊路層、應用層加密）、檢測針對監聽光纖的行為和動作進行告警，安全團隊進行應急響應。
因為雲承載了大量核心的客戶資料，這些資料是客戶甚至一個國家的重要資源，是以美國一直在打壓中國不能讓中國的雲廠商在美國落地生根，發展壯大。如果能針對雲平台進行控制，那影響的後果絕對非常大的，雲上面承載客戶的資料太多了，還包括政府的資料（疫情、疾控等資料）、美國國防部的DIB計劃（武器資料）、國家人力情報（OPM等人力資料）、高科技企業（微軟、Amazon）等。
是以對于雲廠商來說每年數十億的投入、大量的頂尖安全人才、核心的雲安全技術都是雲廠商特别關注的，說真的雲和雲安全更需要創新技術、更渴望頂尖的安全架構、更渴望有理想的追夢和同路的技術大牛、更渴望客戶提出更高的安全要求、更渴望把技術做深入解決客戶面臨的APT攻擊，保證國家新基建數字化轉型過程中的關鍵基礎設施的安全增強和落地。
2、上雲後面臨的風險
① 企業上雲後的雲側風險
雲上安全風險是企業上雲之後，混合雲環境下面臨的巨大風險，包含AK憑證風險、雲上預設配置導緻的風險、雲廠商自身的信任問題導緻的風險；
AK特權憑證洩露：雲上的AK存在較高的權限，利用擷取到的AK可以進行這個AK擁有權限内的各種操作，導緻入侵和資料洩露的風險，這塊有非常多的公開材料可以參考，不再贅述；
雲上預設配置導緻的風險：企業上雲之後采用了大量的雲産品，這些雲産品預設配置會有風險，例如采用對象存儲使用者配置之後可以進行Public的通路，可導緻資料、代碼等被直接通路；
雲廠商自身的信任問題導緻的風險：由于雲廠商的一些信任導緻的安全風險，舉例來說資料類産品本來有IP白名單保護，但是可以通過一些漏洞繞過這個限制。
② 基礎設施安全風險
網絡安全風險：上雲之後面臨的最大風險就是賬号風險以及網絡安全風險，主要是賬号混亂和VPC設計混亂導緻橫向移動；
應用安全風險：粗略的分成了架構類通殺漏洞、大規模竊取使用者資料漏洞、開源軟體漏洞、開發和開發之間的信任調用導緻的漏洞以及供應鍊漏洞（詳情參考https://mp.weixin.qq.com/s/xkeNxE99ORtVs9EOv0ellQ）；
系統安全風險：一旦被突破了層層防禦，包括應用層、網絡層達到系統層，黑客會執行指令，會進行資料竊取，會進行橫向移動；
資料安全風險：資料安全才是黑客入侵的開始，是以黑客會從各個雲的管道竊取資料，造成資料洩露風險，由于雲的API普遍化，資料竊取也形成了工具化、快速化的方式轉變。
第三部分：雲安全架構亮點
1、可信+零信任架構
零信任現在炒的火熱，從個人觀點來看業界是分三層零信任的：
第一種是針對企業辦公網的零信任，代表作是Google BeyondCorp，面向的對象主要适合企業内部的各類員工，包括IT、财務、法務、營運等人員，提升他們的安全性，主要思想是免除企業的特權網絡以及通路權限完全是取決于使用者和裝置的身份，不考慮企業内部員工和使用者所在的網絡位置；
第二種是針對企業内網東西向橫向隔離提出的零信任，主要代表是Google BeyondProd、Amazon CloudAuth、Alibaba ZTPA(Zero Trust Prod Access)主要解決的問題内網橫向移動隔離、預設認證鑒權、預設攜帶身份等能力，建構以身份為下一代的基礎設施安全層，Google、Amazon和Alibaba都面臨着三種典型的場景，後續會講到三家基礎設施安全層的差別；
第三種就是面向租戶側的零信任，主要是針對網際網路産品使用者側的通路控制，例如Azure AD Conditional Access、Okta、Auth0為代表的，解決使用者側零信任問題，主要包括提供MFA、持續驗證能力、Conditional Access（風控引擎）等。下面我們抽取生産網和辦公網的代表架構來做講解和分析，關于Okta、Auth0等可參考一下相關材料。
對于企業辦公網零信任來說，國内外有大量的初創公司和安全大廠投入其中，個人觀點解決的最核心的問題面對一些高價值(High Value Assets)企業使用者的核心資産來看，一旦被APT組織突破邊界，那麼就可以利用内網中的預設信任進行滲透，包括之前Google Aurora攻擊事件，那次攻擊事件之後Google開始了架構更新，預設假設邊界是不安全的，需要把目前的安全架構進行更新，Google BeyondCorp對于企業員工的管理就是慢慢去除VPN，核心邏輯使用Google Login(MOMA)登入内部相關的系統，采用硬體YubiKey方式杜絕釣魚式攻擊，使用安全裝置（采集15+個類别200+采集點，并且高安全等級使用者采用了TPM）、使用者層認證等資訊通過Access Control Engine來進行持續的驗證和裝置、使用者、身份、應用權限的檢查，一旦通過之後既可通路背景有配置設定對應權限的應用，并且在通路過程中不斷驗證各種次元的資訊。
雖然Google首先提出了BeyondCorp并且有了對應的商業化能力，但從我觀點來看，我還是更加看好AACA（Azure AD Conditional Access）。下面上一張圖來看看整個AACA的架構：
這張圖我就不展開了一一介紹了，大家肯定也在很多地方看過這張圖了，也比較熟悉，我更多說說AACA架構的亮點，和一些我觀察到的點。
在2019年疫情期間的時候，我通過觀察世界500強一個月的相關的域名解析記錄追蹤，發現了使用Azure雲的比例提升較快，其實基于這個點我加速了針對Azure的研究，我發現在疫情期間AACA的架構相對來說還是會比較弱的，但是僅僅拿到賬号密碼就能夠進行登入，包括當時Amazon電商和AWS登入都是這種安全狀态，相對來說安全等級還是比較低的。
随着疫情的慢慢變化，導緻黑客攻擊越來越多，對于采用Azure雲的這些客戶來說安全性遇到了巨大挑戰，Azure、Amazon、Google對于自身的員工安全等級很高（後面會講到Azure的最佳實踐），但是對于Azure、AWS上的使用者來說，大家同時開始發力，在同年7月增加了Device認證，2020年1月份打通了Intune、Citrix、VMWare、Citrix等MDM的生态，2021年截至到目前已經支援衆多MDM廠商，企業原來管理自己裝置的平台也可以跟AACA進行整合，擴大了整個AACA裝置認證的生态。
在2020年除了Device生态之外也增加了一些針對AACA的攻擊增強手段，提供了Header驗證功能來提升Password Spraying對抗。目前Azure也提出了新的安全能力，提供可驗證憑證的架構體系，對身份進行徹底的變革，分散标式身份識别方法 (DID：參考文檔https://docs.microsoft.com/zh-cn/azure/active-directory/verifiable-credentials/decentralized-identifier-overview)方式來改變目前的一些身份安全性。
另外從安全性上來說，我也發現在2019年的時候通過密碼竊取、Password Spraying等方式的難度大大增加，後來有了Device對抗，有了全新的Password Spraying對抗，有了社工庫密碼的查詢（國外常見的洩露的庫是無法進行登入的，個人猜測是跟HaveIBeenPwned進行了合作），全面提升賬号安全性對抗。是以從黑客視角來看，這種零信任架構還是有對抗和進行持續安全能力和架構在提升的。但是從國家級APT組織和黑客來看，目前微軟的身份認證架構還是存在一些分析的，例如可以繞過login.microsoftonline.com的SSO的限制直接登入繞過登入頁面，直接通路背景的業務，當然這種漏洞叫做微軟AACA的配置問題也可以的，而且Azure自身也存在各種漏洞可以Bypass MFA等限制。
是以給國内搞零信任的一些個人微小的建議，零信任的端、網關、SDP、Radius、NAC準入等零信任廠商，還是要非常重視零信任産品的安全性的，一旦零信任鋪開而出高危漏洞的話，影響的範圍都是十分廣泛的，請一定要把安全性内嵌零信任當中，而且給參加攻擊的同學一些建議，未來的攻防肯定會更聚焦基于零信任的攻擊技術，這塊也可提前布局研究攻擊政策和手法。
辦公網零信任講完了，下面講一下我們基礎設施安全團隊也在落地的一件事，這件事可能是未來5-10年的事情，對于落地、工程化、績效體系等都有非常大的挑戰，但是我們還是花了一年摸清楚了這條路的重要性。
生産網零信任主要解決的問題還是服務的預設認證、預設鑒權、預設攜帶身份，建構以身份為基礎設施安全層的架構。我們在了解整個Google BeyondProd、Amazon CloudAuth以及Alibaba ZTPA（Zero Trust Prod Access）之前，還是講一下各家的基本架構格局。Google是2015年公開了他們的架構Borg容器化的（論文位址：https://research.google/pubs/pub43438/），Borg可以了解是現在Kubernetes的Google内部版，基本上都是基于容器、容器編排、在離線混部、資源統一排程等次元的技術。也就是說Google内部大部分都是部署在容器上的，Google開始發展了容器，發現需要容器編排，容器編排之後發現使用率比較高，需要進行在離線混部，後來在發展到整個Google的統一資源的排程一步一步發展的。
同時Google非常重視安全架構，也就是在Borg的過程中涉及了ALTS（在容器層上建構了一套基礎設施安全層）， 預設開啟加密mTLS、預設針對gRPC進行鑒權和授權以及預設身份綁定實體（人、機器、容器）等，同時Google為了提升安全性，把可信計算也加入了其中，為達到的目的就是保證整個身份體系中整個ALTS根證書的安全性，零信任+可信的架構是未來一個非常高安全等級的必然之路。
下面講一下Amazon的架構。
Amazon是電商業務，他們上雲之後使用了雲的EC2等，他們的服務都是基于EC2的是以他們的基礎設施安全層，是建構在EC2上的，并不是容器化的。簡單來說Amazon CEO Jeff早在20多年前左右就推廣了SOA化，SOA化帶來的好處就是所有的服務都是微服務的，API化的，是以Amazon維護了雙十億甚至上百億的關系，每次服務要進行通路另外一個服務的話，是預設都需要進行申請、授權和鑒權的，并且把身份傳遞到零信任守護程序，詳情見下圖。阿裡巴巴的做法是Google和Amazon的一個結合版，通過基于集團上雲雲原生化之後做的零信任架構，同時也要支援部分非容器化的業務，形成混合态生産網零信任。詳情可以參考下圖。Google是基于ALTS+證書+全鍊路Ticket機制，Amazon是基于SOA化的API網關建構的安全基礎設施層，阿裡巴巴是混合态、四層和七層建構的基礎設施安全層。
2、全鍊路加密
上面雲平台和雲租戶面臨的風險的時候講到了，在網絡上美國是有能力來監聽海底光纖的，是以明文存儲我們也看到了斯諾登曝光的棱鏡計劃、Xkeyscore等項目的威力了，是以國外很多雲廠商的安全性都做的非常高，他們不但要防禦國外的APT攻擊，還要防禦具備頂尖攻擊能力的美國。是以不管是Amazon、Azure、Google都有很系統化的針對這塊的防禦和檢測手段的。
首先說一下Amazon，Amazon擁有豐富的資料和令美國垂涎的資料，通過這些資料可以做各種各樣的事情。Amazon的CSO Stephen Schmidt是FBI出來的，是以對于美國的監控手段也有一些了解。而且慢慢的Amazon電商業務也開始慢慢上AWS雲，是以AWS在全鍊路加密方面做了非常多的工作。下面的圖可以看到整個AWS全鍊路加密的層次。
第一層實體層進行了實體的光纖的加密使用AES-256算法。
第二層資料鍊路層使用了IEEE 802.1AE的MACsec AES-256加密，這裡還是要重點提一下MACsec的加密方式，MACsec的前提是加密AWS的流量是在營運商網絡上進行傳遞的，預設不相信經過營運商的網絡的安全性，另外一個假設就是如果僅僅是應用層加密的話，有可能美國還可以通過破解存儲資料的方式來解密部分流量，是以AWS是進行了多層加密方式來保證安全性的。這種主要是為了防禦AWS自身的業務被監聽和資料破解。另外AWS的商業化思維是非常強的，AWS目前在Direct Connect等客戶接入網絡上，也可以使用MACsec的技術，保證10G和100G網絡的安全性，提升因為IPSec流量超過10G而帶來的性能問題。
第三層就是網絡層，針對VPC内部的流量也進行了加密，VPC一般采用Vxlan技術，預設情況下是明文傳遞的，是以AWS針對VPC的底層加密解除安裝到Nitro裸金屬上，這樣的情況下針對Vxlan的流量也是進行加密的；同時跨Region之間的Peering網絡組網也是進行鍊路加密的，同時針對客戶采用的Amazon VPN等使用IPSec等協定進行的網絡連結也是進行加密的。
第四層就是傳輸層包括Amazon s2n、NLB-TLS、ALB、CloudFront、ACM Intergration等也進行了加密；
第五層最後一層也就是應用層包括AWS Crypto SDK和基于KMS的服務端加密等應用層加密方式。
Google的方式稍微跟AWS有一些不一樣的，Google的網絡安全假設也是基于網絡資料流向經過的途徑進行流量加密的，例如Google認為網絡如果經過營運商的話就一定要采用加密通信方式，在Google可控的内部DC（Data Center資料中心）的話，就是可選擇加密也可以不選擇加密，但是預設情況下一定要進行鑒權的方式提升安全性。
Azure跟AWS有一些雷同，也采用了全鍊路加密的方式，具體的不過多贅述。主要總結一下，其實就是橫縱兩層加密方式，縱向就是TCP/IP傳統的層次，另外橫向的就是客戶側入->雲廠商内部->客戶側出的邏輯，而為了對抗國家級的攻擊，客戶側入->雲廠商内部->客戶側出的邏輯就是全鍊路加密的。這是一種非常值得學習的架構和思路。
3、雲的安全縱深防禦體系
其實在我跟很多大型客戶、相關的評測機構聊的時候，大家都普遍回報一個問題，那就是雲安全的縱深防禦體系到底是什麼樣子的？邊界上部署了WAF、DDoS，然後被突破之後就是VPC之間的隔離、流量監控等、資料出方向進行控制等就是縱深防禦體系了？
那肯定不是的，我來講一下我心目中的雲的安全縱深防禦體系。
我實踐下來的縱深防禦體系是第一點規範和安全政策，規範、安全政策先行，定義好流程、紅線、安全規範和你到底解決什麼問題；第二點準入機制和統一賬号身份管理：雲産品接入、内部員工體系、資源的開通、身份的生命周期管理要進行統一管理；第三點賬号管理：針對内部賬号進行詳細的組織管理、分層管理、權限牢籠、IAM落地、審計、通路行為等；第四點網絡安全縱深：在雲的邊界入口處設定縱深防禦隔離VPC，把WAF、RASP、CFW、全包捕獲、NDR、安全生态産品等防止在類似傳統的DMZ區域中，經過這個區域到達背景的業務，另外一點VPC也要按照業務進行詳細的拆分，通路雲産品的時候有對應的PrivateLink通路；第五點就是這次不詳細展開的ISAM（Infrastructure Security Assess Management基礎設施态勢評估）；第六點是最終的應急響應等安全營運工作。詳情見下圖：
這個圖大家可以看到比我在《鳥哥談雲安全》第三篇中架構進行了進一步的更新，因為逐漸的開始清晰了。
我所認為的雲安全終态安全架構，首先企業、政府、金融客戶必須要有規範和雲安全執行政策，規範就是定義清楚了具體要做哪些，安全政策就是要做到什麼程度，落地的架構就是最終實際效果和營運的目标是什麼。安全規範和安全執行政策包含了雲安全的方方面面，最主要的就是賬号管理、雲産品準入标準、資料安全以及合規以及基礎設施安全等。分的領域涵蓋系統安全、雲上網絡安全、應用安全、雲賬号安全、資料安全、雲産品安全、供應鍊安全和安全生态。
我舉一個例子來看一下，賬号安全的設計。
首先第一步雲産品安全要有對應的準入标準，隻有允許客戶允許的雲産品才能準入，包括IAM、日志記錄、API調用記錄、組織管理的支援和覆寫、Tagging标簽管理、資料安全存儲标準等等，這個是跟FedRAMP學習的，美國FedRAMP就是要卡住雲産品一點點的進行接入準入的，讓雲的客戶使用安全的産品。
第二個就是開發小二擁有的身份和裝置的辨別，可以參考零信任章節的内容，這裡不再贅述。開發小二通過零信任通路OneCloudIdentity平台，OneCloudIdentity平台具備賬号管理的各種能力，包括組織管理、統一釋出的平台、統一的權限授權管理、生命周期管理、賬号回收機制等。
這裡介紹一個組織樹管理，這個能力還是非常重要的，通過組織樹管理，我可以給企業設定一個Root根賬号，這個根賬号預設不允許通過控制台直接進行登入，需要設定MFA登入方式，沒有根AK密鑰。同時Root根賬号也可以設定一個SCP（Service Control Policy），SCP主要是來設定權限牢籠的，就是說主賬号的權限沒辦法超過這個權限。Root賬号下面可以設定Core Account賬号，主要用來實施OneSOC、基礎設施元件等，例如可以通過OneSOC來收集每個雲賬号的小SOC的資訊，進行統一的處理和響應。還可以針對其他VPC的賬号設定基礎設施元件，例如DNS、漏洞掃描、YUM包等等。Root賬号下也可以設計一個縱深防禦的體系賬号，用這個賬号來部署WAF、RASP、Cloud Firewall雲防火牆、全包捕獲、NDR網絡檢測和響應以及安全生态的産品也可以進行部署。其他就是業務級的賬号來部署具體的業務了，預設情況下不管是Core Account、縱深防禦Account還是業務Account都可以來進行SCP和IAM的雙層IAM限制。在VPC裡面的業務，也可以針對雲産品和自身的一些比較重要的應用使用PrivateLink來做限制，僅允許一個更小範圍内的通路，設定PrivateLink的網絡牢籠。
最終通過規範和政策知道自己要解決什麼問題，利用賬号架構、網絡縱深防禦、應用安全、網絡牢籠、權限牢籠建構了一個我認為的雲的真正的網絡安全縱深防禦體系。這個必然是國内雲廠商要做的很痛苦的路，畢竟目前大家對于雲的組織管理的重視程度還是略有不足和需要提升的，當然也有其他很多的安全項例如資料安全等，這裡不再一一展開，但是從縱深防禦體系角度來說安全規範、賬号體系、VPC隔離體系、縱深防禦體系、權限牢籠體系設計的已經比較全面了。
4、資料安全體系
其實使用者上雲之後，如果針對自己的雲資産管理的不當的話，會造成很嚴重的資料安全洩露風險。我個人其實就在給國外雲平台漏洞授權挖掘的時候，發現了雲廠商的資料庫白名單繞過漏洞導緻竊取資料、利用AWS S3和Azure Blob進行對應的雲廠商自身的資料洩露等（漏洞已上報）。
舉例子來說，首先某CSP上雲之後由于自身的代碼開發、編譯、上線等需求，直接購買了Azure Blob、AWS S3等對象存儲來存儲自己的開發編譯的中間代碼。首先從公網環境來看Azure Blob、AWS S3沒有直接進行列舉所有檔案和目錄的漏洞，也直接擷取不到相關資訊，但是經過分析找到了某CSP的這個代碼釋出平台，進行了JS的分析，掌握了采用Azure Blob、AWS S3存儲代碼的邏輯和版本，例如https://commitfiles.blob.core.xxxxxxx.net/coreService/2.3.0.2/UserAccountService.coreService.manifest，這個Mainfest裡面包含了所有的這個元件相關的編譯下載下傳位址，這樣就完美掌握這個某CSP企業的比較核心的編譯資訊了。
是以大家可以想象一下自己使用這些資料庫和存儲元件的時候，是不是也沒使用Private這種模式，也許大家會認為資訊存在不對稱不會被洩露，但是實際情況呢。講了這麼多，今天不講資料安全的體系，隻講一個AWS、Google都在提倡的一種減少和杜絕資料安全風險的一個可以看似很簡單，但是非常有效果的資料安全架構，那就是AWS CSO Stephen Schmidt提出的Data And Human Don’t Mix以及Google提出的Zero Touch Prod和Zero Touch Network。
AWS提出的DHDM的思想，主要是為了減少人通路資料的直接機會，這是一種思想，核心是自動化能力。利用自動化能力、工程化能力、開發能力、變更管理等來減少人通路資料的機會。
例如在CI/CD開發階段，源代碼進行自動化的人員Review，一旦有人30天沒有開發代碼或者開發的代碼突然增多和變少，都會出發一些行為異常，利用行為異常發現可能存在的一些風險，把安全隐患左移和掐死到腹中，這樣的話惡意代碼和有漏洞的一些代碼就很難釋出到線上，真正做到不打擾研發并且真正的左移。
開發階段的源代碼編寫階段之後，來到了Build階段，這個階段會進行自動化的黑、白、灰盒的測試，保證漏洞掐死在Build階段，沒辦法釋出到生産環境，這些全部都是自動化的。
過了Build階段就來到了Release階段，所有的釋出必須通過釋出系統進行釋出，人是沒有辦法直接登入系統進行直接操作的，這種行為是被嚴格禁止的，也就是說Release階段的釋出的二進制、部署的位置、SLB的負載均衡、雲賬号的權限配置、安全産品的部署等等，全部都是通過IaC和PaC進行的，IaC就是基礎設施既代碼所有的部署都是Json和Yaml，專門由釋出系統來進行解析和釋出。PaC是安全政策代碼，所有的安全政策和配置全部都是通過政策來進行部署的，例如IAM的政策、雲防火牆的統一配置政策等。
Release之後來到了維護階段，這個階段同樣通過自動化的釋出跟蹤變更系統，來跟進變更，處理變更，人是沒有權限通路SSH、RDP的，全部都是通過釋出變更系統來處理，但又極其特殊的一些場景需要登入使用者資料的生産系統，需要利用通路透明化，一方面内部進行留存時候調查驗證或者也可以利用Google Access Transparency這種方式來透明給客戶針對資料的通路。AWS的思路相信大家都比較清楚了，AWS的核心就是減少人通路資料的機會，就是利用在開發生命周期、運維生命周期中不斷的增強自動化能力，有資料通路的進行審計和通路資料日志透明化給客戶的方式來搞。
Google Zero Touch Prod和Zero Touch Network都有異曲同工之妙，這裡講一點Google的不同：Google Zero Touch Prod采用了Security Proxy的方式來針對指令進行授權，并且針對Googler通路員工的管理采用了Group管理的方式，目前國内還是RBAC的管理方式，個人感覺使用Group組管理來說會更加的友善，針對在職員工的轉崗、調整等有更好的管理方式和權限管理模型。另外分析一下Azure為了解決資料安全問題而設計的運維安全體系：
① 運維辦公終端安全：System Center Endpoint Protection、Microsoft Endpoint Protection、Microsoft Defender；
② 限制來源（SAW）：通路Azure自身的服務需要特權安全終端，SAW包含IP白名單、TPM、指令白名單等等一系列的手段；
③ MFA：通路Azure自身的一些管理的服務需要Redmond Smart Card、Windows Hello PIN等高等級的認證手段；
④ 按需通路（JIT）：Just In Times按需通路對應的主機，對于Azure平台服務如果員工需要通路客戶的資料，客戶可以授權JIT Support操作；
⑤ Device認證：在2020年7月增加Device認證，目前支援了更進階别的Intune、MDM、MAM等內建裝置管理方案，多層确認：确認使用者憑證、确認裝置簽名、确認裝置證書、确認裝置自身；
⑥ 其他Passwordless認證：FIDO2、Windows Hello PIN等等手段，很明顯的趨勢是Azure不信任SMS，SMS認證級别很低，高等級不會用；
⑦ 通路政策風控（Condition Access）：針對登陸的風險，使用者層面風險、裝置層面風險來進行決策，來決策是否通路IaaS、PaaS、SaaS、IoT、智能裝置、Xbox、On-Permises等應用；
⑧ 預設安全：Azure存在Leagcy認證，可以讓攻擊者采用PasswordSpary來進行暴力破解，這種攻擊占比60%-70%左右，Azure提供預設安全選項一鍵屏蔽Leagcy認證。
有些時候Google也不一定神化，其實有些時候是技術架構倒逼安全架構的更新，先有了容器自然出現了容器編排進而出現了Borg，有了Borg的管理過程中遇到了node的管理，發現需要一個信任根來做mTLS的認證，出現了Titan，上層業務在慢慢完善BeyondProd，再進一步完善研發體系成為BAB，另外一套就是說所有的應用有統一的Identity，這個Identity是兩套外部使用者一套，内部的開發、運維等相關人員一套也就是所謂的OneIdentity，打通研發、營運、SRE等，其實做這些架構最終目的是解決内部資料安全問題。
理論上資料安全體系在内部也進行了卡點和收斂，使用者的資料通路、應用通路都有限制也就是全鍊路Ticket或者說全鍊路Token，用來說微服務的預設權限驗證。有了Identity之後也出現了RPC的鑒權體系，統一的身份、統一的鑒權，每個微服務入口鑒權，出口轉發Ticket，直到最後一個業務的處理完成回報資料。因為Google遭遇的Aurora行動，導緻内部架構進行了更新，人的通路通過BeyondCorp解決，服務到服務的通過BeyondProd解決。
是以安全架構做的是不是世界第一的，還是在基礎設施轉型的時候是否進行了對應的安全架構更新，安全架構更新之後是否能夠持續的疊代和完善，國内的安全圈還是要踏踏實實做深入的基礎設施安全技術，而不是過于浮誇追求熱點名詞和PPT型産品的現狀。
第四部分：雲安全技術亮點
1、可信/機密計算
提到機密計算的發展，就不得不提Microsoft微軟和Intel的合作，小道消息微軟為了提升使用者的資料安全的體系，讓使用者更信任公有雲，就跟Intel進行了戰略合作，其實就是針對Intel SGX進行了詳細的設計。這真是一個晶片的安全能力改變了一個行業的資料安全的典型案例，是以這個技術首當其中的成為了最具有亮點的技術。
發現微軟搞這件事的時候是拜讀了《VC3: Trustworthy Data Analytics in the Cloud using SGX》，這篇論文是在2015年微軟釋出的，當時我記得清清楚楚，這篇文章的釋出的時候，Intel SGX還有諸多記憶體限制，沒有辦法大規模的利用，當時我也根據VC3這篇論文，在阿裡雲的城市大腦項目中，跟諸多大神（不一一列舉）進行了産品原型的孵化，當時在N個星期内，學會Intel SGX的SDK的開發流程，跟Hadoop進行了整合，跟DataX資料導入導出流程進行了整合，最終完成内部産品“交換寶”原型設計。
當時還是非常興奮的，因為從設計流程、到實作細節都是親自上手寫C++代碼、JAVA Native Library C++代碼。當然産品是做出來了，但是也付出了慘重的代碼。最慘的是一行代碼，一個緩沖區溢出一個指令執行，至今都是無法被超越的經典（我代碼安全和SDL還不錯的，隻是趕時間）。
當時也做出來了一些有趣的産品，叫做“交換小寶”，用來解決一些離線的威脅情報對客戶輸出的問題，客戶可以拿到全量的資料，但是都是通過SGX進行加密的，密鑰也進行保護，在對于威脅情報手機号和IP等枚舉上也做了限制，當時覺得還是挺牛逼的。微軟提出Azure Confidential Computing主要是為了解決資料在使用過程中的安全性，讓CSP雲平台無法看到對應的資料。
當然這裡也要提一下阿裡雲，僅僅同步一些公開消息：擴充加密計算延展到FPGA講機器學習模型和資料相關的計算運作在可信環境、跟Mellanox釋出智能網卡加密計算，實作可信網絡、布局SGX開發棧釋出Graphene Golang解決方案、舉辦SGX應用創意大賽等等，這些并不是全部，近兩年也有了更多的發展、國内首發了公有雲可信執行個體、釋出業界首個基于SGX2.0和TPM的可信虛拟化執行個體給高安全等級客戶使用：https://mp.weixin.qq.com/s/v9yklMWSN-KPNxtvj_mEYw等等，各位如果感興趣可以自行搜尋。
其實很明顯的微軟、Google、AWS等已經不滿足僅僅采用Intel SGX架構的東西了，更在深入布局AMD SEV、ARM TrustZoom、RISC-V Sanctum等，持續擴大基于機密計算/可信計算的技術深度和對應的安全生态。
提到安全生态，這個是一個利用技術來解決資料安全信任、資料使用過程中的安全以及可以引發一個安全生态的技術，例如安全生态可以通過實作Intel SGX的資料安全解決方案，實作資料安全交換，資料使用過程中的安全性等等廠商，這些廠商可以開發雲上各種客戶的場景性的資料安全問題解決方案和産品，來增加雲上行業的粘性。
下面講一下做的比較好的Azure的一些應用場景，Azure Confidential Computing nodes on Azure Kubernetes Service（AKS）這個功能主要是指通過底層機密計算底層通過硬體支援的SGX的受信任可執行容器環境來保護資料不受其他應用程式、雲的管理者或者CSP服務提供商的影響。通過AKS這個能力，可以将容器應用程式定位為在隔離的、受硬體保護的和可證明的環境中執行。說白了就是提供了Confidential Container執行個體，把程式和資料跑在這個機密容器中，最終保證資料安全效果的，防止黑客、雲的管理者來搞。
Azure Confidential Computing virtual machines主要是在虛拟機執行個體上使用SGX機密計算，說白了就是把硬體SGX透傳到了虛拟機中形成了vSGX架構，讓虛拟機可以在實體機使用SGX一樣在虛拟機使用。SQL Server Always Encryted with secure enclaves主要是給Microsoft SQL Server提供機密計算的功能，進行資料使用過程中的安全。如下圖所示：
用戶端明文資料給到SQL Client Driver，SQL Client Driver使用加密算法把資料程式設計密文，密文進行計算的時候把資料放到基于SGX的Enclave中進行處理，在Enclave中是明文的，但是這塊記憶體區域還是加密的，是以無法通過Dump Memory擷取到資料。
總體來說基于Intel SGX還是AMD、ARM最終的重要作用就是讓客戶的資料可以安全上雲，保證資料運算過程中，雲廠商也是無法擷取裡面資料的，雲廠商的運維還是管理者都是無法直接檢視客戶的資料。當然對于雲的客戶來說，在使用SGX進行編碼的時候，密鑰的管理、應用程式的安全還是要非常重視的，如果SGX Trust的程式代碼遭到洩露還是有風險的，是以雲的客戶要針對SGX的程式進行重點保護的。當然說了這麼多，機密計算也不能萬能的，這個技術本身隻是解決了一些信任的問題，是以雲的客戶在選擇的時候要謹慎篩選。
另外一個點要說的，就是國内目前都在搞信創，基于國産晶片的機密計算還是要加速的，畢竟這個技術如果國産晶片非常成熟的話，對于提升信創雲的安全性來說還是有一定提升的。
下面講一下我所見到的可信計算布局比較好的廠商。
Google的可信體系也是有發展曆程的，首先是Google為了增強整個安全體系，開始落地内部的可信計算，也就出現了大家熟知的Titan晶片（技術細節下面聊，先把發展曆程搞清楚）。後來随着Titan和可信技術的深入覆寫落地和技術的完善，逐漸開始在Google Cloud Platform開始推廣，出現了基于Titan的Shielded VM執行個體。
介紹完了發展，再分享一下他們使用的場景。内部的基于Titan晶片做的可信主要是落地場景有幾個，解決固件的安全風險、減少Bootkit木馬，個人覺得最重要的就是在Google 生産網零信任中的ALTS中來通過安全啟動過程驗證Google系統軟體的完整性，并基于受支援的安全微控制器硬體（Titan）運作。可信完整性檢查包括 BIOS、BMC、引導加載程式和作業系統核心上的數字簽名驗證，并且在Google每台機器均具有通過可信系統（HINT）預配的 ALTS 憑據，并且隻有在 HINT 已驗證機器啟動成功後才能解密。這樣保證整個Google生産網零信任BeyondProd的安全性，因為Google是識别Borg容器上實體機的身份的，用來做身份的辨別。作為信任傳遞的根，來逐層驗證和傳遞信任。
對于在Google Cloud Platform上的Shielded VM主要是針對Google雲上的高安全等級客戶來提供的進階安全執行個體，主要解決以下3個問題：第一個就是保護虛拟機遠離高等級威脅，主要解決的威脅包括内部惡意人員、客戶固件、核心漏洞等。第二個就是確定Workload可靠可驗證，提供安全啟動以及度量啟動功能，保護虛拟機能夠防禦Rootkit、啟動級惡意軟體和核心級惡意軟體的威脅。第三個就是提供密鑰管理和防重播攻擊，生成和保護的密鑰存放到虛拟機的vTPM中，并且隻有驗證過完整性之後才會被調用。
其實另外一點就是可信執行個體除了提升安全性之外，還可以讓生态在上面長出來各種各樣的針對客戶問題，解決客戶資料安全問題的可信生态市場。目前的市場的一些情況如下：
Azure雲市場Fortanix、Anjuna、Anqlave大概17款産品；Google雲市場Equinix等，目前從國外雲市場來看，目前可信計算的安全生态并沒有起來，我個人還是非常看好這個領域的。
但是最後還是要在提醒一嘴，機密計算在保護敏感資料方面是非常有用的，但是在使用的過程中也要考慮硬體的安全漏洞，包括SGX自身以及CPU的漏洞，例如某些漏洞可以利用側信道漏洞攻擊，竊取SGX保護的密鑰和程式。
2、虛拟化安全防禦技術
從上面的圖我們可以看到Google Cloud Platform的可信體系，大家應該可以看到一個非常重要的技術能力，就是各家針對虛拟化逃逸所做的各種努力的工作。
今天我們講解AAG到底如何做虛拟化安全相關的技術工作的。
先說Google，Google首先會針對KVM削減攻擊面，主要包括Fuzzing和手工的漏洞挖掘，Google這塊也是非常厲害的，發現了為數不多的一些KVM的嚴重漏洞，證明了其實力。另外現在主流的雲廠商都在使用QEMU來做自己的虛拟化的硬體模拟、網卡、音頻、USB等裝置進行互動，因為QEMU曆史上出現了大量的逃逸漏洞，是以Google選擇了一條跟其他雲廠商不一樣的道路，他使用自研的類似QEMU的元件來替換掉了QEMU，并且從Google的安全架構經驗來看他認為虛拟化是一定會被逃逸的，是以他們在類似QEMU的元件上啟了沙箱，大家可能覺得這個技術也許不是特别神奇，但是大家可以想一下，雲計算的性能、穩定性都是有極高要求的，可能損失1%的CPU就會對性能造成巨大的損失，而且從收入角度來也會影響收入，也許1%的性能小号，就要投入上千萬美金的硬體投入和損失上億的收入，這個真的不是誇張的，這個是我們評估過的。是以這一點來說還是非常牛的。對工程化、穩定性、安全性都有極高的要求，這個也是我唯一看到在虛拟化層做沙箱的雲安全廠商。
第二家就是Azure，Azure的虛拟化架構跟其他家都有很大的不同，Azure采用的是Hyper-V架構，在Hyper-V架構的核心幾萬行代碼中Azure完成了代碼的形式化驗證，保證虛拟化核心子產品的真正安全性。Azure工程化也是世界級的，我曾見過Azure CTO示範虛拟機在實體機上跑，實體機直接藍屏之後，虛拟機沒有任何變化的繼續跑，可以進行熱執行個體的能力，而達到不影響運作執行個體的結果。當然這個僅僅是一個DEMO示範，實際的推廣和覆寫度還是需要持續觀察的。
AWS來說就比較體系化一些，下面的圖就是我總結的整個虛拟化安全的體系化的架構。詳細的内容就不過多解釋了。各位一看就懂了。
第五部分：總結
感謝大家耐心的看完我這個長篇大論，我基本上梳理了一個星期左右，總感覺還是不盡完善。沒有真正的講透徹了清楚，如果各位群裡的大佬有疑問，也可以盡情的提問。希望在交流的過程中能夠把雲安全的風險、安全架構和細節的安全技術聊透徹。分享結束了，感謝大家。
---------------------------------------------------
問答環節：
Q1：例如在CI/CD開發階段，源代碼進行自動化的人員Review，一旦有人30天沒有開發代碼或者開發的代碼突然增多和變少，都會出發一些行為異常，利用行為異常發現可能存在的一些風險，把安全隐患左移和掐死到腹中，這樣的話惡意代碼和有漏洞的一些代碼就很難釋出到線上，真正做到不打擾研發并且真正的左移。有什麼好辦法知道開發人員留了後門嗎？
A：感謝您的提問。其實個人感覺留後門這件事整體上來看還是有很大難度的，後門一定是執行指令嗎？能不能寫一個周遊ID竊取資料的API接口呢，因為我确實在上家電商的時候遇到過這樣的問題，後門有可能是專業人做的，也有可能是非專業人做的，有各種别有用心的議題。是以我認為代碼留後門這件事是一個體系化的事。講一下純技術層面的，國外就是進行Double Check和Peer結對程式設計雙向Review的，最近大團隊内部的人面試了一些國外雲安全架構師，他們就是純人工代碼稽核，當然不是安全Review，安全Review有白盒、黑盒、灰盒等手段，是以人是一種避免的方式，另外自動化的規則稽核也算一種，可以根據一些重要核心的業務來進行定向針對性的檢測，個人感覺這是一種營運+安全技術能力的綜合搞法。
Q2：鳥哥你怎麼看 PA 家的PRISMA 在頭部雲廠商瘋狂疊加安全能力的情況下, 第三方安全廠商空間？隻談美國市場, 不談國内。
A：謝謝李總的提問，問的确認很尖銳，因為說實話國外安全廠商的代表PA、CrowdStrike都在轉型雲安全，大家也可以看到近幾年，PA和CrowdStrike在瘋狂的收購跟雲安全相關的技術，包括微隔離、容器安全等等。是以我不好說國内的，我僅代表個人觀點，從我的認知，我覺得未來是一種合作的模式的，例如PA、CS第一點可以做多雲的安全，AWS、Google、Azure等多雲安全，是以這是安全公司的一條路，第二條路就是跟雲廠商正面開始PK，我也不忌諱，現在是市場經濟，誰牛逼就用誰的，全部聽客戶的，但是我認為做好的産品，不管誰做，能解決客戶的問題就是好的安全廠商。
---------------------------------------------------
Q3：感謝鳥哥分享，請教一下，現在幾個csp都提供k8s接口（eks，gke，aks）和容器接口（aecs，ce，acs），這幾家不知道誰的安全成熟度比較高一點?
A：我個人感覺K8s這塊都各有優勢，但是我個人還是看好Google GKE和Google Anthos，因為不管HSBC是混合雲還是私有雲，都能夠很好的支撐您的業務，但是這裡确實也有一些問題，雖然Google的能力可能比較好一些，但是我覺得可能您們還需要選擇專業的容器安全廠商，例如TwistLock、Aqua、Nuevector以及國内的很多容器的廠商，是以我覺得安全成熟度最高的就是Google GKE，但是容器安全要選擇專業的廠商更加體系化。容器接口個人還是推薦成熟度更強的，符合自身業務的容器接口。
Q4：感謝鳥哥分享，請教一個問題，從你的落地實踐經驗上來看你覺得AAG這幾家雲廠商的安全之路哪個更适合國内企業去對标，最大的潛在挑戰是什麼？
A：這個問題我說的深入一點，我也說說個人觀點，華為雲從我的角度來看一定是要學習Google的，因為Google的安全體系最深入，最成熟，從個人觀察角度來看華為雲是被美國認為是關鍵基礎設施雲的，是以NSA和CIA會針對華為雲進行各種想不到層面的攻擊的，包括晶片層面、包括作業系統層面、包括OpenStack開源軟體層面和其他開源軟體層面等等，是以一定要在BeyondProd、零信任、基礎設施安全、晶片安全、OpenStack安全、還有5G安全上，因為我了解5G已經慢慢上了雲要進行大的布局和基礎設施安全的變革和提升，是以我認為基礎設施安全最好的可能就是華為雲，這個是因為他可能會遭遇頂尖攻擊的思維決定的。
---------------------------------------------------
Q5：問一個問題，AWS的SOA化做統一API平台，Google做borg容器化，從成本、實施難度、營運難度和實作效果而言，那種對安全來說更友好？容器的無狀态優勢，在安全層面是否反而添加了管控和監測的難度？
A：感謝謝總提問，說真的，我個人感覺都很難，成本、實施難度、營運難度和實作效果都很難。因為這些架構是企業的基因，是很難學的，是以個人感覺還是貼近自身業務和技術發展的安全才是最好的一個辦法，而不是學人家架構更新、學人家SOA化，這樣對于組織來說是十分不利的，感謝謝總的提問，我還是要正式說一下的，我隻是想給大家一點點的輸入，并不是希望大家和業界來抄這個東西。
---------------------------------------------------
Q6：謝謝鳥哥，幹貨滿滿，開拓了雲安全的視野！也問個問題，雲安全縱深防禦方案，多涉及基礎架構安全，落地成本太高，對于普通企業私有雲安全建設投入的資源順序和建設優先級的建議是什麼樣的？
A：确實我分享了非常多的基礎設施的安全的亮點，但是說實話确實落地成本太高了，從我自己營運好幾朵國家的大的部委的雲安全架構來說，而且我也是落地的私有雲項目，包括群裡也有我的一些客戶和甲方爸爸，是以我認為第一點是租戶層的安全，一定要保證您企業的代碼的安全流程，DevSecOps要一定夠完善，第二步就是假設這些代碼是不安全的，是以我要部署WAF、DDoS和RASP，第三步就是我要利用私有雲做好VPC的隔離網絡的隔離，第四步就是我肯定會假設被入侵了，是以我選擇的是雲的SOC，雲的Agent來說威脅檢測和響應，投入對應的營運團隊。雲平台側的，請相信我們這些雲安全廠商，我們會盡我們100%的努力和決心做好底層平台安全。
---------------------------------------------------
Q7：整體的安全建設，都在走基礎設施融合路線，這對于乙方廠商不是一個好消息。
A：确實是的，但是我僅僅代表我個人觀點，我個人希望雲廠商做好底層的安全架構，包括分布式作業系統安全這些能力，底層一定要讓我們專業的團隊和人員來保證底層，但是對乙方來說底層的安全其實很難的，就是xi4oyu總說的不是一個好消息，是以個人感覺租戶層是乙方廠商的一個大可為的地方，雲廠商要開放心态，讓更強的安全廠商接入進來，一起建構生态，為客戶解決問題，為TOB、TOG來一起解決，共同發展和完善。
---------------------------------------------------
Q8：”Release之後來到了維護階段……目前國内還是RBAC的管理方式，個人感覺使用Group組管理來說會更加的友善，針對在職員工的轉崗、調整等有更好的管理方式和權限管理模型。”鳥哥，想了解一下這個組授權模型，後面的資源怎麼配置設定？是歸類嗎還是原來的資源碼管理方式？
A：我來解釋一下Google Group管理的模型，首先企業有員工，現在大家大部分的管理方式還是通過RBAC的方式，你有什麼權限就做什麼事。Google Group組管理，其實變了一種玩法和模式，首先我是一個員工，我加入了運維業務A的Group，這個組的組管理者要進行審批，這個時候組就有了，然後我去通路運維業務A，這個時候運維業務A要維護一套組管理的引擎，也可以叫ABAC，例如例如允許Group Admin來進行通路。我找了個例子：
Example 3-1. Google Tool Proxy Borg policy config = { proxy_role = 'admin-proxy' tools = { borg = { mpm = '[email protected]' binary_in_mpm = 'borg' any_command = true allow = ['group:admin'] require_mpa_approval_from = ['group:admin-leads'] unit_tests = [{ expected = 'ALLOW' command = 'file.borgcfg up' }] } } }
---------------------------------------------------
Q9：誠摯感謝鳥哥的分享。幹貨滿滿，學到了很多新知識。我想問一個對于企業核心商密上雲風險評估和決策的問題。首先是企業上雲必然是趨勢，但對于一些大廠來說，走的是混合雲建設模式，就必然涉及到哪些資訊能上雲，哪些不能上。對于企業核心商密上雲，大廠是有顧慮的，一方面是雲特有的資料安全風險需要去評估、制定政策、執行；另一方面就是雲安全的監管，大家把錢放銀行覺得比家裡安全，那是有一套嚴格的金融監管體系，資料也是高價值資産，但是現在的雲安全的法規及監管對比金融還是要弱一些的，是以企業有顧慮。但是如果企業希望提供全球化的數字化能力，上雲是最快的彈性建設方式。鳥哥有什麼看法呢？您是如何評估的？
A：感謝俞總的提問，這個問題真的感謝，我體會到了您的擔心和顧慮，我也回答一下相關的看法，首先對于企業核心商密上雲來說，資料安全問題是最最重要的核心問題，是以我實話實說，現在階段還是私有雲的階段，是以可以在短期内選擇私有雲來部署，包括金融等機構；您這裡提到了一個核心的問題，如果您的企業具有核心商密的話，在中國的企業也分層次的，如果是中興，我個人非常不建議放到AWS、Amazon和Azure上，這對您企業來說是一個核心的打擊，如果美國政府想要看您企業的一些資料，AAG給了的話，這裡面對您的企業打擊還是很大的。是以在雲安全法律法規監管等逐漸完善的過程中，又想選擇使用雲的彈性，做Global全球的業務，建議您走混合雲模式，公有雲做一些非常簡單和少的東西，不放核心的，如果牽扯到機密的資料放到私有雲上，私有雲和公有雲之間進行非常嚴格的限制和政策，是以這種混合雲的場景，第一層是鍊路加密層，就是公有雲和私有雲的專線是一定要加密的，使用MACsec類似的機會進行加密，第二層就是要保證雙向通路足夠的細粒度，按需通路是非常必要的，第三層就是上面要部署雙向IDS/IPS進行縱深防禦體系，保證流量是可信和能檢測的，第四層就是安全營運和響應，保證第一時間處置威脅。更重要的是要對您這邊的私有雲的資料安全做到Cloud DLP的詳細分析和看，保證絕對的資料安全。
---------------------------------------------------
Q10：感謝鳥哥，想請問一下，在使用雲上産品時，除了 WAF 和防 DDoS 的配置之外，運維還需重點關注那些問題，能降低或減少被攻擊的風險？
A：WAF、DDoS是解決應用層的和網絡層可用性的攻擊問題，從攻擊面開始分析，首先要先把開放出去的端口、業務、指紋進行分析，把所有的WAF和重要核心的業務進行DDoS的防護，保證核心業務的高品質。第二步就是要假設會被入侵，WAF說實話也可能會被繞過，是以要在主機、資料庫等進行檢測和防禦，針對入侵行為進行快速的自動化響應等，然後保證核心的資料不被洩露，這樣能夠算一個比較完善的工作。
---------------------------------------------------
Q11：在混合雲中，私有雲和公有雲的一起使用使業務連接配接或者共享，這個過程中有什麼特别要關注的嗎？
A：這個是一個非常好的問題，因為現在金融機構和企業機構都是混合雲形态，是以會存在私有雲和公有雲一些使用的場景，是以這種混合雲的場景，第一層是鍊路加密層，就是公有雲和私有雲的專線是一定要加密的，使用MACsec類似的機會進行加密，第二層就是要保證雙向通路足夠的細粒度，按需通路是非常必要的，第三層就是上面要部署雙向IDS/IPS進行縱深防禦體系，保證流量是可信和能檢測的，第四層就是安全營運和響應，保證第一時間處置威脅。
---------------------------------------------------
Q12：感謝鳥哥分享，請教一個問題，雲上那麼多措施，也需要人去營運，那麼哪些方向應該做為重點關注？
A：雲上安全措施非常多，要做的事情也非常多，是以需要投入一些資源，是以可以選擇MSSP雲安全的托管服務，因為這些廠商比較專業，能夠幫助客戶來解決實際的問題；第二個如果企業有一定規模的情況下，就會選擇自己建設團隊，因為雲安全的層面還是非常多的，是以需要關注應用安全、賬号安全、密鑰安全、網絡安全、系統安全等等，是以SOAR自動化響應、TDR（威脅檢測和響應）、應用層的安全漏洞和攻擊面的減少，是重中之重的工作，如果選擇一個重要的就是利用雲的可見性API，來把資産100%管理好，然後防護做上去，自動化營運慢慢用起來，就能保持一定的安全水位。