資料安全與風控解決方案測試實踐與思考

在業務安全SDK測試中，最核心的一項工作是評估異常檢測和加解密演算法的效果。比如，加解密演算法類似於黑盒子，如何來保證這個黑盒子的質量?資料敏感，樣本少，如何快速生產測試資料樣本?功能迭代，頻繁發版，如何保證迴歸測試的質量與效率，覆蓋更多的場景?本文將分享58同城在業務安全三端“移動端、H5、服務端”SDK方面的探索經驗和當前取得的成果。

▲58同城測試架構師劉元

嘉賓介紹： 58同城測試架構師，10年測試開發經驗，從2020年至今，在58集團-技術工程平臺群-研發管理部擔任測試架構師。負責業務安全SDK專案的質量保證工作、集團效能測試平臺開發工作，致力於從實踐中總結經驗，將優秀的方法論及工具平臺引入到實際工作中。

以下是劉元老師在SACC2022大會的演講實錄：

一、背景介紹

什麼是安全?安全是產品的屬性之一，它和產品的功能、效能、穩定性歸屬於同一維度。那麼，安全的目標是為了保障在產品當中，資訊資產的保密性、完整性、可用性。其中，保密性是指未經授權的資料不可訪問;完整性是指未經授權的資料不可篡改;可用性是指已授權的使用者可正常的訪問。

圍繞這個目標，使用安全架構才能達成。在安全架構領域，有三道防線，分別是產品安全架構、安全技術體系架構、審計架構。結合實際落地的過程中，對它進行邏輯上的抽離，從而得到幾個核心要素。也就是，業內比較認可的安全架構5A方法論：資產保護、身份認證、授權、訪問控制、可審計。

在瞭解整個大背景之後，無論是對測試物件進行評審，還是對測試設計，包括最終的測試覆蓋做評估，我們都要從目標、手段、5A方法論層面出發。

以時間軸劃分，我們當前所處的是一個怎樣的時間節點。首先，從最早以資訊為中心的資訊保安時代，歷經了以網路為中心的網路安全時代，到現在以資料安全的採集、傳輸、使用、儲存、轉換、銷燬整個全生命週期為中心的資料安全時代。

我國相繼建立《網路安全法》、《資料安全法》、《個人資訊保護法》，保護個人、組織與資料有關的權益，提升資料安全治理和資料開發利用水平，促進以資料為關鍵生產要素的數字經濟發展。

2021年，大家都是在合規整改當中度過。我國三法建立之後，對整個工作影響較大，從原來的只需要保證資訊保安、網路安全層面，過渡到以資料安全為主的保證範圍之內，無論是使用者的資料，還是企業自身的資料。

隨著資料價值提升，越來越多的攻擊目標轉向企業的業務資料和使用者資料。常見場景為被友商、黑產爬取產品價格、內容資訊、運營活動等惡意行為。基於此，自2020年10月起，我們開啟金盾專案，用來保護企業級業務資料安全。

上圖是去年8月份，58同城本地版資料訪問量大盤的情況。第一週，紫色線有明顯的激增。當時，運營同事反饋資料不太正常，這個時間節點既沒有節假日，也沒有運營活動。透過排查，我們懷疑訪問量激增的背後，是有人在抓取資料。但誰在抓取，抓取了多少量，我們並不知曉。

自此，我們順勢將金盾專案推到業務線當中做整合。經過一天時間，我們將SDK緊急整合到安卓iOS雙端裡面，透過緊急發版。同時，後端透過整合金盾的包，管控有異常攔截的介面。接著，我們發現的確有問題，有一批黑產不停地變換IP在抓取我們的資料。最後，我們對它進行了封禁處理。大家可以看到，從第六天開始，所有的線已經恢復正常。

金盾是一套針對介面請求和響應的安全防護體系，透過客戶端SDK、服務端SDK、管理後臺，來實現通訊加解密、資料埋點、風控監測、異常攔截等能力。透過技術手段，針對移動應用“APK、IPA、WAP”與業務伺服器之間的資料，透過“加密與解密”的方式，實現資料安全與業務安全。

