Amazon MQ for RabbitMQ 的认证与授权选项
DataHot 速览
在规模化场景下，消息代理的认证管理十分复杂，静态用户名密码方式会带来凭证分发、轮换与撤销等运维负担。Amazon MQ for RabbitMQ 支持简单凭证、OAuth 2.0、IAM、LDAP、HTTP 认证后端及 SSL 证书等多种认证授权方式，便于对接企业现有身份基础设施。文章介绍了各方式的特点，并帮助用户根据自身环境选择合适方案。
为什么值得关注：消息代理是数据管道与集成治理的重要组件，其认证授权设计直接影响数据平台的安全性与合规性，值得数据平台和治理团队参考。
译文
AI 逐段翻译大规模管理消息代理的认证是复杂的：凭据泛滥、审计要求以及与现有身份提供商的集成都会产生运营开销。默认的创建具有静态用户名和密码的 RabbitMQ 用户的方法适合入门，但在大规模场景下很快就会成为负担。凭据必须安全分发、定期轮换，并在团队成员角色变更或离开组织时及时撤销。对于受监管的行业，审计人员希望看到您的消息基础设施强制执行与环境中其他部分相同的身份和访问控制。
不同的组织拥有不同的身份基础设施。有些通过 Active Directory 管理用户，另一些则已标准化使用 OAuth 2.0。在 AWS 上构建的平台团队希望使用他们熟悉的AWS Identity and Access Management (IAM)角色和策略。注重安全的環境可能要求基于证书的认证，完全不通过网络传输密码。
Amazon MQ for RabbitMQ支持多种认证和授权方法，因此您可以将代理连接到您已有的身份基础设施。本文介绍了可用的选项，并帮助您为用例选择合适的方法。
认证方法概览
Amazon MQ for RabbitMQ支持以下认证和授权方法：
| 方法 | 凭据类型 | 用户管理 | 推荐用于 |
| 简单凭据 | 用户名/密码 | 代理本地 | 入门、开发环境 |
| OAuth 2.0 | 来自外部身份提供商的承载令牌 | 外部身份提供商 | 需要来自第三方身份提供商的短期令牌的工作负载 |
| IAM 认证 | 来自 AWS Security Token Service (AWS STS) 的短期 JSON Web 令牌 (JWT) | IAM | AWS 原生工作负载、多租户隔离、无凭据认证 |
| LDAP | 目录凭据 | Active Directory 或 LDAP 服务器 | 拥有现有目录服务的组织 |
| 基于 HTTP 的认证后端 | 由外部服务器验证的用户名/密码 | 外部 HTTP 服务器 | 自定义认证逻辑、跨代理集中用户管理 |
| SSL 证书认证 | 仅证书（无密码） | 代理本地（从证书提取用户名） | 完全消除密码，仅使用证书身份 |
| 双向 TLS (mTLS) | 证书和用户名/密码 | 代理本地 | 在现有基于凭据的认证之上添加传输层证书验证 |
选择正确的方法
正确的选择取决于您现有的身份基础设施、安全要求和运营偏好。
简单凭据
默认方法。您直接在代理上创建具有用户名和密码的 RabbitMQ 用户。这是一种简单的入门方式，但需要您手动管理凭据。选择此方法用于开发、测试或小规模部署，其中凭据管理开销是可以接受的。
OAuth 2.0
客户端从任何兼容 OAuth 2.0 的身份提供商获取短期令牌，并将其作为承载令牌呈现给代理。当您已有为应用程序颁发令牌的身份提供商（非 IAM），并且希望自动令牌过期而无需管理代理本地凭据时，请选择此方法。
IAM 认证
IAM 充当身份提供商。客户端应用程序使用其 IAM 凭据从 AWS Security Token Service (AWS STS) 获取短期 JWT，并将其作为承载令牌呈现。IAM 策略控制哪些角色可以获取令牌。代理上的 RabbitMQ 范围别名将每个角色的 Amazon Resource Name (ARN) 映射到特定资源权限（读、写、配置和管理员）。AWS CloudTrail 记录每次令牌颁发以供审计。当您的工作负载在 AWS 计算服务上运行并使用 IAM 角色，且希望实现无凭据、IAM 原生的认证和代理级授权时，请选择此方法。
LDAP
将您的代理连接到现有的目录服务，例如 Active Directory。用户使用其目录凭据进行身份验证，RabbitMQ 权限映射到 LDAP 组成员身份。当您的组织已经通过目录服务管理用户和组，并且希望将现有密码策略和基于组的访问控制应用于代理访问时，请选择此方法。
基于 HTTP 的认证后端
将认证和授权决策委托给自定义的 HTTPS 服务器。代理向您的服务器发送 HTTP 请求以进行用户验证、虚拟主机访问、资源权限和主题权限。当您需要自定义认证逻辑、希望跨多个代理集中管理用户，或需要与不原生支持 OAuth 2.0 或 LDAP 的身份系统集成时，请选择此方法。
SSL 证书认证
完全消除密码。代理使用 EXTERNAL Simple Authentication and Security Layer (SASL) 机制直接从 X.509 证书（例如，从通用名称字段）提取客户端身份，并将其用作 RabbitMQ 用户名。使用此方法，您的应用程序不会通过网络传输凭据。当您的安全策略要求无密码认证，并且您通过公钥基础设施 (PKI) 管理客户端身份时，请选择此方法。
双向 TLS (mTLS)
在现有用户名/密码认证之上添加证书验证。在 TLS 握手期间，客户端验证代理的证书，代理验证客户端的证书，然后客户端在应用层提供用户名和密码。这为您提供了双重因素安全性：您拥有的东西（证书）加上您知道的东西（密码）。当合规框架要求相互认证，但您希望保留现有的用户名/密码认证流程时，请选择此方法。
结论
Amazon MQ for RabbitMQ 版本4支持七种身份验证和授权方法。通过这些方法，您可以将消息代理的安全性与现有的身份基础设施保持一致。您的组织可能会标准化使用IAM，通过Active Directory管理身份，通过第三方身份提供商（如Okta或Microsoft Entra ID）进行联合访问，或依赖PKI进行基于证书的信任。在每种情况下，您都可以消除大规模管理静态凭据的运营开销。
选择您的实施路径：
- 基于证书的安全性：按照第1部分：双向TLS和SSL证书认证，使用证书实现无密码代理访问
- 企业身份集成：按照第2部分：OAuth 2.0、LDAP和HTTP认证，连接您现有的身份提供商并使用您当前的用户目录
- AWS原生访问控制：按照第3部分：IAM认证，使用IAM原生访问控制
对于示例代码和基础设施模板，请克隆Amazon MQ示例存储库，并为您选择的身份验证方法部署CDK堆栈。
这篇内容对你有用吗？
反馈只用于改善内容筛选，不等同于收藏