Javascript AWS DynamoDB使用AWS Cognito&；基于角色的IAM

直接访问AWS DynamoDB（使用AWS sdk）和DynamoDB可访问性的客户端应用程序（使用客户端javascript的web应用程序）由AWS Cognito进行身份验证。所有用户必须使用AWS Cognito登录才能访问AWS DynamoDB

---

对于上述无服务器应用程序（客户端javascript应用程序-从浏览器访问），上述应用程序体系结构的安全漏洞是什么？

当您将代码放入web应用程序中时，任何具有适当知识的人都可以从表，索引和键名称

应用程序安全方面的最佳实践是不要让任何人获得此类信息。有知识和动机的人可以利用这些内部信息来开发一个向量，试图利用您的环境

---

AWS环境提供了一个安全的体系结构。但是如果你能让你的环境对开发者来说有点困难，也许他们会寻找其他东西或其他人的环境。

你需要确保你通过Cognito给用户的权限受到尽可能的限制。最明显的一点是，他们将拥有只读权限，否则，用户将能够调整您的代码以删除、更新或将项目放入表中

另一个风险是，用户将能够访问同一表中其他用户的数据。如果您的表包含每个用户的数据（例如，配置文件），并且您希望允许每个用户快速检索其配置文件，则用户将能够调整代码以从其他用户读取数据。您可以使用细粒度访问控制（）来限制这一点，这将允许用户仅读取（或写入）具有其用户id的记录

您可以考虑在用户和DeaDoDB表之间放置一个AWS lambda，以对输入进行更多的检查，以及激活DeaDoDB流以捕获表中的每个更改以从错误（甚至是正确权限）更改中恢复（<0）。p> 对于小型单用户（无组和角色）web应用程序，您可以使用Cognito和DynamoDB为经过身份验证的用户提供表的行级访问控制，这在理想情况下可以提供安全的体系结构。然而，在实际实施安全性和其他因素时有几个方面

• 单个IAM策略更改可能会造成数据访问的高风险安全漏洞
• 通过身份验证的用户可以通过过度使用DynamoDB危害系统，导致DynamoDB成本显著增加
• 无法提供基于角色的访问控制
• Dynamodb表模式限制支持Cognito认证用户的细粒度访问控制，这可能会限制查询性能
• 无法在静止时使用加密（加密DynamoDB表中的数据，例如使用AWS KMS）

---

建立在别人已经写过的基础上，虽然你当然可以做到这一点，但在大多数情况下，如果你不小心，它很容易让你暴露。获取正确的权限，特别是当您的DynamoDB表包含属于多个用户的数据时，可能会很棘手且容易出错

将AWS Lambda函数置于两者之间的建议可能会有所帮助。我想指出的另一个选择是，您可以使用API网关直接前置DynamoDB。这有几个潜在优势：

• 您可以使用不同的（甚至没有）授权方案来访问数据库
• 您可以在调用DynamoDB之前和之后在API网关中执行验证任务
• 对于某些类型的请求，您可以更好地利用缓存（例如，查询请求通常是POST请求，通常无法缓存；API网关可以将查询公开为GET请求，从而允许将结果缓存到下游）

有关更多信息，请参见AWS的示例：