数据边界从监听地址开始
推理引擎通常不做用户鉴权，它默认信任调用方，所以边界要从最基础的一步开始收：引擎只监听环回或内网地址，公网入口只在网关，网关到引擎之间再加一层内部鉴权。再往上才是数据层面的处理，包括请求内容最小化、敏感字段在进入模型前替换、返回后还原，以及日志分级留存。具体合规口径以本单位的制度与所在行业要求为准。
基本信息
| 第一道边界 | 引擎监听地址收敛到环回或内网网段 |
|---|---|
| 第二道边界 | 公网仅暴露网关端口，网关持有对外鉴权 |
| 第三道边界 | 网关到引擎的调用携带内部凭据或走受控网络 |
| 数据层面 | 敏感字段模板化替换、请求最小化、日志脱敏 |
| 执行方式 | 按本单位数据分类分级制度与行业监管要求落地 |
典型使用场景
- 新服务上线前的安全自查：确认引擎端口没有直接暴露在公网
- 数据分类落地：识别请求中会出现的身份信息、联系方式与内部标识
- 日志留存设计：确定请求体是否入库、保留多久、谁能查看
- 第三方模型接入评估：外部调用会离开自有边界，需单独评估与授权
- 审计与追溯：为敏感调用留下可审计的元数据，同时不记录正文
边界核对清单
边界核对清单
# 1 确认引擎仅内网/环回监听
ss -lntp | grep -E '8000|8001'
# 2 确认对外只开网关端口，防火墙与安全组一致
firewall-cmd --list-ports
# 3 从外部网络尝试直连引擎端口，应当不可达
# 4 网关到引擎的调用带内部鉴权，来源网段受控
# 5 请求最小化：只传必要字段，敏感字段模板化替换
# 6 日志分级：请求体不入库，或脱敏后再入库边界分层与常见缺口
| 层面 | 应有做法 | 常见缺口 |
|---|---|---|
| 监听地址 | 仅环回或内网网段 | 开发环境遗留 0.0.0.0 监听未回收 |
| 对外入口 | 仅网关端口暴露 | 调试端口或监控端口开到公网 |
| 调用鉴权 | 内部凭据或受控网络 | 网关到引擎裸奔，内网横向移动即可调用 |
| 请求内容 | 最小化并替换敏感字段 | 整段业务数据直接进模型 |
| 日志留存 | 脱敏并按级别保留 | 请求正文全量入库且长期保存 |
| 第三方出口 | 单独评估与授权 | 数据流出后无法追溯去向 |
敏感字段在进模型前替换、返回后还原，采用模板化替换比人工逐条审查更可执行：替换规则集中维护，且不依赖个人经验。
把引擎端口直接暴露到公网是最常见的严重缺口：鉴权、限流与审计全被绕过，先收监听地址，再谈其余安全措施。