通常我在与使用它的应用程序相同的机器上使用MySQL或PostGreSQL等数据库,这使得访问变得简单而安全。我现在正在构建第一个将拥有单独的物理数据库服务器的站点(今年晚些时候它将会)。我想知道三件事:
ServerFault
ish但相关)如果在相同的物理服务器上启动数据库(使用单独的VMWare VM)并稍后移动到不同的物理服务器,是否存在隐含的问题,我将不得不处理?是否仍然可以通过localhost
访问另一个VM?如果这些问题完全荒谬,我向DB专家道歉。
答案 0 :(得分:3)
很简单,我会给你的。安全......好吧,安全性与数据库服务器的物理位置关系不大。
要解决你的三个问题:
这里的要点是您的应用程序只是数据库服务器本身的一个可能入口点。问问自己,如果有人可以使用您的应用凭据直接连接而无需通过您的应用,会发生什么。接下来问一下,如果他们发现SQL注入问题会发生什么。另外,问问自己,如果有人能够监控您的应用和服务器之间的IP流量,可以收集哪些信息。他们能辨别任何数据吗?最后,问问自己,如果他们得到数据库本身的副本会怎么样?
你去#1的长度将取决于几个因素,例如数据的价值(例如:如果你的公司或你的客户丢失了会发生什么);你有多少时间想出一个理想的解决方案?
可伸缩性:这纯粹是负载的函数。不幸的是,扩展大多数数据库应用程序的唯一方法是扩展。这意味着您可以根据需要获得更大的数据库服务器。 Stack Overflow不久前经历了这个。某些数据库类型(nosql,mongodb等)支持称为碎化或分片的概念。 MySql,PostGreSql等没有。相反,你必须专门设计应用程序来处理它。这意味着不使用自动递增键等内容。这可以是皇家PITA ...这就是为什么根据您的应用程序扩展是一个更容易的前景。
无法通过“localhost”访问另一个VM。 localhost定义对当前服务器的访问权限。该服务器是否是VM是无关紧要的。您必须按名称引用数据库服务器。现在,将数据库VM转换到另一个物理服务器应该没有影响,因为您按名称引用它。除此之外,没有任何其他考虑因素。
答案 1 :(得分:2)
除了Chris的有效回复,
安全强>
除了数据库或应用程序框架提供的任何安全功能之外,在网络上使用安全机制。也许这是一个简单的防火墙网络,运行IPSEC或通过ssl隧道。关键是你不应该假设数据库作者是网络安全专家,或者数据库认证机制甚至已经解决了网络安全问题。
<强>可扩展性强>
从本地dbs移动到远程dbs时,会出现一个可伸缩性问题。远程TCP / IP通信比本地管道通信慢得多。由于频繁往返数据库,您的应用可能会隐藏可扩展性问题。在每个查询之间,您的应用程序会连续等待每个数据库响应。在本地系统上,延迟非常小,您可能没有注意到它。