📚 课程目录第2章特权账号全景盘点

2. 特权账号全景盘点

特权账号治理的第一步不是“管”，而是“看清”。如果连系统里存在哪些账号、它们归谁所有、以什么方式被使用都不清楚，后续的最小权限收敛、会话审计、定期轮换都无从谈起。特权账号全景盘点的目标，是建立一份可追溯、可分类、可复核的账号资产台账，把散落在操作系统、数据库、网络设备、云平台、中间件和自动化脚本中的账号统一纳入视野。

盘点工作最容易犯的错误，是只盯着“人用的管理员账号”。实际上，真正难以治理、也最容易成为攻击跳板的，往往是那些没有明确归属、长期不轮换、被硬编码在配置里的机器类账号。因此本节按五类账号展开：人类账号、机器账号、服务账号、应用账号、应急账号。分类不是目的，分类是为了让每一类账号匹配不同的发现手段、责任归属和治理策略。

五类特权账号的识别特征

人类账号由自然人持有，通常与员工工号、邮箱或域账号绑定，具备交互式登录能力。识别特征是存在登录时间分布、来源 IP 变化、可关联到具体人员。典型对象包括域管理员、root、数据库 DBA、网络设备超级用户。治理重点是实名绑定、按需授权、会话录屏。

机器账号指由系统或设备自身持有、用于主机之间认证的账号，例如域内计算机账户、集群节点账户、Kubernetes 节点证书身份。它们通常数量庞大、命名有规律（如 HOST-01$），很少交互登录，但一旦被冒用可横向移动。

服务账号是操作系统或中间件为运行服务而创建的账号，如 svc_mysql、nginx、tomcat。特征是权限相对固定、随服务启动而使用、密码常写在服务配置或密钥库中。识别关键是把它与具体服务进程、监听端口关联起来。

应用账号是业务应用连接后端资源时使用的账号，如应用连接数据库的 app_user、调用 API 的客户端凭证。特征是出现在应用配置文件、连接池配置或密钥管理系统中，权限往往偏大且长期不变。

应急账号是为故障处置预留的“破窗”账号，如本地管理员、带外管理口账号、云平台 break-glass 账号。特征是平时禁用或封存，仅在紧急时启用。治理重点是启用审批、使用告警和用后立即复位。

盘点方法与工具组合

盘点不能只靠人工登记，也不能只靠单一工具。推荐采用“自动采集 + 交叉比对 + 人工确认”的三层方法。自动采集负责把各系统的账号原始数据拉出来；交叉比对负责发现同一账号在不同系统中的映射关系和异常；人工确认负责解决归属不清、用途不明的“灰色账号”。

在操作系统层面，Linux 可用 awk -F: '($3==0){print $1}' /etc/passwd 快速找出 UID 为 0 的超级用户，用 lastlog 和 last 判断账号是否长期未登录。Windows 域环境可用 PowerShell 查询：

Get-ADUser -Filter * -Properties LastLogonDate, MemberOf |
  Where-Object { $_.LastLogonDate -lt (Get-Date).AddDays(-90) } |
  Select-Object Name, SamAccountName, LastLogonDate

数据库侧，Oracle 可查 DBA_USERS 与 DBA_ROLE_PRIVS，MySQL 可查 mysql.user 与 mysql.db，重点标记拥有 SUPER、GRANT、FILE 等高危权限的账号。网络设备通过 SNMP 或配置备份解析出本地用户和权限级别。云平台则通过 IAM 凭证报告导出所有用户、角色和访问密钥，重点关注未启用 MFA 的账号和长期未使用的 AccessKey。

对于服务账号和应用账号，最有效的手段是“进程—账号—连接”关联分析。在 Linux 上执行 ps -eo user,pid,cmd 可看到每个进程的运行账号；结合 ss -tnp 可看到该进程建立的网络连接。如果发现某个服务账号正在连接数据库，就说明它同时承担了应用账号的角色，需要进一步确认是否应该拆分。代码仓库扫描则用于发现硬编码凭证，常用工具包括 gitleaks、trufflehog，扫描规则应覆盖密码、API Key、私钥、连接字符串等模式。

盘点结果台账与判断依据

盘点完成后，应形成一份账号台账，至少包含以下字段：账号名称、所属系统、账号类型、责任人、权限级别、最近登录时间、密码/密钥最近轮换时间、是否可交互登录、是否启用 MFA、发现来源、复核状态。台账不是一次性文档，而应作为持续运营的基线，每次变更后更新。

判断一个账号是否属于“高风险待治理”，可参考以下依据：拥有超级用户或等价权限；超过 90 天未使用但仍启用；密码超过 180 天未轮换；无法关联到明确责任人；同时具备交互登录和远程访问能力；出现在多个系统中且权限不一致。满足其中两条以上，就应列入优先治理清单。

盘点初期不要追求一次覆盖全部系统。建议先选取 2～3 个核心系统（如域控、核心数据库、云平台）做样板，跑通采集、比对、确认、入库的完整流程，再逐步扩展。样板阶段暴露出的字段缺失、责任人不明等问题，正是后续治理的重点。

应急账号在盘点中容易被遗漏，因为它们平时处于禁用状态，常规的“活跃账号”查询不会返回。必须单独建立应急账号清单，记录封存方式、启用审批人、启用后通知对象，并定期做“不实际启用”的桌面推演，确认流程仍然有效。

最后需要强调，盘点的价值不在于台账有多漂亮，而在于它能否回答三个问题：这个账号是谁的？它能做什么？它现在是否应该存在？当这三个问题都能被快速回答时，特权账号治理才真正有了可落地的基础。