2012-01-03 156 views
5

我明白安全地存储数据在大多数情况下,包括存储在单独的服务器,仅允许从应用程序的连接,密钥对加密等,但对数据的概念,我仍然不了解如何分离服务器使其更安全。安全地存储数据

举例来说,假设我有一个Web服务器,它被硬化和安全,它抓住了从用户输入的数据进行存储。数据被加密并通过数据库查询或Web服务提交给数据库服务器。数据库服务器仅允许来自Web服务器的连接并以加密形式存储数据。因此,如果有人访问数据库,数据是毫无价值的。

但是,如果有人访问Web服务器,他们将有机会获得DB以及加密算法和密钥,不是吗?既然如此,为什么即使有不同的服务器上的数据,因为数据的传输只是另一个潜在的攻击点?

有什么方法可以隐藏在Web服务器上的连接信息和加密算法,这样,如果它被破坏,访问数据库服务器是不是得到了什么?混淆是不够的,我不会想。任何想法都欢迎。

感谢 布赖恩

回答

5

在人们为安全而设计的方式中存在着一定数量的神奇思维和民间传说,你是对的:将数据存储在不同的服务器上并不一定使事情更安全,除非你完成了所有的事情还有其他一些东西。

管理密钥是其中的一个重要部分;在Web应用程序环境中这样做是一个主题,我不知道任何强大的PHP解决方案。你说得很对 - 如果你的web应用程序需要解密某些东西,它需要访问这些密钥,并且如果web应用程序受到攻击,攻击者也可以访问密钥。

这就是为什么我倾向于使用公钥密码系统,并将面向公众的网络服务器视为“只写” - 即网络服务器使用公钥进行加密,存储在数据库中,永远不能解密;只有一个单独的进程(在公共互联网上不可用)可以使用私钥解密它。这样,您就可以将信用卡详细信息存储在数据库中,只有收费卡的应用程序才有私钥解密它;这个应用程序运行在一个安全的环境,不能从互联网上访问。其次,存在多种级别的折衷 - 例如,攻击者可能会获得对服务器文件系统的只读访问权限。如果该文件系统包含数据库,他们可以获取数据文件,将其恢复到他们控制的服务器,并使用解密密钥来窃取您的私人数据。如果数据库运行在单独的服务器上(无法从Internet访问),则此攻击路径变得不可能。

事实上,一条攻击路线让你打开并不意味着你无法抵御其他攻击。

+0

杰出的信息,无论在那里和其他答案。这让我意识到分离数据是不够的。加密/解密功能也必须分开,让网络服务器像Neville所说的“只写”。感谢所有的洞察力! – 2012-01-03 17:32:16

4

在大多数我的设定时,Web服务器在防火墙的DMZ中,而DB是在防火墙后面。我绝不希望将DB服务器放在防火墙之外。这种额外的安全性使得人们在未经授权的情况下获取数据变得更加困难。

顺便说一句,网络上的任何Web服务器都不应该被认为是“硬化和安全的”。如果公众可以使用,则可以使用可以破解。这只是他们想要尝试的难度问题。

你就在你的假设,如果有人黑客的网络服务器,以他们可以登录作为管理员的地步,他们可以读取和写入数据库。但是,这并不意味着您应该通过将数据库放在Web服务器上来进一步削弱您的设置。你想要更多安全性,不要低于。

编辑:

总是想着在在安全方面。将关键部件分为不同的层。这有两件事。它使得perp有更多的问题需要解决,并为您提供更多时间进行检测和响应。

因此,在您的场景中,访问Web服务器是一层,然后您可以调用第二层的加密服务器(防火墙后面是另一层),加密服务器可能是唯一的机器允许与DB服务器交互,这是另一层。

层使它更安全。但他们也增加了负担,减缓了响应时间。因此,请保持您的解决方案与您的实际需求保持平衡。

+1

是的。但是,如果他们访问Web服务器,他们不能从那里连接到数据库吗? – 2012-01-03 17:06:17

+0

不得不说,我一直在想同样的事情。 – Sam 2012-01-03 17:10:36

+0

你是“BTW”评论正是我所关心的。在Web服务器上是连接设置到数据库,以及任何密钥和加密算法。似乎访问Web服务器也会暴露您的数据库服务器。 – 2012-01-03 17:10:45

3

这里的问题是,关键是可能受到影响的公众,面向服务器上 - 即使服务器本身的“硬”,有可能是在你的应用程序中的漏洞赋予密钥或数据的攻击者访问。

为了提高安排的安全性,您可以将处理加密数据的代码(以及密钥)移动到只能通过Web服务器访问的安全机器上,并且只能通过非常有限的API(即需要的最低限度)。记录每项操作以发现异常行为,这可能是企图提取秘密数据的症状。

+1

这是很好的建议。请记住,最佳实践体系结构实际上会使用三台服务器,一台不带应用程序逻辑的Web服务器,一台带有所有代码的应用程序服务器以及一台数据库服务器。 Web服务器是唯一可以与应用程序服务器进行通信的应用程序服务器,并且应用程序服务器是唯一可以与数据库交谈的事物。如果层之间的所有交互尽可能小(就像@SimonJ所建议的那样)并且在层之间相互认证(双向认证SSL),那么与数据库相比,您对数据库的攻击要比如果他们共处。 – jeffsix 2012-01-03 17:31:29

1

从安全的角度来看,将数据库放入单独的服务器并不是真的有帮助。如果身份验证令牌遭到入侵,则游戏结束。

然而,它确实是有意义的数据库数据访问层(DAL)从业务逻辑和表示分开。这样,如果应用程序服务器沦为不择手段,则数据库访问仅限于特定的DAL操作,如果执行得当,可以使数据远离危害方式。

除此之外,将数据存储隔离到单独的服务器中并没有太大的安全优势。