[[143107]]

嘉賓介紹

朱磊，（James Wharton），現(xiàn)任北京沃頓在線執(zhí)行總裁，復旦大學外聘主講（安全軟件架構課程）。前京東、完美世界高級安全經理、負責運維安全、業(yè)務安全方向，主導運維流程建設、安全系統(tǒng)設計、信息安全體系落地。

主要內容

將運維進行層次劃分，從網(wǎng)絡到前端防護逐級分解各層次中安全的風險，以及在安全方向應該重心的地方。

本次分享主要集中在網(wǎng)絡安全、系統(tǒng)安全和權限管理這三個層次。

引子

如上圖，這是比較常見的互聯(lián)網(wǎng)公司內部網(wǎng)絡劃分的方式：

• 簡單點的會有辦公網(wǎng)和生產環(huán)境;

• 稍微好一些的，會為研發(fā)團隊單獨劃出一個物理隔離的開發(fā)環(huán)境。

其中，針對辦公網(wǎng)的劃分比較講究的是按部門進行VLAN的劃分，不同部門之間的VLAN無特別需求是不能相互訪問的。

這點針對黑客或內網(wǎng)病毒、ARP攻擊的抵御是比較有效的。然而，公司內網(wǎng)只是在心理上讓員工覺得大家是在一個獨立的網(wǎng)絡里，外面接觸不到，但正是這種心理以及非技術人員安全意識不夠，讓公司內網(wǎng)成為了攻擊者的首選目標。

試想，市場部門打開一個要求市場合作的郵件是多么正常的行為，HR打開應聘者的簡歷同樣是多么正常的行為。

但市場人員和HR的員工是不具備分辨郵件附件是否是病毒的能力，而攻擊者在滲透的初期通常會做信息收集。

通過百度、GOOGLE、Bing這類搜索引擎公司暴露在外的郵件地址，然后對這些郵件地址按照部門進行簡單分類，再針對不同崗位職責為病毒文件編輯不同的文件名稱，如發(fā)給市場的文檔，就叫XXX市場合作方案.docx；給HR的就叫XXX簡歷.docx等。

當病毒在內網(wǎng)中被執(zhí)行，黑客就有了一個攻擊內網(wǎng)的跳板，此時如果內部的辦公網(wǎng)絡沒有按部門進行劃分和ACL的限制，那么攻擊者就會借助跳板在內網(wǎng)中進行弱口令掃描，發(fā)起ARP欺騙。

再有一類風險是，員工電腦偶爾會收到“X.X.X.X地址正在掃描你的主機”此類主機防御軟件的報警提示，當然，只要被防御軟件提示出來的，我們都應該比較放心，因為攻擊被攔截了，但非技術人員不一定這么想。

而針對內部的防御系統(tǒng)部署，其實是個大工程，防御不是一個系統(tǒng)去解決的事情。好比國家安全的防御部署需要涵蓋海陸空，企業(yè)也一樣，防御包括從網(wǎng)絡邊界到區(qū)域訪問、從系統(tǒng)安全到應用系統(tǒng)策略等。

為了方便理解，我將整體的防御做了一個歸類分層，這就是我所說的運維安全塔叻。本次分享著重在網(wǎng)絡安全和系統(tǒng)安全。

運維塔第一層：網(wǎng)絡安全

運維小塔有7層，我們從底層往上解讀，首先是第一層網(wǎng)絡安全。網(wǎng)絡是基礎，這就是為什么開始的時候先以內網(wǎng)區(qū)域劃分以及舉例不嚴格VLAN+ACL的例子開場。

網(wǎng)絡層，除了剛才提到的辦公區(qū)域的劃分，同時還要重點針對運維環(huán)境、開發(fā)測試環(huán)境和生產環(huán)境通道進行明確。

這里的明確不只是簡單地把區(qū)域給界定出來，而是要初步定義ACL的主框架。默認的安全策略采用白名單機制，沒有特別需求的網(wǎng)絡區(qū)域之間是不能訪問的，有需求單獨提出，同時配合流程及制度，然而策略也并非一直留存，而是要定義一個策略的有效周期。不然通行策略開的多了，白名單的區(qū)域限制策略就失去意義了。

#p#

運維塔第二層：系統(tǒng)安全

系統(tǒng)層，在感知程度上很貼近運維工程師，無論怎么樣的維護、變更、升級和上新業(yè)務都與這個基礎打交道。接下來我們來到第二層——系統(tǒng)安全。

無論是操作系統(tǒng)、數(shù)據(jù)庫還是應用程序，在安全的考慮中，最頭疼的其實是版本的不同和交叉的業(yè)務。

面對安全人員或一些安全加固文檔，都會比較經常能聽到的一句話是“最小權限”。

其實，最小權限這句話沒有什么錯，但這只是一個方向性的引導，并沒有什么實質性的價值，我們更多時候也知道為了安全要最小化授權。但是這時候就懵圈了——什么是最小化授權？

這里說的最小化授權，其實是有一個前提——就是對業(yè)務的了解程度。

比較常見的情況是，安全工程師對運維工程師說：“你們維護的業(yè)務和服務器在跑交叉業(yè)務是不安全的，要安全就要最小授權。”運維工程師這時候可能就會罵：“你是SB么。服務器上這么多業(yè)務最小個什么毛權限，你小給我看。”

其實，這個時候安全工程師也是比較難辦的，因為不知道這服務器上的業(yè)務具體提供的是什么業(yè)務，也不清楚業(yè)務之間的邏輯，所以在不知道業(yè)務邏輯或交互細節(jié)的時候，安全工程師也不能很有效地給出一個最小權限的建議。

但這并不代表安全無法下手，其最簡單的方法就是業(yè)務拆分或就死磕了，把交叉業(yè)務的邏輯關系摸清楚，針對不同應用啟用不同用戶、各普通用戶之間不能相互訪問等限制。

