【问题标题】:Database security / scaling question数据库安全/扩展问题
【发布时间】:2010-06-14 22:31:52
【问题描述】:
我通常在与使用它的应用程序相同的计算机上使用 MySQL 或 PostGreSQL 等数据库,这使得访问变得简单和安全。我现在正在构建第一个具有单独物理数据库服务器的站点(今年晚些时候它将)。我想知道 3 件事:
- (安全性)对于初学者来说,关于访问单独计算机数据库的安全性,我应该注意哪些事项?
- (可扩展性)我应该考虑的可扩展性问题是否与此相关(与技术无关)?
- (更多
ServerFaultish 但相关)如果在同一物理服务器上启动数据库(使用单独的 VMWare VM)然后移动到不同的物理服务器,是否存在我必须处理的隐含问题?不是还在通过localhost访问另一个VM吗?
如果这些问题完全荒谬,我向你们 DB 专家道歉。
【问题讨论】:
标签:
database
scalability
database-security
【解决方案1】:
简单,我答应你。安全……嗯,安全与数据库服务器的物理位置关系不大。
要回答你的三个问题:
- 首先,看看如何使用数据库服务器安全模型限制对数据库表的访问。也就是说,如果您的应用程序不需要删除表,请确保它用来连接的用户没有该能力。其次,研究如何加密数据库服务器和应用程序之间的连接。在 Windows 中,这通过 kerberos 非常透明,甚至可以通过组策略设置强制执行,不确定其他平台。第三,查看数据库具有哪些功能来加密“静态”数据。意思是,它本身是否支持对实际数据文件本身进行加密?
这里的要点是,您的应用程序只是数据库服务器本身的一个可能入口点。问问自己,如果有人可以使用您的应用程序凭据直接连接您的应用程序,会发生什么。接下来问,如果他们发现 SQL 注入问题会发生什么。另外,问问自己,如果有人能够监控您的应用程序和服务器之间的 IP 流量,可以收集到哪些信息。他们能辨别任何数据吗?最后,问问自己,如果他们得到数据库本身的副本怎么办?
您选择#1 的时间将取决于几个因素,例如数据的价值(例如:如果丢失,您、您的公司或您的客户会发生什么);以及,您需要多少时间来提出理想的解决方案?
可扩展性:这纯粹是负载的函数。不幸的是,扩展大多数数据库应用程序的唯一方法是扩展。这意味着您需要在需要时购买更大的数据库服务器。 Stack Overflow 不久前经历了这个。某些数据库类型(nosql、mongodb 等)支持称为粉碎或分片的概念。 MySql、PostGreSql 等没有。相反,您必须专门设计应用程序来处理它。这意味着不使用诸如自动递增键之类的东西。这可能是一个皇家 PITA ......这就是为什么根据您的应用程序进行扩展更容易的原因。
无法通过“localhost”访问另一个 VM。 localhost 定义对当前服务器的访问。该服务器是否是虚拟机并不重要。您必须按名称引用您的数据库服务器。现在,将数据库 VM 转换到另一台物理服务器应该具有零影响,因为您通过名称引用它。除此之外没有任何其他考虑。
【解决方案2】:
除了克里斯的有效回应,
安全
使用网络上的安全机制除了数据库或应用程序框架提供的任何安全功能。也许这很简单,例如对网络设置防火墙、运行 IPSEC 或通过 ssl 隧道。关键是您不应该假设数据库作者是网络安全专家,或者数据库身份验证机制甚至根本解决了网络安全问题。
可扩展性
从本地数据库迁移到远程数据库时,会想到一个可伸缩性问题。远程 TCP/IP 通信比本地管道通信慢得多。由于频繁往返数据库,您的应用程序可能存在隐藏的可扩展性问题。在每次查询之间,您的应用程序会连续等待每个数据库响应。在本地系统上,延迟非常小,您可能没有注意到。