Security Architecture集成设计实战 - 第1节

一、安全架构是什么？——先说清楚定义

很多人问我，安全架构到底在做什么？说实话，答案没你想得那么玄乎。

安全架构，就是一套结构化的方法。它用来定义安全策略、安全组件和它们之间的交互关系。说白了，它回答三个问题：

• 要保护什么？——关键数据、核心业务、基础设施
• 怎么保护？——加密、访问控制、监控审计
• 出事后怎么办？——应急响应、恢复、改进

我个人习惯把安全架构比作一张城市的防御地图。你想想看，一座城市不会只在城门口放两个卫兵了事。它得有城墙、护城河、巡逻队、警报系统。安全架构就是帮你画这张地图的。

二、安全架构的核心目标

安全架构要达成的目标，业内公认有三大块。嗯，这里我直接给出来：

目标维度	具体含义	我在项目中的常见误区
机密性	数据只能被授权者读取	以为AES加密就万事大吉，忽略了密钥管理的风险
完整性	数据在传输和存储中不被篡改	只做传输层校验，忘了做数据库级别的完整性检查
可用性	系统和数据在需要时可用	过分强调安全导致正常业务不可用，这是典型的本末倒置

除了CIA三元组，还得加上几个我认为同样重要的：

• 可追溯性：谁、在什么时候、做了什么操作，一清二楚。这是审计的根本。
• 可控性：安全策略你说了算，不是安全厂商说了算。
• 合规性：满足相关法律法规和行业标准。这个不能绕。

三、设计原则——这些是底线

原则这东西，听起来像空话。但我在项目里被坑过好几次，才真正理解它们的重量。下面几个原则，我觉得可以当作你的安全意识检查清单。

3.1 纵深防御

别把鸡蛋放在一个篮子里。你想想看，一个门锁能防住大多数小偷，但专业开锁匠几秒钟就搞定。所以，我们需要多层防护。

我之前做过一个电商平台的安全设计。在支付环节，我们做了四层防护：

1. WAF 拦截常见的 Web 攻击
2. API 网关做参数校验和频率限制
3. 业务逻辑层做风控（识别异常交易）
4. 数据库层做敏感数据加密

我记得第一次做多层级防护时，客户嫌麻烦，觉得“有WAF就够了”。结果一个月后，攻击者绕过了WAF，直接对API进行重放攻击。从那以后，他主动找我要加强纵深防御。

3.2 最小权限

这个原则听起来简单——只给完成任务所需的最小权限。但实施起来，难上加难。

我曾经在一个金融项目里做权限梳理。结果发现，运维人员竟然有DBA的权限，可以直连数据库。这个权限能让他看到所有客户的交易记录。所幸当时没出事，我赶紧建议他们做了细粒度的权限拆分。

最小权限的实施要点：

• 账号要细粒度：别搞什么超级管理员一统天下。
• 权限要按时效：临时任务结束后，权限自动回收。这个叫JIT（Just-In-Time）访问。
• 定期审计：我建议每季度至少过一次权限清单，看谁有不该有的权限。

3.3 默认安全

系统部署上线时，默认配置就应该是安全的，而不是等出问题了再加固。我见过太多系统，“先上线再说，安全以后慢慢加固”——结果呢？

• 默认密码没改，直接被扫爆。
• debug模式没关，暴露了源码。
• 不必要的服务开着，成了入侵跳板。

所以，我建议在架构设计阶段，就把“默认安全”写进需求文档。这会帮你省下大笔后续成本。

3.4 安全迭代

安全不是一锤子买卖。你想想看，业务在变，攻击技术在变，安全设计也得跟着变。我习惯用“安全需求 backlog”来管理迭代。每个迭代都留出10%-20%的时间来处理安全问题。

四、常见安全架构框架

框架是你做安全设计的模板。有了模板，你不用从零开始推演。这里介绍两个最常见的。

框架	全称	核心思想	适用场景
SABSA	Sherwood Applied Business Security Architecture	从业务出发，逐层推导安全需求，有专门的“生命周期”矩阵和“分层抽象”模型	适合大型企业、需要跟业务对齐安全的组织
TOGAF	The Open Group Architecture Framework	企业架构方法论，有专门的“安全架构”视角和“安全架构原则”集	适合需要统一企业架构管理的组织

SABSA——从业务看安全

SABSA 最酷的一点，是它把安全和业务深度绑定。它把安全架构分成六层：

1. 上下文安全：识别业务目标和风险
2. 概念安全：制定安全愿景和策略
3. 逻辑安全：定义安全服务和服务交互
4. 物理安全：具体技术和组件
5. 组件安全：配置、编码、实现细节
6. 运营安全：持续管理、监控、改进

我建议你在做To-B业务时，优先学SABSA。因为它能让你在跟业务部门开会时，不只说技术，而是讲业务风险怎么解决。这能帮你拿到更多资源。

TOGAF——从企业架构看安全

TOGAF 更适合大型组织。它有一个专门的“安全架构”工作包，教你如何在企业架构中加入安全视角。

TOGAF 的 ADM（架构开发方法）有明确的阶段：

• 准备阶段：设定安全原则
• 架构愿景：安全如何支撑业务目标
• 业务架构：安全流程和职责
• 信息系统架构：安全组件（IAM、加密、日志等）
• 技术架构：安全基础设施（防火墙、WAF、SIEM）
• 迁移规划：怎么安全地过渡到新架构

我个人觉得，TOGAF 对安全架构师的要求更高——你得同时懂企业架构和安全。但它的产出更全面，适合做全局设计。

五、本章核心结构图

下面这张图，我习惯叫它“安全架构师的核心视图”。它帮你快速理解安全架构的构成要素和关联关系。

这张图你每做一次安全架构设计，都可以拿出来对一下。哪个要素没顾上？哪个关系没理清？它就是你的检查清单。

六、一点总结，也是想让你记住的

这一章，我们把安全架构的根扎稳了：

• 定义——它是结构化方法，不是工具清单。
• 目标——CIA + 可控 + 可追溯 + 合规。
• 原则——纵深防御、最小权限、默认安全、安全迭代。这四个原则，按优先级从上到下。
• 框架——SABSA 从业务出发，TOGAF 从企业架构出发。选哪个，看你的组织背景。

说到底，安全架构是一场与风险共舞的工程实践。你有地图（框架），有工具（组件），有原则（设计原则），剩下的是经验和判断。

我记得刚入行时，觉得安全就是堆设备。后来做了三五个项目，踩过坑、改过方案、被审计review过好几次，才真正理解“架构”二字的分量。希望这一章能帮你少走一些弯路。