适用范围与依据
区块链监控审计可以围绕系统运行记录、合约权限及其变更开展。监控关注持续发现变化，审计关注依据记录核对操作与授权是否一致。适用条件需要结合具体审计对象判断。
NIST SP 800-92讨论组织层面的安全日志基础设施和管理流程，可作为日志管理的通用参考。OpenZeppelin访问控制文档介绍合约所有权、角色授权及权限事件，可用于理解相关合约的权限审计。前者不是区块链专项标准，后者的具体机制也不能直接套用于所有区块链。
条件一：审计目标与权限规则明确
开展审计前，需要明确要核对什么，例如管理权限由谁持有、角色变更是否经过授权、敏感功能是否限制调用者。只有先确定正常授权范围，监控发现的变化才有可核对的依据。
单一管理员可以采用所有权模型；职责较多时，可以通过角色划分权限。审计不仅要关注能够执行某项操作的账户，也要关注能够授予或撤销该权限的管理账户，否则容易遗漏权限扩大的路径。
条件二：记录能够支持核查
审计所需记录应当能够获取，并覆盖所核查的时间与对象。例如核查角色变动，需要掌握相关授权、撤销记录以及必要的初始状态；记录不完整时，对历史权限的还原就存在限制。
OpenZeppelin基础AccessControl不支持链上枚举角色成员，可通过RoleGranted和RoleRevoked事件在链下追踪；需要链上枚举时，可采用相应扩展。因此，应先确认合约实际提供的查询与记录能力，再确定审计方式。
条件三：具备持续管理与处理能力
日志采集之后，还需要明确保存、访问、分析和维护责任。监控规则也应随权限设置和业务职责变化进行复核，使记录能够持续服务于核查，而不是仅被存储。
发现权限变化后，需要有人判断其是否符合授权安排，并保留核查结果。对承担多种角色的账户，应结合权限组合审查；最小权限原则可以帮助判断职责与授权是否匹配。
常见问题与适用边界
链上记录公开就足够了吗？公开记录提供了核查线索，但判断操作是否符合组织授权，仍可能需要业务规则和审批依据。地址及事件本身不能完整解释操作目的。
使用访问控制组件就代表审计通过了吗？组件提供权限约束机制，审计仍需检查实际配置、管理关系和权限变更。持续监控权限事件也不能替代对合约其他逻辑的安全审查。
记录不全时能否出具结论？可以说明已核实的范围及证据缺口，但不宜将局部记录推导为整个系统安全、全部操作合规或历史权限始终正确。