TG咨询企业移动应用在托管终端上的授权审计，重点不是数一遍已安装的应用，而是核实人员、应用、数据和设备之间的访问关系：谁可以登录，能执行哪些操作，权限由哪里授予，离职或换岗后是否及时收回。审计应结合身份系统、应用自身的角色配置和终端管理策略，不能只看一份设备清单。
先划定审计范围
先列出纳入检查的移动应用、托管终端类型、用户群和管理系统。范围可从企业统一部署的应用开始，再补充经批准的业务应用；访客或个人设备是否纳入，应按组织的设备管理边界确定。Microsoft Intune、Jamf Pro 等产品可提供设备或应用管理信息，但它们显示的配置不一定等于应用内部的实际授权。
每个应用至少记录四项：应用负责人、用户或用户组、角色与可执行操作、授权来源。再标明终端合规要求，例如是否只允许受管理设备登录。这样能区分设备上的应用安装权限与账号对业务数据的访问权限。
按权限链逐层核验
从人员和账号开始
将在职人员、岗位或团队与应用账号及用户组对应，重点检查离职、转岗、临时协作和长期未使用账号。共享账号会让操作难以追溯，应确认是否能改为个人账号，并检查紧急备用账号是否有负责人和使用记录。
再看角色、数据和终端条件
逐项比对应用内角色与实际工作需要。使用 RBAC（基于角色的访问控制）时，检查角色是否绑定了过多功能；同时采用最小权限原则，只保留完成当前职责所需的访问。核对应用能访问的数据范围、导出或分享能力，以及终端策略是否限制不合规设备访问。若使用单点登录，还要分别检查身份提供方的组分配和应用自身的角色映射。
一套可执行的审计流程
- 导出清单：从身份系统、应用管理后台和终端管理平台分别导出账号、组、角色、设备及策略信息，记录导出日期、负责人和来源，避免把不同时间的数据直接混在一起。
- 建立对照表：按“人员—应用—角色—数据范围—设备条件”整理记录。标出无负责人账号、重复或过宽角色、离职人员残留权限，以及无法说明用途的例外授权。
- 向业务负责人复核：请负责人确认人员是否仍需访问、具体功能是否必要、例外何时到期。不能仅凭账号近期有登录记录就认定权限合理。
- 验证高风险权限：对管理员、批量导出、用户管理等能力，检查配置与实际访问结果是否一致。优先在测试账号或经批准的低风险环境验证，避免直接撤权影响业务。
- 整改并留证：按批准结果调整组成员、应用角色或终端条件；保留申请或审批依据、调整前后配置、执行人和时间。随后用目标账号复核允许与拒绝的访问场景。
- 跟踪例外：为临时权限登记原因、批准人和复查日期，到期时重新确认或收回，不让例外授权成为永久权限。
证据、频率与常见误区
审计日志用于追踪账号登录、角色变更和管理操作；设备管理记录则说明终端是否受管及符合哪些策略。两类记录不能互相替代。保存证据时应遵循组织的数据保留和隐私规则，限制审计材料的访问范围，并使用统一时区或明确记录时区，方便比对事件先后。
可按风险安排复核：管理员和敏感数据权限在发生人员变动或配置变更时及时检查，普通权限按组织设定的周期复核。没有条件做到全量人工核对时，可优先处理离职账号、特权角色、长期未复核的例外和外部协作账号，再扩大到其他用户。自动化报表能减少整理工作，但仍需业务负责人判断权限是否必要。
常见误区包括把“应用已从设备删除”当作账号权限已撤销，把“已加入受管设备”当作所有应用访问都安全，以及只保存最终名单而没有审批与变更记录。企业移动应用在托管终端上的授权审计要形成闭环：发现差异、确认责任人、完成调整、复核结果并留下可追溯记录。
常见问题
只检查终端管理平台够吗？
不够。还要核对身份系统和应用内部的账号、角色与数据权限；平台之间的组或角色映射也要验证。
审计发现权限过宽，能直接删除吗？
先确认业务用途和影响，再按组织审批流程调整。涉及管理员或关键操作的权限，应安排变更验证和必要的回退方案。
没有完整审计日志怎么办？
记录现有数据来源及缺口，先保存可获得的账号、角色、审批和配置变更证据，并制定补齐日志或改进流程的措施；不要把缺失记录推断成没有发生操作。
多久复核一次合适？
没有适用于所有组织的固定频率。可按数据敏感度、权限影响和人员变动频率制定周期，并在离职、转岗、重大配置变更时触发额外复核。