国产AV88|国产乱妇无码在线观看|国产影院精品在线观看十分钟福利|免费看橹橹网站

網(wǎng)安加·百家講壇

發(fā)布時間:2023-8-24 | 雜志分類:其他
免費制作
更多內(nèi)容

網(wǎng)安加·百家講壇

49LECTURE ROOM 百家論道(二)CSPM 與 CNAPPGartner 視 CNAPP 為統(tǒng)一化的云安全管理平臺。在《CNAPP 創(chuàng)新洞察》報告中,針對云原生應用保護平臺(CNAPP)解決方案其認為是涉及基礎設施即代碼(IaC)掃描、容器掃描、云工作負載保護(CWPP)、云安全態(tài)勢管理(CSPM)等跨越開發(fā)和生產(chǎn)環(huán)境的關鍵能力。從作用上看,CNAPP 能夠為云原生客戶真正提供端到端的云原生應用保護,提高云原生應用的安全可見性、改進了兼容性、加快了風險識別能力、實現(xiàn)了風險和合規(guī)檢測自動化。從圖 3 可以看到,CSPM 是 CNAPP 整體解決方案中一環(huán),而且扮演著非常重要的角色。但 CNAPP 出現(xiàn)的時間落后于 CSPM 幾年,或者 Gartner 也是看到了云管控的復雜性,孤立的點狀解決,不如來一個大一統(tǒng)“集大成”的便捷。另外,在“安全左移”理論的作用下,CSPM 的功能在前面提到的通用能力基礎上,又增加了 IaC 掃描、云威脅檢測和響應、惡意軟件/敏感數(shù)據(jù)掃描等功能屬性,有點“既要又要還要”的味道。但這種類似自閉環(huán)的小SOC,如何在甲方安全架構(gòu)體系下生存是個問題。(圖三 ... [收起]
[展開]
網(wǎng)安加·百家講壇
粉絲: {{bookData.followerCount}}
文本內(nèi)容
第51頁

49

LECTURE ROOM 百家論道

(二)CSPM 與 CNAPP

Gartner 視 CNAPP 為統(tǒng)一化的云安全管理平臺。在

《CNAPP 創(chuàng)新洞察》報告中,針對云原生應用保護平臺

(CNAPP)解決方案其認為是涉及基礎設施即代碼(IaC)

掃描、容器掃描、云工作負載保護(CWPP)、云安全態(tài)勢

管理(CSPM)等跨越開發(fā)和生產(chǎn)環(huán)境的關鍵能力。

從作用上看,CNAPP 能夠為云原生客戶真正提供端

到端的云原生應用保護,提高云原生應用的安全可見

性、改進了兼容性、加快了風險識別能力、實現(xiàn)了風險

和合規(guī)檢測自動化。

從圖 3 可以看到,CSPM 是 CNAPP 整體解決方案中一

環(huán),而且扮演著非常重要的角色。但 CNAPP 出現(xiàn)的時間

落后于 CSPM 幾年,或者 Gartner 也是看到了云管控的復

雜性,孤立的點狀解決,不如來一個大一統(tǒng)“集大成”

的便捷。

另外,在“安全左移”理論的作用下,CSPM 的功能

在前面提到的通用能力基礎上,又增加了 IaC 掃描、云

威脅檢測和響應、惡意軟件/敏感數(shù)據(jù)掃描等功能屬性,

有點“既要又要還要”的味道。但這種類似自閉環(huán)的小

SOC,如何在甲方安全架構(gòu)體系下生存是個問題。

(圖三 CNAPP 云原生應用保護平臺)

四、CSPM 挑戰(zhàn)與實踐

前面介紹了 CSPM 的前世今生,而且亦對與 CSPM 密

切關聯(lián)的 CIEM、CNAPP 做了對比。筆者最后介紹下自身

在實踐中面臨的一些挑戰(zhàn)和當前的探索。

( 一)挑戰(zhàn)

由于我們的業(yè)務完全依托公有云而建,所以在講挑

戰(zhàn)之前還是介紹下云廠商在這塊已經(jīng)做的事情。以某云

上此塊已有的類似 CSPM 的能力為例。

1、配置審計,重點關注的也是配置風險問題,無論

國內(nèi)還是海外的云廠商,一般都會有 config 類產(chǎn)品。

配置審計中已內(nèi)嵌了部分合規(guī)包,而且也支持自定

義規(guī)則,相對來講屬于低成本的一個實現(xiàn)邏輯,作為輔

助快檢還是可以的。當然,它也帶一定自修正的能力,

敢不敢用屬于另外一個維度的問題。

(圖四 配置審計功能示例)

2、針對基礎設施權(quán)限管理,在其云安全中心中提供

了云平臺配置檢查模塊,涵蓋 CIEM、常規(guī)云產(chǎn)品安全風

險和合規(guī)風險。出現(xiàn)的時間不長,但是功能迭代和豐富

度進步蠻快。

(圖五 云安全中心功能示例)

我們當前是結(jié)合這 2 類產(chǎn)品的部分功能輔助做一定

檢測使用。但仍然會面臨一些挑戰(zhàn):

(1)無論的云廠商提供的類 CSPM 功能產(chǎn)品或商用

產(chǎn)品,本質(zhì)上仍處于事中 / 事后監(jiān)控的管控邏輯。云上

的基礎設施權(quán)限和云服務配置管控的特殊點,天然的決

定了監(jiān)控管控邏輯帶來的治理成本高昂,尤其業(yè)務上線

跑起來。我們更希望以事前的阻斷邏輯去做好管控,輔

助以事中 / 事后監(jiān)控邏輯來做好檢測。

(2)多云不是我們面臨的場景,但多賬號是。當有

20+ 以上的云賬號需要去管控的時候,監(jiān)控 Detection

管控邏輯帶來的運營成本和壓力是巨大的。

(3)配置審計功能一般云廠商可能會免費提供,但

是云安全中心云平臺配置檢查功能是收費的,費用也是

不低的,尤其在海外區(qū)域。

(4)云廠商或商用產(chǎn)品是站在通用邏輯和風險維

度去做這塊能力,雖然云廠商的此塊能力的進化速度很

第52頁

50

百家論道 LECTURE ROOM

快。但仍然無法結(jié)合企業(yè)云上架構(gòu)自動生成足夠可信的

風險檢測結(jié)果,誤報率是繞不開的問題。另外,商用產(chǎn)

品完全依賴云廠商 API 的開放程度,這塊的瓶頸是在選

用商用產(chǎn)品時不得不考量的點。畢竟要想看得深,首先

需要看到見。

(5)無論云廠商或商用產(chǎn)品,此塊能力完全依賴對

云 infra 風險的認知程度,主要看 2 個維度。

a. 覆蓋度。覆蓋度是指檢測能力對云上產(chǎn)品和服務

的覆蓋面,是否能實現(xiàn)多數(shù)覆蓋是個挑戰(zhàn),這塊對商用

產(chǎn)品挑戰(zhàn)更大。

b. 豐富度。豐富度是指針對單一產(chǎn)品或服務檢測的

維度和深度能達到多少,規(guī)則數(shù)是一個衡量指標。

這塊云廠商是有天然優(yōu)勢的,但仍然會面臨其他的

問題,怎么去整合關聯(lián)方同時跟進節(jié)奏。在《新視角下

企業(yè)云化安全治理框架 OCBC》一文中,筆者也曾提到,

云廠商各個產(chǎn)品是獨立的,每個產(chǎn)品多數(shù)時候是站在自

身的維度來考量功能實現(xiàn),安全不是第一選項。同時針

對多產(chǎn)品組合使用的安全性和風險問題,更不是第一考

量項;加之各云產(chǎn)品的迭代速度出奇的快,一個新功能

點的引入都有可能對甲方安全架構(gòu)產(chǎn)生影響。因為,作

為用云企業(yè),是無法和云廠商提出云產(chǎn)品的升級迭代與

否由自己企業(yè)來自主決定的要求的。

( 二)實踐

基于 CSPM 仍偏向事中 / 事后的管控邏輯,與實際業(yè)

務場景事前管控、與內(nèi)部平臺強耦合的特性有著較大的

差異,我們結(jié)合業(yè)務特點,針對云權(quán)限和配置安全管控

我們采用如下的管控邏輯來實現(xiàn)自身的訴求。

( 圖 6 云權(quán)限和配置風險安全管控 )

云權(quán)限和配置風險安全管控整體上遵循事前、事中

和事后的思路邏輯,功能上:

(1) 覆蓋常規(guī)CSPM通用功能、云基礎設施權(quán)限管理等。

(2)針對云產(chǎn)品自身風險治理,管理更前置化。在

云產(chǎn)品選(評估)的階段安全就進行介入,保證先評估,

后準入,再購買機制。

(3)針對人員、應用的云服務和產(chǎn)品權(quán)限使用以自

建化能力,遵循最小化權(quán)控原則,并確保 AK 自動化托

管,實現(xiàn)事前風險收口。

(4)采用基線風險監(jiān)測和有效性檢測二重機制,確

保基線可靠性落地,繞過基線管控風險檢測。

當前部分功能仍在建設階段,后續(xù)會結(jié)合控權(quán)邏輯

再綜合進行介紹。

五、寫在最后

CSPM 的出現(xiàn)本質(zhì)上是為了解決云配置安全風險

的問題,Gartner 在 CSPM 的定義中也強調(diào)其能力覆蓋

prevention、detection 和 response。但是在甲方復雜

的業(yè)務場景下,prevention 實現(xiàn)的難度和復雜度甚高,

對乙方廠商要求產(chǎn)品通用性和可復制性的原則指導下,

更不會愿意去介入前置的動作。

但是,依賴事后追著治理的思路對甲方來講是非常

被動的。僅僅作為事后監(jiān)控的機制,顯得略雞肋,畢竟

云廠商已經(jīng)提供了類似的功能點,而且商用產(chǎn)品又完全

依賴云廠商的 API 開放能力來構(gòu)建規(guī)則,本身是存在弱

勢的。另外,就是對國內(nèi)云廠商的支持力度參差不齊。

最佳實踐往往是在特定基建上的落地,可以參考,

但不一定能借鑒。作為甲方,結(jié)合自身業(yè)務特點,選擇

最適宜的方案才是上策,博眾家之所長,補已之短。

第53頁

51

LECTURE ROOM 百家論道

多場景下的安全運營集約化

當前在外部安全威脅不斷加劇的背景下,為提升抗風險能力,安全、業(yè)務

部門投入大量資源落實包括安全意識、數(shù)據(jù)安全、主機安全、研發(fā)安全等 110+

項具體工作,但結(jié)果卻出現(xiàn)投入多、效率低、用戶滿意度差的情況,亟待建立

集約型安全服務平臺,基于集約化、場景化、自動化措施解決以下問題。

一.安全威脅分類

(一)安全風險分散

安全系統(tǒng)是煙囪式部署,風險數(shù)據(jù)割裂,各種風險數(shù)據(jù)存在不同系統(tǒng)或設

備中。比如網(wǎng)絡攻擊數(shù)據(jù),在 WAF、NGFW、APT、態(tài)勢感知等系統(tǒng)各有一部分,

需要建立一個集約型安全服務平臺。

(二)安全工作缺乏端到端場景

單一安全系統(tǒng)或設備難以滿足業(yè)務場景化需求,需要基于業(yè)務場景化把安

全與運維、工單、授權(quán)、管理等系統(tǒng)有機結(jié)合起來。比如超融合安全運維場景,

就整合 SSO 單點登錄、賬號納管、動態(tài)授權(quán)、自動代填密碼登錄能力,達到了

快速交付能力,實現(xiàn)端到端安全運維場景。

(三)安全工作自動化能力不足

在攻防對抗過程中,面對龐大信息資產(chǎn),缺乏體系化和成熟的自動化能

力,脆弱性暴露時間越長,攻擊成功概率越大。比如:面對大量對外主機需要

修復 Log4j 漏洞、Tomcat、Nginx 漏洞等,有自動化漏洞修復能力,可以快速修

補這一風險。

二、項目目標——一體化安全服務平臺

在此背景下,多場景安全運營集約化項目應運而生。

多場景安全運營集約化項目最終的目標是打造一個一體化安全服務平臺,

具有集約、服務和提效的功能,其中包括:

1、安全服務集約化:對接內(nèi)部云、外部云、混合云等場景下主機漏掃平

臺、入侵檢測平臺、研發(fā)安全漏掃平臺、數(shù)據(jù)安全管控平臺、安全考核平臺等

多環(huán)境幾十種維度的安全風險數(shù)據(jù),整合安全資源,聚合多環(huán)境、多系統(tǒng)數(shù)

據(jù),打造統(tǒng)一安全服務平臺。

2、安全能力場景化:聚焦用戶痛點,提煉用戶應用場景,打造針對性功能

和流程,補齊最后一公里短板。規(guī)劃設計了一鍵修漏洞 / 基線 / 弱口令、密碼

納管自動授權(quán)(動態(tài)授權(quán))、一鍵 Bypass/ 封堵 IP、自助委托策略等 8 個安全業(yè)

畢業(yè)于中山大學網(wǎng)絡工

程專業(yè),現(xiàn)任某金融科技企

業(yè)安全團隊負責人。曾任職

于多家頭部世界 500強企業(yè),

從事網(wǎng)絡安全工作十余年,

熟悉各行業(yè)的信息安全建設

規(guī)劃,對企業(yè)安全合規(guī)、個

人隱私保護、安全治理等方

面有較豐富的經(jīng)驗。

鄭太海

第54頁

52

百家論道 LECTURE ROOM

務場景,為用戶提供基于場景、融入業(yè)務流程的安全服

務能力。

3、安全工作自動化:打通流程斷點 / 阻點,通過平

臺和系統(tǒng)對接,讓數(shù)據(jù)流動起來,讓數(shù)據(jù)多跑路,讓用

戶節(jié)省時間,提高效率,改善體驗。

(1)打通斷點:通過平臺對接,為用戶提供批量修

復漏洞 / 基線便捷功能。

(2)打通流程:通過打通風險數(shù)據(jù)與工單系統(tǒng),實

現(xiàn)漏洞考核申請全流程自動化貫通。

(3)打通系統(tǒng):通過打通堡壘機、特權(quán)系統(tǒng),一體

化平臺實現(xiàn)用戶自助托管主機賬號密碼,即實現(xiàn)自動授

權(quán) / 動態(tài)授權(quán)運維通道使用等等。

三、建設一體化信息安全服務平臺

如圖一所示,一體化信息安全服務平臺具備業(yè)務和

安全兩個視角:上層業(yè)務層是開發(fā)和運維;下層安全層

由下往上依次是安全資源層、模塊層和服務層。我們先

從安全層的最下面安全資源層開始介紹:

1、安全資源層:這里說的資源就是指日常的風險掃

描器,HIDS 主機入侵監(jiān)測和 TIP 威脅情報,還包括了像

研發(fā)安全的代碼掃描、數(shù)據(jù)安全層面的分類分級,以及

終端安全的防病毒托管和基于情報的態(tài)勢感知等等,我

們把它統(tǒng)稱為安全資源層。

2、模塊層:大部分公司在部署這些設備的時候,都

屬于煙囪式的部署,數(shù)據(jù)是割裂的,我們需要把安全資

源層整合成一個個的模塊,我們按照標準的開發(fā)安全、

網(wǎng)絡安全、主機安全、安全管理、數(shù)據(jù)安全等整合成安

全模塊。在這個模塊里面,我們主要關注“安全事務”,

什么叫“安全事務”?就是我們要去處理一件安全的事

情,比如說修復漏洞,以及去關注一些安全的指標,像

口令、基線的及時修復率等,我們需要在不同的模塊里

去定義下來。

3、服務層:模塊層再往上是服務層,服務層是對模

塊層的進一步抽象,是把從安全資源抽象成模塊以后,

再把相應的資源里面的接口抽離出來,然后對外封裝成

一種安全服務,比如開發(fā)安全服務、網(wǎng)絡安全服務、主

機安全服務和安全管理服務等。

最后,也就是最上層的業(yè)務層。從業(yè)務人員的視角

來看,如果你是一個業(yè)務部門的 Leader,登錄平臺時

最關心的內(nèi)容是部門所管理的資產(chǎn)面臨的安全風險有哪

些、有哪些漏洞沒修復、有多少可疑的資產(chǎn)、數(shù)據(jù)安全

層面的有哪些風險。

第二個重要的點是待辦。比如說部門的安全專員登

錄平臺之后,除了看風險之外,還要看他自己的待辦,

要看他的行事日歷,每天要做的安全工作有哪些?比如

說漏洞修復的排期要求是怎樣的、有多少漏洞是這個月

必須要修復的、有多少漏洞是可以等到下個月或者下個

季度去修復的。

自動化模塊

自動化策略配置

腳本管理

運維平臺配置

Ops

服務層 開發(fā)安全服務 網(wǎng)絡安全服務 主機安全服務 安全管理服務

開發(fā)安全模塊

開發(fā)架構(gòu)評審

人工滲透風險審核

應用漏洞配置與研判

風險掃描器 HIDS主機入侵檢測

態(tài)勢感知平臺

TIP威脅情報 SRC應急響應中心

蜜罐系統(tǒng) 風險管理系統(tǒng)

網(wǎng)絡安全模塊

外網(wǎng)高危端口識別

外網(wǎng)漏洞檢測與研判

外網(wǎng)攻擊檢測與確認

NGFW下一代防火墻

CMDB配置中心

數(shù)據(jù)資產(chǎn)管理平臺

WAF應用層防火墻

主機安全模塊

主機漏洞基線配置

口令規(guī)則&弱口令庫

DDoS防御

堡壘機運維審計

主動防御系統(tǒng) 數(shù)據(jù)分類分級平臺

特權(quán)賬號 …

數(shù)據(jù)安全服務 安全自動化服務

Dev

需求 設計 開發(fā) 測試 部署

安全管理模塊

預警通知管理

違規(guī)檢測規(guī)則配置

考核指標管理

應用漏洞管理

納管改密策略

一體化信息安全服務平臺

數(shù)據(jù)安全模塊

數(shù)據(jù)使用策略

分級分類標準

脫敏規(guī)則

運維

網(wǎng)絡安全

外網(wǎng)漏洞

高危端口

外網(wǎng)攻擊

一鍵Bypass

主機安全

主機基線

主機漏洞

一鍵賬號納管

一鍵修復漏洞

安全管理

安全考核

預警中心

員工違規(guī)

委托處理

數(shù)據(jù)安全

加解密

分類分級

數(shù)據(jù)脫敏

Dashboard

風險可視

個人中心

待辦事項

資產(chǎn)中心

開發(fā)安全

代碼安全掃描

研發(fā)安全考核

版本發(fā)布合規(guī)

架構(gòu)風險

滲透測試

應用漏洞管理

模塊層

安全資源層

(圖一 一體化信息安全服務平臺)

第55頁

53

LECTURE ROOM 百家論道

四、超融合安全運維場景

第三個重要的內(nèi)容是場景化,也是業(yè)務人員最關心

的視角之一?;跇I(yè)務視角的信息安全服務平臺被定義

之后,然后去開展一些相應的安全運營工作。

接下來我會舉兩個關于場景化的例子,通過這兩個

例子能夠很好地去解決業(yè)務人員和非安全人員在整個開

發(fā)運營過程當中遇到的問題。

第一個場景我們內(nèi)部叫做超融合安全運維場景(如

圖二)。超融合主要是解決以下問題:

第一個例如圖二的 SSO 單點登錄,我們將它融合進

來進行處理。很多公司上了堡壘機,需要登陸要運維的

目標機器的時候,還要再去登錄一個跳板機,再比如要

去運行很多專業(yè)的命令的時候,必須在一臺跳板機上才

能夠去實現(xiàn),這個時候就需要進行多跳。從第一跳堡壘

機到第二跳目標機,最后到第三跳跳板機,需要輸入三

遍用戶名密碼,如果還有些堡壘機的目標機是基于雙因

素的話,就要輸 4 遍密碼,等待 4 分鐘左右,這種情況

會導致效率較低。所以第一個場景我們是解決 SSO 單點

登錄的問題,就是如何讓用戶登錄一次之后,把 SSO 的

信息帶到各個安全的目標業(yè)務系統(tǒng)里面。

第二個是我們解決了賬號納管,通過超融合的一個

入口,我們可以統(tǒng)一地去納管用戶的主機賬號,然后在

整個主機進行申請的時候,只要投產(chǎn),就會經(jīng)過自動化

的流程把賬號納管進來,也就是通過特權(quán)賬號系統(tǒng)把賬

號輸進來,不用操作者去管密碼了。

第三個解決的是動態(tài)授權(quán)應用。傳統(tǒng)環(huán)境下,用戶

登錄的時候,我們得手動給用戶分配,客戶登錄堡壘機之

后,他能訪問哪些目標機器,這個時候我們可以通過超融

合入口,去打通內(nèi)部的 CMDB(見下圖二右下角 CMDB 的內(nèi)

部配置管理系統(tǒng)),然后去自動確認屬于哪個組織架構(gòu),

再自動分配他自己有權(quán)限的那一部分運維的目標機器。

第四個解決的是主機的自動代填登錄,這一塊是解

決輸密碼的問題,傳統(tǒng)環(huán)境下登錄堡壘機之后再登錄目

標機,還得再輸密碼,這里我們通過 WebSSH 的前端和后

端的一些方式去實現(xiàn)主機密碼的自動代填。

最后是變更安全管控。圖二的左上角有一個工單系

統(tǒng),如果說用戶要進行變更的時候需要讀取申請變更的

工單,然后把工單里的信息提煉出來,比如說有效期,

要訪問的目標機器再給到 SSH 后端,然后把這部分信息

帶到后端之后,再自動地去分配操作窗口,有效期過了

之后,變更工單會自動失效。

所以超融合運維場景是去解決多云環(huán)境下各類問題

的一個復雜性場景,是去解決不同的登錄入口,然后不同

環(huán)境下的資產(chǎn)和事件的處置,包括怎么統(tǒng)一和將流程自動

串聯(lián)起來,以及這些資產(chǎn)和權(quán)限歸屬的自動分配等等。

五、自動化漏洞修復場景

(一)傳統(tǒng)手工修復漏洞方式

傳統(tǒng)環(huán)境下,安全人員會周期性地配置掃描任務(這

里討論的主要是指主機或是組件的漏洞,不包括應用層

(圖二 超融合安全運維場景)

超融合安全運維場景

(統(tǒng)一入口)

跳板機

SSH

主機群

WebSSH前端

SSH

WebSSH后端

(動態(tài)授權(quán))

堡壘機(多云,多套)

SSO單點登錄

密碼代填登錄

密碼代填登錄

(密碼代填登錄)

透傳 透傳

一體化信息

安全服務平臺

特權(quán)賬號

工單系統(tǒng)

(運維賬號托管)

(變更工單授權(quán))

數(shù)據(jù)

同步

運維人員

登錄

獲取資源動態(tài)授權(quán)

CMDB

? SSO單點登錄

? 賬號納管

? 動態(tài)授權(quán)應用

? 主機自動代填登錄

? 變更安全管控

傳統(tǒng)運維方式

云環(huán)境運維方式

第56頁

54

百家論道 LECTURE ROOM

的漏洞)。讓安全人員去配置掃描任務,在指定時間內(nèi)

掃描完之后會經(jīng)過安全人員的評審,手動、人工地去評

審和確定,排除如誤報、資產(chǎn)歸屬不準等情況,然后再

把掃描報告發(fā)給相應的團隊,相應的團隊自己也會再做

第二次評估,利用第二輪評估再去確認哪些是不用修復

的,哪些是誤報。

評估完了以后進入推修環(huán)節(jié),主機團隊或者運維團

隊需要自己打補丁,或者更新一些組件。操作完之后進

入到驗證環(huán)節(jié),會把手工修復的郵件回傳給安全團隊,

去讓安全團隊再次掃描和驗證,基本上是一個 T+1 或者

T+N 的周期。

具體手工修復流程如圖三所示,我們可以看到傳統(tǒng)

的手工修復漏洞方式存在人工修復成本高、比較耗時和

費力,同時也存在效率較低和修復周期長的問題。另外,

部門安全專員收到漏洞推修郵件,需要導出多套環(huán)境的

資產(chǎn)信息,與多套環(huán)境的風險漏洞數(shù)據(jù),進行手動關

聯(lián),得到最終主機運維方或?qū)僦?,再分發(fā)到部門內(nèi)部人

