我们公司目前有一个面向客户的集群，用于我们的注册和客户帐户管理，可以直接访问实时数据库（一个主数据库加上几个只读从属数据库）。
我们最近讨论过如何提高此设置的安全性（超越现有防火墙）。这个想法（来自管理层）是生产服务器不应该直接访问或写入数据库，而应该从数据库服务器或连接到生产服务器的其他内部服务器运行某些程序，并从那里存在的某个临时队列请求信息。
所以
现在：
应用程序将新注册信息写入数据库 应用程序从数据库读取有关客户的数据
(App -> DB)
建议的：
应用程序将新注册写入临时本地缓存（可以是文件系统、临时数据库、memcached 等）来自内部网络的 Cron/守护进程连接到应用程序服务器并获取排队的数据库请求 Cron/守护进程根据请求将新数据写入数据库或从数据库读取旧数据
Cron/daemon 将结果推送回应用服务器
(App <- Daemon -> DB)
作为一名开发人员（不是系统管理员），这对我来说似乎很荒谬，但我坦然承认自己不是安全专家。作为替代方案，我建议，如果我们无法直接访问数据库，那么我们可以有一个中间层，它接受结构化请求并生成数据库查询并返回数据。这看起来更像是
(App -> Proxy -> DB)
管理层的回应是，这不是最理想的（但至少仍有待商榷）。
我认为这种争论在很多地方都出现过很多次，但我没有看到任何具体内容来说明他们提出的架构的优缺点。所提议的向后代理方法真的那么安全吗，值得花时间去构建它吗？如果不是，如果有人要求你实现这样的架构，你会用什么来支持你的论点呢？
答案1
他们希望缓解哪些具体漏洞？这似乎会带来很多额外的开销和复杂性（这不可避免地会导致这样或那样的问题）。
如果应用服务器仍可通过代理或其他中介访问数据库服务器，则根应用服务器仍可编写请求来阻止数据库。我只是没有在提案中看到任何特别增加的安全性；也许我遗漏了什么。
安全并不是一些模糊或可替代的“东西”，你可以通过模糊性或复杂性来增加它。安全是为减轻特定威胁而采取的具体措施。
答案2
生产服务器不应位于外部。典型的模型是三区模型，即外部、DMZ（非军事区）和内部。外部永远不能访问内部。但是，生产服务器应位于 DMZ 中。DMZ 服务器对内部网络的访问权限应受到限制。从 DMZ 访问应以最低权限为基础。
对于这种类型的应用程序，我将提供对内部网络上执行必要操作的服务的访问权限。这些操作应该是一组有限的操作，每次可以更新一个客户端的数据。
如果有人破解了生产的 Web 服务器，那么从 DMZ 进行通用访问将会使您的数据面临风险。