本文我們將針對如何解決問題來進行詳細說明，從問題入手，通過糾正或者培養(yǎng)良好的運維安全習慣，搭建完整的運維安全技術體系。

[[243739]]

一、培養(yǎng)良好的運維安全習慣

想要解決運維安全的問題，首先就必須要培養(yǎng)良好的運維安全習慣。這包括了很多方面的做法，比如：

端口開放

• 默認監(jiān)聽內(nèi)網(wǎng)或者本地;
• 如需監(jiān)聽全部外網(wǎng)，iptables、password和acl能加都加上。

iptables

• 在cmdb為機器或者服務設計好iptables規(guī)則，同時結(jié)合同步機制：
• 部署服務時使用cmdb生成的iptables同意更新;
• 測試時一旦清空iptables后使用自動或者手工方式刷回標準iptables。

權限管理

• 采用puppet、ansible或者saltstack等集群管理工具統(tǒng)一管理操作系統(tǒng)權限;
• 遇到臨時需要高級權限時手工后添加定時回收，量大時采用自動化方式配置。

腳本安全

• 校驗變量，特別是高危操作;
• 原則上不給腳本授權sudo密碼或者授予666的權限位。

密鑰管理

• 不要讓ssh私鑰離開你的辦公電腦;
• 聽IT的話，定期修改你的corp或者域密碼;
• 配置與代碼分離的一個理由是：賬號密碼不能寫在代碼里。

服務管理

• 能不用root啟動最好不要用root;
• 不要把服務根目錄放到你的home目錄。

代碼管理

• 跟工作相關的代碼禁止上傳github!!!
• 仔細學習git/svn等版本管理工具的使用姿勢;
• 定義好你的.gitignore，特別是刪除你的.DS_Store。

應用選型

• 安全性是應用選型的一個重要考慮點;
• 對漏洞修復和安全編碼不怎么積極的開源軟件，再好用都不要用。

關注應用安全配置文檔

• 一般應用程序的官方說明文檔會包含安全配置的章節(jié)，在部署時需要循序漸進，按照最佳實踐配置安全部分，而不是嫌麻煩直接跳過。

二、企業(yè)級運維安全體系

安全體系是一套很大的概念。從流程規(guī)范，到技術架構(gòu)，不是本文所能解釋清楚。因此，下面所探討的企業(yè)級運維安全體系，會把我接觸到的或者已經(jīng)落地的方案大體介紹一下，涉及到其中的具體落地，則待以后再撰文詳細討論。

首先，整套運維安全體系，其實屬于企業(yè)安全體系的一部分，所以大體上思路不會相差太多。其次，運維安全，更關注的是“運維”，所以像業(yè)務風控、反欺詐、app反編譯則不在考慮范圍之內(nèi)。下面讓我們一同看看一套完整的企業(yè)級運維安全體系長什么樣。

1、流程規(guī)范

運維規(guī)范如同人間法律，“人生而自由，卻無往不在枷鎖之中”。這套規(guī)范，不僅是約束、指引運維人員，也是約束、指引開發(fā)測試人員，以及圍繞生產(chǎn)活動的所有參與者。

培訓

此處的培訓不是安全部門做的員工安全意識培訓所能替代的，也不是針對開發(fā)測試人員舉辦的研發(fā)安全培訓，而是只面向運維人員的意識與技術培訓。就比如本文前面的安全陋習和安全習慣，就可作為意識培訓的藍本。而后面所講的技術體系，則可作為技術培訓的基礎。這類培訓可以放在校招培訓課程里，也可以放在部門沙龍講座里講。

審批+審核+評估

首先，審核或者審批，不是為了阻礙業(yè)務發(fā)展，更不是為了沒事找事，而是希望通過流程去減少或者避免人的因素導致忽略安全。所以權限申請要上級審批、功能開放要安全人員或者同組同事審核、功能上線要安全人員評估測試。

當然，實現(xiàn)的方式可以靈活多樣，比如默認通過，可以根據(jù)產(chǎn)品或者業(yè)務需要開啟審批、審核機制，然后把評估機制放在業(yè)務上線流程中，只有通過評估才能上線。在安全部門比較強勢或者相對重視安全的企業(yè)，相信以上機制都落實的比較到位。

安全報表

