概要
在遠程與外包協同成為常態的環境下，“運維審計”既要滿足合規留痕，也要對高風險行為做到可見、可證、可阻斷。傳統路徑通常以“堡壘機”作為入口，但當工程師直接 SSH 連接主機（繞行堡壘機） 時，命令與返回內容往往不可見，形成審計盲區。基于更多堡壘機繞行場景的運維審計產品選型，可以參考本文。 #&【重點】：傳統堡壘機無法解決繞行連接的場景需求、以及做精細化的風險分析需要的復雜的協議操作的內容級分析，因此需要給客戶2種清晰的場景界定
1. 選型要點總覽
典型的運維審計體系包含：身份與授權（4A/多因子/國密） 、資產納管（主機/數據庫/網絡設備/云資源） 、運維通道治理（SSH/RDP/DB 協議與命令控制） 、審計留痕（命令/回放/文件傳輸留痕/完整性） 、告警聯動（SIEM/SOAR/ITSM） 、合規與數據治理（保留策略/檢索/可核查） 。
在此基礎上，針對SSH 加密協議帶來的“操作內容不可見”問題，需要補充服務器側的明文采集能力，將“命令 + 返回文本”落入審計日志里，形成與堡壘機互補的閉環。
2. 主流產品能力矩陣（對標項）
說明：下表僅選取選型討論中最常出現的維度；“可選/插件”表示該能力存在于特定版本、選配或與第三方組件集成后具備。
| 維度 | 阿里云 堡壘機（多版本） | 華為 UMA 系列 | JumpServer（開源/商業） | 安恒 堡壘機 | 銳捷 RG-OAS | AI-FOCUS 錄云 SSH 審計 |
|---|---|---|---|---|---|---|
| 身份認證/4A/國密 | ?（多因子/國密版本） | ? | ?（對接 AD/LDAP） | ? | ? | 對接現有 4A（本身不做 4A 主體） |
| 資產納管（主機/DB/網絡） | ? | ? | ? | ? | ? | 主機側探頭（面向納管主機） |
| 運維通道（SSH/RDP/DB） | ? | ? | ? | ? | ? | SSH 命令鏈路可見（含 scp/sftp 行為識別） |
| 命令控制/策略攔截 | ? | ? | ? | ? | ? | 基于主機側策略（補充直連攔截） |
| 審計：命令/回放/文件留痕 | ? | ? | ? | ? | ? | 命令 + 返回文本級證據（內容級） |
| 直連可見性（無跳轉） | 視版本/Agent（可選/有限） | 視版本/Agent（可選/有限） | 需插件/旁路（有限） | 視版本/Agent（可選/有限） | 視版本/Agent（可選/有限） | ?（主機側輕量 Agent） |
| 部署形態 | 云/專有云/集群 | 物理/集群 | 開源自建/商業 | 物理/集群 | 物理/集群 | 主機側 Agent + 中央審計服務 |
| 生態聯動（API/SIEM/ITSM） | ? | ? | ? | ? | ? | Kafka/ES/Prometheus/REST |
定位關系：堡壘機負責統一入口與通道治理，而錄云作為“堡壘機繞行補充措施”，將 SSH 直連時的命令與返回文本納入統一證據鏈，彌補“繞行場景不可見”的天然缺口。這樣做不替代堡壘機，而是把“內容級證據”拼齊。
3. 堡壘機繞行的SSH行為帶來的操作行為不可見：從協議到證據鏈
* MITM 的邊界：SSH 在會話階段為端到端加密，流量鏡像/旁路等方案可見到流量，但拿不到明文命令與返回文本，除非改變連接路徑或在主機側采集。
* ASCII 原理草圖：
``` 工程師終端 ──(SSH 加密)──→ 服務器 │ │ └─(繞行堡壘機？若無)──×──┘ ← 傳統旁路/鏡像僅見加密包 ``
* 補全思路：在目標主機布署輕量探頭，對 SSH 會話相關的 read/write、execve 等關鍵系統調用進行明文側采集，提取“命令 + 返回文本 + 文件操作”，并與賬號、主機、時間、來源網段等聯合成可核查證據。
4. AI-FOCUS｜錄云 SSH 運維行為審計系統
4.1 架構與組件
* 主機探頭（recorder-agent）
- 以低侵入方式掛接關鍵系統調用（如
execve()、read()/write()），捕獲 SSH 會話中命令與返回文本、文件傳輸與歸檔操作（scp/sftp/tar等）。 * 支持systemd自恢復（Restart=always），異常退出自動拉起。 * 資源開銷控制在CPU <1% / 內存 ~50MB（典型場景），對生產負載影響可量化評估。
* 中央審計服務（audit-engine）
* Kafka 消峰、Elasticsearch 毫秒級檢索、Kibana 可視化、Prometheus 健康監測（/metrics 暴露探頭狀態）。 * 統一關聯系統：賬號（含 SSO/AD/LDAP）、主機、時間線、會話 ID、來源 IP/子網，生成可復核證據鏈。 * 提供 REST API 與 WebHook，便于接入堡壘機、SIEM/SOAR、ITSM。
4.2 內容級證據：從“命令”到“上下文”
* 規則 + 語義并行：
1. 基礎規則：高危命令黑名單（如 rm -rf /、mkfs.*）、關鍵目錄操作（/etc、/var/lib 等）；
2. 上下文語義：對連貫行為序列建模（如 sudo su - → chattr -i /etc/passwd），識別“看似正常命令但上下文異常”的鏈路；
3. 組合行為：將 tar czf /sensitive ... → scp ... external:/tmp 關聯為外發路徑，并給出時間窗統計。
``
* 輸出形態： * 每次操作落成“命令 + 返回文本”的可檢索記錄（適合證據復核與復盤）； * 附帶文件操作摘要（方向、大小、散列）與基線偏離評分； * 觸發策略可聯動阻斷（如調用本機 iptables 規則或通知堡壘機側策略）。
`4.3 時效性與穩定性
- 探頭就地采集，毫秒級命令捕獲； * 在 1Gbps 網絡與常見 I/O 壓力下，結合分段壓縮傳輸（GZIP/Snappy）保障高完整性傳送； * 第三方測評中實現高日志覆蓋率與低誤報（示例：覆蓋率 ~99% / 誤報 <5% 的量級，具體以項目 PoC 報告為準）。 ---
- 場景復盤（與原文一致并更聚焦）
場景 A｜外包賬號夜間登錄
探頭捕獲登錄與后續命令；2) 與時間策略對比（工作時段白/黑名單）；3) 觸發聯動（告警或強制斷開），并將上下文命令序列落成證據。
場景 B｜批量外發嘗試
識別 tar/scp 等組合；2) 對可疑目錄執行內容級標注（如含個人敏感信息/關鍵配置）；3) 觸發阻斷與取證保全（含散列與時間線）。 --- - 與堡壘機體系的對接方式（最小改動）
* 不改變現有入口：堡壘機繼續作為統一運維入口、賬號與策略中樞。 * 在關鍵服務器側啟用錄云探頭：僅對需要“內容級證據”的資產啟用（生產數據庫、核心業務主機等）。 * 證據匯聚：錄云將“命令 + 返回文本 + 文件鏈路”推送到中央審計服務，再與堡壘機日志在 SIEM/SOAR/數據湖對齊與匯總。 * 賬號與會話關聯：通過 SSO/AD/堡壘機工單編號對齊，定位到具體人員與授權來源。 * 變更半徑可控：先行在 10% 資產啟用 dry-run（僅采不攔），復核結果后再打開策略攔截。 --- - 合規映射與留存策略
* 等保 2.0 三級（GB/T 22239-2019） ：審計日志覆蓋關鍵操作、具備完整性與可追溯； * ISO/IEC 27001 A.12.4.1：信息系統審計記錄具備充分性與留存策略； * GDPR Article 30（如涉及跨境業務） ：可提供“訪問與處理記錄”，便于響應數據主體請求。 * 留存建議：按主機重要級別與法律法規要求分級保留，敏感主機建議≥ 6–12 個月在線可檢索，歸檔 ≥ 2–5 年。 --- - 驗證與口徑
統一驗證口徑：
覆蓋率：以“真實命令總數”為分母（含腳本內命令、非交互式命令），核對錄云與堡壘機側的去重后明細；誤報/漏報：設定基準規則集，對每條告警進行人工復核并記錄樣本庫；資源占用：在峰值與日常兩種負載下分別采集 CPU/內存/I/O，給出 P95/P99；延遲：以“命令執行→可檢索落庫”為鏈路，采樣 1000 次求分位數；阻斷有效性：在測試機上演練高危命令與外發鏈路，記錄命中率與誤殺率。 ---
9. 實施路徑（保留原文思路并壓縮成要點）`
* 部署規劃：生產主機使用包管理部署 recorder-agent；測試環境用容器快速驗證。 * 策略配置：policy.yaml 定義高危命令白/黑名單；ai-config.json 設置模型閾值與組合規則。 * 灰度與觀測：先在 10% 服務器啟用 dry-run，通過 Kibana/Prometheus 看齊采集質量與系統健康。 * 運維聯動：Alertmanager / ITSM 工單打通，重要告警進入閉環。 * 變更管理：與安全/合規/業務方共評估“必審資產”清單，再逐步全量。
`---
10. 結論
* 堡壘機依舊是“運維審計選型”的主入口，擅長統一接入、賬號授權與通道治理； * AI-FOCUS團隊的錄云 SSH 審計以主機側明文采集補齊直連場景的內容級證據，把“命令與返回文本”納入可核查鏈路； * 二者結合，在不改現有組織與權限體系的前提下，實現可見性完整、證據可復核、策略可落地的運維審計閉環。對于對外包協同多、直連頻繁、合規要求高的單位，建議優先在核心資產上啟用錄云探頭，按“干預強度由弱到強”的節奏推進，最終與堡壘機與 SIEM 聯成統一面板。 ---
附：關鍵技術要點（摘要）`
- 采集：
execve()/read()/write()鏈路級采集； * 時效：毫秒級命令入庫； * 覆蓋：命令 + 返回文本 + 文件外發鏈路； * 穩定：systemd自恢復、Kafka 消峰、ES 毫秒檢索； - 生態：REST API、WebHook、Prometheus 指標、對接 SIEM/SOAR/ITSM；
- 合規：等保/ISO27001/GDPR 條款對應的留存與檢索能力；
- 資源：典型主機 CPU <1%、內存 ~50MB（以 PoC 觀測報告為準）。
posted on
浙公網安備 33010602011771號