員,且線下跟催和推修,容易遺漏,效率不高。

這個場景既是安全部門的痛點,也是運維部門開發(fā)

部門的痛點。

(二)自動化漏洞修復方式

自動化修復漏洞有幾個方面能做到自動化:

第一個是評審自動化,先制定評審原則,然后將其

沉淀成策略,比如說主機團隊的一些評審的原則,做成

策略之后,然后放到平臺里面,掃出的報告進行自動解

讀,符合策略的,才繼續(xù)往下推修。

第二個是修復自動化,需要針對不同類型的漏洞深

入分析,制定自動修復的腳本,比如說打補丁,補丁源

下什么版本?把它做成腳本之后然后配置在一個固定的

地方,然后通過程序自動地調(diào)用,因此整個腳本的維護

包括了主機團隊、應用團隊以及安全團隊的一些專家共

同組成,大家一起共同來維護主機的腳本。

第三個是驗證自動化,傳統(tǒng)方式的整個驗證是通過

郵件來回確認,時間周期較長,驗證自動化是在運維方

修復漏洞之后,可以點一鍵驗證環(huán)節(jié),去觸發(fā)調(diào)度掃描

器,掃描器掃描目標資產(chǎn)的同時返回掃描結(jié)果,然后通

過平臺反饋給點擊驗證環(huán)節(jié)的用戶,這時候用戶可以知

道哪些是需要修復的,下載的更新包或者補丁是不是有

效的,且能快速得到反饋結(jié)果。

第四個方面是 CMDB 自動化,資產(chǎn)的分配管理,整個

掃描分配環(huán)節(jié)和驗證環(huán)節(jié),都是通過對接 CMDB 進行資產(chǎn)

的自動分配,當然會出現(xiàn) CMDB 數(shù)據(jù)不準的問題。

因此,自動化修復漏洞方式具有自動聚合數(shù)據(jù)的優(yōu)

勢,據(jù)統(tǒng)計效率能較之前以提升大約 60 倍,另外可以精

簡修復動作,用戶只需一步操作。

綜上所述,一體化信息安全服務平臺,聚合多維安

全數(shù)據(jù)(如信息資產(chǎn)、安全設備、系統(tǒng)、網(wǎng)絡信息、數(shù)

據(jù)安全、事件和預警等數(shù)據(jù)),打造滿足安全管理的多個

管理場景:

安全人員 掃描資產(chǎn) 漏洞評估與研判 漏洞分發(fā)與修復 漏洞驗證閉環(huán)

配置任務 專家評審 推修清單

不推修

(誤報/低風險)

漏洞驗證

驗證不通過

豁免/延期

到期重新納入 暫無法修復 推修清單

風險評估專家虛

擬團隊

漏洞評估

手工修復流程示意圖

備注:

部門安全專員收到漏洞推修郵件,需要

導出多套環(huán)境的資產(chǎn)信息,與多套環(huán)境

的風險漏洞數(shù)據(jù),進行手動關聯(lián),得到

最終主機運維方或?qū)僦?,再分發(fā)到部門

內(nèi)部人員,且線下跟催和推修,容易遺

漏,效率不高。

(圖三 手工修復流程示意圖)

第57頁

55

LECTURE ROOM 百家論道

1、基于風險的漏洞全生命周期閉環(huán)管理(含自動化

處理)。

2、基于主機賬號全流程納管與應用(含運維特權(quán)

賬號)。

3、基于數(shù)據(jù)安全的全生命周期線上化、自動化、批

量化處理與管理。

通過多元數(shù)據(jù)整合,系統(tǒng)拉通,圍繞信息安全管理

目標,打造了可支撐和助力業(yè)務價值實現(xiàn)的豐富安全管

理場景和能力,提升企業(yè)信息安全管理水平。

超融合安全運維場景,統(tǒng)一平臺和入口,與一體化

信息安全服務平臺對接,實現(xiàn)動態(tài)授權(quán),密碼自動代填

登錄,SSO 單點登錄等提效功能,實現(xiàn)快速、便捷、安

全的二大安全運營場景,在傳統(tǒng)的運維模式下,創(chuàng)新性

地解決了云計算環(huán)境下快速交付后立即使用的安全運維

場景。

漏洞自動化修復場景,通過與運維管理系統(tǒng)對接,

構(gòu)建了一條自動化安全風險處理通道,定期組織專家開發(fā)

批量安全風險處理腳本,通過一體化信息安全服務平臺,

進行適配、管控、自動下發(fā),輔助安全風險快速處置關

閉,大大提升安全運營效率,減少了處理風險的成本。

六、項目亮點、價值與意義

風險產(chǎn)出效率提升 60 倍:通過拉通多云環(huán)境,多套

安全平臺和系統(tǒng)的多維度風險數(shù)據(jù),進行線上聚合、加

工、關聯(lián)等,產(chǎn)出可直接使用的風險數(shù)據(jù),相較手工作

業(yè)效率提升 60 倍,且每天動態(tài)更新。

