本文根據劉歡老師在〖deeplus直播第223期〗線上分享演講內容整理而成。
劉歡
58到家安全負責人
CISP，曾參與政府、軍工、營運商、銀行、互聯網企業等安全評估建設專案；
現負責58到家集團安全防護體系的建設。
這次分享主要分為三部份：
-
我們如今這個DT時代的安全現狀；
-
當前企業數據所面臨的威脅；
-
結合58到家這兩年的實踐談數據安全建設。
一、DT時代安全現狀
首先看看我們今天所處的整個互聯網安全現狀。如今我們已經從IT時代步入DT時代，DT時代就是指數據技術。事實證明最近幾年大數據越來越重要，數據已經成為企業的核心。
例如共享單車，傳統觀念上可能只是代步工具，但現在的共享單車一般都有感應器和定位裝置，這時它就不僅是一輛單車了，可能我們走到什麽地方，共享單車的App就可以告訴我們附近有什麽商圈、酒店、餐館，在什麽地方買東西可能還可以用移動支付。當視角從單車走到了其他行業，就開始跨界關聯了，另外車輛排程也是需要數據演算法支撐的，同理還有外賣等行業。
然而新事物發展必然是有利也有弊的，數據技術也不例外，數據改變生活，但同時也給我們帶來一些威脅。相信大家都有感觸，今天網購個東西，明天一堆詐騙電話、騷擾資訊接踵而來，什麽海景房、小額貸款、各種培訓等等每天就好像狗皮膏藥天天騷擾我們。
下面這張圖是摘錄的2018年部份數據泄密事件，可以看到今天我們的數據並不安全，幾乎每個月都有發生數據泄露事件。
另外國家和國際方面對數據安全的法律法規也越來越嚴，近些年陸續出台了許多安全合規制度。可見在數據技術時代，數據安全的保障已經是每個企業需要承擔的責任和義務。
二、企業數據安全威脅
2018年波洛蒙研究所做了一個企業內部威脅成本報告，發現內部問題占比最高，企業數據安全威脅主要來自內部。
為了找到58到家內部的威脅，我們在內部做了一些調研。58到家主營業務是家庭服務行業，是一個連線勞動者和使用者的平台，而且使用者很垂直，例如月嫂、育兒嫂對應的使用者就是母嬰家庭，另外也會有一些明星客戶、商務客戶等，因為服務總要落到線下，就會涉及到客戶的一些家庭資訊。所以不論是我們的客戶資訊、服務人員資訊（因為家政服務人員都是我們自己培訓出來的），以及員工資訊、財務數據等等，這些都是我們要保護的數據。
需要保護哪些東西找到了，接下來就是見招拆招，從哪些人能夠接觸到這些數據、什麽環境能夠接觸到這些數據等場景去考慮，詳見下圖：
惡意入侵：來自外部的入侵或攻擊，這是所有公司都有可能會遇到的問題；
IT管理：運維、DBA、BI、特權賬戶等許可權大、掌握的數據量也大；
業務人員：這類人員比較難以管控，因為群體大，並且他們本身拿到的就是一些明文數據；
合作方：直接拿到的也是明文數據，而且本身就有許可權，只不過是看他們需不需要讀取這麽多數據而已。
三、數據安全探索實踐
以上分析了我們需要保護的數據以及威脅來源，接下來具體看看我們58到家在數據安全上的探索。
安全治理的前提是基礎安全要做好，基礎安全就像房子的根基，如果根基不穩的話也就談不上後面的蓋大樓了，所以數據安全的前提還是要先做一些基礎安全的保障，包括以下這些部份：
接下來是58到家在數據安全的體系化建設上的整體指導思路，整個體系的核心是數據，治理的物件是人。
首先要知道數據在哪，這就需要做到數據發現，要知道哪些居里面存在著敏感數據。其次要對已知的數據做好對應的分類分析。把前兩項處理好後，再考慮哪些人能夠存取這些數據，做好認證和許可權的管控。再之後就要考慮做好對應監控和審計工作。最後當我們發現違規或泄密時，要能及時做好事中的阻斷和事後的溯源。
早期的數據分類發現是透過人工的方式實作，但這樣無法做到及時更新，後來慢慢的采取了一些自動化的數據發現技術，並在過程中進行敏感數據的自動打標。
接著在認證許可權這塊，58到家目前人員打通了HR系統、SSO系統、許可權系統、業務系統，特別是針對業務人員的管控問題，我們首先對員工做了身份統一處理。從員工入職開始就匹配人員角色，分配角色許可權並增加統一認證。同時，在執行過程中會有監控規則，比如涉及敏感數據許可權時，需要對應的審批，審批過程會自動進行職責分離，敏感許可權分析等自動化分析，在使用過程中還會有對應審計；員工離職時，其相應的角色許可權也會被一並清除。
有了這種認證和許可權之後，下面講一下我們是如何做好事中或事後的監控、溯源和阻擊的。
我們的監控體系主要分成三塊，一是堡壘機日誌、Binlog和Gltlab日誌，會對其中的敏感操作進行審計，若發生敏感操作則會發出告警或阻斷；二是基於業務人員做的，首先會對包括Nginx-Lua、SSO日誌、AMS日誌、VPN日誌、上網行為日誌在內的日誌做數據過濾，把發現的敏感介面推薦出來，然後基於這些介面做了一些引擎和規則的判斷，包括一些場景的錄用等做了線上分析和離線分析，同時整合到SOC上去做一些告警，聯動防火墻等做一些阻斷；三是鑒權分析和被動掃描這塊，主要是用於降低業務人員的一些行為風險，比方說違規操作、存取數據異常、賬戶盜用、登入異常以及一些介面的異常等。
這個系統上線之後，幫助我們發現了不少內部人員違規讀取數據的問題，我們也都一一做了相應的處理。當然我們也踩過不少坑，最後跟大家分享下這些坑，給大家一些避坑建議。
坑1、監督&賦能：很多安全部門都會有一種自己是監督人的心態，但這樣跟業務溝通時會讓他們產生抵觸心理，覺得安全的人是來挑事兒的，導致很多東西無法推進，得不償失。所以我們應該把自己作為服務方，去給業務賦能，讓業務產生信賴，甚至會主動找我們做些介入。
坑2、閉門造車&多部門協作：起初我們安全自己做了很多東西，但做好後真正要上線時，發現需要其他部門做些對應的協助，可能就會有不太樂意的情況。所以涉及到跨部門的專案，做之前一定要提前做好規劃和溝通。
坑3、抓主要矛盾：我剛到58到家的時候比較心急什麽都想做，包括基礎安全、數據安全、業務安全等等，但做了一堆東西後發現這樣反而什麽都沒做好。所以還是應該先做好基礎安全，然後根據公司自身的需求再一步步做其他安全建設。
坑4、先技術&技術管理並重：起初我們認為能用技術解決的就不要去扯別的，後來我們發現如果沒有制定明確的制度，會導致很多許可權問題，有時就算發現了異常也很難追究清楚，所以前期制定好明確的規章制度還是非常有必要的。
坑5、黑貓白貓能抓老鼠就是好貓：只要能滿足自身需求，無論是自研也好、采購也好、開源改造也好，都是可以的。而且也未必要使用一些高大上的技術，比如說我們的數據安全分析平台原本是打算用機器學習的，但實際上我們內部數據存取量其實沒那麽大，後來我們發現利用統計學的一些規則直接就可以解決問題，沒必要用到AI演算法等。所以歸根到底，只有適合自己的才是最好的。
>>>>
Q&A
Q1：告警規則的制定有要求嗎？
A：告警規則的話我們的做法是先收集一些互聯網數據風險案例，同時和內審、監察聊下他們處理的一些內部歷史案例，最後再結合業務場景腦暴列出一些違規行為，制定一些對應的規則；至於規則的閥值的話，前期可以設定低點，慢慢根據歷史數據最終逐步給角色或者細化到每個人去畫像。
Q2：有基於日誌的告警方案嗎？
A：目前我們自己用的告警的話是使用的內部架構提供的，一個封裝好的服務。不過我們之前也做過一些其它的，例如使用ES做一些告警。有個開源的Elastalert你可以看下。
Q3：怎麽給老板衡量做安全的投入產出？
A：這個問題其實是所有安全團隊都會遇到的問題，相對業務來說安全本身是支出部門，想要講清楚這個比較難，不過又恰恰是很重要的。
這塊我的經驗是如果是基礎安全的話，比如我們發現並解決了多少問題，這些問題如果是被外界獲取，可能帶來哪些損失。如果是SDL的投入，至少能夠保證我們做完這些專案需求評估後，要保證不會出現除0 day以外的高危安全問題。
如果是數據安全相關的話，這個其實還算比較好講的，就是我們發現了多少違規或者泄密，挽回了多少損失。
Q4：你們安全團隊多大？與運維、大數據的關系？
A：安全團隊的話去年相對規模大一點，近10人。今年年初有所調整，目前的規模要小一些；現在安全團隊和運維、大數據都是並列的兄弟部門。也是因為目前安全團隊相對較小，所以和運維以及BI還有DBA、架構、配置管理等等各部門都會有一些合作一些專案。
Q5：怎麽做數據脫敏的？敏感數據存取的審批和執行怎樣才能快點？
A：數據脫敏的話，首先明確哪些是敏感的，然後確定哪些是可以完全脫敏的，那些是數據分析或者外部合作必須要是使用的。明確出來一些等級，然後根據不同需要，選擇是動態還是靜態，是可逆的還是不可逆的等等。
審批過程的化，還是要配合一些線上化的流程，剛剛分享裏面有提到我們數據地圖發現，這塊打的一些標簽。這塊是如果對方申請匯出內容不涉及敏感欄位那自動透過，反之工單就需要按照不同環節就行流轉。
Q6：如何保證數據視覺化過程中不會數據泄露？
A：這個多方面去處理吧，套用顯示的話可以不顯示全部的，例如188(點選脫敏)9999；這樣這個點選過程就可以做到記錄，超頻異常的話也可以告警。
對於拍照截圖這樣的其實只能依賴浮水印了，當然這個方面目前我們也只是明浮水印只是震懾作用。
安全側還可以去做的點，就是今天提到的流量介面的監控了，還有一些許可權的管控。
Q7：程式連線線上數據庫，你們怎麽避免開發人員接觸線上數據庫連線參數的？
A：在到家的話，首先網絡是有嚴格安全域劃分的；部署是要透過統一部署平台的，也就是一般情況下開發人員是不需要存取線上主機或數據庫的許可權。另外套用呼叫數據時候不是直接使用密碼連線數據庫的，是使用key代替密碼，透過keycenter系統中轉的，這樣數據庫連線就是白名單形式，開發人員是沒辦法直接連線線上庫的。
