2. 密码服务中的身份模型

在密码服务体系中，“身份”并不是一个单一概念。同一个密码服务请求，可能同时涉及发起操作的人、承载请求的设备、调用接口的服务，以及真正执行加解密的工作负载。如果把这些身份混为一谈，就会出现权限过宽、审计断链、密钥越权使用等问题。因此，身份权限治理的第一步，是建立清晰的身份模型。

四类身份的本质区别

实体身份指向“人”或“组织”。它回答的是“谁在发起或授权这次密码操作”。实体身份通常由统一身份源（如 LDAP、OIDC IdP）管理，携带姓名、部门、岗位、角色等属性。在密码服务中，实体身份很少直接持有密钥，而是通过授权关系获得对密钥或证书的使用权。

设备身份指向“承载密码操作的物理或虚拟设备”。它回答的是“这次操作从哪台设备发起”。设备身份通常以设备证书、TPM 背书密钥或设备指纹为凭据，用于判断终端是否可信、是否在合规网络内。设备身份的关键属性包括设备序列号、平台类型、合规状态和所属区域。

服务身份指向“提供密码能力的服务实例”。它回答的是“哪个服务在调用密码接口”。服务身份通常以服务账号、mTLS 客户端证书或 SPIFFE ID 表示，用于服务间认证和最小权限授权。服务身份关注的是服务名、版本、所属命名空间和可访问的密钥范围。

工作负载身份指向“实际运行中的进程、容器或 Pod”。它回答的是“哪个具体工作负载正在使用密钥”。工作负载身份比服务身份更细，通常由编排平台签发（如 Kubernetes ServiceAccount Token、SPIFFE SVID），具有短生命周期、可自动轮换的特点。它关注的是工作负载的运行时上下文，包括镜像摘要、节点、标签和启动时间。

建模方法：从属性到策略

四类身份不能只停留在概念区分，必须落到可执行的建模方法上。建模的核心是把身份属性映射为密码服务可判断的授权条件。

以实体身份为例，建模时通常提取“部门 + 岗位 + 数据密级”三个属性，映射为密钥标签。例如，财务部会计岗位只能访问标签为 dept=finance 且 level<=3 的数据密钥。这样，当实体身份通过 OIDC 登录后，密码服务根据令牌中的声明自动匹配密钥范围，无需人工分配。

设备身份的建模重点在“可信状态”。可以把设备分为“已注册合规”“已注册不合规”“未注册”三种状态，分别对应不同的密码操作权限。已注册合规设备可以执行签名和密钥导出；已注册不合规设备只能执行验签和加密；未注册设备拒绝所有密钥操作。设备状态由 MDM 或终端检测平台定期上报，密码服务在每次请求时校验设备证书中的合规声明。

服务身份的建模采用“服务名 + 命名空间 + 接口范围”三元组。例如，payment-service 在 prod 命名空间下，只允许调用 encrypt 和 decrypt 接口，不允许调用 exportKey。这种建模方式把授权粒度从“服务级”细化到“接口级”，显著降低横向移动风险。

工作负载身份的建模最细，通常绑定“镜像摘要 + ServiceAccount + 节点标签”。例如，只有镜像摘要为 sha256:9f2c... 且运行在 zone=dmz 节点上的 Pod，才能获取数据库加密密钥。工作负载身份的有效期通常很短，例如 15 分钟，到期自动轮换，即使凭据泄露，攻击窗口也极小。

身份生命周期管理要点

身份不是一次性配置，而是有生命周期的。四类身份的生命周期管理各有侧重，但都遵循“签发—绑定—轮换—审计—吊销”五个阶段。

签发阶段要确保身份来源可信。实体身份必须来自统一身份源，设备身份必须经过注册审批，服务身份必须由服务注册中心签发，工作负载身份必须由编排平台自动注入。任何手工创建的身份都应视为高风险，需要额外审批。

绑定阶段要建立身份与密钥、证书、策略的关联。绑定关系应记录在案，包括绑定时间、绑定人、绑定依据。例如，某服务身份绑定到某密钥时，必须记录“因支付业务需要，经安全评审后绑定”。

轮换阶段要自动化。实体身份的令牌有效期建议不超过 1 小时；设备证书有效期建议不超过 90 天；服务身份证书建议不超过 24 小时；工作负载身份建议不超过 15 分钟。轮换过程应无感，不能中断业务。

审计阶段要能回答“谁在什么时候用什么身份访问了什么密钥”。审计日志应包含四类身份的标识、请求时间、操作类型、密钥标识和结果。日志本身也要防篡改，建议写入只追加的存储或区块链式日志。

吊销阶段要快速生效。当员工离职、设备丢失、服务下线或工作负载异常时，必须能在秒级内吊销对应身份。吊销后，密码服务应拒绝该身份的所有请求，并触发告警。吊销记录同样需要审计。

四类身份模型不是彼此替代，而是层层叠加。实体身份解决“谁授权”，设备身份解决“从哪来”，服务身份解决“谁调用”，工作负载身份解决“谁使用”。只有把四层身份都建模清楚，密码服务的身份权限治理才有坚实基础。