Web服务作为额外的安全层

Question

我在应用程序服务器上有一个小型Web应用程序，它可以访问数据库服务器上非常敏感的数据。我没有考虑直接通过SQL连接访问这些数据，而是考虑在数据库服务器上编写一个只能由应用程序服务器使用的Web服务接口。

我的想法是，如果应用服务器遭到黑客入侵，他们将无法直接访问数据。黑客将不得不处理另一层（接口），这时我会处理这种情况。

我知道这会给网络应用程序增加一些延迟，但由于数据是敏感的，我相信这是一个可以接受的权衡。

这个额外的“安全层”真的会让我的系统更安全，还是我错过了什么？

Answer 1

我认为你的评论“此时我会处理这种情况”是不合适的，但否则这是一个好主意。如果攻击者破坏了您的前端应用程序，则无需额外的时间来加强后端层。如果后端层是最有可能出现的情况，那么您会在发现前端层受到威胁的同时找到它。

后端层有助于它的原因是它只向前层暴露它所需的功能，而不是SQL的全部功能。而且这是深度防御，因此攻击者必须找到两种不同类型的漏洞利用并同时使用它们才能通过这两层。

Answer 2

您真的想在这里使用标准的三层架构。将Web服务器（没有业务/应用程序逻辑）作为前端;仅限静态内容。它应该通过防火墙连接回应用程序服务器，只允许连接（并且只能连接到特定的应用程序服务器）。然后，只允许该应用程序服务器与数据库服务器通信。

互联网 - ＆gt;防火墙 - ＆gt; Web服务器 - ＆gt;防火墙 - ＆gt;应用程序服务器 - ＆gt;数据库

有人攻击您的Web服务器，它们与您的应用程序没有任何关系，因为它们都存在于应用程序服务器上（是的，它们可以连接到它，但只使用定义的接口，至少应该减慢它们的速度）。即使在应用程序服务器上，他们仍然需要将接口设计到数据库中。这是此类应用程序的标准安全体系结构。

Answer 3

我知道你来自哪里，但它似乎闻到了一点“默默无闻”的味道。第一个调用点是确保Web应用程序使用的SQL用户被正确锁定，并且只能访问所需的数据库对象。例如，只读访问它只需要读取的表，对需要写入的表的写访问权。在MS SQL上，通过仅对少量存储过程提供执行访问权限，可以使这更简单。用户只需要在SP上执行访问权限，并且不需要对基础表的权限。然后，这将使用数据库级安全性，而不是使用额外的，可能不安全的抽象层。

正如已经建议的那样，您可以继续为您的架构添加更多层，但我会在使用现有的安全选项之前从地面开始。