Security Architect

安全架构师

概述

Security Architect 是一项整合型技能，涵盖完整的安全生命周期：威胁建模、安全设计原则、安全编码实践和法规合规。它确保从一开始就将安全融入其中，而不是到最后才补上。

整合自：

• threat-modeling - STRIDE 威胁分析和风险评估
• security-first-design - 安全原则和安全设计模式
• secure-coding-review - OWASP Top 10 和漏洞检测
• compliance-validator - GDPR、HIPAA、SOC2、PCI-DSS 合规

何时使用此技能

以下情况可使用 Security Architect：

• 启动新项目（设计阶段）
• 开展安全架构审查
• 审查代码中的安全漏洞
• 确保符合法规要求
• 响应安全事件
• 规划安全认证（SOC2、ISO 27001）
• 设计身份验证和授权系统

核心能力

威胁建模（来自 threat-modeling）

• 使用 STRIDE 方法识别威胁
• 评估风险级别（可能性 × 影响）
• 创建威胁模型和缓解计划
• 识别攻击面和信任边界

安全设计（来自 security-first-design）

• 运用安全原则（纵深防御、最小权限、零信任）
• 设计安全的身份验证和授权机制
• 实施加密和密钥管理
• 设计安全的 API 和数据保护机制

安全编码（来自 secure-coding-review）

• 根据 OWASP Top 10 审查代码
• 检测注入漏洞（SQL、XSS、命令注入）
• 识别身份验证和访问控制失效问题
• 确保安全地处理和验证数据

合规（来自 compliance-validator）

• 确保符合 GDPR、HIPAA、CCPA、SOC2、PCI-DSS
• 落实数据主体权利（访问、删除、可携带性）
• 设计审计日志和保留策略
• 配置加密和访问控制

工作流

第 1 部分：威胁建模（STRIDE）

STRIDE 框架

S - 欺骗（身份验证）

• **威胁：**攻击者冒充用户或系统
• 示例：
  • 凭据被盗
  • 会话劫持
  • 身份验证薄弱或缺失
• 缓解措施：
  • 多因素身份验证（MFA）
  • 强密码策略
  • 采用短过期时间的 JWT
  • 安全的会话管理

T - 篡改（完整性）

• **威胁：**攻击者修改数据或代码
• 示例：
  • SQL 注入
  • 中间人攻击
  • 参数操纵
  • 代码注入
• 缓解措施：
  • 输入验证与清理
  • 全面使用 HTTPS/TLS
  • 签名令牌（JWT）
  • 完整性检查（哈希）

R - 抵赖（可追责性）

• **威胁：**用户否认执行过某项操作
• 示例：
  • 没有审计日志
  • 未签名的交易
  • 匿名操作
• 缓解措施：
  • 全面的审计日志记录
  • 为交易添加数字签名
  • 不可变的日志存储
  • 跟踪用户操作

I - 信息泄露（机密性）

• **威胁：**敏感数据暴露给未经授权的对象
• 示例：
  • API 密钥泄露
  • 数据库转储
  • 过于详细的错误消息
  • 访问控制不足
• 缓解措施：
  • 对静态数据和传输中的数据进行加密
  • 最小权限原则
  • 安全的密钥管理（AWS Secrets Manager、Vault）
  • 基于角色的访问控制（RBAC）

D - 拒绝服务（可用性）

• **威胁：**合法用户无法使用系统
• 示例：
  • DDoS 攻击
  • 资源耗尽
  • 未处理的异常
• 缓解措施：
  • 速率限制和流量限制
  • 输入验证（拒绝超大负载）
  • 自动扩展基础设施
  • CDN 和 DDoS 防护（Cloudflare）

E - 权限提升（授权）

• **威胁：**用户获得未经授权的更高权限
• 示例：
  • 访问控制失效
  • 不安全的直接对象引用（IDOR）
  • 缺少授权检查
• 缓解措施：
  • 对每个请求进行授权检查
  • 最小权限原则
  • 基于属性的访问控制（ABAC）
  • 定期审查权限

---

威胁建模流程

第 1 步：识别资产

• 用户数据（PII、密码、财务信息）
• 业务数据（IP、客户名单、交易）
• 系统凭据（API 密钥、证书）
• 基础设施（服务器、数据库、API）

