定义
IAM（Identity and Access Management，身份与访问管理）是 ICMP 平台的身份认证、授权与访问控制体系，与 RBAC 角色权限、OAuth2、API Key、2FA 配合，保障平台 Portal、RESTful API、Partner Portal 的安全访问。
核心功能
IAM 包括：身份认证——用户名密码、OAuth2、SSO、API Key、证书；授权——RBAC 基于角色的权限控制，细粒度到 API、功能、数据范围；多因素认证——2FA 双因素认证提升安全；会话管理——Token 有效期、刷新、吊销；审计——登录、权限变更记录至 Audit Trail。
多租户与角色
ICMP 支持多租户：客户、Reseller 渠道、平台管理员等不同角色，权限隔离。客户可创建子账号、分配角色（如只读、运维、财务）；Partner Portal 为渠道提供独立入口与权限。API 调用需通过 API Key 或 OAuth2 Token 鉴权，API Gateway 负责校验与限流。
在 ICMP 中的实践
达希物联 ICMP 的 IAM 支持多因素认证、OAuth2、API Key；与 RBAC 深度集成；支持 SSO、LDAP 等企业集成；Audit Trail 记录所有认证与授权事件；满足 PCI DSS、GDPR 等合规要求。
主体、角色与资源边界
身份与访问管理要回答的是“这个主体是谁，以及他这次能对哪些资源做什么”。主体可以是门户用户、渠道账号、服务程序或短期令牌；资源则是某一租户的卡、订单、账单、诊断记录和配置。认证只解决主体是否真实，授权才决定动作是否被允许。连接管理里的高风险动作包括批量暂停、导出含设备标识的清单、修改资费和发起结算，这些动作不应因为某人能登录就自动开放。
使用它的条件，是先有稳定的主体目录，再把权限写成可复核的角色或范围，而不是把管理员口令分给每个集成系统。人员账号适合交互式操作，并应能要求第二因素；系统调用适合单独的凭证，范围只覆盖它真正要读或写的接口。租户边界必须先于角色生效：渠道账号即使拥有“卡管理”角色，也只能看见分配给自己的卡。登录之外的敏感确认可以再要求一次性密码，避免一个长期会话被直接用来改结算信息。短信通道只负责把验证码送到手机，账号是否有权操作仍由身份系统判断，两者不要并成短信网关上的一条发送记录。
过宽授权在跨境操作中的后果
最常见的错误是用一个“运营管理员”角色覆盖停机、导出、改价和付款。跨境团队往往按地区分工，区域同事只应处理本区卡和本区工单；角色如果只按功能、不按数据范围裁剪，一个人就能暂停其他区域的设备，或导出不属于自己的用量。另一个错误是把个人账号的密钥交给集成脚本。人员离职后密钥仍有效，审计里看到的却是这个人在半夜批量调用接口。
服务账号还容易被配成永久不过期、并且拥有门户上的全部菜单。脚本只需要查询用量时，却能够修改漫游策略。权限变更如果不留下前后差异，事后无法说明是谁把某一渠道的可见范围放大了。配置身份与访问管理时，应把人员、服务、租户和动作四项分开授权，高风险动作单独审批，并定期收回不再使用的凭证。
权限复核应按主体逐个看，而不是只看角色名称是否还在。长期未登录的人员账号、已经换岗的渠道账号、以及集成下线后仍有效的服务凭证，都要有明确的停用日期。停用时同时作废尚未到期的会话和令牌，否则角色虽然删了，已经发出的凭证仍能继续暂停卡或导出清单。复核记录本身只保存谁在何时核对了哪些主体，不保存密码和验证码。
职责要分开。能修改资费的人不应独自完成结算确认，能导出完整标识清单的人不应同时持有批量停机的权限。紧急处理可以准备单独的应急账号，但应急账号默认禁用，启用时要记录原因、批准人和自动收回时间。应急账号若长期可用，就变成另一个不受约束的管理员。收回时要检查它在启用窗口里实际做了哪些写操作，而不是只看它后来被关掉。
服务凭证按集成系统发放，每个系统一把，范围只包含该系统真正调用的动作。共用一把凭证时，无法在泄露后只停掉其中一个系统，也无法从记录里分辨是下单系统还是报表系统发起的调用。凭证轮换要有重叠期：新凭证验证可用之后再废止旧凭证，避免轮换瞬间所有集成一起失败。重叠期结束后，旧凭证的调用应被拒绝并留下记录。
租户边界还要覆盖导出和订阅。用户界面上看不见其他客户的卡，并不等于接口和事件推送也做了同样的限制。新增一种查询或推送时，要用不属于该租户的标识试一次，确认被拒绝，再放到生产。身份与访问管理的验收标准是越权请求失败，而不是管理员自己能打开所有菜单。