21、应用系统访问控制测评解读

GB/T 22239-2019 8.1.4.2 访问控制在业务应用系统上的逐条解读：a)~g) 七项要求在应用层的落地形态、核查方法、水平与垂直越权测试、判定标准与常见误判。
Categories:

  2 分钟阅读  

定位：应用系统「访问控制」控制点（8.1.4.2）七项要求的测评理解与判定口径，面向业务应用系统测评。 配套测评：11、新员工网络培训考核（模拟环境样例）；配套加固：20、应用系统安全加固；高风险口径：22、高风险判定指引与加固对照表。 适用：GB/T 22239-2019 安全计算环境-访问控制，三级系统；B/S 与 C/S 架构均适用，架构差异见各节判定提示。

使用说明：

  • 本文所有命令均为只读取证命令，不修改配置、不重启服务、不执行清除类操作；确需变更由被测单位运维方在授权下实施。
  • 命令回显本身即证据，须连同命令行一起截图；示例中的地址、账户、路径均为演示值，现场须替换为真实取证结果，并对个人信息与内网管理地址脱敏后再入报告。
  • 命令不存在或输出与示例差异较大时，先确认产品版本与部署形态（单机/集群/容器/云托管），再换用等效命令或转入配置文件、管理控制台取证，不得据命令缺失直接判不符合。
  • 文中「默认」「一般」等表述均为初判倾向，须经上机核查 + 访谈 + 配置/制度核对三方印证后定论，并在报告中写明取证来源。

不适用标识说明：

  • 使用 【不适用】 明确标记现场可判定为不适用的控制点，并写明判定依据。
  • 依据 GB/T 28448-2019「按测评对象实际承载功能与数据处理范围判定」原则：控制能力由上层应用、统一认证平台、前置代理、堡垒机、宿主操作系统或云托管平台承载时，应注明测评单元边界后判定不适用或转由上位组件核查，不得机械按缺失判不符合。
  • 产品版本确实不提供该能力（如社区版无审计插件）时，须核查替代措施并按替代措施的实际效果定档，不得直接判不适用。

一、测评项

对应控制点：GB/T 22239-2019 8.1.4.2 访问控制 a)~g)

判定要点：账户与权限一一对应、默认账户已处置、无多余与共享账户、管理权限已分离、有书面授权策略、授权粒度达到用户级与表级 → 符合；有权限划分但存在越权高权限账户或粒度仅到角色级 → 部分符合；统一使用超级账户或应用账户持最高权限 → 不符合。

取证要求：账户与角色对照表、权限清单查询输出、默认账户处置记录、访问控制策略文件与授权审批记录、粒度核查（对象级/列级/行级）输出。

项要求
a)应对登录的用户分配账户和权限
b)应重命名或删除默认账户，修改默认账户的默认口令
c)应及时删除或停用多余的、过期的账户，避免共享账户的存在
d)应授予管理用户所需的最小权限，实现管理用户的权限分离
e)应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则
f)访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级
g)应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问

二、测评项 a) 应对登录的用户分配账户和权限

2.1 要求理解

字面看"用户都登录了自然就有账户"似乎无意义，实际要求的是：系统应存在多个账户， 并按职责把不同权限的账户分配给不同的使用者（自然人），即"权限通过账户分配给用户"。

因此本项的最低取证要求是：系统中至少存在两个账户，且这两个账户的权限不同。

2.2 常见缺陷

  • 系统完全缺乏访问控制：未登录即可直接访问后台地址（可直接判不符合，且常伴高风险）；
  • 系统只有一个账户；
  • 系统有多个账户但代码中没有权限分配机制，所有账户权限完全一致。

核查方法：导出系统账户清单，核查账户数量与各自权限；用不同权限账户登录对比功能菜单/接口；实测未登录或低权限直接访问后台地址/接口是否被拒。

2.3 判定标准

结论条件
符合存在多个账户、权限按职责差异化分配、无未授权可访问的后台入口
部分符合有账户与权限分配但粒度粗放；或存在个别未纳入权限控制的后台 URL
不符合单账户、多账户同权限、或未登录可访问后台功能

证据留存：账户清单截图、不同权限账户登录后功能菜单/接口对比截图、未登录访问后台地址的验证截图。

三、测评项 b) 应重命名或删除默认账户，修改默认账户的默认口令

核查方法：检查是否存在 admin、system、administrator、root、test 等常见默认用户名。

判定标准

