使用 SSM 参数存储

问题描述

我在 AWS 云上有一个基于 SAAS 的应用程序，使用 AWS Amplify 作为无服务器技术构建。我正在使用至少 2-3 个第三方服务，如 wordpress、JWplayer，并通过它们的 API 进行通信以对它们执行任何操作，并且我需要 API 凭据。因为，这是一个多租户应用程序，因此对于每个用户，我为第三方拥有单独的用户帐户，以及我的应用程序的用户 A 拥有 wordpress 和 JWPlayer 的帐户，而用户 B 在这些第三方应用程序上拥有不同的帐户。因此，用户 A 和 B 对其第三方具有不同的 API 凭证。我想在我的应用程序级别安全地保存和检索每个用户的 API 凭据。我探索了 SSM 参数存储，以便像对象一样存储和检索凭据：

{
    "[e-mail]" : 
                     {
                           "wordpress_api_key": "abcd","wordpress_api_value": "1234","JW_api_key": "qwer","JW_api_value": "5422",}
}

我正在考虑将包含每个单独用户的不同 API 凭据的对象作为上述对象放在 SSM 参数存储中，并通过我的 Lambda 中的唯一电子邮件 ID 进一步检索，并使用 SSM 库响应前端。

或者有更好的方法吗？喜欢以加密形式存储在 DynamoDB 中，然后从它们中检索它然后解密？

解决方法

我会坚持使用 Parameter Store，因为它提供开箱即用的透明加密支持，并与 KMS 很好地集成。

至于存储方案，有几种不同的存储方式。您可以创建一个 Parameter Store 条目树，并将每个键或值单独存储为 SecureString 参数，例如：

/myapp/user-key/wordpress/key
/myapp/user-key/wordpress/value
/myapp/user-key/JWAPI/key
/myapp/user-key/JWAPI/value

我个人更喜欢上述选项，因为它很灵活，可以让您分别访问每个凭据。您还可以将非凭据存储为 String 条目，这样它们就不会经过加密。但是有 a limit of 10k parameters per account，因此如果您希望处理大量用户，则可能会超出限制。

另一种选择是将整个用户“个人资料”存储为一个条目，正如您在问题中提到的。此选项不太灵活，因为您始终必须检索/保存整个对象，即使只有部分更改。虽然此选项允许您在达到 10k 限制之前存储更多用户配置文件，但每个用户配置文件的大小必须小于 4KB，因为这是每个条目的 AWS 限制。