編輯導語：隨著社會對數據安全、信息安全等方面的注重，企業也需要提升安全意識，比如SaaS企業，在為客戶提供服務時，就需要考慮如何降低風險，提升安全保障。本篇文章里，作者就SaaS產品的風險控制等問題做了解讀，一起來看一下。

一、聊聊安全

在SaaS企業成長的過程中，往往會出現這樣的轉變：從完全不在意安全，到慢慢開始在意，再到非常在意。

這樣的轉變，主要源于客戶群體的變化。

最初服務的客戶體量規模較小，使用的人數較少，會把注意力放在是否滿足業務場景，是否能夠達成業務目標。關心的是能產生對應的結果。

而隨著SaaS企業的擴展，服務客戶的規模越來越大，到后期行業內的標桿企業也會購買系統，這類客戶把安全作為第一要務，用審計、風控、合規等崗位來確保實現安全目標。他們既關心結果，也關心產生結果的過程。

看起來是大客戶對安全的關注，倒逼企業來重視和關注系統安全。所以安全模塊的設計，在產品設計中處于長期被忽視的狀態，往往認為是為了迎合大客戶不得去去投入資源的模塊，無法產生價值。

但形成這樣的既定認知前，有一個問題值得思考：安全需求，真的只是大客戶才關心的嗎？

先講一個小故事。

兩位農夫在田間勞作，正當正午，日頭曬得人頭暈眼花，農夫甲擦了擦汗，直起身來望向城里，彷佛視線落在了紫禁城，他艷羨地說：你說皇帝在宮里，過都是什么樣的日子？

農夫乙笑著說：那肯定是神仙一樣的日子，他坐在屋里，前面一油鍋后面一油鍋，想吃油條炸油條，想吃麻花炸麻花。

農夫甲接話：“可能還不止，下地干活肯定也用的是金鋤頭?！?/p>

我們已知的是，皇帝日常并不做飯，并不下地，所以農夫的猜測如同坐井觀天，和現實并不搭邊。

同理，小客戶對于SaaS軟件的認識，很可能也大大出乎我們的意料。

客戶一般數字化程度不高，使用SaaS的經驗很少甚至沒有，對技術更是毫不了解，系統對于他們而言，就像坐在宮殿里的貴人，只能用自己的思維去猜測。購買一套系統的作用被極致簡化，認為是就是這里點點，那里寫寫，產生數據，大家看看。

他們并不知道系統可能是不安全的，不知道系統一旦被使用，從人，從權限，從操作流程方面等方面都會帶來安全隱患，或者并沒有對安全隱患的背后的損失有著正確的認識。

用馬斯洛需求層次來解釋，每個人的底層需求都是安全，同理，每個企業的底層需求也應該是安全。小客戶沒有明確表達需求，并不代表他們不重視安全。反而由于他們不懂不會，才是需要SaaS企業更好地支持到他們，為客戶防患于未然。

從長遠來看，這一項工作也非常有意義。進入數字時代后，我們每天產生的數據呈倍數級增長。所以數據的安全顯得更加重要。

同時，在互聯網+，產業互聯網的共同升級下，安全的定義被極大地延伸，安全不僅要做到保護數據隱私，防范數據流出，也需要呈現準確的數據，因為只有準確的數據，未來才會有連通和銜接的價值。

這就意味做到安全，要符合行業互聯網的規范，要減少客戶試錯成本，要真正以幫客戶實現業務目標為核心，去思考系統如何能幫客戶做好做對做準確。

二、4類風險與3層限制

1. 4類風險

回到具體的場景，會造成系統不安全的風險一共有四類。

它們分別是

1. 環境的風險：系統登錄環境，使用環境帶來的風險。
2. 操作的風險：員工越權操作，或操作無人監管，無據可查帶來的風險。
3. 合規的風險：產生的業務數據是否符合財務規范，符合財務真實準確的要求。以及數據是否符合相關行業規范，采集的過程和結果是否可靠。
4. 經營的風險：上下游合作伙伴管理不善帶來的經營風險，導致收入和成本可能出現劇烈波動。

2. 三層限制

相對應的是，我們需要建好三道門檻，用不同的態度去限制用戶，降低風險。

第一層限制：能不能。

在這個層次的限制中，我們扮演的是一個執法者。

