隨著互聯網技術的不斷發展，在線網站的規模越來越大，防火墻作為網站的安全屏障，被大量的使用。防火墻數量的增加以及防火墻中安全策略條目的增加，安全工程師的運維工作量成倍的增長，應用交付往往要求防火墻策略能快速設置。用傳統的人工方式運維大量的防火墻策略已經變得非常困難。
本文會介紹攜程網絡安全運維如何通過自動化方式，在防火墻數量達到幾十臺，策略條目龐大、多品牌的情況下，對防火墻策略進行集中式統一化的管理，提升用戶查詢、申請策略體驗，優化申批流程，系統自動化配置防火墻策略，提升安全工程師效率的同時降低人工出錯概率。
防火墻運維之痛
防火墻運維之痛，這種叫法有點落俗套，可事實上運維的確是痛的，我們經常在很多場合以及在PPT的開篇，會看到這樣的說法，比如IT運維之痛，機房管理之痛，網絡管理之痛，所以痛在運維這個行業是一個正常的存在，我們都知道，運維通常要經歷人工階段到自動化階段，再到智能階段這三個過程。當人工階段處理的事務遇到嚴重挑戰，就會痛苦，不痛苦就沒有改變。所以痛也不見得是壞事。
我們在建設基礎的安全架構的時候，通常有兩種選擇，一種是單一品牌的防火墻，或者選擇多品牌的防火墻的架構。攜程由于一些歷史的原因，我們在現網使用的就有5個品牌。據相關調查數據顯示，企業網使用多品牌防火墻是一種普遍情況。比如銀行業有防火墻異構的合規要求，一些金融企業也會參照這個標準。不同品牌的防火墻提供不同的功能特性。比如在OA出口，你想看到并攔截應用層的安全威脅。就會選擇NGFW，數據中心可能會選大吞吐量的墻來滿足數據轉發的需求。不同時期、商務因素等這樣一些原因，導致我們使用了不同品牌的防火墻來滿足安全隔離的要求。
這張拓撲圖展示的一些較大規模互聯網公司或企業典型的防火墻部署示意圖，體現了邊界防護、重要業務系統隔離保護、辦公與生產隔離的一些保護需求。據我了解使用幾臺到幾十臺的企業有很多，也有一些大型集團公司或跨國公司使用數百臺防火墻。面對這么多防火墻，要把它管理好，難度是很大的。有些廠商就說了，你可以使用我們的防火墻集中管理系統幫助降低運維復雜度，當告訴他我們有好幾個品牌的墻，對不起，他的系統管不了。只能管自家的墻。有商用產品可以實現不同品牌防火墻策略集中管理，但是按license 算錢，價格昂貴，而且不靈活，不能實現個性化的需求。在這種多品牌，多數量的情況下，防火墻系統的運維難度和挑戰將變得非常的大。
現在看看運維層面實際遇到的問題，用戶經常會提出這樣的問題，我訪問某個資源不通，是不是被墻攔截了？訪問lab 環境有沒有墻呀？測試訪問生產是違規的，需要特別審批，找誰去審批呢？而防火墻安全工程師呢要一遍遍解答用戶的疑問，不斷與用戶溝通。同時要人工審核策略需求，編寫防火墻配置工藝，在變更窗口登錄到防火墻設備下發配置，不斷重復這個過程。我們都知道，現有安全工程師很難招，而且都很貴，招來做大量重復性工作，對安全工程師本身的成長是不利的。還有一個顯著的缺點就是人工處理的速度慢。互聯網企業業務需求變化快就要求防火墻策略能夠隨需而變快速部署。在這種情況下，低效的工作已經不能滿足實際的業務要求，因此我們提出自己的運維目標：透明、規范、自動化、高效。
防火墻運維管理系統
為了實現透明、規范、自動化、高效的防火墻運維目標，我們設計了這樣一個架構，最底層是每臺防火墻設備，通過API接口與系統連接，配置備份系統，每小時對全網防火墻自動進行一次配置備份，當然可以針對不同實時性要求級別來調整備份間隔。比如AD會新增入職員工域帳號，也會按需新建一些郵件組，這些信息多久同步到防火墻上呢，看需求。路由解析和和配置解析兩個模塊處理配置文件，并將元數據（5元組+路由表）存入統一模型數據庫。
最核心的基礎工作就完成了，在此之上設計一些功能模塊，路徑查詢解決拓撲計算問題，策略查詢允許用戶自助查詢兩點間防火墻策略，策略合并和生成模塊是自動生成策略配置工藝。策略自動下發實現工藝下發設備，再上一層是API，這些功能模塊都是通過API方式調用 的，最外層是統一web portal 入口，提供給用戶查詢或申請防火墻策略，跟蹤進度等。還有一些小工具我們也集成進入管理系統，比如設備密碼修改、VPN管理。最右上角，可以通過系統API與其他系統共享數據。
這張圖展示的是，我們自主開發的防火墻運維管理系統的組成，簡單來說它有三個模塊，拓撲計算、策略查詢和策略生成三個模塊，工單對接指的是一套流程，其他的模塊其實指的是一些有用的工具。
那我簡要的說一下這些模塊實現的功能，拓撲計算做什么事情？通過路由計算的方法形成一個拓撲，這個拓撲指的是，訪問的兩點之間跨越了哪些墻，然后策略查詢它做兩件事情，第一件事情就說提供給用戶可以自主的去查詢策略。第二件事情，用戶在申請策略的時候，我們后臺會幫他自動做一個查詢動作，看是不是已經有策略了，如果有策略會返回一個消息告訴說，有策略了，你不需要申請，直接去測試就可以了，這樣可以節省大家的時間，策略生成這個模塊，它是針對不同品牌的墻去編寫防火墻的配置工藝，比如說我們都知道思科、PaloAlto、Fortigate這些品牌的墻，每個策略工藝都不一樣，我們需要去解決這些問題。
工單對接，這塊強調的是流程的，解決三個問題。第一個是我們與現有的企業網內的變更管理系統，或者是工單系統對接，第二要解決的問題是，我們設計一個用戶從提出申請到自動化完成一個策略配置，再告訴用戶需求完成一個完整的一條龍服務。第三個就是一些特殊權限的審批，如果遇到特殊權限，原來都是發郵件審批，非常低效，現在我們通過一個特殊審批的模塊解決這個問題，我們設計了規則，比如說要訪問數據庫的防火墻權限，要找誰審批。如果要測試環境訪問生產環境的違規訪問，要做特例審批，我們都定好規則。當用戶的輸入條件匹配了這些規則會自動發郵件給審批人，通過URL鏈接進行審批，然后就會往下面的流程去走。
其他的一些功能模塊，比如說有改密碼的模塊，有VPN隧道管理模塊，還有一些防火墻元素查詢的模塊，我們要維護數百條的VPN隧道，如果人工的方式一條一條去添加效率非常的低，防火墻運維系統開放接口，允許我們通過導入Excel表格的方式，一次可以添加一批隧道效率大幅提升。
核心模塊實現原理
接下來會詳細介紹一下幾個核心模塊的實現原理。拓撲計算要解決的問題是知道兩點之間的訪問經過哪幾臺墻？通常的做法是這樣的，安全工程師根據經驗模糊判斷兩點之間的訪問經過哪幾臺防火墻，再加人工查詢、驗證，有時拿不準需要看防火墻Log，看是不是有deny日志，。存在的問題就是在防火墻數量較多的情況下，安全工程師往往難以判斷兩個IP是否經過墻或經過哪幾臺墻，費時費力，效率低下，判斷可能產生差錯。
自動化拓撲計算方法，來解決，確定源訪問到目標經過哪幾臺防火墻的問題。首先在防火墻進行路由匹配 （最長路由匹配，掩碼中的1最多）也叫精確匹配，如果匹配到轉到下個過程，否則繼續查詢其他防火墻。B.接口比較，這個過程是判斷出路由經過防火墻的接口或zone.如果判斷源、目的接口或zone 相同，就需要把該防火墻從拓撲中刪除。實際上就是不經過這臺墻。匹配到將相應的防火墻添加到拓撲中。C.過程，如果所有防火墻都被遍歷，則可以輸入防火墻拓撲。否則轉到A 進行下次循環。
策略查詢普遍做法仍是基于經驗判斷，經驗豐富的工程師可以快速定位到墻和策略，不熟悉的操作人員可能要逐臺查詢多臺防火墻才能找到對應的策略，安全策略在不斷的增，當策略數目多到幾千條時，查詢工作將變得困難，在跨多IDC，跨多墻的環境下，比較難搞不清楚用戶提出的策略申請到底有沒有策略支持。帶來的缺點就是工作效率低下，可能漏查。
自動化策略查詢的實現，查詢的輸入條件包括源、目標、目標端口，協議4個元素，通過拓撲計算已經知道目標落在哪臺墻上，因此查找目的的動作直接在目標墻上進行，范圍縮小，查詢速度很快。在程序處理上是按這個邏輯處理的。首先匹配目標，找到目標接著匹配目標協議和端口，也找到了，再匹配源，如果源也找到了。則記錄查詢結果，注意此時還沒有結束，還需要繼續在剩余的策略中查詢，所有策略都匹配完，統一輸出結果。通過這樣幾個步驟，根據用戶的查詢條件，就能秒級返回結果，是有策略放行還是該訪問被防火墻攔截，一目了然。
防火墻配置工藝編寫的傳統做法，根據不同品牌，有些墻只能圖形界面配置，有些墻可以圖形可以命令行，安全工程師會針對不同品牌墻，根據自己熟悉的方式編寫配置工藝，在變更窗口登錄防火墻完成配置，從變更申請到工藝編寫再到登錄設備配置，整個過程平均耗時在30分鐘以上。人工處理的方式缺點也很明顯，人工操作時間加上變更窗口時間限制，用戶的等待時間有數小時之久，用戶滿意度差。人工操作還有一個不好的地方，會發生人為差錯的可能性。
自動化生成策略工藝并下發設備的實現。第一個過程首先是判斷拓撲中涉及的防火墻，對它的策略操作是不添加、新建還是修改。然后會有2種情況，如果策略生成動作為新建策略，則按需生成新建策略的工藝，生成的方法是按防火墻的API格式或是CLI命令行格式生成。第二種情況，如果判斷策略生成動作是修改策略，那么在生成策略工藝時，就需要處理對原策略的修改，可能需要調整策略順序等操作。完成策略工藝生成過程，這里會對工藝做人工審核，后面后進到。到達變更窗口時間，自動把配置下發到防火墻設備。完成策略變更。
流程優化
之前的內容解決了技術層面的問題，接下來看看流程方面的優化。
對于用戶來說，我們提供統一的申請portal，用戶申請策略需求，后臺自動判斷，如果有策略，返回消息，用戶自行測試通過就結束了。如果后臺判斷沒有策略支持，生成策略清單，可能是1條或多條策略需求，如果是常規申請，會直接提交成功，如果提供的策略需要特別審批，比如申請測試環境訪問生產，一定是特例申批。
我們有一個審批管理模塊解決這個問題，程序判斷如果提出的策略屬于特殊申請的，會自動給審批人發郵件說明申請理由，審批人點開鏈接點通過或拒絕進行審批，通過后完成申請提交。在安全工程師這條線上，申請提交后會進入自動化的防火墻管理系統開始自動生成工藝，安全工程師人工審核工藝，必須要安全工程師人工審核。
上生產前二次檢查，就是為了避免由于系統設計可能存在的疏漏，生成與預期不一致的變更工藝，帶來對生產業務的影響，我們要防止這種錯誤的產生。增加人工把關環節。審核通過后等待變更窗口，到達變更窗口時間，自動執行變更。也是自動下發策略的過程。完成一次策略申請到人工審核再到自動下發設備的整個過程。通過自動化策略配置的實現，策略維護花費的時間大大減少，現在做一個變更，平均花費3分鐘左右，比原來30多分鐘有10倍的提升。
對接工單系統，自動化對接工單或變更系統，雖然自動化與流程之間有很多的沖突，因為自動化追求的是速度，效率，而流程希望你慢下來。要求把事情做正確。
前幾天參加另一個安全的會議，遇到一些與會嘉賓舊事重提，也剛好是攜程528事件過去1周年不久。就問我到底是什么原因導致網站癱瘓12小時。對于這次事件，網上各種猜測，各種版本，有數據刪除說、有員工報復說、有網站被黑說。
在這里說明一下，真正的原因就是由于員工錯誤操作，誤刪除了生產服務器上的執行代碼導致。雖然流程不能完全規避掉像528這樣的事故，但是它會幫助我們降低發生事故的概率。因此在攜程的最佳實踐就是自動化系統與變更工單系統對接。打通，使二者結合作用。在流程框架的規定下進行自動化。
具體是這樣一個過程，策略申請，策略配置請求單生成進程會創建請求單，并返回單號，第一個步驟是等待審批，這個角色通過是安全工程師的leader， 授權該申請。到變更窗口時間，程序修改狀態為“處理中”，此時工單進行會創建一個變更單，前面的是請求單，二者有區別，不要混淆。生成好變更單后是等執行狀態，會自動發消息給NOC，說某某同事因什么需求，需要在某某設備上執行策略變更。NOC接受工單后，狀態修改為已接受、并且獲取請求單對應的變更單。當程序將變更單狀態修改為執行中時，程序同步自動化登錄到相應的防火墻設備執行策略下發操作。然后程序將請求單和變更單狀態分先后置為已完成。整個流程部分就完成了。
簡單總結一下分享的內容，三個核心模塊，拓撲計算，策略查詢和策略工藝生成，一套流程，解決用戶一條龍的服務，以及與我們的變更管理和配置管理系統的工單對接，一些工具用來提升我們的效率，它們共同構成了我們的防火墻自動化運維系統，通過這套系統的自動化方式，幫助我們輕松運維幾十臺防火墻，在不斷提高工作效益的同時，也降低了人工出現差錯的一些概率。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.vmgcyvh.cn/
本文標題：攜程網絡防火墻自動化運維
相關文章