第 2 步：识别信任边界

• 用户 ↔ Web 应用
• Web 应用 ↔ API
• API ↔ 数据库
• 内部服务 ↔ 外部 API
• 管理员 ↔ 生产系统

第 3 步：对每个边界应用 STRIDE 针对每个边界，提出以下问题：

• **S：**攻击者能否冒充身份？
• **T：**数据能否被篡改？
• **R：**操作能否被抵赖？
• **I：**信息能否被泄露？
• **D：**服务能否遭到拒绝？
• **E：**权限能否被提升？

第 4 步：评估风险

Risk = Likelihood × Impact

Likelihood:
- High (likely to occur)
- Medium (may occur)
- Low (unlikely to occur)

Impact:
- Critical (data breach, financial loss, legal liability)
- High (significant damage, downtime)
- Medium (limited damage, temporary disruption)
- Low (minimal impact)

Risk Level:
- Critical: Immediate action required
- High: Address before launch
- Medium: Address post-launch
- Low: Monitor, may accept risk

第 5 步：制定缓解措施 针对每项威胁，记录：

• 缓解策略
• 实施工作量（低、中、高）
• 缓解后的剩余风险
• 负责人和时间表

---

第 2 部分：安全优先设计

安全原则

1. 深度防御 采用多层安全控制。即使一层失效，其他层仍可提供保护。

示例：

• 第 1 层：防火墙
• 第 2 层：身份验证
• 第 3 层：授权
• 第 4 层：加密
• 第 5 层：审计日志

2. 最小权限 用户/系统仅拥有所需的最低权限。

示例：

• 报告服务使用只读数据库凭据
• 用户只能查看自己的数据
• 管理员访问需要 MFA + 有时限的令牌

3. 零信任 永不信任，始终验证。即使是内部网络也不可信。

示例：

• 对每个请求进行身份验证和授权
• 不存在“可信”的内部网络
• 加密内部流量
• 始终假设系统可能已遭入侵

4. 默认安全 默认配置是安全的。用户必须主动选择安全性较低的选项。

示例：

• 默认强制使用 HTTPS
• 默认采用严格的密码策略
• 注册时建议启用 MFA
• 安全 Cookie（HttpOnly、Secure、SameSite）

5. 安全地失败 发生错误时，以不会危及安全的方式失败。

示例：

• 出错时拒绝访问（而不是授予访问权限）
• 记录错误，但不向用户暴露详细信息
• 平稳降级，同时不暴露内部信息

---

安全设计模式

身份验证：

• 模式： OAuth 2.0 + OpenID Connect（OIDC）
• 实现：
  • 使用 Auth0、AWS Cognito 或 Okta（不要自行构建）
  • 使用有效期较短的 JWT 令牌（访问令牌 15 min，刷新令牌 7 day）
  • 安全存储令牌（HttpOnly Cookie 或安全的本地存储）
  • 对敏感操作启用 MFA

授权：

• 模式： 基于角色的访问控制（RBAC）或基于属性的访问控制（ABAC）
• 实现：
  • 定义角色：admin、user、viewer
  • 对每个 API 请求检查授权
  • 使用中间件：@requireRole('admin')
  • 实施 IDOR 防护（验证所有权）

数据保护：

• 模式： 对静态数据和传输中的数据进行加密
• 实现：
  • 对所有外部流量使用 TLS 1.3
  • 对静态数据使用 AES-256 加密
  • 使用密钥管理服务（AWS KMS、Google Cloud KMS）
  • 加密 PII 字段（电子邮件、SSN、信用卡）

API 安全：

• 模式： 速率限制 + 身份验证 + 输入验证
• 实现：
  • 速率限制：每位用户每分钟 100 个请求
  • 服务器到服务器的通信使用 API 密钥
  • 用户到服务器的通信使用 OAuth 令牌
  • 验证所有输入（类型、长度、格式）
  • 将允许的值列入白名单

机密管理：

• 模式： 切勿提交机密信息，使用机密管理器
• 实现：
  • AWS Secrets Manager 或 HashiCorp Vault
  • 使用环境变量存储配置（切勿写入代码）
  • 定期轮换机密信息（90 days）
  • 使用 IAM 角色（而不是长期有效的凭据）

---

第 3 部分：安全编码审查（OWASP Top 10）

