拿來即用的企業級安全運維體系搭建指南

摘要： 在上篇《99%的人會中招的運維安全陋習，請規避！》中，我們花了很大的篇幅去剖析運維安全的問題所在，本文我們將針對如何解決問題來進行詳細說明， 從問題入手，通過糾正或者培養良好的運維安全習慣，搭建完整的運維安全技術體系 。 一、培養良好的運維安全習慣 想要解決運維安全的問...

在上篇 ofollow,noindex"> 《99%的人會中招的運維安全陋習，請規避！》 中，我們花了很大的篇幅去剖析運維安全的問題所在，本文我們將針對如何解決問題來進行詳細說明， 從問題入手，通過糾正或者培養良好的運維安全習慣，搭建完整的運維安全技術體系 。

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

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

埠開放

• 預設監聽內網或者本地；

• 如需監聽全部外網，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、技術體系

訪問控制

安全域劃分下的網路隔離

• 網路層： 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開放白名單

基線審計與入侵檢測

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

堡壘機

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

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

安全agent

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

那麼，什麼樣的解決方案才能眾口皆調呢？在google提出beyondcorp之後，問題可能有了轉機，那就是把使用輕量agent採集資訊，把計算、分析、決策交給大資料後臺。

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

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

漏洞掃描

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

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

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等或商用或開源的程式碼審計工具，也可以結合使用。

認證授權

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

• SSH不允許用密碼登陸，必須用公鑰登陸；

• 建立個人帳號的概念，必須做到一人一個帳號，不允許多個人共用一個個人帳號；

• 公共帳號要和個人帳號分開，不允許直接登陸；

• 口令安全需要注意複雜度校驗；

• 無法通過網路層或應用層進行訪問控制的，應增加認證授權機制；

• RBAC：根據角色授權；

• 最小許可權原則：禁止給業務配置root/admin級別的資料庫賬號，根據業務需求授權相應許可權；

• 白名單機制：同時限制root/admin級別的資料庫賬號僅能通過白名單ip訪問，如存在預設賬號密碼應同時刪除；

• 認證資訊管理：說到Docker容器這塊，目前Kubernetes提供了ConfigMap，可以用於傳遞認證配置路徑或者其他間接變數，用於計算認證資訊。也可以用Hashicorp Vault進行認證資訊管理。

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的所有流量都會被先送到清洗裝置進行過濾。

攻擊阻斷與過濾

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

資料安全

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

• 訪問控 制 ： 區分資料敏感程度，實行不同程度的訪問控制。但是應當嚴格按照db放置於內網的原則。

• 認證授權： 基於RBAC進行授權。如果是比較成熟的db或者大資料叢集，還可以使用動態計算許可權、動態下發許可權的方式，做到有需才授權、用完就回收。

• 備份： 本地備份與遠端備份，是業務需要決定是否加密備份。

• 加密

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

  a.證書採購：開發測試環境或者非重要業務可以使用免費SSL證書Let's Encrypt，該方案支援全自動簽發、續簽，通過交叉證書實現了對大多數客戶端環境的相容，此外可以使用https://www.ssllabs.com/進行站點安全掃描與相容性測試。

  b.證書部署：針對站點接入CDN需要把證書私鑰放在CDN，或者tls握手環節消耗服務端效能可能影響業務的問題，可以使用cloudflare的keyless方案，將計算壓力轉移到專門的叢集，該叢集可以使用Intel QAT硬體加速，同時在協議層面做針對性優化，從而實現壓力轉移與效能優化。

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

• 脫敏： 開發測試人員需要從備份資料或者日誌中拉資料進行它用，此時需要注意脫敏。通常採用替換、增刪欄位、去除特徵以及去除關聯性等方式。

安全事件應急響應

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

• 保護現場，備份資料；

• 聯絡產品評估影響範圍；

• 確認能否先封iptables限制外網訪問；

• 確認被黑機器接入基線審計與入侵檢測情況；

• 確認是否有資料洩露、機器被root，加了異常使用者、異常程序、crontab，開放異常埠；

• 確認被黑機器是否有內網ip，檢視監控核實是否被作為跳板機；

• 建立運維工單，跟蹤和覆盤漏洞發生與處理情況。

3、外部合作

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

與IT部門

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

與安全部門

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

• 安全部門提供基礎設施如DDoS防禦系統和對外統一介面如SRC等；

• 安全部門提供SDL支援，運維與產品部門的聯絡較安全部門更為密切，很多時候需求先到運維，才到安全，所以通過運維安全一起推動安全培訓、安全架構設計與落地、滲透測試等工作也不少見；

• 相對應的，運維安全也能根據運維部門和產品具體情況實現精細化的漏洞運營，同時推動漏洞高效修復。

與網路部門

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

• 訪問控制

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

• DDoS防禦

  網路打通、流量採集與包括ip資產資訊在內的資料共享。

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

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