大資料平臺紅藍對抗 - 磨利刃，淬精兵！

背景

目前大促備戰常見備戰工作：專項壓測（全鏈路壓測、內部壓測）、災備演練、降級演練、限流、巡檢（監控、應用健康度）、混沌演練（紅藍對抗），如下圖所示。隨著平臺業務越來越複雜，紅藍對抗的作用愈來愈明顯，下面將詳細介紹大資料平臺在大促備戰工作中是如何開展紅藍對抗的。

首先我們先了解一下什麼是紅藍對抗，它都有哪些好處？

一、紅藍對抗介紹

紅藍對抗是網路安全領域常見的一種對抗性演練方法，是指為發現並整改企業內外網資產及業務資料深層次安全隱患，在確保業務平穩執行的前提下，整合平臺安全威脅監測能力、應急處置能力和防護能力，以真實網路環境開展實兵紅藍對抗演練，提高並完善安全防護技術與管理體系。

藍方代表攻擊方，紅方代表防守方。紅藍對抗模擬了真實的網路攻擊和防禦過程，在受控的環境中進行，藍方透過模擬各類威脅和攻擊手段，對紅方進行攻擊，測試其防禦能力和系統高可用情況。紅方則負責防禦和應對，尋找並修復系統中的問題，並且收集關於攻擊者的資訊。

二、紅藍對抗的好處

1.保證監控告警有效性

紅藍對抗可幫助產研驗證監控告警的配置有效性，通知及時性，資訊準確性。

2.增強系統可靠性

紅藍對抗透過識別可能導致系統發生錯誤的潛在問題，幫助提高系統的可靠性。

3.降低風險

紅藍對抗透過識別可能被惡意攻擊者利用的潛在弱點，幫助降低發生線上問題的相關風險。

4.經濟高效的測試

紅藍對抗模擬了生產環境的場景，但卻不會對生產環境產生風險，從測試角度來看保障系統的質量。

三、紅藍對抗實踐

紅藍對抗演練實踐主要包括：演練公告、人員指定與任務分配、演練前場景梳理、紅藍對抗過程、演練結果收集、演練覆盤共 6 個部分。

1、演練公告

主要包括兩個部分：

第一、本次紅藍對抗主負責人組織對抗演練啟動會、確定對抗演練時間範圍、指定實時 | 離線演練介面人。

第二、實時 | 離線產品提前郵件 | 咚咚通知業務使用者將進行紅藍對抗演練。

2、人員指定與任務分配

首先，指定本次紅藍對抗的主負責人。負責整個紅藍對抗演練的統籌工作，包括方案制定、演練對抗文件落地、場景收集通知及複核、組織攻擊方發起及防守方防禦過程、演練覆盤工作。

其次，分別指定實時和離線側備戰介面人。充當藍方攻擊方，主要是指定演練攻擊場景、發起系統攻擊。

再次，分別指定實時和離線側 backup 兜底人員。一般為核心研發人員，由於發起攻擊的具體時間是不確定，為避免藍方發起攻擊後，紅方由於各種特殊原因不能及時處理故障導致影響線上正常業務，backup 兜底人員可快速的恢復系統。

最後，分別指定實時和離線側演練監測員。一般為測試人員，主要是記錄演練過程中發出的告警資訊（mdc、ump）以及複核演練記錄文件。

3、演練前場景收集

該部分是演練前最重要的環節，主要包括確定演練應用範圍、確定攻方演練場景。

3.1、確定演練應用範圍

演練應用建議優先選取應用等級L0 和 L1的應用，具體可根據業務需要進行選取。另外，可透過以下兩種方式快速查詢對應的應用：

http://XXX.jd.com/dashboard/4/node/XXX

http://XXX.jd.com/health

詳細演練應用列表由實時 | 離線介面人（經過 C3 領導複核透過）提供，輸出：攻方批次注入場景收集，

3.2、收集演練故障場景

jdos 應用 主要是藉助【混沌工程】平臺進行故障注入，採用以下演練場景：

cpu 使用率高、記憶體使用率高、磁碟使用率高、網路延遲、網路丟包、程序終止、mysql 請求延遲異常、jimdb 請求延遲異常等。

底層叢集 主要是運維人員透過指令碼、命令等方式進行故障注入。主要包括以下演練場景：

資料庫例項 CPU 打高、hdfs 佇列打滿、計算任務 pending、RSS 叢集繁忙、zk 節點當機異常等。

4、紅藍對抗過程

有了演練場景，產品也傳送了演練通知郵件後，就可以進行紅藍對抗了。這裡要說明幾點：

① 不能將具體的攻擊時間 “透露” 給藍方。

② 建議選擇生產環境應用或叢集進行攻擊，儘可能真實的模擬線上問題。

4.1、【主負責人】演練前通知

主負責人在藍方攻擊方正式演練前提前在群裡發訊息，模板如下：