漏洞基線自動化修復占比最高達 30%:通過打通運

維平臺,精準從源頭避免,新增與存量共同推進的方

式,打造一鍵自動修復漏洞功能,實現(xiàn)從 0% -30%自動

化修復率。

一鍵自動納管賬號 40% +納管率:通過自動化納

管,新增賬號納管率 100%,存量賬號納管 40%+的納

管率。大大提升效率。同時配合開發(fā)出多種自動代填密

碼登錄的運維應用場景,進一步提升效率。

節(jié)省人力 5 人 / 年:通過 SSO 單點登錄改造,減少

登錄雙因素系統(tǒng),每成功跳轉(zhuǎn) 1 次節(jié)省時間 30 秒,全年

累計節(jié)省人力 5 人 / 年。

主機群

安全人員 掃描資產(chǎn)

1.配置任務

自動評審規(guī)則

自動下發(fā)漏洞清單

專家評審

漏洞評估與研判

漏洞修復腳本庫

一鍵修復 自動驗證閉環(huán)

運維人員 豁免/延期

一體化信息安全服務平臺--自動化漏洞修復場景

2.全量漏

洞清單

編寫腳本

3.推修漏洞清單

(漏洞類型關聯(lián)修復腳本)

4. 收到推修通知

8.自動驗證

5.1 登錄平臺一鍵修復

6. 下發(fā)腳本

5.2 人工申請

9.驗證不通過

(到期自動釋放

重新推修)

7. 執(zhí)行成功

(圖四 自動化修復流程示意圖)

第58頁

56

百家論道 LECTURE ROOM

API 安全與實踐

OWASP 在 2019 年發(fā)布了 OWASP API Top 10 2019 版本,現(xiàn)在是 2023 年,

OWASP 計劃在今年十月份發(fā)布最新的 OWASP API Top 10 2023 版本,本文將根據(jù)

現(xiàn)在預覽狀態(tài)的 OWASP API Top 10 2023 版本針對 API 安全進行說明,并且給

出一些實踐的建議。

OWASP API Top 10 2023 版本包括以下內(nèi)容:

1、失效的對象級授權(quán)

2、失效的認證

3、失效的對象屬性級授權(quán)

4、不受限制的資源消耗

5、失效的功能級別授權(quán)

6、服務器端請求偽造

7、安全性錯誤配置

8、缺乏對自動化威脅的保護

9、資產(chǎn)管理不當

10、API 的不安全使用

針對上面的風險,本文將從描述、例子、測試用例、開源解決方案等方面

進行說明。

一、API 1:失效的對象級授權(quán)

(一)描述

攻擊者可以利用失效的對象級別授權(quán)的 API 端點,通過操縱在請求中發(fā)送

的對象訪問未經(jīng)授權(quán)的敏感數(shù)據(jù)。

這個問題在基于 API 的應用程序中極為常見,因為服務器組件通常不完全

跟蹤客戶端的狀態(tài),而是更多地依賴于從客戶端發(fā)送的對象 ID 等參數(shù)來決定對

象的訪問。

(二)示例場景

在線商店的電子商務平臺提供了一個列表頁面,其中包含其托管商店的收

入圖表。檢查瀏覽器請求,攻擊者可以識別用作這些圖表及其模式的數(shù)據(jù)源的

API 端點 /shops/{shopName}/revenue_data.json。

使用另一個 API 端點,攻擊者可以獲得所有托管商店名稱的列表。

攻擊者通過一個簡單的腳本來操縱列表中的名稱,替換 {shopName},就可

以訪問數(shù)千家電子商務商店的銷售數(shù)據(jù)。

晨星資訊高級安全架構(gòu)

師,OWASP 中 國 廣 東 區(qū) 域 負 責

人、網(wǎng)安加社區(qū)特聘專家,獲得

北京化工大學計算機科學與技術(shù)

學士學位,華中科技大學軟件工

程專業(yè)工程碩士學位。精通 C、

C++、Java、.Net 等多種語言以

及現(xiàn)有的各種流行架構(gòu),在開發(fā)

安全領域深耕 17 年以上,對安

全設計和安全開發(fā)有豐富的實戰(zhàn)

經(jīng)驗。持有 CISSP、AWS 解決方

案架構(gòu)師和 AWS 安全專家等認

證,多次參與安全書籍翻譯工

作,組織、領導和獨立完成多個

OWASP 項目翻譯工作。

肖文棣

第59頁

57

LECTURE ROOM 百家論道

(三)建議

實施依賴于用戶策略和層次結(jié)構(gòu)的適當?shù)氖跈?quán)策略。

使用授權(quán)機制檢查登錄用戶是否有權(quán)訪問通過 URL

指定的資源。

使用隨機或者不可預測的值作為記錄 ID,如 GUID。

編寫測試用例來評估授權(quán)機制的漏洞,不要發(fā)布測

試失敗的變更。

(四)測試用例

1、測試未經(jīng)授權(quán)的用戶是否可以訪問他們不允許訪

問的對象。

2、測試未經(jīng)授權(quán)的用戶是否可以修改不允許他們修

改的對象。

3、測試訪問控制規(guī)則是否在應用程序的所有層都得

到執(zhí)行。

(五)開源解決方案

開發(fā)者使用 JSON Web Tokens (JWT) 用于簡化 API

身份驗證。JWT可以用于實現(xiàn)對象級別的身份驗證和授權(quán)。

Spring Security 是一個強大的開源安全框架,

可 以 用 于 保 護 Java 應 用 程 序 和 REST API。Spring

Security 提供了一系列的安全過濾器和授權(quán)機制,可

以輕松地實現(xiàn)基于角色或基于資源的授權(quán)控制。此外,

Spring Security還提供了基于OAuth2的安全解決方案,

可以用于保護 API 端點和資源服務器。

Auth0 是一款云原生的身份驗證和授權(quán)平臺,可以用

于保護 API 端點和 Web 應用程序。Auth0 提供了一系列的

身份驗證和授權(quán)機制,包括基于角色的訪問控制、屬性

級訪問控制等。此外,Auth0 還提供了社交登錄、多因素

身份驗證等功能,可以大大提高應用程序的安全性。

二、API 2:失效的認證

(一)描述

API 中的身份認證通常比較復雜。人們可能對身份

認證的邊界以及如何正確進行身份認證存在誤解。此外,

身份認證都是公開的,這導致身份認證很容易成為攻擊

者的目標。

公開的 API 在以下情況很容易受到攻擊:

1、允許憑據(jù)填充,其中攻擊者使用暴力破解有效的

用戶名和密碼列表。

2、允許攻擊者對同一用戶帳戶執(zhí)行暴力攻擊,而無

需提供驗證碼 / 帳戶鎖定機制。

3、允許弱密碼。

4、發(fā)送敏感的身份驗證詳細信息,例如 URL 中的身

份驗證令牌和密碼。

5、允許用戶更改自己的電子郵件地址、當前密碼或

執(zhí)行任何其他敏感操作而無不需要密碼確認。

6、不驗證令牌的真實性。

7、 接 受 未 簽 名 或 者 弱 簽 名 的 JWT 令 牌, 如 (

{\"alg\":\"none\"})。

8、不驗證 JWT 到期日期。

9、使用純文本、未加密或弱哈希密碼,如 MD5。

10、使用弱加密密鑰,如 DES。

(二)示例場景

為了執(zhí)行用戶身份認證,客戶端必須使用用戶憑據(jù)

發(fā)出 API 請求:

如果憑據(jù)有效,則返回一個授權(quán)令牌,該令牌應在

后續(xù)請求中提供以識別用戶。登錄嘗試受到嚴格的速率

限制:每分鐘只允許三個請求。

為了對受害者的帳戶進行暴力破解,攻擊者利用

GraphQL 查詢批處理繞過請求速率限制:

(三)建議

確保了解清楚所有可能的進行API身份認證的流程,

包括移動、網(wǎng)絡、實現(xiàn)一鍵式身份驗證的深層鏈接等。

了解身份驗證機制。確保了解身份認證的用途和使

用方式。

不要在身份驗證、令牌生成或密碼存儲方面重新發(fā)

明輪子,而應該使用標準的方法。

在暴力破解、速率限制和鎖定保護方面,憑證恢復

和忘記密碼應作為登錄端點進行限制。

要求對敏感操作重新進行二次身份認證,例如更改

第60頁

58

百家論道 LECTURE ROOM

帳戶所有者電子郵件地址或者更改多因素認證中的電話

號碼等。

參考 OWASP Authentication Cheat Sheet 檢查認證

過程。

盡可能實施多因素認證。

實施反暴力破解機制,以降低對身份驗證的憑據(jù)填

充、字典攻擊和暴力破解攻擊。這種機制應該比 API 上

的常規(guī)速率限制機制更嚴格,特別要防止類似 Graph QL

的批量查詢。

實施帳戶鎖定和驗證碼機制以防止針對特定用戶的

暴力攻擊。實施弱密碼檢查。

API 密鑰不應用于用戶身份驗證,而應該只用于 API

客戶端身份驗證。

(四)測試用例

1、測試身份驗證憑據(jù)是否以純文本或散列格式存儲。

2、測試驗證令牌是否正確存儲和處理。

3、測試是否跨應用程序的不同級別強制執(zhí)行身份驗證。

(五)開源解決方案

開發(fā)者可以使用 OpenID Connect 協(xié)議增強身份認

證。OpenID 可以用于處理多種身份認證,如設備身份認

證,多因素身份認證和智能卡身份認證。

Keycloak 是一個開源的身份和訪問管理解決方

案,支持多種認證和授權(quán)協(xié)議,如 OAuth 2.0、OpenID

Connect、SAML 和 LDAP 等。它提供了 Web 界面和 REST

API,可以方便地進行配置和管理。

Apache Shiro 是一個輕量級的安全框架,提供了

身份驗證、授權(quán)、密碼加密、會話管理等功能。它支持

多種身份驗證方式,如基于表單的身份驗證、基于 HTTP

Basic 和 Digest 認證、CAS 認證等。

三、API 3:失效的對象屬性級授權(quán)

(一)描述

攻擊者可以利用失效的對象屬性級別授權(quán)的 API 端

點來讀取或更改不應該訪問的對象屬性的值。

在以下情況下,API 端點容易受到攻擊:

1、API 端點公開了一個對象的屬性,這些屬性被認

為是敏感的,用戶不應訪問的。

2、API 端點允許用戶更改、添加或刪除用戶不應訪

問的敏感對象屬性的值。

(二)示例場景

一個基于短視頻的社交網(wǎng)絡,強制執(zhí)行限制性內(nèi)容

過濾和審查。即使上傳的視頻被屏蔽,用戶也可以使用

以下 API 請求更改視頻的描述:

攻擊者可以重播合法請求并添加以下惡意負載:

API 端點容易受到攻擊,因為沒有驗證用戶是否有

權(quán)訪問內(nèi)部對象屬性“blocked”,并且用戶可以將值從

“true”更改為“false”并解鎖自己被阻止的內(nèi)容。

(三)建議

1、使用 API 端點公開對象時,請始終確保用戶應該

有權(quán)訪問公開的對象的屬性。

2、避免使用通用方法返回結(jié)果,例如 to_json() 和

to_string()。相反,需要根據(jù)請求要求,返回特定對象

屬性,可以參考最小權(quán)限原則,只返回需要的。

3、盡可能避免使用自動將客戶端輸入綁定到代碼變

量、內(nèi)部對象或?qū)ο髮傩缘暮瘮?shù)。

4、只允許更改應由客戶端更新的對象屬性。

5、實施基于模式的響應驗證機制作為額外的安全

層。作為此機制的一部分,定義并強制執(zhí)行所有 API 方

法返回的數(shù)據(jù)。

6、根據(jù)端點的業(yè)務和功能要求,返回的數(shù)據(jù)結(jié)構(gòu)應

符合最小限度的原則。

(四)測試用例

1、測試未授權(quán)用戶是否可以修改他們不允許的對象。

2、測試應用程序是否在所有層執(zhí)行屬性級授權(quán)規(guī)則。

3、測試未經(jīng)授權(quán)的用戶是否可以訪問他們不允許訪

問的屬性。

(五)開源解決方案

開發(fā)者可以使用基于屬性的訪問控制(ABAC)來管

理用戶訪問權(quán)限和實現(xiàn)屬性級別的授權(quán)。例如,可以使

用 ABAC 來確定哪些用戶可以訪問特定屬性的特定數(shù)據(jù)。

Django Guardian 是一個基于 Django 的授權(quán)框架,

提供了細粒度的訪問控制。它支持基于角色和權(quán)限的訪

問控制,以及基于對象的訪問控制。Django Guardian

第61頁

59

LECTURE ROOM 百家論道

還提供了管理界面和 API。

同樣也可以考慮上文的 Spring Security 和 Apache

Shiro。

四、API 4:不受限制的資源消耗

(一)描述

開發(fā)者只需要簡單的 API 請求,就可以從單個本地

計算機或使用云計算資源執(zhí)行多個并發(fā)請求。

API 請求需要網(wǎng)絡帶寬、CPU、內(nèi)存和存儲等資源。

資源有時候由服務提供商通過 API 集成提供,并按請求

付費,例如發(fā)送電子郵件/短信/電話、生物識別驗證等。

如果缺少限制或限制設置不當(例如太低 / 太高),

則 API 很容易受到攻擊:

1、執(zhí)行超時時間。

2、最大可分配內(nèi)存。

3、最大文件描述符數(shù)。

4、最大進程數(shù)。

5、最大上傳文件大小。

6、在單個 API 客戶端請求中執(zhí)行的操作數(shù)(例如

GraphQL 批處理)。

7、在單個請求 - 響應中返回的每頁記錄數(shù)。

8、第三方服務商消費限額。

(二)示例場景

服務提供商允許客戶使用其API下載任意大的文件。

這些文件存儲在云對象存儲中,并且不會經(jīng)常更改。服

務提供商依靠緩存服務來獲得更好的服務率并保持較低

的帶寬消耗。緩存服務最多只能緩存 15GB 的文件。

當其中一個文件更新時,其大小增加到 18GB。所有

服務客戶端立即開始拉取新版本。由于沒有消費成本提

醒,也沒有云服務的最高成本限制,下一個月的賬單就

會大幅增加,給公司帶來必要的經(jīng)濟損失。

(三)建議

1、使用基于容器的解決方案,可以輕松限制內(nèi)存、

CPU、重啟次數(shù)、文件描述符和進程數(shù)。

2、定義并強制執(zhí)行所有傳入?yún)?shù)和有效負載的最大

數(shù)據(jù)大小,例如字符串的最大長度、數(shù)組中元素的最大

數(shù)量以及上傳文件的最大大?。o論是存儲在本地還是

云存儲中)。

