我所服务的小公司的领导层已经对SaaS感到非常兴奋，并且正在推动我们的产品进入SaaS部署 – 我对此感到担忧，因为产品的部分function是基于用户能够使用商业智能工具来编写针对应用程序底层数据库的报告。
当我问到我们如何计划在SaaS模型中提供这个function时，我被空洞的目光迎面而来，而且我们的反应就是将数据库服务器暴露在互联网上，并允许人们查询数据库，就好像它正在运行他们的企业networking。
这吓坏了我，但是我不知道我是否偏执，或者是否有重大的理由要关心。
所以我的问题是：是否有可能适当加强Oracle数据库服务器的安全性，这样我们就不用担心它会暴露在互联网上呢？ 如果是这样，我应该研究哪些资源来学习这样做？ 数据库将存储我们的客户不想公开给世界的专有信息，但是把这个function放在VPN后面的build议已被直接拒绝。
我关于加强oracle数据库的search几乎都包含了“永远不要在你的防火墙上戳洞”这样的语句，所以这里的正确答案可能是“尽快更新你的简历”，但是我感谢您可以给的任何build议。
暴露一个数据库并不是一个真正的巨大问题，与其他一些经常暴露于世界+狗的服务相比，除了它是一个复杂的系统，包含许多潜在的漏洞，包括权限升级。 我会确保你不会公开查询数据库并运行所需的SSL等。我会说这是可能的，但是，你应该是偏执狂，你应该为公众面对一个单独的数据库安装。 如果贵公司不愿意为此支付授权费用，那么，是的。
从客户/支持方面来看，如果客户的ISP阻止某些types的端口或stream量，则直接连接到数据库可能是一个问题。
在SaaS模型中，您通常希望程序员要做的就是编写一个可以从应用程序中查询的API。 这种性质的API通常通过https进行操作，并在HTTP响应中将数据提供给应用程序。 额外的好处：它可以在networking上的任何地方工作，使用memcached或其他caching技术caching结果集，以减轻数据库服务器的负载，并且http auth得到很好的支持和testing。
我将在DMZ中设置第二个数据库服务器，并将转储导入到该数据库中，并使该数据库可用。
正如我相信你会同意，几乎所有的定义访问和安全是一个折衷。 而你的任务是使敏感数据可访问。
简而言之，您可以通过防火墙技巧，稳固的networking架构，更新的补丁集，访问审核以及丰富的备份来减轻很多风险。
密码pipe理也被认为是一件棘手的事情，通常应用程序帐户的密码永远不会过期，并且物理/networking访问控制已经到位，以确保具有密码知识的前雇员无法访问数据。 如果你的数据库服务器暴露给整个互联网，这似乎是一件很难做到的事情。
你可能也想定义一个'我们已经被妥协了，现在我们做什么？ 战略，这样你就可以为所有参与者设定期望值，并且在你的运气用完时有一个行动计划。
我会说使用API或Web服务，首选Web服务，因为最终用户（客户）应该有更多的灵活性连接到它们。
第二部分，pipe理层会说：“坚持到底，我们现在需要立即上市！” 不想花钱开发它。
第3部分，你需要易于理解为什么直接暴露数据库是不好的，然后拿出大量的白皮书，安全报告等。另外，如果我想使用你的软件，它是SaaS ，我我想知道所有关于你的安全的事情，一旦我发现你暴露了数据库，交易就closures了。
SaaS是货物。
将数据库服务器公开到Internet – 不太好。
为什么他们需要暴露？ 是因为RPC而不想使用静态RPC端口？
但是有一些很棒的应用防火墙，如果你locking数据库的端口映射器端口，然后防火墙 – 你可以用ACL，IP限制等做一些好的事情。
而且您需要审核事件日志，漏洞扫描等。
将数据库服务器安全地放在防火墙后面。 如有必要，编写Web服务，该Web服务位于面向公众的网站上，该网站具有到DB服务器的隧道。 确保Web服务对数据库的访问权限有限。 如果要求他们正在进行报告，那么Web服务只需要只读访问权限。 我可能会创build我想要呈现的数据的视图，并授予对它们的读取权限，而不是基础表本身。
像Rob说的那样，审计所有内容，运行漏洞扫描，在Web服务应用程序中包含访问日志，这样您就可以看到谁访问了什么内容以及访问时间。
我们在业务过程中使用多个SaaS应用程序，他们通过两种方式来实现。
除了安全性，你还要担心多租户系统的性能。 您不希望一个用户在Crystal中撰写得不好的报告影响所有其他报告用户。