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

1、序言

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

2、背景

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

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

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

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

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

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

3、安所有門的尷尬

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

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

（圖1 安全驅動產品）

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

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

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

（圖2 產品驅動安全）

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

5、產品如何驅動安全

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

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

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

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

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

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

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

6.1 明確產品安全需求

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

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

（圖4 產品安全需求）

6.2 產品數據安全需求

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

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

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

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

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

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

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

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

6.3 合規性需求

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

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

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

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

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

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

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

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

8、產品安全研發方法

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

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

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

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

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

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

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

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

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

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

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

11、小結

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

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

12、感悟

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

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

做者：危國洪 郭建偉

來源：宜信技術學院