3、限制客戶端在定義的時間范圍內(nèi)與 API 交互的頻

率(速率限制)。

4、應根據(jù)業(yè)務需求微調(diào)速率限制。某些 API 端點可

能需要更嚴格的策略。

5、限制單個 API 客戶端或者用戶執(zhí)行單個操作的次

數(shù)或頻率(例如,OTP 驗證或請求密碼驗證等)。

6、為查詢字符串和請求正文參數(shù)添加適當?shù)姆掌?/p>

端驗證,特別是控制要在響應中返回的記錄數(shù)的參數(shù)。

7、為所有服務提供商的 API 集成配置設置支出限

額。當無法設置支出限額時,應改為配置賬單提醒。

(四)測試用例

1、測試應用程序是否限制單個用戶的資源使用。

2、測試應用程序是否限制一組用戶的資源使用。

3、測試應用程序是否限制了整個組織的資源使用。

(五)開源解決方案

開發(fā)者可以使用限制資源消耗(RCE)來對 API 請求

進行限制,可用于限制 API 的資源消耗。例如,可以限

制每個 API 請求的最大內(nèi)存使用量,最大時間等。

API Rate Limiter 限制 API 的請求速率,防止某些

用戶或攻擊者發(fā)送大量請求。

Fail2ban 監(jiān)視日志文件并禁止惡意 IP 地址的訪問。

Snort 是一個開源入侵檢測系統(tǒng)(IDS),可用于檢

測和防止 DoS 和 DDoS 攻擊。

五、API 5:失效的功能級別授權(quán)

(一)描述

利用漏洞,攻擊者可以通過合法的 API 調(diào)用訪問他

第62頁

60

百家論道 LECTURE ROOM

們不應訪問的 API 端點。這些端點可能會暴露給匿名用

戶或普通的非特權(quán)用戶。API 應用中的這些問題更容易

發(fā)現(xiàn),因為 API 更加結(jié)構(gòu)化,并且很容易預測訪問某些

功能的方式,例如,將 HTTP 方法從 GET 替換為 PUT,或

將 URL 中的“users”字符串更改為“admins”。

查找失效的功能級別授權(quán)問題的最佳方法是對授權(quán)

機制進行深入分析,同時牢記用戶層次結(jié)構(gòu)、應用程序

中的不同角色或組,并提出以下問題:

1、普通用戶可以訪問管理端點嗎?

2、用戶是否可以通過簡單地更改 HTTP 方法(例如

從 GET 到 PUT)來執(zhí)行他們不應訪問的敏感操作(例如

創(chuàng)建、修改或刪除)?

3、X 組的用戶是否可以通過簡單地猜測端點 URL

和參數(shù)來訪問只應向 Y 組的用戶公開的功能 /api/v1/

users/export_all ?

(二)示例場景

在只允許受邀用戶加入的應用程序的注冊過程中,

移動應用程序會觸發(fā)API調(diào)用GET/api/invites/{invite_

guid} 方法。響應包含一個 JSON,其中包含有關邀請的

詳細信息,包括用戶的角色和用戶的電子郵件。

攻擊者復制請求并將 HTTP 方法和端點操縱到 POST/

api/invites/new,此端點只能由使用管理控制臺的管理

員訪問。端點不實施功能級授權(quán)檢查。

攻擊者利用該問題并發(fā)送具有管理員權(quán)限的新邀請:

隨后,攻擊者使用惡意制作的邀請為自己創(chuàng)建管理

員帳戶并獲得對系統(tǒng)的完全訪問權(quán)限。

(三)建議

應用程序應該有一個統(tǒng)一的授權(quán)模塊,該模塊用于

所有業(yè)務功能。通常,這種保護是由應用程序代碼外部

的一個或多個組件提供的。

1、默認情況下,應拒絕所有訪問,要求明確授予特

定角色以訪問每個功能。

2、針對功能級授權(quán)缺陷檢查 API 端點,同時牢記應

用程序和組層次結(jié)構(gòu)的業(yè)務邏輯。

3、確保所有管理控制器都繼承自管理抽象控制器,

該控制器根據(jù)用戶的組或者角色實施授權(quán)檢查。

4、確保常規(guī)控制器內(nèi)的管理功能根據(jù)用戶的組和角

色實施授權(quán)檢查。

(四)測試用例

1、測試未經(jīng)授權(quán)的用戶是否可以訪問他們不允許訪

問的功能。

2、測試未授權(quán)用戶是否可以修改他們不允許的功能。

3、測試應用程序是否在所有層執(zhí)行功能級授權(quán)規(guī)則。

(五)開源解決方案

開發(fā)者可以使用基于角色的訪問控制(RBAC)來管

理用戶訪問權(quán)限和實現(xiàn)函數(shù)級別的授權(quán)。例如,可以使

用 RBAC 來確定哪些用戶可以訪問特定函數(shù)的特定數(shù)據(jù)。

Open Policy Agent(OPA)是一個通用的政策引擎,

可以用于編寫和執(zhí)行各種訪問控制政策,包括基于角色

的授權(quán)、基于屬性的授權(quán)、基于數(shù)據(jù)分類的授權(quán)等。可

以與任何應用程序集成,提供強大的 API 保護功能。

同樣也可以考慮Spring Security和Keycloak等方案。

六、API 6:服務器端請求偽造

(一)描述

利用 SSRF 漏洞,攻擊者需要找到一個接收 URI 作為

參數(shù)的 API 端點,然后訪問提供的 URI。大多數(shù)常見編

程語言的內(nèi)置函數(shù)和庫都存在 URL 解析不一致的問題。

只要 API 在未驗證用戶提供的 URL 的情況下獲取遠

程資源,就會出現(xiàn)服務器端請求偽造(SSRF)的漏洞。

SSRF 允許攻擊者強制應用程序?qū)阂庹埱蟀l(fā)送到意想不

到的目的地,越過防火墻或 VPN 的保護。

現(xiàn)代的應用程序開發(fā)使 SSRF 更加普遍和危險。

第63頁

61

LECTURE ROOM 百家論道

開 發(fā) 人 員 根 據(jù) 用 戶 輸 入 訪 問 外 部 資 源, 如

Webhook、從 URL 獲取文件、自定義 SSO 和 URL 預覽等。

云提供商、Kubernetes 和 Docker 等現(xiàn)代技術(shù)在眾

所周知的路徑上通過 HTTP 公開管理和控制通道。這些通

道很容易成為 SSRF 攻擊的目標。

(二)示例場景

社交網(wǎng)絡允許用戶上傳個人照片。用戶可以選擇從

他們的機器上傳圖像文件,或者提供圖像的 URL。選擇

第二個,將觸發(fā)以下 API 調(diào)用:

攻擊者可以使用 API 端點發(fā)送惡意 URL 并在內(nèi)部網(wǎng)

絡中啟動端口掃描。

攻擊者可以根據(jù)響應時間,判斷端口是否打開。

(三)建議

1、隔離網(wǎng)絡中的資源獲取機制:通常這些功能旨在

檢索遠程資源而不是內(nèi)部資源。

2、盡可能使用白名單。

3、對于遠程源,用戶應從指定的供應商(例如

Google Drive、百度云等)下載資源。

4、URL 方案和端口要確定。

5、給定可接受的媒體類型。

6、禁用 HTTP 重定向。

7、使用經(jīng)過良好測試和維護的 URL 解析器,以避免

因 URL 解析不一致而導致的問題。

8、驗證所有客戶提供的輸入數(shù)據(jù)。

9、不要向客戶端發(fā)送原始響應。

(四)測試用例

1、測試應用程序是否容易受到服務器端請求偽造

(SSRF)攻擊。

2、測試應用程序是否存在惡意文件上傳漏洞。

3、測試應用程序是否容易受到惡意遠程代碼執(zhí)行的

攻擊。

(五)開源解決方案

Blacklist3r 是一種用于檢測潛在的 SSRF 漏洞的工

具,它可以掃描 Web 應用程序和 API 以查找潛在的 SSRF

攻擊點。

Barideki 是一種基于 Python 的 SSRF 漏洞掃描器,

它可以掃描 Web應用程序和 API以查找潛在的 SSRF漏洞。

七、API 7:安全性錯誤配置

(一)描述

攻擊者通常會嘗試尋找未修補的漏洞、常見端點或

未受保護的文件和目錄,以獲得未經(jīng)授權(quán)的訪問。

在以下情況下,API 可能容易受到攻擊:

1、API 堆棧的任何部分都缺少安全強化措施,或者

云服務的權(quán)限配置不當。

2、缺少最新的安全補丁,或者系統(tǒng)已過時。

3、啟用了不必要的功能。

4、HTTP 服務器鏈中的服務器處理傳入請求的方式

存在差異。

5、傳輸層安全性(TLS)缺失。

6、不向客戶端發(fā)送安全或緩存控制指令。

7、跨域資源共享(CORS)策略缺失或設置不當。

8、錯誤消息包括堆棧跟蹤,或公開其他敏感信息。

(二)示例場景

API 后端服務器維護由流行的第三方開源日志實用

程序編寫的訪問日志,支持占位符擴展和 JNDI(Java

命名和目錄接口)查找,默認情況下均啟用。對于每個

請求,都會使用以下模式將一個新條目寫入日志文件:

<method> <api_version>/<path> - <status_code>.

攻擊者發(fā)出以下 API 請求,該請求被寫入訪問日志

文件:

由于日志實用程序的不安全默認配置和寬松的網(wǎng)

絡出站策略,為了將相應的條目寫入訪問日志,同時

擴展請求標頭中的值,日志實用程序?qū)墓粽叩膶ο?/p>

“X-Api-Version”獲取數(shù)據(jù)并執(zhí)行 Malicious.class 對

象遠程控制服務器。

(三)建議

1、可重復的強化過程可快速輕松地部署的環(huán)境。

2、審查和更新整個 API 堆棧的配置的任務。審查應

第64頁

62

百家論道 LECTURE ROOM

包括:編排文件、API組件和云服務(例如S3存儲桶權(quán)限)。

3、持續(xù)評估配置和設置在所有環(huán)境中的有效性的自

動化流程。

4、確保從客戶端到 API 服務器以及任何下游 / 上游

組件的所有 API 通信都通過加密通信通道(TLS)進行,

無論它是內(nèi)部 API 還是面向公眾的 API。

5、具體說明每個 API 可以訪問哪些 HTTP 方法:應

禁用所有其他 HTTP 方法(例如 HEAD)。

6、對預期從基于瀏覽器的客戶端(例如 Web 應用程

序前端)訪問的API實施適當?shù)目缬蛸Y源共享(CORS)策略。

7、確保 HTTP 服務器鏈中的所有服務器(例如負載

平衡器、反向和正向代理以及后端服務器)以統(tǒng)一方式

處理傳入請求以避免不同步問題。

8、在適用的情況下,定義和實施所有 API 響應有效

負載模式,包括錯誤響應,以防止異常跟蹤和其他有價

值的信息返回給攻擊者。

(四)測試用例

1、測試應用程序是否易受常見錯誤配置的影響。

2、測試應用程序是否存在已知漏洞。

3、測試應用程序是否易受不安全默認設置的影響。

(五)開源解決方案

Configuration Audit,對應用程序的配置文件進行

審核,以檢查其中的潛在安全漏洞,并建議如何糾正它

們。其中包括可以使用的命令行工具和腳本,如 OWASP

Dependency-Check 和 PMD 等。

安全配置管理平臺,使用此平臺可以管理應用程序

的配置信息,并確保其安全。例如,使用 HashiCorp 的

Vault 來管理安全憑證或使用 Ansible Tower 管理應用

程序的配置文件。

八、API 8:缺乏對自動化威脅的保護

(一)描述

攻擊者利用了解到的 API 的業(yè)務模型,來查找敏感

業(yè)務流以及自動訪問這些業(yè)務流,從而損害業(yè)務。

自動化威脅變得更有利可圖、更智能且更難防范,

API 通常是攻擊者的目標。

隨著時間的推移,傳統(tǒng)的保護措施(例如速率限制

和驗證碼)變得不那么有效。例如,操作僵尸網(wǎng)絡的攻

擊者可以繞過速率限制,因為攻擊者可以在幾秒鐘內(nèi)從

全球數(shù)千個位置或者 IP 地址輕松訪問 API。

易受攻擊的 API 本身不一定有實現(xiàn)錯誤,只是簡單

地公開一個業(yè)務流程,例如買票或發(fā)表評論,而沒有考

慮如果以自動化方式過度使用這些功能會對業(yè)務造成怎

樣的損害。

(二)示例場景

拼車應用程序提供推薦計劃,用戶可以邀請他們的

朋友,并為每個加入該應用程序的朋友獲得積分。這筆

信用額度以后可以用作現(xiàn)金來預訂服務。

攻擊者通過編寫腳本來自動執(zhí)行注冊過程來利用此

流程,每個新用戶都會向攻擊者的錢包中添加信用。

攻擊者以后可以享受免費乘車或出售信用過多的帳

戶以換取現(xiàn)金。

這就是所謂薅羊毛。

(三)建議

緩解計劃應分兩層進行:

1、業(yè)務上:確定如果過度使用可能會損害業(yè)務的業(yè)

務流程。

2、技術(shù)上:選擇正確的保護機制來降低業(yè)務風險。

3、一些保護機制更簡單,而另一些則更難實施。以

下方法用于減緩自動威脅:

4、設備指紋識別:拒絕向意外客戶端設備(例如無

頭瀏覽器)提供服務往往會使攻擊者使用更復雜的解決

方案,這會增加攻擊者的成本。

5、人體檢測:使用驗證碼或更高級的生物識別解決

方案。

6、機器人模式檢測:分析用戶流以檢測機器人模式

(例如,用戶在不到一秒內(nèi)訪問“添加到購物車”和“完

成購買”功能)。

7、考慮阻止 Tor 出口節(jié)點和知名代理的 IP 地址。

8、保護和限制對機器直接使用的 API 的訪問(例如

開發(fā)人員和 B2B API)。

(四)測試用例

1、測試應用程序是否容易受到自動化攻擊。

2、測試應用程序是否可以檢測和響應惡意流量。

3、測試應用程序是否可以保護自己免受惡意腳本的

侵害。

(五)開源解決方案

第65頁

63

LECTURE ROOM 百家論道

ModSecurity 是一個開源的 Web 應用程序防火墻

(WAF),可用于保護 API 免受自動化威脅的攻擊。它可

以檢測并防止暴力破解、DDoS、機器人掃描和爬蟲攻擊

等常見威脅。ModSecurity 具有靈活的規(guī)則集,可以根

據(jù) API 的需求進行定制。

Fail2ban 是一個開源的入侵防范系統(tǒng)(IPS),可用

于保護 API 免受暴力破解和 DDoS 攻擊等自動化威脅。它

