一、序言

本文從產品經理的角度出發，對產品經理的安全職責、產品驅動安全的內涵、工作內容、工作方法、所需安全資源、以及產品經理的安全工作量進行了分析。希望所有產品經理在沒有心理負擔的情況下，有目標、有方法、有資源推進產品安全建設。

二、背景

安全是軟件產品天然屬性的一部分，“無安全不金融”，對于金融軟件產品而言，安全尤為重要，因為客戶總是能夠從各種安全漏洞聯想到他的金融資產安全和個人信息安全。以前偶爾會在一些安全沙龍或峰會聽見同行吐槽，“信息安全說起來重要、做起來次要、忙起來不要”。吐槽背后的原因很復雜，其中很重要的一點是跟產品經理安全意識淡薄、不清楚如何推進產品安全建設有關，比如不重視產品安全屬性、產品安全需求不明確、產品安全資源不充分、產品安全建設無從下手等。本文主要站在產品經理的角度，從產品經理能力維度出發，探討產品經理如何推動產品的安全性建設。

眾所周知，安全性作為軟件產品的天然屬性，從產品定義與規劃角度來看，產品經理對產品安全負有不可推卸的責任，但產品經理如何履行自己的安全職責，業界還沒有給出一個清晰可行的行動方案。

目前，軟件產品安全需求通常是基于開發人員和安全人員的職業常識提出相應的解決方案，比如目前業內比較通用的敏感信息五要素分析方法：

12345

姓名身份證號電話號碼銀行卡信息聯系地址

這種方法簡單易行，但往往不能涵蓋所有的敏感信息，比如

用戶的多系統用戶數據關聯ID（超級ID）。

交易過程中的音視頻等多媒體數據。

各種非結構化的文檔數據，如合同掃描件。

用戶的行為畫像數據等內容。

這些信息均為有價值的敏感數據，顯然不屬于前述的敏感數據范圍，但往往沒有明確的防護要求。從特定業務場景出發，產品經理對敏感數據范圍及其業務價值最有發言權。

三、安全部門的尷尬

前述的敏感信息五要素分析方法是典型的安全驅動產品的方法，即安全部門推動產品相關各團隊的安全工作開展。這種模式存在很多弊端，比如：

安全需求可能不完整，職業常識代替不了特定業務場景的深度分析；

產品各團隊的安全工作資源無法保證，研發團隊有理由認為安全團隊干擾研發計劃，研發進度與資源不變的情況下，額外增加了工作量；

安全部門通常沒機會參與制訂研發計劃，產品研發計劃與安全脫節；

安全團隊高度依賴話語權，強制性驅動往往陷入窘境。

（圖1 安全驅動產品）

眾多的安全實踐表明，安全驅動產品的思路與方法存在眾多弊端，如果反過來，產品驅動安全，讓產品經理明晰自己的安全職責、主動推動產品的安全建設，就會產生對比鮮明的效果。

四、產品驅動安全的合理性

產品驅動安全并非意味著產品經理單一角色推動產品的安全建設，而是說產品經理主動承擔相應的產品安全責任，主動與安全部門一起推動產品的安全建設，由安全驅動產品的單輪驅動轉變為產品驅動安全的雙輪驅動。如下圖所示：

（圖2 產品驅動安全）

安全是軟件產品的天然屬性，是產品經理職責的一部分。同時產品經理作為產品規劃演進與研發資源投入的指揮棒，可以保證研發團隊在安全上的適度投入。通過簡單分析，產品經理承擔產品安全責任，主動推動產品安全建設應該是十分合理的邏輯。

五、產品如何驅動安全

產品經理有意愿做好產品安全，可能會問如下幾個問題：

內容方面，產品經理需要做哪些安全工作；

能力方面，為了完成這些工作，產品經理需要具備什么樣的安全能力；

方法方面，這些安全工作如何做，才能既兼顧產品業務功能研發與安全，又能保持研發敏捷性和項目管理流程不變形；

安全資源，從安全部門和其他部門可以獲取哪些安全支持，來提升自己和研發團隊安全工作的效率和效果，降低安全工作的能力門檻；

工作負擔，安全工作會不會讓產品經理很辛苦，影響其工作品質和生活品質。

為產品經理解決了以上問題，消除其后顧之憂，產品經理才有可能大概率地擁抱安全，從根本上解決研發與安全間的矛盾。

六、產品經理的安全工作內容

產品經理的安全工作內容大致如下：

明確產品安全需求；

保障安全研發資源，將安全工作設定到研發計劃中，并分撥足夠的安全研發資源；

推動研發團隊安全能力建設，確保研發計劃中的安全工作執行到位;

整合周邊安全資源，確保研發計劃中的安全工作執行到位。

（圖3 產品經理的安全工作內容）

6.1 明確產品安全需求

