前言
開始前先說個觀點:企業 IDC 安全實際是雲安全的一個分支而已，這是本文希
望強調的點之一。
其實本文的著力點是雲安全，之所以標題沒說雲安，是因為在多數人印象裡，雲安就是 各種雲平臺的安全，是“雲”的安全，認為企業 IDC 安全什與雲安沒有關係。為了避免這種 誤解，本文標題故意沒寫“雲”，希望通過本文，能讓人更深入全面瞭解究竟什麼是雲安。
雲安相關概念及安全架構的定義
本文要講安全架構方面的內容，也就是怎麼做才能搞定安全這件事。具體開始前，我先 說下什麼是架構。之前我們說過，安全通常分解為三個方面:安全產品、安全運維、安全架 構。
前兩者都是具體實施手段上的細節問題，架構問題回答的是很多人經常有的疑問:如何 做才能搞定安全這件事----這就是架構。
交易所安全其實和傳統企業安全沒有太大差別，企業安全是雲安全的一個分支。雲安全 通常三個方面:公有云安全、私有云安全、企業 IDC。
企業 IDC 安全一定程度上可以合併到私有云安全裡去，不過企業 IDC 安全又有它稍微不 一樣的地方，所以這裡把它和私有云安全分開來作為一個分支。至於混合雲安全，實際是幾 個方面的綜合，不單獨說了。說了這麼多，其實核心就是:交易所及普通企業安全是雲安全 的一個分支。
所以我們從頭來講雲安全，我先解釋下什麼是雲:雲是在對傳統軟硬件產品和服務抽象 出標準接口的基礎上、屏蔽了軟件硬件差異，對外提供基礎性 IT 服務的服務，雲與虛擬化 沒有必然關係，但為了抽象出標準接口，虛擬化是必要手段;同時，物理服務器也未必不是 雲，關鍵看它是 否有一整套的統一對外服務和管理接口。
總結一下就是:雲是一種 IT 設施以及相關服務的交付手段。
公有云、私有云及企業 IDC 安全產品和安全運維的異同
接下來我們就來講講如何搞定雲安全，也就是雲安全的架構問題。
第一，需要搞清楚公有云、私有云、企業內網他們各自的安全問題特性，再針對他們的 異同 點針對性的做出架構設計。
公有云重產品，目前的公有云環境多數是中小企業，他們沒有特別強大的安全運維團隊， 所以更希望安全產品幫它解決所有安全問題。因此，公有云環境實際上對安全產品本身的處 理和防禦安全問題的能力提出了更高的要求。
具體表現在如下幾點:
對主機反入侵產品的效果特別看重。中小企業來說，服務器數量不是特別多，業務也並 不復 雜，安全問題更多集中在服務器被入侵上。所以解決服務器被入侵問題是他們的迫切 需求。
對服務器入侵容忍度低，是因為他們服務器數量少，犧牲任何一臺服務器都可能對他的
業務造成致命影響，所以服務器入侵問題是他們對雲平臺好壞評價的基本的也是最重要的標 準;
對安全服務不敏感，因為安全服務多數是需要被服務對象具有一定的安全運維能力，中 小企 業不具備這樣的能力。比如態勢感知、威脅情報這樣的偏服務型產品，其輸出內容並 不足夠 容易理解，也並不能對企業安全產生直接效果，對中小企業沒有實用價值;
對安全產品的自動化處理能力要求高，中小企業囿於自身能力問題，安全問題高度依賴 安全 產品的自動化處理能力和防禦能力，而且更多體現在實時阻斷能力上;
對資源佔用敏感，公有云客戶多數資源並不充分，且因為認知問題，對於第三方安全產 品佔 用的資源量特別敏感，非常容易因為資源佔用問題而投訴安全產品，或者直接關閉相 關安全 產品。
對安全問題的共擔意願低，一旦出現任何安全問題，客戶通常都把原因直接歸因於雲安 全平 臺做得不夠好，即使很多問題實際上應該是和客戶共擔風險的，比如經多次提醒仍不 修復的 弱密碼和系統的、應用的漏洞等等。
後果就是:
主機反入侵產品應該是公有云環境雲安全的核心內容。公有云環境的安全體系建設應該 把主 機反入侵產品作為重中之重。
功能點實現上，應該儘可能降低需要客戶操作的內容，最好是完全無需客戶額外操作。 這要 求安全產品的設計者對安全問題處理經驗，安全問題對系統的影響，安全問題與各種 服務器 應用的關係等有著極為成熟的理解度。既保證自動化處理的效果，又保證對用戶系 統和業務 產生儘可能小的負面影響。
產品功能表現上，公有云安全更傾向於實時阻斷型功能，數據分析型功能可以適當弱化。
這點來說，公有云上的安全服務型產品更多面向雲平臺自身的運維團隊，為運維團隊的 運維行為提供數據支撐和分析手段，具體產品設計實施方面，就要求這些產品所提供的數據 足夠細化和專業，提供的分析工具和手段也足夠充分，一切以方便運維為前提，反而對自動 化的結果分析沒有太多要求。
公有云的安全運維團隊應該是以改進現有云安產品效果、為雲安產品創新提供支撐為最 終目 標，其運維對象是安全產品，直接目標是讓安全產品發揮其最大功效，並最大程度降 低安全 產品的固有弊端。一切運維行為圍著產品轉是公有云安全運維的基本特徵。
這裡其實就回答了一個問題:公有云運維團隊與私有云、企業 IDC 運維團隊，他們的業 務目標以及做法上的差異在哪。
第二，私有云及企業內網重運維。這裡之所以把企業內網安全和私有云安全一起說，是 因為企業內網可以認為是私有云的一個特殊形態。展開解釋前先要說明，這裡的企業內網僅 指 IDC 生產服務器機房，辦公網絡不在此範疇內。辦公網絡的安全問題是另一個話題， 在 此不做進一步介紹。
私有云和企業內網的不同點在於:
私有云更多指的是雲平臺商通過標準化與個性化的結合，對公眾輸出的、針對具體企業 客戶 一定程度定製過的、與公有云環境物理或者至少邏輯上隔離的網絡及服務器環境，是 toB 的 一個具體的雲計算商品，可以認為是具有定製化特性的公有云商品; 而企業內網實際上是企業自建、自用的機房、網絡、服務器環境，不具有商品屬性，擁有高 度定製化的環境，與企業自身的業務特性高度結合。
私有云和企業內網的共同點在於:
他們都具有相對隔離的環境，使用範圍都僅限於企業自身業務，都針對自身業務做過定 制化 處理，架構設計都不具有通用性，使用者都具有一定的安全運維能力以及一定規模的 安全運 維團隊。這些異同點導致了他們的安全問題特性以及具體做法上的異同。
首先，私有云環境因為是基於標準化雲產品做出的特殊定製，所以私有云的安全問題具 有一定程度的共通性，其安全特性也繼承了雲平臺的一些基本特性，安全缺陷也通常一併繼 承過來。
而企業內網環境因為高度定製化，每個企業根據其業務內容、業務規模、業務特性、企 業特 點等理由，內網環境幾乎不會有任何相同，安全特性和安全缺陷也因此完全沒有相關 性。
其次，因為私有云仍然是在標準化產品的基礎上做的定製，所以由同一個雲平臺提供的 不同企業私 有云之間在運維方式和運維工具、途徑上有相似的地方;在相關安全規則的制 定上也基本遵 循相似的邏輯，引入的安全問題也都有相關性。
而企業內網基於完全沒有相關性的環境發展而來，不同企業的運維方式、運維工具和途 徑， 安全策略的制定與實施，都完全沒有相關性，相關安全問題也是花樣百出。
後果:
首先，私有云及企業內網的安全問題都更重運維。因為基於私有云或者自有機房運行業 務的 企業通常都具有一定規模的安全運維團隊，有相當的安全能力，為通過運維解決安全 問題提 供了可能。對於私有云以及企業 IDC 來說，重運維也是必然的選擇。 其次，這些企業通常都業務複雜且非常敏感，一旦出問題對公司乃至對社會都會產生嚴重影 響，比如銀行。在這種環境下，很難單一通過安全產品程序既滿足功能性需求，又避免誤操 作導致的風險。
再次，企業環境，很多時候可以容忍犧牲部分服務器被入侵，但不能容忍服務器被入侵 後無 法及時發現，所以私有云及企業內網的基本安全目標就是及時發現入侵，至於入侵防 御，通 常更多依賴具體的運維手段。
實際上，在企業環境裡，基於對誤判的低容忍以及“犧牲部分服務器”情況的高容忍，不 建議使用阻斷性的安全產品，以 “監控+應急響應”為主。
接下來講講一般性原則和方案:
A、產品為運維服務。產品存在的意義是為運維提供數據支撐和工具支撐。具體到產品 實現 上，體現為產品幾乎以收集數據、分析數據以及執行運維命令為核心功能，比如日誌 數據的 收集及分析等等。
這裡就體現出了與公有云的區別:公有云更多是產品及研發團對驅動運維團隊，而私有 雲及企業 idc 是反過來的，由運維團隊去驅動產品及研發團隊。
說的粗暴點就是:公有云環境產品及研發團隊會處於相對強勢的地位，運維團隊處於協 作、配合的位置;而私有云及企業 IDC 環境運維團隊處於相對強勢的地位，產品及研發是協 作與配合的地位。
所以比較粗暴的判斷某個公司安全架構是否合理的方式就是:看他們產品研發與運維團 隊的協作與被協作關係就行了。
B、安全問題的處理高度依賴運維團隊以及完整的管理制度、應急處理機制。比如，通 常安 全運維團隊都有 7X24 小時值班的傾向，所有服務器基本都會有實時聯絡人，對服務 器的異 常處理都有一套完善的流程做指導。
這點，在 BAT 貫徹的比較徹底，小公司很難做到，所以我之前也建議小公司儘量不要自 己處理安全問題，找個靠譜點的第三方安全公司比較合理。比如目前的各個代幣交易所，最 好的選擇就是找靠譜的第三方安全公司處理安全問題。
C、高度依賴服務型安全產品，比如態勢感知、威脅情報、掃描器、數據分析平臺以及 紅藍 對抗等運維手段。運維人員做出決策，更多需要藉助這些工具來為自己的決策提供支 撐，同時結合自身經驗和能力，對這些數據加工分析，得出具體策略內容。
但私有云和企業內網在這方面又不完全一致:
私有云環境的運維團隊通常沒有企業內網那麼 大規模，其安全能力也要弱於企業內網 環境的安全運維團隊(前面這些觀點可能有失偏頗， 但很大程度也是事實情況)，最重要的 一點是私有云的基礎設施由雲平臺提供，其運維團隊 對私有云的基本架構邏輯和安全特性 掌握不一定充分，這些事實情況給運維團隊分析數據並 得出結論製造了障礙，所以他們更 多傾向於這些服務型產品一定程度上輸出處理建議;而企 業內網環境的運維團隊通常具有 安全能力優勢，也對自身所處網絡和服務器、業務環境有更充分的認識，他們更多傾向於利 用安全產品輸出的原始數據自行分析得出結論，對安全產品的智能化要求不高。
D、高度依賴安全管理制度。比如對安全邊界的控制(防火牆、內網分區、端口開放限 制等 等)，對操作流程的限制等等。堡壘機、跳板機這樣的措施實際也可以歸類為安全管理 制度 之列。
E、安全措施深度切入業務環境，比如針對具體應用程序做出專門的加固處理，這在公 有云 是不可接受的也無法實現的。
F、防禦性安全產品必不可少，但產品更多是作為運維團隊的安全防禦工具出現的，安 全防 御產品極少會作為獨立的解決方案存在。
總結:私有云及企業內網環境，安全問題的解決以運維團隊為中心，所有安全產品及制 度都為安全 運維服務。
產品角度:核心是搭建一套數據收集及大數據分析平臺，以及一套順暢穩定、易於使用 和事 後追蹤的運維工具;同時，強化服務型產品的研發力度，以運維需求為基本目標，實 現產品 研發與運維的良好協作。
運維角度:重視團隊成員數據分析能力和工具應用能力，重視關鍵數據敏感度;重視紅 藍對 抗等基本運維手段;建立基本的安全管理制度和應急處理機制，有完整的應急處理流 程。
產品與運維在私有云和企業內網安全問題上二者缺一不可，有主理與協作之分，但無重 要度 之分。
產品角度的雲安全一般性設計原則
以上實際更多強調的是運維團隊在“安全”這件事上該如何做。
作為安全架構團隊，除了要做好運維團隊的定位外，對安全產品及研發團隊的工作思路 和團隊定位一樣非常重要。
接下來講講安全產品在“安全”這件事上的具體思路和定位。
首先要搞清楚雲安全各個產品線的具體內容以及其主要作用和協作關係，包括一些要注 意的問題。
以下將要說的產品類型之間並不是同一標準下的分類，所以多個分類間的安全產品有不 完全的重合。之所以會把不同分類標準下的產品同時列出，原因在於每個分類都無法涵蓋雲 安全的方方面面，很多產品無法按同一標準分類，而且以下的列舉也並非是完整的，更多目 的是做演示說明。
1、 邊界防禦性產品:防火牆(主機型，網絡型);WAF(主機型，網絡型)，漏洞掃描 與補丁推送等等。
邊界防禦產品在目前很多人鼓吹無邊界的時代仍然有其不可替代的地位，其意義在於以 較低 的成本解決絕大多數安全問題。完全阻斷邊界安全問題不是邊界防禦的目標，也是不 可實現 的。比如漏洞問題，這是個永遠無法杜絕的問題。
邊界防禦性產品的基本評價標準有幾點: A、不給邊界功能引入故障:比如不能因為裝了 WAF 導致 web 容器掛了，或者資源
佔用率 過高等等問題。
B、 沒有明顯的程序 bug，比如明確設置了 80 端口不允許被訪問，這個端口如果仍
然能被 某個客戶端訪問，這就是明顯程序 bug。這裡的 bug 不包括一些安全效果性問題， 比如未 識別的攻擊類型就不在此之列。
C、安全問題識別率符合預期:這裡之所以不說具體識別率要到多少，這是因為任何一 個產 品都有它的發展階段;任何業務對安全性的要求也都有一個限度控制。只要產品是符 合設計預期的，符合具體業務對安全性要求的，就算合格。
D、產品間功能重合度低:不同的邊界防禦產品間要有明確的功能定位，杜絕疊床架屋; 多 個邊界防禦產品間的“安全間隙”要儘可能低，充分覆蓋邊界安全問題的方方面面。
2、 縱深防禦性產品:所謂縱深防禦型產品，實際上並非指某個或者某些特定產品。縱 深防禦更多指的是安全產品間的協作關係，縱深防禦型產品與邊界防禦產品有不完全的重合 關係，二者考量標準不同而已。
通常，某個具體的安全點，不可能有任何安全產品能做到滴水不漏;而且，基於投入產 出比 考慮，也沒有必要把它做到滴水不漏的程度。
一個產品，通常只解決某個安全點的絕大多數 問題，那些被漏掉的安全問題，並非不 管了，而是需要進一步的其它產品，在更合適的安全 點上予以處理，這就是縱深防禦的通 常做法。
以病毒文件掃描為例:通常以 ReadDirectoryChange(windows 系統)或者 inotify(linux 系 統) 監控絕大多數的文件變動，並予以實時處理;
但是因為這兩種方式都是非阻塞的，所以仍然 有部分文件會逃過檢查邏輯。基於此， 通常會在系統的模塊加載處再加一個阻塞式處理邏輯， 對惡意程序的運行予以直接阻斷。
這個過程中，通過非阻塞的方式處理掉了絕大多數惡意文件，獲得了系統性能的提升; 同時， 又以阻塞式的處理，對可能的極少數漏網之魚予以最後的阻截，解決了安全性遺漏。 這就是典型的縱深防禦思路。
縱深防禦產品的幾個基本評價標準:
A、是否以最低的成本解決儘量多的安全問題:這裡是定性的，具體標準還是要結合實 際情況分析，但基本原則是解決其所在安全點的絕大多數安全問題，個人認為至少解決 80% 以上問題。
B、漏掉的少數安全問題是否有補救方案，補救方案所在安全點是否合理:成本足夠低， 效 果足夠好。
C、 多個縱深防禦產品間功能重合度低，避免疊床架屋的做法。
3、 主機反入侵產品:主機反入侵產品的基本目標是阻斷或者實時發現主機被入侵的行 為，目前市面上這類產品裡用戶量最高、檢測及防禦效果最好的是安全狗系列產品，但是其 缺點在於過於依賴本地行為分析，對大數據分析以及運維支持不足。
除了有 agent 的主機反入侵產品外，還有另一類無 agent、基於網絡大數據分析的主 機反入 侵產品。這類產品的優勢在於不需要侵入用戶主機，用戶體驗好，但缺點在於因為 很多重要 數據拿不到，入侵發現效果實在差強人意。
而且在公有云環境，這種方案對第三方安全廠商實在不夠友好，目前這種方案基本無人 使用。但在某些特定場合，配合 agent 數據也能提高 主機入侵問題的檢出率，比如 DNS 隧 道類木馬的檢測、內網掃描行為等等。
這類產品的基本評價標準為:
A、較高的入侵發現率 之所以不說一個定量的數字，原因與之前說過的一樣，產品的不同階段以及針對的不同
業務，對入侵發現率都應該有相對合理的要求，而不是一律 100%，這樣本身不現實，也不
符合投入產出比的原則。
B、 對於有阻斷功能的主機防禦產品，對發現的入侵事件，其阻斷成功率必須 100%，
否則 產品不合格。
C、 較低的資源佔用，按經驗，1 分鐘平均 cpu 使用率不得高於 0.1%;10 分鐘平均
內存佔 用不得高於 50MB;峰值 CPU 佔用率不得高於 25%，峰值內存佔用不得高於 100MB。
這些定量的數字，你要是問我是怎麼來的，我確實說不出一個靠譜的理由，這些更多來 自於經驗。
D、 系統不得因為裝了主機防禦產品後有明顯性能下降。
E、 可運維性:是否方便運維，是否對關鍵操作和關鍵數據有記錄、可追溯。
4、 應用安全產品:這類產品最廣為人知的就是 WAF，還有諸如數據庫加密產品、數
據庫防注入產品、賬戶防 爆破產品等一系列產品。這類產品通常防禦效果較好，但存在幾 個問題:
A、 深度侵入用戶應用，容易導致兼容性問題和用戶應用穩定性問題。
B、大量接觸用戶數據，存在數據洩密可能性以及用戶隱私等法律問題，通常在接入前 必須 得到用戶授權。
這類產品通常有以下幾個評價標準:
A、 兼容性問題:在其應用領域是否兼容常見應用及其各個常見版本，否則不合格。 B、 是否有不經授權獲取並使用用戶數據的行為。
C、 資源佔用及對性能影響是否在用戶可接受範圍內。
D、 可運維性:是否方便運維，是否對關鍵操作和關鍵數據有記錄、可追溯。
E、 安全問題發現率是否滿足預期。
5、網絡安全產品:這類產品最廣為人知的就是 DDOS 高防了，除此之外還有基於分光
模式的 WAF，以及基於 cname 的雲 WAF 等等。 這裡可以明顯看出，不同分類標準下，同一個產品可能落在不同的產品類型裡。這個問
題在上面有過說明，不必在意。
這類產品通常有以下幾個評價標準:
A、使用複雜度:比如 cname 模式的雲 WAF 因為很多用戶覺得使用複雜而拒絕使用。 B、 檢出率及攔截率滿足業務需求，符合設計預期，之所以用這種定性標準，之前有說
過， 不再重複。
C、 不因自身故障或者其他原因導致客戶網絡接口故障。
D、 對安全產品運營方的資源消耗在預期範圍內。
E、 對客戶網絡接口性能的影響在預期範圍內、滿足業務需求。
6、 安全運維類產品:比如威脅情報、態勢感知、運維工具、掃描器等等。這類產品更
多滿足運維需求，根據雲平臺是公有云還是私有云的區別，會有不同產品要求，一般有如下 評價標準:
A、 數據覆蓋範圍是否滿足業務需求。
B、 數據及時性、使用便利性、詳細度是否滿足業務需求。 C、數據準確度是否滿足業務需求。
D、是否有與之配套的分析、存儲工具。
E、噪音數據的剔除度是否符合預期。
7、雲平臺對各個產品的取捨原則: A、根據公有云、私有云及企業內網的情況，依據上面說過的業務及客戶特點確定產品
重點 和優先級。
B、根據平臺目標和平臺需求以及客戶特點確定哪些產品是要直接面向客戶的，哪些產 品需 要以運維為緩衝然後輸出加工過的結果的。
C、 保證平臺穩定與安全的產品，比如 DDOS 產品必須有且必須與雲平臺同時投入使 用。
D、應用安全類產品因為涉及到具體應用和用戶數據等原因，通常不應作為默認選項， 而應 該根據用戶請求做出處理。
E、 各個產品間應該有協作關係，不能出現孤立的產品點;“安全間隙”應該足夠小，安 全點 應該足夠齊全，但各安全點間必須重點突出，不能平均用力。
F、平臺只做重點的、核心的功能，其它安全功能儘可能開放給第三方安全廠商，形成 安全 生態。
以上內容其實就是對於安全產品團隊的基本要求，我以安全架構的角度分享了:安全運 維該怎麼做，安全產品及技術該怎麼做。