可以監(jiān)視 API 的日志,并根據(jù)配置的規(guī)則集自動封鎖攻

擊者的 IP 地址。

九、API 9:資產(chǎn)管理不當

(一)描述

攻擊者通常通過 API 的舊版本或未打補丁且使用較

弱安全要求的端點進行未經(jīng)授權(quán)的訪問。攻擊者可能會

通過管理不善的第三方接口訪問敏感數(shù)據(jù)。

API 經(jīng)常沒有清晰的文檔,包括:

1、API 目的不明確,以下問題沒有明確的答案:

(1)API 在哪個環(huán)境中運行(例如生產(chǎn)、暫存、測

試、開發(fā))?

(2)誰應該擁有 API 的網(wǎng)絡訪問權(quán)限(例如公共、

內(nèi)部、合作伙伴)?

(3)哪個 API 版本正在運行?

2、沒有文檔或現(xiàn)有文檔沒有更新。

3、每個 API 版本都沒有下線計劃。

4、主機的資產(chǎn)丟失或過時。

(二)示例場景

社交網(wǎng)絡允許獨立應用程序的開發(fā)人員與其集成。

作為此過程的一部分,需要最終用戶同意,因此社交網(wǎng)

絡可以與獨立應用程序共享用戶的個人信息。

社交網(wǎng)絡和獨立應用程序之間的數(shù)據(jù)流沒有足夠

的限制或監(jiān)控,允許獨立應用程序不僅可以訪問用戶信

息,還可以訪問所有朋友的私人信息。

一家咨詢公司構(gòu)建了一個惡意應用程序并設法獲得

270,000 名用戶的同意。由于該漏洞,該咨詢公司設法

訪問了 50,000,000 名用戶的私人信息。后來,咨詢公司

出于惡意目的出售這些信息。

(三)建議

1、全部 API 資產(chǎn)記錄在案,重點關注 API 環(huán)境(例

如生產(chǎn)、暫存、測試、開發(fā))、誰應該擁有主機的網(wǎng)絡訪

問權(quán)限(例如公共、內(nèi)部、合作伙伴)和 API 版本。

2、資產(chǎn)綜合服務并記錄 API 的重要信息,例如 API

在系統(tǒng)中的作用、交換的數(shù)據(jù)(數(shù)據(jù)流)及其敏感性。

3、記錄 API 的所有方面,例如身份認證、錯誤、重

定向、速率限制、跨源資源共享(CORS)策略和端點,

包括調(diào)用參數(shù)、請求和響應。

4、采用開放標準 Open API 自動生成文檔。在 CI/

CD 管道中包含文檔構(gòu)建。

5、使 API 文檔僅供獲得 API 使用授權(quán)的人員使用。

6、對 API 的所有版本都要妥善保護,而不僅僅是當

前生產(chǎn)版本。

7、避免將生產(chǎn)數(shù)據(jù)用于非生產(chǎn) API 部署。如果不可

避免的,這些端點應該得到與生產(chǎn)端點相同的安全保護。

8、當較新版本的 API 包含安全改進時,執(zhí)行風險分

析以告知舊版本所需的緩解措施。例如,是否可以在不

破壞 API 兼容性的情況下向后移植改進,或者是否需要

快速移除舊版本并強制所有客戶端遷移到最新版本。

(四)測試用例

1、測試應用程序是否存在資產(chǎn)泄漏漏洞。

2、測試應用程序是否容易受到未經(jīng)授權(quán)訪問資產(chǎn)數(shù)

據(jù)的影響。

3、測試應用程序是否容易受到資產(chǎn)數(shù)據(jù)操縱的影響。

(五)開源解決方案

SwaggerHub 是一個 API 設計和開發(fā)平臺,可以幫助

開發(fā)人員更好地管理他們的 API 資產(chǎn)。SwaggerHub 包括

一個集成的版本控制系統(tǒng),允許用戶跟蹤 API 版本,并

對其進行更改。

第66頁

64

百家論道 LECTURE ROOM

Kong 是一個基于 OpenResty 的云原生 API 網(wǎng)關和服

務網(wǎng)格。Kong 提供了豐富的功能,如路由,負載平衡,

插件等,以幫助開發(fā)人員更好地管理 API 資產(chǎn)。

十、API 10:API 的不安全使用

(一)描述

開發(fā)人員傾向于信任但不驗證與外部或第三方 API

交互的端點。攻擊者成功利用這些 API 中的安全漏洞可

能會訪問他們不應該訪問的數(shù)據(jù)。

在以下情況下,API 可能容易受到攻擊:

1、通過未加密的通道與其他 API 交互。

2、在處理數(shù)據(jù)或?qū)⑵鋫鬟f給下游組件之前,沒有正

確驗證和凈化從其他 API 收集的數(shù)據(jù)。

3、盲目重定向。

4、不限制可用于處理第三方服務響應的資源數(shù)量。

5、不為與第三方服務的交互設置超時。

(二)示例場景

API 與第三方服務提供商集成,以安全地存儲敏感

的用戶醫(yī)療信息。使用如下所示的 HTTP 請求通過安全連

接發(fā)送數(shù)據(jù):

攻擊者找到了一種破壞第三方 API 的方法,攻擊者

開始以 308 永久重定向響應前一個請求。

由于 API 盲目重定向,API 會重復包含用戶敏感數(shù)

據(jù)的完全相同的請求,但這次返回的對象是攻擊者的服

務器,從而導致敏感數(shù)據(jù)泄漏。

(三)建議

1、在評估服務提供商時,評估他們的API安全狀況。

2、確保所有 API 交互都通過安全通道(TLS)進行。

3、在使用之前始終驗證并正確處理從集成 API 接收

的數(shù)據(jù)。

4、維護一個白名單,只允許集成的 API 可能重定向

到白名單的地址,不要盲目重定向。

(四)測試用例

1、測試應用是否存在通過 API 注入攻擊的漏洞。

2、測試應用程序是否容易通過 API 繞過身份驗證。

3、測試應用是否存在 API 會話劫持漏洞。

(五)開源解決方案

OpenAPI Security 是一個基于 OpenAPI 規(guī)范的 API

安全框架,可以幫助用戶進行 API 設計和開發(fā),以減少

API 的安全風險。OpenAPI Security 提供了許多安全檢

查和控制,如身份認證、授權(quán)、輸入驗證和輸出驗證等。

API Fortress 是一個基于云的解決方案,提供 API

測試和監(jiān)控功能。API Fortress 可以幫助用戶進行身份

驗證和授權(quán),同時對API請求進行輸入驗證和輸出驗證,

防止惡意攻擊。

十一、總結(jié)

OWASP API Security Top 10 2023 版本是最全面和

最新的 API 最關鍵安全風險列表。該列表反映了不斷變

化的威脅形勢,包括近年來出現(xiàn)的新風險。大家可以結(jié)

合該列表去檢查一下自己的 API,看看是否有影響。

另外本文提供了開源解決方案,所以 API 安全首先

是意識上的,然后才是對應的解決方案。希望大家共同

努力,把 API 安全做好。

第67頁

65

LECTURE ROOM 百家論道

甲方的個人信息保護實踐

一、解碼個人信息保護法律法規(guī)體系

(一)法律法規(guī)體系

在開展個人信息保護之前,一定要梳理國家層面的法律法規(guī)和標準,比如

《國家安全法》、《網(wǎng)絡安全法》、《數(shù)據(jù)安全法》、《個人信息保護法》、《數(shù)據(jù)出

境安全評估辦法》、《網(wǎng)絡安全審查辦法》、《個人信息出境標準合同辦法》、《兒

童個人信息網(wǎng)絡保護規(guī)定》等等。這些內(nèi)容都可以通過對應的渠道查找,法律

可以通過中國人大網(wǎng)查詢,法規(guī)可以在監(jiān)管機構(gòu)在國家網(wǎng)信辦、中國人民銀行

等機構(gòu)查詢,國家標準可以在信安標委查詢。

通過分析近幾年國家出臺的相關法律法規(guī)和政策文件,我們會發(fā)現(xiàn)網(wǎng)絡安

全相關的立法速度越來越快,其多項配套措施也逐漸完善。從近幾年的國家網(wǎng)

絡安全周活動,以及網(wǎng)絡安全事件的處罰,我們也發(fā)現(xiàn)執(zhí)法活躍且嚴厲,而且

是多頭合作監(jiān)管,其顆粒度是全球最細的,比如滴滴處罰事件,被罰金額約占

上一年營業(yè)額的 5%,接近法律處罰力度的上限,涉及網(wǎng)信辦、公安部等多個監(jiān)

管部門。而且,出臺的法律法規(guī)除了應對國內(nèi)風險外,還能反制境外規(guī)則,特

別是美國的長臂管轄。

除此之外,近兩年大家的網(wǎng)絡安全意識不斷提升,法律也賦權(quán)用戶,大家

更加注重保護自己的個人權(quán)益,對應的司法案例也呈爆發(fā)式增長,個人用戶的

投訴舉報能力也越來越高。雖然有數(shù)據(jù)泄露和數(shù)據(jù)濫用的風險,但所造成的個

人安全事件越來越少了。

(二)個人信息范疇和處理要求

個人信息:以電子或者其他方式記錄的與已識別或者可識別自然人有關的

各種信息,如姓名、手機號、生日、住址、財產(chǎn)、人臉識別、指紋、掌紋等;

不包括匿名化處理后的信息。

個人信息處理:個人信息處理包括個人信息的收集、存儲、使用、加工、

傳輸、提供、公開、刪除等。

諸子云上海會長、某跨

國企業(yè) CSO、網(wǎng)安加社區(qū)特

聘專家、專利發(fā)明人,歷任

多家金融機構(gòu)、世界 500 強

企業(yè)的安全負責人、安全專

家。有近 20 年科技風險、信

息安全、數(shù)據(jù)安全、業(yè)務安

全等領域的豐富經(jīng)驗,是多

家機構(gòu)的專家和顧問。

趙 銳

我們知道,做安全在和業(yè)務部門或技術(shù)部門溝通的時候,通常都會涉及到

敏感信息的監(jiān)管合規(guī)問題,要熟悉國家的法律法規(guī)、安全標準等等,因此本次

內(nèi)容將從解碼個人信息保護法律法規(guī)體系和個人信息保護實踐兩個方面展開。

第68頁

66

百家論道 LECTURE ROOM

敏感個人信息:一旦泄露或者非法使用,容易導致

自然人的人格尊嚴受到侵害或者人身、財產(chǎn)安全受到危

害的個人信息;包括生物識別、宗教信仰、特定身份,

醫(yī)療健康、金融賬戶、行蹤軌跡等信息,以及不滿十四

周歲未成年人的個人信息。

個人信息處理者:是指在個人信息處理活動中自主

決定處理目的、處理方式的組織、個人。

處理個人信息時,應當遵循合法、正當、必要和誠

信原則,不得通過誤導、欺詐、脅迫等方式處理個人信

息。尤其個人信息出境涉及到《數(shù)據(jù)出境安全評估辦法》

和《個人信息出境標準合同辦法》,個人信息數(shù)量達到

百萬量級或向境外提供個人信息達到 10 萬或向境外提供

敏感個人信息達到 1 萬的組織,在面臨數(shù)據(jù)出境時就會

面臨較大的監(jiān)管。所以,企業(yè)的安全負責人要清楚了解,

自己所在企業(yè)收集處理個人信息是不是合法正當。

數(shù)據(jù)收集時需要目的明確,處理個人信息應當具有

明確、合理的目的,并應當與處理目的直接相關,采取

對個人權(quán)益影響最小的方式。

在滿足業(yè)務的情況下,應當限于實現(xiàn)處理目的的最

小范面,不得過度收集個人信息,個人信息處理者應當

對其個人信息處理活動負責。另外,處理個人信息應當

遵循公開、透明原則,公開個人信息處理規(guī)則,明示處

理的目的、方式和范圍。

在處理個人信息時,應當保證個人信息的質(zhì)量,

避免因個人信息不準確、不完整對個人權(quán)益造成不利影

響。同時,個人信息處理者應當對其個人信息處理活動

負責,并采取必要措施保障所處理的個人信息的安全。

二、個人信息保護實踐

我們知道,處理個人信息不可能靠甲方一家公司能

處理完,因為企業(yè)作為個人信息處理者,除了自己需要

使用還會涉及到于第三方的共享,比如轉(zhuǎn)賬,就需要和

銀行分享個人信息。因此在處理個人信息時,要梳理清

楚哪些需要轉(zhuǎn)移處理,哪些需要委托處理,哪些需要共

同控制。

既然有這些情況,首先需要確認數(shù)據(jù)生命周期,如

收集、存儲、使用、加工、傳輸、提供、公開等。另外

還要確認所在組織的生命周期的安全情況,按照實際業(yè)

務場景來開展個人信息保護。

經(jīng)過梳理,企業(yè)的個人信息主要包括三個部分,外

部的客戶、內(nèi)部的員工以及相應的服務商。

(一)企業(yè)客戶數(shù)據(jù)

如圖一所示,是手機銀行的業(yè)務數(shù)據(jù)流,要分析手

機銀行收集使用管理的個人信息合不合法,可以參照《個

人信息保護法》、《常見類型移動互聯(lián)網(wǎng)應用程序必要個

人信息范圍規(guī)定》、《金融數(shù)據(jù)安全數(shù)據(jù)安全分級指南》、

《信息安全技術(shù)個人信息安全規(guī)范》等法規(guī)標準。

基于這一系列的法律法規(guī),可以知道在當前業(yè)務

場景下,手機號碼、收款人姓名、證件類型、開戶行信

( i o s 、A n d r i o d )

(圖一 手機銀行業(yè)務數(shù)據(jù)流)

第69頁

67

LECTURE ROOM 百家論道

息是必要非敏感信息,證件號碼、證件有效期、銀行卡

號、口令、存款信息、交易和消費記錄、指紋和人臉識

別是必要且敏感的信息。

除此之外,還需要根據(jù)某些城市當?shù)氐臈l例來判

斷,比如天津 2020 年頒布條例,規(guī)定不允許收集指紋和

面部識別等生物識別信息。因此,我們在開展個人信息

保護實踐過程中要去分析業(yè)務數(shù)據(jù)流,再對比國家和各

地相關的法律法規(guī)和標準,判斷是否會存在相應的風險。

(二)企業(yè)員工個人信息

從企業(yè)的招聘場景來講,首先企業(yè)會自主發(fā)出招

聘信息,或通過第三方獵頭收集簡歷,經(jīng)過一輪輪面試

以后,就會進入到入職環(huán)節(jié),然后收集員工的姓名、生

日、證件號、住址、黨派、照片、郵箱、電話號碼、健

康數(shù)據(jù)、金融賬戶和家屬信息等。在這些數(shù)據(jù)的收集環(huán)

