安全

相关源文件

• docs/cs-basics/network/network-attack-means.md
• docs/java/concurrent/images/java-thread-pool-summary/relationship-between-thread-pool-parameters.png
• docs/system-design/security/advantages-and-disadvantages-of-jwt.md
• docs/system-design/security/basis-of-authority-certification.md
• docs/system-design/security/jwt-intro.md

本文档涵盖了系统设计中与安全相关的概念和机制，重点关注身份验证、授权和 Web 应用程序中常见的安全威胁。有关网络特定安全威胁和对策的信息，请参阅网络安全（计算机基础）。

认证与授权

身份验证和授权是安全的基本概念，它们经常被混淆，但在系统安全中扮演着不同的角色。

身份验证 vs. 授权

• 身份验证 (Authentication)：验证用户是谁。这涉及通过用户名/密码、令牌或生物识别等凭据来验证用户的身份。
• 授权 (Authorization)：确定已通过身份验证的用户被允许做什么。这会根据用户的权限或角色来控制对资源的访问。

身份验证示例

授权示例

来源： docs/system-design/security/basis-of-authority-certification.md8-30

RBAC 模型

基于角色的访问控制（RBAC）模型是系统权限管理中最常用的访问控制模型。

RBAC 创建了一个“用户-角色-权限”的授权模型，其中

• 用户被分配到角色
• 角色被授予权限
• 权限控制对资源的访问

这种方法通过将单独的权限抽象为角色，大大简化了权限管理。

RBAC 的典型数据库设计包括以下表

• 用户表
• 角色表
• 权限/资源表
• 用户-角色映射表
• 角色-权限映射表

来源： docs/system-design/security/basis-of-authority-certification.md32-53

认证机制

Session-Cookie 身份验证

在请求之间维护用户身份的传统方法是使用会话和 cookie。

工作原理

1. 用户将凭据（用户名、密码）发送到服务器
2. 服务器验证凭据并创建会话
3. 服务器通过 Cookie 将 SessionID 发送给客户端
4. 客户端在所有后续请求中都包含 SessionID Cookie
5. 服务器验证 SessionID 并检索相关的会话数据

Session-Cookie 在分布式系统中的挑战

• 当用户连接到不同的服务器节点时，需要共享会话信息
• 解决方案包括
  • 粘性会话（始终将用户路由到同一服务器）
  • 服务器之间的会话复制
  • 集中式会话存储（例如 Redis）
  • 使用 Spring Session 等专用工具

来源： docs/system-design/security/basis-of-authority-certification.md54-170

JWT 身份验证

JSON Web Token (JWT) 是一种流行的基于令牌的身份验证替代方案，它解决了基于会话的身份验证的一些限制。

JWT 结构

1. Header：包含关于令牌类型和签名算法的元数据

2. Payload：包含声明（关于用户和附加数据的陈述）

3. Signature：通过使用密钥对编码的 Header 和 Payload 进行签名而创建

   HMACSHA256(
     base64UrlEncode(header) + "." +
     base64UrlEncode(payload),
     secret)
   

来源： docs/system-design/security/jwt-intro.md10-127 docs/system-design/security/advantages-and-disadvantages-of-jwt.md15-52

JWT vs. Session 身份验证

方面	JWT	会话
状态管理	无状态（不需要服务器端存储），可提高可扩展性	有状态（会话数据存储在服务器上）
存储	客户端（localStorage、sessionStorage）	服务器端（Cookie 中带有 SessionID）
可扩展性	更适合分布式系统	需要会话同步
安全	不易受 CSRF 攻击，但易受 XSS 攻击	如果使用 Cookie，则容易受到 CSRF 攻击
大小	体积较大 - 包含所有必要信息	体积较小 - 仅包含 SessionID
撤销	在过期前很难撤销	易于失效
移动/API	非常适合移动应用和 API	不太适合移动应用

来源： docs/system-design/security/advantages-and-disadvantages-of-jwt.md14-92

JWT 安全注意事项

JWT 的优点

1. 无状态：不需要服务器端存储，提高了可扩展性
2. CSRF 防护：存储在 localStorage 中时，不易受 CSRF 攻击（而不是存储在 Cookie 中）
3. 对移动友好：适用于包括移动应用在内的不同平台
4. 跨域：方便跨多个域实现单点登录

挑战与解决方案

挑战 1：JWT 撤销

由于 JWT 是无状态的，并且在过期前都有效，因此在以下场景中很难使其失效：

• 用户注销
• 密码更改
• 权限更改
• 账户暂停

解决方案

1. 黑名单方法：将已撤销的令牌存储在数据库（例如 Redis）中
2. 短过期时间：设置 JWT 的过期时间要短
3. 刷新令牌模式：使用生命周期短的访问令牌和生命周期长的刷新令牌

挑战 2：JWT 更新

出于安全考虑，JWT 应具有有限的生命周期，但这会产生对更新机制的需求。

解决方案：刷新令牌模式

挑战 3：JWT 体积

JWT 可能变得很大，增加网络开销。

解决方案

