2009-06-20 35 views
4

我开始在工作中使用一个小型的内部Web应用程序,主要是一个概念验证,但我们想把它看作是一个“真实”的应用程序。作为一名DBA我没有太多经验,我的团队也没有人(因为它是一个PoC,所以有一个人并不特别重要)。我应该为不同的查询类型分开SQL帐户吗?

但我想知道,如果这个Web应用程序上市,我们应该有不同的查询类型的数据库服务器的帐户?例如。有一个SQL帐户用于SELECT查询,另一个用于UPDATE/DELETE?我无法说服自己有这样做的任何特殊优势,但我之前听说过这种技术,所以必须有一定的价值。

回答

4

对于不同类型的任务(例如,批处理作业与Web服务)有不同的帐户,并对连接计数等有各自的限制是有用的。这意味着如果你的批处理作业变得疯狂,它无法取出你的网络应用程序。

您还希望不同帐户拥有不同的权限。例如,如果您的管理员和用户应用是分开的,他们应该拥有自己的帐户。这有助于确保如果您的用户应用程序遭到入侵,它将无法对您的数据造成太大的损害。

在这两方面有一个“只读”用户是有用的,但只有当你的应用程序没有写入。

0

对于查询类型,您不需要单独的帐户。通常,与数据库的连接使用与访问Web应用程序的用户无关的数据库用户。

+1

这个问题说它是在谈论“SQL帐户”。所以你的答案是多余的。 – tialaramex 2009-06-20 14:45:37

2

您可以限制匿名用户访问该站点时有权访问的主帐户的查询类型。但是,我认为您不需要该子集中的每个查询都有不同的用户。

你想要关注的是每个用户可以访问哪些数据库/表,而不是特定类型的查询。

1

都是应用程序使用的这些帐户类型,我会想象您所指的练习是试图阻止sql injection attacks。如果您确保清理输入信息,可能并不是必需的。记得bobby tables

只读帐户的另一个原因是允许管理员用户直接在db上运行报告来处理系统活动和调试生产问题。

0

在“公共”应用程序中,一个好的做法是使用服务帐户访问数据库(运行查询,exec存储过程),并在代码级别计算用户访问控制。

这可以防止您需要将新用户添加到数据库的安全管理器中。

我唯一一次看到单独的SQL数据库帐户正在使用的是分开应用程序功能,即使如此,他们是服务帐户。即

  • 格兰特选择ReportService的
  • 格兰特选择,更新,删除对TransactionService

然后,您可以运行Web应用程序作为ReportService的或TransactionService,根据自身的需要。

通过将这两个概念相加(代码中的用户访问,服务的功能区分),您可以有效地对您的用户访问控制机制进行单元测试。否则,你需要在数据库中设置一个用户,然后看看你从数据库中得到了什么样的行为。

1

是的。见Principle of least privilege

在信息安全,计算机 科学等领域,最小特权 原则,也 称为最小 特权或只是最小特权原则, 要求,在特定 抽象层计算 环境中,每个模块(如 过程中,用户或 基础上,我们正在考虑的层的上一个节目) 必须能够仅访问这样 信息和资源所必需 其legitima te 的用途。 1 [2]当应用于用户, 术语至少用户访问或 至少特权用户帐户(LUA) 也被使用,指的是 概念,在所有时间的所有用户 应 用尽可能少的权限运行可能的,并且还用尽可能少的权限启动应用程序 。

有很多技术可以帮助公司接受这一原则。许多技术属于同一类别,重点在于保留每一层的最终用户身份并回答以下问题:

'谁是真正的'用户'?

您至少应该意识到决定忽略最低特权原则并使用单个共享数据库用户帐户来处理中间层/应用程序服务器和数据库之间的所有交互的后果和风险。有一些技术可以保持数据库应用程序开发人员的工作效率,并且仍然在应用程序中提供强大的安全功能在这个空间技术的

实例包括但不限于:

  1. Kerberos票据或X.509证书 (SSL)。
  2. 代理验证 - 允许您继续共享连接,但代理服务器会为每个会话分配不同的角色。

除了安全性之外,还有其他一些优势来支持最小权限原则。在许多数据库中,只读连接可以执行得更好,因为它不需要知道和/或参与事务。

相关问题