@全體成員  
【重要通知】
今天17:30～21:30大資料平臺（實時+離線）進行紅藍對抗演練，不定時進行故障突襲。請各位同學將跟進處理過程在本群進行同步。  分三個階段：問題發現、原因分析診斷、故障處理。
每個環節（問題發現、故障診斷、故障處理）確定後立馬發訊息，不要最後發總結！
每個環節（問題發現、故障診斷、故障處理）確定後立馬發訊息，不要最後發總結！


1、問題發現
【問題發現】
產品-服務名稱：
（1）收到電話/咚咚告警，告警內容xxx  
或
（2）雷達大屏飄紅，截圖xx  開始排查處理

2、原因分析
【故障診斷】
產品-服務名稱：xx問題原因已查到，原因概要描述。

3、故障處理
【故障處理】
產品-服務名稱：：xx問題已處理，已恢復，並給出告警恢復/監控截圖。

4.2、【藍方】建立&執行演練任務

藍方在混沌工程平臺，按照之前收集的演練場景建立演練任務或批次建立演練任務。如下圖

說明以下幾點：

① 底層叢集的攻擊主要透過命令、指令碼實現，這裡暫不詳細敘述。

② 網路延遲、丟包故障可能演練失敗，原因：限制網路故障演練（該宿主機核心版本存已知 BUG 不能演練）"4.18.0-80.11.2.el8_0.x86_64"。

③ 記憶體利用率 100% 場景，因為 linux 記憶體滿了會觸發 oom kill，所以建議設定 90%。

④ 演練時長建議大於 5 分鐘，原因：有些應用配置的 mdc 報警週期範圍是 5 分鐘內，如果演練時長小於 5 分鐘可能收不到報警。

4.3、【紅方】防守修復故障

藍方發起攻擊後，紅方會收到咚咚報警，按照既定預案進行故障修復。部分截圖如下：

4.4、【紅方】系統恢復

有些演練場景（程序終止）不會自動恢復，需要紅方手動重啟系統應用服務，確保生產應用服務均正常。

4.5、【紅方 + 藍方】演練結束

紅藍對抗演練結束後，紅藍雙方均填寫 “紅藍對抗演練場景” 文件，藍方填寫：混沌任務連結、混沌演練場景、演練狀態、混沌演練執行開始時間、混沌演練執行結束時間。紅方填寫：排查人、告警資訊、根因、排查到原因時間、排查過程描述（包含排查過程，使用工具，輔助決策判斷）、計劃解決方案&應急預案、預估影響 處理時間。如下圖所示：

5、演練結果收集主負責人複核演練結果、梳理分離演練問題，讓紅藍雙方儘早完善。主要存在以下問題：

1) 未及時處理：紅方收到告警後， 由於種種原因 (開會、未在工位等) 未及時處理故障。

2) 處理不完整：紅方處理完 ns 失敗問題後，未通知使用者處理失敗任務。

3) 未收到報警：

① 未配置報警規則。例，mdc 或 ump 平臺未配置報警。

② 未觸發告警閾值。例，藍方攻擊時 cpu 利用率 90% 但 mdc 報警規則配置的是 95%。

③ mdc 平臺停用告警。例，mdc 暫時停用了模版中心的 MDC 監控與告警。

6、演練覆盤

主負責人組織紅藍對抗覆盤會議，提供演練結果、問題列表，實時 + 離線架構師均參加，從演練過程、演練效果等角度對本次演練進行評價或建議。

① 告警級別需要自查修正。目前部分告警級別配置偏低，cpu 利用率大於 90% 時，報【警告】，建議改為【緊急】。

② 延長攻擊時間。找某幾個應用，攻擊時間為 30+ 分鐘，驗證防守人員是否真正摘流量。

③ 混沌演練常態化。可透過混沌工程平臺 - 常態演練進行，並結合值班表增加演練頻次，以戰養兵。

④ 分步演練【警告】、【緊急】場景。第一步先攻擊 10 分鐘觸發【警告】的場景，第二步再攻擊 10 分鐘觸發【緊急】的場景。

⑤ java 方法異常、延遲場景未演練。後續期望測試人員透過 forcebot 壓測來支援流量流入。

期望混沌平臺的支援：

① 混沌工程平臺支援一次批次選擇多個應用建立、啟停混沌演練任務。 可提高建立任務效率，目前的批次建立演練任務功能，只能一個一個的新增應用進行建立。

② 混沌工程平臺提供常態化混沌演練 api。方便使用者自定義建立常態化演練任務。

③ 混沌工程平臺支援在平臺內檢視 mdc、ump 告警。減少使用者在多個平臺系統來回切換。

四、總結

透過本次紅藍對抗演練，既有效的增強了大資料平臺系統應用的抗風險能力，降低了生產環境系統發生故障的機率，又大大的提升了研發人員解決問題故障的能力，也沉澱了一套快速高效的演練的方案。

作者：京東零售 尹偉

來源：京東雲開發者社群 轉載請註明來源