一、ISO/IEC 27017:2015 9.4 标准原文
ISO/IEC 27017:2015 9.4 系统和应用访问控制
条款原文：本条补充要求：客户应确保能够按自身访问控制策略限制对云服务、云服务功能以及其中客户数据的访问；提供商应提供相应的访问控制能力。标准还提示，管理控制台、虚拟化管理功能等云特有功能也需要额外访问控制；若允许使用可绕过正常流程的实用程序，则客户和提供商都应明确限制和审计要求。
条款原文：本条补充要求：客户应确保能够按自身访问控制策略限制对云服务、云服务功能以及其中客户数据的访问；提供商应提供相应的访问控制能力。标准还提示，管理控制台、虚拟化管理功能等云特有功能也需要额外访问控制；若允许使用可绕过正常流程的实用程序，则客户和提供商都应明确限制和审计要求。
提示：完整原文请参阅 ISO/IEC 27017:2015 正式文本
引用：9.4解决的是“即使登录成功，也不代表什么都能做”。
二、条款解读说明
2.1 云访问控制的难点，不是“有没有账号”，而是控制边界已经扩展到控制台、API、联合身份和共享环境。
云服务中的访问控制比传统系统更强调多层边界：普通用户、管理员、自动化脚本、联合身份源、管理接口、服务功能、租户数据和特权工具都可能形成独立控制面。本条要求组织不仅要有访问策略，还要能够把注册、授权、认证、复核、撤销和技术限制落到云服务的真实接口和真实角色上。就本条而言，组织尤其需要把信息访问限制、控制台与管理接口和特权工具使用放进同一套判断框架，而不是分散给不同团队各自理解。
2.2 核心关注点
| 关注点 | 条款要求 | 常见失效表现 | 正确做法 |
|---|---|---|---|
| 信息访问限制 | 本条要求组织在云场景下把信息访问限制纳入正式控制范围 | 边界不清，团队往往默认由平台或他人负责 | 先定义责任、范围和最小控制要求 |
| 控制台与管理接口 | 本条要求组织在云场景下把控制台与管理接口纳入正式控制范围 | 要求存在于文件中，但没有落到流程和配置 | 把要求写入制度、协议、配置或审批流程 |
| 特权工具使用 | 本条要求组织在云场景下把特权工具使用纳入正式控制范围 | 证据不足，审核或事件发生时无法还原事实 | 保留可验证记录，并建立周期复核机制 |
| 细粒度功能授权 | 本条要求组织在云场景下把细粒度功能授权纳入正式控制范围 | 与相邻条款脱节，形成控制孤岛 | 与前后条款联动，形成闭环控制链条 |
2.3 云场景下的管理重点
访问控制在云场景下最容易失效的地方有三个：一是把平台默认权限当成合规权限；二是只管理人，不管理API密钥、服务账号和联合身份；三是只看能否登录，不看登录后可调用哪些功能。结果就是访问看似受控，实际上高权限面、旁路接口和共享环境仍存在大量盲区。对于9.4而言，如果组织只停留在条文理解层，而没有把信息访问限制、控制台与管理接口、特权工具使用转化为流程、配置和证据，那么控制看似存在，实际运行中依旧会出现大量灰区。
2.4 与前后条款的衔接
本条并不是孤立存在，它与9.2账号管理、13.1网络控制、CLD.9.5共享虚拟环境控制和12.4特权日志紧密相连。实务中，只有把本条输出持续回灌到制度、采购、变更、审计和退出场景中，组织才能证明自己不仅理解了条款，还真正用条款重塑了云服务治理方式。
注意：云访问控制若只停留在登录层，而不细化到功能层和数据层，越权风险会被长期隐藏。
三、实施要点
3.1 先把责任和适用范围说清楚
- 明确信息访问限制在客户侧、提供商侧和共享责任侧分别由谁承担。
- 将控制台与管理接口写进制度、协议或服务说明书，避免只靠口头理解。
- 对高风险场景设置触发条件，出现重大变更、事件或业务调整时及时复核。
3.2 把条款要求落到流程和技术控制
- 围绕信息访问限制和特权工具使用建立审批点、配置基线或标准操作步骤。
- 避免仅有原则性要求而没有实际执行动作和系统留痕。
- 对例外场景设置期限、补救措施和复核责任。
3.3 建立持续监视和复核机制
- 通过日志、报表、抽查、演练或会议机制持续观察控制台与管理接口是否按预期运行。
- 将发现的问题与整改计划、责任人和完成时限对应起来。
- 不要只在认证前集中补证据，应让记录随运行自然产生。
3.4 与前后条款联动形成闭环
- 将本条输出纳入以下控制链：9.2账号管理、13.1网络控制、CLD.9.5共享虚拟环境控制和12.4特权日志
- 在管理评审、内部审查或供应商评审中定期检查本条的有效性。
- 将经验教训回灌到制度、培训和技术基线更新中。
四、常用工具与实施方法
| 工具/方法 | 适用场景 | 实施重点 | 关键输出 |
|---|---|---|---|
| IAM权限矩阵 | 定义不同角色可访问的服务和功能 | 区分普通用户、管理员、审计员和自动化账号 | 权限矩阵 |
| MFA与强认证策略 | 强化高风险访问 | 把管理员和特权操作纳入更高认证要求 | 认证策略 |
| SSO/联合身份配置 | 连接云服务与企业身份源 | 减少孤立账号并统一生命周期管理 | 接入记录 |
| 权限复核台账 | 定期检查授权是否合理 | 结合岗位变化、项目结束和异常行为复核 | 复核记录 |
| 访问日志与异常分析 | 监测异常访问和越权行为 | 重点关注控制台、API和特权操作 | 分析报告 |
五、典型案例
案例1：平台默认角色过宽，业务团队误用高权限
- 背景：某团队直接使用云平台默认管理员角色处理日常任务，结果多个成员拥有远超职责需要的权限。
- 改进：组织按访问矩阵重构角色后，把高权限分离、审批和MFA一起纳入控制。
- 启示：案例说明组织需要围绕系统和应用访问控把责任、流程、配置和记录四个层面同时做实。
案例2：联合身份未打通，离岗账号在云端残留
- 背景：企业内部账号已停用，但某些SaaS和云平台仍保留本地独立账户和API密钥。
- 改进：通过SSO和生命周期管理对接，组织把身份治理从本地延伸到了云端。
- 启示：案例说明组织需要围绕系统和应用访问控把责任、流程、配置和记录四个层面同时做实。
六、成文信息管理要求
审核本条时，通常会同时查看制度文件、协议或系统配置、运行记录以及例外和复核记录。换言之，本条需要用“文件+动作+证据”三类材料共同证明，而不是只靠一份制度文本。
- 建议保留的成文信息
- 与系统和应用访问控制相关的制度、流程或控制说明文件
- 围绕信息访问限制、控制台与管理接口形成的配置、审批、评审或检查记录
- 与云服务提供商沟通、确认和举证所需的协议、说明书、报告或工单记录
- 定期复核、抽查、演练或例外审批的闭环记录
- 证明本条与相关条款衔接关系的映射表、说明材料或评审纪要
- 管理要求
- 记录应与真实云服务、真实角色和真实操作场景一一对应，避免模板化泛写。
- 出现重大变更、重大事件或服务模式调整后，应及时更新并保留版本痕迹。
- 相关文件和记录应按组织文件控制要求统一管理，便于审核、追溯和复盘。
七、常见误区及踩坑提醒
| 误区 | 常见表现 | 正确做法 |
|---|---|---|
| 把信息访问限制当成一次性动作 | 前期做过一次后长期不更新 | 建立周期评审和变更触发机制 |
| 只看文件，不看控制台与管理接口是否可执行 | 制度存在但配置、审批和接口没有同步 | 让文件要求进入流程、系统和证据链 |
| 默认特权工具使用由云厂商兜底 | 责任边界模糊，客户侧控制长期缺位 | 通过责任矩阵和合同条款明确双方职责 |
| 只关注上线，不关注运行与退出 | 控制在运行期漂移，终止时无法收口 | 将运行监视、变更和退出纳入同一治理框架 |
警告：忽略控制台、管理接口和特权工具的额外访问限制，会让高权限面成为整个平台的最薄弱环节。
小结：9.4要求组织把云访问控制落到功能、数据和特权工具层面，避免“登上去就几乎全可见”。