所有配置類的資訊都在管理後臺進行統一的管控，新增、刪減，裡面會涉及到策略配置、白名單配置、降級配置等。服務端SDK和客戶端SDK的能力都是一一對應的。比如，在客戶端進行請求加密，這條請求達到服務端之後，服務端會進行相應的解密。在客戶端，對這條請求進行簽名，服務端會對它進行驗籤。

在解密完成之後，會把它下發到具體的業務邏輯程式碼當中，進行業務邏輯的處理。完成這部分之後，在資料回到客戶端之前，我們會對響應進行加密，客戶端接收到response之後，對響應進行解密，最終來進行資料渲染的操作。

對使用者來說，整個流程是透明的，未加密的操作體驗和已經資料加密的操作體驗並沒有太大的差異。我們希望，金盾以安全官的角色植入到各業務線，賦予業務線具有“資料安全與風險控制的能力”。

上圖是金盾整體架構設計圖，包括模組劃分和資料流向。由於金盾以類中介軟體的方式存在，且受制於各個業務線“現狀”，“業務形態”及“業務方式”，因此歸納出金盾專案的輸出應該具有以下特質：整合方式規約化、業務低耦無侵入、場景業務定製化、資料分析視覺化。

為了賦能整個金盾專案，需要兼顧不同的業務場景。58同城是一個多業務場景的產品，所以我們考慮不同業務線的現狀，包括業務形態和業務方式。首先，金盾專案透過SDK嵌入的方式來做多端的整合，包括客戶端、安卓、iOS、web、H5端，以及整個服務後端。

接著，在金盾SDK上定義一套私有化協議，就無須關心業務方、業務特徵，以及業務能力，透過儲存的方式來採集資訊。在客戶端啟動時，進行金盾SDK的初始化，它會自主資訊採集，包括端上環境監控、硬體資訊的採集。這部分資訊的採集主要是用來生成裝置指紋，進行整體的規約。

如果這部分發現採集異常情況，我們可以自主的進行二次採集，儘可能保證資料的完備性。由於要將SDK整合到業務方，我們分別在安卓端基於安卓的攔截器做應用層。

在iOS端，提供工具包在真正發起業務請求的時候，判斷標記，是否需要做加密傳輸，呼叫金盾SDK提供的能力進行加密，包括傳輸完成之後收到的解密。在服務端，以金盾註解的方式提供能力。

不同的業務對安全的要求不同，核心業務既需要做整個風險的監控，又需要對風險進行攔截處理。部分低頻業務只需要進行監控，不需要其他操作。為了更好的支援不同定製化的需求，我們需要把這部分能力的控制交付給業務方來做。

站在業務角度，希望看到整個業務系統到模組維度，或者介面維度，不同統計的報表。涉及到大家對資料視覺化的需求，又有不同的維度指標，所以我們會對它進行不同的拆分，透過不同的看板來支援。

我們來看整個金盾架構圖，金盾綜合服務管理平臺除了一些配置之外，還會涉及到資料分析、統計等一些資訊，這裡面的互動我們用到了儲存的中介軟體。

整個專案涉及到的程式碼工程，包括SDK程式碼、Demo程式碼、測試程式碼等。SDK本身是用來提供一些能力，我們不能在沒有進行完備的測試之前，就將SDK整合到業務APP當中，去進行測試，原因在於本身業務APP的邏輯很複雜，SDK的功能也很複雜，一旦出現問題，我們很難去界定到底是SDK導致的，還是APP導致的。

所以，我們在做交付之前都會做獨立的SDK的Demo，將SDK的每一項能力原則化的透過安卓、iOS的活動去觸發能力。有了獨立的SDK的Demo之後，進行功能測試、專項測試，包括效能損耗的評估、Demo執行的穩定等等。

需要強調的是，SDK的Demo由誰來開發，無論是最早做Demo，還是SDK功能迭代了，Demo要做相應的升級，在這裡推薦大家由自己對應的RD來做這件事。