產品安全需求是指站在業務角度，軟件產品需要滿足的數據安全需求、業務合規需求和業務連續性要求，它是業務安全需求的一部分。本文描述的產品安全需求通常包括：

產品承載的業務數據安全防護需求，主要關注點是業務數據的機密性和完整性。

產品相關信息的安全監管要求，如等級保護、行業信息安全監管等要求。

產品承載的業務連續性要求。由于通常由數據中心或運維部門統一牽頭實施該項任務，本文將不會展開描述該項內容。

（圖4 產品安全需求）

6.2 產品數據安全需求

產品數據安全需求是指系統安全體系應確保恰當的用戶在恰當的時間與地點以恰當的途徑用恰當的動作訪問恰當的數據，確保其承載數據的機密性、完整性和可用性。即系統安全體系應確保類似于白名單的合法訪問行為清單，只要屬于清單范圍內的行為均為合法行為，白名單行為之外的行為都是默認不恰當的數據訪問行為，需要安全措施進行預防，本文稱之為黑名單行為。

由于黑名單行為通常為黑客攻擊行為，其典型行為的分析與羅列需要較強的攻防技術背景，不在業務人員和產品經理能力范圍之內，需要安全專家根據產品運行環境進行分析，所以本文要求產品經理明確的產品安全需求通常為其白名單部分，黑名單部分需要產品經理組織安全專家和研發專家配合明確。產品設計所包含的各種安全措施主要目標就是確保白名單行為一定成功，黑名單行為一定被預防、監控和審計。

從業務安全角度出發，定義合法數據訪問行為之后，還需要有數據訪問行為審計手段，幫助業務確保訪問行為的正確性，以及對違規的數據訪問行為進行審計。

（圖5 產品數據安全需求）

基于上文分析，白名單行為清單的明確只需要了解業務模型相關信息就可以做到，對于產品經理而言，不存在能力上的門檻。過程中產品經理需要明確的數據包括：

ID內容說明

1合法用戶清單系統用戶類別、辦公地點與訪問方式，用戶類別應包括有接口調用關系的對端系統

2敏感數據清單敏感數據范圍與清單，及其分類、分級說明

3業務訪問行為清單系統用戶與敏感數據之間的訪問映射關系與操作方式清單

4敏感行為清單需要記錄業務操作日志的最小集合，為業務審計提供依據，該清單與上面的業務訪問行為清單基本重合

在明確上述信息的過程中，產品經理應遵循如下兩個原則：

ID原則解釋

1最小權限將用戶對數據的訪問操作的方式和動作最小化，如對于某個用戶類別，OA網訪問可滿足業務需求的就不應開放到外網訪問，數據脫敏可讀可滿足業務需求的情況應不開放明文可讀或可寫權限

2知所必需將用戶的數據訪問范圍最小化，如對于某個用戶類別，單個文件訪問可以滿足業務需求，決不開放2個或多個文件訪問

設計人員可以根據該白名單進行權限管理與訪問控制模型設計，測試人員可以將白名單作為數據安全測試基線，任何違背白名單的測試發現均為系統的安全bug，比如：

敏感數據未脫敏。

多余的數據操作權限。

橫向或縱向數據訪問越權。

關鍵行為的日志痕跡缺失。

6.3 合規性需求

合規性需求是指由于系統運行地點、服務網絡以及客戶所在地區或國家相關部門，對服務提供模式、數據安全以及業務連續性提出了限制性要求。目前公司系統所面對的主要監管要求包括：

ID監管要求監管層級

1網絡安全法及其兩高釋法（國家）國家

2信息系統等級保護（公安部）公安部

3個人信息保護規范（工信部）工信部

4GDPR（涉及到服務歐盟公民的相關IT服務）歐盟

2019年國家相關部門提出了一系列App收集個人信息相關監管要求：

ID名稱時間發文部門

1關于開展App違法違規收集使用個人信息專項治理的公告2019/1/25中央網信辦、工業和信息化部、公安部、市場監管總局

2移動互聯網應用基本業務功能必要信息規范2019/6/1全國信息安全標準化技術委員會

3App違法違規收集使用個人信息自評估指南2019/3/1APP專項治理工作組

4App違法違規收集使用個人信息行為認定方法（征求意見稿）2019/5/5APP專項治理工作組

5信息安全技術 移動互聯網應用程序（App）收集個人信息基本規范（草案）2019/10/25全國信息安全標準化技術委員會

6關于開展APP侵害用戶權益專項整治工作的通知2019/11/6工業和信息化部

在產品經理羅列出合規要求、安全部得到相關部門的權威解釋后，與產品線溝通建議各種安全措施設計，將會在很大程度上滿足IT安全合規要求。等級保護相關要求為所有系統需要面對的共通要求，無需產品經理羅列，安全部可以直接解釋。

