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

[[243739]]

一、培養良好的運維安全習慣

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

端口開放

• 默認監聽內網或者本地;
• 如需監聽全部外網，iptables、password和acl能加都加上。

iptables

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

權限管理

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

腳本安全

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

密鑰管理

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

服務管理

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

代碼管理

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

應用選型

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

關注應用安全配置文檔

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

二、企業級運維安全體系

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

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

1、流程規范

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

培訓

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

審批+審核+評估

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

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

安全報表

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

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

2、技術體系

1）訪問控制

安全域劃分下的網絡隔離

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

統一出入口級訪問控制

建設IDC級別統一入口，結合NAT網關實現出入向訪問控制

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

敏感端口訪問控制

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

應用層訪問控制

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

堡壘機與VPN

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

2）基線審計與入侵檢測

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

堡壘機

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

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

安全agent

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

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

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

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

3）漏洞掃描

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

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

4）CI/CD安全

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

敏感信息泄露

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

代碼或鏡像的安全審計

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

5）認證授權

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

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

6）DDoS防御

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

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

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

流量采集

云清洗

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

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

IDC清洗

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

流量分析

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

流量牽引

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

攻擊阻斷與過濾

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

7）數據安全

數據安全層面，最好是和開發、業務安全聯合規劃設計方案。通常運維安全所能覆蓋的是訪問控制、認證授權、備份、加密等。

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

加密

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

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

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

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

8）安全事件應急響應

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

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

3、外部合作

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

1）與IT部門

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

2）與安全部門

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

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

3）與網絡部門

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

• 訪問控制

如網絡隔離和統一出入口訪問控制的落地。

• DDoS防御

網絡打通、流量采集與包括ip資產信息在內的數據共享。

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

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

作者介紹

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