堡壘機是幹什麼的

既然問到堡壘機，我仍是有必要回答一下的，這是由於堡壘機確實給個人運維工做履歷帶來了實際幫助，若是沒有堡壘機我可能已經考慮轉行了。我就從個人經歷提及吧，說來話長，你們慢慢看。

從事運維三年了，本身也曾遇到過各式各樣的問題，諸如因認證方式過於簡單形成服務器帳號被盜、權限劃分不明形成的誤刪數據庫文件等問題家常便飯，果不其然的印證了「70%的故障均來自內部人員的操做失誤」的魔咒。

很顯然，問題出在平常運維工做不規範，若是不規範工做中的一舉一動，就會不斷的犯錯，最後致使全部的功勞都變成徒勞。

俗話說的好：常在河邊走， 哪能不溼鞋。身邊例子不少，隨便舉一個朋友在羣裏的對話。

若一不當心執行命令 rm -rf / tmp，若是此時正好擁有root權限，那麼後果將不堪設想。

關於rm -rf / tmp 這種錯誤，對於手快的朋友或者在咱們網速比較慢時，出現的機率至關大，當你發現執行完以後，你的心至少是涼了半截。可能你們對本身擁有至關大的自信，老子每次都這樣沒出過錯，唬誰呢。

當出現一次你就明白了，不要認爲那些運維事故都是在別人身上，若是你不注意，下一個就是你。

衆多運維工做的失誤，時刻提醒咱們運維人員要創建明確、規範的標準化管理流程，以提升運維效率、下降綜合成本，保障業務的連續性。

在這裏跟你們分享幾個關於rm防止誤刪除數據的小技巧：

一、先備份，再操做，最好有異機備份，修改配置等先提交版本管理系統再發布到線上；

二、刪除文件時使用mv命令替代rm命令，無用的文件先不刪除，而是移動到/tmp裏觀察些許時間；

mv filename.txt /tmp/

三、若是非要使用rm刪除，請儘可能先使用Tab補全目錄，再切換目錄再刪目錄下的數據，能不用通配符就不用通配符。

cd /tmp
rm -f filename_1.txt filename_2.txt

四、若是刪除的不是目錄，就不要使用「rm -fr」，應採用最小化權限「rm -f」來進行對文件的刪除。

至此以後，運維失誤確實減小了，可是好景不長，時隔倆月問題又再次重演，而咱們還不知道是誰操做的（當時我立刻查看了系統日誌，但苦於系統日誌可讀性差、零散、可刪除、篡改、而且咱們帳號與運維人員沒法一一對應）！！！

CTO完全爆發，此次必須從源頭完全根除這個問題，不然你就給我滾蛋。此時的我，很是理解CTO的心情，因而當面立下軍令狀，杜絕此類事故的再次發生。

目前咱們的主機資源規模大概在數百臺左右，上面跑着許多不一樣的業務系統，對於這些資源來講，都有各自獨立的一套帳號體系，當時爲了方便管理，咱們是經過一個Excel來維護這些帳號信息，使用時，也就存在了多人共用帳號的狀況。

多人共用帳號給咱們帶來方便的同時，帳號自己的安全性也就沒法獲得保證，致使操做者的身份沒法肯定，當系統發生問題後，很難確認具體責任人。

爲了保證密碼的安全性，咱們也會制定嚴格的密碼管理策略，諸如密碼必須按期修改，密碼需保證足夠的強度等，但現實執行中，因爲管理的資源規模太大和帳號數量太多，這一費時費力的操做，每每最終都流於形式，由此引出咱們的第一個問題：帳號密碼管理體系不規範。

在訪問控制這塊，咱們對運維人員數據信息的訪問能力和範圍並無作嚴格的控制與限制，致使運維操做流程就像一個「黑盒」，咱們並不清楚運維人員：

• 在哪臺設備上執行操做？
• 操做是哪一位來執行？
• 正在進行哪些操做？
• 執行的操做是否合規？

