2012-02-29 40 views
3

我正在构建一个将处理高度敏感数据的Web应用程序。我关于提高安全性的想法是为登录信息创建一个数据库,以及一个包含敏感数据的完全独立的数据库。安全数据库的认证将依靠通过登录数据库进行的两部分身份验证以及敏感数据库中用户帐户的验证。用于登录信息和任务关键信息的单独数据库?

我的问题是:那里有更好的解决方案吗?如果我将这两个数据库都维护在一台服务器上,是否存在重大安全漏洞?维护单个数据库还是值得的,只是加密安全数据库的内容?对安全数据库的内容进行加密并通过配置文件中的其他用户/传递单独对其进行身份验证访问是否过度矫枉过正?

希望这是有道理的。谢谢。

+0

我想到的是用三个数据库(如果这听起来很可笑,请告诉我)。数据库1:有限的用户数据,只读访问公开。数据库2:身份验证数据库,只允许管理员在数据库1中创建账户。如果登录后,允许用户创建一个账户(如果它存在于数据库1中),他们将获得读/写访问权限,被允许做一个帐户。数据库3是基于权限的,并具有由Web程序定义的ACL(其他则在MySQL级别定义)。数据库3中包含关键信息。 – OverlordvI 2012-02-29 05:35:08

回答

1

这取决于您的Web应用程序最可能的攻击媒介。如果SQL注入对您的应用程序是一种风险,如果用户可以合法登录,那么拥有单独的数据库将无济于事,然后将您的应用程序伪装为读取他们已有权访问的表中的其他记录。

一种方法是使用每个用户的唯一加密密钥对每条记录进行加密。这样,如果他们确实损害了一个用户帐户,其他行将是乱码。这是非常缓慢的,但如果信息是敏感,您可能必须忍受。

另一种方法是不让敏感信息直接由网络应用查询。您的网络应用程序&在DMZ中运行的非敏感数据库以及运行在防火墙后面的敏感数据库将其与DMZ隔离。然后,您可以使用Web服务或严格限制的数据库角色来根据需要获取数据。然后在Web服务/数据库端,确保代码只能传递登录用户可以看到的记录。

1

安全就像一个链条。最薄弱的环节是整个事情破裂的地方。

因此,使用一个或多个数据库并不重要。您需要保证整个系统的安全。

1

您应该查看有关存储信用卡信息的PCI合规性标准。这是一个真正的痛苦实施,但值得。如果你不存储信用卡或类似的东西,你可能会削减一些角落。

因为一个真正安全的解决方案需要设置的组合:硬件,软件和网络,所以没有“解决方案”。

http://www.pcicomplianceguide.org/merchants-20071022-gaining-pci-compliance.php

+0

这很有帮助。 PCI合规性在构建安全应用程序时有一些很好的想法。当你编程一些安全的东西时,它们似乎很直观,但它有一个清单是很好的。 – OverlordvI 2012-02-29 05:30:53