技术架构与安全架构：核心要素及设计方法

技术架构与安全架构共同构成企业信息系统稳定运行的重要基础。技术架构回答系统依托什么技术能力、组件和基础设施运行，以及这些资源如何部署和协同；安全架构则回答哪些架构对象需要保护、面临哪些安全风险、需要遵循哪些安全要求，以及通过什么控制措施降低风险。两者并不是相互独立的设计工作，而应从需求分析、方案设计、部署实施到运行治理全过程协同开展。

随着大模型、智能体、异构算力和MLOps等技术进入企业信息系统，技术架构的设计对象和运行方式也在发生变化。传统计算、存储、网络和中间件之外，需要进一步考虑AI算力、模型服务、智能体运行环境和云边端协同等新型技术能力，并同步考虑由此产生的模型、数据、权限和供应链安全问题。

一、技术架构与安全架构分别解决什么问题

技术架构的核心任务，是将业务和应用提出的非功能需求转化为具体的技术实现体系。业务系统需要达到怎样的性能、可用性和扩展能力，需要哪些计算、存储、网络、数据库和中间件能力，采用哪些技术组件和技术平台，以及最终部署在哪里，都属于技术架构需要回答的问题。

因此，技术架构关注的不是某一项孤立技术，而是技术能力之间如何组合形成稳定的系统运行环境。一个完整的技术方案通常需要同时考虑性能、容量、高可用、弹性扩展、容灾恢复、可观测性以及技术生命周期等因素。

安全架构关注的重点则不同。安全架构首先需要识别需要保护的业务、应用、数据和技术资产，在此基础上划分安全域和安全边界，分析不同对象面临的威胁和风险，并形成相应的安全策略、控制措施和合规要求。

因此，两类架构的关系可以理解为：技术架构建立系统的运行基础，安全架构则围绕这些运行对象建立相应的安全边界和控制体系。技术方案发生变化时，相应的安全风险和控制要求也需要同步调整。

二、技术架构包含哪些核心要素

技术架构可以围绕技术分类、技术能力、技术组件、技术服务、技术平台和部署节点等对象展开。

技术分类用于对企业使用的技术进行统一归类，例如计算、存储、网络、数据库、中间件、容器、云平台和AI基础设施等；技术能力描述企业能够对上层应用提供什么样的技术支撑；技术组件是实现这些能力的具体技术单元；技术服务则是技术能力面向应用提供服务的方式；技术平台由多个相关组件和服务组合形成相对完整的运行环境；部署节点进一步说明这些技术对象实际运行的位置和部署关系。

这些对象之间需要建立明确关系。例如技术分类包含技术组件、技术组件实现相应技术能力、技术组件提供技术服务、技术组件部署于部署节点，应用系统使用相应技术服务，不同节点之间通过网络建立连接。

通过上述对象和关系，可以形成从“技术分类—技术能力—技术组件—技术服务—部署环境”逐步展开的技术架构，使技术选型、部署设计和运行管理建立在统一的架构模型之上，而不是简单形成一份产品和软硬件清单。

三、安全架构包含哪些核心要素

安全架构不宜简单按照安全产品或安全组件进行划分，而应围绕“保护什么、面临什么风险、如何进行控制”建立完整结构。

首先需要划分安全域和安全边界。安全域用于将具有相近安全等级、业务属性和访问要求的对象组织到相应安全区域，并明确不同安全域之间的数据访问、网络通信和信任关系。

其次需要建立安全策略和安全标准。安全策略明确企业在身份认证、访问控制、数据保护、网络隔离、日志审计、漏洞管理、监测响应等方面需要遵循的总体要求；安全标准进一步形成可以在项目建设和系统运行过程中执行、检查和验证的具体要求。

再次需要形成安全控制措施。安全控制措施是安全要求在具体架构对象上的落实，可以包括身份认证、权限控制、加密、网络隔离、安全审计、漏洞管理、异常监测和应急响应等。不同控制措施应明确适用对象、实施条件和验证方式。

