我应该为不同的查询类型设置单独的SQL帐户吗?

对于不同类型的任务(例如,批处理作业和web服务),有不同的帐户是很有用的,并且对每个帐户的连接计数等都有限制。这意味着,如果你的批处理作业变得疯狂,它就无法取出你的web应用程序。

您还需要为不同的权限使用不同的帐户。例如,如果你的管理员和用户应用是分开的,他们应该有自己的帐户。这有助于确保,如果您的用户应用程序遭到破坏,它将不会对您的数据造成如此大的损害。

在这两方面,拥有一个“只读”用户是有用的,但前提是您的应用程序不执行写操作。

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

如果应用程序使用了这两种帐户类型,我认为您所指的做法是为了避免 sql injection attacks bobby tables !

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

对看见 Principle of least privilege

在信息安全领域,计算机 科学和其他领域 特权或最不特权, 计算系统的抽象层 环境,每个模块(例如 进程上的用户或程序 必须只能访问这些 对其合法性而言是必要的 意图 1 [2] 当应用于用户时, 最低特权用户帐户(LUA) 概念是所有用户在任何时候 可能的,也可以启动应用程序 尽可能少的特权。

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

'谁是“真正的”用户'?

您至少应该意识到,如果您决定忽略最小权限原则,并在中端/应用程序服务器和数据库之间的所有交互中使用单个共享数据库用户帐户,那么您将面临后果和风险。作为一名数据库应用程序开发人员,有一些技术可以保持高效,并在应用程序中提供健壮的安全特性。

该领域的技术示例包括但不限于:

1. Kerberos票证或X.509 证书(SSL)。
2. 代理身份验证-允许您继续将连接池化,但将代理作为每个会话的不同角色。

除了安全之外,接受最低特权原则还有其他好处。在许多数据库中,只读连接可以执行得更好,因为它不需要知道和/或参与事务。

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

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

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

• 将选择权授予ReportService
• 向TransactionService授予选择、更新、删除权限

然后,您可以根据需要将web应用程序作为ReportService或TransactionService运行。