|
|
1
1
唯一可以在Windows上验证的是 用户 . 没有 保护 确定 应用 . 因此,任何限制对特定应用程序的访问的尝试都可能被具有足够动机的攻击者击败。 您可以通过添加 logon trigger . 在触发器中,您可以从连接字符串检查声明的“应用程序名称”,如果不是,则关闭连接。这将阻止有人意外连接到您的服务器。但是,它不会阻止有动机的管理员访问数据,因为应用程序名可能被欺骗。如果你有 任何 管理和维护任务、管理员和维护任务都需要访问数据库。 一个稍微好一点的方法是通过批准来控制对数据的访问。Approle允许访问应用程序,您仍将使用自定义应用程序逻辑来限制内容管理(列限制和您引用的其他限制)。这将稍微提升条,以便只有应用程序可以修改和访问数据。它将阻止非管理员访问您的数据,但特权管理员将 总是 能够做他或她想做的事。 最后,通过部署加密还有一个更高的标准。一个真正有决心的管理员需要超越这一点,而一个必须采取特定步骤才能找到您的密钥密码的管理员,他无法意外地发现这些密码。如我所说,一个专门的管理员总是能够访问您的数据。 另一种选择是不部署任何屏障,而是使用审计来监视数据。篡改明显的审计可以在SQL Server中进行,并且广告审计通常具有足够的威慑力。 |
|
2
1
应用程序名可以是连接字符串的一部分,但可以被欺骗。如果你 需要 为了实现这一点,我将抽象出对应用服务器的数据访问,并通过它从客户机进行数据访问(大概使用Web服务)。然后,你的应用服务器可以使用一个已知的帐户与服务器进行对话(作为一个“可信子系统”),而各个客户机实际上并不是 需要 访问数据库(win:win,尤其是涉及防火墙时)。 就我个人而言,我倾向于将此作为我的默认模型…它从一开始就增加了很多未来的可伸缩性,而且事后很难添加。 |
|
|
3
1
你看过用 Application Roles 在SQL Server中? 您可以只将所有必需的权限授予应用程序角色,并且数据库登录将仅是没有其他权限的public成员。这样,即使有人通过ManagementStudio或其他直接连接获得访问权限,他们也无法在不知道应用程序角色凭据的情况下在数据库中执行任何操作。 编辑:在下面增加了加密部分,试图解决麦切的意见。 对于字段级粒度,可以使用SQL 2005及更高版本中的内置加密功能来限制对某些字段的各种角色的读取访问。这只适用于少数加密字段,而不是整行。在 this answer 对于加密SSN/信用卡信息的问题,我提供了一个代码示例,说明如何使用加密功能来确保只有特定用户才能在字段中解密数据。该示例目前设置为使用数据库用户,但也可以适应应用程序角色。如果选择用密码加密密钥,还可以防止具有系统管理员权限的DBA也能够解密加密的数据。 |
|
|
4
0
要将客户端应用程序的名称传递给SQL Server,请在连接字符串中设置“application name”参数。您可以使用
但是,如果要对不同的应用程序强制使用不同的权限,则必须使用每个应用程序的密码定义标准登录,而不是使用集成登录。 |