安全可視化、數(shù)據(jù)化非常重要，是體現(xiàn)安全價值的形式之一，因此通過與企業(yè)SRC或者安全部的對接，可以獲取運維相關的漏洞、安全事件統(tǒng)計數(shù)據(jù)，然后根據(jù)內(nèi)部需求進行二次處理、通過定期報表的形式發(fā)給運維人員或者部門領導甚至技術負責人查看，讓他們了解運維安全態(tài)勢。這種做法通常能讓他們看到安全不足，從而讓大家從數(shù)據(jù)得到警示，或者獲得上級關注，使得獲得更多的資源或者實現(xiàn)自上而下推動安全規(guī)范落地走向可能。

流程規(guī)范的落地包括但不限于以上幾點，但我覺得這幾點是最重要的。

2、技術體系

1）訪問控制

安全域劃分下的網(wǎng)絡隔離

• 網(wǎng)絡層：192.168分為辦公區(qū)、辦公服務區(qū)與開發(fā)機網(wǎng)，部分隔離;10.x分為IDC物理內(nèi)網(wǎng)、IDC虛擬內(nèi)網(wǎng)與公有云虛擬內(nèi)網(wǎng)，通過IGP互通，可申請端口映射外網(wǎng);公網(wǎng)IP僅用于業(yè)務外網(wǎng)，開發(fā)測試環(huán)境禁止使用公網(wǎng)環(huán)境!
• 系統(tǒng)層：裝機鏡像默認開啟防火墻，僅開放ssh、rdp管理端口。ssh一律采用公鑰登陸，禁止啟用密碼認證;按角色授權系統(tǒng)權限。
• 應用層：數(shù)據(jù)庫、緩存類應用部署在內(nèi)網(wǎng)IP，管理接口禁止對外開放，按最小權限原則授權。

統(tǒng)一出入口級訪問控制

建設IDC級別統(tǒng)一入口，結(jié)合NAT網(wǎng)關實現(xiàn)出入向訪問控制

目前BATJ都有自己的企業(yè)級GW作為統(tǒng)一應用層入口，同時使用NAT網(wǎng)關走出向流量。GW的實現(xiàn)開源方式不少，一旦作為企業(yè)級GW仍需自研。而NAT網(wǎng)關，則可采購具備API功能的分布式硬件防火墻或者自研NAT網(wǎng)關，解決IDC內(nèi)網(wǎng)出向流量RS直接回外網(wǎng)時無外網(wǎng)IP的問題，或者服務器直接對外發(fā)起請求的情況，然后再采用統(tǒng)一系統(tǒng)管理。目前業(yè)界多有分享，相關思路不難找到。

敏感端口訪問控制

一旦有了統(tǒng)一的出入口，整個生產(chǎn)網(wǎng)就像辦公網(wǎng)一樣，可以對外屏蔽敏感端口訪問，對內(nèi)限制出向流量，在風險緩解和攻擊阻斷上行之有效。

應用層訪問控制

通過WAF防刷、限流是一種通用方案，如果沒有WAF的可以應用的acl自行進行控制，比如nginx的limit_rate或者haproxy的acl。

堡壘機與VPN

• 使用堡壘機可實現(xiàn)運維入口統(tǒng)一化，也能做到集中訪問控制和審計。
• 在登陸堡壘機時也需要撥入VPN，目前應用比較廣泛的有IPSecVPN以及SSLVPN，像OpenVPN則部署維護簡單、服務端較為靈活以及客戶端支持豐富等優(yōu)勢目前被廣泛應用。
• 服務器ssh端口或者業(yè)務管理后臺也可只對堡壘機與VPN Server開放白名單

2）基線審計與入侵檢測

我認為基線審計與入侵檢測是兩個不同的概念，前者在于事后審計，看合不合格;后者在于事前預防與事中檢測響應。在具體落地上，基線審計通常依賴堡壘機，入侵檢測通常依賴安全agent。

堡壘機

通常堡壘機有訪問控制、日志審計、操作行為審計、數(shù)據(jù)上傳下載審計以及權限管理等功能。但系統(tǒng)補丁更新與應用版本更新等操作則不是堡壘機所能覆蓋的。

對于堡壘機的落地，采購設備倒是其次，重點在于整合整套運維體系，對于有些年頭的企業(yè)改造成本太大，而且大家也擔心其性能與可用性。