原因在於，當RD開始去寫Demo時，會對自己開發的功能做自測。接下來，等到SDK的Demo互動到我們手中之後，我們可以在上面做一些迭代性功能的開發，這樣可以保證本身體測的質量比較高，同時，像介面性質的Demo，我們一般都是自己來做。

上圖是我們整體的實現流程，安卓端所有的互動都是基於攔截器實現。在真正發起請求前，會經過金盾SDK，對資料進行加密後傳送。在接受資料之後，進行解密，交給前端進行渲染。出於安全的考慮，具體的加密方法已經做了模化處理。

在iOS端，由於攔截器實現並不是很穩定，所以我們選擇以工具的方法的形式提供能力。它的觸發時機和安卓端相同，在發起請求時呼叫工具方法進行加密，拿到響應資料之後，呼叫工具方法進行解密。

如果加密功能出現問題，我們有一套降級的策略，分為全域性降級和url降級兩個維度。面向測試物件，在瞭解整個產品的設計架構之後，最終所有的實現都是基於程式碼。

大家強調測試先行，在開發定義好介面文件之後，向服務端就可以寫一些介面維度測試的用例，測試的指令碼。介面文件對我們來說很重要，包括無論是新增的介面，還是介面的迭代版本。

二、SDK全流程質量保障

整個測試流程包括需求風險評估、測試排期、用例設計、資料準備、效能損耗評估、影響分析、風險覆蓋、釋出決策八個階段。

在需求風險評估階段，除了關注整個功能的優先順序，還評估需求的業務風險，設計測試用例對風險進行有效的覆蓋，建立需求與測試用例的對映關係，根據測試時間和業務風險確定測試範圍和優先順序，根據風險覆蓋率進行軟體釋出的決策。

如果想要很好的管控風險，首先我們要對它進行量化。業務風險是用來量化一個需求對業務產生負面影響的可能性(業務風險=使用頻率✖失效危害)。風險絕對權重根據每個需求的使用頻率和失效危害計算獲取。

風險相對權重是指每個需求相對同一層級中其他需求的業務風險權重百分比(相對權重=需求權重/總權重)。風險貢獻度是指每個需求佔所有需求的風險貢獻百分比。

上圖是一個實際用例，在SDK3.0專案裡有四個核心的功能，包括金盾後端新增token介面，金盾後端2.0 SDK的升級相容，靜態檢測的能力，以及動態配置策略。基於整個需求之後，對它進行使用者故事的拆解。

拆解完成之後，我們會基於使用場景來定義它的使用頻率等級和危害等級，這部分更多是由人工來敲定的。透過買點統計決定是否要對一些使用頻率等級和危害等級進行調整，得到絕對權重和相對權重，最終得到的風險貢獻度。

在測試排期階段，會進行整體優先順序的定義。在高優先順序時，測試的人力和時間都會進行充分的保障。同時，我們會提前梳理出業務方的接入流程，最終交付形式等，包括在用例設計之前，整個測試策略的制訂。表格的形式無論是常用的Excel，還是腦圖都可以。

在用例設計環節，重點關注可接受的測試覆蓋率，我們儘量將風險覆蓋到一個可控的範圍，它可支撐發版。如果線上發現問題，我們可以很好、很快地進行定位和修復，這裡面既要保證效果，也要保證效率。

上圖是整個測試流程的用例設計，我們會對它進行分模組，或者按照需求來進行用例的劃分。劃分完成之後，每個用例本身會有用例的優先順序，其中包括用例型別劃分，這裡面會記錄變更的時間，後面每個測試都會從這些用例中進行篩選。

業務級動態策略配置提供給業務方的一種能力，業務方基於取樣傳輸過來的27種業務運算元，與14種計算運算元進行組合，對請求流量進行標記。舉個例子，某IP:127.10.0.1以1次/秒請求介面，標記該IP，給出具體的處理結果。