執法者面臨的是環境的風險，操作的風險，在這些環節出現風險的時候，執法者當機立斷，采用一刀切的方式，阻攔用戶，告訴用戶不能進行某些操作，需要按照規定來操作。

而作為執法者，我們憑借什么去阻攔用戶呢？

首先依仗的是系統上的，約定俗成的安全性要求。

要保證的是系統里所有用戶的賬號是安全的，也要確保當前登錄的人確實是用戶本身。

常見的功能有：

1）登錄安全提示：首次登錄某個設備需要做二次校驗；登錄時提示上一次登錄地和時間，以便用戶及時發覺異常；讓用戶設置一串文字作為安全碼，登錄時展示安全碼，用戶看到安全碼和自己設置的一致時，則認為安全。

2）雙重校驗：例如增加goggle校驗，增加短信校驗，把新增的校驗方式視為臨時密碼，與用戶事先設置的固定性密碼組合，共同確保安全。

3）單設備登錄校驗：不允許用戶同時登錄兩個設備。

4）登錄密碼安全性設置：可由管理人設置密碼的安全性等級，例如是否考慮大小寫字母，數字，特殊字符的混用，是否限制長度，以及是否設置過期時間。

除了依賴安全規范，也要依賴法律上、道德上的規范。

這些規范用于限制內部員工的行為，讓員工在規范內允許的范圍內操作，盡可能減少員工犯錯可能。曾有一段時間，銀行、支付工具等公司，都屢屢被爆出員工的數據倒賣的情況，但近些年這類新聞少了很多，猜測可能和系統逐步提升安全等級有關。

為了管控員工行為，一共有3類的方向可以去優化。

1）細化數據權限

對于系統而言，有兩類數據是最重要的：公司業務數據，合作方隱私數據。

• 業務數據：包含成本，售價，利潤，單數等等信息，應該嚴格限制，特別是上市公司的經營數據，更應該把可查范圍縮小縮小再縮小。
• 合作方隱私數據：包括證件號碼，聯系方式，犯罪信息等等，這類有倒賣價值、以及流出后會影響他人的信息，都應設置嚴格的權限

解決方案

① 敏感信息，界面查看時脫敏處理

例如電話號碼，證件信息，可以用只保留首尾數字的方法展示，展示為138****8888。又例如個人姓名，默認展示時僅展示姓氏李**，但點擊可以查看到完整的信息。

這兩種方式可以適應到不同的情況，前者是無論如何都不展示全部信息，后者是可以展示完整，但多了一層信息保護，避免一目了然看到所有信息。

② 設置敏感信息的統一查看權限

較為敏感的信息，且只有某些角色才需要查看到的，可以設置統一的查看權限，擁有權限的人才可以看到相關信息。

③ 非常敏感的信息設置獨立權限。

例如查看犯罪信息，需要有單獨的查看和篩選權限。

2）管控關鍵行為

在使用中，有兩類行為是非常值得注意的。

一類是導致數據流出系統的行為，也就是下載。

首先需要重點梳理下載行為涉及的字段。

有些字段在系統中展示和查看問題不大，外流則會造成很大的問題，例如犯罪信息的外流，可想而知會引起多大程度的輿論壓力。對于這類情況，需要讓用戶可以設置，無論權限如何都不能下載的字段。

其次需要限制導出的數據量。

絕大多數場景中，導出是用于做數據分析，按月導出可以滿足絕大多數需求。如果一次性導出幾年的數據，是有風險的。對于這類情況，需要讓用戶設置導出的條件限制。

最后導出某些數據，需要受到監管。

或者有統一的下載管理評查，可查看導出的數據內容和信息，或者可以把導出行為設計成需要審批。

另一類值得注意的是修改業務上的關鍵信息。

例如把已經過期的身份證修改為正常，導致圖片和文字信息不匹配，把犯罪信息從無改到有，都是嚴格的紅線行為。

如果系統本身有業務屬性，則可以預見并嚴格限制紅線行為。

如果系統不為業務服務，無法知道用戶的修改會造成什么問題，至少提供不允許修改的配置，并在培訓時著重強調修改信息的權限，請用戶思考背后對應的風險。

3）服務合理用戶

正常來說，有系統登錄權限的人，都應該是在職且有權限的員工。

但事實上總有各種情況，導致不在職的人，無權限的人還可以登錄系統，造成系統信息的不安全。

可以從功能設計上防范這些情況：

