宜信SDL實踐：產品經理如何驅動產品安全建設
一、序言
本文從產品經理的角度出發，對產品經理的安全職責、產品驅動安全的內涵、工作內容、工作方法、所需安全資源、以及產品經理的安全工作量進行了分析。希望所有產品經理在沒有心理負擔的情況下，有目標、有方法、有資源推進產品安全建設。
二、背景
安全是軟體產品天然屬性的一部分，“無安全不金融”，對於金融軟體產品而言，安全尤為重要，因為客戶總是能夠從各種安全漏洞聯想到他的金融資產安全和個人資訊保安。以前偶爾會在一些安全沙龍或峰會聽見同行吐槽，“資訊保安說起來重要、做起來次要、忙起來不要”。吐槽背後的原因很複雜，其中很重要的一點是跟產品經理安全意識淡薄、不清楚如何推進產品安全建設有關，比如不重視產品安全屬性、產品安全需求不明確、產品安全資源不充分、產品安全建設無從下手等。本文主要站在產品經理的角度，從產品經理能力維度出發，探討產品經理如何推動產品的安全性建設。
眾所周知，安全性作為軟體產品的天然屬性，從產品定義與規劃角度來看，產品經理對產品安全負有不可推卸的責任，但產品經理如何履行自己的安全職責，業界還沒有給出一個清晰可行的行動方案。
目前，軟體產品安全需求通常是基於開發人員和安全人員的職業常識提出相應的解決方案，比如目前業內比較通用的敏感資訊五要素分析方法：
| 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|
| 姓名 | 身份證號 | 電話號碼 | 銀行卡資訊 | 聯絡地址 |
這種方法簡單易行，但往往不能涵蓋所有的敏感資訊，比如
- 使用者的多系統使用者資料關聯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 | 個人資訊保護規範（工信部） | 工信部 |
| 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安全合規要求。等級保護相關要求為所有系統需要面對的共通要求，無需產品經理羅列，安全部可以直接解釋。
關於具體安全需求的定義與維護方法，筆者將通過其他文章進行說明。
七、產品經理安全能力分析與建設
分析產品經理的安全工作內容，最主要的考驗來自於明確業務安全需求的四個清單。相關安全能力分析如下表：
| 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 | 整合周邊安全資源 | 為解決已知安全問題，很多產品經理日常也在推進該項工作，成為日常溝通協調工作的一部分。主要是將這種被動的、個案化的行動轉換為主動的、常態化的工作行為。目前公司有較為清晰的安全責任劃分和流程，構不成明顯工作壓力。 |
上表描述了產品經理可能會遇到的主要工作內容，但並不是全部內容。整體而言，會增加產品經理一定的工作量，但不會構成明顯的工作壓力。
十一、小結
產品經理對產品安全負有責任，通過明確產品安全需求中的白名單指明產品安全目標，通過制訂安全研發計劃、推動團隊安全能力建設和協調周邊安全資源，實現產品安全落地。
經過簡短安全培訓後，相關工作均在產品經理能力範疇，工作量不會對產品經理形成心理壓力，靈活的安全活動觸發標準也不會影響研發的敏捷性。筆者在這裡衷心期望各位產品經理放心大膽、勇往直前地擁抱安全，和安全部一起不斷地將產品安全推向新高潮。
十二、感悟
在筆者的工作經歷中，安全部門為了推動安全工作，總是想著法地“抱大腿”，期望藉助外力以推動安全工作，卻沒有注意到產品經理這個“大腿”，只需覺醒其安全意識，這一“大腿”不僅粗壯有力，而且有著主動擁抱安全的強烈動因。
安全部與產品經理合作，很容易建立基於迭代開發的常態化安全落地機制，而與其他部門合作，例如合規或法務，常常只在特定階段推動特定安全工作的落地。建議各位應用安全同行和產品經理多多交流，因為：產品經理才是我們安全部最需要擁抱的“大腿”！
作者：危國洪 郭建偉
來源：宜信技術學院