做资产清单的人八成会遇到同一件事花三周做出一张 300 行的 Excel交上去之后没人用。半年后再打开里面的机器已经有一半不存在了。所以这篇讲的不是「资产台账该怎么建」这种原则而是具体到字段每一列填什么、怎么校验、怎么自动生成。这不是「不够努力」的问题。清单失败通常是三个原因字段设计错了该有的没有不该有的填不满、没有校验机制同一个 IP 出现三次、责任人是运维部、没有维护触发点全靠想起来才更新。这篇给一套能直接抄的东西七类资产的字段表可复制成 CSV 直接导入、Excel 里的校验公式、一个从多源自动生成初版清单的脚本、分级判定标准与对应的防护矩阵以及维护触发点。你手上如果还没有清单照这个做一个下午能有初版。如果你刚接手团队、连从哪拿数据都不知道可以先看 甲方安全新人第一个月做什么那篇讲的是六个数据源怎么交叉。一、先定字段八列打底其余按类扩很多人做清单的第一反应是字段越全越好结果三十多列里有二十列是空的。原则应该是每加一个字段都要能说出它会被谁用来做什么决策。所有资产共用的八列底座字段类型取值约束谁用asset_id字符串全局唯一永不复用所有记录挂载点asset_name字符串与主机名/系统名一致与日志、告警对齐category枚举网络/服务器/应用/终端/账号/数据/其他决定用哪套基线ip字符串主 IP多个用逗号分隔与扫描结果对齐biz_owner字符串业务线名称判断影响面owner字符串具体到人不是部门派单、追责level枚举核心/重要/一般决定 SLA 与防护强度status枚举在用/闲置/待下线识别僵尸资产owner必须是具体人名这一条要死守。写部门等于没写出事时没人认。找不到 owner 的资产本身就是一条要上报的风险。在八列基础上每类资产加自己的专属字段。下面是七类的完整字段表可以直接当表头用。二、资产清单的七类字段表可直接复制2.1 网络资产字段说明示例device_model型号USG6650mgmt_ip管理 IP10.10.0.1macMAC 地址00:e0:fc:12:34:56location机房与机柜位置A 机房 3 号柜 U12firmware固件/系统版本V500R005C20config_backup配置文件备份路径/netcfg/fw-a-20261001.cfg网络设备最容易漏的是固件版本和配置备份。没有版本信息就判断不了有没有已知漏洞没有配置备份设备坏了要重建整份策略——这一条吃过亏的运维都会认。2.2 服务器资产字段说明示例host_type物理/虚机/云主机/容器宿主云主机os_version操作系统与版本CentOS 7.9cpu_mem_disk规格8C/16G/200Gruntime承载的中间件与运行时Nginx PHP 7.4patch_level最近一次补丁时间2026-09-20cloud_instance_id云上实例 ID云主机必填i-bp1xxxxxpatch_level这个字段看起来很麻烦但它是这台机器多久没管了的唯一量化依据。填不出补丁时间的机器基本就是没人管的机器。2.3 应用资产字段说明示例app_url访问地址多个入口全列出https://oa.example.comdeploy_ip部署服务器 IP关联 2.210.20.1.31port对外端口443dev_type自研/外包/商业产品外包vendor供应商外包/商业必填某软件公司version版本号v3.2.1internet_exposed是否公网可达是internet_exposed是我加的最有用的一列。它直接决定漏洞的处置时限——同样的高危公网可达的 3 天内缓解纯内网可以 14 天。没有这一列所有漏洞只能按同一个节奏追。2.4 终端资产字段说明示例device_type台式/笔记本/移动设备笔记本user_name使用人张三department部门财务部fixed_asset_no固定资产编号GD-2024-0187edr_installed是否装了 EDR 及版本是 / v6.2disk_encrypted是否磁盘加密是edr_installed为空或者为否的终端就是你终端防护的真实缺口。这个数字比终端覆盖率 96%更可信因为后者往往是按采购数算的。2.5 账号资产这一类最常被忽略但它是横向移动的关键。字段说明示例account_name账号名svc_backupaccount_type管理员/服务账号/普通/审计服务账号related_asset关联系统或设备备份服务器privilege_scope权限范围本地管理员password_rotation口令轮换周期90 天last_login最后登录时间2026-10-20is_shared是否共享账号否is_shared为是的账号要单独列出来。共享账号意味着出事后无法定位到人这是审计上的硬伤。last_login超过 90 天没变的账号要么该停要么该查——很可能人已经离职了但账号还在。2.6 数据资产字段说明示例data_name数据名称客户订单库data_level核心/重要/一般/公开核心storage_type数据库/文件/对象存储/本地数据库storage_location具体位置云 RDS 实例 rm-xxxxcontains_pii是否含个人信息是data_flow流转到哪些系统CRM、数据仓库retention保留期限3 年contains_pii这一列直接对应合规义务。含个人信息的库泄露了要报监管不含的处置等级完全不同。这一列填不准后面所有合规判断都是错的。2.7 其他资产密钥、证书、接口、代码仓库字段说明示例sub_type密钥/证书/API 接口/代码仓库证书related_biz关联业务或系统官网storage_path存放位置密钥管理服务 KMSexpire_date有效期证书/密钥必填2027-03-15rotation_owner轮换责任人李四expire_date是这类资产唯一真正重要的字段。证书过期导致业务中断比绝大多数攻击事件更常见而且完全可预防。三、把字段变成能落地的表字段定了之后别手工画 Excel。用下面这段 SQL 建表导出成 CSV 就是模板或者直接在 Excel 里按这个结构建七个 sheet。CREATE TABLE asset_inventory ( asset_id VARCHAR(32) PRIMARY KEY, asset_name VARCHAR(128) NOT NULL, category VARCHAR(16) NOT NULL CHECK (category IN (网络,服务器,应用,终端,账号,数据,其他)), ip VARCHAR(256), biz_owner VARCHAR(64) NOT NULL, owner VARCHAR(64) NOT NULL, level VARCHAR(8) NOT NULL CHECK (level IN (核心,重要,一般)), status VARCHAR(8) NOT NULL DEFAULT 在用 CHECK (status IN (在用,闲置,待下线)), ext JSON, -- 各类专属字段按 category 存不同结构 updated_at DATE NOT NULL );ext用 JSON 存专属字段是为了避免七类资产七张表、跨表查一次要 join 七次。查核心资产时一句 SQL 就够-- 核心资产里公网可达且超过 90 天没打补丁的优先处理 SELECT asset_id, asset_name, biz_owner, owner, ext-patch_level AS patch FROM asset_inventory WHERE level 核心 AND status 在用 AND ext-internet_exposed 是 AND (ext-patch_level IS NULL OR ext-patch_level to_char(CURRENT_DATE - INTERVAL 90 day, YYYY-MM-DD)) ORDER BY biz_owner, asset_name;这条查询就是本周该先修哪几台的答案。清单的价值不在于全而在于能回答这种问题。四、Excel 里的三个校验能挡掉八成脏数据用 Excel 维护的话至少配三个校验否则三个月后一定会出现同一个 IP 三条记录、责任人是运维部、状态是空白。校验一IP 唯一性。选中 IP 列 → 数据 → 数据验证 → 自定义 → 公式填COUNTIF($D:$D,D2)1再配一条出错提示该 IP 已存在。这一条能挡掉重复登记。校验二责任人不能是部门名。数据验证公式AND(LEN(F2)1,ISERROR(FIND(部,F2)))。填运维部直接报错逼着填人名。校验三核心资产必须有公网可达标记。条件格式AND($G2核心,ISBLANK($O2))时整行标黄。核心资产没标暴露面等于没定处置时限。三个校验都不复杂但它们把人工检查变成了填的时候就报错。后者才可持续。五、资产清单怎么从多源自动生成手工从零填 300 行不如先用脚本生成 80%剩下的靠人补。下面这段把云平台导出、DHCP 租约、扫描结果三份 CSV 合并成初版# 三份输入cloud.csv(实例ID,内网IP,实例名)、dhcp.csv(IP,MAC,主机名)、scan.csv(IP,开放端口) # 输出assets.csv按 IP 合并标出多源一致单源冲突三种状态 import csv from collections import defaultdict def load(path, key, fields): out {} with open(path, encodingutf-8-sig) as f: for row in csv.DictReader(f): k (row.get(key) or ).strip() if k: out[k] {f: (row.get(f) or ).strip() for f in fields} return out cloud load(cloud.csv, 内网IP, [实例ID, 实例名]) dhcp load(dhcp.csv, IP, [MAC, 主机名]) scan load(scan.csv, IP, [开放端口]) by_ip defaultdict(dict) for k, v in cloud.items(): by_ip[k].update(v); by_ip[k][src] by_ip[k].get(src, ) 云 for k, v in dhcp.items(): by_ip[k].update(v); by_ip[k][src] by_ip[k].get(src, ) DHCP for k, v in scan.items(): by_ip[k].update(v); by_ip[k][src] by_ip[k].get(src, ) 扫描 with open(assets.csv, w, encodingutf-8-sig, newline) as f: w csv.writer(f) w.writerow([IP, 主机名, 实例ID, MAC, 开放端口, 来源, 待确认]) for ip, v in sorted(by_ip.items()): src v.get(src, ).strip() note 多源一致 if src.count( ) 2 else 单源 w.writerow([ip, v.get(主机名, ), v.get(实例ID, ), v.get(MAC, ), v.get(开放端口, ), src, note]) print(生成 %d 条其中单源 %d 条需人工确认 % (len(by_ip), sum(1 for v in by_ip.values() if v.get(src, ).count( ) 2)))输出的待确认列就是你的工作清单。多源一致的可以直接入库单源的要逐个确认——这些往往是测试机、临时扩容、或者已经没人管的机器也是最有价值的那部分。六、容器和云资产怎么归进去这两类最容易漏也最容易填错。漏了它们清单看起来完整实际少了增长最快的那部分。容器不要单独建一类。容器是跑在宿主机上的进程单独建表会带来一个麻烦容器一重启 IP 就变你永远追不上。正确做法是把它作为服务器资产的附属信息记两列字段说明示例container_runtime容器运行时Docker / containerdcontainer_images运行的镜像及版本多个用分号app-api:v2.3.1; nginx:1.25镜像版本是关键。容器漏洞八成来自基础镜像你只要知道这台机器上跑着哪些镜像什么版本就能对应到已知漏洞。真正要单独管的是Kubernetes 集群本身——集群名、API Server 地址、节点数、谁有 kubeconfig。kubeconfig 的持有者名单实际上就是集群的管理员名单这个在出事时非常有用。云资产要按账号分组不能混在一张表里。一个集团往往有好几个云账号生产、测试、子公司各一个同一台虚机在不同账号下可能同名。做法是给 asset_id 加上账号前缀asset_id含义ali-prod-ecs-001阿里云生产账号的 ECSali-test-ecs-001阿里云测试账号的同名 ECS但是另一个资产hw-prod-obs-logs华为云生产账号的 OBS 桶另外云上有三类容易被忽略的资产必须显式登记对象存储桶最容易配成公共读写、快照与镜像含完整数据权限常比生产环境还松、RAM 子账号及其 AKAK 泄露等于账号被接管。这三类不登记清单就答不了我们有哪些数据可能被公开访问。云资产类型是否易漏必填的专属字段ECS/CVM 等虚机否实例 ID、VPC、安全组对象存储桶是桶名、访问策略私有/公共读/公共读写快照与自定义镜像是来源实例、创建时间、是否含敏感数据RAM 子账号与 AK是权限策略、AK 创建时间、是否启用 MFA负载均衡与 CDN是后端服务、证书 ID对象存储桶的访问策略这一列建议每季度核一次。这是最容易出事的配置也是核查成本最低的——控制台上看一眼就能确认。七、分级三条标准别用打分分级不需要评分模型。三条标准命中两条及以上算核心命中一条算重要都不中算一般停机是否直接影响收钱下单、支付、开票是否含个人信息或重要数据是否公网可达分级的目的不是给资产贴个标签是决定防护动作。下面是配套的防护矩阵分级之后照着做级别巡检漏洞时限认证备份日志核心每日高危 3 天缓解强制 MFA每日 异地集中采集 180 天重要每周高危 14 天强口令 关键系统 MFA每周集中采集 90 天一般每月高危 30 天强口令每月本地 30 天这张表是把清单和日常动作接起来的关键。没有它分级就只是个标签没人按它做事。八、维护靠触发点不靠自觉清单失败最常见的原因不是没人做是做完就没人更新。解决办法是给更新设触发点到点就必须动触发点动作谁做新系统上线上线前必须提交资产登记否则不予开通网络运维/安全资产报废状态改待下线90 天后删除记录运维人员离职其名下资产转移 owner账号停用HR 触发安全执行每月新增/变更资产核对与 DHCP、云平台对比差额安全每季度全量核对出差异报告安全 各业务第一条最重要也最难推。它需要 IT 流程配合——新系统申请网络资源时把资产登记作为一个卡点。推不动的话退一步做每月对比拿 DHCP 和云平台的当前列表跟清单 diff差额就是没登记的。# 每月核对当前实际 IP 与清单的差集两边都是排序后的 IP 列表 comm -13 (cut -d, -f4 assets.csv | tr , \n | sort -u) \ (cat dhcp_ips.txt cloud_ips.txt | sort -u) unregistered.txt wc -l unregistered.txt # 未登记数量unregistered.txt里的每一条都要有结论补登记、或者确认是废弃资产。这个动作每个月半小时能让清单的准确率维持在 90% 以上。资产清单这件事做一次不值钱能持续维护才值钱。而要能持续靠的不是决心是你有没有把更新嵌进别人的流程里。 
长河君 · 2026/10/29 1:35:25 · 阅读 1.2k 资产清单模板怎么设计？七类资产字段表 + Excel 校验 + 自动合并脚本
做资产清单的人八成会遇到同一件事花三周做出一张 300 行的 Excel交上去之后没人用。半年后再打开里面的机器已经有一半不存在了。所以这篇讲的不是「资产台账该怎么建」这种原则而是具体到字段每一列填什么、怎么校验、怎么自动生成。这不是「不够努力」的问题。清单失败通常是三个原因字段设计错了该有的没有不该有的填不满、没有校验机制同一个 IP 出现三次、责任人是运维部、没有维护触发点全靠想起来才更新。这篇给一套能直接抄的东西七类资产的字段表可复制成 CSV 直接导入、Excel 里的校验公式、一个从多源自动生成初版清单的脚本、分级判定标准与对应的防护矩阵以及维护触发点。你手上如果还没有清单照这个做一个下午能有初版。如果你刚接手团队、连从哪拿数据都不知道可以先看 甲方安全新人第一个月做什么那篇讲的是六个数据源怎么交叉。一、先定字段八列打底其余按类扩很多人做清单的第一反应是字段越全越好结果三十多列里有二十列是空的。原则应该是每加一个字段都要能说出它会被谁用来做什么决策。所有资产共用的八列底座字段类型取值约束谁用asset_id字符串全局唯一永不复用所有记录挂载点asset_name字符串与主机名/系统名一致与日志、告警对齐category枚举网络/服务器/应用/终端/账号/数据/其他决定用哪套基线ip字符串主 IP多个用逗号分隔与扫描结果对齐biz_owner字符串业务线名称判断影响面owner字符串具体到人不是部门派单、追责level枚举核心/重要/一般决定 SLA 与防护强度status枚举在用/闲置/待下线识别僵尸资产owner必须是具体人名这一条要死守。写部门等于没写出事时没人认。找不到 owner 的资产本身就是一条要上报的风险。在八列基础上每类资产加自己的专属字段。下面是七类的完整字段表可以直接当表头用。二、资产清单的七类字段表可直接复制2.1 网络资产字段说明示例device_model型号USG6650mgmt_ip管理 IP10.10.0.1macMAC 地址00:e0:fc:12:34:56location机房与机柜位置A 机房 3 号柜 U12firmware固件/系统版本V500R005C20config_backup配置文件备份路径/netcfg/fw-a-20261001.cfg网络设备最容易漏的是固件版本和配置备份。没有版本信息就判断不了有没有已知漏洞没有配置备份设备坏了要重建整份策略——这一条吃过亏的运维都会认。2.2 服务器资产字段说明示例host_type物理/虚机/云主机/容器宿主云主机os_version操作系统与版本CentOS 7.9cpu_mem_disk规格8C/16G/200Gruntime承载的中间件与运行时Nginx PHP 7.4patch_level最近一次补丁时间2026-09-20cloud_instance_id云上实例 ID云主机必填i-bp1xxxxxpatch_level这个字段看起来很麻烦但它是这台机器多久没管了的唯一量化依据。填不出补丁时间的机器基本就是没人管的机器。2.3 应用资产字段说明示例app_url访问地址多个入口全列出https://oa.example.comdeploy_ip部署服务器 IP关联 2.210.20.1.31port对外端口443dev_type自研/外包/商业产品外包vendor供应商外包/商业必填某软件公司version版本号v3.2.1internet_exposed是否公网可达是internet_exposed是我加的最有用的一列。它直接决定漏洞的处置时限——同样的高危公网可达的 3 天内缓解纯内网可以 14 天。没有这一列所有漏洞只能按同一个节奏追。2.4 终端资产字段说明示例device_type台式/笔记本/移动设备笔记本user_name使用人张三department部门财务部fixed_asset_no固定资产编号GD-2024-0187edr_installed是否装了 EDR 及版本是 / v6.2disk_encrypted是否磁盘加密是edr_installed为空或者为否的终端就是你终端防护的真实缺口。这个数字比终端覆盖率 96%更可信因为后者往往是按采购数算的。2.5 账号资产这一类最常被忽略但它是横向移动的关键。字段说明示例account_name账号名svc_backupaccount_type管理员/服务账号/普通/审计服务账号related_asset关联系统或设备备份服务器privilege_scope权限范围本地管理员password_rotation口令轮换周期90 天last_login最后登录时间2026-10-20is_shared是否共享账号否is_shared为是的账号要单独列出来。共享账号意味着出事后无法定位到人这是审计上的硬伤。last_login超过 90 天没变的账号要么该停要么该查——很可能人已经离职了但账号还在。2.6 数据资产字段说明示例data_name数据名称客户订单库data_level核心/重要/一般/公开核心storage_type数据库/文件/对象存储/本地数据库storage_location具体位置云 RDS 实例 rm-xxxxcontains_pii是否含个人信息是data_flow流转到哪些系统CRM、数据仓库retention保留期限3 年contains_pii这一列直接对应合规义务。含个人信息的库泄露了要报监管不含的处置等级完全不同。这一列填不准后面所有合规判断都是错的。2.7 其他资产密钥、证书、接口、代码仓库字段说明示例sub_type密钥/证书/API 接口/代码仓库证书related_biz关联业务或系统官网storage_path存放位置密钥管理服务 KMSexpire_date有效期证书/密钥必填2027-03-15rotation_owner轮换责任人李四expire_date是这类资产唯一真正重要的字段。证书过期导致业务中断比绝大多数攻击事件更常见而且完全可预防。三、把字段变成能落地的表字段定了之后别手工画 Excel。用下面这段 SQL 建表导出成 CSV 就是模板或者直接在 Excel 里按这个结构建七个 sheet。CREATE TABLE asset_inventory ( asset_id VARCHAR(32) PRIMARY KEY, asset_name VARCHAR(128) NOT NULL, category VARCHAR(16) NOT NULL CHECK (category IN (网络,服务器,应用,终端,账号,数据,其他)), ip VARCHAR(256), biz_owner VARCHAR(64) NOT NULL, owner VARCHAR(64) NOT NULL, level VARCHAR(8) NOT NULL CHECK (level IN (核心,重要,一般)), status VARCHAR(8) NOT NULL DEFAULT 在用 CHECK (status IN (在用,闲置,待下线)), ext JSON, -- 各类专属字段按 category 存不同结构 updated_at DATE NOT NULL );ext用 JSON 存专属字段是为了避免七类资产七张表、跨表查一次要 join 七次。查核心资产时一句 SQL 就够-- 核心资产里公网可达且超过 90 天没打补丁的优先处理 SELECT asset_id, asset_name, biz_owner, owner, ext-patch_level AS patch FROM asset_inventory WHERE level 核心 AND status 在用 AND ext-internet_exposed 是 AND (ext-patch_level IS NULL OR ext-patch_level to_char(CURRENT_DATE - INTERVAL 90 day, YYYY-MM-DD)) ORDER BY biz_owner, asset_name;这条查询就是本周该先修哪几台的答案。清单的价值不在于全而在于能回答这种问题。四、Excel 里的三个校验能挡掉八成脏数据用 Excel 维护的话至少配三个校验否则三个月后一定会出现同一个 IP 三条记录、责任人是运维部、状态是空白。校验一IP 唯一性。选中 IP 列 → 数据 → 数据验证 → 自定义 → 公式填COUNTIF($D:$D,D2)1再配一条出错提示该 IP 已存在。这一条能挡掉重复登记。校验二责任人不能是部门名。数据验证公式AND(LEN(F2)1,ISERROR(FIND(部,F2)))。填运维部直接报错逼着填人名。校验三核心资产必须有公网可达标记。条件格式AND($G2核心,ISBLANK($O2))时整行标黄。核心资产没标暴露面等于没定处置时限。三个校验都不复杂但它们把人工检查变成了填的时候就报错。后者才可持续。五、资产清单怎么从多源自动生成手工从零填 300 行不如先用脚本生成 80%剩下的靠人补。下面这段把云平台导出、DHCP 租约、扫描结果三份 CSV 合并成初版# 三份输入cloud.csv(实例ID,内网IP,实例名)、dhcp.csv(IP,MAC,主机名)、scan.csv(IP,开放端口) # 输出assets.csv按 IP 合并标出多源一致单源冲突三种状态 import csv from collections import defaultdict def load(path, key, fields): out {} with open(path, encodingutf-8-sig) as f: for row in csv.DictReader(f): k (row.get(key) or ).strip() if k: out[k] {f: (row.get(f) or ).strip() for f in fields} return out cloud load(cloud.csv, 内网IP, [实例ID, 实例名]) dhcp load(dhcp.csv, IP, [MAC, 主机名]) scan load(scan.csv, IP, [开放端口]) by_ip defaultdict(dict) for k, v in cloud.items(): by_ip[k].update(v); by_ip[k][src] by_ip[k].get(src, ) 云 for k, v in dhcp.items(): by_ip[k].update(v); by_ip[k][src] by_ip[k].get(src, ) DHCP for k, v in scan.items(): by_ip[k].update(v); by_ip[k][src] by_ip[k].get(src, ) 扫描 with open(assets.csv, w, encodingutf-8-sig, newline) as f: w csv.writer(f) w.writerow([IP, 主机名, 实例ID, MAC, 开放端口, 来源, 待确认]) for ip, v in sorted(by_ip.items()): src v.get(src, ).strip() note 多源一致 if src.count( ) 2 else 单源 w.writerow([ip, v.get(主机名, ), v.get(实例ID, ), v.get(MAC, ), v.get(开放端口, ), src, note]) print(生成 %d 条其中单源 %d 条需人工确认 % (len(by_ip), sum(1 for v in by_ip.values() if v.get(src, ).count( ) 2)))输出的待确认列就是你的工作清单。多源一致的可以直接入库单源的要逐个确认——这些往往是测试机、临时扩容、或者已经没人管的机器也是最有价值的那部分。六、容器和云资产怎么归进去这两类最容易漏也最容易填错。漏了它们清单看起来完整实际少了增长最快的那部分。容器不要单独建一类。容器是跑在宿主机上的进程单独建表会带来一个麻烦容器一重启 IP 就变你永远追不上。正确做法是把它作为服务器资产的附属信息记两列字段说明示例container_runtime容器运行时Docker / containerdcontainer_images运行的镜像及版本多个用分号app-api:v2.3.1; nginx:1.25镜像版本是关键。容器漏洞八成来自基础镜像你只要知道这台机器上跑着哪些镜像什么版本就能对应到已知漏洞。真正要单独管的是Kubernetes 集群本身——集群名、API Server 地址、节点数、谁有 kubeconfig。kubeconfig 的持有者名单实际上就是集群的管理员名单这个在出事时非常有用。云资产要按账号分组不能混在一张表里。一个集团往往有好几个云账号生产、测试、子公司各一个同一台虚机在不同账号下可能同名。做法是给 asset_id 加上账号前缀asset_id含义ali-prod-ecs-001阿里云生产账号的 ECSali-test-ecs-001阿里云测试账号的同名 ECS但是另一个资产hw-prod-obs-logs华为云生产账号的 OBS 桶另外云上有三类容易被忽略的资产必须显式登记对象存储桶最容易配成公共读写、快照与镜像含完整数据权限常比生产环境还松、RAM 子账号及其 AKAK 泄露等于账号被接管。这三类不登记清单就答不了我们有哪些数据可能被公开访问。云资产类型是否易漏必填的专属字段ECS/CVM 等虚机否实例 ID、VPC、安全组对象存储桶是桶名、访问策略私有/公共读/公共读写快照与自定义镜像是来源实例、创建时间、是否含敏感数据RAM 子账号与 AK是权限策略、AK 创建时间、是否启用 MFA负载均衡与 CDN是后端服务、证书 ID对象存储桶的访问策略这一列建议每季度核一次。这是最容易出事的配置也是核查成本最低的——控制台上看一眼就能确认。七、分级三条标准别用打分分级不需要评分模型。三条标准命中两条及以上算核心命中一条算重要都不中算一般停机是否直接影响收钱下单、支付、开票是否含个人信息或重要数据是否公网可达分级的目的不是给资产贴个标签是决定防护动作。下面是配套的防护矩阵分级之后照着做级别巡检漏洞时限认证备份日志核心每日高危 3 天缓解强制 MFA每日 异地集中采集 180 天重要每周高危 14 天强口令 关键系统 MFA每周集中采集 90 天一般每月高危 30 天强口令每月本地 30 天这张表是把清单和日常动作接起来的关键。没有它分级就只是个标签没人按它做事。八、维护靠触发点不靠自觉清单失败最常见的原因不是没人做是做完就没人更新。解决办法是给更新设触发点到点就必须动触发点动作谁做新系统上线上线前必须提交资产登记否则不予开通网络运维/安全资产报废状态改待下线90 天后删除记录运维人员离职其名下资产转移 owner账号停用HR 触发安全执行每月新增/变更资产核对与 DHCP、云平台对比差额安全每季度全量核对出差异报告安全 各业务第一条最重要也最难推。它需要 IT 流程配合——新系统申请网络资源时把资产登记作为一个卡点。推不动的话退一步做每月对比拿 DHCP 和云平台的当前列表跟清单 diff差额就是没登记的。# 每月核对当前实际 IP 与清单的差集两边都是排序后的 IP 列表 comm -13 (cut -d, -f4 assets.csv | tr , \n | sort -u) \ (cat dhcp_ips.txt cloud_ips.txt | sort -u) unregistered.txt wc -l unregistered.txt # 未登记数量unregistered.txt里的每一条都要有结论补登记、或者确认是废弃资产。这个动作每个月半小时能让清单的准确率维持在 90% 以上。资产清单这件事做一次不值钱能持续维护才值钱。而要能持续靠的不是决心是你有没有把更新嵌进别人的流程里。