如何應對堡壘機安全風險

堡壘機作為服務器和網絡安全控制的系統，包含了用戶管理、資源管理、策略、審核等功能，為企業安全提供了有力保障。但越是復雜的系統，可能遭遇的漏洞與威脅也越大，因此，堡壘機安全的重要性自然不言而喻。本期話題，我們就聚焦于堡壘機本身，看看大家在遇到有關安全風險時如何“排憂解難”。

單點故障和繞過訪問是堡壘機比較容易遇到的安全風險，對此大家的解決辦法是什么？除此以外還遇到過哪些其他安全威脅？都是如何解決的？

A1：單點故障（可用性）的話通過HA或集群部署，然后異地多站點的方式應對；繞過訪問涉及到安全有效性的問題，有兩種發現渠道，一是需要對網絡安全策略進行一些監測與驗證，通過部署在不同網段的節點做一些連通性測試，二是通過操作機器上的軟審計功能，結合風險規則進行發現。還遇到過Log4j漏洞，通過升級版本打補丁解決。

A2:堡壘機支持雙機雙活，最好選擇密碼備份有逃生機制的方案，比如密碼保險箱，防止繞過訪問，必須網絡明確管理來源的一致性。作為資產的集中管理和權限管理審計工具，首當其沖應對各種攻擊，選擇成熟服務商和產品很關鍵。

A3：堡壘機賬號管理混亂，密碼長期不換，這是個風險，還是得定期換密碼。

A4：有很多堡壘機綁定域，拿下域=拿下堡壘機。

A5：單點故障是可用性的問題，架構層面HA或者集群都是可行性方案，通過部署不同物理機器或者分散機房的方式，也是解耦的一種實現；繞過訪問，不同網段的問題基本可以通過網絡ACL解決，同網段的訪問容易繞過堡壘機，可以通過收集登錄日志分析SIP是否是堡壘機白名單解決。感覺HIDS也可以解決這個問題。其他的風險諸如0Day、賬號共享、高危命令操作等。賬號共享問題，主要通過提升共享的難度和成本來規避。前端通過MFA等方式，后端可通過定期改密等方式。高危命令操作問題，事前將命令收斂，事中增加審批節點復核的方式。

A6：繞過這個風險，如果說的是不通過堡壘機訪問目標服務器這種情況，我們是通過在接入交換機實施網絡策略做限制的，僅允許堡壘機可訪問SSH端口。

Q：攻防演練期間遇到堡壘機 0Day爆出，大家是如何進行處置的？

A1:不管什么時期，遇到0Day，首先確認堡壘機不對互聯網開放，在攻擊路徑上設置多卡點管控，第一時間檢查產品服務授權是否在維保期內，然后要求供應商盡快修復。

A2：堡壘機+零信任組合使用。

A3：初期主要是限制訪問，嚴格訪問策略，把訪問頻度低的需求暫時砍掉，訪問頻度高的流量丟到威脅感知里去。中后期廠商出具了相關補丁與緩解措施，及時升級維護。

A4：1.補丁發布之前，無POC細節，通過提升攻擊難度，如繼續收斂操作員登錄SIP、管理員登錄SIP；2.補丁發布之前，無POC細節，通過全流量設備，監控有無此類的攻擊告警，重點關注；3.補丁發布，有測試環境的先測試，無測試環境的，待穩定版本發布后，通知升級。期間做好持續監測。

A5：堡壘機在HVV中經常會成為靶子，為了防止服務器擼了攻擊堡壘機，我們是對堡壘機實施了最小化的網絡訪問權限：如僅允許VPN網段可訪問堡壘機，堡壘機可訪問目標服務器SSH端口，實施粒度是到端口、協議級。

Q：除上述外，還遇到過哪些堡壘機的自身BUG？最后都是怎么解決的？

A1:堡壘機自身BUG無窮多，喊上代理商/供應商上門即可。

A2：堡壘機的客戶端穩定性欠佳，甚至沒一些開源的VNC好用。

A3：估計也不算BUG，就是不夠智能，在用戶無操作但畫面如果有一些動態的元素（如閃動條、動態桌面等），缺乏智能判斷，審計數據大，結合部分會話控制策略有效性遇到問題，導致疫情影響下的遠程辦公場景審計數據過大，通過轉發審計數據方式解決。

A4：目前遇到最大的問題，是圖形化工具量一上來，就觸發當前的BUG，無法使用。短期通過引流其他節點，重啟BUG應用發布機器；長期通過升級。

A5：防火墻要放到堡壘機管理，堡壘機前面有防火墻，防火墻有問題導致堡壘機連不上怎么辦？

A6：架構師設計問題，沒有設置帶外管理網。

Q：現在不少人吐槽一些廠商的堡壘機價格昂貴，會選擇更換堡壘機，那在更換不同廠商堡壘機時需要注意些什么？除此以外還可以有哪些安全的低成本方案？

A1：堡壘機已經是市場化比較成熟的產品，價格昂貴情況實屬未明確需求，只需要采購滿足需求的功能模塊即可。遷移堡壘機，需要注重資產導入、密碼復原、災備方案，全面規劃方案，重點逐步推進替換。低成本的開源方案不失為好的選擇。

A2：低成本的就是JumpServer 開源堡壘機挺好用的。

A3：可以通過一些可擴展的安全代理軟件來做反向代理或者跳板代理，通過某一臺特定的跳板機訪問特定目標主機，如V2ray trojan 。

A4：如果更換堡壘機是慢慢換，還是直接一次性換完呢？

A5：慢慢替換，一下子替換，有難度。

A6：一般都是建議慢慢換，尤其涉及到使用習慣的問題，需要慢慢培養。

A7：需求層面：合規方面的需求，使用部門的需求，安全其他方面的考慮，建議分批次上線，直接切換影響用戶體驗，還可能會出現很多意想不到的事情。

階段1，并行運行期間，邀請個別用戶部門體驗，提問題優化；

階段2，陸續邀請其他部門，直至所有用戶；

階段3，明確切換時間，提醒用戶盡早切換；

階段4，切換后，保留歷史堡壘機，規避用戶訪問；新堡壘機運行一段時間后，歷史設備下線。

話題二：大家對象存儲都全部要求私有嗎？業務想拿桶來放允許公開的數據，是否允許呢？

A1：要依據數據安全管理制度，盡然已經定級為公開數據，那就隨意。當然也不排除定級標準不規范。

A2：標準規范了，也不排除業務可能不知道，還有可能誤操作。

A3：在這個時候可以提一些基線要求，滿足了這108項，可以上。

A4：還是得看最佳實踐吧，可是最佳實踐不會那么細，就像基線要求，是否包含敏感數據，是否為測試數據等等。

A5：每家數據的戰略定位都不一樣，何況國內的實踐不一定是最佳的。數據安全是獨立的體系，是在基礎安全之上的。

A6：多少安全基線都不合格的已經在上DLP 加密。喊著做數據安全了。

A7：我想著基礎的也只能判斷業務是否允許公開讀、禁止公開讀寫這樣了。

A8：業務定義的可公開，大概率只是他們認為不重要，不會考慮安全性。比如，我這邊業務團隊認為身份證號、銀行卡號這些不算敏感信息。

A9：這個有明確制度規范要求，還好，我也管不過來了，再管下去，大頭都要管不住了，只能給些基礎的要求了。