我在应用服务器上有一个小型 Web 应用程序，它访问数据库服务器上非常敏感的数据。我没有直接通过 SQL 连接访问这些数据，而是考虑在数据库服务器上编写一个只能由应用程序服务器使用的 Web 服务接口。
我的想法是，如果应用程序服务器被黑客入侵，他们将无法直接访问数据。黑客将不得不处理另一层（接口），而此时我已经处理了这种情况。
我知道这会给 Web 应用程序增加一些延迟，但由于数据很敏感，我相信这是一个可以接受的折衷方案。
这个额外的“安全层”真的会让我的系统更安全还是我遗漏了什么？
【问题讨论】：
标签： web-services security web-applications
我认为您的评论“到这个时候我会处理这种情况”是不合时宜的，但否则这是个好主意。如果攻击者破坏了您的前端应用程序，您不一定会获得任何额外的时间来加强后端层。如果包含后端层，则最可能的情况是您会在发现前端层被入侵的同时发现它。
后端层提供帮助的原因是它只会向前端层公开它需要的功能，而不是 SQL 的全部功能。而且它是深度防御，因此攻击者必须找到两种不同类型的漏洞并同时使用它们才能通过这两层。
【讨论】：
您确实想在这里使用标准的三层架构。将 Web 服务器（无业务/应用程序逻辑）作为前端；仅限静态内容。它应该通过只允许它连接的防火墙连接回您的应用程序服务器（并且只允许连接到特定的应用程序服务器）。然后，只允许该应用程序服务器与数据库服务器通信。
Internet -> 防火墙 -> Web 服务器 -> 防火墙 -> 应用程序服务器 -> 数据库
有人入侵了您的 Web 服务器，他们没有得到与您的应用程序相关的任何信息，因为所有这些都存在于应用程序服务器上（是的，他们可以连接到它，但只能使用定义的接口，这至少会减慢它们的速度）。即使在应用程序服务器上，他们仍然需要开发出与数据库的接口。这是此类应用程序的标准安全架构。
【讨论】：
我知道你来自哪里，但对我来说似乎有点“默默无闻的安全”。首先要确保 Web 应用程序使用的 SQL 用户被适当地锁定，并且只能访问它需要的数据库对象。例如，对只需要读取的表的只读访问权限，对需要写入的表的写访问权限。在 MS SQL 上，这可以通过只授予对一小部分存储过程的执行访问权限而变得更简单。用户只需要对 SP 的执行权限，而不需要对基础表的权限。这将利用数据库级别的安全性，而不是使用额外的、可能不安全的抽象层。
如前所述，您可以继续为您的架构添加更多层，但我会从底层开始使用已有的安全选项，然后再推出您自己的。
【讨论】：