節(jié)中,可能都會涉及與第三方分享員工的個人信息,比

如與體檢機構(gòu)共享員工的健康數(shù)據(jù),與銀行共享員工的

金融賬戶數(shù)據(jù)等。

在工作過程中還會有差旅,在報銷相關行程車票

時,行為軌跡也會泄露給公司。還有像個人偏好,比如

坐飛機、坐火車,喜歡什么位置,這些相關信息都會被

公司或供應商所獲取。另外很多企業(yè)為了方便考勤,還

會使用生物特征,比如指紋、掌紋、人臉以及虹膜等等。

在此過程中,企業(yè)應做好個人信息保護,有的企業(yè)

可能會有簽署隱私政策,部分企業(yè)的隱私政策可能還在

制定完善中,但都應該重視對個人信息的隱私保護。

(三)實踐技術(shù)解析

如圖二所示,按照數(shù)據(jù)處理生命周期來梳理,在數(shù)

據(jù)采集階段,我們可以做全站的 https 加密,其他的還

可以通過 Keyless CDN、跨 IDC 自動加密、反爬、賬號

安全等措施,如果和微信綁定的,還可以看到 UUID。

在前臺業(yè)務處理的時候,可以通過全程 ticket 鑒

權(quán)、token、sso 等方式。在數(shù)據(jù)存儲時,可以進行相應

的加密。另外在傳輸時,進行通道加密和數(shù)字加密。

在日常訪問和運維階段,通過堡壘機、Debug 脫敏、

監(jiān)控日志脫敏、開發(fā)運維分離等措施進行處理,生產(chǎn)數(shù)

據(jù)轉(zhuǎn)測試環(huán)境時也會脫敏。

在后臺數(shù)據(jù)分析階段,對系統(tǒng)中內(nèi)外部的業(yè)務用戶

數(shù)據(jù)去做相應的加密,特別是數(shù)據(jù)倉庫下的匿名化算法。

在數(shù)據(jù)展示和使用階段,使用添加水印和數(shù)據(jù)防泄

露等措施,同時盡量展示統(tǒng)計數(shù)據(jù)而不是個人數(shù)據(jù)明細

在數(shù)據(jù)共享和再分發(fā)階段,在用戶注冊初期就把隱

私聲明公告出來讓用戶簽署,同時要進行授權(quán)審核和脫

敏等措施,防止下游對信息進行緩存,使用 APP 時要有

相應的安全 SDK。

最后,當企業(yè)不再使用這些個人信息的時候,應

該要進行安全刪除的操作,尤其在云里,用數(shù)據(jù)清除工

具,確保存儲介質(zhì)中的數(shù)據(jù)都被刪除。

三、總結(jié)

實際上,個人信息保護的實踐是基于數(shù)據(jù)生命周期

來開展的。在這些工作中,首先要將數(shù)據(jù)做好分類分級,

針對不同類型的用戶做好授權(quán),基于場景來開展保護工

作。另外,還需要做好資產(chǎn)的梳理,制定并完善流程制

度。從更基礎的角度講,其實需要把人的能力都展現(xiàn)出

來,通過流程和技術(shù),開展個人信息保護工作。

(圖二 實踐技術(shù)解析)

第70頁

68

百家論道 LECTURE ROOM

護網(wǎng)行動和企業(yè)信息安全體

系治理邏輯

資深信息安全專家,網(wǎng)安

加社區(qū)特聘專家,曾任騰訊出行

學院信息安全講師。具備互聯(lián)網(wǎng)

行業(yè)、金融、政務、能源、汽車

出行、通信行業(yè)等領域的信息安

全建設咨詢與培訓的實戰(zhàn)經(jīng)驗,

服務客戶均為行業(yè)頭部企業(yè)。

王 勘

一、來自 17 年的預測

筆者在 2017 年《網(wǎng)絡安全法》頒布之時,就已經(jīng)在法律條文分析中向當時

的業(yè)內(nèi)客戶匯報了關于“護網(wǎng)行動”的開展的預測。其實展開來《網(wǎng)絡安全法》

的法律條文,護網(wǎng)行動的規(guī)劃也數(shù)次被提及。

當時預測的網(wǎng)絡安全建設節(jié)奏應該是,立法及普法、擴大行業(yè)監(jiān)管、提高

演練頻率,當初的預測或者說今天的治理歷程如下圖:

( 一)《網(wǎng)絡安全法》第三十四條規(guī)定:

除本法第二十一條的規(guī)定外,關鍵信息基礎設施的運營者還應當履行下列

安全保護義務:

(四)制定網(wǎng)絡安全事件應急預案,并定期進行演練。

其中的演練包含企業(yè)的自行演練,還包括配合相應監(jiān)管機構(gòu)的聯(lián)合演練。

(二)《網(wǎng)絡安全法》第三十九條規(guī)定:

國家網(wǎng)信部門應當統(tǒng)籌協(xié)調(diào)有關部門對關鍵信息基礎設施的安全保護采取

下列措施:

(二)定期組織關鍵信息基礎設施的運營者進行網(wǎng)絡安全應急演練,提高

應對網(wǎng)絡安全事件的水平和協(xié)同配合能力。

其中,“定期組織”、“應急演練”就是我們今天看到的“護網(wǎng)行動”,而參

與護網(wǎng)行動的大部分企業(yè)其實也就是《網(wǎng)絡安全法》中描述的“關鍵信息基礎

設施”。

(三)《網(wǎng)絡安全法》第五十三條規(guī)定:

國家網(wǎng)信部門協(xié)調(diào)有關部門建立健全網(wǎng)絡安全風險評估和應急工作機制,

第71頁

69

LECTURE ROOM 百家論道

制定網(wǎng)絡安全事件應急預案,并定期組織演練。

負責關鍵信息基礎設施安全保護工作的部門應當制

定本行業(yè)、本領域的網(wǎng)絡安全事件應急預案,并定期組

織演練。

這條規(guī)定指導了省級單位、行業(yè)監(jiān)管部門組織的“護

網(wǎng)行動”或“應急演練”。

二、護網(wǎng)行動的意義

提到護網(wǎng)行動的意義就必須了解下國家的網(wǎng)絡安全

治理邏輯:

? 國家層面:立法,維護國家信息空間領土主權(quán)完整。

? 行業(yè)層面:執(zhí)法,轉(zhuǎn)譯法律條紋至具體行業(yè)標準

規(guī)范要求。

? 企業(yè)層面:守法,依托合規(guī)規(guī)范要求建設企業(yè)內(nèi)

部基礎設施及制度流程。

而在信息安全治理過程中,不同的層面關注的點也

不同:

? 企業(yè)關注:企業(yè)安全、企業(yè)利益不被侵犯竊取。

? 行業(yè)關注:行業(yè)穩(wěn)定、業(yè)內(nèi)發(fā)展符合規(guī)范預期。

? 國家關注:國家安全、網(wǎng)絡空間領土主權(quán)完整。

這里也側(cè)面解答了很多網(wǎng)絡安全從業(yè)者和企業(yè)主的

困惑:“我企業(yè)的網(wǎng)絡一直很平穩(wěn),沒出過什么大事兒,

我不想花費這個預算,不做安全行不行?不演習不護網(wǎng)

行不行?”

答案是:不行。享有財產(chǎn)被保護是每個公民和企業(yè)

法人的權(quán)利,保障行業(yè)合規(guī)維護國家網(wǎng)絡空間領土主權(quán)

完整,行業(yè)穩(wěn)定發(fā)展也是各位的義務。

第一是因為我國憲法已經(jīng)規(guī)定了公民的合法的私有

財產(chǎn)受憲法保護。公民的合法的私有財產(chǎn)不受侵犯。這

樣的規(guī)定一是涉及到企業(yè)所服務的用戶的個人財產(chǎn)安全。

第二是企業(yè)在法律意義上其實也是一個完整的“法

人”,其自身利益一樣受法律保護,也就是說其企業(yè)所有

者有義務保障企業(yè)的安全運營。

第三是被定義為關鍵信息基礎設施的行業(yè)牽動了大

量的民生和基礎設施保障問題,一旦遭受到攻擊或出現(xiàn)

信息安全事故對國家和人民的損失是巨大的。

三、護網(wǎng)行動設計的意義

我們先來思考下為什么很多很多網(wǎng)絡安全從業(yè)者和

企業(yè)主會存在著:“我企業(yè)的網(wǎng)絡一直很平穩(wěn),沒出過什

么大事兒,我不想花費這個預算,不做安全行不行?不

演習不護網(wǎng)行不行?”這樣的困惑?其根本原因是因為

我國企業(yè)發(fā)展的周期太短了、速度太快了。相比較于國

外的企業(yè)發(fā)展的歷史沉淀還過于年輕。

在發(fā)展初期的核心目標一定是為了保障市場的繁榮

擴張,保護企業(yè)健康茁壯成長,所以這個階段國家在立

法設置、合規(guī)管控、信息安全建設指導層面給予了相對

微妙且平衡的節(jié)奏,這讓我們擁有了高速增長的 20 年,

但同時也意味著我國大部分企業(yè)的信息安全水平是“不

及格”的,甚至很多企業(yè)是“交白卷”的。

從可持續(xù)發(fā)展的角度出發(fā),我們依舊需要盡快的堵

上這個窟窿。從現(xiàn)有的國際緊張的局勢和競爭格局去看,

信息安全能力也是我國企業(yè)的整體一個短板,很容易被

降維打擊。企業(yè)的安全能力不以人的主觀意志決定水平,

不以安全人才的高低決定水準浮動,企業(yè)的信息安全攻

防線一定是基礎設施加制度流程加響應機制綜合形成一

個整體的有機能力。

護網(wǎng)行動的核心價值是一個相對較低成本的、可以

快速查缺補漏的優(yōu)質(zhì)方法:

是的,和各位印象相反的是,護網(wǎng)行動是所有的建

設方案中,成本最低的。相比于給出一套通用的行業(yè)建

設標準,動輒幾千萬投入的“馬奇諾防線”,護網(wǎng)行動其

實是給企業(yè)一個動態(tài)尋找自身短板的過程,原有的投入

無需浪費,找到企業(yè)核心的短板快速補足。

四、護網(wǎng)行動的誤區(qū)

我來給一個非常武斷的觀點,如果作為一個信息安

全行業(yè)從業(yè)的讀者,在讀到上面兩個篇章的時候只感覺

到了乏味和枯燥,沒有任何共鳴點,那很遺憾您并不是

一位合格的從業(yè)人員,或是在這方面沒有天賦,或是專

業(yè)知識面儲備欠缺。這并非是對筆者的認同感,而是說

第72頁

70

百家論道 LECTURE ROOM

各位對國家在網(wǎng)絡安全空間治理和企業(yè)安全治理的政策

和出發(fā)點并沒有深刻的理解。如果沒有這方面的理解,

那在企業(yè)做信息安全也永遠是與企業(yè)主做成本與預算的

對抗,并不能幫助到企業(yè)切身實地的將信息安全的 ROI

做到最優(yōu)解。

實際上近年來的護網(wǎng)行動,對于很多企業(yè)而言也確

實走到了一個偏門的誤區(qū)。進入到了一種為了護網(wǎng)而護

網(wǎng)的狀態(tài)。

國家設計的護網(wǎng)行動的初衷其實是讓企業(yè)可以以

最小代價的、可迭代的找到自身的企業(yè)信息安全建設路

徑。護網(wǎng)行動本質(zhì)是一場“測評”,其核心的意義不在于

其過程,或者“通過”,而在于企業(yè)能通過本次“測評”,

企業(yè)自身能夠發(fā)現(xiàn)多少的能力缺失,或是內(nèi)部基礎設施

的短板,或是響應機制的短板,或是一些流程的不合

理。當然這其中的原因復雜繁瑣,或有企業(yè)的理解不到

位,或有企業(yè)主的安全意識不足,或有測評監(jiān)管機構(gòu)的

力度過于嚴苛或者因為行業(yè)的“一刀切”。但無論如何對

于一家企業(yè)尤其是中大型企業(yè),如果每年度的信息安全

演習只有一次護網(wǎng)行動,每年集全公司力氣護一次網(wǎng),

那無疑是遺憾的,畢竟真正的“敵人”不會如護網(wǎng)行動

一般一板一眼,手段可控且將手段和威脅以及攻擊周期

提前通知到企業(yè)。

更令人遺憾的是,企業(yè)仍舊習慣利用自己在甲方優(yōu)

勢地位,每年在測評期間“借調(diào)人員”、“借調(diào)設備”,甚

至將護網(wǎng)行動變成了一場分門別類的生意。一個行業(yè)如

此發(fā)展注定是不能持久的,也不能給這個行業(yè)注入任何

新的活力,如此做法的代價也終將有一天會從某些突如

其來的事件中告知我們答案。“作弊”代價的種子早已經(jīng)

埋下,問題是誰來為這樣的錯誤進行買單罷了。

五、依托護網(wǎng)行動的建設思路

企業(yè)該如何利用護網(wǎng)行動的思路,來實現(xiàn)企業(yè)信息

安全的有機建設。這里我們提出一個概念叫做信息安全

彈性能力。其核心思想是:企業(yè)壓根沒必要建設極高成

本的安全馬奇諾防線,只需要建設符合自身水準的安全

能力即可,只需要具備發(fā)現(xiàn)風險的能力以及向監(jiān)管機關

及時匯報的制度和流程。

當然這樣的核心思想也并非筆者杜撰或是原地感悟

出來的,這就是等級保護的核心思想,分級而治。企業(yè)

并不要承擔來自未知的極度不確定的威脅的代價,企業(yè)

只需要做到對應自身企業(yè)標準,有能力響應有能力匯報

即可。這也是為什么各位在護網(wǎng)行動過程中,不只有防

護的過程還要發(fā)現(xiàn)風險及時上報的原因,也在訓練企業(yè)

的響應上報機制。

( 一)其中的建設思路可以參考如下:

1、構(gòu)建自身業(yè)務模型,拆分不同業(yè)務板塊的被損壞

可接受度;

2、分級治理,核心業(yè)務提高檢測以及響應權(quán)重;

3、分層建設,建設以業(yè)務為導向的 IT 基礎設施;

4、流程構(gòu)建,很多企業(yè)缺乏流程響應機制的建設;

5、演習測評,內(nèi)部組織定期演習,交叉演習強化應

對風險的能力;

6、人才培育,構(gòu)建企業(yè)內(nèi)部的人才培養(yǎng)機制,培育

企業(yè)自身的信息安全人才以及 IT 人才的信息安全能力;

7、常態(tài)化培訓,固化信息安全至企業(yè)的文化意識當中。

(二)其中的建設原則如下:

1、合理的分層建設勝過完整的大而全的建設;

