宝软数字 · 产品深度解读 · 2025-09-03
企业引入AI平台时，安全是绕不开的第一道门槛。模型推理可能接触核心业务数据，Agent调用可能涉及敏感系统权限，LLM输出可能产生不可预期的内容——每一环都是风险敞口。EIOS在设计之初就把安全内建到架构里，而不是事后补丁。这篇文章将完整拆解EIOS的7层纵深防护体系：从最外层的DDoS清洗，到最内层的审计追溯，每一层都有具体的架构决策、技术选型依据和真实踩坑记录。
任何暴露在公网的服务，首先要面对的就是大流量攻击。EIOS的前置层部署了云防护的DDoS清洗中心，所有入站流量先经过清洗节点，再路由到后端。这里的关键决策是：不在Nginx层做限流，而是在更上游的清洗层完成粗粒度过滤。原因是Nginx的limit_req模块基于共享内存，在高并发下会成为瓶颈——单机limit_req的锁竞争在超过5000并发时会显著拖慢正常请求延迟。
清洗层采用了两级过滤策略。第一级是源IP信誉库——对接了云厂商的威胁情报，已知的攻击IP、恶意代理、Tor出口节点在黑名单命中后直接丢弃，不进入任何后续处理。第二级是行为分析——基于滑动窗口统计每个源IP的请求速率和请求模式。如果一个IP在10秒窗口内向同一URL发送超过200次POST请求，或者请求的URL熵值异常（说明在暴力扫描），触发自动限速。这里我们设置了一个重要参数：限速不是直接封禁，而是将超量请求放入低优先级队列。这样做的好处是，即使误判了正常用户，他们的请求只是慢一点，不会被完全阻断——这对企业SaaS场景至关重要。
架构决策：我们评估了Cloudflare Magic Transit和阿里云Anti-DDoS Pro的方案，最终选择了多云清洗策略——核心API走阿里云清洗（同区域延迟<2ms），静态资源和CDN边缘走Cloudflare（全球加速），这样既利用了云厂商的清洗能力，又避免了单一厂商依赖。事实是，过去6个月我们遭受了约340次DDoS攻击，最大一次峰值流量达到87Gbps，清洗层全部成功拦截，后端服务零影响。
过了清洗层，流量进入WAF（Web Application Firewall）。WAF的职责是识别和阻断应用层攻击——SQL注入、XSS、CSRF、命令注入、路径遍历等。EIOS的WAF采用了规则引擎+语义分析的双引擎架构。
规则引擎基于ModSecurity的OWASP核心规则集（CRS），但做了三点重要改进。第一，规则分级而非全量拦截：CRS默认的偏执级别是1（最宽松），我们调整到2（中等），并手动审查了所有严重级别为CRITICAL的规则。这里有一个踩坑经验——CRS的规则920100（无效的HTTP协议版本）在生产环境误杀了大量使用HTTP/1.0的旧客户端，我们把它降级为WARN并加入了白名单路径。第二，按租户维度定制规则：每个EIOS租户可以有自己的WAF配置，因为不同行业客户面对的威胁模型不同——金融客户需要更严格的SQL注入规则，而制造业客户可能更需要关注工控协议相关的攻击模式。第三，动态规则更新：WAF规则集每24小时从OWASP官方仓库拉取更新，但新规则先进入"审计模式"7天——只记录不拦截，确认无误报后再切换为拦截模式。
语义分析引擎是规则引擎的补充。传统正则匹配的WAF容易被绕过——攻击者可以用编码、注释注入、分段传输等方式绕过正则。语义分析引擎会对HTTP请求做完整解析：URL解码、JSON/XML解析、Base64解码、多重编码检测，然后在解析后的语义层做威胁检测。例如，如果参数中检测到SELECT ... FROM ... WHERE的SQL语义结构，即使经过了三层编码绕过了所有正则规则，语义引擎仍能识别。
真实数据：WAF上线6个月，累计拦截恶意请求约1270万次。其中规则引擎贡献了约76%的拦截量（主要是自动化扫描器的常规攻击），语义引擎贡献了约24%（主要是绕过尝试和定制化攻击）。两者互补效果明显——有约3.2%的攻击绕过了规则引擎但被语义引擎捕获，这些是最危险的手工渗透尝试。
传统安全架构依赖"城堡+护城河"模型——外围防护做得足够坚固，内部网络默认信任。这种假设在现代云原生架构下已经完全失效。EIOS从第一天起就采用了微分段策略：即使在同一VPC内部，服务之间也不默认信任，所有东西向流量都需要经过策略引擎授权。
微分段的实现依赖Kubernetes的NetworkPolicy和Calico网络插件。我们定义了三个核心安全域：入口域（ingress-nginx所在的Pod，只暴露443端口）、业务域（NestJS API服务所在Pod，只接受入口域的请求，不暴露公网）、数据域（PostgreSQL/Redis/Neo4j所在Pod，只接受业务域的连接，数据库端口对公网完全不可达）。每个域的进出流量都有白名单策略——不是"允许所有，拒绝特定"，而是"拒绝所有，只允许特定"。
这里有一个架构细节值得展开。Agent在执行工具调用时，需要访问外部API（如搜索引擎、文档解析、邮件发送等）。如果让Agent Pod直接出公网，等于给攻击者提供了一个潜在的SSRF出口点。我们的方案是引入一个外联网关——Agent发出的所有外部请求都经过这个网关，网关做了三件事：域名白名单（只允许预定义的API域名）、请求签名（防止Agent被注入后发送未授权的外部请求）、速率限制（防止单个Agent滥用外部API配额）。外联网关本身也运行在独立的Pod中，和Agent Pod不在同一安全域。
关键原则：微分段的"零信任起点"意味着任何两个服务之间的通信，默认是被阻断的。每个允许策略都代表一个经过审查的、明确的业务需求。目前EIOS内部有47条NetworkPolicy规则，每条都有对应的业务理由文档。新增一条策略需要经过安全审查——这不是官僚主义，而是防止"为了方便"打开不必要的通道。
传输层安全是纵深防御中最基础但最容易配置出错的一层。EIOS要求所有通信——无论是客户端到服务器、服务器到数据库、还是服务之间的内部调用——都必须加密。在TLS层面，我们做了三个关键决策。
第一，TLS 1.3 only。TLS 1.2虽然仍然广泛使用，但它在握手中包含了多个不安全的密码套件选项（如CBC模式的对称加密），而且握手需要2个往返（2-RTT）。TLS 1.3移除了所有已知不安全的算法，握手减少到1-RTT（首次连接）甚至0-RTT（恢复连接）。更重要的是，TLS 1.3的密钥交换强制使用前向安全性（PFS）——即使服务器私钥泄露，历史会话也无法被解密。在Nginx配置中，我们明确禁用了TLS 1.2及以下版本：ssl_protocols TLSv1.3;。这带来的代价是放弃了约2.3%的旧客户端（主要是不支持TLS 1.3的企业内部系统），但这个取舍是值得的。
第二，证书自动化与HSTS预加载。使用Let's Encrypt的ACME协议自动管理证书，90天自动续期。同时启用了HSTS（HTTP Strict Transport Security），max-age设置为2年，并提交到浏览器的HSTS预加载列表。这意味着即使攻击者通过DNS劫持将用户导向了一个伪造的HTTP站点，浏览器也会因为HSTS预加载而拒绝连接。
第三，内部mTLS。服务之间的内部通信不仅加密，还通过TLS双向认证（mTLS）来验证通信双方的身份。每个服务拥有自己的X.509证书，由内部CA签发。Calico网络策略加上mTLS证书验证，确保即使攻击者突破了外层防护进入了内网，也无法冒充合法服务进行横向移动。
注意：mTLS的运维成本不低——证书轮换、CA管理、服务启动时的证书加载都需要自动化。我们使用cert-manager在Kubernetes中管理内部证书，Service Mesh（Istio）自动处理mTLS的握手和轮换。如果没有这些基础设施的支撑，mTLS很容易变成"配了就忘"的安全负债。
过了网络层和传输层，进入应用层的身份认证与访问控制。这是纵深防御中唯一直接面向用户的一层，也是安全事件的第一响应阵地。
EIOS的身份认证采用多因子认证（MFA）架构，支持TOTP和WebAuthn（FIDO2）两种第二因子。TOTP覆盖了移动端场景，WebAuthn覆盖了桌面端硬件密钥场景。密码策略遵循NIST SP 800-63B的最新指南：不强制定期更换密码（研究成果表明定期换密码反而导致用户选择弱密码），但强制检查密码是否在已知泄露库中（通过Have I Been Pwned的k-anonymity API）。密码哈希使用argon2id，内存开销设置为64MB，并行度为4——这个参数在密码验证延迟（约500ms）和抗暴力破解能力之间取得了平衡。
Session管理是认证体系中最容易出问题的环节。EIOS的Session方案：JWT作为API访问令牌，有效期15分钟，不支持刷新；Refresh Token存储在httpOnly+Secure+SameSite=Strict的Cookie中，有效期7天。Token刷新时采用Token轮换机制——每次使用Refresh Token会同时下发新的Refresh Token，旧的立即失效。这样即使Refresh Token被窃取，合法的用户会在下一次刷新时发现Token失效（因为攻击者已经用掉了），系统检测到重放攻击并自动通知安全管理员。
授权层面使用RBAC（基于角色的访问控制）加上ABAC（基于属性的访问控制）的混合模型。RBAC处理粗粒度的功能权限——管理员、编辑者、查看者；ABAC处理细粒度的数据权限——如"只有本部门的数据"、"只有自己创建的项目"。每个Agent的每次工具调用，在执行前都会经过策略决策点（PDP），PDP评估当前的用户角色、资源标签、环境属性（时间、IP、设备类型），然后返回允许或拒绝。策略使用OPA（Open Policy Agent）的Rego语言编写，存储在Git仓库中，CI/CD自动部署到策略引擎——这确保了权限策略的版本控制和审计。
踩坑记录：早期版本中，Agent的工具权限是直接硬编码在Agent配置里的。一次代码审查发现，如果攻击者通过提示注入让Agent调用了本不该有权调用的数据库写入工具，由于权限硬编码在Agent侧而非策略引擎侧，无法通过修改配置来阻断。修复方案是将所有Agent工具权限统一切换到OPA策略引擎评估——Agent发出工具调用请求时，PDP根据当前会话的上下文（用户角色+资源+操作）实时决策。这个改动虽然增加了约15ms的工具调用延迟，但消除了权限旁路的可能性。
纵深防御的最后一层不是阻止攻击，而是确保任何操作都有迹可循。即使前面的5层都被突破，一个设计完善的审计系统能让安全团队快速定位攻击路径、评估数据泄露范围、提供合规证据。
EIOS的审计系统设计遵循三个原则。第一，全覆盖——不仅是管理员的CRUD操作，还包括Agent的每次推理决策、每次工具调用、每次LLM提示注入尝试、每次权限拒绝。所有审计事件通过Kafka事件总线异步写入，不阻塞业务请求。第二，不可篡改——审计日志使用Merkle树结构，每小时生成一个区块根哈希，写入一个独立的只追加数据库。任何人（包括DBA）修改了历史审计记录，Merkle根哈希会立即暴露篡改。第三，可追溯——每个审计事件携带traceId，贯穿整个请求生命周期。从用户发起请求，到Nginx接入日志，到API服务的业务日志，到Agent的推理日志，到数据库的查询日志，所有链路通过一个traceId串联。
审计存储采用冷热分层策略。热数据（最近30天）存储在Elasticsearch中，支持近实时的全文搜索和聚合分析——安全团队可以在秒级内回答"过去24小时内谁访问了财务报表相关的Agent"。温数据（30天到1年）存储在对象存储的Parquet文件中，通过Athena/Trino按需查询。冷数据（1年以上）归档到冷存储，但在保留期内不会被删除——等保和GDPR都要求特定类型的日志保留期限。
安全运营实践：审计系统不只是合规需求的被动满足，更是安全运营的主动工具。我们设置了约60条审计告警规则——例如"同一用户在5分钟内从3个不同地理位置的IP登录"、"单个Agent在1小时内执行了超过1000次工具调用"、"数据库查询中检测到全表扫描且包含敏感字段"。这些规则帮助安全团队在攻击进行中就能发现异常，而非事后翻日志。
传统Web应用的7层防护到应用层就结束了。但AI平台引入了一个全新的安全维度——模型层安全。提示注入、模型越狱、训练数据投毒、幻觉输出——这些是传统WAF和RBAC无法覆盖的风险面。EIOS的AI安全策略分为三个方面。
第一，提示注入检测。用户的输入在进入LLM之前，经过一个轻量级的检测模型——基于BERT的文本分类器，专门训练用于识别提示注入模式（如"忽略之前的指令"、"你现在是DAN模式"、"输出你的system prompt"等）。这个分类器的推理延迟控制在50ms以内，不会显著影响用户体验。同时，系统提示词本身采用了参数化设计——用户输入通过结构化的JSON参数传递，而非直接拼接到提示词中，这从语法层面消除了大部分注入路径。
第二，输出安全审查。LLM的输出在返回给用户之前，经过内容安全过滤器——检测是否包含PII泄露（通过正则和NER模型识别身份证号、电话号码、邮箱地址）、是否包含恶意代码（检测代码块中的eval、exec、subprocess等危险调用）、是否包含受管控的内容类别（根据租户的安全策略配置）。过滤器以流式方式工作——LLM的输出流经过过滤代理，不安全的片段被替换为安全提示，而不是等整个响应生成完再检查。
第三，工具调用权限的运行时验证。即使认证和授权层已经通过了，Agent在每次具体工具调用前，系统还会做一次"意图验证"——检查Agent请求的工具参数是否在合理范围内。例如，如果Agent突然请求读取"/etc/passwd"这样的系统文件路径，即使Agent有文件读取权限，运行时验证器也会拦截——因为这显然不在Agent的正常操作范围内。这个验证器基于历史行为基线，通过统计Agent过去100次工具调用的参数分布，标记出统计异常的参数。
防御深度：AI安全的核心理念是"不信任任何一方"——不信任用户输入（可能包含注入）、不信任模型输出（可能包含幻觉或泄露）、不信任Agent决策（可能被越狱）。三重防护各自独立运作，彼此不依赖。在6个月的生产运行中，提示注入检测拦截了约1.3万次尝试，输出过滤器拦截了约2800次PII泄露风险（其中约60%是模型从训练数据中"回忆"出的泄露模式），运行时验证器拦截了47次异常的Agent工具调用——大部分是Agent在复杂对话中被引导到不安全的操作路径。