2. 服务器资产与配置项梳理

服务器安全基线的第一步不是改配置，而是把“要管什么”说清楚。如果连一台主机上跑了哪些中间件、哪个数据库实例、哪些容器、各自版本和监听端口都不清楚，后续的基线核查、漏洞修复、变更审计都会失去锚点。本节要解决的核心问题是：如何把主机、操作系统、中间件、数据库、容器这些异构对象，抽象成统一的配置项模型，并落地为可维护的资产台账。

一、为什么需要“配置项建模”而不是简单列清单

很多团队一开始用 Excel 记录服务器 IP、用途、负责人，这只能算“设备清单”，不是“配置项台账”。区别在于：设备清单描述的是“有一台机器”，配置项台账描述的是“这台机器上承载了哪些可被安全基线约束的对象，以及它们之间的依赖关系”。例如同一台物理机上可能运行 3 个容器、1 个 MySQL 实例、1 个 Nginx，它们各自有独立的配置文件、版本、监听端口和基线要求。如果只记录主机 IP，就无法定位“某个容器镜像使用了 root 用户”这类问题。

因此，配置项建模的目标是建立一套分层、可扩展的对象模型，让每个安全基线检查项都能挂载到明确的配置项上。推荐采用“四层对象模型”：

• 主机层（Host）：物理机、虚拟机、云主机，标识为资产唯一编号、IP、机房/区域、责任人。
• 操作系统层（OS）：OS 类型、发行版、内核版本、补丁级别、账户与权限策略。
• 运行时层（Runtime）：中间件（Nginx、Tomcat、Redis）、数据库（MySQL、PostgreSQL）、容器运行时（Docker、containerd）。
• 实例/容器层（Instance/Container）：具体进程实例、容器、镜像、挂载卷、监听端口、配置文件路径。

这四层之间是“承载关系”：主机承载 OS，OS 承载运行时，运行时承载实例。建模时用统一字段描述每一层，再用关系字段表达依赖，就能避免台账变成互不关联的表格堆砌。

二、配置项的统一字段设计

为了让不同对象能被同一套基线引擎处理，每个配置项至少应包含以下字段：

其中 parent_id 是建立层级关系的关键。通过它可以把“主机—OS—中间件—实例”串成一棵树，查询某个主机下所有配置项时只需按 parent_id 递归即可。实际落地时，建议用 CMDB 或轻量级图数据库存储，而不是纯 Excel，因为关系查询和变更追踪在表格中很难维护。

三、资产台账的建立方法

台账建立不是一次性录入，而是“发现—归一—补全—校验”的循环。推荐按以下顺序推进：

1. 自动发现：通过 SSH 批量采集主机信息，使用 dmidecode、uname -a、systemctl list-units 获取主机与 OS 信息；通过 docker ps、ps -ef、ss -lntp 获取运行时与监听端口。
2. 归一化：把不同来源的数据映射到统一字段。例如把 nginx -v 输出解析为 version，把 ss 输出解析为 listen。
3. 补全关系：根据进程 PID、容器 ID、配置文件路径，自动推断 parent_id，形成层级树。
4. 人工校验：对自动发现无法判断的字段（如责任人、业务归属、基线模板）进行人工确认。

下面是一段示例采集脚本片段，用于获取主机与容器的基础配置项：

#!/bin/bash
# 采集主机基础信息
HOST_ID=$(dmidecode -s system-uuid)
OS_VER=$(grep PRETTY_NAME /etc/os-release | cut -d'"' -f2)
KERNEL=$(uname -r)

# 采集容器列表
docker ps --format '{{.ID}}|{{.Image}}|{{.Names}}|{{.Ports}}' \
  | while IFS='|' read cid image name ports; do
      echo "container,$cid,$image,$name,$ports"
    done

# 采集监听端口
ss -lntp | awk 'NR>1 {print $4, $6}'

采集结果写入台账时，建议保留原始输出作为“证据字段”，便于后续核查时对比配置是否发生漂移。例如某台主机上周 Nginx 版本为 1.24.0，本周变为 1.25.1，台账应能记录变更时间和变更前后值。

四、配置项关系与基线挂载

台账建立后，下一步是把安全基线挂载到配置项上。不同层级的配置项对应不同的基线模板：主机层关注账户、SSH、防火墙；OS 层关注补丁、内核参数；中间件层关注 TLS、目录权限、日志；数据库层关注认证、审计、远程访问；容器层关注镜像来源、特权模式、挂载卷、资源限制。

下图展示了四层配置项模型及其与基线模板的挂载关系，同时标出了自动发现与人工补全的分工：

五、台账维护与漂移检测

台账建立后最大的挑战是“保鲜”。服务器会新增、下线、升级、迁移，如果台账不更新，基线核查就会漏检或误报。建议把台账更新嵌入日常变更流程：任何一次上线、扩容、版本升级，都必须同步更新对应配置项。同时，定期执行“台账与实机比对”，发现差异时区分两种情况：

• 台账缺失：实机存在但台账没有，说明发现流程有遗漏，需要补录并排查采集盲区。
• 台账过期：台账有但实机已变更，说明变更流程未同步，需要修正台账并追溯变更来源。

比对结果可以用简单的差异率衡量：差异配置项数 ÷ 台账总配置项数。示例中若台账共 1200 个配置项，比对发现 36 个不一致，差异率为 3%。这个指标可以作为台账健康度的观察值，持续偏高说明流程需要改进。

总结来说，配置项建模解决的是“对象如何抽象”，资产台账解决的是“对象如何记录与维护”。两者结合，才能让后续的基线核查、漏洞管理、变更审计有稳定的数据基础。下一阶段的工作，就是基于这套台账，为每一类配置项定义具体的基线检查项和判定规则。