將運維進行層次劃分，從網絡到前端防護逐級分解各層次中安全的風險，以及在安全方向應該重心的地方。本文主要集中在網絡安全、系統安全和權限管理這三個層次。引子
如上圖，這是比較常見的互聯網公司內部網絡劃分的方式：
簡單點的會有辦公網和生產環境;
稍微好一些的，會為研發團隊單獨劃出一個物理隔離的開發環境。
其中，針對辦公網的劃分比較講究的是按部門進行VLAN的劃分,不同部門之間的VLAN無特別需求是不能相互訪問的。
這點針對黑客或內網病毒、ARP攻擊的抵御是比較有效的。然而，公司內網只是在心理上讓員工覺得大家是在一個獨立的網絡里，外面接觸不到，但正是這種心理以及非技術人員安全意識不夠，讓公司內網成為了攻擊者的首選目標。
試想，市場部門打開一個要求市場合作的郵件是多么正常的行為，HR打開應聘者的簡歷同樣是多么正常的行為。
但市場人員和HR的員工是不具備分辨郵件附件是否是病毒的能力，而攻擊者在滲透的初期通常會做信息收集。
通過 百度、GOOGLE、Bing這類搜索引擎公司暴露在外的郵件地址，然后對這些郵件地址按照部門進行簡單分類，再針對不同崗位職責為病毒文件編輯不同的文件名稱，如發給市場的文檔，就叫XXX市場合作方案.docx;給HR的就叫XXX簡歷.docx等。
當病毒在內網中被執行，黑客就有了一個攻擊內網的跳板，此時如果內部的辦公網絡沒有按部門進行劃分和ACL的限制，那么攻擊者就會借助跳板在內網中進行弱口令掃描，發起ARP欺騙。
再有一類風險是，員工電腦偶爾會收到“X.X.X.X地址正在掃描你的主機”此類主機防御軟件的報警提示，當然，只要被防御軟件提示出來的，我們都應該比較放心，因為攻擊被攔截了，但非技術人員不一定這么想。
而針對內部的防御系統部署，其實是個大工程，防御不是一個系統去解決的事情。好比國家安全的防御部署需要涵蓋海陸空，企業也一樣，防御包括從網絡邊界到區域訪問、從系統安全到應用系統策略等。
為了方便理解，我將整體的防御做了一個歸類分層，這就是我所說的運維安全塔叻。本次分享著重在網絡安全和系統安全。
運維塔第一層：網絡安全
運維小塔有7層，我們從底層往上解讀，首先是第一層網絡安全。網絡是基礎，這就是為什么開始的時候先以內網區域劃分以及舉例不嚴格VLAN+ACL的例子開場。
網絡層，除了剛才提到的辦公區域的劃分，同時還要重點針對運維環境、開發測試環境和生產環境通道進行明確。
這里的明確不只是簡單地把區域給界定出來，而是要初步定義ACL的主框架。默認的安全策略采用白名單機制，沒有特別需求的網絡區域之間是不能訪問的，有需求單獨提出，同時配合流程及制度，然而策略也并非一直留存，而是要定義一個策略的有效周期。不然通行策略開的多了，白名單的區域限制策略就失去意義了。
運維塔第二層：系統安全
系統層，在感知程度上很貼近運維工程師，無論怎么樣的維護、變更、升級和上新業務都與這個基礎打交道。接下來我們來到第二層——系統安全。
無論是操作系統、數據庫還是應用程序，在安全的考慮中，最頭疼的其實是版本的不同和交叉的業務。
面對安全人員或一些安全加固文檔，都會比較經常能聽到的一句話是“最小權限”。
其實，最小權限這句話沒有什么錯，但這只是一個方向性的引導，并沒有什么實質性的價值，我們更多時候也知道為了安全要最小化授權。但是這時候就懵圈了——什么是最小化授權?
這里說的最小化授權，其實是有一個前提——就是對業務的了解程度。
比較常見的情況是，安全工程師對運維工程師說：“你們維護的業務和服務器在跑交叉業務是不安全的，要安全就要最小授權。”運維工程師這時候可能就會罵：“你是SB么。服務器上這么多業務最小個什么毛權限，你小給我看。”
其實，這個時候安全工程師也是比較難辦的，因為不知道這服務器上的業務具體提供的是什么業務，也不清楚業務之間的邏輯，所以在不知道業務邏輯或交互細節的時候，安全工程師也不能很有效地給出一個最小權限的建議。
但這并不代表安全無法下手，其最簡單的方法就是業務拆分或就死磕了，把交叉業務的邏輯關系摸清楚，針對不同應用啟用不同用戶、各普通用戶之間不能相互訪問等限制。
無論是運維安全還是業務安全，都要有一個側重點，聽起來雖然很像個廢話，但是這值得作為一句廢話不斷地被說出來，因為技術人員通常是鉆牛角尖的
就愛死磕難點，覺得越難越有價值。
我不去否認或辯解這個觀點，只是做為一個提醒，很多時候我們把大把的精力放在這些所謂的技術難點上，而忽略在當前環境中，最常見的問題是什么。
在以前，我覺得弱口令是因為懶的記密碼，但弱口令這個事情要分環境看，員工PC的弱密碼和運維支撐系統弱密碼是兩回事。
先說員工PC弱密碼的事情。
早些時候我真的覺得是因為員工懶，后來發現原因并非這么簡單，當然懶只是其中的一個原因，考勤在各公司都是常見的公司規定，我相信很多同學都有替同事打過卡或者讓同事幫自己打卡。其實，這個需求催生了很多人把密碼設置成弱密碼。
很奇怪吧,為什么會這樣?因為大家都有一顆保護自己的心。現在大家都認可密碼通這種事情了，一個密碼通殺所有個人賬戶，為了給自己來個保護，辦公PC機就來個弱口令吧，反正只要不影響到自己生活就好。
第二個，運維弱口令的。
做運維的各位，你們中存在使用弱口令的嗎?
運維團隊有兩個問題是攻擊者比較喜歡的：
1.弱口令;
2.低版本應用。
弱口令事情可以粗略的歸到偷懶這個原因，而低版本的考慮就是穩定的問題了。
關于口令這個問題解決辦法已經比較成熟了，有用動態口令的，也有用強制密碼策略的。而針操作系統的安全策略，以下給出幾個簡單的策略;
其實，針對操作系統安全加固的部分都比較傳統而簡單，簡單的東西難點在于落地實施和集中管理，策略只是安全的一小部分。其實運維有一些工具是存在安全問題的，比如常見的rsync，rsync做數據同步的時候需要一個系統賬號，而我見過比較帥的運維，rsync的賬號直接用root。
在運維過程中，安全的重心應該是流程與制度的落實，像針對操作系統的安全策略和ACL，只是技術的輔助手段，只要能做到集中管理起來，安全策略的落地，這都好辦。重點還是流程制度與技術的配合，針對運維人員的權限劃分、惡意操作和越權操作等。
第六層：權限管理
因為時間關系，本次跳過第三、四、五層，以后的主題分享會再做闡述。
運維安全的核心是權限管理，或者說是權限分離更容易理解。無論是操作系統、數據庫還是應用程序，都應該依據不同的業務場景設置權限。
例：操作系統的權限要分為：
系統管理員(分配給運維團隊中較高職位的人);
維護賬號(分配給普通工程師，賬號權限主要做業務的運維。針對該賬號要限制一些高權限命令的執行限制)：
為不同的應用建立不同的賬號用于應用的獨立啟動;
應用程序的賬號要去掉遠程登陸權限。
這些策略以核心業務系統為必備，輔助系統或不相關的系統選配。安全也是要考慮成本的。
下面是本次分享的部分互動環節整理。
問題1：運維工作大部分的安全問題，是不是在網絡層面根據安全級別進行邏輯分區，效果事半功倍?
答：無論是網絡層、系統層還是業務層，安全的策略都需要一個場景，就是指業務的重要程度，所以在定義安全策略之前首先要明確的是，你所要保護的系統或數據，其重要程度是多少。
問題2：賬號如何統一管理，授權和審計?
答：賬號統一管理有多種方案，有Windows域、基于kerberos以及LDAP或兩者結合的。授權和審計可以使用現成的堡壘機這種現成的產品。或者就自己開發一套審計系統，在網絡中建一個LOG SERVER，然后LOG入數據庫，并聯員工的賬號，然后讓員工審計自己的操作過程，同時員工確認之后，升級領導可以再做一次確認。
京公網安備 11010502049343號