2、及時的風險識別機制勝過一味的設備堆疊;

3、高效的匯報機制勝過于大而全的條紋制度;

4、事前的演習成本永遠小于事后的補救;

5、信息安全人才的培育是企業(yè)信息安全工作能持久

化的內(nèi)核;

6、信息安全意識的普及是非常有必要的以便應對數(shù)

字化時代的沖擊。

由于篇幅原因,筆者就不繼續(xù)深入拆解更為詳細的

解決方案和治理經(jīng)驗了,有感興趣的小伙伴可以咨詢網(wǎng)

安加社區(qū)進行詳細了解,本文內(nèi)容僅供參考,不提供任

何實際工作中的指導意見。

第73頁

71

COMMUITY ACTIVITES 百花齊放

AI 激蕩 70 載,ChatGPT 的橫空出世瞬間火爆全網(wǎng),

一周的時間用戶超過百萬。近期,隨著 GPT-4、文心一

言、Google Bard 的迭代與發(fā)布,讓大家領略到了 AI 包

括文字、圖像、代碼、音頻、視頻等內(nèi)容強大的生成能

力,引發(fā)了新一輪的 AI 風暴,熱議不斷。

值得關注的是,人工智能的網(wǎng)絡安全風險也開始暴

露,因涉嫌數(shù)據(jù)泄露意大利禁用 Open AI、三星因引入

ChatGPT 被曝機密資料外泄,ChatGPT 被推至風口浪尖,

又引發(fā)了大家對 AI 安全的新一輪思考。

ChatGPT 會對網(wǎng)絡安全帶來什么樣的革命性影響?

作為安全行業(yè)從業(yè)者應該怎么應對安全風險問題和迎接

機遇與挑戰(zhàn)?未來 ChatGPT 有什么樣的發(fā)展趨勢?

歡迎大家收看網(wǎng)安大咖說第二期:AI 狂飆—ChatGPT

會顛覆網(wǎng)絡安全行業(yè)嗎?我們邀請到人工智能領域?qū)<?/p>

學者李濤博士、某跨國企業(yè)首席安全官趙銳,和兩位嘉

賓主持、樂信集團信息安全中心總監(jiān)劉志誠、網(wǎng)安加學

院院長宋荊漢,四位重磅大咖深度研討、共同論道:

“近日,中國證券業(yè)協(xié)會組織起草了《證券公司網(wǎng)

絡和信息安全三年提升計劃(2023-2025)》。從科技治理

能力、科技投入機制、信息系統(tǒng)架構(gòu)規(guī)劃設計、研發(fā)測

試效能與質(zhì)量、系統(tǒng)運行保障能力和網(wǎng)絡信息安全防護

體系等六個方面提出要求,共計 33 項重點任務。券商可

參照實施,并制定配套實施計劃?!?/p>

《安全提升計劃》作為指導 2023 年至 2025 年券商

提升網(wǎng)絡與信息安全工作的行動指南,券商行業(yè)該如何

參照實施并貫徹落實?行業(yè)甲乙雙方如何提高相應的安

全治理能力以取得成效? 2023 年網(wǎng)絡安全有什么新的技

術(shù)趨勢?

歡迎收看網(wǎng)安大咖說第一期——《拐點已至——2023

安全新風口》,我們邀請到安信證券安全總監(jiān)李維春、

中銀證券科技風險與安全負責人蔣瓊,以及兩位嘉賓主

持——樂信集團信息安全中心總監(jiān)劉志誠、網(wǎng)安加學院院

長宋荊漢,四位重磅大咖共同研討,為您答疑解惑:

網(wǎng)安大咖說第二期 AI狂飆—ChatGPT會顛覆網(wǎng)絡安全行業(yè)嗎?

網(wǎng)安大咖說第一期 拐點已至——2023 安全新風口

掃碼觀看上集 掃碼觀看下集

掃碼觀看視頻

第74頁

72

百花齊放 COMMUITY ACTIVITES

2 月 26 日,網(wǎng)安加社區(qū)舉辦的“ChatGPT 對研發(fā)管

理的沖擊與契機”線下沙龍在深圳成功舉辦。本次活動

邀請到 HW 外聘高級顧問潘繼平老師進行主題分享,吸引

了金融、互聯(lián)網(wǎng)、制造業(yè)等多個行業(yè)的 CEO、管理者和

網(wǎng)絡安全技術(shù)人員的熱情參與。

最近,ChatGPT 在各行各業(yè)掀起了軒然大波,以一

副 AI 全能的姿態(tài)進入到大眾的視野中。尤其在 ChatGPT

通過谷歌 L3 工程師編程面試的消息傳出后,更是在各個

行業(yè)引發(fā)了群體性恐慌,被人工智能取代崗位的情形仿

佛近在眼前,但現(xiàn)實真如此殘酷嗎?

活動開始,潘繼平老師從研發(fā)管理的角度出發(fā),就

AI 對研發(fā)管理帶來的沖擊和如何利用 AI 提升自身價值

等方面進行了闡述。他認為,在當前 ChatGPT 帶來巨大

影響的現(xiàn)狀下,應該積極擁抱它,利用新技術(shù)實現(xiàn)自我

價值的提升。隨后,潘老師分享了他在實際項目管理工

作中對于 ChatGPT 的使用經(jīng)驗,并分享了多款 AI 工具,

希望能幫助大家更高效地工作。

經(jīng)過兩個小時的激烈討論,活動逐漸步入尾聲。本

次活動是今年網(wǎng)安加社區(qū)舉辦的第一場線下沙龍,感謝

大家的參與。今年還會陸續(xù)舉辦多場線下沙龍與論壇活

動,敬請期待。

線下活動 | “ChatGPT 對研發(fā)管理的沖擊與契機”線下沙龍成

功舉辦

線下活動 | 開源安全治理行業(yè)最佳落地實踐私享會成功舉辦

開源技術(shù)廣泛應用,正在引領信息技術(shù)的創(chuàng)新與

發(fā)展,在推動科技創(chuàng)新和數(shù)字化轉(zhuǎn)型方面發(fā)揮著重要作

用,但也面臨安全可控等諸多風險。4 月 1 日,網(wǎng)安加

社區(qū)在深圳星河藝術(shù)中心成功舉辦開源安全治理行業(yè)治

理最佳落地實踐私享會,會議邀請到各行業(yè)開源治理權(quán)

威專家就當下備受關注的議題展開研討,從各專業(yè)領域

分享理論實踐。

會議伊始,網(wǎng)安加學院院長宋荊漢對各參會人員表

示熱烈歡迎。他指出,開源治理已經(jīng)成為全球開源生態(tài)

可持續(xù)發(fā)展的關鍵,涉及到政府、行業(yè)、企業(yè)、社區(qū)等

各方力量,并希望通過此次會議,共同探討開源治理的

問題、思路以及解決方案,以幫助企業(yè)更好地實現(xiàn)開源

治理,促進企業(yè)業(yè)務發(fā)展。

——— 網(wǎng)安加學院院:宋荊漢 微眾銀行開源治理專家叢洋分享了《微眾銀行開源

——— 微眾銀行開源治理專家:叢洋

第75頁

73

COMMUITY ACTIVITES 百花齊放

治理實踐》:就為何需要建設開源治理體系、對企業(yè)開

源治理的思路和企業(yè)進行開源治理的路線展開了分享,

還介紹了企業(yè)開源治理組織“開源管理辦公室”的重要

性及相關職能。最后結(jié)合具體案例,對如何以開源管理

制度和開源治理工具為抓手,落地企業(yè)開源治理要求展

開了詳細介紹。

樂信集團信息安全中心總監(jiān)劉志誠分享了《從建設

到運營——開源軟件治理閉環(huán)之路》,他首先對開源治

理的背景做了簡要介紹,接著介紹了開源軟件風險的分

類,最后分享了開源軟件治理方案,并就開源治理方案

的引入評估、應用審核、可信制品庫、共享知識庫和自

動化編排方面做了詳細介紹。

開源安全治理解決方案專家汪杰分享了《開源安全

治理解決方案分享》,他提出,開源技術(shù)的應用帶來了

大量風險,近幾年開源應用安全事件頻發(fā)、影響巨大,

當前開源技術(shù)監(jiān)管工作已經(jīng)全面鋪開,針對開源檢測技

術(shù),我們需要知道哪些應用用到了開源組件、怎么使用

好開源組件、以及開源組件的安全工作應該如何展開,

最后他就開源治理的總體能力方案進行了闡述分享。

開源大勢浩浩湯湯,各企業(yè)既是開源技術(shù)的使用

者,也能成為開源技術(shù)的貢獻者。大家積極擁抱開源技

術(shù)的同時,也需要共同探索開源治理方案。未來,網(wǎng)安

加社區(qū)將在開源治理政策指引下,積極聯(lián)合各開源治理

標桿行業(yè)、企業(yè),開展各類開源治理技術(shù)分享活動,攜

手各方,為開源生態(tài)建設貢獻力量。

——— 樂信集團信息安全中心總監(jiān):劉志誠

——— 開源安全治理解決方案專家:汪杰

第76頁

74

百花齊放 COMMUITY ACTIVITES

線下活動 | 2023 CI/CD 安全技術(shù)研討會成功舉辦

CI/CD 作為現(xiàn)代軟件開發(fā)的重要工具,為軟件快速

部署和高質(zhì)量交付提供了強有力的支持。2023 年 5 月 13

日,網(wǎng)安加社區(qū)聯(lián)合 OWASP 中國廣東分會在深圳南山共

同舉辦“2023 CI/CD 安全技術(shù)研討會”,會議邀請到各

個行業(yè)的資深技術(shù)專家圍繞 CI/CD 安全最新實踐和行業(yè)

趨勢展開研討。

會議開始,OWASP 廣東分會負責人肖文棣與大家分享

了《OWASP CI/CD Top 10》。他指出,CI/CD 環(huán)境、流程和

系統(tǒng)是現(xiàn)代軟件組織的重要組成部分,OWASP CI/CD Top

10 通過對 CI/CD 相關攻擊向量,以及被重點關注的攻擊

事件和安全漏洞進行廣泛研究,旨在幫助防御者確定其

CI/CD 生態(tài)系統(tǒng)安全的重點領域。

樂信研發(fā)安全負責人楊環(huán)分享了《安全左移的那些

事》,就研發(fā)安全痛點、安全左移必要性與安全左移能力

建設展開分享,其中重點介紹了安全左移的必要性以及相

關能力的建設實踐,并結(jié)合具體實踐案例分享了各個安全

測試環(huán)節(jié)的重點和實踐經(jīng)驗。

某互聯(lián)網(wǎng)公司應用安全專家 Luke 分享了《多維視角

下的 CI/CD 安全實踐思考》,他先是通過一組數(shù)據(jù)分享了

當前安全的嚴峻現(xiàn)狀和 DevSecOps 的重要趨勢,接著通過

對 SDL/DevSecOps 的探討和 CI/CD 實踐思考兩個方面分享

了他的議題,其中 CI/CD 實踐思考部分詳細介紹了能力視

角、評價視角、風險視角和挑戰(zhàn)的內(nèi)容。

某金融科技安全團隊應用安全經(jīng)理周亞軍分享了《企

業(yè) SSDLC 實踐分享》,他從實施 SSDLC 的背景、落地 SSDLC

的實時路徑以及實施的效果與不足等方面展開了精彩分

享,其中在落地階段著重介紹了實施難點、應對措施與取

得的效果,最后他總結(jié)實施 SSDLC 的價值與意義“人力節(jié)

約 41 人年,效率提升 27%,中危以上漏洞下降 73%”。

隨著 CI/CD 在開發(fā)流程中的廣泛應用,CI/CD 安全已

經(jīng)成為企業(yè)保障業(yè)務連續(xù)性和數(shù)據(jù)安全的重要一環(huán)。大家

在擁抱技術(shù)以尋求快速交付的同時,也應積極應對它所帶

來的風險,在最佳安全和快速交付之間尋求適當?shù)钠胶狻?/p>

未來,網(wǎng)安加社區(qū)將繼續(xù)關注行業(yè)趨勢,積極開展各類技

術(shù)分享活動,攜手各方共建安全生態(tài)。

——— OWASP 廣東分會負責人:肖文棣

——— 樂信研發(fā)安全負責人:楊環(huán)

——— 某互聯(lián)網(wǎng)公司應用安全專家:Luke

——— 某金融科技安全團隊應用安全經(jīng)理:周亞軍

第77頁

75

COMMUITY ACTIVITES 百花齊放

第78頁

76

網(wǎng)安加社區(qū)專家團自招募以來,受到了業(yè)內(nèi)人士的

廣泛關注。所謂眾行者遠,智慧與經(jīng)驗方面尤為如此,單

絲不成線,獨木不成林,網(wǎng)安加社區(qū)致力于集合各方專家

和業(yè)內(nèi)資深人士,為行業(yè)提供一個交流與學習的平臺。

未來,在本社群的各類活動中會有越來越多的專家

現(xiàn)身演講,公眾號中也將推出更多知識技能文章,專家

親自下陣,持筆揮墨。與大家共同努力,讓我們社群的

每位成員都能夠獲得更好更快地成長——解困惑、交高

人、拓社圈、創(chuàng)機遇!

網(wǎng)安加社區(qū)專家團專家列表排名以入團時間先后為

依據(jù),持續(xù)更新中 ......

網(wǎng)安加社區(qū)專家團

(專家團入駐聘書)

第79頁

77

資深信息安全專家,曾任騰訊出行學院信息安全講師。具備互聯(lián)網(wǎng)行業(yè)、

金融、政務、能源、汽車出行、通信行業(yè)等領域的信息安全建設咨詢與培訓

的實戰(zhàn)經(jīng)驗,服務客戶均為行業(yè)頭部企業(yè)。

成都極質(zhì)軟件有限公司創(chuàng)始人。美國伊利諾伊州立大學 MBA,6 年海外工

作經(jīng)歷。擁有 20 年 IT 領域從業(yè)經(jīng)驗,涵蓋軟件設計研發(fā)、項目管理、部門

管理、信息安全咨詢、制度建設咨詢等領域。專注于軟件研發(fā)全生命周期體

系建設、企業(yè)數(shù)字化轉(zhuǎn)型升級、基于大數(shù)據(jù)的綜合治理、軟件研發(fā)項目管理

等領域。曾為眾多政府單位、央企、大型金融機構(gòu)提供信息安全規(guī)劃與培訓

咨詢服務。

上海青鎖科技有限公司(麟學堂)創(chuàng)始人。上海交通大學網(wǎng)絡空間安全

學院碩士,資深信息安全專家,曾任某大型央企信息安全主管,有多年甲方

信息安全管理經(jīng)驗,有大量金融行業(yè)、大型國企、政府等項目經(jīng)驗,精通網(wǎng)

