出于安全原因，是否需要单独的数据库来存储用户输入数据

Question

我们正在构建一个Web应用程序并计划在AWS上运行它。用MySQL创建了一个RDS实例。建议的架构如下： 数据正从公司数据集市上传到RDS中的Core DB。另一方面，用户通过我们的Rest API发送数据以发布数据。正如我们的架构师建议的那样，该用户输入数据将保存在同一RDS中的单独数据库中。然后，数据将定期复制到Core DB内的表中。我们将基于Core DB运行规则引擎。每当检测到异常时，都会向客户发送通知。

整体结构似乎很好。我改变的一件事是，我们可以只有一个数据库，并且在同一个数据库的表中有用户输入数据，而不是拥有两个独立的数据库。根据我们的架构师的说法，独立数据库背后的逻辑是出于安全考虑。由于Core DB将拥有我们公司的数据，因此最好独立完成。因此来自客户端的http请求只会影响用户输入数据库。

虽然有道理，但我不确定它是否真的有必要。首先，所有用户输入都经过身份验证。其次，web api为数据库提供了另一个保护层，因为它只允许某些请求，在这种情况下，请求的是几个端点。此外，如果某人仍能以某种方式入侵RDS中的User Input DB，因为它位于同一个RDS实例上，而且数据库之间存在数据传输，因此他们无法进入Core。

那就是说，我们真的需要单独的数据库吗？如果这是可行的方法，那么在User Input DB中从User Input TB同步到Core DB的最佳方法是什么？

Answer 1

就安全性原因而言，分离数据库并不神奇地使它成为现实。我的建议是：

1. 限制API层，例如只有写访问权限（以防万一意外删除数据）
2. 对于凭据数据，请不要将其放在源代码上，您可以将其作为环境变量，例如ElasticBeanstalk Environment Variables
3. 对于RDS本身，请将其置于VPC
之下

如果必须使用2 db，则在同步数据方面。

1. 如果您的两个数据库在架构上完全相同，则可以使用db replication功能（例如mysql复制）
2. 如果没有，您可以将其发送到消息代理服务（SQS），然后创建一个工作人员将其拉出然后将其保存到目标数据库
3. 或者您可以使用其他服务，例如datapipeline