安全agent

當然，前面說到的系統(tǒng)補丁更新與應用版本更新，都可以交給安全agent去做。入侵檢測、基線審計，安全agent可全面覆蓋。但因為要跑agent，通常沒有愿意商用入侵檢測系統(tǒng)跑在自己機器上的，如果自研則開發(fā)周期長，還會引起業(yè)務的擔憂：服務器監(jiān)控agent、數(shù)據(jù)上傳agent等等之外還要再跑安全agent，萬一agent崩了會不會引起雪崩?說到底，要取得產(chǎn)品的信任，還得自家底子夠硬。

那么，什么樣的解決方案才能眾口皆調(diào)呢?在google提出beyondcorp之后，問題可能有了轉(zhuǎn)機，那就是把使用輕量agent采集信息，把計算、分析、決策交給大數(shù)據(jù)后臺。

當然，我們很難像google那樣基于rpc協(xié)議去做訪問控制、身份認證，那么在傳統(tǒng)的堡壘機、vpn方案之上，結(jié)合輕量級agent，可能是一種更好的方式。

不過還是上面那句話，如果自家底子夠硬，能取得大家信任，那就另當別論。

3）漏洞掃描

目前大中型企業(yè)誰沒有自己的漏洞掃描器，不會開發(fā)購買商用的總行吧?但我覺得可能有個通病，就是漏洞掃描器做的太重。如果可以解放思路，或許可以嘗試從掃描器的定位重新出發(fā)，在效率、覆蓋面上進行選擇，比如大型掃描器專門做周期長的、要求覆蓋面廣的掃描，而輕量級掃描器則定位于高效、定向掃描。

現(xiàn)在不光是waf在結(jié)合機器學習，漏洞掃描器也可以結(jié)合機器學習或者大數(shù)據(jù)分析，根據(jù)掃描日志或者已有的經(jīng)驗，做策略的自動生成，實現(xiàn)掃描規(guī)則的輕量化與精準化。

4）CI/CD安全

CI/CD是運維的重要一環(huán)。在CI/CD上出現(xiàn)的安全漏洞也多如牛毛。下面我們從如何安全的發(fā)布和應用部署來討論。

敏感信息泄露

我們都知道發(fā)布代碼應排除：源碼文件和臨時文件，如.py、.cc、*.swp(vim臨時文件)，上傳版本管理相關的信息文件(如.svn/.git)，以及打包/備份文件(如.gz/.bak)。這看起來更像是一種規(guī)范，其實不然，通過在代碼分發(fā)系統(tǒng)增加鉤子或者過濾模塊，是可以提前發(fā)現(xiàn)敏感信息的上傳的。比如代碼提交了ssh私鑰或者賬號密碼配置文件，只需要一個webhook就能檢測到。實現(xiàn)上的成本與出問題付出的代價相比，其實不算什么。

代碼或鏡像的安全審計

隨著Docker容器技術的廣泛應用，CI/CD安全的落地更加充滿希望。我們都知道，使用Docker容器需要經(jīng)歷編寫dockerfile/docker-compose文件，docker build之后才有鏡像，然后再docker pull、docker run部署服務，實際上可以結(jié)合Jenkins等CI/CD工具調(diào)CoreOS官方的Clair鏡像安全審計工具進行漏洞掃描。此外，當然還有RASP等Runtime機制的動態(tài)檢測機制，也有foritity或者Cobra等或商用或開源的代碼審計工具，也可以結(jié)合使用。

5）認證授權

認證授權機制這塊，主要分享的思路如下：

• SSH不允許用密碼登陸，必須用公鑰登陸;
• 建立個人帳號的概念，必須做到一人一個帳號，不允許多個人共用一個個人帳號;
• 公共帳號要和個人帳號分開，不允許直接登陸;
• 口令安全需要注意復雜度校驗;
• 無法通過網(wǎng)絡層或應用層進行訪問控制的，應增加認證授權機制;
• RBAC：根據(jù)角色授權;
• 最小權限原則：禁止給業(yè)務配置root/admin級別的數(shù)據(jù)庫賬號，根據(jù)業(yè)務需求授權相應權限;
• 白名單機制：同時限制root/admin級別的數(shù)據(jù)庫賬號僅能通過白名單ip訪問，如存在默認賬號密碼應同時刪除;
• 認證信息管理：說到Docker容器這塊，目前Kubernetes提供了ConfigMap，可以用于傳遞認證配置路徑或者其他間接變量，用于計算認證信息。也可以用Hashicorp Vault進行認證信息管理。

