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

一、聊聊安全

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

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

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

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

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

但形成這樣的既定認知前，有一個問題值得思考：

安全需求，真的只是大客戶才關心的嗎？

先講一個小故事。

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

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

農夫甲接話：“可能還不止，下地幹活肯定也用的是金鋤頭。”

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

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

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

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

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

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

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

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

二、4類風險與3層限制

1。 4類風險

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

。

它們分別是

環境的風險：系統登入環境，使用環境帶來的風險。

操作的風險：員工越權操作，或操作無人監管，無據可查帶來的風險。

合規的風險：產生的業務資料是否符合財務規範，符合財務真實準確的要求。以及資料是否符合相關行業規範，採集的過程和結果是否可靠。

經營的風險：上下游合作伙伴管理不善帶來的經營風險，導致收入和成本可能出現劇烈波動。

2。 三層限制

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

第一層限制：能不能。

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

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

而作為執法者，我們憑藉什麼去阻攔使用者呢？

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

要保證的是系統裡所有使用者的賬號是安全的，也要確保當前登入的人確實是使用者本身。

常見的功能有：

1）登入安全提示：

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

2）雙重校驗：

例如增加goggle校驗，增加簡訊校驗，把新增的校驗方式視為臨時密碼，與使用者事先設定的固定性密碼組合，共同確保安全。

3）單裝置登入校驗：

不允許使用者同時登入兩個裝置。

4）登入密碼安全性設定：

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

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

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

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

1）細化資料許可權

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

業務資料：包含成本，售價，利潤，單數等等資訊，應該嚴格限制，特別是上市公司的經營資料，更應該把可查範圍縮小縮小再縮小。

合作方隱私資料：包括證件號碼，聯絡方式，犯罪資訊等等，這類有倒賣價值、以及流出後會影響他人的資訊，都應設定嚴格的許可權

解決方案

① 敏感資訊，介面檢視時脫敏處理

例如電話號碼，證件資訊，可以用只保留首尾數字的方法展示，展示為138****8888。又例如個人姓名，預設展示時僅展示姓氏李**，但點選可以檢視到完整的資訊。

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

② 設定敏感資訊的統一檢視許可權

較為敏感的資訊，且只有某些角色才需要檢視到的，可以設定統一的檢視許可權，擁有許可權的人才可以看到相關資訊。

③ 非常敏感的資訊設定獨立許可權。

例如檢視犯罪資訊，需要有單獨的檢視和篩選許可權。

2）管控關鍵行為

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

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

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

有些欄位在系統中展示和檢視問題不大，外流則會造成很大的問題，例如犯罪資訊的外流，可想而知會引起多大程度的輿論壓力。對於這類情況，需要讓使用者可以設定，無論許可權如何都不能下載的欄位。

其次需要限制匯出的資料量。

絕大多數場景中，匯出是用於做資料分析，按月匯出可以滿足絕大多數需求。如果一次性匯出幾年的資料，是有風險的。對於這類情況，需要讓使用者設定匯出的條件限制。

最後匯出某些資料，需要受到監管。

或者有統一的下載管理評查，可檢視匯出的資料內容和資訊，或者可以把匯出行為設計成需要審批。

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

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

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

如果系統不為業務服務，無法知道使用者的修改會造成什麼問題，至少提供不允許修改的配置，並在培訓時著重強調修改資訊的許可權，請使用者思考背後對應的風險。

3）服務合理使用者

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

但事實上總有各種情況，導致不在職的人，無許可權的人還可以登入系統，造成系統資訊的不安全。

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

控制超級管理員人數：

超級管理員的賦予和取消都應有通知和留檔，甚至可以設定為需要審批。

人員退出機制：

儘量把系統人員狀態和其他系統打通，例如OA和辦公協同系統，這樣員工離職後，可以自動變更賬號狀態。

人員回收機制：

如果某些使用者長期未登入，可以把狀態自動變更為凍結。

臨時登入機制：

如果某些使用者需要臨時登入，可以開始有登入有效期的臨時賬號，滿足短期內使用的需求。

第二層限制：對不對。

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

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

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

1）資訊採集

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

2）資訊修改

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

3）對賬過程

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

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

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

第三層限制：好不好。

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

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

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

那麼系統是不是可以給出專案經營的風險預警呢？

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

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

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

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

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

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

三、總結

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

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

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

環境的風險：系統登入環境，使用環境帶來的風險。用“不能”的態度去攔截。

操作的風險：員工越權操作，或操作無人監管，無據可查帶來的風險。用“不能”的態度去攔截。

合規的風險：產生的業務資料是否符合財務規範，符合財務真實準確的要求。以及資料是否符合相關行業規範，採集的過程和結果是否可靠。用“不對”的態度去規勸。

經營的風險：上下游合作伙伴管理不善帶來的經營風險，導致收入和成本可能出現劇烈波動。用“不好”的態度去提示。

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

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

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

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

題圖來自Unsplash，基於CC0協議