代码之家 › 专栏 › 技术社区 › E.J. Brennan

SQL Server和ASP.NET应用程序安全模型/最佳实践[关闭]

security sql-server asp.net

E.J. Brennan · 技术社区 · 16 年前

对于针对SQL Server的ASP.NET Web应用程序(至少是需要登录才能访问的应用程序),我通常实现以下安全性:

我通常会滚动我自己的用户注册、用户登录页面,并在SQL Server中保留一个用户ID和一个加密密码,并根据该表验证登录-我还提供了忘记的密码、“发送我的密码”、电子邮件验证以激活帐户等所有自定义代码。

一旦应用程序对用户进行了验证(假设所有用户都具有相同的权限),我通常使用实用工具logon id让ASP.NET与SQL Server对话,因此换句话说,我只需要为每个应用程序创建一个登录ID,而且由于所有数据访问的100%都是通过存储过程完成的,所以我只需要授予对单个应用程序的访问权限。用户执行存储过程,而不需要在SQL Server上执行其他工作。每个应用程序都有自己的数据库,该应用程序的登录只能访问该数据库。

所有这些对我来说都很好,唯一的缺点是能够在SQL Server中设置跟踪并查看正在调用的用户ID和进程是很好的,但是由于所有用户都通过一个数据库登录与数据库“对话”,所以这是不可能的。

所以,两部分问题:

1)你们有没有安全模型是我应该考虑的?一次又一次地做同样的事情是很容易的,特别是因为它是有效的——但是有没有其他的模型可以更好地工作或者我应该考虑?是否建议从ASP.NET应用程序访问的所有数据库都共享一个数据库登录名?或者这被认为是不好的做法?如果是这样,为什么?

2)假设我坚持使用我的模型,是否有一种方法允许在SQL跟踪窗口中看到应用程序登录ID?很高兴看到正在调用的SP和登录到系统的人的用户ID(而不是数据库登录名)。

6 回复 | 直到 15 年前

Otávio Décio 16 年前

建议的做法是从ASP.NET应用程序访问数据库会共享一个数据库吗? 登录?

是的,主要用于连接池。

对于2),我通常通过在ASP.NET端登录来实现这一点。

JoshBerke 16 年前

1)建议您的Web应用程序通常使用单一的数据库登录。如果你不这样做,你将被迫模仿你的呼叫者,这是典型的不推荐,而且它的规模不太好。不应为每个用户使用不同的连接字符串。例如,对每个用户使用SQL身份验证是一个坏主意。这将使连接轮询无效。

2)您可以通过修改连接字符串来做到这一点,但这会使连接轮询无效。

user25623 16 年前

从.NET最佳实践的角度来看,您可能需要考虑 Microsoft Enterprise Library . 它包含一组帮助解决安全和数据访问等问题的实践、模式和功能。

Sam 16 年前

1)只要使用存储过程进行访问,一次登录就可以了。有些人也喜欢用一个来管理。

2)您可以修改存储过程以接受用户ID作为参数。

Robin Day 16 年前

我通常会为连接池共享一个用户。

在这种情况下,您可能需要跟踪特定的用户。我编写了管理功能,您可以在其中使应用程序使用第二个数据库登录。然后,您可以为特定用户启用此功能,并单独跟踪该用户。

这只意味着您可以一次性跟踪,同时为应用程序的其余部分保留单个用户连接池。

R.MacLean 15 年前

我也用同样的方法。最近,我想知道这是否影响了应用程序的可伸缩性。我的数据库服务器有多核处理器,能够进行并行操作,但我认为SQL Server序列化查询使用相同的userid运行。我认为这意味着来自不同实际用户的存储过程正在排队,因为SQL Server认为它们都来自同一个用户ID。

如果是这样的话,我想这会严重限制我的应用程序的可伸缩性,不是吗?