• 控制超級管理員人數：超級管理員的賦予和取消都應有通知和留檔，甚至可以設置為需要審批。
• 人員退出機制：盡量把系統人員狀態和其他系統打通，例如OA和辦公協同系統，這樣員工離職后，可以自動變更賬號狀態。
• 人員回收機制：如果某些用戶長期未登錄，可以把狀態自動變更為凍結。
• 臨時登錄機制：如果某些用戶需要臨時登錄，可以開始有登錄有效期的臨時賬號，滿足短期內使用的需求。

第二層限制：對不對。

第一層限制里，我們關注的是用戶能不能這么做，而在第二層限制，我們扮演的是一個老師，來告訴客戶這么做是否對，在合規層面，操作是否符合規范。

企業留存在系統中的業務數據，最后都會變成財務數據，甚至有些客戶希望把系統打通，直接按系統金額去進行支付，這就要求系統的數據最后應該是符合財務的規范的。

就實踐而言，系統應該重點關注以下幾個場景，數據是否做到了真實、準確、及時。

1）信息采集

主要是基礎數據的準確。例如訂單系統需要維護商品和客戶數據，物流系統需要維護司機和車輛數據。

2）信息修改

基礎信息的修改往往會導致業務數據，財務數據變化。例如商品價格沒有及時更新，導致訂單價格錯誤，而此時已經走完打款開票流程，就顯而易見地已經造成了損失。

3）對賬過程

一般需要內部和外部的審核，在這些場景中，是否可以提示風險點和審核要點，快速幫助定位問題，避免自動化工作造成的人工錯誤。

這些場景，是在對行業、業務有深度認知上才能認識到重要性，且能夠給到解決方案的。

通過給到專業的解決方案，達成數據真實、準確、及時的目標，達成最終的財務合規目標，這就是產品隱形實力的體現，是硬功夫的細節，是不容易抄走的理念。

第三層限制：好不好。

在這個層次里，系統扮演的是專家，可以給出關于企業經營的意見。

企業能夠順利運轉，很大程度上都依賴于合作伙伴，那么合作方的帶來風險也可以被關注起來。

例如一個固定項目，長期都是一個供應商來承接，那么代表著項目可能存在一家獨大的風險，項目風險無法分攤，對于成本也很難有議價權。

那么系統是不是可以給出項目經營的風險預警呢？

除此以外，對于合作方的資質要求，保證金管理，系統是否對應的能力和預警，也是可以考慮的。

對于上游客戶，如果連續出現某類客戶的訂單下降，是否可以給到預警，提示持續流失風險。

以上只是一些例子，可以挖掘的場景應該還有很多。畢竟企業經營，是上游下游都好，才是真的好。

系統能做到這一點，也是真的能夠把SaaS的雙重性都體現出來了，既是經營思路，又是經營工具。

除了三個層次的限制，我們也要有一些兜底的能力。

目標是盡量增加違規操作的成本，或者在事后能盡快定位。例如增加可查驗的、完整的系統日志，以及設置系統全局的水印。

三、總結

回顧本文，我們聊了SaaS企業的安全意識，并把安全指代的場景擴大化。

安全不僅僅是信息儲存安全，也代表著信息生成的過程合規，上下游的運營安全。

與之對應，我們聊了4種風險，并一一對應了三類解決辦法。

1. 環境的風險：系統登錄環境，使用環境帶來的風險。用“不能”的態度去攔截。
2. 操作的風險：員工越權操作，或操作無人監管，無據可查帶來的風險。用“不能”的態度去攔截。
3. 合規的風險：產生的業務數據是否符合財務規范，符合財務真實準確的要求。以及數據是否符合相關行業規范，采集的過程和結果是否可靠。用“不對”的態度去規勸。
4. 經營的風險：上下游合作伙伴管理不善帶來的經營風險，導致收入和成本可能出現劇烈波動。用“不好”的態度去提示。

SaaS系統既然是理念和工具的合并，也同時也代表著執法者，老師，專家三類角色，三者背后的服務理念各不相同，從低到高，服務于用戶的不同需求。

經常聽到創業者說SaaS功能太容易被抄襲了。那么我想說：未來SaaS的競爭核心，或許不是功能的競爭，而是理念的競爭。

作者：假裝是運營，微信公眾號：SaaS學姐

本文由 @假裝是運營 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議