企業安全體系建設方案設計（內附案例）

今天講一講安全體系建設方案，對於企業來講，安全體系一直是比較關心的話題，不管大企業仍是小企業都對於如何建設安全體系以及什麼是安全，存在必定的疑問，這篇文章就從基礎組成的角度來討論一下安全架構的建設。

安全架構包括哪些方面？

物理方面
好比機房的安全，物理服務器的安全，硬盤的安全。有人可能會問，個人服務器是放在雲上的，存在物理方面的安全嗎？固然，對於企業而已，雲端的物理安全是不須要過於擔憂的，由於雲提供方會對他們的雲機房作物理安全監控，但其實有不少信息在初期也是須要考察的，好比雲機房的監控，雲機房的人員訪問審查，雲機房的高可用，雲服務器的使用時長等等。

舉個例子

在這裏舉個例子，咱們的服務器使用時間大概已經有5年時間，主板電池有些問題，服務器一旦重啓就會刷新時區，比正常的業務時間慢8個小時，HTTPS校驗時間時就出了問題，致使業務進不來。Crontab的執行時間同步一旦沒有達到秒級就會存在這個問題，可是正常誰會把時間同步定義到秒級呢？這個問題直接致使了業務的癱瘓，因此在選擇雲供應商的時候必定要詢問他們的宿主機使用時長。

雲物理監控須要看什麼？
好比須要監控進出機房的人員，早些時候會有一些編外人員以雲提供商的身份進入雲機房進行數據竊取，這方面國外最嚴重，國內通過管控已經好不少，可是物理監控依舊不能掉以輕心。

數據方面
數據安全，好比存放的數據加密，必要時須要脫敏處理，加密儘可能採用雙層加密，這裏分享一下個人作法：
原始數據的脫敏處理（因爲是互聯網金融行業，會存在我的信息的傳輸，存儲中如非必要，這類信息是不容許存儲的，須要脫敏，好比銀行卡號保留前4後4位等做爲支付依據，覈對時覈對關鍵信息）。
第一層採用3DES加密算法，把數據進行加密；
第二層採用RSA強加密算法（2048位）加密3DES的密鑰；
最終密鑰存放於加解密系統中，此係統會對存放的密鑰作亂序處理，只有相關權限的人申請，拿到亂序的密鑰，經過CEO或CTO受權，由密鑰負責人作恢復處理，才能拿到密鑰。
這塊雖然流程會很麻煩，可是可以最大程度的保障數據的安全。

應用方面

其實應用安全是***者們最喜歡***的方面，也是最容易被***的方面，如何作好應用安全，決定了***們可否攻進或者攻進的難易程度。下面從幾個方面來討論我對於應用安全的處理辦法：

1
誰
首先其實看到這個小標題，相信有不少人是懵的，簡單講述一個小例子好了，我用Jenkins舉例，Jenkins是開源的自動化項目部署平臺，通常項目作發佈的時候使用的，與Apollo不同，具體差別我並無研究，可是爲告終合項目架構，兩套自動化部署平臺我都有搭建，Apollo更多體如今微服務化，Jenkins更可能是使用項目發佈。
Jenkins在剛剛安裝好的時候會設置訪問矩陣，就是說受權什麼人作什麼事情，好比運維受權作項目發佈，腳本執行，審計受權作日誌查看等等，這個時候其實有幾種不正常的行爲：

（1）未受權訪問

未受權訪問是指沒有被受權的用戶能夠訪問到系統中，並擁有受權用戶的權限。
仍是以Jenkins舉例，早期的Jenkins初始化後是沒有訪問矩陣配置的，形成不少使用者不瞭解，同時也不知道未受權訪問的危害，在公網上暴露的Jenkins數不勝數，或許使用者本身都沒有發現，登陸Jenkins，空用戶名、空密碼是能夠登陸的，這在訪問矩陣中是everyone的身份，可怕在於everyone默認是有全部權限的，直接致使任何人只要發現Jenkins未受權訪問，就能夠進入到Jenkins中而且執行shell命令，這在Jenkins中是客觀存在的，放下截圖。

一樣存在未受權訪問這個問題的還有不少，好比zeppelin、redis、zookeeper、elasticsearch、docker、hadoop等等。
這裏個人建議是作好「誰」的把控，控制好全部的應用訪問權限，什麼人訪問什麼系統，擁有什麼權限，固然這裏人的判斷依據最好是雙因素判斷。
而且應用系統最好是放在內網並作訪問控制，即便爆出0day也不會第一時間被掃到利用。
公網上開放的應用越少，相對***的***層面就越少，***難度也就越大。
（2）越權訪問

越權訪問是指合法用戶，指定A權限，但卻能夠作B權限能作的事情。
在這裏仍是以Jenkins爲例：

在這裏直接貼個漏洞編號，有興趣的能夠查一下，這個漏洞雖然官方說是嚴重級別，可是我給他評級只能評中危，所以沒有詳細貼出來。

