AI安全加固教程：从模型接口到服务器层做一轮可验证的加固
AI 应用的安全加固不是装一个防护软件就结束，而是把模型接口、服务器、密钥和日志这几条链路逐项收紧。
下面这套做法适用于自己部署或代理大模型 API 的场景，比如用 Nginx 反向代理 Ollama、vLLM 或云端模型接口。
核心目标是：未授权请求进不来、异常调用被限住、敏感信息不外泄、出问题能查日志。
动手前先确认暴露面和前提
先搞清楚哪些入口对外可达。
在服务器上执行：
ss -lntp重点看监听 0.0.0.0 的端口，尤其是模型服务端口（Ollama 默认 11434，vLLM 常见 8000）。
如果模型服务直接暴露在公网，第一步就是改成只监听 127.0.0.1，由 Nginx 统一对外。
加固前需要准备：一个可用的 Nginx、能修改模型服务启动参数的权限、API Key 的存放位置（建议环境变量或独立配置文件，不要写进代码仓库）。
修改配置前先备份：
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak第一层：接口鉴权与限流
给模型接口加鉴权最省事的方式是在 Nginx 层校验请求头。
准备一个 Key 文件，用 htpasswd 生成：
htpasswd -c /etc/nginx/.ai_auth ai_user然后在 server 块中加：
location /api/ {
auth_basic "AI API";
auth_basic_user_file /etc/nginx/.ai_auth;
limit_req zone=ai_limit burst=10 nodelay;
proxy_pass http://127.0.0.1:11434/;
}限流规则要在 http 块定义：
limit_req_zone $binary_remote_addr zone=ai_limit:10m rate=5r/s;改完执行 nginx -t 检查语法，再 nginx -s reload。注意：auth_basic 是明文传输凭据，必须配合 HTTPS 使用，否则密码在链路上可被截获。
第二层：输入输出过滤与密钥隔离
模型接口被滥用常见于两类情况：超长输入撑爆上下文、返回内容带出内部信息。
可以在代理层限制请求体大小：
client_max_body_size 2m;
proxy_read_timeout 60s;密钥方面，模型 API Key 不要出现在前端代码或日志里。
应用侧用环境变量读取：
export MODEL_API_KEY="你的密钥"同时确认模型服务启动时没有把 Key 打到标准输出。
日志中如果出现 Authorization 头，需要在 Nginx 日志格式里剔除，避免审计日志本身成为泄露源。
加固后如何验证是否生效
逐项验证比“看起来配好了”更可靠。
先测未授权请求：
curl -i http://你的域名/api/generate预期返回 401 Unauthorized。
带上凭据再测：
curl -i -u ai_user:密码 -X POST http://你的域名/api/generate -d '{"model":"llama3","prompt":"hi"}'预期返回正常模型响应。
然后用循环快速请求，观察是否出现 503（被限流），说明 limit_req 生效。
最后检查日志里是否还有明文密钥：
grep -i "authorization" /var/log/nginx/access.log应当没有输出，或输出已被脱敏。
容易踩的坑
- 只改了模型服务监听地址，忘了重启服务，端口仍在公网可达，用
ss -lntp复查。 - 限流只按 IP 做，同一出口 IP 后的多个用户会互相影响，多租户场景应改为按用户维度限流。
- 日志保留过短，出事后无法回溯，建议至少保留 7 天并定期轮转。
- 加固后没做回归测试，正常业务请求被误拦，改完配置务必用真实调用方式验证一遍。
AI 安全加固没有一劳永逸的开关，建议每次变更配置后都按上面的验证步骤跑一遍，并把结果记录下来，方便后续排查和复查。
