概述

安全域隔離是企業安全裡最常見而且最基礎的話題之一，目前主要的實現方式是網路隔離（特別重要的也會在物理上實現隔離）。對於很小的公司而言，雲上開個VPC就實現了辦公網和生產網的基礎隔離，但對於有自建的IDC、網路基礎設施甚至自己構建雲基礎設施的大型公司而言，網路隔離是一項基礎而複雜的安全建設。基礎在這裡的意思並非沒有技術含量，而是強調其在安全體系裡處於一個根基的位置，根基做不好，上層建設都不牢靠。

隔離的目標是為了抑制風險傳播的最大範圍，使受害範圍限定在某個安全域內，類似於船塢的隔離模式，一個倉進水不會沉船。從攻擊的角度看，網路隔離可以阻攔攻擊者單點得手後的橫向擴散，防禦者視角更具體的思路可以參考

網路隔離通常分為（1）IDC隔離以及（2）辦公網隔離，除此之外，還有（3）辦公網跟IDC之間的訪問控制。受限於安全策略的敏感性，本文不會披露過於詳細的策略或實現方案。

IDC隔離

以下先從IDC隔離說起，安全做的沒有特點的公司通常是這麼分的：辦公網內部沒有任何隔離，生產網內部也沒有任何隔離。

甚至有些市值好幾百億美元的公司也這麼分。這樣分的結果是對運維比較便利，但從安全來說相當於什麼也沒做。比較普遍的做法如下圖所示（某電商公司的例子）：

首先會在IDC整體上區分公有云和私有云，其次在私有云內部區分生產和測試環境，然後是辦公網跟IDC的隔離。當然這個粒度是比較粗的，實際在每個安全域內部還有更細的劃分，安全域之間設定運維和資料通道，資料在安全域之間流轉時需要脫敏和審計。再來看另一個大型網際網路公司安全域的例子：

裡面更細粒度的定義了OA-IDC之間的通道，即圖中標示為內部運營網的部分，例如通常運維的堡壘機就屬於內部運營網，思路還是把運維通道，資料通道，測試環境都放在了內部運營網，可以理解為整體上就是OA-測試（內部運營通道）-生產，3大安全域。

除了國內主要的網際網路公司，再看一個國際電商和雲端計算巨頭的例子：

辦公網包含測試環境，通過釋出系統與生產環境隔離，生產環境中除了金鑰管理等強制合規性需求外，基本沒有做太多隔離，推測是為了網路資源的彈性考慮，staging可以理解為是CI末端的一個預釋出環境，在全球範圍內會跟雲端計算一樣區分Region（北美、亞太……Region之間幾乎不互通），AZ（Availability Zone，可用區，可以理解為是同一個IDC內有用相同的災備等級）的隔離概念。

基本上上述例子可以代表全球範圍內絕大部分網際網路和雲端計算公司的安全域隔離方法論了。於是，我們吸收各家的優點，整理出一個相對通用的安全域劃分示例，如下圖所示：

在大多數公司，如果安全工作做得認真到位，沒有太激進或者技術引領之類的需求基本上也算OK了。只不過網路隔離這件事天生跟彈性計算是對立的，隔離的越細緻，對於快速擴容、服務編排、資源回收都是不利的。在海量IDC運維環境下，會給追求全自動化資源管理的理念引入障礙。

另一方面，雖然明確定義了很多諸如生產測試分離之類的規則，但在實際的日常使用中往往會有很多問題。網際網路公司的研發不是傳統的瀑布模型，也不一定都有專職的且供應量足夠的測試人員，尤其對於擴充套件中的業務很多流程和規則往往處於模糊地帶，測試環境也未必能滿足所有的測試需求，例如全鏈路壓測等，這些問題帶來的挑戰是安全隔離對業務需求產生阻礙，但是業務又不能中斷，所以會有很多變相操作，例如直接去生產環境測試，從而跳過了安全預設的場景和規則，最後使得隔離看起來有點虛幻。

