我有一個小的Web應用程序在應用程序服務器上訪問數據庫服務器上的非常敏感的數據。我一直在考慮在數據庫服務器上編寫一個只能由應用服務器使用的Web服務接口，而不是直接通過SQL連接訪問這些數據。Web服務作爲額外的安全層
我的想法是，如果應用程序服務器遭到黑客攻擊，他們將無法直接訪問數據。黑客必須處理另一層（界面），到時候我會處理這種情況。
我知道這會給Web應用程序增加一些延遲，但由於數據很敏感，我相信這是一個可以接受的平衡。
這個額外的「安全層」會讓我的系統更安全嗎？還是我錯過了什麼？
我認爲你的評論「到這個時候我會處理這種情況」是不合格的，但否則這是一個好主意。如果攻擊者損害了你的前端應用程序，你不一定會得到任何額外的時間來加強後端層。如果後端圖層包含在最有可能發生的情況下，那麼您會在發現前端圖層已被泄露的同時發現它。
後端層會提供幫助的原因是它只會向前層提供它所需的功能，而不是SQL的全部功能。而且它是深度防禦，因此攻擊者必須找到兩種不同的漏洞，並同時使用它們來通過這兩個層。
你真的想在這裏使用標準的三層架構。將Web服務器（無業務/應用程序邏輯）作爲前端;僅限靜態內容。它應該通過防火牆連接回應用程序服務器，防火牆只允許連接它（並且只能連接到特定的應用程序服務器）。然後，只允許該應用程序服務器與數據庫服務器通信。
互聯網 - >防火牆 - > Web服務器 - >防火牆 - >應用程序服務器 - >數據庫
有人黑客你的Web服務器，他們什麼也沒得到有關您的應用程序，該應用程序服務器上所有的生命（是的，他們可以連接到它，但只能使用定義的接口，至少應該減慢它們）。即使在應用程序服務器上，他們仍然需要將接口編制到數據庫中。這是這種類型的應用程序的標準安全架構。
我看到你來自哪裏，但它似乎聞到了一點「默默無聞的安全」給我。第一個要點是確保Web應用程序使用的SQL用戶被適當鎖定，並且只能訪問它需要的數據庫對象。例如，只讀訪問只需要讀取的表，寫訪問需要寫入的表。在MS SQL上，通過僅對小範圍的存儲過程執行訪問，這可以變得更簡單。用戶只需要SP上的執行訪問權限，並且不需要基礎表的權限。這將會利用數據庫級別的安全性，而不是使用額外的，可能不安全的抽象層。如前所述，您可以繼續添加更多層到您的架構，但是我會在使用已有的安全選項在地面上開始，然後再滾動您自己的。