结论条件
符合不存在常见默认账户名，或已重命名/删除且口令已改为强口令
部分符合默认账户已改名但口令仍为弱口令
不符合存在默认账户且沿用默认口令（高风险）

两点实践提示：

  1. 只要出现 admin/system 等常见默认名，不论其是否真的是出厂默认用户， 多数测评机构都会按不完全符合处理并要求改名；
  2. 有些应用不使用 admin 这类通用名，但该产品所有客户的初始用户名都相同（如产品特有的固定管理员名）， 同样属于默认账户，也应改名。

证据留存：账户清单截图、默认账户重命名/停用记录、口令强度核查记录、访谈纪要。

四、测评项 c) 应及时删除或停用多余的、过期的账户，避免共享账户的存在

核查方法：重点核查管理员账户与后台账户，逐一核对台账与在职/在用情况。

判定标准

结论条件
符合无多余、过期、共享账户，账户与自然人一一对应并有用途说明
部分符合存在个别长期未登录但仍在用的账户，且无停用机制
不符合存在离职人员账户未停用、或明确的共享账户（一个账户多人使用）

实际测评中本项对一般业务系统多为符合；风险集中在外包人员账户与历史运维账户上， 应索取账户台账与在职/离职比对记录。

证据留存：账户台账与在职/离职比对记录、停用/删除操作记录、访谈纪要。

五、测评项 d) 应授予管理用户所需的最小权限，实现管理用户的权限分离

核查方法：导出管理角色与权限分配清单，核查是否按业务角色细分并落实最小权限；抽查是否存在权限集中于单一管理账户、管理角色互不制约的情形。

判定标准

结论条件
符合权限按业务角色细分并落实最小权限，管理用户之间权限相互制约
部分符合权限分配粒度粗（如仅"普通用户/后台用户"两类），无法满足最小权限
不符合全部管理功能集中于单一账户，无任何权限分离

业务复杂度是重要参考：医院 HIS、财务系统等业务本身就要求细粒度权限，通常可判符合； 而小型系统若只有"普通用户 + 后台用户"两类角色，则只能往部分符合甚至不符合方向判定。

证据留存：管理角色与权限分配清单、权限分离配置截图、岗位职责与权限对照表。

六、测评项 e) 应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则

核查方法：确认系统内存在授权主体（超级管理员/系统管理员）专门负责权限策略的配置， 且策略表达为"主体（用户/角色）对客体（功能/数据）的访问规则"。

判定标准

结论条件
符合存在明确的授权主体与权限配置功能，策略以主体-客体规则形式表达，并有授权审批记录
部分符合有配置功能但无授权审批流程
不符合无权限配置功能（权限写死在代码中）

本项通常可判符合，但须索取授权审批记录作为管理流程证据，不能仅凭"系统里有这个功能"下结论。

证据留存：授权主体与权限配置功能截图、授权审批记录、策略文件。

七、测评项 f) 访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级

核查方法：核查授权模型是否支持用户级授权（7.1）、客体到表单/菜单/按钮级（7.2），并按 7.3 所述做越权实测验证后端鉴权。

7.1 主体粒度：用户级

多数应用采用「角色拥有权限 → 用户属于角色 → 用户获得权限」的 RBAC 模型。 严格来说，要达到用户级粒度，系统还应支持把某个具体权限直接赋予某个具体用户 （而非只能通过调整角色来间接调整，因为角色下往往有多个用户）。

判定标准

结论条件
符合支持直接对用户授权（或 RBAC + 用户级例外授权）
部分符合仅支持角色级授权，调整权限必须调整整个角色
不符合无任何权限分配机制

实践中不必过度深究：主流 RBAC 系统通常按"符合"或"部分符合"处理， 只有在权限模型明显粗放（如角色不可配置）时才判部分符合。

7.2 客体粒度：表级

不是跑到数据库里查表，而是在应用系统中判断：应用的表单页面大致对应数据库中的一张表 （如个人信息表、业务表）。因此本项核查的是能否对表单页面的访问权限进行分配（功能栏/菜单栏授权）。

判定标准：能对表单（页面/菜单）级资源进行授权 → 符合； 做得更细的系统可到按钮级（如新增/删除/导出按钮分别授权），属加分项； 仅能做整站级开关（能进或不能进） → 部分符合。

7.3 访问控制的表现与验证（重点）

限制用户权限在系统中有两种表现：

