AI等保配置先定边界：模型、数据与日志该怎么管

AI等保配置不是一个可以一次性打开的开关，而是把等级保护对主机、数据、访问控制和审计的要求，逐项对应到AI系统的模型文件、训练数据、推理接口和运行日志上。
动手之前先做一件事：划定这套AI系统的边界，明确哪些服务器、哪些目录、哪些接口算在保护范围内。
边界不清，后面的账号、日志、备份配置都会漏项。

本文按“先清点、再收敛、后验证”的顺序展开，适合已经在运行模型服务、准备做等保整改的运维人员。
不同等级和不同测评机构的具体要求会有差异，最终以本单位定级结果和测评方的检查项为准。

先把AI系统边界和资产清单列出来

等级保护检查的第一手材料是资产清单。
AI系统容易出问题的地方在于资产分散：模型权重放在一台机器，训练数据放在对象存储，推理服务又跑在另一台机器上。
建议先在每台相关服务器上执行基础清点。

• 确认操作系统与内核版本：cat /etc/os-release、uname -r
• 列出监听端口，确认推理服务对外开放了哪些端口：ss -tlnp
• 找出模型文件所在目录及大小：du -sh /data/models/*
• 记录服务运行账号：ps -eo user,pid,cmd | grep -i infer

把结果整理成一张表，字段至少包含：主机IP、用途（训练/推理/存储）、模型文件路径、数据存放位置、对外端口、负责人。
这张表后面配置权限和日志时都要用。

需要提醒的是，模型权重和训练数据都应视为重要数据资产。
如果训练数据里含个人信息，还要单独标注，因为这类数据的访问控制和留存要求通常更严格。

账号权限要按最小化原则收敛

AI服务常见的隐患是用root直接跑推理进程，或者多人共用同一个账号。
等保对身份鉴别和访问控制有明确要求，实际配置可以从这几点入手。

• 为AI服务单独建运行账号，例如 useradd -r -s /sbin/nologin ai-run，进程以该账号启动。
• 模型目录和训练数据目录设置属主与权限，例如 chown -R ai-run:ai-run /data/models，权限设为 750，避免其他用户读取。
• 关闭不必要的远程登录，检查 sshd_config 中的 PermitRootLogin no。
• 多人运维时使用独立账号加 sudo 授权，不要共享密码。

配置完成后用 ls -l /data/models 和 ps -eo user,cmd | grep infer 复查，确认进程账号和目录属主一致。
如果服务启动报权限错误，优先检查目录属主和SELinux状态，而不是直接改成777。

审计日志要覆盖登录、操作和接口调用

审计是等保检查的重点，也是AI系统最容易缺的部分。
需要区分三类日志：系统登录日志、运维操作日志、AI接口调用日志。

系统层面，确认 auditd 或系统日志服务在运行：systemctl status auditd。
登录记录可通过 last 和 /var/log/secure（Debian系为 /var/log/auth.log）查看。

运维操作层面，建议开启命令历史记录并集中收集，至少保证 history 不被随意清空，重要操作通过 sudo 留痕。

接口调用层面，推理服务应在应用层记录请求时间、来源IP、调用账号、请求摘要和响应状态。
日志中不要记录完整的敏感输入内容，可按需做脱敏。
日志留存期限要结合本单位定级要求和存储容量确定，不建议在未确认要求前随意设定一个数字。

日志文件本身也要保护：设置合适权限，避免被普通账号删除，必要时配置远程日志服务器。

配置改完要逐项验证

改完权限、账号和日志配置后，不要只看配置文件，要做实际验证。

• 用服务账号重启推理进程，确认能正常启动并对外提供服务。
• 用普通账号尝试读取模型目录，预期应被拒绝。
• 触发一次登录和一次接口调用，检查对应日志是否产生记录。
• 检查防火墙规则是否只放行必要端口：firewall-cmd --list-all 或 iptables -L -n。

任何一项验证失败，先回看该步骤对应的配置项，再决定是否调整。
涉及修改防火墙或权限的操作，建议提前备份配置并记录回滚方式，避免影响线上服务。

几个容易踩的坑

把模型文件放在Web可访问目录下，等于绕过了所有权限控制；
训练数据未脱敏就进入日志，反而制造新的泄露点；
只配置了系统日志却忽略应用层调用记录，测评时会被认为审计不完整；
多人共用root账号，操作无法追溯到人。
这些问题的共同点是配置看起来做了，但边界和留痕没有真正闭合。

AI等保配置的核心是把AI资产纳入已有的安全管理制度，而不是另建一套体系。
先把资产清单和边界定清楚，再逐项收敛权限、补齐日志、验证效果，整改才有据可查。