基於微分段的東西向安全防護,如何提升資料中心運維效率?|社群成長營分享回顧
在社群成長營網路與安全第二期分享中,SmartX 高階產品營銷經理張濤介紹了原生於超融合系統的微分段防火牆和其工作模式的特點( 點選檢視第二期圖文總結)。
網路與安全第三期分享繼續由張濤老師提供,以下為內容回顧。
SmartX 社群成長營
在 SmartX 使用者社群,我們將透過系列成長營活動,持續分享技術乾貨內容與行業解決方案,與社群成員共同成長。
大家晚上好,我是來自 SmartX 的張濤。今天內容將聚焦基於微分段技術的東西向安全防護,如何為資料中心在虛擬化、網路、安全方面帶來思路和方法上的改變,以及這些改變將如何影響與提升資料中心的運維效率。
分享內容主要包括以下五個部分:
- 企業常見的業務網路和安全部署模型。
- 實現常見網路和安全簡化部署模型對 IT 人員的要求。
- 現代化應用趨勢對安全模型的新要求。
- SmartX 超融合微分段機制的原理和優勢。
- 實施虛擬化原生的微分段對 IT 人員工作的改變。
一、企業常見的業務網路和安全部署模型
圖中的各種功能例項,在實際環境中可以是虛擬機器或物理機形態。今天討論的主要是虛擬化、容器化環境下的微分段安全,也就是當面對這些不同功能的虛擬機器和容器時,我們應如何設定合適的安全策略。
資料中心與外部之間,透過邊界防火牆區隔。由於要面向外部提供各種服務(本例中均標識為基於 WEB 的服務),因此邊界防火牆的安全策略對外部源地址的限制比較寬鬆,普遍採用黑名單方式,對已知的安全漏洞進行封堵。
資料中心內部的安全區,分開設定為 DMZ 區和內網區,兩區之間透過內網防火牆進行隔離。內網防火牆的安全策略更加細顆粒度,通常採用白名單、精細黑名單或動態安全策略等方式,以免攻擊從 DMZ 區擴散到內網區。
圖中用不同的顏色來區分各種不同的業務,同一業務內部的流程要保障通暢(虛線表示各種業務的內部通訊流),比如:
- DMZ 區綠色業務的前端 WEB 虛擬機器組,應當同內網區的綠色資料庫伺服器組之間保持通訊。
- 淡黃色業務和藍色業務的前端 WEB 虛擬機器組,應當同內網區的紫色檔案伺服器組保持通訊。
- 橘紅色業務的前端 WEB 虛擬機器組,應當同內網區的橘紅色資料庫伺服器組之間保持通訊。
而不同業務的功能例項之間,需儘可能地進行隔離,更直觀理解是圖中的虛線條之間不能有交叉連線。
二、實現常見網路和安全簡化部署模型對 IT 人員的要求
接下來我們來看看,要實現這個簡化模型上的安全部署,企業 IT 工作人員需要進行哪些工作(如下圖):
- 安全管理員與業務系統負責人一起,梳理每一項業務對於地址和埠號互通的需求,並以此為依據設計邊界防火牆和內網防火牆上的安全規則。
- 安全管理員和網路管理員設計 IP 地址規劃方案,如有可能、不同業務之間應互相隔離。
- 網路管理員依據已有的 VLAN 規劃表、IP 規劃表,為各種 DMZ 區和內網區的各種業務例項分配 VLAN 號和 IP 地址段。
- 安全、網路與虛擬化管理員一同討論以上制定的方案,如需進行虛擬機器之間東西向隔離,在防火牆、交換機上是否要配合啟用高階功能,包括但不限於:基於 MAC 地址的訪問控制、PVLAN、策略路由和透明防火牆…
- 以上方案分別在不同裝置上配置,隨後聯調測試。如正常的業務流程被安全策略打斷,則再次討論、修訂方案,反覆聯調測試直至同時達到業務釋出和安全管理的目標。
在管理嚴格的組織中,將驗證後的配置從測試環境部署到生產環境。還需要相應的審批流程。
對於使用多資料中心的組織/企業,如果在不同資料中心使用了不同品牌/型號的防火牆、交換機、路由器,則需要將設計原則轉換為不同的可實施方案和配置。
對於分工細化的大型 IT 組織架構,以上流程涉及到多部門/團隊之間的協作。對於中小規模的 IT 團隊,往往由 1-2 個人完成全部設計和配置工作。
三、現代化應用趨勢對安全模型的新要求
而我們討論的大背景則是在現代化應用的趨勢下,業務在敏捷化方面有了更高的要求,支撐業務的 IT 基礎架構既要滿足業務敏捷性、有效性,也要保持高水平的可用性、效能和安全性。這方面,我們之前總結過,虛擬化、容器化環境的三大變化:
- 被管理物件總體上增多了 —— 從若干臺物理例項增加為十倍以上數量的虛擬化、容器化例項。
- 被管物件的位置不再是長期確定的 —— 每一個虛擬機器、容器可能在不同的時間執行在不同的物理伺服器上。
- 被管物件數量和屬性的變動更快了 —— 對虛擬機器、容器的建立/啟動/關閉/刪除等操作頻率遠遠高於物理伺服器。
如下圖所示,如果在一個設計好的資料中心安全模型下,業務例項的數量和角色發生了變動,原有的 VLAN 規劃、IP 地址規劃、安全策略及執行模式都將無法繼續使用,必須重新進行走一遍需求調研、設計、測試和釋出的流程。
這些複雜的業務關係,確實有可能導致基於 IP 地址的安全規則數量爆炸式增長,導致安全體系過於複雜而無法實現,從而不得不降低安全目標,或者反過來限制業務架構的敏捷變化。這二者都是不可接受的。
四、SmartX 超融合微分段機制的原理和優勢
SmartX 超融合的微分段機制原生於自身的 ELF 虛擬化系統,允許管理員為每一個虛擬機器設定自定義的 “標籤”。這個 “標籤” 可以理解為虛擬機器的 “別名”,比如:“業務-1”、“業務-2”、“WEB”、“DB” 等等。
基於這些標籤的組合,制定出來的安全策略比之前大大簡化了,就像是這樣:允許 (標籤= “WEB” & “業務-1”) 訪問 (標籤 =“DB” & “業務-1”)。
受到這條安全規則的約束,遵循 “預設拒絕” 原則,除了這些被 “明確允許” 的行為以外,其他的網路通訊都會被拒絕,比如 (標籤= “WEB” & “業務-1”) 試圖訪問 (標籤= “DB” & “業務-2”)時,就會被拒絕。相當於為每個目標物件都配屬了專門的防火牆。
這樣的策略基於業務場景,比起使用一串 IP 地址編寫的安全規則更加容易被理解,而且規則條目也經過了彙總簡化。即便今後這個應用環境發生了一些變化,比如:
1.DMZ 區內的目標數量增減或 IP 地址變化。
- 內網區的目標物件數量增減或 IP 地址變化。
- 這些物件在不同物理伺服器、不同機房之間發生了位置遷移。
……
下圖為 SmartX 超融合的微分段機制示意圖。
五、實施虛擬化原生的微分段對 IT 人員工作的改變
以上這些場景下,每個虛擬機器設定了 “標籤” 就會和對應的安全策略自動關聯,它具有以下優點:
- 業務和應用視角:敏捷性和穩定性提升。
- 應用所需 IP 地址分配不再受到預設的明細地址段限制,節省了相應的環節和時間。
- 縮短了安全策略部署週期,加快了應用上線和業務開通的速度。
- 減少了由目標物件跨節點遷移導致的應用中斷。
- 安全管理視角:安全保障度提高,效能瓶頸消除。
- 重新定義物理安全裝置與虛擬化、容器化安全的分工介面,消除了流量重定向的複雜配置,減輕了物理安全裝置的效能壓力。
- 將虛擬化、容器化安全策略真實落地,消除了安全隱患,提升了整體安全等級。
- 不僅可以管理 DMZ 到內網的訪問安全,也可以對 DMZ 安全區內部和內網安全區內部進行微隔離。
- 不改變現有物理安全邊界。
- 網路管理視角:精簡帶來的架構級穩定性。
- 減少了 IP 地址規劃和變更的工作量和網路路由表瘦身,無需為每個業務劃分劃分網段併發布明細路由,地址利用率也提高了。
- 避免了為安全目的進行復雜的流量迂迴設計,簡化了網路拓撲,降低了網路配置複雜度和效能消耗。
- 超融合管理視角:Make IT Simple(讓 IT 更簡單)。
- 在統一管理中心 CloudTower 介面上(或透過 API)完成計算、儲存和網路安全策略的超融合管理。
- 虛擬機器、容器的生成、移動、消亡的全生命週期內都與業務安全策略緊耦合,全程自動化,無需 “保姆式” 照看。
總之,企業建設資料中心的目的是為了提高數字化應用的服務質量和效率,部署相應的安全措施也是為了保障數字化服務的連續性。
在外部和內部網路安全威脅越來越嚴重的情勢下,如果僅僅是簡單地累加安全裝置的種類和數量,有可能適得其反 —— 不合理的安全措施會降低資料中心的效率、彈性、敏捷性和業務處理能力。
SmartX 基於自主研發的超融合系統,透過在資料中心的虛擬機器、容器之間部署分散式微分段安全機制,幫助使用者減輕、消除資料中心內部的東西向安全威脅。
這種分散式的訪問管理和控制方式,採用了面向業務和應用的安全策略表達方式,在執行效率和安全保障之間很好地實現了平衡,使得安全措施真正成為業務的 “保障” 而不是 “限制”。
往期內容分享:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69974533/viewspace-2926385/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- SmartX Everoute 如何透過微分段技術實現 “零信任” | 社群成長營分享回顧
- 個推談數智運營:資料驅動運營增長,助力APP運營效率提升APP
- 龍蜥社群 11 月運營大事件回顧事件
- 小程式助力提升運維效率運維
- 資料庫與我:一段關於學習與成長的深情回顧資料庫
- 【提升團隊運營效率】交易履約之訂單中心實踐
- 使用小程式助力提升運維效率!運維
- 電商資料分析全攻略:從零開始提升運營效率
- 裝置運維工單售後系統:提升企業運營效率的關鍵運維
- 如何提升SQLServer Delete資料的效率SQLServerdelete
- 工程師成長的必備技能【11.7 熱門分享回顧】工程師
- 直播回顧:Coremail校園郵件安全防護交流會暨新技術應用分享REMAI
- 如何提升scrapy爬取資料的效率
- 節省3500萬的背後,運維如何兼顧成本與效率?運維
- 如何做好大型資料中心的運維運維
- 在阿里雲容器服務上基於Istio實現東西向流量管理阿里
- 資料維護和基礎架構維護-有感架構
- 創利樹快速重構私域電商運營策略,提升商家運營效率
- 用資料驅動運營:構建團隊的資料思維和增長基因
- Tech Talk · 雲技術有話聊 | 基於低程式碼的資料開發如何提升效率?
- 冰河指南AI技術社群基於ChatGPT正式啟動運營AIChatGPT
- 回顧走上Linux運維路上的那點經驗Linux運維
- 如何提升專案的運營和管理?
- 智慧運維,雲資料中心運維的未來之路運維
- 分享一個提高運維效率的 Python 指令碼運維Python指令碼
- [原創]如何利用雲安全運營中心監測資料洩露
- 大資料時代下,金融行業資料安全防護如何落地?大資料行業
- 運維效率之資料遷移自動化運維
- 2010年架構社群回顧:悠長的一年架構
- 龍蜥社群高效能儲存技術 SIG 11 月運營回顧 | 龍蜥 SIG
- 如何基於Dataphin實現敏感資料保護
- 各行業資料治理案例分享 | 肇慶高新區城市運營中心_光點科技行業
- 亞馬遜雲科技助力大觥科技 降低運營成本20%並提升運營效率達40%亞馬遜
- 【知識分享】站長如何對伺服器進行維護伺服器
- 吉林大學資料庫安全防護資料庫
- 微營銷平臺運營
- 商務智慧系統提升電信企業運營效率
- 基於時序資料,推動智慧運維發展運維