Question

有没有办法保护胖客户端访问的SQL Server数据库？含义：应用程序在放置sql语句本身时直接与数据库通信。这意味着，连接字符串必须位于客户端的某个位置。使用此连接字符串（使用winauth或sql server身份验证），任何用户都可以使用某个管理工作室或命令行访问数据库，并将不同的语句放置到数据库，而不是GUI允许他。该怎么办？我不能在客户端和数据库之间放置另一层，因为这个架构正在修复。

Answer 1

在所有安全模型（包括Windows和SQL身份验证）中，访问权限都授予用户（标识），而不是应用程序。因此，必须向运行应用程序的用户授予应用程序所需的任何访问权限。使用Windows身份验证时，这意味着同一用户可以从SSMS查询中利用应用程序本身所需的所有权限。这是任何管理员必须了解的基本规则。从安全的角度来看（意味着CC合规等等），这是一个事实，任何绕过它的企图都是注定的。

但从实际角度来看，有一些措施可以部署。最常用的是使用logon trigger来验证APP_NAME()，并且只允许从定义良好的客户端工作站集以及明确定义的用户集访问SSMS。

CREATE TRIGGER reject_SSMS
ON ALL SERVER WITH EXECUTE AS '...'
FOR LOGON
AS
BEGIN
IF (APP_NAME() = 'Microsoft SQL Server Management Studio' 
   OR APP_NAME() = 'Microsoft SQL Server Management Studio - Query')
   AND (ORIGINAL_LOGIN() NOT IN (...)
   OR HOST_NAME() NOT IN (...))
    ROLLBACK;
END;

重要的是要了解这些机制是 NOT 安全功能，因为它们很容易被恶意用户规避。它们更像是门锁：它们不会让小偷出局，而是让诚实的用户诚实。

Answer 2

这就是SQL Server权限的用途。

您可以执行诸如在View或Stored Procedure上为用户授予权限而不向用户授予基础表权限的操作。

您可能需要查看“应用程序角色”

http://msdn.microsoft.com/en-us/library/ms190998.aspx

http://www.sqlservercentral.com/articles/Security/sqlserversecurityprosandconsofapplicationroles/1116/

Answer 3

首先，SQL注入漏洞的全部内容是攻击者能够操纵查询。这个目的协议是一个更糟糕的漏洞。但这不仅明显违反了CWE-602: Client-Side Enforcement of Server-Side Security和CWE-603: Use of Client-Side Authentication。

为了确保安全，您必须执行以下操作：

每个用户还必须拥有自己的锁定数据库。因为他们只有select / update / delete / insert而没有其他权限（尤其不是xp_cmdshell（）!!!! ）。您不能允许用户共享数据库，否则攻击者将能够查看其他用户信息。攻击者始终能够获取sql server的用户名/密码，并能够直接与自己的客户端连接。很难想象这种关系是安全的，几乎在所有情况下这都是巨大的漏洞。

在所有现实中，这是一个非常严重的架构缺陷，您必须构建一个服务器端组件，为客户端构建quires。这通常使用SOAP（ms平台的wcf）完成。

胖客户端访问的安全SQL Server

3 个答案: