宜信SDL實踐：產品經理如何驅動產品安全建設

1、序言

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

2、背景

安全是軟件產品自然屬性的一部分，「無安全不金融」，對於金融軟件產品而言，安全尤其重要，由於客戶老是可以從各類安全漏洞聯想到他的金融資產安全和我的信息安全。之前偶爾會在一些安全沙龍或峯會聽見同行吐槽，「信息安全提及來重要、作起來次要、忙起來不要」。吐槽背後的緣由很複雜，其中很重要的一點是跟產品經理安全意識淡薄、不清楚如何推動產品安全建設有關，好比不重視產品安全屬性、產品安全需求不明確、產品安全資源不充分、產品安全建設無從下手等。本文主要站在產品經理的角度，從產品經理能力維度出發，探討產品經理如何推進產品的安全性建設。

衆所周知，安全性做爲軟件產品的自然屬性，從產品定義與規劃角度來看，產品經理對產品安全負有不可推卸的責任，但產品經理如何履行本身的安全職責，業界尚未給出一個清晰可行的行動方案。

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

1	2	3	4	5
姓名	身份證號	電話號碼	銀行卡信息	聯繫地址

這種方法簡單易行，但每每不能涵蓋全部的敏感信息，好比

• 用戶的多系統用戶數據關聯ID（超級ID）。
• 交易過程當中的音視頻等多媒體數據。
• 各類非結構化的文檔數據，如合同掃描件。
• 用戶的行爲畫像數據等內容。

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

3、安所有門的尷尬

前述的敏感信息五要素分析方法是典型的安全驅動產品的方法，即安所有門推進產品相關各團隊的安全工做開展。這種模式存在不少弊端，好比：

• 安全需求可能不完整，職業常識代替不了特定業務場景的深度分析；
• 產品各團隊的安全工做資源沒法保證，研發團隊有理由認爲安全團隊干擾研發計劃，研發進度與資源不變的狀況下，額外增長了工做量；
• 安所有門一般沒機會參與制訂研發計劃，產品研發計劃與安全脫節；
• 安全團隊高度依賴話語權，強制性驅動每每陷入窘境。

（圖1 安全驅動產品）

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

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

產品驅動安全並不是意味着產品經理單一角色推進產品的安全建設，而是說產品經理主動承擔相應的產品安全責任，主動與安所有門一塊兒推進產品的安全建設，由安全驅動產品的單輪驅動轉變爲產品驅動安全的雙輪驅動。以下圖所示：

（圖2 產品驅動安全）

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

5、產品如何驅動安全

產品經理有意願作好產品安全，可能會問以下幾個問題：

• 內容方面，產品經理須要作哪些安全工做；
• 能力方面，爲了完成這些工做，產品經理須要具有什麼樣的安全能力；
• 方法方面，這些安全工做如何作，才能既兼顧產品業務功能研發與安全，又能保持研發敏捷性和項目管理流程不變形；
• 安全資源，從安所有門和其餘部門能夠獲取哪些安全支持，來提高本身和研發團隊安全工做的效率和效果，下降安全工做的能力門檻；
• 工做負擔，安全工做會不會讓產品經理很辛苦，影響其工做品質和生活品質。

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

6、產品經理的安全工做內容

產品經理的安全工做內容大體以下：

• 明確產品安全需求；
• 保障安全研發資源，將安全工做設定到研發計劃中，並分撥足夠的安全研發資源；
• 推進研發團隊安全能力建設，確保研發計劃中的安全工做執行到位;
• 整合周邊安全資源，確保研發計劃中的安全工做執行到位。

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

6.1 明確產品安全需求

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

• 產品承載的業務數據安全防禦需求，主要關注點是業務數據的機密性和完整性。
• 產品相關信息的安全監管要求，如等級保護、行業信息安全監管等要求。
• 產品承載的業務連續性要求。因爲一般由數據中心或運維部門統一牽頭實施該項任務，本文將不會展開描述該項內容。

（圖4 產品安全需求）

6.2 產品數據安全需求

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

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

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

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

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

ID	內容	說明
1	合法用戶清單	系統用戶類別、辦公地點與訪問方式，用戶類別應包括有接口調用關係的對端系統
2	敏感數據清單	敏感數據範圍與清單，及其分類、分級說明
3	業務訪問行爲清單	系統用戶與敏感數據之間的訪問映射關係與操做方式清單
4	敏感行爲清單	須要記錄業務操做日誌的最小集合，爲業務審計提供依據，該清單與上面的業務訪問行爲清單基本重合

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

ID	原則	解釋
1	最小權限	將用戶對數據的訪問操做的方式和動做最小化，如對於某個用戶類別，OA網訪問可知足業務需求的就不該開放到外網訪問，數據脫敏可讀可知足業務需求的狀況應不開放明文可讀或可寫權限
2	知所必需	將用戶的數據訪問範圍最小化，如對於某個用戶類別，單個文件訪問能夠知足業務需求，決不開放2個或多個文件訪問

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

• 敏感數據未脫敏。
• 多餘的數據操做權限。
• 橫向或縱向數據訪問越權。
• 關鍵行爲的日誌痕跡缺失。

6.3 合規性需求

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

ID	監管要求	監管層級
1	網絡安全法及其兩高釋法（國家）	國家
2	信息系統等級保護（公安部）	公安部
3	我的信息保護規範（工信部）	工信部
4	GDPR（涉及到服務歐盟公民的相關IT服務）	歐盟

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

ID	名稱	時間	發文部門
1	關於開展App違法違規收集使用我的信息專項治理的公告	2019/1/25	中央網信辦、工業和信息化部、公安部、市場監管總局
2	移動互聯網應用基本業務功能必要信息規範	2019/6/1	全國信息安全標準化技術委員會
3	App違法違規收集使用我的信息自評估指南	2019/3/1	APP專項治理工做組
4	App違法違規收集使用我的信息行爲認定方法（徵求意見稿）	2019/5/5	APP專項治理工做組
5	信息安全技術 移動互聯網應用程序（App）收集我的信息基本規範（草案）	2019/10/25	全國信息安全標準化技術委員會
6	關於開展APP侵害用戶權益專項整治工做的通知	2019/11/6	工業和信息化部

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

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

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

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

ID	產品經理安全需求工做內容	能力分析
1	明確合法用戶清單	無需額外能力，須要描述模板支持
2	明確敏感數據清單	須要理解安全基礎概念，在指定敏感數據安全等級時，須要敏感數據分類分級標準支持，須要模板支持
3	明確業務訪問行爲清單	無需額外能力，須要描述模板支持
4	明確敏感行爲清單	無需額外能力，須要描述模板支持

產品經理其餘安全開發工做所需能力分析以下：

ID	工做內容	能力分析
1	保障安全研發資源	在產品迭代研發計劃中增長安全相關活動與環節，並指定責任人。計劃制訂自己無需額外能力，但在安排相關安全活動時，爲保持開發的敏捷性和現有的項目管理機制不變形，須要安全、質量管理和項目管理等部門提供方法論支持。須要產品經理有必定的安全意識。
2	推進研發團隊安全能力建設	爲了保證迭代研發計劃中的活動執行成功，研發團隊（設計、開發和測試）須要較高的安全意識和一些基礎的安全能力，如安全設計、安全編碼和安全測試。安所有應統籌各團隊的安全能力建設需求，提供相關安全能力建設支持。須要產品經理有必定的安全意識。
3	整合周邊安全資源	爲了保證迭代研發計劃中的活動執行成功，須要整合周邊部門的專業性安全服務，好比安所有的各種安全評審服務、威脅建模、代碼審計、滲透測試、流量實時監控等服務，基礎研發部的SSO平臺，運維的統一身份管理服務等等。甚至須要法務與合規等部門的安全支持。安所有門有責任提供和維護一份持續可用的安全服務清單，讓產品經理和研發團隊知曉服務清單，並知曉何處獲取相關安全服務。須要產品經理有必定的安全意識。

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

8、產品安全研發方法

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

爲了將安全開發理念在敏捷與DevOps開發中獲得貫徹，建議採用以下原則：

• 安全開發活動輕量化。輕量化能夠經過工具化、自動化來實現，儘可能減小人工耗費大和耗時長的安全開發活動；
• 安全開發活動分散化。將那些短時間沒法輕量化處理的安全開發活動分解並分散到多個迭代週期中執行；
• 安全開發活動並行化。將安全開發相關活動與其餘活動並行，如滲透測試一般安排在測試的最後一個環節，避免單輪次滲透測試沒法覆蓋那些並行的修復點，固然滲透測試也能夠由多個輪次來彌補這種狀況，但一般資源不容許。實際上這種同步修復致使滲透測試覆蓋率降低的問題，徹底能夠經過良好的溝通和團隊文化建設進行彌補。
• 優化現有敏捷開發與DevOps相關的流程與工具平臺，使得安全專家可以充分參與項目，提高安全開發溝通效率，快速獲取安全反饋；
• 將安全專家歸入到敏捷開發和DevOps文化建設中來，信息安全人人有責，安全專家能夠充分發揮教練員角色和守門員角色，使得團隊人人有能力履行本身的安全職責，安全專家在恰當的時機對安全交付物進行質量把控；
• 提早進行安全基礎設施規劃與佈局，如身份與權限管理系統、SSO系統、加解密平臺與SDK、日誌分析與監控平臺、全流量檢測平臺等等，使得安全措施標準化、服務化和平臺化，下降安全設計與編碼的能力門檻，對安全基礎設施的測試與驗證取代設施所承載應用的大部分安全測試，能夠有效消減安全測試工做量。

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

ID	安全活動名稱	迭代執行要求	觸發場景與基線示例
1	建立產品安全需求名單	一次性執行	產品原型發佈以前
2	維護產品安全需求白名單	每迭代執行
3	評審產品安全需求白名單	多迭代執行	重大需求變動或累積變動開發量達到n人天
4	建立產品數據流圖	一次性執行	產品原型發佈以前
5	創建威脅初始模型	一次性執行	產品原型發佈以前
6	維護威脅模型	每迭代執行	重大需求變動或累積變動開發量達到n人天
7	評審威脅模型	多迭代執行	重大需求變動或累積變動開發量達到n人天
8	安全設計評審	多迭代執行	重大需求變動或累積變動開發量達到n人天
9	代碼掃描及其報告分析（開發）	天天/迭代執行
10	代碼掃描及其報告分析（安所有）	多迭代執行	重大需求變動或累積變動開發量達到n人天
11	深度黑盒安全掃描	天天/迭代執行
...	...	...

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

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

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

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

ID	產品經理工做內容	所需資源或服務	提供者
1	明確產品安全需求白名單	敏感數據分類分級標準及其相關模板和Demo；產品安全需求變動發生判斷標準	安所有
2	保障安全研發資源	安全活動清單及其迭代基線	安所有&QA
3	推進研發團隊安全能力建設	安全培訓與實操	安所有
4	整合周邊安全資源	安全資源清單，包括安全諮詢、評審、培訓、開發包、平臺或服務	安所有&法務&合規

10、產品經理安全工做壓力分析

產品經理安全工做壓力分析以下表：

ID	產品經理工做內容	產品經理工做壓力分析
1	明確產品安全需求白名單	初次建立產品安全需求白名單的4張表格有必定的工做量，但屬於一次性工做。產品經理也能夠分批次完成，先完善主要信息，其它信息後續擇機補充。後續產品安全需求白名單維護工做壓力比較小，新增需求或變動只要不觸動白名單4張表格的內容，就無需維護。實踐代表，產品的用戶、數據、訪問白名單在通過少數幾輪迭代後趨於穩定，不多有機會對錶格進行變動。
2	保障安全研發資源	是迭代研發計劃制訂與推動工做的一部分，無需額外花費時間；每一年可能須要花費一天左右的時間參加安全培訓，瞭解安全活動迭代安排基線，瞭解安全基礎概念，瞭解產品安全需求制訂與維護方法。
3	推進研發團隊安全能力建設	在研發團隊能力建設計劃與方案中添加安全相關內容，可能會涉及到一部分預算和人天。能力建設推動過程當中可能涉及到一部分參加培訓和演練的人天投入，但這部分資源佔比應該會較小，構不成明顯資源壓力。可能存在一些安所有能力暫時沒法覆蓋的培訓，須要外購，好比雲安全、移動安全等，產品經理能夠獨立申請預算，或安所有跟產品線統籌統一申請預算。
4	整合周邊安全資源	爲解決已知安全問題，不少產品經理平常也在推動該項工做，成爲平常溝通協調工做的一部分。主要是將這種被動的、個案化的行動轉換爲主動的、常態化的工做行爲。目前公司有較爲清晰的安全責任劃分和流程，構不成明顯工做壓力。

上表描述了產品經理可能會遇到的主要工做內容，但並非所有內容。總體而言，會增長產品經理必定的工做量，但不會構成明顯的工做壓力。

11、小結

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

通過簡短安全培訓後，相關工做均在產品經理能力範疇，工做量不會對產品經理造成心理壓力，靈活的安全活動觸發標準也不會影響研發的敏捷性。筆者在這裏衷心指望各位產品經理放心大膽、一往無前地擁抱安全，和安所有一塊兒不斷地將產品安全推向新高潮。

12、感悟

在筆者的工做經歷中，安所有門爲了推進安全工做，老是想着法地「抱大腿」，指望藉助外力以推進安全工做，卻沒有注意到產品經理這個「大腿」，只需覺醒其安全意識，這一「大腿」不只粗壯有力，並且有着主動擁抱安全的強烈動因。

安所有與產品經理合做，很容易創建基於迭代開發的常態化安全落地機制，而與其餘部門合做，例如合規或法務，經常只在特定階段推進特定安全工做的落地。建議各位應用安全同行和產品經理多多交流，由於：產品經理纔是咱們安所有最須要擁抱的「大腿」！

做者：危國洪 郭建偉

來源：宜信技術學院