筆者細數了一下網路隔離誕生於上個世紀，是自網路安全開始就有的概念，產生於一個網際網路並不發達也沒有海量IDC的時代，所以這種模式可能有點區域性（並非全部和絕對）過時了。直到發現Google的模式，闡述了一種全新的思路：不使用基於網路的隔離，而是用應用級別的隔離來實現訪問控制，如下圖所示：

我們從幾個層面詳細分析這一方案。

首先Google這個規模的IDC管理的理念是必須通過自動化管理實現，人肉是不可能的，當然人肉審批ACL策略也是不可能的。叢集全部通過自動化管理的前提是高度的彈性計算能力：所有機器的安裝初始化，上線，應用例項部署，到自動擦除資料下線，回收資源都是自動化的，所以過度的隔離也會抑制生產能力。以前這些自動化工作都通過sshd服務來，且需要root許可權，Google認為這是一個巨大的安全隱患，所以重新設計了一個admin服務運行於所有的VM、容器例項，這個admin服務本質上是一個RPC服務，支援認證、ACL驅動和審計，並且只需要完成工作的最小許可權。相當於原來通過SSH管道執行的命令變成了通過admin服務的一堆RPC呼叫指令，每個引數都可審計。這是Google這套機制的背景之一。

第二點，這套機制能work的前提是：Google的IDC內網只有RPC協議，沒有像其他公司一樣的mysql，ssh，rpc，http等各種協議，所以只對RPC服務做訪問控制就相當於給所有的攻擊面做訪問控制，但是對於有著各種複雜協議的普適性IDC內網場景來說，這一點前提是不ready，不能說沒有用，但顯然其他協議仍然有攻擊面，仍然可用於內網滲透和橫向拓展。這也是Google自研技術棧比較深導致的跟大多數公司基礎設施不太一樣的地方，所以看官可能也察覺到這不是一個放之四海皆準的方案。

第三點，這套機制的工作原理，可以參考圖中右半部分。服務呼叫通過RPC鑑權：譬如某型別的前臺服務A只能訪問某個型別的後臺服務B，也可以衍生出業務X的前臺服務A只能訪問業務X的後臺服務B，而不能訪問業務Y的後臺服務B。測試跟生產分離，也只需要將測試和生產定義成不同的業務大類。從攻擊者的立場來看，假如你搞定了內網的一臺機器，你拿出掃描器去掃其他機器，雖然路由可達，但是因為不具有對應的RPC許可權，所以沒有對其他應用的訪問token，相當於被隔離。

不過可惜的是，前置條件IDC內網收斂為一種RPC協議這一條絕大多數公司都不符合，所以這種形式的可落地改進方案還有待討論，但是筆者認為這代表了未來的方向，對於超大規模IDC自適應的安全隔離無法通過簡單的劃分安全域和手工ACL審批來實現。

辦公網隔離

筆者在《網際網路企業安全高階指南》中描述過一種OA網路的劃分方法，如下圖所示：

首先把IT應用（假如在內網的話）跟桌面使用者劃開，桌面使用者根據職能部門划動態VLAN，這種一種傳統的安全域方式。策略收斂比較到位的話也能起到不錯的效果。

圖示的是BeyondCorp這套機制，通過識別當前裝置狀態，使用動態的訪問控制策略決定當前裝置能訪問哪些OA應用。這套機制跟傳統的OA安全域最本質的區別是：

• Bird傳統的訪問控制策略都是基於IP/MAC的。
• BeyondCorp模型是基於裝置/賬號的。
• 傳統的模型訪問控制是靜態的，後者則是動態的。
• 傳統的模型是ACL，BeyondCorp則有點風控的意味。

對於企業來說，如果移動辦公程度非常高，那麼應用雲端化和SSO這些都是現成的，只需要梳理資產，改造gateway支援風控引擎就可以實現BeyondCorp。而對很多非高度移動化的公司而言，如果傳統的安全域劃分、網路監控、終端安全管理都做的非常到位的情況下，強制改造成BeyondCorp的成本是非常高的，筆者傾向於認為ROI可能不足以支撐安全團隊的績效。