由於27個業務運算元加上14個計算運算元，結合2種流量型別，包括WEB流量和APP流量，一共有105種可能情況。對於多條件組合，如何處理?我們使用全組合，把所有的組合全部列出來，或者選取其中的兩個因子做組合。

我們希望用很少的測試用例，覆蓋更多的業務風險。對此，我們找到了線性組合方法，在整個測試的精準度上面，包括最終如果發現問題的根因分析，它可以做到高精準度且易分析。

在資料準備階段，涉及到種子資料的選取與資料生成策略的應用。那麼，種子資料從哪裡來?我們對真實的線上資料進行脫敏處理之後，才可以使用。我們還可以根據業務需求，手工構造一些資料。

基於種子資料的特徵或規則，擴充套件開源比較常用的Faker庫，自定義我們自己的規則，然後再去生成Faker資料。它符合真實資料的特徵，也避免了非真實資料的一些其他問題，可以很好的擴充測試資料的豐富度。

為什麼會有損耗?裡面涉及到加解密，動靜態校驗，會引入效能的損耗。損耗可承受的範圍是什麼?經過我們的實驗資料顯示，1%損耗為最佳;3-5%損耗為可接受;8%損耗為拒絕，需要進行對應的最佳化。

我們基於開源的壓測引擎，結合自研的任務排程系統，做了一個分散式壓測平臺。在效能測試平臺裡，我們主要關注兩個點，第一個點是壓力引擎的選擇。第二個點是排程系統。

上圖是資料級加密解密的工作流程，客戶端在冷啟動的時候，會去請求服務端獲取並儲存本次的token(身份識別認證)，接下來進行正常的業務請求，將業務的明文請求進行引數的採集加密，併發到後端，在後端進行明文請求的解密，給到具體的業務介面。

此外，我們還會對它進行前期壓測計劃的設定。整個壓測計劃包括我們需要關注的一些指標，qps、CPU、平均響應時間、fullGC觸發頻率、錯誤率等。基於這個錯誤指標，我們來構造整個的加壓模型和降壓模型。

測試影響分析在迴歸測試中的應用原則：將回歸測試用例關聯到SDK程式碼，選擇與最新git push相關聯的用例。根據檢測到缺陷的可能性對迴歸用例進行排序，優先執行容易暴露缺陷的用例。

這部分的執行工具是基於HttpRunner的介面自動化測試用例集，提供多步驟、多用例串聯，針對具體值的校驗。對於大家，學習的成本較低，可以很快入門。

上圖是風險覆蓋率以及測試用例的執行情況。首先，我們本次新增的功能要百分之百執行，基於風險貢獻度和執行覆蓋率，最終計算得出風險的覆蓋率。

有了以上的資料，就可以得到釋出決策的結論，98%的業務風險已經被測試的覆蓋並透過，沒有執行失敗的情況。同時有將近1.63的業務風險有測試用例但未執行，沒有任何的業務風險，沒有無用例覆蓋的情況，那麼我們認為這次測試的質量保證工作成功，可以對業務線進行交付。

三、風控評估和總結思考

服務端風控主要以介面監控為主，透過“系統級靜態校驗”、“業務級動態策略配置”和“資料級加密解密”執行線上實時標記與攔截。以“終端監測”+“風控監測”融合資料為基礎，透過異常採集項的多維組合構建“高危”、“中危”和“低危”評估模型，並以此為準則與業務方進行相關溝通與異常排查。

針對一些中危或低危使用者，我們會對它進行挑戰驗證碼的發起，然後進行人工的二次渲染的挑戰。我們會在相對短的時間裡，變換不同的驗證形態，從而進行升級或者降級處理，最終根據業務方需要及配置指導，實施“挑戰”、“標記”

與“攔截”功能。

資料安全領域需要敬畏對手。針對新專案測試，我們應該怎樣做?流程和工具都是為人服務的，不拘泥於此;更應注重專案前人積累，注重行業趨勢方向;敢於嘗試，敢於試錯;知其然知其所以然：業務背景、技術細節。