我们目前正在开发一个应用程序功能，该功能需要访问客户数据库。客户将不得不在我们的SaaS中注册他们的远程数据库凭据，我们将其存储起来，并使用它代表他们执行SQL请求。因此，我们需要加密/解密数据。
我们用于该体系结构的第一个版本是对客户凭证（AES256）进行加密，将加密的数据存储在安全VPC中的远程数据库中，我们还将对随机生成的加密AES密钥（使用RSA）进行加密，等等。
但是，我们正在调查以了解将凭证存储在诸如Secret Manager之类的产品中是否会更好（我们使用的是GCP，但对于AWS Secret-manager来说，问题是相同的。
[如果是这样，我们是否应该仅将客户凭证存储在Secret Manager中，并信任他们的加密系统？还是我们应该添加自己的加密层，例如，将已经AES256加密的数据存储在Secret-manager中？ （然后，将其检索并解密）
谢谢！
Secret Manager数据在静态时使用Google Default Encryption进行加密，并在使用TLS时进行传输。除此标准保护外，Secret Manager机密还使用Google Cloud KMS密钥before进行了加密，并被保留。目前，这些Cloud KMS密钥是在内部进行管理的，但是我们计划让客户将来控制这些密钥。在GCP上，这通常称为客户管理的加密密钥（CMEK）。同样，目前，Secret Manager不支持CMEK，但它正在发展中。从文档中的Encryption of secrets：
CMEK当前不适用于Secret Manager。如果您的组织对Secret Manager的CMEK支持感兴趣，则可以express interest by filling out a form。
您当然可以在将机密存储在Secret Manager中之前对其进行加密。这通常称为“应用程序层加密”，但确实会给您的设置带来复杂性。
[不了解许多的秘密，很难提出建议。但是，您可能有兴趣阅读我对Google Secret Manager - Can it be used for storing usernames and passwords of API users?的答复。简而言之：
技术上可行，因为GCP项目中的秘密数量没有限制。但是，它可能很快变得昂贵。每个机密价格为$ 0.06 /月。这意味着每个用户的年费为$ 0.72。对于100万用户，则为$ 720k /年+ API运营成本。
还有要考虑的延迟时间...
最后，要对约翰的评论加倍说明：保护凭据只是威胁模型的一方面。您还需要仔细考虑访问日志，吊销和安全通信。