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

【问题标题】：Do I need a separate database to store user input data for security reason出于安全原因，我是否需要一个单独的数据库来存储用户输入数据
【发布时间】：2018-02-26 11:48:32
【问题描述】：

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

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

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

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

【问题讨论】：

一个单独的数据库在任何方面都不会从根本上/自动/神奇地更安全。使用 db 用户权限，可以限制 REST 服务器对数据的访问权限，并且 db 级别的权限（而不是表级别的权限，否则您需要这样做）可能会使描述更清晰，错误更少-prone...但目前还不清楚这里是否有足够的信息来给出权威的答案。您绝对应该在内部限制 REST API 使用的凭据，以免无意访问。

标签： database rest amazon-web-services security architecture

【解决方案1】：

就安全原因而言，分离 db 并不是神奇地让它成为现实。我的建议：

限制API层，比如只有写权限（以防意外删除数据）
凭证数据，不要放在源代码中，可以放在环境变量中，例如ElasticBeanstalk Environment Variables
对于RDS本身，将其放在VPC下

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

如果你的两个数据库在schema上完全一样，你可以使用db复制能力（比如mysql复制）
如果没有，您可以将其发送到消息代理服务 (SQS)，然后创建一个 worker 来拉取它，然后将其保存到目标数据库
或者您可以使用其他服务，例如datapipeline

【讨论】：