關于具體安全需求的定義與維護方法，筆者將通過其他文章進行說明。

七、產品經理安全能力分析與建設

分析產品經理的安全工作內容，最主要的考驗來自于明確業務安全需求的四個清單。相關安全能力分析如下表：

ID產品經理安全需求工作內容能力分析

1明確合法用戶清單無需額外能力，需要描述模板支持

2明確敏感數據清單需要理解安全基礎概念，在指定敏感數據安全等級時，需要敏感數據分類分級標準支持，需要模板支持

3明確業務訪問行為清單無需額外能力，需要描述模板支持

4明確敏感行為清單無需額外能力，需要描述模板支持

產品經理其他安全開發工作所需能力分析如下：

ID工作內容能力分析

1保障安全研發資源在產品迭代研發計劃中增加安全相關活動與環節，并指定責任人。計劃制訂本身無需額外能力，但在安排相關安全活動時，為保持開發的敏捷性和現有的項目管理機制不變形，需要安全、質量管理和項目管理等部門提供方法論支持。需要產品經理有一定的安全意識。

2推動研發團隊安全能力建設為了保證迭代研發計劃中的活動執行成功，研發團隊（設計、開發和測試）需要較高的安全意識和一些基礎的安全能力，如安全設計、安全編碼和安全測試。安全部應統籌各團隊的安全能力建設需求，提供相關安全能力建設支持。需要產品經理有一定的安全意識。

3整合周邊安全資源為了保證迭代研發計劃中的活動執行成功，需要整合周邊部門的專業性安全服務，比如安全部的各類安全評審服務、威脅建模、代碼審計、滲透測試、流量實時監控等服務，基礎研發部的SSO平臺，運維的統一身份管理服務等等。甚至需要法務與合規等部門的安全支持。安全部門有責任提供和維護一份持續可用的安全服務清單，讓產品經理和研發團隊知曉服務清單，并知曉何處獲取相關安全服務。需要產品經理有一定的安全意識。

綜上所述，產品經理要履行相關安全職責，必要的能力和素質是具有較高安全意識，能夠理解相關安全基礎概念，沒有過高的能力門檻，通過一定的安全培訓，產品經理完全可以達到相應的能力要求。

八、產品安全研發方法

針對目前敏捷開發與DevOps開發普遍落地的情況，安全開發不應固守與瀑布開發相結合的陳舊經驗。因為瀑布開發周期長、資源充分，在繁雜的計劃活動中安排一些零星的安全活動不會產生明顯的延期壓力和資源壓力。而敏捷開發和DevOps開發要求快速響應用戶需求的同時，兼顧開發質量與效率，如果在迭代計劃中設置過重的安全開發活動，迭代開發容易失去敏捷特性。

為了將安全開發理念在敏捷與DevOps開發中得到貫徹，建議采用如下原則：

安全開發活動輕量化。輕量化可以通過工具化、自動化來實現，盡量減少人工耗費大和耗時長的安全開發活動；

安全開發活動分散化。將那些短期無法輕量化處理的安全開發活動分解并分散到多個迭代周期中執行；

安全開發活動并行化。將安全開發相關活動與其他活動并行，如滲透測試通常安排在測試的最后一個環節，避免單輪次滲透測試無法覆蓋那些并行的修復點，當然滲透測試也可以由多個輪次來彌補這種情況，但通常資源不允許。實際上這種同步修復導致滲透測試覆蓋率下降的問題，完全可以通過良好的溝通和團隊文化建設進行彌補。

優化現有敏捷開發與DevOps相關的流程與工具平臺，使得安全專家能夠充分參與項目，提升安全開發溝通效率，快速獲取安全反饋；

將安全專家納入到敏捷開發和DevOps文化建設中來，信息安全人人有責，安全專家可以充分發揮教練員角色和守門員角色，使得團隊人人有能力履行自己的安全職責，安全專家在恰當的時機對安全交付物進行質量把控；

提前進行安全基礎設施規劃與布局，如身份與權限管理系統、SSO系統、加解密平臺與SDK、日志分析與監控平臺、全流量檢測平臺等等，使得安全措施標準化、服務化和平臺化，降低安全設計與編碼的能力門檻，對安全基礎設施的測試與驗證取代設施所承載應用的大部分安全測試，可以有效消減安全測試工作量。

對于一些安全開發活動的計劃安排示例如下：

ID安全活動名稱迭代執行要求觸發場景與基線示例

1創建產品安全需求名單一次性執行產品原型發布之前

2維護產品安全需求白名單每迭代執行

3評審產品安全需求白名單多迭代執行重大需求變更或累積變更開發量達到n人天

4創建產品數據流圖一次性執行產品原型發布之前

5建立威脅初始模型一次性執行產品原型發布之前