絡技術(shù)、信息安全技術(shù),對企業(yè)信息安全建設經(jīng)驗豐富。同時有多年信息安

全培訓經(jīng)驗,曾為國內(nèi)多個大型金融機構(gòu)開展相關培訓。

晨星資訊高級安全架構(gòu)師,OWASP 中國廣東區(qū)域負責人,獲得北京化工大

學計算機科學與技術(shù)學士學位,華中科技大學軟件工程專業(yè)工程碩士學位。精

通 C、C++、Java、.Net 等多種語言以及現(xiàn)有的各種流行架構(gòu),在開發(fā)安全領

域深耕 17 年以上,對安全設計和安全開發(fā)有豐富的實戰(zhàn)經(jīng)驗。持有 CISSP、

AWS 解決方案架構(gòu)師和 AWS 安全專家等認證,多次參與安全書籍翻譯工作,組

織、領導和獨立完成多個 OWASP 項目翻譯工作。

第80頁

78

劉志誠,樂信集團信息安全中心總監(jiān),中科院心理研究所管理心理學博

士,印第安納大學 Kelley 商學院金融碩士(MF),香港理工大學軟件理學與工

商管理(MBA)雙碩士。前中國移動電子認證中心(CMCA)負責人,OWASP 中

國廣東區(qū)域負責人,CSA 大中華區(qū)數(shù)據(jù)安全專家。關注智慧城市,企業(yè)數(shù)字化

過程中網(wǎng)絡空間安全風險治理,對大數(shù)據(jù)、人工智能、區(qū)塊鏈等新技術(shù)在金

融風險治理領域的應用,以及新技術(shù)帶來的技術(shù)風險治理方面擁有豐富的理

論和相關經(jīng)驗。

11 年網(wǎng)絡安全從業(yè)經(jīng)驗,現(xiàn)任某金融企業(yè)安全負責人,持有 CISSP、

27001 LA、等保測評師等證書;從事過企業(yè)安全規(guī)劃和建設、安全運營體系設

計與實踐、安全生命周期管理體系設計與實踐、數(shù)據(jù)安全、滲透測試和等保

測評等工作;參與、承擔多項金融行業(yè)安全標準起草和課題研究工作;曾榮

獲兩次網(wǎng)絡安全技能競賽“一等獎”和福建金融網(wǎng)安技能競賽“五一勞動獎章”。

某金融企業(yè)網(wǎng)絡安全專家,11 年網(wǎng)絡安全從業(yè)經(jīng)驗,曾就職于華為技術(shù)

有限公司,擔任高級安全架構(gòu)師職位。多年專注于網(wǎng)絡安全領域,熟悉各大信

息安全體系以及相關法規(guī)標準,掌握多項前沿技術(shù),在網(wǎng)絡安全與隱私保護方

面具有豐富的管理與實踐經(jīng)驗。熟悉 ISO27001、網(wǎng)絡安全等級保護、GDPR 等

信息安全體系和相關法規(guī)標準,可基于企業(yè)業(yè)務戰(zhàn)略和風險管控制定信息安全

總體規(guī)劃,并推動落地;熟悉主流的安全工具、產(chǎn)品和技術(shù),具備產(chǎn)品架構(gòu)安

全,云、管、端、數(shù)據(jù)安全、安全審計、監(jiān)控運營、隱私保護等各領域信息安

全建設落地經(jīng)驗;熟悉信息安全風險評估、STRIDE 威脅建模工程方法。

OWASP 中國北京分會理事、成都市發(fā)改委經(jīng)濟體制改革智庫成員、川大

技轉(zhuǎn)智谷科技轉(zhuǎn)化中心科學經(jīng)紀人、四川省綿陽市三臺縣公安局反詐中心外

聘專家顧問、中國衛(wèi)生信息與健康醫(yī)療大數(shù)據(jù)學會首屆委員、紫光軟件系統(tǒng)

有限公司成都分公司網(wǎng)絡安全專家顧問、【登峰造極】系列講座聯(lián)合創(chuàng)始人,

獲得《ISO27001 信息安全管理體系認證證書》、《國家技術(shù)轉(zhuǎn)移專業(yè)人員能力

等級培訓初級技術(shù)經(jīng)紀人結(jié)業(yè)證書》。目前公司在重組合并階段,主要在以輔

助國安、公安等執(zhí)法部門打擊犯罪的基礎下,通過國家安全視角,集技術(shù)、

人才、產(chǎn)品等為一體,構(gòu)建多維度的全行業(yè)產(chǎn)業(yè)生態(tài)鏈并覆蓋到每條產(chǎn)業(yè)鏈

的重要節(jié)點,落地到一體化、多元化、可視化,促進自身發(fā)展,補全行業(yè)短

板,推動行業(yè)發(fā)展。

第81頁

79

腦動極光首席信息安全官、OWASP 中國北京區(qū)域負責人、西班牙 UAB 大學

碩士、北京某高校網(wǎng)絡空間安全學院研究生導師、網(wǎng)絡安全研究生實習基地導

師、中國衛(wèi)生信息與健康醫(yī)療大數(shù)據(jù)學會首屆委員,參與編寫 GB/T 39725 健

康醫(yī)療行業(yè)數(shù)據(jù)安全指南、三個健康醫(yī)療行業(yè)標準,榮獲國家三級榮譽證書(技

術(shù)貢獻類)。網(wǎng)絡安全行業(yè)從業(yè)十余年,曾于金融集團、上市企業(yè)及互聯(lián)網(wǎng)企業(yè)、

Top 國企擔任安全負責人角色,負責基礎安全、法務合規(guī)、隱私合規(guī)、安全研發(fā)、

風控及業(yè)務安全、SRC(安全應急響應中心)、數(shù)據(jù)安全、內(nèi)審內(nèi)控等工作。

現(xiàn)任開源網(wǎng)安交付中心總監(jiān),開源項目愛好者。具有軟件開發(fā)、項目管理、

產(chǎn)品設計背景,從事網(wǎng)絡安全行業(yè)十余年,前 IDF 互聯(lián)網(wǎng)威脅情報實驗室執(zhí)

行負責人,負責實驗室產(chǎn)品開發(fā)、安全研究和安全運營工作,曾任互聯(lián)網(wǎng)金

融企業(yè)、SaaS 企業(yè)信息安全負責人,負責安全合規(guī)、IT 審計、軟件安全、基

礎安全、數(shù)據(jù)安全、安全運維和安全研發(fā)等工作,熟悉軟件開發(fā)、研發(fā)管理、

產(chǎn)品設計、SDL 和 DevSecOps。

華為土耳其研究所外聘高級項目顧問,負責華為云應用生態(tài)圈產(chǎn)品線研

發(fā)管理。曾為華為全球技術(shù)服務中心、華為制造 IT 以及華為流程 IT 解決方案

提供等多個部門提供長達 8年的顧問服務。也曾任職環(huán)信科技華南區(qū)項目總監(jiān),

金蝶國際軟件研發(fā)工程師。獲得 PMI-PMP、PMI-ACP、PRINCE2、NPDP、MSP、

P3O 等認證。擁有 1 項國家專利,4 項軟件著作,具有豐富的項目管理實戰(zhàn)經(jīng)驗。

畢業(yè)于北京工業(yè)大學,中國計算機學會(CFF)會員,上海開源協(xié)會預

備個人會員,著有圖書《軟件測試技術(shù)實戰(zhàn) - 設計、工具及管理》、《基于

Django 的電子商務網(wǎng)站設計》、《全棧軟件測試工程師寶典》、《通過案例

玩轉(zhuǎn) JMeter( 微課版 )》。軟件綠色聯(lián)盟 2018 年最佳優(yōu)秀講師第一名獲得者。

先后就職于炎黃新星網(wǎng)絡科技有限公司、中興通訊股份有限公司、意法半導體

(中國)有限公司和愛立信通信(中國)有限公司擔任軟件開發(fā)工程師、軟件

測試工程師,軟件測試經(jīng)理等職務,積累了豐富的軟件研發(fā)測試的理論和實

踐經(jīng)驗。精通軟件測試基礎理論、測試設計、測試管理、安全測試、性能測試、

自動化測試、敏捷測試和 DevOps 測試技術(shù)。從 2015 年起,從事金融、通信、

航空、郵政、高校等企業(yè)的從事軟件測試咨詢和培訓服務。

第82頁

80

騰訊 DevOps 與研發(fā)效能資深技術(shù)專家、騰訊研究院特約研究員,前百

度工程效率專家、前京東 DevOps 平臺產(chǎn)品總監(jiān)與首席架構(gòu)師,曾任埃森哲、

惠普等全球五百強企業(yè)咨詢顧問、資深技術(shù)專家。長期在擁有數(shù)萬人研發(fā)規(guī)

模的一線互聯(lián)網(wǎng)公司,負責研發(fā)效能提升、研發(fā)效能度量體系建設、敏捷與

DevOps 實踐落地及 DevOps 工具平臺研發(fā)工作。作為 DevOps 運動國內(nèi)早期布

道者與推動者,目前是 DevOpsDays 國際峰會中國區(qū)核心組織者,國內(nèi)多個

DevOps、工程生產(chǎn)力、研發(fā)效能領域技術(shù)大會聯(lián)席主席、DevOps 與研發(fā)效能

專題出品人?!堆邪l(fā)效能宣言》發(fā)起人及主要內(nèi)容起草者,EXIN DevOps 全系

列國際認證官方授權(quán)講師、鳳凰項目沙盤授權(quán)教練。著作:《軟件研發(fā)效能提

升實踐》、《軟件研發(fā)效能權(quán)威指南》;譯著:《獨角獸項目:數(shù)字化轉(zhuǎn)型時代的

開發(fā)傳奇》、《價值流動:數(shù)字化場景下軟件研發(fā)效能與業(yè)務敏捷的關鍵》。

東南大學電子工程系本、碩,南京大學 EMBA,PMP,現(xiàn)擔任科大訊飛智慧

城市 BG 軟件質(zhì)量負責人,曾就職于中興通訊、摩托羅拉、趨勢科技、初速度

等國內(nèi)、國際名企,多次負責過質(zhì)量體系從 0 到 1 的搭建,DevSecOps 工具鏈

的建設及在公司內(nèi)的大規(guī)模落地,日活用戶超千人,踐行軟件質(zhì)量與效能改

進的體系化、線上化、自動化、數(shù)據(jù)驅(qū)動化。

近 10 年安全行業(yè)從業(yè)經(jīng)驗,5 年 + 團隊管理經(jīng)驗,長期負責企業(yè)安全建

設,探求安全體驗與效率并存的安全能力和解決方案建設。熟悉公有云安全、

數(shù)據(jù)安全、基礎安全和安全運營等領域,擅長企業(yè)的信息安全解決方案高效

落地,并有體系規(guī)劃和安全運營實踐經(jīng)驗。在企業(yè)安全產(chǎn)品方案選型和建設(特

別是數(shù)據(jù)安全)、解決方案規(guī)劃與落地、安全運營能力體系化建設等方面具

備獨特理解和全過程實踐經(jīng)驗。

第83頁

81

本科畢業(yè)于西南交通大學,碩士畢業(yè)于中南大學,目前中南大學博士在

讀,具備計算機領域?qū)I(yè)背景和根基。先后就職于中國中鐵五局、株洲中車時

代電氣股份有限公司、廣東 OPPO 移動通信有限公司等大型集團企業(yè),目前任

職三一重工股份有限公司信息安全負責人,全面負責三一集團的企業(yè)信息安

全戰(zhàn)略規(guī)劃、企業(yè)安全體系架建、安全人才隊伍建立和培養(yǎng)等。深耕行業(yè)十

余年間以扎實的理論基礎付諸于實踐,緊跟信息化、數(shù)字化時代的發(fā)展與演

進,從戰(zhàn)略到體系,從體系到落地,具有非常豐富的實戰(zhàn)經(jīng)驗。OPPO 和三一

集團工作期間,根據(jù)企業(yè)的不同屬性、不同環(huán)境,都是從 0 到 1 完成了信息

安全隊伍建設,從有到無完成了集團安全體系搭建,帶領團隊一次次突破,

通過戰(zhàn)略規(guī)劃與落地共同支撐企業(yè)數(shù)字化戰(zhàn)略的實現(xiàn)。

畢業(yè)于中山大學網(wǎng)絡工程專業(yè),現(xiàn)任某金融科技企業(yè)安全團隊負責人。

曾任職于多家頭部世界 500 強企業(yè),從事網(wǎng)絡安全工作十余年,熟悉各行業(yè)

的信息安全建設規(guī)劃,對企業(yè)安全合規(guī)、個人隱私保護、安全治理等方面有

較豐富的經(jīng)驗。

諸子云上海會長、某跨國企業(yè) CSO、專利發(fā)明人,歷任多家金融機構(gòu)、世

界 500 強企業(yè)的安全負責人、安全專家。有近 20 年科技風險、信息安全、數(shù)

據(jù)安全、業(yè)務安全等領域的豐富經(jīng)驗,是多家機構(gòu)的專家和顧問。曾在銀監(jiān)會

《金融科技治理與研究》雜志發(fā)表論文《“互聯(lián)網(wǎng) +”環(huán)境下銀行信息安全風

險之應對》,參與并已出版的有《DevOps 三十六計》、《反黑客的藝術(shù)》、《上海

金融信息行業(yè)發(fā)展報告》、《云安全現(xiàn)狀年度報告》、《CSA GDPR 合規(guī)行為準則》、

《從網(wǎng)絡安全轉(zhuǎn)向業(yè)務安全的價值實現(xiàn)》、《信息安全人員如何與業(yè)務人員溝

通》、《云端數(shù)據(jù)安全淺談》、《2020DevSecOps 企業(yè)實踐白皮書》、《亞太數(shù)據(jù)合

規(guī)手冊》、《CISSP 權(quán)威指南(第 8 版)》、《網(wǎng)絡服務安全與監(jiān)控》、《云安全控

制矩陣 (CCM)4.0》、《CSO 進階之路》、《云圖·云途》,即將出版:《零信任安全》、

《網(wǎng)絡安全法律法規(guī)關鍵術(shù)語釋義》。

第84頁

官方公眾號 官方微信號

郵 箱:891929369@qq.com

地 址:深圳市龍華區(qū)民治街道民樂社區(qū)

星河 WORLD 二期 E 棟 4F

百萬用戶使用云展網(wǎng)進行圖文電子書制作,只要您有文檔,即可一鍵上傳,自動生成鏈接和二維碼(獨立電子書),支持分享到微信和網(wǎng)站!
收藏
轉(zhuǎn)發(fā)
下載
免費制作
其他案例
更多案例
免費制作
x
{{item.desc}}
下載
{{item.title}}
{{toast}}