📚 课程目录第3章资产识别与分类

3. 资产识别与分类：摸清你的家底

做安全需求，第一步不是画架构图，也不是写威胁模型。你得先搞清楚——你到底在保护什么？

我见过不少团队，上来就列一堆安全功能，结果发现最核心的数据根本没被覆盖。说白了，你连家里有什么值钱东西都不知道，怎么装防盗门？

这一章，我们就聊聊怎么把系统里的关键资产一个个揪出来，给它们估值，再按机密性、完整性、可用性三个维度分好类。

很多人一提到资产，第一反应就是“用户数据”、“数据库”。这没错，但太窄了。

我个人习惯把资产分成三大类：

我在项目中遇到过一件事：一个支付系统，所有精力都花在保护交易数据库上。结果攻击者通过一个没锁的日志采集器，拿到了数据库的访问凭证。嗯，那个日志采集器，就是被大家遗忘的资产。

避坑指南： 我曾经在资产清单里漏掉了“测试环境的生产数据副本”。结果测试库被拖库，数据照样泄露。记住：数据在哪里，资产就在哪里，不管它是在生产环境还是测试环境。

资产识别出来之后，你得给它们排个优先级。不是所有资产都值得用核弹级别的保护。

我一般用三个维度来评估：

举个例子：

资产	业务影响度	合规要求	攻击吸引力	综合价值
用户支付卡号	高（无法交易）	PCI-DSS强制加密	极高（黑市高价）	关键
系统操作日志	低（不影响核心功能）	一般审计要求	低（价值有限）	普通
API网关配置	中（配置错误可导致服务中断）	无强制要求	中（可被用于横向移动）	重要

我的习惯： 我会给每个资产打一个1-5分的综合价值分。5分的资产，安全需求必须写得滴水不漏；3分以下的，用通用安全措施覆盖就行。别在低价值资产上浪费太多精力。

资产分好价值等级之后，还得按机密性（Confidentiality）、完整性（Integrity）、可用性（Availability）三个维度做精细分类。这才是写安全需求的关键输入。

你想想看，一个资产在三个维度上的要求可能完全不同：

我一般用下面的矩阵来记录：

资产名称	机密性等级	完整性等级	可用性等级	安全需求方向
用户密码哈希	高（不可泄露）	高（不可篡改）	中（可短暂不可用）	加密存储 + 完整性校验
商品价格表	低（公开数据）	高（改价就是损失）	高（影响交易）	防篡改 + 高可用架构
用户登录会话	高（会话劫持风险）	中（篡改影响有限）	高（用户无法登录）	加密传输 + 会话超时 + 冗余

为什么会这样分？因为同一个资产，在不同场景下，CIA的优先级不一样。比如商品价格表，机密性要求不高，但完整性要求极高——被人改了价格，公司直接亏钱。

    关键原则： 安全需求不是一刀切的。一个资产在CIA三个维度上的等级，决定了你要写什么样的安全控制措施。机密性高的，写加密需求；完整性高的，写校验和审计需求；可用性高的，写冗余和灾备需求。

说了这么多，到底怎么落地？我一般按下面几步走：

下面这张图，是我自己项目里常用的资产分类流程，你可以参考：

我记得有一次帮一个金融科技公司做安全评估。他们的核心系统是“用户账户服务”。

一开始，团队只把“用户余额数据”列为关键资产。我让他们按上面的流程重新走了一遍：

结果呢？他们之前只给“用户余额”做了加密和备份，但“风控规则”和“交易流水”几乎裸奔。我们补上了完整性校验和访问控制，后来真的拦住了一次内部人员的篡改尝试。

一个小技巧： 做资产识别的时候，拉上开发、运维、业务三方一起过。每个人看到的资产都不一样。我习惯用白板画数据流图，然后让大家往上面贴便签——谁贴的资产最多，谁请下午茶。

资产识别与分类，说白了就是回答三个问题：

这一步做扎实了，后面的威胁建模和安全需求编写，才有根有据。别嫌麻烦，磨刀不误砍柴工。