6維護威脅模型每迭代執行重大需求變更或累積變更開發量達到n人天

7評審威脅模型多迭代執行重大需求變更或累積變更開發量達到n人天

8安全設計評審多迭代執行重大需求變更或累積變更開發量達到n人天

9代碼掃描及其報告分析（開發）每天/迭代執行

10代碼掃描及其報告分析（安全部）多迭代執行重大需求變更或累積變更開發量達到n人天

11深度黑盒安全掃描每天/迭代執行

.........

上表中“多迭代執行”指的是按照一定要求，間隔多個迭代后執行一次。關于多迭代執行的安全活動需要制訂一個執行基線，該基線無標準可參考，需要根據各產品線實際情況逐漸摸索調整。

安全活動的觸發場景與基線不是固定的，隨著團隊安全能力與自動化、工具化程度的提高，多迭代執行的安全活動可能轉變為每迭代執行；不是所有識別出來的安全活動都必須執行，一切以控制主要安全風險、不拖迭代項目后腿為基準。通常安全團隊會與所有產品經理和項目管理進行多次溝通，提出一個多方基本認可的安全活動觸發場景與基線表，供產品經理參考。

九、產品經理獲取安全資源支持

產品經理在履行各項安全職責時，需要周邊部門提供的安全服務與支持包括但不限于：

ID產品經理工作內容所需資源或服務提供者

1明確產品安全需求白名單敏感數據分類分級標準及其相關模板和Demo；產品安全需求變更發生判斷標準安全部

2保障安全研發資源安全活動清單及其迭代基線安全部&QA

3推動研發團隊安全能力建設安全培訓與實操安全部

4整合周邊安全資源安全資源清單，包括安全咨詢、評審、培訓、開發包、平臺或服務安全部&法務&合規

十、產品經理安全工作壓力分析

產品經理安全工作壓力分析如下表：

ID產品經理工作內容產品經理工作壓力分析

1明確產品安全需求白名單初次創建產品安全需求白名單的4張表格有一定的工作量，但屬于一次性工作。產品經理也可以分批次完成，先完善主要信息，其它信息后續擇機補充。后續產品安全需求白名單維護工作壓力比較小，新增需求或變更只要不觸動白名單4張表格的內容，就無需維護。實踐表明，產品的用戶、數據、訪問白名單在經過少數幾輪迭代后趨于穩定，很少有機會對表格進行變更。

2保障安全研發資源是迭代研發計劃制訂與推進工作的一部分，無需額外花費時間；每年可能需要花費一天左右的時間參加安全培訓，了解安全活動迭代安排基線，了解安全基礎概念，了解產品安全需求制訂與維護方法。

3推動研發團隊安全能力建設在研發團隊能力建設計劃與方案中添加安全相關內容，可能會涉及到一部分預算和人天。能力建設推進過程中可能涉及到一部分參加培訓和演練的人天投入，但這部分資源占比應該會較小，構不成明顯資源壓力。可能存在一些安全部能力暫時無法覆蓋的培訓，需要外購，比如云安全、移動安全等，產品經理可以獨立申請預算，或安全部跟產品線統籌統一申請預算。

4整合周邊安全資源為解決已知安全問題，很多產品經理日常也在推進該項工作，成為日常溝通協調工作的一部分。主要是將這種被動的、個案化的行動轉換為主動的、常態化的工作行為。目前公司有較為清晰的安全責任劃分和流程，構不成明顯工作壓力。

上表描述了產品經理可能會遇到的主要工作內容，但并不是全部內容。整體而言，會增加產品經理一定的工作量，但不會構成明顯的工作壓力。

十一、小結

產品經理對產品安全負有責任，通過明確產品安全需求中的白名單指明產品安全目標，通過制訂安全研發計劃、推動團隊安全能力建設和協調周邊安全資源，實現產品安全落地。

經過簡短安全培訓后，相關工作均在產品經理能力范疇，工作量不會對產品經理形成心理壓力，靈活的安全活動觸發標準也不會影響研發的敏捷性。筆者在這里衷心期望各位產品經理放心大膽、勇往直前地擁抱安全，和安全部一起不斷地將產品安全推向新高潮。

十二、感悟

在筆者的工作經歷中，安全部門為了推動安全工作，總是想著法地“抱大腿”，期望借助外力以推動安全工作，卻沒有注意到產品經理這個“大腿”，只需覺醒其安全意識，這一“大腿”不僅粗壯有力，而且有著主動擁抱安全的強烈動因。

安全部與產品經理合作，很容易建立基于迭代開發的常態化安全落地機制，而與其他部門合作，例如合規或法務，常常只在特定階段推動特定安全工作的落地。建議各位應用安全同行和產品經理多多交流，因為：產品經理才是我們安全部最需要擁抱的“大腿”！