未授权访问的共同模式
内网里绝大多数「服务未授权」问题都满足同一个模式：服务监听在可达地址上、没有开启认证、且业务与办公网可以直连。典型对象是数据库、缓存、消息队列、容器与编排接口，还有一些自带管理页面的中间件。这类问题的处置顺序很清晰：先建一张清单把服务、地址、认证状态与数据敏感度填清楚，再按暴露面与数据等级排优先级逐类收敛。
基本信息
| 常见对象 | MySQL、Redis、消息队列、容器编排接口、中间件管理台 |
|---|---|
| 判定方式 | 无需凭据即可读取数据或修改配置 |
| 取证纪律 | 只记录可读或可写结论，不导出业务数据 |
| 收敛路径 | 监听内网 + 开启认证 + 管理面隔离 + 访问审计 |
| 优先级依据 | 数据敏感度、可达范围、是否有写权限 |
典型使用场景
- 内网评估的整体收口：把分散的服务暴露问题汇总成一张表
- 为整改排期提供依据：按数据敏感度与可达范围分级
- 验证「仅监听回环」与「全网可达」的差异，避免误报
- 核查容器与编排接口的暴露：这类接口往往直接等价于主机权限
- 修复验证：确认认证已开启且监听地址已收敛
清单模板
清单模板
服务 | 地址 | 端口 | 认证状态 | 数据敏感度 | 整改优先级
MySQL | 10.0.20.11 | 3306 | 未认证可读 | 高 | 高
Redis | 10.0.20.5 | 6379 | 未认证可读 | 中 | 高
RabbitMQ 管理台 | 10.0.30.8 | 15672 | 默认口令 | 中 | 中
# 记录原则：只写结论（可读/可写/需凭据），不导出业务数据作为证据结论分级
| 认证状态 | 数据敏感度 | 建议优先级 |
|---|---|---|
| 无认证且可写 | 高 | 紧急：可导致数据篡改与横向移动 |
| 无认证但只读 | 高 | 高：直接构成数据泄露 |
| 默认口令或弱口令 | 任意 | 高：等同无认证，且暴露了配置能力 |
| 需凭据才能访问 | 任意 | 低：纳入基线管理即可 |
只记录「可读或可写」的结论，不导出业务数据作为证据：证据充分性与数据最小化之间，优先选择后者。
仅监听回环地址的服务不算暴露：核查前先确认监听地址与可达范围，避免把本地服务误判成暴露面。