第一章：安全工程概论
“安全不是产品，而是过程。” —— Bruce Schneier
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 提出了零信任模型。其核心原则：
永不信任，始终验证（Never Trust, Always Verify）
假设已被入侵（Assume Breach）
最小权限（Least Privilege）
显式验证（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）
每个用户、进程或系统组件只应拥有完成其任务所需的最小权限。
# ❌ 反模式：给所有用户管理员权限
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）
不依赖单一安全措施，而是在多个层次部署防御：
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）
当系统发生故障时，应该默认拒绝访问，而不是默认允许：
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 │
└─────────────────────────────────────────┘
自适应安全
现代安全系统采用自适应策略，根据风险动态调整安全级别：
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 三要素是信息安全的基石：机密性、完整性、可用性
安全模型从城堡模型演进到零信任，反映了威胁环境的变化
安全左移将安全实践融入开发生命周期的每个阶段
安全设计原则（最小权限、纵深防御、默认安全、职责分离）是构建安全系统的指导方针
安全与可用性需要平衡，风险驱动的决策是关键
在接下来的章节中，我们将深入探讨密码学基础、证书体系、威胁建模等核心主题，为后续的身份认证和访问授权打下坚实的基础。