4. 联动配置准备：环境要求、权限设置、网络连通

做联动配置前，先得把地基打好。

我记得刚带团队那会儿，差点就踩了个大坑——环境还没配齐就想验证功能，结果日志满天飞，排查了一整天，最后发现是网络策略没放通。从那以后，我养成了一个习惯：配置前先盘点，三件事一件不能少。

4.1 环境要求：版本、硬件与依赖

先把软件版本对齐了。我个人习惯用一个表格来对照，省得翻文档翻到眼花：

组件	推荐版本	说明
DSPM 平台	v3.5.x 及以上	需开启审计事件导出功能
数据源（如数据库、大数据平台）	与 DSPM 版本兼容列表核对	建议使用 LTS 版本
联动目标系统（日志平台/CMDB）	支持 REST API v2 或 JDBC	需要确认接口协议

硬件方面，我建议至少给 DSPM 节点预留 8 核 CPU、32GB 内存、500GB SSD 磁盘。为什么？审计数据一旦开始联动，日志写入量会陡增，磁盘 I/O 不够的话，整个平台都可能被拖慢。

依赖服务也很关键。确认以下组件是否已经就位：

• 消息队列（如 Kafka）—— 用于解耦审计事件的生产与消费。我用的是 Kafka 3.x，吞吐量比较稳。
• 对象存储（如 MinIO / S3）—— 审计日志的归档层。建议单独建一个 bucket，别和其他业务数据混在一起。
• 数据库（如 PostgreSQL / MySQL）—— 元数据与配置的持久化。嗯，这里要注意字符集必须用 utf8mb4，不然遇到特殊字符会报错。

4.2 权限设置：最小化与角色分离

权限这块，说白了就是「够用就行」。我在项目中遇到过不止一次，因为权限开太大导致安全合规检查亮红灯。

正确做法：创建一个专门的 审计服务账号，只授予必要的最小权限。

-- 以 MySQL 为例，审计服务账号赋权脚本
CREATE USER 'dspm_audit'@'%' IDENTIFIED BY '安全密码_替换为我方秘钥';
-- 仅授予读权限，不需要写、删、改
GRANT SELECT ON *.* TO 'dspm_audit'@'%';
-- 授予对 `information_schema` 的只读访问（用于获取表结构）
GRANT SELECT ON `information_schema`.* TO 'dspm_audit'@'%';
FLUSH PRIVILEGES;

角色分离也是一个要点。我比较推荐搞三套角色：

• 操作员：只能查看审计结果，无权修改配置。
• 配置员：可以设置联动规则，但不能看原始日志内容。
• 审计主管：全量权限，但需要双人审批才能提权。

对了，密钥管理也不要忽略。我曾经见过直接把密码写死在配置文件里的，结果配置泄露连累了一大批系统。最好使用 密钥管理服务（KMS） 或 环境变量 来传递密码。

4.3 网络连通：端口、协议与防火墙

环境配好了，账号也建好了，就差网络了。你想想看，两边服务器互相访问不了，配置写得再漂亮都是白搭。

首先，确认 端口开放清单。我一般会做成表格，发给网络组的同事让他们直接照着开：

源端	目标端	端口	协议	用途
DSPM 平台	数据源	3306 / 5432 / 1521	TCP	JDBC 直连采集元数据
DSPM 平台	联动系统 API	443 / 8443	HTTPS	推送审计事件
DSPM 平台	Kafka	9092 / 9093	TCP (SSL)	消息队列连接
联动系统	DSPM 回调接口	8080 / 8443	HTTP(S)	接收回调确认

然后，做一个简单的 连通性验证。我个人习惯用 telnet 或 nc 快速测一下：

# 在 DSPM 服务器上测试到数据源的连通性
telnet 10.12.34.56 3306

# 或者用 nc 做更详细的端口探测
nc -vz 10.12.34.56 9092

如果 telnet 能连上，基本就没什么问题。要是连不上，先检查防火墙策略，再看安全组。嗯，还有个别情况是 iptables 规则冲突，我遇到过两次，规则虽然配置了，但顺序不对，请求被后面的 deny 规则拦截了。解决方法很简单：把 allow 规则放在 deny 规则前面。

最后，别忘了 SSL/TLS 证书。如果你们公司要求全链路加密（很多金融客户都有这个要求），那还得提前把证书互信做好，避免配置过程中出现证书校验失败的错误。

4.4 配置预检流程图

说了这么多，不如直接看一张流程。我把环境、权限、网络这三步串到一起，整理成了下面的预检决策图：

好啦，准备工作做完，下一步就可以开始真正的联动配置了。别急，这时候最忌的就是「跳过检查直接上配置」。我见过太多因为漏掉一个环境版本、一个网络端口导致通宵排错的案例。花十分钟做验证，省的是后面十个小时的排查时间。