今天，2026年国家网络安全宣传周开幕（9月14日-20日），主题是"网络安全为人民，网络安全靠人民——智能时代，网安护航"。

开幕式上同步发布了《人工智能安全治理框架3.0》（网安标委编制、国家网信办指导）——继2024年1.0、2025年2.0后的第三次迭代，延续"风险分类、技术应对、综合治理"总体框架，按AI新趋势更新了风险分类与技术应对措施，同期落地《生成式人工智能服务安全基本要求》等一批大模型国家标准。

"智能时代"进副题、治理框架一年一版——信号很明确：AI安全已是国家级议题，且规则进入年度迭代节奏。

笔者之前写过一篇《技术架构设计》，讲了战略层三原则（合适、简单、演化）和战术层打法（高并发、高可用、业务设计）。网安周这几天重读旧文，发现一件有意思的事：

把这三条原则放到安全语境下重新推导一遍，结论几乎可以原文照搬。本文做一次完整的安全化重读，并在最后结合OWASP清单与刚发布的框架3.0，补上大模型接入带来的新增风险面与合规基线的架构落点——这部分是2021年写原文时不存在的。

一、战略层：三原则的安全重读

1.1 合适原则：威胁建模优先于安全产品堆砌

原文说：技术选型没有最新，只有最合适，适合优于业界领先。论据是"没有那么多人，却想干那么多活"——十几人的团队抽调人研究新技术框架，项目必延期。

安全建设的翻车姿势一模一样：设备买了一屋子，但没人回答三个基本问题：

- 核心资产是什么（数据、服务、凭证）？

- 攻击面在哪（入口、依赖、人员）？

- 各风险的概率和影响如何排序？

这三个问题就是威胁建模（Threat Modeling）——方法不重要，先做才重要。跳过威胁建模直接买设备，等于跳过需求分析直接写代码。

安全侧合适原则：防护强度与资产价值对齐。用户头像泄露和支付凭证泄露，不该享受同级防护预算；内网管理后台和公网API网关，威胁模型完全不同。

1.2 简单原则：攻击面最小化

原文的概率计算值得每年重读一遍：单组件故障率1%时，2组件系统可用性98%，5组件掉到95%。组件越多越不稳定，且改动传播像多米诺。

安全视角下这个计算更加残酷——可用性是乘法衰减，攻击面是加法扩张：

- 每引入一个组件，就多一组CVE待披露、一个管理台待加固、一份默认配置待检查；

- 每新增一条服务间链路，就多一条横向移动路径；

- 组件间关系越复杂，零信任的网络策略越难落地。

原文讲的逻辑复杂性（把淘宝塞进一个组件：几十个分支、几百人维护、改一行影响全局）在安全上的对应物是：代码复杂度直接决定审计成本。分支越多、路径越绕，SAST扫不出的问题就越多，人工review就成了走过场。

工程结论：

- 能不引入的依赖就不引入，引入前查一遍它的CVE历史和维护活跃度；

- 暴露面做减法：管理台不进公网、调试接口生产禁用、未使用端口一律关闭；

- 这就是安全领域的大道至简：攻击面最小化（Attack Surface Reduction）。

1.3 演化原则：安全是过程，不是状态

原文说：软件与建筑的本质差异是"建筑永恒、软件变化"，试图一步到位设计终极架构的，最后都落不了地。

安全是这条原则最极端的体现：漏洞是持续被发现的，今天的"安全系统"只是"还没被测出漏洞的系统"；攻击手法在演化，合规标准也在逐年加码，防守机制必须同步演化。

所以安全侧的演化原则落地为节奏机制：定期渗透测试、依赖CVE跟踪、应急响应演练，三者必须进入迭代日历，而不是等出事再做。

AI把演化周期又压缩了一个量级：攻击工具的迭代速度从年变成了月。防御方的演化速度，第一次成为生存指标。

二、战术层：你已有的架构战术，半个是安全机制

重读原文战术层，会发现大量打法本质上就是安全机制，只是当年没按安全的名义记账：

限流：原文目的写的就是"防止恶意请求攻击或超过系统峰值"——Nginx limit、网关QPS配额、恶意IP deny，这就是抗DDoS/抗撞库的第一道防线。安全注脚：限流阈值要按"正常峰值×冗余系数"设定，并在压测中验证。

降级：原文讲降级开关集中管理、开关前置化（Nginx+Lua做灰度引流）、高并发时保核心砍次要。攻击场景下这就是应急响应预案：核心交易保住，推荐、评论这类非核心功能先降。安全注脚：降级开关本身要有鉴权和审计——它是最不该被攻击者拿到手的开关。

