我的身份池 ID 有多敏感？

Question

背景

我一直在研究消耗 AWS 资源（主要是 API 网关后面的 Lambda）的前端 javascript 应用程序。API 网关资源受 IAM 保护，应用程序相应地使用 Cognito 提供的大部分内容。

这包括启用了未经身份验证的身份的身份池，以及与 Cognito 用户池和多个社交和自定义 OIDC 提供商的联合。Cognito 仅通过我们的前端 JavaScript 代码使用亚马逊的 SDK 进行交互。

未经认证的身份

ID 池 id 的敏感性适用于我的所有用例，但我对未经身份验证的用例最为好奇。我们一直在遵循似乎是Amazon 建议的方法：使用 Cognito 或 STS 获取 IAM 密钥，并使用这些密钥访问 AWS 资源。 我什至一直在传播这个福音。

这一切都很好，但它确实需要我向前端公开我的身份池 ID。身份池 ID 是您为未经身份验证的 IAM 角色获取 IAM 密钥所需的唯一信息。

从理论上讲，任何攻击者都可以使用我使用的相同 Amazon SDK 获取我的身份池 ID 并开始滥用我的资源（允许用于 Unauth IAM 角色）。

问题

• 一般来说，我应该考虑一个身份池 id 有多敏感？可以向任何人展示这个吗？
• 如果我决定它是足够灵敏不会暴露到浏览器，我该如何处理呢？我在哪里以及如何隐藏它并获得它？
• 在任何情况下，我应该“烘焙”一种经常旋转 id 的方法吗？
• 是否有（类型的）用例可以公开 id，哪些用例不能公开？

我正在寻找的答案

正如上面链接的答案中所指出的，我的理解是未经身份验证的身份并不是万无一失的，并且只能提供合理的置信度，即它是您的应用程序的另一端。换句话说，虽然并非不可能，但有人使用此模型滥用您的 AWS 后端至少是相当困难的。

除了上面的要点之外，我很感激对这种理解的任何批评。我是否低估了未经身份验证的 IAM 访问 AWS 的安全性？超卖吗？

免责声明

我承认这个问题很像这个问题。我不是在问在我的应用程序中对身份池 ID 进行硬编码；这已经从网络服务中获取。但是，它仍然完全暴露给前端，您可以争辩说，从 AJAX 响应中提取它实际上比从缩小代码中提取更容易。

我确实尽可能严格地锁定 Unauth 角色，并且我明白允许匿名访问内容只能如此安全。