云上数据安全新范式:Apache Doris IAM Assume Role 解锁无密钥访问 AWS S3 数据

一、传统 AK/SK 方式访问 AWS 资源存在的问题
密钥管理困境:
长期暴露风险:静态 AK/SK 需硬编码于配置文件中,一旦因代码泄露、误提交或恶意窃取导致密钥扩散,攻击者可永久获得等同于密钥所有者的完整权限,引发持续性的数据泄露、资源篡改及资金损失风险;
审计盲区: 多用户/多服务共享同一组密钥时,云操作日志仅记录密钥身份而无法关联具体使用者,无法追溯真实责任人或业务模块;
运维成本高:密钥轮换灾难,需手动轮换业务模块密钥,容易出错触发服务中断;
权限管理失控:账户管理不清晰,授权无法满足服务/实例级的最小权限管控需求。
二、AWS IAM Assume Role 机制介绍
AWS Assume Role 是一种安全身份切换机制,允许一个可信实体(如 IAM 用户、EC2 实例或外部账号)通过 STS(安全令牌服务)临时获取目标角色的权限。其运作流程如下:
使用 AWS IAM Assume Role 方式访问的优点:
动态令牌机制(15 分钟~12 小时有效期)替代永久密钥
通过
External ID实现跨账号安全隔离,并且可通过 AWS 后台服务进行审计基于角色的最小权限原则(Principle of Least Privilege)
AWS IAM Assume Role 访问 S3 Bucket 的鉴权过程:
阶段 1:源用户身份验证
权限策略检查
源用户发起
AssumeRole请求时,源账户的 IAM 策略引擎首先验证:该用户是否被授权调用 sts:AssumeRole 操作?检查依据:附着在源用户身份上的 IAM Permissions Policies
信任关系校验
通过 STS 服务向目标账户发起请求:
源用户是否在目标角色的信任策略白名单中?检查依据:目标角色绑定的 IAM Trust Relationships Policies(明确允许哪些账号/用户担任该角色)
阶段 2:目标角色权限激活
临时凭证生成
若信任关系验证通过,STS 生成三要素临时凭证
其中 "s3.role_arn" 对应填入 AWS IAM Account2 下的 Iam role2 的 arn 值,"s3.external_id"对应填入 Trust Relationships Policies 中配置的 externalId 的值(可选配置)。
更多功能 SQL 语句详细参考: Doris 官网文档;
Doris 当前仅支持了 AWS IAM Assume Role 的机制,未来会逐步实现其他云厂商的类似鉴权机制。
Reference
官网文档 https://doris.apache.org/zh-CN/docs/3.0/admin-manual/auth/integrations/aws-authentication-and-authorization
视频 https://www.bilibili.com/video/BV1U3uezjEPW/?vd_source=20479f0462e74fcf98f1df731639610f







评论