由於此漏洞是須要Jenkins重啓，然而通常這種放在生產環境的運維工具是極少有重啓的機會的，除非配合DoS***或者等待機房故障等不可逆因素。
漏洞總體描述是***者可利用CVE-2018-1999001漏洞從Jenkins主目錄下移除 config.xml 配置文件到其餘目錄，當Jenkins 服務再次重啓時，因加載不了config.xml中配置的安全域和受權策略，退回 legacy 模式，而且賦予匿名用戶管理員訪問權限。
當***者獲取Jenkins權限後，可查看構建歷史數據，甚至可下載工做區的代碼，致使核心代碼泄露。
***者在進入管理頁面後，可經過「系統管理」下的「腳本命令行」功能，執行用於管理或故障探測或診斷的任意腳本命令，對Jenkins系統服務器產生比較嚴重的影響和危害。
其實是就是越權訪問改動了config.xml文件，以後經過未受權訪問***服務器。
越權訪問通常是因爲權限管控不當而發生的，個人建議是在權限規劃時，執行最小權限管控，分的稍微細緻一些，而且認證必定要作好，每個都須要認證機制，這樣可以最大程度下降越權訪問發生的可能。

（3）繞過認證訪問

早期比較流行，好比在認證頁面，正常輸入用戶名密碼，經過sql注入的方式使sql語句成爲真值的計算，即可以跳過認證，進入系統中。

目前也有很多CMS系統存在繞過認證訪問。或經過撞庫的方式也算是繞過認證。

以前Akamai有個統計，從2017年11月初到2018年6月末，Akamai的研究分析結果顯示，惡意登陸嘗試在8個月內超過300億次。

全球惡意登陸的次數在不斷增長，狀況不容樂觀。面對如此嚴重的暴力撞庫***，有什麼好辦法能夠避免嗎？

其實不少人會想到雙因素登陸，可是一樣有不少人分不清雙因素登陸與雙因子登陸的區別。

雙因素登陸是指在登陸時同時驗證傳統密碼與第二因素認證，而雙因子登陸是指先認證傳統密碼，成功後再認證第二因素。

這二者區別就在於雙因素沒法判斷密碼是不是正確，而雙因子即便有第二因素，還能夠爆破出密碼，而後經過此密碼進行撞庫。

在這裏有個假設，一旦企業郵箱的密碼與爆破出的密碼是同一個，那麼企業信息泄露，甚至是專業的社工釣魚便會如夢魘通常圍繞着你，圍繞着企業。

在這裏建議是使用雙因素登陸認證來規避繞過認證訪問的問題。

2
作什麼

經過行爲判斷是否異常。通常來講，正經常使用戶不會執行異常請求。仍是用Jenkins舉個例子：
正經常使用戶，好比運維，執行腳本通常會執行項目替換代碼，好比編譯jar包，好比替換等等；
***者在拿到命令執行權限的時候第一時間使用的命令通常是身份類型命令，好比whoami、w、last等等；
然而這些信息通常Jenkins正常操做都是用不到的，須要作管控。固然Jenkins自己權限要執行權限最小化，那也固然不多是root，在執行時也一樣會增大***難度。

3
怎麼作

這一點要考慮***可能經過什麼手段***應用，最多見的OWASP TOP10中的SQL注入、XSS、XXE、惡意文件上傳、CSRF、×××F等等，基於這些***手段建議採用WAF來阻斷惡意***，具體後續會分享開源WAF體系的建設，包括WAF自己與日誌審計、告警工做，感興趣可留言討論，歡迎關注。

主機層面
主機安全是相對於以上全部安全中最難把控的，包括服務器安全和終端安全。
技術層面的安全相對來講比較好把控，包括服務器終端的基線安全、殺軟、訪問控制等等，可是最很差把控的實際上是人爲的因素。
案例一大把，隨便舉例子，員工私設WiFi設置弱口令致使***鏈接到企業內網，進行內網***；員工瀏覽惡意網站致使終端植入感染病毒，傳播擴散到企業內網。
這種事情還有不少，憑藉管理制度並不足以防止此類事件的發生，那麼主機安全應當如何作？在這裏分享個人治理方法：
首先服務器使用ansible推送安裝ClamAV，按期進行查殺，這裏可使用crontab進行定時任務，並將結果反饋，反饋能夠經過filebeat傳遞到日誌分析中去作，告警也在日誌分析中規範告警條件。
終端以360爲例，統一管控，360有服務端和客戶端，在服務器設置統一管控密碼，客戶端分發安裝到各終端，終端便會定時殺毒，並且不能被關閉。
按期開展企業培訓，提升全部人的安全防範意識，在路由器上設置訪問控制，禁止訪問有害網站（利用爬蟲作黑名單訪問控制）。

網絡層面
網絡層面重點體如今防火牆管控DMZ區的流量進出，管控跨網之間的訪問哪些屬於合規哪些不合規。
舉個例子，假如說個人某一個業務放在阿里雲，監控體系與主體業務在騰訊雲，因爲成本問題我不想在阿里雲單獨創建一套監控體系，只想延用騰訊雲的監控體系，但又要保證業務之間的隔離，那麼這時候就要在雲兩端架設×××，而且設置僅容許監控系統與業務之間互相訪問。
可是要保證×××的穩定性，在目前國內的形式來講應該是挺難的，尤爲前段時間的護網行動，×××基本天天都斷上幾回。
多鏈路可靠訪問是針對網絡堵塞、大環境網絡故障、意外***等狀況設計的業務可用性的體現。
試想一個業務域名，好比ex.com，當遇到DDoS***時，大量的商戶訪問不到業務域名，形成的損失有多大；
或者大環境網絡出現故障，好比前段時間發生的114DNS故障致使域名沒法訪問、中間節點路由出現故障等等，形成的損失也是巨大的。
這時多線路解析以及雙線路出入口的設計可以最大程度保證業務的可用性，也就是咱們所說的CDN和雙出口。

安全不只僅是技術工做，更是管理工做，一切都是爲了確保業務可以正常開展。咱們須要應急，可是若是能夠，誰又想須要應急。