無論是運維安全還是業(yè)務安全，都要有一個側重點，聽起來雖然很像個廢話，但是這值得作為一句廢話不斷地被說出來，因為技術人員通常是鉆牛角尖的

就愛死磕難點，覺得越難越有價值。

我不去否認或辯解這個觀點，只是做為一個提醒，很多時候我們把大把的精力放在這些所謂的技術難點上，而忽略在當前環(huán)境中，最常見的問題是什么。

在以前，我覺得弱口令是因為懶的記密碼，但弱口令這個事情要分環(huán)境看，員工PC的弱密碼和運維支撐系統(tǒng)弱密碼是兩回事。

先說員工PC弱密碼的事情。

早些時候我真的覺得是因為員工懶，后來發(fā)現(xiàn)原因并非這么簡單，當然懶只是其中的一個原因，考勤在各公司都是常見的公司規(guī)定，我相信很多同學都有替同事打過卡或者讓同事幫自己打卡。其實，這個需求催生了很多人把密碼設置成弱密碼。

很奇怪吧！為什么會這樣?因為大家都有一顆保護自己的心。現(xiàn)在大家都認可密碼通這種事情了，一個密碼通殺所有個人賬戶，為了給自己來個保護，辦公PC機就來個弱口令吧，反正只要不影響到自己生活就好。

第二個，運維弱口令的。

做運維的各位，你們中存在使用弱口令的嗎？

運維團隊有兩個問題是攻擊者比較喜歡的：

• 1.弱口令；

• 2.低版本應用。

弱口令事情可以粗略的歸到偷懶這個原因，而低版本的考慮就是穩(wěn)定的問題了。

關于口令這個問題解決辦法已經比較成熟了，有用動態(tài)口令的，也有用強制密碼策略的。而針操作系統(tǒng)的安全策略，以下給出幾個簡單的策略；

其實，針對操作系統(tǒng)安全加固的部分都比較傳統(tǒng)而簡單，簡單的東西難點在于落地實施和集中管理，策略只是安全的一小部分。其實運維有一些工具是存在安全問題的，比如常見的rsync，rsync做數(shù)據(jù)同步的時候需要一個系統(tǒng)賬號，而我見過比較帥的運維，rsync的賬號直接用root。

在運維過程中，安全的重心應該是流程與制度的落實，像針對操作系統(tǒng)的安全策略和ACL，只是技術的輔助手段，只要能做到集中管理起來，安全策略的落地，這都好辦。重點還是流程制度與技術的配合，針對運維人員的權限劃分、惡意操作和越權操作等。

第六層：權限管理

因為時間關系，本次跳過第三、四、五層，以后的主題分享會再做闡述。

運維安全的核心是權限管理，或者說是權限分離更容易理解。無論是操作系統(tǒng)、數(shù)據(jù)庫還是應用程序，都應該依據(jù)不同的業(yè)務場景設置權限。

例：操作系統(tǒng)的權限要分為：

1. 系統(tǒng)管理員（分配給運維團隊中較高職位的人）；

2. 維護賬號（分配給普通工程師，賬號權限主要做業(yè)務的運維。針對該賬號要限制一些高權限命令的執(zhí)行限制）：

3. 為不同的應用建立不同的賬號用于應用的獨立啟動；

4. 應用程序的賬號要去掉遠程登陸權限。

這些策略以核心業(yè)務系統(tǒng)為必備，輔助系統(tǒng)或不相關的系統(tǒng)選配。安全也是要考慮成本的。

下面是本次分享的部分互動環(huán)節(jié)整理。

問題1：運維工作大部分的安全問題，是不是在網(wǎng)絡層面根據(jù)安全級別進行邏輯分區(qū)，效果事半功倍？

答：無論是網(wǎng)絡層、系統(tǒng)層還是業(yè)務層，安全的策略都需要一個場景，就是指業(yè)務的重要程度，所以在定義安全策略之前首先要明確的是，你所要保護的系統(tǒng)或數(shù)據(jù)，其重要程度是多少。

問題2：賬號如何統(tǒng)一管理，授權和審計?

答：賬號統(tǒng)一管理有多種方案，有Windows域、基于kerberos以及LDAP或兩者結合的。授權和審計可以使用現(xiàn)成的堡壘機這種現(xiàn)成的產品。或者就自己開發(fā)一套審計系統(tǒng)，在網(wǎng)絡中建一個LOG SERVER，然后LOG入數(shù)據(jù)庫，并聯(lián)員工的賬號，然后讓員工審計自己的操作過程，同時員工確認之后，升級領導可以再做一次確認。

如何一起愉快地發(fā)展

高效運維系列微信群是國內高端運維圈子、運維行業(yè)垂直社交的典范?，F(xiàn)有會員800余名，其中運維總監(jiān)及以上級別會員300多名。

“高效運維”公眾號值得您的關注，作為高效運維系列微信群的唯一官方公眾號，每周發(fā)表多篇干貨滿滿的原創(chuàng)好文：來自于系列群的討論精華、運維講壇線上/線下活動精彩分享及部分群友原創(chuàng)。“高效運維”也是互聯(lián)網(wǎng)專欄《高效運維最佳實踐》及運維2.0官方公眾號。

提示：目前高效運維兩個微信主群僅有少量珍貴席位，如您愿意，可添加蕭田國個人微信號 xiaotianguo 為好友，進行申請；或申請加入我們技術交流群（技術討論為主，沒有主群那么多規(guī)矩，更熱鬧）。

重要提示：除非事先獲得授權，請在本公眾號發(fā)布2天后，才能轉載本文。尊重知識，請必須全文轉載，并包括本行及如下二維碼。