# 第一章：安全工程概论 > "安全不是产品，而是过程。" —— Bruce Schneier ```{mermaid} mindmap root((安全工程概论)) CIA 三要素 机密性 完整性 可用性 发展历程 城堡模型 边界防御 纵深防御 零信任 设计原则 最小权限 纵深防御 默认安全 职责分离 安全左移 需求阶段 设计阶段 编码阶段 测试阶段 ``` ## 1.1 信息安全的 CIA 三要素 信息安全的核心目标可以用三个字母概括：**CIA**。这不是美国中央情报局，而是信息安全领域最基本的三个属性： ### 机密性（Confidentiality） 机密性确保信息只能被授权的人访问。就像你的日记本上了锁，只有你有钥匙。 在技术层面，机密性通过以下手段实现： - **加密**：对数据进行加密，使未授权者无法读取 - **访问控制**：限制谁可以访问什么资源 - **数据分类**：根据敏感程度对数据进行分级管理 ``` ┌─────────────────────────────────────────┐ │ 机密性保护层次 │ ├─────────────────────────────────────────┤ │ 传输层加密 │ TLS/mTLS │ │ 存储层加密 │ AES-256-GCM │ │ 应用层加密 │ 端到端加密 │ │ 访问控制 │ RBAC/ABAC │ │ 数据脱敏 │ 掩码/令牌化 │ └─────────────────────────────────────────┘ ``` ### 完整性（Integrity） 完整性确保信息在传输和存储过程中不被篡改。就像你寄出的信件，收件人收到时内容应该和你写的一模一样。 实现完整性的技术手段： - **哈希函数**：SHA-256、SHA-3 等，用于验证数据未被修改 - **数字签名**：证明数据来源可信且未被篡改 - **消息认证码（MAC）**：HMAC，确保消息的完整性和真实性 ### 可用性（Availability） 可用性确保授权用户在需要时能够访问信息和资源。一个安全但无法使用的系统毫无价值。 保障可用性的措施： - **冗余设计**：多副本、多区域部署 - **DDoS 防护**：流量清洗、CDN - **灾难恢复**：备份策略、RTO/RPO 目标 - **容量规划**：确保系统能承受预期负载 ### CIA 的平衡 三个要素之间存在天然的张力： | 场景 | 侧重 | 牺牲 | |------|------|------| | 军事系统 | 机密性 > 可用性 | 宁可不可用，也不能泄密 | | 医疗急救系统 | 可用性 > 机密性 | 紧急情况下可突破权限 | | 金融交易系统 | 完整性 > 一切 | 数据不能有任何差错 | | 公共网站 | 可用性 > 机密性 | 信息本身就是公开的 | ## 1.2 安全工程的发展历程 ### 城堡模型（Castle-and-Moat） 早期的网络安全采用"城堡与护城河"模型： ``` 互联网（不可信） │ ┌────▼────┐ │ 防火墙 │ ← 护城河 └────┬────┘ │ ┌──────────▼──────────┐ │ 内部网络（可信） │ ← 城堡内部 │ │ │ ┌────┐ ┌────┐ │ │ │服务A│ │服务B│ │ │ └────┘ └────┘ │ │ ┌────┐ ┌────┐ │ │ │数据库│ │文件│ │ │ └────┘ └────┘ │ └──────────────────────┘ ``` 这个模型的核心假设是：**内部网络是可信的，外部网络是不可信的**。只要守住边界（防火墙），内部就是安全的。 问题在于：一旦攻击者突破了边界，就可以在内部网络中横向移动，如入无人之境。 ### 纵深防御（Defense in Depth） 纵深防御借鉴了军事战略，在多个层次部署安全措施： ``` ┌─────────────────────────────────────────┐ │ 第1层：物理安全（机房门禁、监控） │ │ ┌─────────────────────────────────────┐ │ │ │ 第2层：网络安全（防火墙、IDS/IPS） │ │ │ │ ┌─────────────────────────────────┐ │ │ │ │ │ 第3层：主机安全（补丁、杀毒） │ │ │ │ │ │ ┌─────────────────────────────┐ │ │ │ │ │ │ │ 第4层：应用安全（WAF、认证） │ │ │ │ │ │ │ │ ┌─────────────────────────┐ │ │ │ │ │ │ │ │ │ 第5层：数据安全（加密） │ │ │ │ │ │ │ │ │ └─────────────────────────┘ │ │ │ │ │ │ │ └─────────────────────────────┘ │ │ │ │ │ └─────────────────────────────────┘ │ │ │ └─────────────────────────────────────┘ │ └─────────────────────────────────────────┘ ``` ### 零信任（Zero Trust） 2010 年，Forrester 的 John Kindervag 提出了零信任模型。其核心原则： 1. **永不信任，始终验证**（Never Trust, Always Verify） 2. **假设已被入侵**（Assume Breach） 3. **最小权限**（Least Privilege） 4. **显式验证**（Verify Explicitly） ``` ┌──────────────────────────────────────────────┐ │ 零信任架构 │ │ │ │ ┌─────┐ ┌──────────┐ ┌──────────┐ │ │ │用户/ │───▶│ 策略引擎 │───▶│ 策略执行 │ │ │ │工作负│ │(身份验证 │ │ 点(PEP) │ │ │ │载 │ │ 风险评估 │ │ │ │ │ └─────┘ │ 权限检查) │ └────┬─────┘ │ │ └──────────┘ │ │ │ ▼ │ │ ┌──────────────────────┐ │ │ │ 受保护的资源 │ │ │ │ (每次访问都需验证) │ │ │ └──────────────────────┘ │ └──────────────────────────────────────────────┘ ``` ## 1.3 安全左移（Shift Left Security） 传统的安全实践是在开发完成后进行安全测试，这就像房子建好后才发现地基有问题。**安全左移**意味着在软件开发生命周期的早期就引入安全实践。 ``` 传统模式： 需求 → 设计 → 编码 → 测试 → 部署 → [安全测试] → 运维 ↑ 发现问题，修复成本高 安全左移： [安全需求] → [安全设计] → [安全编码] → [安全测试] → [安全部署] → [安全运维] ↑ ↑ ↑ ↑ ↑ ↑ 威胁建模 安全架构 SAST/SCA DAST/渗透 安全配置 监控告警 ``` ### 各阶段的安全活动 | 阶段 | 安全活动 | 工具/方法 | |------|---------|----------| | 需求 | 安全需求分析、合规要求 | STRIDE 威胁建模 | | 设计 | 安全架构评审、威胁建模 | 数据流图、攻击树 | | 编码 | 安全编码规范、代码审查 | SAST（Semgrep、CodeQL） | | 构建 | 依赖漏洞扫描、镜像扫描 | SCA（Snyk、Trivy） | | 测试 | 渗透测试、动态扫描 | DAST（OWASP ZAP） | | 部署 | 安全配置、密钥管理 | IaC 扫描（Checkov） | | 运维 | 监控、告警、应急响应 | SIEM、SOC | ### 修复成本的指数增长 安全问题发现得越晚，修复成本越高： ``` 修复成本 │ │ ★ 生产环境 │ ★ ($15,000) │ ★ │ ★ │ ★ 测试阶段 │ ★ ($5,000) │ ★ │ ★ 编码阶段 │ ★ ($500) │★ 设计阶段 │ ($50) └──────────────────────────────────────── 时间 需求 设计 编码 测试 部署 运维 ``` ## 1.4 安全设计原则 ### 最小权限原则（Principle of Least Privilege） 每个用户、进程或系统组件只应拥有完成其任务所需的最小权限。 ```python # ❌ 反模式：给所有用户管理员权限 def get_user_role(user): return "admin" # 简单粗暴，但极其危险 # ✅ 正确做法：基于角色的最小权限 class Permission: READ = "read" WRITE = "write" DELETE = "delete" ADMIN = "admin" ROLE_PERMISSIONS = { "viewer": [Permission.READ], "editor": [Permission.READ, Permission.WRITE], "admin": [Permission.READ, Permission.WRITE, Permission.DELETE, Permission.ADMIN], } def check_permission(user_role: str, required_permission: str) -> bool: """检查用户角色是否拥有所需权限""" permissions = ROLE_PERMISSIONS.get(user_role, []) return required_permission in permissions ``` ### 纵深防御原则（Defense in Depth） 不依赖单一安全措施，而是在多个层次部署防御： ```python from fastapi import FastAPI, Depends, HTTPException from fastapi.security import HTTPBearer app = FastAPI() # 第1层：API Gateway（速率限制、IP 白名单） # 第2层：认证中间件 async def verify_token(token: str = Depends(HTTPBearer())): """验证 JWT Token""" try: payload = jwt.decode(token.credentials, SECRET_KEY, algorithms=["RS256"]) return payload except jwt.InvalidTokenError: raise HTTPException(status_code=401, detail="Invalid token") # 第3层：授权检查 async def check_authorization(user=Depends(verify_token)): """检查用户权限""" if "admin" not in user.get("roles", []): raise HTTPException(status_code=403, detail="Insufficient permissions") return user # 第4层：输入验证 from pydantic import BaseModel, validator class CreateUserRequest(BaseModel): username: str email: str @validator("username") def validate_username(cls, v): if not v.isalnum() or len(v) < 3: raise ValueError("Invalid username") return v # 第5层：审计日志 import logging audit_logger = logging.getLogger("audit") @app.post("/admin/users") async def create_user( request: CreateUserRequest, user=Depends(check_authorization) ): audit_logger.info(f"User {user['sub']} created user {request.username}") # ... 创建用户逻辑 ``` ### 默认安全原则（Secure by Default） 系统的默认配置应该是安全的，用户需要显式地降低安全级别。 | 设置项 | 不安全默认值 | 安全默认值 | |--------|-------------|-----------| | 密码策略 | 无要求 | 最少 12 位，含大小写和特殊字符 | | Session 超时 | 永不过期 | 30 分钟 | | CORS | 允许所有来源 | 仅允许白名单域名 | | Cookie | 无标志 | HttpOnly + Secure + SameSite | | TLS 版本 | 支持 TLS 1.0+ | 仅 TLS 1.2+ | | 日志级别 | DEBUG | WARN | ### 职责分离原则（Separation of Duties） 关键操作需要多人协作完成，防止单点滥用： ``` 代码变更流程（职责分离）： ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 开发者 │───▶│ 审查者 │───▶│ 安全团队 │───▶│ 运维团队 │ │ 编写代码 │ │ 代码审查 │ │ 安全审查 │ │ 部署上线 │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ ▼ ▼ ▼ ▼ 不能自己 不能审查自己 不能跳过安全 不能修改代码 审查代码 的代码 检查直接部署 直接部署 ``` ### 失败安全原则（Fail Secure） 当系统发生故障时，应该默认拒绝访问，而不是默认允许： ```python def authorize_request(token: str, resource: str) -> bool: """授权检查 — 失败时默认拒绝""" try: user = verify_token(token) permissions = get_permissions(user) return resource in permissions except TokenExpiredError: return False # Token 过期，拒绝 except ConnectionError: return False # 无法连接授权服务，拒绝（而非允许） except Exception: return False # 任何未知错误，拒绝 ``` ## 1.5 安全与可用性的平衡 安全和可用性之间存在天然的矛盾。过度的安全措施会降低用户体验，而过于宽松的安全策略则会带来风险。 ### 风险驱动的安全决策 ``` 风险 = 威胁 × 脆弱性 × 影响 安全投入应与风险成正比： ┌─────────────────────────────────────────┐ │ 高风险（核心数据、支付系统） │ │ → 强认证 + 细粒度授权 + 加密 + 审计 │ ├─────────────────────────────────────────┤ │ 中风险（内部工具、管理后台） │ │ → SSO + RBAC + 日志 │ ├─────────────────────────────────────────┤ │ 低风险（公开信息、静态页面） │ │ → 基本防护 + CDN │ └─────────────────────────────────────────┘ ``` ### 自适应安全 现代安全系统采用自适应策略，根据风险动态调整安全级别： ```python def adaptive_authentication(user, context): """自适应认证：根据风险等级决定认证强度""" risk_score = calculate_risk(user, context) if risk_score < 0.3: # 低风险：正常登录即可 return require_password(user) elif risk_score < 0.7: # 中风险：需要 MFA return require_password(user) and require_mfa(user) else: # 高风险：需要额外验证 return (require_password(user) and require_mfa(user) and require_identity_verification(user)) def calculate_risk(user, context): """计算风险分数""" score = 0.0 if context.ip not in user.known_ips: score += 0.3 # 新 IP 地址 if context.device not in user.known_devices: score += 0.3 # 新设备 if context.location != user.usual_location: score += 0.2 # 异常地理位置 if context.time.hour < 6 or context.time.hour > 22: score += 0.1 # 异常时间 if user.recent_failed_attempts > 3: score += 0.3 # 近期多次失败 return min(score, 1.0) ``` ## 1.6 本书结构与阅读指南 本书分为五个部分，共 30 章： ``` 第一部分：安全基础（第1-5章） ├── 第1章：安全工程概论 ← 你在这里 ├── 第2章：密码学基础 ├── 第3章：PKI 与证书体系 ├── 第4章：威胁建模与风险评估 └── 第5章：身份与访问管理概论 第二部分：身份认证 Authentication（第6-12章） ├── 第6章：TLS 协议深入解析 ├── 第7章：OAuth 2.0 授权框架 ├── 第8章：OpenID Connect 身份认证 ├── 第9章：JWT 深入解析 ├── 第10章：多因素认证（MFA） ├── 第11章：单点登录与联邦身份 └── 第12章：API 认证模式 第三部分：访问授权 Authorization（第13-18章） ├── 第13章：访问控制模型 ├── 第14章：OpenFGA — 细粒度授权引擎 ├── 第15章：OPA — 通用策略引擎 ├── 第16章：策略即代码 ├── 第17章：授权架构模式 └── 第18章：授权系统实战 第四部分：工作负载身份与零信任（第19-24章） ├── 第19章：SPIFFE — 通用工作负载身份框架 ├── 第20章：SPIRE — SPIFFE 的参考实现 ├── 第21章：SPIFFE 联邦与跨域信任 ├── 第22章：WIMSE — 多系统环境中的工作负载身份 ├── 第23章：零信任架构 └── 第24章：Service Mesh 安全 第五部分：实战与展望（第25-30章） ├── 第25章：安全框架与库实战 ├── 第26章：API 安全设计 ├── 第27章：密钥与凭证管理 ├── 第28章：云原生安全 ├── 第29章：DevSecOps — 安全左移 └── 第30章：安全工程的未来 ``` ### 阅读建议 | 读者类型 | 推荐路径 | |---------|---------| | 安全新手 | 第1-5章 → 第7-9章 → 第13章 → 第23章 | | 后端开发者 | 第6-9章 → 第12-14章 → 第18章 → 第25-26章 | | 平台工程师 | 第19-24章 → 第27-28章 → 第29章 | | 安全工程师 | 全书通读，重点关注第13-24章 | | 架构师 | 第1章 → 第5章 → 第13-17章 → 第19-24章 → 第30章 | ## 1.7 小结 本章介绍了安全工程的基本概念和原则： - **CIA 三要素**是信息安全的基石：机密性、完整性、可用性 - 安全模型从**城堡模型**演进到**零信任**，反映了威胁环境的变化 - **安全左移**将安全实践融入开发生命周期的每个阶段 - 安全设计原则（最小权限、纵深防御、默认安全、职责分离）是构建安全系统的指导方针 - 安全与可用性需要**平衡**，风险驱动的决策是关键 在接下来的章节中，我们将深入探讨密码学基础、证书体系、威胁建模等核心主题，为后续的身份认证和访问授权打下坚实的基础。