OWASP Top 10（2021）

A01：访问控制失效

• 风险： 用户访问其无权访问的数据或功能
• 示例：
  • 篡改 URL：/user/123 → /user/456
  • 缺少授权检查
  • 不安全的直接对象引用（IDOR）

检测方法：

// BAD: No authorization check
app.get('/api/users/:id', (req, res) => {
  const user = db.users.findById(req.params.id)
  res.json(user) // Anyone can see any user!
})

// GOOD: Check ownership
app.get('/api/users/:id', authMiddleware, (req, res) => {
  const requestedId = req.params.id
  const currentUserId = req.user.id

  if (requestedId !== currentUserId && !req.user.isAdmin) {
    return res.status(403).json({ error: 'Forbidden' })
  }

  const user = db.users.findById(requestedId)
  res.json(user)
})

---

A02：加密机制失效

• 风险： 由于加密薄弱或缺失，敏感数据遭到泄露
• 示例：
  • 数据库中存储明文密码
  • 使用 HTTP 而非 HTTPS
  • 哈希算法薄弱（MD5、SHA1）

检测方法：

// BAD: Plaintext password
const user = { email, password: req.body.password }
db.users.create(user)

// GOOD: Hash with bcrypt
const bcrypt = require('bcrypt')
const hashedPassword = await bcrypt.hash(req.body.password, 10)
const user = { email, password: hashedPassword }
db.users.create(user)

---

A03：注入

• 风险： 攻击者注入恶意代码（SQL、XSS、命令）
• 示例：
  • SQL 注入
  • 跨站脚本攻击（XSS）
  • 命令注入

检测方法：

// BAD: SQL Injection
const query = `SELECT * FROM users WHERE email = '${req.body.email}'`
db.query(query) // Attacker can send: ' OR '1'='1

// GOOD: Parameterized query
const query = 'SELECT * FROM users WHERE email = ?'
db.query(query, [req.body.email])

// BAD: XSS
;<div dangerouslySetInnerHTML={{ __html: userInput }} />

// GOOD: Escape user input
import DOMPurify from 'dompurify'
const sanitized = DOMPurify.sanitize(userInput)
;<div dangerouslySetInnerHTML={{ __html: sanitized }} />

---

A04：不安全设计

• 风险： 架构存在缺陷或缺少安全控制
• 示例：
  • 未设置速率限制
  • 缺少威胁建模
  • 没有安全要求

检测方法：

• 检查架构图
• 检查是否设置了速率限制、身份验证和授权
• 确认是否存在威胁模型

---

A05：安全配置错误

• 风险： 使用默认配置、错误信息过于详细、启用了不必要的功能
• 示例：
  • 默认管理员密码
  • 启用了目录列表
  • 在生产环境中显示堆栈跟踪

检测方法：

// BAD: Exposes stack trace
app.use((err, req, res, next) => {
  res.status(500).json({ error: err.stack })
})

// GOOD: Generic error message
app.use((err, req, res, next) => {
  logger.error(err)
  res.status(500).json({ error: 'Internal server error' })
})

---

A06-A10：其他关键问题

• A06： 易受攻击和过时的组件（使用 npm audit、Dependabot）
• A07： 身份识别和身份验证失效（密码薄弱、未启用 MFA）
• A08： 软件和数据完整性失效（供应链攻击）
• A09： 安全日志记录和监控失效（没有审计日志）
• A10： 服务器端请求伪造（SSRF）（验证 URL）

---

第 4 部分：合规性验证

监管框架

GDPR（通用数据保护条例）

• 适用范围： 欧盟数据主体
• 主要要求：
  • 处理数据的合法依据（同意、合同、合法利益）
  • 数据主体权利（访问、更正、删除、可携带）
  • 通过设计保护隐私并默认保护隐私
  • 数据泄露通知（72 小时内）
  • 对高风险数据处理进行数据保护影响评估（DPIA）

实施清单：

• 设置数据收集的同意机制
• 建立数据主体访问请求（DSAR）流程
• 实现删除权（“被遗忘权”）
• 提供数据可携带性导出（JSON/CSV）
• 制定隐私政策并设置 Cookie 横幅
• 与供应商签订数据处理协议（DPA）
• 建立数据泄露通知流程

---

HIPAA（健康保险流通与责任法案）

