由胖客戶端訪問的安全SQL Server

有沒有辦法保護胖客戶端訪問的sql server數據庫？含義：應用程序直接與數據庫進行通信，因爲它本身會放置sql語句。這意味着，連接字符串必須位於客戶端的某個位置。使用這個連接字符串（無論是winauth還是sql server身份驗證），任何用戶都可以使用一些管理工作室或命令行訪問數據庫，並將不同的語句放入數據庫中，而不是GUI允許的數據庫。
該怎麼辦？此架構已修復時，我無法在客戶端和數據庫之間放置另一個層。由胖客戶端訪問的安全SQL Server

來源

2010-07-28 Uwe

這是SQL Server權限的用途。

您可以爲View或Stored Procedure上的用戶授予權限，而無需授予用戶對基礎表的權限。

你可能要考慮應用程序角色

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

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

來源

2010-07-28 11:07:31

我無法爲每個用戶創建一個視圖。所以需要有一些參數來識別用戶（或對象）。所以通過繞過軟件訪問這些參數可以被操縱。 – Uwe 2010-07-28 11:28:37

@Uwe您不必爲每個用戶創建不同的視圖。您只需確保他們（和應用程序）所連接的帳戶的權限有限。或者你是否說應用程序需要對象的權限，如果用戶可以以不受控制的方式直接訪問，那麼這會是一個問題？ – 2010-07-28 11:51:30

@Martin正是。用戶可以根據數據庫本身的內容刪除，查看和創建記錄。我無法將數據的權限映射到用戶。這就是應用程序邏輯的作用。 – Uwe 2010-07-28 12:33:08

首先是一個SQL注入漏洞的整點是攻擊者能夠操縱查詢。這個目的是一個更糟的漏洞。但不僅如此，這也是明顯違反CWE-602: Client-Side Enforcement of Server-Side Security和CWE-603: Use of Client-Side Authentication。

爲了使這個安全必須做到以下幾點：

每個用戶也必須有自己的鎖定數據庫。在他們只有選擇/更新/刪除/插入和沒有其他特權（特別是不是xp_cmdshell（）!!!!）。您不能允許用戶共享數據庫，否則攻擊者將能夠查看其他用戶信息。攻擊者將始終能夠獲取sql服務器的用戶名/密碼，並能夠直接與他自己的客戶端連接。很難將這種關係看作是安全的，在幾乎所有情況下，這都是巨大的脆弱性。

在所有現實中，這是一個非常嚴重的架構缺陷，您必須構建一個爲客戶端構建quires的服務器端組件。這通常使用SOAP（用於ms平臺的wcf）完成。

來源

2010-07-28 15:57:15 rook

對不起，我不明白？我應該如何爲我的每個員工分配客戶數據庫（例如）？他們需要訪問相同的數據，但受到他們獲得的權限限制（完全閱讀客戶A，但不讀取來自客戶B的發票） – Uwe 2010-07-29 06:51:05

@Uwe oah對不起，我不知道。那麼我認爲，由於非常嚴重的建築缺陷，這絕對不可能得到保證。您必須是一箇中間人，像SOAP服務一樣，爲構建quires而永久存在。同時請記住，攻擊者無需客戶端即可訪問SOAP服務，因此您無法實現客戶端安全系統。這是安全性的基礎，你永遠不能相信客戶（PERIOD）。 – rook 2010-07-29 14:54:29

在包括Windows和SQL身份驗證在內的所有安全模型中，訪問權授予用戶（身份），而不是授予應用程序。因此，應用程序所需的任何訪問權限都必須授予運行該應用程序的用戶。當使用Windows身份驗證時，這意味着同一用戶可以從SSMS查詢中利用應用程序本身所需的所有特權。這是任何管理員必須瞭解的基本規則。從安全的角度來看（這意味着CC遵守等事情），這是一個事實，任何企圖繞過它的嘗試都是註定的。

但是從實際的角度來看，有一些可以部署的措施。最常用的方法是使用驗證APP_NAME()的logon trigger，並允許僅從明確定義的一組客戶端工作站和一組明確定義的用戶訪問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;

重要的是要明白，這種機制是不安全功能，因爲它們可以通過一個惡意的用戶很容易規避。它們更像是門鎖：它們不會讓盜賊失去信心，它們保證誠實的用戶誠實。

來源

2010-07-28 16:10:05

+1你的權利，但你知道這有一個安全標籤，你並沒有真正提供安全解決方案。正如我**真的希望** OP沒有實現這個... – rook 2010-07-28 18:59:01

由胖客戶端訪問的安全SQL Server

回答

相關問題