SQL連接字符串安全

Question

我們有一個內置的asp.net網站，運行在Windows安全的IIS上。根據我的理解（並觀察），這意味着每個線程都使用連接到該網站的用戶的憑據運行。

該網站連接到SQL Server 2014數據庫。我們使用SQL Server用戶名和密碼進行連接。看看MSDN我發現不建議使用SQL Server身份驗證。

登錄的SQL Server帳戶的密碼。 不建議。爲了保持高度的安全性，我們強烈建議您使用集成安全性或Trusted_Connection關鍵字。 SqlCredential是爲使用SQL Server身份驗證的連接指定憑據的更安全的方式。

由於對網站刪除Windows安全性是不是一種選擇，我看到遵循MSDN建議的唯一選擇是：

1. 忽略MS的建議，並使用SQL身份繼續爲我們

2. 給每個網站用戶與當前SQL Server憑證具有相同的SQL Server訪問權限。這意味着如果任何用戶直接連接到服務器，他們可以運行自己的查詢，而不是限於我們編碼的內容。也許某種防火牆規則可以解決這個問題。該業務不是這個想法的粉絲（我不是）

3. 給每個用戶連接訪問權限（沒有其他權限）並使用應用程序角色在用戶通過網站連接時提供權限。

4. 每次連接到SQL Server時，都應該在模擬有權訪問的域用戶的線程上完成。

這些選項聽起來都沒有比使用SQL Server用戶名和密碼更好。

建議連接數據庫的方式是什麼？

Answer 1

我們有一個內置的asp.net網站，運行在Windows安全的IIS上。根據我的理解（並觀察），這意味着每個線程都使用連接到該網站的用戶的憑據運行。

正確。

該網站連接到SQL Server 2014數據庫。我們使用SQL Server用戶名和密碼進行連接。

好的，所以在這個過程中，你會丟失傳遞給網站的Windows/NTLM安全令牌。

[...選項...]

應用程序角色是此任務的正式方案。選項（4）也可以工作，但是在認證過程中有開銷。不過，我會去爲「不關心」的選項，這就是爲什麼：

我前一段時間實施的TDS協議。 （該協議的細節可以在MSDN上找到：https://msdn.microsoft.com/en-us/library/dd357628.aspx）。基本上有兩種認證方式：

• 使用標準質詢 - 響應協議（例如用戶名/密碼認證）;
• 使用集成安全性AD/Kerberos認證;
• 在所有情況下，您都可以選擇TLS/SSL加密。

從安全角度來看，它是足夠安全的。那就是：我不會直接暴露我的SQL Server到互聯網，但是這主要是因爲這沒有任何意義，我...

我也見過微軟的評論，這也困擾了我當時出於幾個不同的原因：

• 如果您執行集成安全性，它必須檢查每個連接的Active Directory。對於少數用戶來說這可能很好，但對於很多用戶來說，我不會那麼喜歡。
• 只要他們在線提供此評論，SQL Azure就不支持集成安全性。如果它確實非常不安全，那沒有任何意義。
• 主要優點是您不必在web.config中輸入用戶名和密碼。然後，我不會直接將SQL服務器直接暴露給互聯網，如果惡意的人可以訪問您的Web服務器，他可以直接或間接地爲您的數據庫執行許多令人討厭的事情。

在有些情況下Windows身份驗證更有意義的情況下，特別是如果你使用基於角色的安全性在數據庫中限制爲架構的，等等。在這些情況下，個人角色的訪問，這是毫無意義的使用單帳戶。

坦白說，我也可以從另一個角度解釋意見是這樣的：微軟的完全許可模式是基於CAL的，這是由AD帳戶數量進行檢查。通過推動所有人使用集成安全性，執行這種許可模式要容易得多。

所以，做一個長話短說，我不會理會它，只是堅持的用戶名/密碼認證。