方式一：无权限的栏目/菜单直接不显示

  • C/S 架构：通常没有问题——除非该表单实际上是另一个 exe 窗口，而 exe 内部未做权限判定 （仅靠主程序隐藏入口），此时绕过主程序直接打开该 exe 即可越权；
  • B/S 架构：必须实测。先用有权限的账户登录并记录表单 URL， 再换无权限账户登录，直接访问该 URL 看是否成功。若表单通过 ajax 加载， 需找到对应接口，在登录后用 $.get()/$.post() 或接口调试工具直接调用验证。

方式二：按钮/菜单仍显示但为禁用态

  • 同样要验证后端是否做了权限控制，而非仅前端置灰。 前端禁用只是界面表现，接口未校验即构成越权漏洞。

证据留存：不同权限账户的功能菜单对比截图、直接访问受限 URL 的结果截图、 接口越权测试的请求与响应截图（脱敏后）。

八、测评项 g) 应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问

核查方法：核查系统是否具备安全标记（密级/范畴标签）配置能力与基于标记的访问控制机制；若声称已实现，抽查带标记资源的越权访问是否被拒。

判定标准：应用系统需为主体与客体设置安全标记（密级、范畴等），并基于标记实施访问控制。

实践中几乎没有应用系统实现本项，通常判不符合。 仅当系统具备明确的数据分级分域功能（如按密级标签控制访问的数据安全平台）时才可能判符合。

证据留存：安全标记配置或数据分级分域功能说明、越权访问测试记录、访谈纪要。

测评项对照表

项核心判据常见结论
a)至少两个账户且权限不同；无未授权后台入口多为符合；无权限分配机制则不符合
b)无 admin/system 等默认名，默认口令已改存在默认名即部分符合起；默认口令未改为高风险
c)无多余/过期/共享账户，重点查外包与历史运维账户多为符合
d)管理用户权限分离、最小权限小系统常部分符合
e)有授权主体 + 主体-客体规则 + 审批记录多为符合（须取审批记录）
f)主体到用户级、客体到表单/表级；越权测试验证后端鉴权RBAC 多为符合；仅角色级授权为部分符合
g)安全标记与基于标记的访问控制几乎均不符合

参考依据

  • GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》（8.1.4 安全计算环境各控制点）：http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=BAFB47E8874764186BDB7865E8344DAF
  • GB/T 28448-2019《信息安全技术 网络安全等级保护测评要求》（测评对象边界认定、单元测评实施与结果判定：符合/部分符合/不符合/不适用）：http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=7E736CDF4502B6FF1258DD250AA3EC8C
  • GB/T 25070-2019《信息安全技术 网络安全等级保护安全设计技术要求》，可在全国标准信息公共服务平台检索：http://openstd.samr.gov.cn/bzgk/gb/
  • GB/T 28449-2018《信息安全技术 网络安全等级保护测评过程指南》（现场测评活动与证据留存要求），可在全国标准信息公共服务平台检索：http://openstd.samr.gov.cn/bzgk/gb/
  • OWASP Authorization Cheat Sheet：https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
  • OWASP Testing Guide — Authorization Testing：https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/
  • 《网络安全等级保护测评高风险判定指引》（中关村信息安全测评联盟团体标准）——高风险情形判定口径，站内对照表：22、高风险判定指引与加固对照表
  • 命令核验说明：本篇为控制点解读页，不绑定具体产品命令。应用层访问控制的核查方法参照 OWASP Authorization Cheat Sheet 与 OWASP Web Security Testing Guide 的授权测试章节，判定口径依据 GB/T 22239-2019 8.1.4.2 与 GB/T 28448-2019 三级测评要求整理（核验日期 2026-09-02）。取证要点：① 越权测试须覆盖水平越权（同角色用户 A 通过替换 ID/参数访问用户 B 数据）与垂直越权（低权限账户直接请求管理接口），两类测试均须以两个真实账户实操并截图，仅看代码或仅听开发方说明不构成有效证据；② 权限校验须确认在服务端完成，前端隐藏菜单与按钮不构成访问控制；③ 粒度须达到用户级与数据对象级（表/记录/字段），仅按角色粗放授权且角色内可互访全部数据时按部分符合定档；④ 安全标记（g 项）在多数业务应用中无实现，须核查是否由数据库强制访问控制或操作系统承担，未实现时判不符合而非不适用；⑤ 权限分离（d 项）须核查系统管理、安全管理、审计管理是否由不同应用账户承担且互不兼任。

关联文章