OA和IDC之間

有幾個必要的通道：

1. SSH遠端訪問通道，通過跳板機，全程審計，許可權回收。
2. 資料安全環境：資料開發，BI報表等，一切需要接觸資料倉庫的開發運營人員的工作集散地，通常這裡會有一些類似虛擬化桌面的審計。
3. 資料傳輸通道：因為各種原因debug、測試需要上傳/回傳資料，只能在指定的傳輸通道進行，必須符合脫敏跟審計的要求。
4. 程式碼釋出渠道：通常大型網際網路公司都有自己的一套釋出系統，甚至還有跟R&D同學本機磁碟對映的方案，所以這個通道的安全都在釋出系統上做。
5. 基礎設施管理通道：運維通道的特殊版本，可能會整合一些運維管理工具或自動化平臺，需要能夠觸達全部的IDC資源。

小結

對於大部分企業來說傳統的安全域劃分方法仍然夠用，至少幾年內沒有太大的問題，但對於IDC規模超大的企業來說，彈性計算和安全會成為對立面，如果需要走Google的模式需要高度的叢集管理自動化，較高的服務治理水平，高度統一的技術棧和極度收斂的內網協議。

如果OA網路需要BeyondCorp模式，需要辦公雲化和移動化程度比較高。退一步回到一家公司整體的安全建設上，如果其他地方還有很多短板，在網路隔離上追求極致不是一個正確的策略，相較而言應該將資源（對於較大的安全團隊而言也包括自研的資源）都投入到優先順序更高的地方，譬如基礎設施的攻擊緩解能力。

站在一個高P的視角，追求技術的領先是一件本分的事情，而對於安全負責人來說，風險管理和ROI永遠是安全工作的核心，也因此在2017年底這個時間點看對於絕大多數公司來說Google模式是沒有複製的必要的，不幸的是筆者所在的公司恰好具備了這方面的基礎條件，所以安全團隊儼然一副在路上的架勢。）

作者簡介

趙彥，ayazero，美團點評集團安全部負責人，負責集團旗下全線業務的資訊保安與隱私保護。

團隊介紹

美團點評集團安全部彙集國內多名尖端安全專家及諸多優秀技術人才，堅持打造“專業、運營和服務”的理念，共同為集團全線業務的高速發展保駕護航。團隊致力於構建一套基於海量 IDC 環境下橫跨網路層、虛擬化層、Server 軟體層（核心態/使用者態）、語言執行虛擬機器層(JVM/Zend/JavaScript V8)、Web應用層、資料訪問層(DAL)的基於大資料+機器學習的全自動安全事件感知系統並努力打造內建式安全架構和縱深防禦體系，藉助廣闊平臺及良機，深度發展，注重企業安全建設方面的實踐，向安全團隊最佳發展方向努力前行。

安利個小廣告

美團點評集團安全部正在招募Web&二進位制攻防、後臺&系統開發、機器學習&演算法等各路小夥伴，對在安全和工程技術領域有所追求的同學來說應該是一個很好的機會。

如果你想加入我們，歡迎簡歷請發至郵箱zhaoyan17#meituan.com

敬請關注我們的企業安全系列文章——面向實操的大型網際網路安全解決方案

Coming soon

《網際網路公司資料安全保護新探索》

《個人資訊保護關鍵點識別與思考》

《百億量級WAF的如何打造》

《海量IDC下的分散式入侵感知系統設計與實現》

《大型網際網路安全體系成熟度度量》

發現文章有錯誤、對內容有疑問，都可以關注美團點評技術團隊微信公眾號（meituantech），在後臺給我們留言。我們每週會挑選出一位熱心小夥伴，送上一份精美的小禮品。快來掃碼關注我們吧！