• 适用范围： 美国的医疗保健数据
• 主要要求：
  • 必须加密受保护的健康信息（PHI）
  • 访问控制和审计日志
  • 商业伙伴协议（BAA）
  • 数据泄露通知

实施清单：

• 对静态 PHI 使用 AES-256 加密，对传输中的 PHI 使用 TLS 1.3 加密
• 对 PHI 实施基于角色的访问控制
• 记录所有 PHI 访问的审计日志
• 与云服务提供商（AWS、Azure）签订 BAA
• 建立数据泄露通知流程
• 定期进行安全风险评估

---

SOC 2（服务组织控制 2）

• 适用范围： 处理客户数据的 SaaS 公司
• 主要要求：
  • 信任服务标准（安全性、可用性、机密性）
  • 访问控制和监控
  • 变更管理
  • 事件响应

实施清单：

• 记录安全策略
• 对员工进行背景调查
• 强制使用多因素身份验证（MFA）
• 对静态数据和传输中的数据进行加密
• 审计日志记录和监控
• 制定事件响应计划
• 建立供应商管理计划
• 定期开展安全培训

---

PCI-DSS（支付卡行业数据安全标准）

• 适用范围： 处理信用卡数据的组织
• 主要要求：
  • 绝不存储 CVV/CVC 代码
  • 加密持卡人数据
  • 定期更新和修补系统
  • 限制对持卡人数据的访问

实施清单：

• 使用支付处理服务（Stripe、Braintree）——不要自行存储卡片信息
• 如需存储卡片信息，请使用令牌化
• 使用符合 PCI 标准的托管服务（通过 Level 1 认证）
• 进行网络分段（隔离持卡人数据）
• 开展漏洞扫描和渗透测试
• 实施严格的访问控制

---

示例

示例 1：SaaS 应用的威胁模型

应用： 项目管理 SaaS

资产：

• 用户凭证（电子邮件、密码）
• 项目数据（文档、任务、评论）
• 支付信息（通过 Stripe）
• 集成所用的 API 密钥

信任边界：

1. 用户浏览器 ↔ Web 应用（HTTPS）
2. Web 应用 ↔ API 服务端（内部 TLS）
3. API 服务端 ↔ 数据库（加密连接）
4. API 服务端 ↔ Stripe API（HTTPS）

边界 1（用户 ↔ Web 应用）的 STRIDE 分析：

威胁	风险	缓解措施
S： 凭证盗窃	高	MFA、密码哈希（bcrypt）
T： 会话劫持	中	HttpOnly Cookie、SameSite、CSRF 令牌
R： 否认操作	低	记录所有用户操作的审计日志
I： 通过 XSS 泄露数据	高	内容安全策略、输入清理
D： 暴力破解登录	中	速率限制（每分钟尝试 5 次）
E： 账户接管	高	电子邮件验证、MFA

优先缓解措施：

1. 实施 MFA（高风险、高影响）
2. 添加速率限制（中风险、易于修复）
3. 启用 CSP 响应头（高风险、易于修复）

---

示例 2：安全代码审查发现

代码审查： 用户身份验证端点

发现：

严重：SQL 注入（A03）

// Current code (VULNERABLE):
const query = `SELECT * FROM users WHERE email = '${email}' AND password = '${password}'`

// Recommended fix:
const query = 'SELECT * FROM users WHERE email = ? AND password_hash = ?'
const hashedPassword = bcrypt.hashSync(password, user.salt)
db.query(query, [email, hashedPassword])

高危：明文密码（A02）

// Current code (VULNERABLE):
db.users.create({ email, password })

// Recommended fix:
const hashedPassword = await bcrypt.hash(password, 10)
db.users.create({ email, password: hashedPassword })

中危：未设置速率限制（A04）

// Recommended fix:
const rateLimit = require('express-rate-limit')
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5 // 5 attempts
})
app.post('/login', loginLimiter, loginHandler)

操作： 部署前修复严重和高危问题。上线后再处理中危问题。

---

示例 3：GDPR 合规性实施

要求： 落实数据主体权利

实施：

1. 访问权（DSAR）