可回滚：原文要求"发布版本失败时可随时快速回退"。勒索攻击、数据投毒之后的最后防线就是回滚：版本可回滚+数据可恢复。安全注脚：备份要离线、要异地、要定期演练恢复——只备份不验证恢复，等于没备份。

防重与幂等：防的就是重放攻击，支付场景的幂等设计就是抗重复提交攻击。

后台审批化：原文讲后台系统操作可反馈、审批化——这就是最小权限+双人复核+操作审计的朴素实现。

工程结论：架构安全的正确姿势不是另起炉灶，是在每个既有战术决策点上补一个安全问句："这一层，攻击者怎么打？"这就是安全左移（Shift Left）在架构设计阶段的落法。

三、新增量：大模型接入后的四个新风险面

以上是旧原则的新读法。真正的增量，是原文写作时不存在的攻击面：大模型接入企业系统后，"输入不可信"的边界从HTTP请求扩展到了自然语言。

OWASP已为大模型应用专门发布风险清单（GenAI LLM Applications Top 10，2025版），结合工程实践，架构师最该关注这四条：

LLM01 提示注入（Prompt Injection）：攻击者用自然语言让模型偏离系统指令——泄露上下文里的内部数据、调用不该调的工具。传统注入防的是把数据当代码执行，提示注入防的是把数据当指令执行。架构对策：系统指令与用户输入严格分层、工具调用前做二次校验、输出过内容网关。

敏感信息泄露：员工把代码、客户数据喂给公开模型即构成泄露事件。架构对策：企业内网代理统一的LLM网关，出网请求先脱敏；明确分级数据禁入外部模型的清单。

过度代理（Excessive Agency）：给Agent的权限过大——能查库、能发邮件、能改配置。一旦被提示注入劫持，Agent就是权限最高的内鬼。架构对策：最小权限+人在回路（Human-in-the-loop），高危操作必须人工确认。给AI的权限应该像给实习生：默认不信，逐项授权。

供应链风险：开源模型、Agent框架、插件市场都可能是投毒点。架构对策：引入前审查来源与社区活跃度，模型文件做哈希校验，供应链依赖登记造册（可参考OWASP AIBOM做法）。

这四条对架构的冲击是同一个方向：信任边界必须重画——从"人与系统、系统与系统"之间，扩展到"人与AI、AI与系统"之间，且AI默认处于不可信区。

框架3.0与配套国标同时给出了国内的对齐基线，且直接指向架构设计：

基线一：服务供给合规。基于第三方模型提供服务，须使用已备案的基础模型并对每次对话做安全检测（截至2026年7月底全国已备案1028款）。架构落点：模型接入统一走LLM网关，做备案模型白名单+对话级检测——与上文"统一LLM网关出网"的防泄露设计是同一个组件，一石二鸟。

基线二：训练数据合规。语料来源留痕、针对31种安全风险制定标注规则、人工抽检、隔离存储。架构落点：RAG/微调数据管线内置来源登记与标注审计——"模型怎么喂大的"要查得出来，这对数据管道可观测性提出了新要求。

基线三：场景适配合规。关键信息基础设施、医疗、金融等高敏场景须有适配防护，涉未成年人需防沉迷设计。架构落点：数据不能出域的场景优先本地化部署；高危操作人工确认+全链路留痕——与前文"最小权限+人在回路"完全同构。

最后一个判例值得所有架构师记住：消费者依据电商AI客服答复下单后"货不对板"，企业被判担全责——对外提供服务的主体是企业，模型只是工具。AI出口的内容必须像系统出口一样过内容安全网关，责任不因"模型说的"而转移。

四、总结

回到原文结尾那个问题：好的软件架构是规划还是演化出来的？原文的回答是"好的架构是设计出来的，但缺少规划难于演化"。

安全的回答更进一步：安全是演化出来的，且永远演化不完。

三句话带走：

- 安全方案，合适优于堆砌——先威胁建模，再谈防护强度；

- 系统设计，简单就是防御——攻击面最小化，每多一个组件多一扇门；

- 安全能力，演化才能生存——把渗透测试、CVE跟踪、恢复演练写进迭代日历。

智能时代，网安护航。对架构师而言，护航的起点，是下一张架构图上多画的那几条信任边界。

参考来源

1. 中央网络安全和信息化委员会办公室、新华网：2026年国家网络安全宣传周于9月14日至20日举办，主题"网络安全为人民，网络安全靠人民——智能时代 网安护航"

2.  CSDN博客《技术架构设计》（作者Agan说架构，2021年发布）：战略层三原则、战术层高并发高可用打法、组件可用性概率计算均整理自此