6）DDoS防御

DDoS防御按照網(wǎng)絡架構(gòu)，可分為云清洗或者IDC清洗兩種模式，前者通過DNS或者反代將目標IP替換成云的VIP的方式引流，對應的防御流程分為：流量分析→流量采集→流量壓制等幾個步驟。

后者通過路由牽引模式引流，對應的防御流程分為：流量采集→流量分析→流量牽引→流量壓制等幾個步驟。

下面從流量采集、流量分析、流量牽引和攻擊阻斷與過濾簡單介紹一下。

流量采集

云清洗

DNS：通常是Web服務，使用域名對外提供服務，只需要將dns A記錄指向高防或者清洗VIP，或者dns cname到云清洗域名即可。

反向代理：配置反代，通常用于那些拿IP直接對外提供服務的，比如游戲。

IDC清洗

流量鏡像/流量分光：這種方式要求IDC機房部署清洗或者高防集群，通過在網(wǎng)絡設備上鏡像流量或者分光拿去做異常流量檢測。

流量分析

• 數(shù)據(jù)包捕獲和抓取、數(shù)據(jù)包分析、會話還原和重組：實際生產(chǎn)環(huán)境中建議用nDPI+PF_RING實現(xiàn)，當然，Intel DPDK技術也很成熟了，后者目前也越來越流行。
• 應用層協(xié)議分析：據(jù)了解有公司使用Bro解析流量，測試結(jié)果顯示峰值幾十Gbps性能也還扛得住。當然，Bro也可以用PF_RING配合性能加速，也有插件可吐給Kafka分析。
• 通過這里的流量分析識別出異常數(shù)據(jù)流，然后觸發(fā)報警，進行下一步操作。

流量牽引

這個只針對IDC清洗有效，通常是清洗設備與IDC出口設備建立BGP協(xié)議，清洗設備向IDC出口下發(fā)牽引路由，那么，流往目標IP的所有流量都會被先送到清洗設備進行過濾。

攻擊阻斷與過濾

攻擊阻斷主要是黑洞路由，流量過濾主要使用適配清洗算法以及各種算法閾值，由此區(qū)分正常流量與異常流量，之后丟棄異常流量，回送正常流量。

7）數(shù)據(jù)安全

數(shù)據(jù)安全層面，最好是和開發(fā)、業(yè)務安全聯(lián)合規(guī)劃設計方案。通常運維安全所能覆蓋的是訪問控制、認證授權、備份、加密等。

• 訪問控制：區(qū)分數(shù)據(jù)敏感程度，實行不同程度的訪問控制。但是應當嚴格按照db放置于內(nèi)網(wǎng)的原則。
• 認證授權：基于RBAC進行授權。如果是比較成熟的db或者大數(shù)據(jù)集群，還可以使用動態(tài)計算權限、動態(tài)下發(fā)權限的方式，做到有需才授權、用完就回收。
• 備份：本地備份與遠程備份，是業(yè)務需要決定是否加密備份。

加密

傳輸：通常使用https實現(xiàn)通道安全。關于https有2個最佳事件——

• a.證書采購：開發(fā)測試環(huán)境或者非重要業(yè)務可以使用免費SSL證書Let's Encrypt，該方案支持全自動簽發(fā)、續(xù)簽，通過交叉證書實現(xiàn)了對大多數(shù)客戶端環(huán)境的兼容，此外可以使用https://www.ssllabs.com/進行站點安全掃描與兼容性測試。
• b.證書部署：針對站點接入CDN需要把證書私鑰放在CDN，或者tls握手環(huán)節(jié)消耗服務端性能可能影響業(yè)務的問題，可以使用cloudflare的keyless方案，將計算壓力轉(zhuǎn)移到專門的集群，該集群可以使用Intel QAT硬件加速，同時在協(xié)議層面做針對性優(yōu)化，從而實現(xiàn)壓力轉(zhuǎn)移與性能優(yōu)化。