app.get('/api/user/data-export', authMiddleware, async (req, res) => {
  const userId = req.user.id

  const userData = {
    profile: await db.users.findById(userId),
    projects: await db.projects.findByUser(userId),
    comments: await db.comments.findByUser(userId),
    activity: await db.activityLog.findByUser(userId)
  }

  res.setHeader('Content-Type', 'application/json')
  res.setHeader('Content-Disposition', 'attachment; filename=my-data.json')
  res.json(userData)
})

2. 删除权

app.delete('/api/user/account', authMiddleware, async (req, res) => {
  const userId = req.user.id

  // Anonymize instead of delete (retain for legal compliance)
  await db.users.update(userId, {
    email: `deleted-${userId}@example.com`,
    name: 'Deleted User',
    deleted_at: new Date()
  })

  // Delete PII
  await db.sessions.deleteByUser(userId)
  await db.notifications.deleteByUser(userId)

  res.json({ message: 'Account deleted successfully' })
})

3. 同意管理

const user = {
  email,
  marketing_consent: req.body.marketingConsent || false,
  analytics_consent: req.body.analyticsConsent || false,
  consent_date: new Date()
}

---

最佳实践

威胁建模

1. 尽早建模 - 在设计阶段进行，而不是开发完成后
2. 定期更新 - 架构变更时更新
3. 聚焦高风险威胁 - 不要追求 100% 覆盖
4. 记录缓解措施 - 不要只记录威胁

安全设计

1. 采用经过验证的方案 - 不要自行实现加密算法
2. 纵深防御 - 采用多层安全防护
3. 默认安全 - 选择降低安全性的操作时需要主动启用，而不是默认启用
4. 假设已遭入侵 - 按照“何时发生”而非“是否发生”的思路进行设计

安全编码

1. 自动化安全扫描 - 在 CI/CD 中使用 SAST、DAST、SCA
2. 验证所有输入 - 不要信任用户提供的任何内容
3. 使用安全库 - OWASP、helmet.js、DOMPurify
4. 保持依赖项更新 - 使用 Dependabot 进行监控

合规

1. 了解适用范围 - 明确哪些法规适用于你
2. 记录所有内容 - 政策、流程和决策
3. 定期审计 - 内部与外部审查
4. 与法务合作 - 不要独自解读法规

---

常见陷阱

1. 事后才考虑安全

反模式： 先构建，之后再加固安全 结果： 后期改造成本高，生产环境存在漏洞

更好的做法： 从设计阶段开始融入安全

2. 信任客户端验证

反模式： 只在前端验证 结果： 攻击者可以用 curl 绕过验证

更好的做法： 始终在后端进行验证

3. 自行实现加密算法

反模式： 使用自定义加密或哈希 结果： 加密强度不足，存在漏洞

更好的做法： 使用经过验证的库（bcrypt、libsodium）

4. 过度依赖合规性

反模式： “我们符合规范，所以我们很安全” 结果： 符合规范，但并不安全

更好的做法： 合规是最低要求；安全需要持续维护

5. 忽视低风险威胁

反模式： 只修复严重问题 结果： 千里之堤，溃于蚁穴

更好的做法： 系统地处理所有严重级别的问题

---

相关技能

• quality-assurance - 安全测试与验证关卡
• api-designer - API 安全模式
• deployment-advisor - 基础设施安全
• framework-orchestrator - 阶段关卡中的安全要求
• data-engineer - 数据安全与隐私

---

交付成果

使用 Security Architect 时，请产出：

1. 威胁模型

   • 资产清单
   • 信任边界
   • STRIDE 分析
   • 风险评估
   • 缓解计划

2. 安全架构文档

   • 身份验证/授权设计
   • 加密策略
   • 密钥管理
   • 标注安全控制措施的网络图

3. 安全代码审查报告

   • OWASP Top 10 发现
   • 严重程度评级
   • 修复建议
   • 重新测试结果

4. 合规性检查清单

   • 适用法规
   • 实施状态
   • 差距分析
   • 修复计划

---

成功指标

在以下情况下，Security Architect 可发挥作用：

• 在开发前完成威胁建模
• 生产环境中严重漏洞数量为零
• 每年安全事件少于 1 起
• 通过合规性审计
• 在 CI/CD 中强制执行安全关卡
• 团队遵循安全编码实践
• 定期完成安全培训

---

请记住： 安全不是一项功能，而是基础。应从一开始就将安全融入其中。