1. 最小化 Payload 数据
2. 使用压缩
3. 在某些用例中，考虑使用传统的令牌和服务器端存储

来源： docs/system-design/security/advantages-and-disadvantages-of-jwt.md94-190

网络安全威胁

常见攻击向量

IP 欺骗

IP 欺骗是一种攻击者伪造源 IP 地址来冒充另一个主机的技术。这可以用于

• 绕过基于 IP 的访问控制
• 隐藏攻击者的身份
• 进行反射攻击

缓解措施：在网络边界实施入口和出口过滤，以验证数据包源地址。

来源： docs/cs-basics/network/network-attack-means.md12-40

SYN Flood 攻击

SYN Flood 攻击通过发送大量 SYN 数据包但不完成握手来利用 TCP 三次握手。

缓解技术:

• 扩展 backlog 队列大小
• 实现 SYN cookies
• 使用连接超时
• 应用速率限制

来源： docs/cs-basics/network/network-attack-means.md42-98

HTTP Flood

HTTP Flood 攻击通过向 Web 服务器发送大量看似合法的 HTTP GET 或 POST 请求来攻击 Web 服务器。

类型:

• HTTP GET Flood：对图像、文件或其他资源的多个请求
• HTTP POST Flood：多个表单提交，触发资源密集型的服务器操作

缓解:

• Web 应用程序防火墙 (WAF)
• 验证码/JavaScript 挑战
• 限流
• IP 信誉分析

来源： docs/cs-basics/network/network-attack-means.md127-150

跨站请求伪造 (CSRF)

CSRF 攻击会诱使用户在已登录的网站上执行不需要的操作。

攻击示例

JWT 如何帮助防止 CSRF：当 JWT 存储在 localStorage 中（而不是 Cookie 中）时，恶意网站无法在伪造的请求中包含 JWT。

基于会话的身份验证的缓解措施:

• 防 CSRF 令牌
• SameSite Cookie 属性
• 请求来源验证

来源： docs/system-design/security/basis-of-authority-certification.md179-203

中间人攻击

在中间人 (MITM) 攻击中，攻击者秘密地拦截并可能篡改两个通信方之间的通信。

缓解:

• 带有有效证书的 HTTPS
• 证书固定
• 消息签名
• 公钥基础设施 (PKI)
• 数字签名
• 使用 AES、IDEA、SM4 等加密算法进行对称加密
• 使用 RSA、ECC、SM2 等算法进行非对称加密

来源： docs/cs-basics/network/network-attack-means.md247-406

安全最佳实践

身份验证最佳实践

1. 使用强密码策略

   • 强制执行最小长度和复杂性要求
   • 在多次失败尝试后实施账户锁定

2. 实施多因素身份验证

   • 你知道的（密码）
   • 你拥有的（设备）
   • 你是什么（生物识别）

3. JWT 安全

   • 将令牌存储在 localStorage 中，而不是 Cookie 中（以防止 CSRF）
   • 使用短过期时间
   • 实施适当的令牌续订策略
   • 切勿在 JWT Payload 中存储敏感信息
   • 安全地管理签名密钥

4. Session 安全

   • 使用安全的 HttpOnly Cookie
   • 实施适当的会话超时
   • 身份验证后重新生成会话 ID

来源： docs/system-design/security/jwt-intro.md158-167

授权最佳实践

1. 实施最小权限原则

   • 用户应仅拥有执行其职责所需的最低权限

2. 使用 RBAC 进行权限管理

   • 将权限分组到角色中
   • 根据职责将角色分配给用户

3. 对每个请求验证授权

   • 不要仅依赖 UI 限制
   • 服务器必须为每个操作验证权限

4. 审计访问和更改

   • 记录安全相关事件
   • 监控可疑活动

来源： docs/system-design/security/basis-of-authority-certification.md32-53

网络安全最佳实践

1. 实施适当的 DDoS 防护

   • 限流
   • 流量过滤
   • 使用 CDN 服务
   • 高容量基础设施

2. 处处使用 HTTPS

   • 使用 TLS 保护所有流量
   • 保持证书最新
   • 配置安全的 TLS 版本和密码套件

3. 实施纵深防御

   • 多层安全控制
   • 网络和应用程序级别的防火墙
   • 入侵检测和防御系统

4. 定期更新和修补系统

   • 保持所有软件组件最新
   • 监控安全漏洞

来源： docs/cs-basics/network/network-attack-means.md426-462

相关安全技术

OAuth 2.0

OAuth 2.0 是一种授权协议，它允许第三方应用程序代表用户访问资源，而无需暴露凭据。

OAuth 2.0 常用于

• 第三方登录（社交登录）
• API 授权
• 微服务身份验证
• 支付集成

来源： docs/system-design/security/basis-of-authority-certification.md229-249

单点登录 (SSO)

SSO 允许用户进行一次身份验证，然后访问多个关联系统，而无需重新进行身份验证。

SSO 的优势

• 改善用户体验（单点登录）
• 减少密码疲劳
• 集中式身份验证管理
• 简化的访问控制
• 简化的应用程序开发

来源： docs/system-design/security/basis-of-authority-certification.md213-227