存儲：這里基本上是開發(fā)層面或者業(yè)務安全層面考慮，但是如果由運維安全去做，則通常只是在文件系統(tǒng)層面進行加密而已，比如使用企業(yè)級方案ecryptfs。

脫敏：開發(fā)測試人員需要從備份數(shù)據(jù)或者日志中拉數(shù)據(jù)進行它用，此時需要注意脫敏。通常采用替換、增刪字段、去除特征以及去除關聯(lián)性等方式。

8）安全事件應急響應

下面是一個通用的安全事件應急響應流程，很顯然運維人員、安全人員需要配合很多工作，其中需要注意的有：

• 保護現(xiàn)場，備份數(shù)據(jù);
• 聯(lián)系產(chǎn)品評估影響范圍;
• 確認能否先封iptables限制外網(wǎng)訪問;
• 確認被黑機器接入基線審計與入侵檢測情況;
• 確認是否有數(shù)據(jù)泄露、機器被root，加了異常用戶、異常進程、crontab，開放異常端口;
• 確認被黑機器是否有內(nèi)網(wǎng)ip，查看監(jiān)控核實是否被作為跳板機;
• 創(chuàng)建運維工單，跟蹤和復盤漏洞發(fā)生與處理情況。

3、外部合作

運維安全，首先是運維。日常工作中與IT、安全和網(wǎng)絡部門關系都十分密切，保持與兄弟部門的良好溝通和信息共享非常重要。下面我們探討一下與他們合作的可能性。

1）與IT部門

主要是辦公網(wǎng)安全，尤其是NAC：網(wǎng)絡接入系統(tǒng)，通常是IT維護，但由于歷史原因或者技術支持的需求，NAC可能需要運維安全人員提供技術支持，比如前面提到的VPN服務。

2）與安全部門

運維安全屬于安全的一個分支，不在安全部門管理之下，但其與安全部門的聯(lián)系極其密切，可以說無論是業(yè)務安全，還是運維安全，都是“站在巨人之上”。

• 安全部門提供基礎設施如DDoS防御系統(tǒng)和對外統(tǒng)一接口如SRC等;
• 安全部門提供SDL支持，運維與產(chǎn)品部門的聯(lián)系較安全部門更為密切，很多時候需求先到運維，才到安全，所以通過運維安全一起推動安全培訓、安全架構(gòu)設計與落地、滲透測試等工作也不少見;
• 相對應的，運維安全也能根據(jù)運維部門和產(chǎn)品具體情況實現(xiàn)精細化的漏洞運營，同時推動漏洞高效修復。

3）與網(wǎng)絡部門

很多企業(yè)的運維和網(wǎng)絡很長一段時間都是放在同一個部門之下，即便拆分出來之后，兩者合作也是最多。對于運維安全而言，在訪問控制和DDoS防御上非常需要網(wǎng)絡部門支持。

• 訪問控制

如網(wǎng)絡隔離和統(tǒng)一出入口訪問控制的落地。

• DDoS防御

網(wǎng)絡打通、流量采集與包括ip資產(chǎn)信息在內(nèi)的數(shù)據(jù)共享。

我們從運維安全的概念入手，強調(diào)了運維安全困境導致了我們的重視，也從安全意識和基礎架構(gòu)建設上剖析了導致該困境的原因，然后就事論事，希望通過運維安全意識培養(yǎng)、運維安全規(guī)范以及運維安全技術體系的建設，來保障一套完整的運維安全體系的有效運轉(zhuǎn)，為業(yè)務發(fā)展保駕護航。

本文源于一次內(nèi)部培訓，從構(gòu)思到成文，前后花了幾周的時間，中間斷斷續(xù)續(xù)，勉強成文。囿于筆者的認知能力和技術沉淀，以及文章篇幅限制，可能很多地方說得不夠清楚或者存在錯漏。再次拋磚引玉，希望得到大家的更多指點。同時，也希望借此文刷新大家對運維安全的認識：運維安全，沒那么簡單。

作者介紹

林偉壕，SecDevOpsor，先后在中國電信和網(wǎng)易游戲從事數(shù)據(jù)網(wǎng)絡、網(wǎng)絡安全和游戲運維工作。對Linux運維、虛擬化和網(wǎng)絡安全防護等研究頗多，目前專注于網(wǎng)絡安全自動化檢測、防御系統(tǒng)構(gòu)建。