2. 云环境资产测绘与分类分级
云上资产测绘与传统IDC资产盘点最大的区别在于：资产不再由物理机箱和网线端口定义，而是由云账号、资源ID、标签和API调用关系定义。一个典型企业云账号里，可能同时存在ECS实例、RDS数据库、OSS存储桶、SLB负载均衡、VPC网络、安全组、RAM角色、KMS密钥、容器集群等十余类资源。如果只靠控制台逐页翻看，既无法保证完整性，也无法判断哪些资产承载敏感数据。因此，本节要解决三个问题：资产怎么发现、标签怎么组织、数据怎么分类分级，并最终落到一份可执行的资产清单与敏感数据识别任务上。
一、资产发现：从API枚举到关系补全
云资产发现的第一原则是“以API为准，不以人工台账为准”。主流云厂商都提供资源查询接口，例如阿里云的DescribeInstances、DescribeDBInstances、ListBuckets，AWS的DescribeInstances、ListBuckets、DescribeDBInstances。实际操作中，建议按“区域—资源类型—分页”三层循环拉取，避免遗漏跨区域资源。以下是一个简化的枚举思路：
for region in regions:
for resource_type in ["ecs","rds","oss","slb","vpc","k8s"]:
page = 1
while True:
resp = client.describe(resource_type, region, page)
save_to_inventory(resp.items)
if not resp.next_page: break
page += 1
仅枚举资源还不够，还要补全关系。例如ECS实例属于哪个VPC、绑定了哪些安全组、挂载了哪些云盘、是否关联RAM角色；OSS桶是否开启了公共读、是否被CDN回源；RDS实例是否在公网可达。这些关系决定了后续风险判断。建议在资产清单中至少保留以下字段：资源ID、资源类型、所属账号、地域、可用区、名称、标签、创建时间、公网暴露状态、关联安全组、数据敏感度初判。
二、标签体系：让资产“自带上下文”
标签是云上资产治理的骨架。没有标签，资产清单只是一堆ID；有了标签，才能按业务、环境、负责人、数据等级快速筛选。一个可落地的标签体系通常包含四类维度：
- 业务维度：
business，如电商、支付、风控； - 环境维度：
env，如prod、staging、dev； - 负责人维度：
owner，如团队邮箱或工号； - 数据维度：
data_level，如L1公开、L2内部、L3敏感、L4核心。
标签设计要避免两个极端：一是标签太少，无法区分；二是标签太多，无人维护。建议采用“强制标签+可选标签”策略：创建资源时必须打上business、env、owner、data_level四个强制标签，否则拒绝创建。对于存量资源，可以通过脚本批量补标，例如按资源名称前缀匹配业务线，再按VPC归属推断环境。
三、数据分类分级：从“有什么”到“多敏感”
数据分类分级是云安全架构中承上启下的环节。分类回答“这是什么数据”，分级回答“泄露后影响多大”。常见做法是先把数据分为若干大类，如个人信息、业务数据、财务数据、运维数据、公开数据；再按影响程度分为四级：
| 级别 | 定义 | 典型示例 | 保护要求 |
|---|---|---|---|
| L1 公开 | 可对外公开，泄露无影响 | 官网图片、公开文档 | 完整性校验 |
| L2 内部 | 仅内部使用，泄露影响有限 | 内部通知、非核心日志 | 访问控制 |
| L3 敏感 | 泄露造成较大影响 | 手机号、订单、员工信息 | 加密+审计 |
| L4 核心 | 泄露造成严重或合规风险 | 身份证、银行卡、密钥 | 加密+脱敏+最小权限 |
分级不是拍脑袋，而是结合数据内容、数据量、业务关联、合规要求四个因子。例如一个OSS桶里存了10万条用户手机号，即使单条看只是L3，但聚合后可能达到L4影响。实际操作中，可以用正则和采样扫描来识别敏感字段：手机号匹配1[3-9]\d{9}，身份证匹配\d{17}[\dXx]，银行卡匹配\d{16,19}。扫描结果只做标记，不落原文，避免二次泄露。
四、典型任务：完成一个云账号的资产清单与敏感数据识别
假设某企业有一个生产云账号，包含3个VPC、12台ECS、2个RDS、5个OSS桶、1个SLB、1个K8s集群。任务目标是产出一份资产清单，并标记出敏感数据所在位置。可按以下顺序执行：
- 枚举资源：调用各资源API，导出JSON，统一转换为CSV，字段包括资源ID、类型、地域、名称、标签、公网IP、安全组。
- 补全关系：通过VPC列表关联ECS和RDS，通过SLB后端服务器组关联ECS，通过OSS桶策略判断是否公共读。
- 标签校验：检查每个资源是否具备四个强制标签，缺失的标记为“待补标”，并通知owner。
- 敏感扫描：对RDS和OSS进行采样扫描，识别手机号、身份证、银行卡等字段，记录命中表名、字段名、命中数量级，不记录具体值。
- 分级判定：根据命中字段和数量，给出L1~L4建议等级，例如“用户表-手机号-10万条”建议L4，“日志表-无敏感字段”建议L2。
- 输出清单：生成资产清单表，包含资源ID、标签、数据等级、保护措施建议、负责人。
五、结果判断与常见问题
任务完成的判断标准不是“清单文件生成了”，而是三个可验证的结果：资产覆盖率100%（与云监控资源总数一致）、强制标签覆盖率≥95%、敏感数据位置可定位到具体资源与字段。如果发现某OSS桶无法判断是否公共读，应优先检查桶策略和ACL，而不是跳过。常见问题包括：跨区域资源遗漏、标签拼写不一致（如prod与Prod）、RDS只读实例未纳入清单、K8s内Pod挂载的Secret未纳入数据分级。解决方法是把“资源枚举”和“数据扫描”做成可重复执行的脚本，每次运行都输出差异报告，而不是依赖人工记忆。
最后需要强调：资产测绘与分类分级不是安全团队的独角戏。业务团队负责确认数据等级，运维团队负责补全标签，安全团队负责扫描与校验。只有把标签作为创建资源的强制门槛，把分级结果接入加密、脱敏和权限策略，资产清单才真正具备安全价值。