从 Confidentiality、Integrity、Availability 三个维度系统梳理 CIA 安全模型，并结合软件工程、Java 后端、SaaS
系统和研发流程给出可落地的设计、编码、测试与运维实践。
CIA 三要素在软件工程中的落地：从安全模型到研发实践
摘要
CIA 三要素是信息安全领域最经典的基础模型之一，分别代表：
- Confidentiality，机密性：不该看的人看不到。
- Integrity，完整性：不该改的人改不了，改了也能发现，业务状态和数据结果保持正确。
- Availability，可用性：该用的时候系统能用，出故障后可以恢复。
在软件工程中，CIA 不应该只是安全团队 PPT 里的概念，而应该进入需求评审、架构设计、接口设计、数据库设计、编码规范、测试用例、发布流程、监控告警和应急响应。
换句话说，CIA 不是“最后加一层安全组件”，而是贯穿软件生命周期的质量属性。
如果用一句话概括：
机密性管谁能看，完整性管谁能改和改得对不对，可用性管系统能不能持续可靠地提供服务。
1. CIA 是什么？
CIA 是信息安全的三个核心目标：
1
2
3
| C = Confidentiality 机密性
I = Integrity 完整性
A = Availability 可用性
|
NIST 对 CIA 的定义可以简化理解为：
- 机密性：保护信息访问与披露限制，避免未授权主体获取信息。
- 完整性：防止信息被不当修改或破坏，并保证真实性和不可抵赖性。
- 可用性：确保被授权主体可以及时、可靠地访问和使用信息。
这三个目标共同构成软件系统安全设计的基础框架。
不过，在真实工程里，CIA 不能只停留在定义层面。更重要的问题是：
1
2
3
4
5
| 这个需求会不会泄露数据？
这个接口会不会被越权访问？
这个状态能不能被非法修改？
这个流程失败后能不能恢复？
这个系统依赖挂了会不会雪崩？
|
这些问题，才是 CIA 在软件工程里的真实落点。
2. 为什么软件工程需要 CIA？
很多系统做安全时，容易变成补丁式安全：
1
2
3
4
5
| 加一个 Spring Security
接口上加个 Token
密码做个加密
上线前扫一下漏洞
日志里偶尔脱敏一下
|
这类做法有用，但远远不够。
真正的软件工程视角应该是：
1
2
3
4
5
| 需求阶段：识别安全目标和业务风险
设计阶段：把 CIA 转成架构约束和业务规则
编码阶段：通过代码、配置、数据库约束实现控制
测试阶段：验证安全控制是否有效
上线阶段：通过监控、审计、备份、应急保证持续安全
|
OWASP ASVS 的价值也在这里：它不是只告诉你“要安全”，而是把 Web 应用安全拆成一组可验证、可测试、可落地的安全需求。
所以，CIA 的意义不是让系统“显得很安全”，而是帮助工程团队建立一套稳定的思考框架：
- 哪些数据是敏感的？
- 哪些操作必须授权？
- 哪些状态不能被绕过？
- 哪些流程必须可审计？
- 哪些依赖失败后必须降级？
- 哪些数据必须能恢复？
没有这些问题，安全就很容易变成“上线前贴符”。贴符可以求个心理安慰，但挡不住真实事故。
3. Confidentiality：机密性如何落地？
机密性的核心目标是：
不该看的人看不到，不该拿的数据拿不到。
在软件系统中，机密性主要体现在认证、授权、数据隔离、加密、脱敏、日志控制和密钥管理上。
3.1 身份认证：先确认“你是谁”
认证解决的是身份问题。
常见认证方式包括：
1
2
3
4
5
6
7
| 账号密码
短信/邮箱验证码
MFA / OTP
OAuth2 / OIDC
企业 SSO
设备绑定
风险登录检测
|
对于 Java 后端，常见实现包括：
1
2
3
4
5
| Spring Security
OAuth2 Resource Server
OIDC Login
Session
JWT / Opaque Token
|
密码存储不能使用普通哈希，例如：
1
2
| MD5(password)
SHA256(password)
|
这类算法太快，适合完整性校验，不适合密码存储。密码应该使用专门的密码哈希算法，例如：
并且要配合随机 salt、合理的成本参数和升级机制。
3.2 授权：再确认“你能干什么”
认证只说明用户是谁，授权才说明用户能访问什么资源、执行什么操作。
常见授权模型包括：
| 模型 |
含义 |
适用场景 |
| RBAC |
基于角色的访问控制 |
后台管理系统、企业 SaaS |
| ABAC |
基于属性的访问控制 |
多租户、复杂组织架构、动态规则 |
| ACL |
针对单个资源授权 |
文档系统、项目协作、网盘 |
接口层可以做权限控制：
1
2
3
4
5
| @PreAuthorize("hasAuthority('finance:settlement:read')")
@GetMapping("/settlements/{id}")
public SettlementDetail getDetail(@PathVariable Long id) {
return settlementService.getDetail(id);
}
|
但只做接口权限是不够的。SaaS 系统尤其要重视数据权限。
例如：
1
2
3
4
5
6
7
8
9
10
| public SettlementDetail getDetail(Long id) {
Settlement settlement = settlementRepository.findById(id)
.orElseThrow();
if (!Objects.equals(settlement.getTenantId(), CurrentUser.tenantId())) {
throw new AccessDeniedException("无权访问该租户数据");
}
return assembler.toDetail(settlement);
}
|
很多越权漏洞并不是没有登录，而是用户登录后通过修改 URL 参数访问了别人的数据：
1
2
| /settlements/1001
/settlements/1002
|
如果后端只判断“用户是否登录”，而不判断“这个资源是否属于当前用户或当前租户”，机密性就被破坏了。
3.3 数据分级与脱敏
不同数据的敏感程度不同，不能一刀切。
常见数据分类：
| 等级 |
示例 |
处理方式 |
| 公开数据 |
商品介绍、公开公告 |
正常访问 |
| 内部数据 |
内部配置、运营数据 |
登录后访问 |
| 敏感数据 |
手机号、身份证号、银行卡号 |
脱敏、加密、审计 |
| 高敏数据 |
密码、Token、密钥、支付凭据 |
不展示、不打印、加密存储、严格授权 |
常见脱敏方式：
1
2
3
4
| 手机号：138****5678
身份证：110101********1234
银行卡：6222 **** **** 8888
邮箱：e***c@example.com
|
脱敏不是为了“好看”，而是为了减少泄露后的伤害面。
3.4 加密：传输、存储、字段级
加密可以分为三层：
1
2
3
| 传输中加密：HTTPS / TLS
存储中加密：数据库、磁盘、对象存储加密
字段级加密：身份证、银行卡、密钥、Token 等
|
生产系统的最低要求：
1
2
3
4
5
| 全站 HTTPS
数据库连接使用安全网络环境
对象存储私有读写
密钥不进 Git
敏感字段尽量字段级加密或脱敏存储
|
要注意：加密不是权限控制的替代品。
如果权限控制做烂了，加密也救不了。就像保险柜很结实，但钥匙贴在柜门上，攻击者还得谢谢你贴心。
3.5 Token 和 Session 的安全
如果系统使用 Bearer Token，需要意识到它的本质是：
谁持有 token，谁就能访问。
因此，access token 应该短生命周期，refresh token 应该可撤销、可轮换，不应该把长期 token 放在 localStorage 或 sessionStorage
中。
Web 系统更推荐：
1
2
| HttpOnly + Secure + SameSite Cookie
或者 BFF 模式
|
Cookie 示例：
1
2
3
4
5
| Set-Cookie: __Host-SESSION=<random>;
Secure;
HttpOnly;
SameSite=Lax;
Path=/
|
其中：
HttpOnly：降低 XSS 读取 Cookie 的风险。Secure：只通过 HTTPS 传输。SameSite：降低 CSRF 风险。__Host- 前缀：减少子域 Cookie 覆盖风险。
3.6 日志脱敏
日志是机密性事故的重灾区。
不要打印：
1
2
3
4
5
6
7
8
9
10
| password
Authorization header
access_token
refresh_token
Cookie
SessionId
验证码
身份证号
银行卡号
完整手机号
|
错误示例：
1
| log.info("login request: {}", loginRequest);
|
如果 loginRequest 中包含密码，这条日志就直接泄露敏感信息。
更好的写法：
1
2
3
4
| log.info("user login attempt, username={}, ip={}",
MaskUtils.maskUsername(username),
clientIp
);
|
4. Integrity：完整性如何落地？
完整性的核心目标是：
数据不能被未授权修改；数据被修改时必须符合业务规则；出了问题能够发现、追踪和恢复。
在财务系统、订单系统、权限系统、库存系统里，完整性往往比机密性还关键。数据泄露很严重，但金额算错、库存超扣、结算单重复生成，同样可能是灾难。
4.1 输入校验：所有外部输入都不可信
外部输入包括：
1
2
3
4
5
6
7
8
| HTTP 参数
Header
Cookie
JWT Claims
Excel 导入
MQ 消息
第三方回调
管理员后台输入
|
需要校验：
1
2
3
4
5
6
7
8
| 格式
长度
范围
枚举
金额精度
业务状态
资源归属
操作权限
|
金额字段必须使用 BigDecimal，不要使用 double 或 float 做财务计算。
示例：
1
2
3
| if (amount == null || amount.compareTo(BigDecimal.ZERO) < 0) {
throw new BizException("金额不能为负数");
}
|
但更重要的是业务完整性校验：
1
2
3
4
5
| 已结算单不能修改
已审核单不能删除
账期不能重叠
费用摊销总额必须等于原始费用
订单状态流转必须合法
|
这些规则不能只写在前端，必须在后端业务层或领域层兜底。
4.2 数据库约束：不要只相信应用代码
应用层校验很重要，但数据库也必须兜底。
常见数据库约束包括：
1
2
3
4
5
6
7
| NOT NULL
UNIQUE
FOREIGN KEY
CHECK
VERSION
DELETED
CREATE_TIME / UPDATE_TIME
|
示例：
1
2
| ALTER TABLE finance_bill
ADD CONSTRAINT uk_bill_no UNIQUE (tenant_id, bill_no);
|
金额字段：
1
2
| amount
NUMERIC(18, 2) NOT NULL CHECK (amount >= 0)
|
数据库约束是最后一道门。应用代码是保安，数据库约束是门锁。保安可能打瞌睡，门锁不能没有。
4.3 事务一致性
涉及多表写入时，要明确事务边界。
示例：
1
2
3
4
5
6
7
| @Transactional(rollbackFor = Exception.class)
public void createSettlement(CreateSettlementCommand command) {
}
|
要避免：
1
2
3
| 主表写成功，明细写失败
状态改成功，审计日志没写
金额汇总成功，部分明细丢失
|
这类问题不是简单 bug，而是完整性破坏。
4.4 并发控制
并发是完整性的天然敌人。
常见问题：
1
2
3
4
5
6
| 重复提交
重复支付
库存超扣
余额扣成负数
结算单重复生成
审批状态被覆盖
|
常见手段：
1
2
3
4
5
6
7
| 唯一索引
乐观锁 version
悲观锁 select for update
状态机约束
幂等键 Idempotency-Key
分布式锁
消息去重
|
JPA 乐观锁示例：
1
2
| @Version
private Long version;
|
幂等请求示例：
1
2
| POST /payments
Idempotency-Key: 20260623-user123-xxx
|
服务端记录这个 key。用户重复提交或网络重试时，返回同一个结果，而不是执行两次扣款。
4.5 状态机与业务不变量
复杂业务系统一定要显式管理状态。
例如结算单状态：
1
2
3
4
5
| DRAFT 草稿
SUBMITTED 已提交
APPROVED 已审核
SETTLED 已结算
CANCELLED 已取消
|
合法流转：
1
2
3
4
5
| DRAFT -> SUBMITTED
SUBMITTED -> APPROVED
APPROVED -> SETTLED
DRAFT -> CANCELLED
SUBMITTED -> CANCELLED
|
非法流转必须拒绝：
1
2
3
| SETTLED -> DRAFT
CANCELLED -> APPROVED
APPROVED -> DRAFT
|
代码中不要散落大量 if status == xxx，可以抽出状态机规则，让完整性约束更清晰。
4.6 审计日志
完整性不只是防止错误修改，还要能回答：
1
2
3
4
5
| 谁改的？
什么时候改的？
从什么值改成什么值？
为什么改？
从哪个 IP、设备、TraceId 发起？
|
审计日志建议记录：
1
2
3
4
5
6
7
8
9
10
| operator_id
operator_name
operation
resource_type
resource_id
before_value
after_value
ip
trace_id
created_at
|
关键审计日志最好是 append-only，不允许普通业务代码修改或删除。
示例表结构：
1
2
3
4
5
6
7
8
9
10
11
12
13
| CREATE TABLE audit_log
(
id BIGINT PRIMARY KEY,
tenant_id BIGINT NOT NULL,
operator_id BIGINT NOT NULL,
resource_type VARCHAR(64) NOT NULL,
resource_id VARCHAR(128) NOT NULL,
operation VARCHAR(64) NOT NULL,
before_json JSONB,
after_json JSONB,
trace_id VARCHAR(128),
created_at TIMESTAMP NOT NULL
);
|
4.7 代码与供应链完整性
完整性不仅包括业务数据，也包括代码、依赖、配置和制品。
要防止：
1
2
3
4
5
6
| 依赖被投毒
镜像被替换
构建产物被篡改
配置被误改
数据库 migration 被回改
生产环境被手工改坏
|
建议实践：
1
2
3
4
5
6
7
8
| 主分支保护
Code Review
CI/CD 权限控制
依赖漏洞扫描
制品仓库权限控制
Docker 镜像签名
生产配置只读化
Flyway migration 只新增不修改
|
尤其数据库迁移文件，一旦发布到环境，就不应该修改历史版本。正确方式是新增一个 migration 版本进行修正。
5. Availability：可用性如何落地？
可用性的核心目标是：
系统在需要的时候能正常提供服务，即使部分组件故障，也不要整体崩掉。
可用性不是“服务器不挂”这么简单，而是一整套架构、容量、限流、容灾、备份、恢复、监控、应急能力。
5.1 高可用架构
常见手段：
1
2
3
4
5
6
7
8
9
| 多实例部署
负载均衡
数据库主从或集群
Redis Sentinel / Cluster
MQ 集群
Kubernetes 自动重启
多可用区部署
CDN
对象存储
|
基本原则：
1
2
3
4
| 无状态服务水平扩展
有状态组件做复制和备份
关键链路避免单点
故障时允许局部降级
|
典型架构：
1
2
3
4
5
6
7
8
9
| Browser
↓
CDN / WAF
↓
Nginx / API Gateway
↓
多个 Spring Boot 实例
↓
Database / Redis / MQ / Object Storage
|
5.2 限流、熔断、降级
可用性问题经常不是机器少，而是系统没有自我保护能力。
要防：
1
2
3
4
5
6
| 突发流量
恶意刷接口
慢 SQL 拖垮连接池
第三方接口超时
MQ 积压
线程池耗尽
|
常见控制：
1
2
3
4
5
6
7
| Rate Limit 限流
Circuit Breaker 熔断
Timeout 超时
Retry with Backoff 重试退避
Bulkhead 舱壁隔离
Fallback 降级
Queue 队列削峰
|
Java 生态常见选择：
1
2
3
4
5
| Resilience4j
Sentinel
Spring Cloud Gateway RateLimiter
线程池隔离
信号量隔离
|
重试要谨慎。无脑重试会把小故障打成雪崩，是典型的“帮倒忙界 MVP”。
5.3 超时控制
所有外部调用都必须有超时：
1
2
3
4
5
6
7
| HTTP 调用
RPC 调用
数据库查询
Redis 调用
MQ 发送
文件上传
第三方支付/短信/物流接口
|
要明确：
错误设计：
1
| restTemplate.getForObject(url, String.class);
|
更好的做法是配置合理的连接池、超时、重试和熔断策略。
5.4 备份与恢复
可用性不只是“不挂”，还包括“挂了能恢复”。
必须定义两个指标：
1
2
| RPO：Recovery Point Objective，最多能丢多少数据
RTO：Recovery Time Objective，多久必须恢复服务
|
例如：
1
2
| RPO = 5 分钟：最多丢 5 分钟数据
RTO = 30 分钟：30 分钟内恢复核心服务
|
建议实践：
1
2
3
4
5
6
7
| 数据库定期备份
binlog / WAL 归档
对象存储版本控制
配置备份
异地备份
恢复演练
灾难恢复预案
|
没有演练过的备份，不算真正可用。备份文件存在，只能证明“你备份过”；能不能恢复，是另一回事。
5.5 监控和告警
可用性必须可观测。
至少监控：
1
2
3
4
5
6
7
8
9
10
11
12
13
| 接口成功率
接口延迟 P95 / P99
错误率
数据库连接池
慢 SQL
CPU / Memory / Disk
GC
线程池
Redis 命中率
MQ 堆积
登录失败率
限流次数
外部依赖超时率
|
常见工具：
1
2
3
4
5
6
| Prometheus
Grafana
Loki / ELK
OpenTelemetry
SkyWalking / Jaeger
Alertmanager
|
告警不应该只在“服务已经挂了”之后触发，还应该在“快挂了”时触发：
1
2
3
4
5
6
| P99 延迟持续升高
错误率突然上升
线程池队列堆积
数据库连接池耗尽
磁盘空间低于阈值
MQ 消费延迟持续增加
|
6. CIA 在研发流程中的实践
CIA 最有价值的地方，是把安全问题提前到研发流程中。
6.1 需求阶段
每个需求都应该问三组问题。
机密性问题
1
2
3
4
5
6
| 这个功能涉及哪些敏感数据？
谁可以看？
是否需要脱敏？
是否需要导出限制？
是否需要水印？
是否涉及跨租户访问？
|
完整性问题
1
2
3
4
5
6
| 谁可以改？
什么状态下可以改？
是否需要审批？
是否允许撤销？
是否需要审计？
是否存在金额、库存、结算等强一致要求？
|
可用性问题
1
2
3
4
5
6
| 这个功能是否是核心链路？
峰值 QPS 大概多少？
失败后能否重试？
依赖第三方挂了怎么办？
是否需要异步化？
RTO/RPO 要求是多少？
|
6.2 设计阶段
设计文档建议固定加入一节：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| ## Security & Reliability Considerations
### Confidentiality
- 数据分类：
- 访问控制：
- 脱敏策略：
- 加密策略：
### Integrity
- 业务不变量：
- 事务边界：
- 并发控制：
- 审计日志：
### Availability
- 超时/重试：
- 限流/熔断：
- 降级方案：
- 监控指标：
- 备份恢复：
|
这比上线前临时补安全靠谱得多。
6.3 编码阶段
团队可以形成一些默认规则：
1
2
3
4
5
6
7
8
| 所有接口默认需要认证
所有查询必须带租户或数据权限
所有写操作必须校验状态机
所有金额计算必须使用 BigDecimal
所有外部调用必须配置超时
所有关键写操作必须有审计日志
所有批量任务必须可重试、可幂等
所有异常日志不得泄露敏感信息
|
特别是多租户系统，租户隔离应该成为基础设施，而不是靠每个开发者“记得加 tenant_id”。
6.4 测试阶段
CIA 可以直接转成测试用例。
机密性测试
1
2
3
4
5
| 未登录访问接口，应返回 401
普通用户访问管理员接口，应返回 403
用户 A 访问用户 B 数据，应返回 403
导出数据时敏感字段应脱敏
日志中不应出现 token/password
|
完整性测试
1
2
3
4
5
| 重复提交不会生成两条记录
并发审批不会覆盖状态
金额合计和明细一致
非法状态流转被拒绝
修改关键数据会写审计日志
|
可用性测试
1
2
3
4
5
| 第三方接口超时时能降级
Redis 挂了核心功能是否可用
MQ 积压时系统是否保护自己
高并发登录是否触发限流
数据库慢查询是否触发告警
|
6.5 上线和运维阶段
上线后需要持续保障：
1
2
3
4
5
6
7
8
9
| 安全日志
审计日志
指标监控
异常告警
备份任务
恢复演练
漏洞扫描
依赖升级
应急预案
|
NIST SP 800-53 这类控制目录的价值在于，它不只看代码漏洞，还覆盖访问控制、审计、配置管理、事件响应、应急计划、供应链风险管理等组织级和系统级控制。
7. CIA 三者之间的取舍
CIA 不是三个目标全部无脑拉满。它们之间经常会冲突。
7.1 机密性 vs 可用性
MFA 可以提高机密性，但如果 MFA 服务挂了，用户可能无法登录。
解决方式：
1
2
3
4
| 备用验证方式
恢复码
管理员应急流程
MFA 服务高可用
|
7.2 完整性 vs 可用性
强一致事务可以保护完整性，但可能降低性能和可用性。
例如：
这些都可能影响吞吐。
更合理的做法是分级：
1
2
3
| 核心资金链路：强一致
非核心统计链路：最终一致
报表分析链路：异步计算和定期校正
|
7.3 可用性 vs 机密性
缓存可以提高可用性，但缓存敏感数据会增加泄露风险。
解决方式：
1
2
3
4
5
| 缓存最小化
敏感字段不缓存
缓存设置过期时间
按租户隔离 key
Redis 网络隔离和认证
|
8. Java 后端 / SaaS 系统落地清单
8.1 机密性最低要求
1
2
3
4
5
6
7
8
9
| 全站 HTTPS
密码使用 Argon2id / bcrypt
Token 不进入日志
敏感字段脱敏
接口级权限控制
数据级权限控制
租户隔离
数据库账号最小权限
生产密钥不进 Git
|
8.2 完整性最低要求
1
2
3
4
5
6
7
8
9
| 核心表有唯一约束
金额字段精度明确
写接口有幂等设计
关键业务有事务
关键状态有状态机
并发写有锁或 version
重要操作有审计日志
Flyway migration 只新增不修改
CI/CD 有分支保护和 Code Review
|
8.3 可用性最低要求
1
2
3
4
5
6
7
8
9
10
| 服务多实例
数据库备份
Redis / MQ 高可用
外部调用有超时
核心接口有限流
慢 SQL 监控
错误率告警
P95 / P99 延迟监控
发布可回滚
定期恢复演练
|
9. 示例：结算单系统中的 CIA
以财务结算单系统为例，CIA 可以这样落地。
9.1 机密性
1
2
3
4
5
6
| 门店只能看自己的结算单
总部可以看全部
联营商只能看自己相关账单
导出 Excel 时手机号、身份证号脱敏
接口必须校验 tenantId
日志不能打印完整敏感结算数据
|
9.2 完整性
1
2
3
4
5
6
7
| 已结算单不能修改
已审核单不能删除
账期不能重叠
应收/应付金额必须和明细合计一致
重复点击生成结算单不能生成两份
摊销金额最后一期必须处理尾差
每次审核/反审核都写审计日志
|
9.3 可用性
1
2
3
4
5
6
7
8
| 大客户结算异步生成
导出任务走队列
查询接口强制分页
复杂报表走缓存或预计算
结算任务失败可重试
MQ 堆积有告警
数据库慢 SQL 有告警
生成失败可以回滚或补偿
|
这样看，CIA 就不是抽象概念，而是能直接指导需求、设计、编码和测试。
10. 团队可直接使用的 CIA Checklist
下面这个 checklist 可以放到需求评审、技术方案或 Pull Request 模板里。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| # CIA Checklist
## Confidentiality 机密性
- [ ] 是否涉及敏感数据？
- [ ] 谁可以访问这些数据？
- [ ] 是否需要接口权限控制？
- [ ] 是否需要数据权限控制？
- [ ] 是否涉及多租户隔离？
- [ ] 是否需要脱敏展示？
- [ ] 是否需要加密存储？
- [ ] 日志是否可能泄露敏感信息？
## Integrity 完整性
- [ ] 是否存在关键业务不变量？
- [ ] 是否需要数据库唯一约束或 CHECK 约束？
- [ ] 是否需要事务？
- [ ] 是否存在并发写？
- [ ] 是否需要幂等？
- [ ] 是否需要状态机约束？
- [ ] 是否需要审计日志？
- [ ] 是否需要数据修复或补偿机制？
## Availability 可用性
- [ ] 是否属于核心链路？
- [ ] 是否存在外部依赖？
- [ ] 是否设置超时？
- [ ] 是否需要重试退避？
- [ ] 是否需要限流？
- [ ] 是否需要熔断或降级？
- [ ] 是否需要异步化或队列削峰？
- [ ] 是否配置监控和告警？
- [ ] 是否有备份和恢复方案？
|
11. 总结
CIA 三要素在软件工程中的价值，不是提供一个安全口号，而是提供一套系统性的设计框架。
1
2
3
| Confidentiality：权限、加密、脱敏、隔离，防止不该看的看到。
Integrity：校验、事务、约束、审计、幂等，防止不该改的改了，防止改错。
Availability：高可用、限流、熔断、备份、监控，保证该用时能用。
|
对于软件团队来说，最实用的做法是：
1
2
3
4
5
| 需求评审时问 CIA
技术设计里写 CIA
编码规范里落实 CIA
测试用例里验证 CIA
上线运维中持续监控 CIA
|
安全不是一个最后才加上的模块，而是一种系统质量。
系统设计如果不考虑 CIA，就像盖楼只看装修图，不看地基、承重和消防。短期看起来能住，长期就全靠玄学。软件工程不该靠玄学，尤其是生产系统。
参考资料
NIST CSRC Glossary: Confidentiality, Integrity, Availability
https://csrc.nist.gov/glossary/term/confidentiality_integrity_availability
NIST NCCoE SP 1800-26: Data Confidentiality — Executive Summary
https://www.nccoe.nist.gov/publication/1800-26/VolA/index.html
NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations
https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
OWASP Application Security Verification Standard, ASVS
https://owasp.org/www-project-application-security-verification-standard/
OWASP Session Management Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
OWASP Top 10 Web Application Security Risks
https://owasp.org/www-project-top-ten/