由此，帶來的後果除了本次失誤操做致使關鍵應用服務異常、宕機以外，存在違規操做致使敏感信息泄露、丟失的狀況也曾發生過。

那麼咱們要解決的第二個問題：訪問控制不嚴格。

該如何解決？維持現有的運維流程確定是不行，經過制度來約束運維人員實現安全合規的操做未免顯得有些力不從心。

那麼只能依靠經過其餘手段來避免上述問題的發生，對於從事運維的朋友大概都清楚只要用堡壘機就能解決咱們如今全部面臨的問題，由於堡壘機的做用就是讓遠程運維操做管理可以實現按用戶/資源進行受權管理，除此以外經過事前訪問控制、事中錄像監控、過後指令審計，以保證企業數據的安全以及運維操做的安全合規。

咱們也調研了目前主流的堡壘機解決方案，這裏我主要根據本身的經驗，從幾個要點進行分析和比較，分享給你們參考，至於如何選擇，你們可根據自身的業務環境進行適配。

• 主流堡壘機解決方案
  • 內部自研
  • 開源堡壘機
  • 商業堡壘機

一開始咱們是想經過內部自研的方式進行堡壘機的開發，對於堡壘機來講，它是由多種技術協調整合造成的。簡單來講至關於運維人員的一臺代理服務器（Proxy Server），若是從主幹技術原理的角度概述的話，堡壘機所應用的主要技術包括但不限於：邏輯命令自動識別技術、分佈式架構處理技術、圖形協議代理技術、多進程/線程與同步技術、數據加密技術等。能夠說，堡壘機技術是一個看似簡單，其實複雜而精細的分佈式系統集羣。

考慮到內部研發堡壘機在性能和穩定性上必定會有所欠缺，出問題後，運維人員不能登陸，影響不少團隊幹活，尤爲在處理業務故障的時候，若是忽然發現某臺服務器進不去，這就尷尬了，嚴重影響周圍團隊對咱們運維團隊的滿意度。

運維自己是個服務性質的工做，儘可能不要搞得周圍部門不滿意纔好。

考慮再三決定調研測試開源堡壘機，目前的開源堡壘機方案有不少，目前作的較好的諸若有CrazyEye、Teleport、Jumpserver、GateOne、麒麟開源堡壘機等。

當咱們公司選擇了使用開源堡壘機時，便擁有初始投入少、使用靈活等特色。不過在後來咱們的管理成本、學習曲線和安全性方面卻很可貴到，可能咱們一開始未曾考慮開源堡壘機也需專人進行維護，並且大多開源堡壘機的功能相對簡單，只可以知足咱們最最基本的安全需求。若是想更進一步的發揮堡壘機真正的價值或者說是有用的堡壘機，那麼根據公司業務進而定製開發就是必經之路。

而對開源堡壘機的定製開發，又讓咱們回到了內部自研的老路，開發堡壘機這我的必須很是熟悉Linux以及公司業務，並且還要會玩Python（大多與運維相關的應用使用Python開發的較多，具有這樣能力的人薪資每每不低），除此以外也能夠選擇開源堡壘機的商業支持服務，不過需支付高昂的技術支持服務費用，這自己就是一個運維成本。從這個角度講，開源堡壘機並不等同於免費堡壘機，後期成本可能遠遠高於商用堡壘機，對開源堡壘機廠商尚未任何責任約束。

行吧，是時候調研商業堡壘機了，咱們經過調研得知商業堡壘機目前可細分爲：傳統堡壘機和雲堡壘機。

以傳統堡壘機廠商爲表明的供應商諸如：齊治、綠盟、碉堡、安暢等。

以雲堡壘機廠商爲表明的供應商諸如：行雲管家、雲安寶等。

對於傳統堡壘機多爲軟硬件結合且價格昂貴，其管控能力十分強大，是銀行、國營大型企業IT運維團隊的首要選項。