在此基础上，再根据控制措施确定所需要的安全技术能力及具体实现组件。也就是说，安全组件是实现安全控制的技术载体，而不是安全架构设计的起点。例如身份认证平台可以实现身份认证相关控制，日志审计系统可以支撑审计控制，安全网关可以实现访问控制和流量防护。

因此，安全架构可以提取安全域、安全组件、安全服务、安全控制、合规要求等概念，但这些概念应形成清晰层次：安全域定义安全控制措施、安全策略、安全标准、安全角色，并明确相应的安全边界；安全策略和合规要求形成约束，安全控制措施明确需要落实的安全要求，安全服务和安全组件负责提供相应的技术实现能力。

在对象关系上，可以进一步明确安全组件提供安全服务、安全策略约束资源等，安全控制措施作用于业务、应用、数据或技术对象，合规要求则约束相应的安全策略和控制要求。通过这些关系，使安全要求最终能够追溯到具体的架构对象和实施措施。在形成上述安全架构对象及关系的基础上，还可以进一步形成安全域划分图、安全组件清单、安全服务清单、合规要求清单、安全策略文档等安全架构制品，为后续安全架构设计、评审和治理提供统一依据。

四、技术架构如何开展设计

技术架构设计首先从业务和应用需求出发，将性能、容量、可用性、扩展性、容灾恢复、安全和运维等要求转化为可度量的非功能需求。

在此基础上，根据企业技术标准和现有技术资产确定技术路线，选择相应的技术平台和技术组件，并进一步设计组件之间的依赖关系、部署位置、网络连接、服务调用和故障切换方式。

技术选型不能只考虑“能不能实现”，还需要综合考虑技术成熟度、性能容量、兼容性、生命周期、团队技术能力、建设与运维成本以及未来替换难度。对于企业已经形成统一平台能力的领域，应优先复用既有技术能力，避免不同项目重复引入功能相近的技术组件。

完成技术方案后，还需要通过容量评估、性能测试、故障演练和运行监测验证设计是否满足原有非功能需求，并根据实际运行结果持续调整技术架构。

五、安全架构如何开展设计

安全架构设计应与技术架构同步开展，而不是在技术方案完成后再附加安全产品。

设计首先识别需要保护的业务、应用、数据和技术资产，并结合资产的重要程度、数据敏感程度和业务影响分析安全风险。随后根据业务场景、网络环境和访问关系划分安全域及安全边界，明确不同区域之间允许发生什么样的访问和数据交换。

在此基础上，将安全策略和合规要求进一步转化为具体控制措施。例如对于敏感数据，需要明确访问权限、传输加密、存储保护和操作审计要求；对于重要应用，需要明确身份认证、最小权限、异常监测和应急处置要求；对于跨安全域访问，则需要明确访问路径、身份校验和边界防护措施。

最后再将控制要求映射到具体技术能力和组件，并明确实施主体和验证方法。这样形成的是“资产—风险—安全要求—控制措施—技术实现”的完整链路，能够避免安全架构退化为单纯的安全产品配置清单。

六、技术架构与安全架构如何协同

技术架构和安全架构的协同，核心是让每一个重要技术对象都有相应的安全要求，同时让每一项安全控制都能够找到具体的技术落点。

例如，技术平台需要对应平台安全基线和访问边界；技术组件需要明确身份认证、漏洞管理和配置安全要求；技术服务需要明确调用权限、接口防护和日志审计；部署节点则需要与安全域、网络隔离和信任边界建立对应关系。

当技术架构中的部署方式、网络关系或者技术组件发生变化时，需要同步分析安全边界和控制措施是否发生变化。反过来，安全要求也可能影响技术架构，例如数据不能跨越特定安全边界、关键业务必须实现容灾隔离或者特定操作必须保留审计记录，都可能影响系统最终的技术部署方案。

因此，技术与安全架构应形成共同设计、共同评审和共同变更的机制，而不是在两个相互独立的流程中分别开展。

图1 技术架构与安全架构协同关系

七、AI原生技术对技术架构提出了哪些新要求

大模型和智能体进入企业应用后，技术架构管理的对象开始从传统计算、存储、数据库和中间件进一步扩展到异构算力、模型服务、推理端点、MLOps流水线、知识管理组件和智能体运行环境。