但傳統堡壘機的缺點是，價格很高動輒數十上百萬（容易出現單點故障，因此一次要買倆進行高可用），因此部署起來相對來講比較困難，須要專業的團隊統籌部署，維護成本高。同時對現有網絡結構侵入大，軟件和硬件升級都不方便，並不怎麼適合中小型企業、通常創業企業。

對於雲堡壘機的調研來講，瞭解到雲堡壘機在功能上已很是成熟，同時藉助了雲計算的優點，使得雲堡壘機在資源的交互性、易用性、性價比、維護成本、產品自身安全性等方面又獲得了進一步提高，尤爲解決了傳統堡壘機的單點故障問題。

除此以外，雲堡壘機還有許多特性，諸如免安裝、免維護、開箱即用，支持Windows\Linux等主機運維審計、指令檢索、監控預警、自動化運維等。

這裏你們須要注意的是，堡壘機對於自動化運維的影響甚大，由於咱們使用了堡壘機實現了雲環境下的統一運維管理，成爲全部運維的惟一入口。那麼堡壘機既會成爲自動化運維的羈絆，那麼可就得不償失了，因此咱們選擇使用堡壘機時，也需對配套功能進行考慮（是否具有其它運維相關功能，好比主機監控、遠程協同、自動化運維等）；

從身邊已在使用堡壘機的朋友得知，他們的採購同事購買傳統堡壘機的流程通常爲：

一、須要乙方銷售人員屢次上門介紹產品；

二、簽定合約；

三、須要運輸、安裝、調試、配置……

整個流程通常長達數月。

但在雲上，雲堡壘機的交付則更爲簡單，對於雲堡壘機廠商，雲安寶提供了私有部署版本，而行雲管家不只提供了私有部署版本，同時還擁有SaaS平臺，SaaS的優點在於咱們無需在硬件和IT人員方面再進行任何額外的投資，便可得到堡壘機服務，這種區別就如同拎包租住一間精裝房和聘請施工隊 爲本身修建一套住房的區別。廢話少說，接下來就是對兩家產品進行細粒度的測試。

雲匣子：雲匣子總的來講與開源的JumpServer相差很少。

行雲管家堡壘機在線體驗-https://www.cloudbility.com/cj/baolei.html：前面提到，行雲管家擁有SaaS平臺，只須要經過瀏覽器便可體驗，咱們經過Google搜索行雲管家堡壘機，獲得了在線體驗的環境，經過註冊、建立團隊、導入資源三個步驟，咱們即可以經過行雲管家來管理主機資源。

經過一番體驗以後，無論是在UI、產品功能、產品體驗方面都很滿意，在咱們長時間的測試過程當中，工做人員始終保持與咱們進行良好溝通和解決產品問題，最終他們用堅持不懈贏得咱們領導的承認也促成訂單落地。

從上線到目前一個季度，我對CTO的承諾也得以兌現，未雨綢繆永遠比出了問題在處理要好的多，出了問題補救是不得已的事，但仍是有許多公司，沒有亡羊補牢，而是好了傷疤忘了疼，沒過多久問題又重演。

所以，在工做中要儘可能作到未雨綢繆，從源頭上減小故障的發生。其次，要作到亡羊補牢、觸類旁通，事情出現一次就不能再出現第二次。固然，完善的備份和恢復策略也是須要作的。只有把這些結合起來，才能把咱們運維的工做作的更好。

最後總結一下，對於選購堡壘機並不是越貴的就越好，而是要綜合考量各項指標與運維團隊自己的契合度，以及在實際應用中的真實需求。若是咱們所在的團隊是金融、政府等對安全性要求極高的組織，建議考慮傳統堡壘機。可是對於一些互聯網企業、創業企業而言，我比較傾向於向你們推薦使用雲堡壘機，不管是從價格仍是靈活性來講他都具有優點。何況隨着雲計算市場的發展，上雲成爲主流，將來的堡壘機發展趨勢也必然是偏向於雲堡壘機。