一方面，AI工作负载对算力和部署方式提出新的要求。模型训练和推理可能同时使用CPU、GPU及其他异构算力，技术架构需要进一步考虑异构算力调度、资源弹性、模型推理性能以及云边端协同部署等问题。

另一方面，模型能力逐渐以服务方式被多个应用调用，因此需要加强模型服务治理。模型版本发生变化时，需要能够识别调用方和影响范围；模型服务出现性能异常时，需要能够监测调用链路、资源消耗和服务质量。

为适应这些变化，可以在现有技术架构制品中增加AI原生相关字段，如组件类型标注、是否支持AI推理、算力规格、部署形态、SLA要求、可观测性配置等，使AI相关技术资源能够纳入统一的架构资产体系进行管理。

同时，可以根据实际需要补充新的技术架构制品，如AI算力资源清单、MLOps流水线配置表、模型服务网关路由表、知识管理组件清单等。这些制品并不是独立于原有技术架构重新建立一套体系，而是对现有技术架构对象和制品的扩展。

在设计方法上，也需要进一步增加AI就绪和弹性优先等原则，并在原有技术架构设计过程中补充AI技术选型评估和架构决策，使AI基础设施建设与企业整体技术架构保持一致。

八、AI原生环境下安全架构需要关注什么

AI技术并没有改变安全架构“资产—风险—控制”的基本逻辑，但扩展了需要保护的对象和需要考虑的风险类型。

传统应用主要关注用户、应用、数据、接口和基础设施，而AI应用还需要关注训练数据、知识库、模型文件、提示词、模型服务、推理端点以及智能体可以调用的外部工具。特别是智能体能够进一步执行实际业务操作时，其身份、权限和动作范围需要纳入安全架构。

因此，AI安全设计需要在既有身份认证、权限控制、数据保护、日志审计和监测响应基础上，进一步考虑训练与推理数据保护、模型访问控制、提示词攻击防护、模型输出风险、智能体工具调用权限以及模型供应链等问题。

这些要求仍应按照安全架构原有方法落实到具体对象和控制措施中，而不是另外建设一套与企业安全体系割裂的“AI安全架构”。例如模型服务需要设置身份认证和访问控制，智能体调用高风险业务工具时需要限定操作权限，重要业务动作可以设置人工确认点，模型和智能体的关键操作需要保留审计记录。

图2 AI原生技术栈及贯穿式安全控制体系

九、如何推动技术与安全架构持续演进

技术架构和安全架构都不是一次性设计成果。技术版本升级、部署环境调整、业务规模变化以及AI技术引入，都可能使原有架构发生变化。

企业需要持续维护技术组件、技术服务、部署关系、安全域、安全策略和控制措施等架构资产，并将架构要求纳入项目设计、架构评审、测试验证和上线运行全过程。

对于AI相关技术资产，也需要持续维护算力资源、模型服务、MLOps流水线和知识管理组件等信息。当模型版本、推理服务、部署方式或智能体能力发生变化时，应同步开展技术影响和安全影响分析。

最终，技术架构解决的是企业数字化和智能化能力“依靠什么运行”的问题，安全架构解决的是这些能力“如何在可控风险下运行”的问题。只有把传统技术能力、AI原生技术能力与安全控制统一纳入企业架构体系，才能使技术架构既支撑当前系统稳定运行，也能够持续适应AI时代的技术演进。

参考来源

[1] The Open Group. TOGAF Standard, 10th Edition.

[2] ISO/IEC/IEEE 42010:2022. Systems and software engineering — Architecture description.

[3] 国家市场监督管理总局、国家标准化管理委员会. GB/T 22239—2019《信息安全技术 网络安全等级保护基本要求》.

[4] NIST. Cybersecurity Framework (CSF) 2.0.

[5] NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0).

[6] 国家互联网信息办公室等.《生成式人工智能服务管理暂行办法》.

[7] 全国人大常委会.《中华人民共和国网络安全法》.

[8] 全国人大常委会.《中华人民共和国数据安全法》.

[9] 全国人大常委会.《中华人民共和国个人信息保护法》.