目前，我的僱主在3臺服務器上部署了一個Web應用程序。是否使用Web服務公開.NET DAL添加安全性？
這樣做的原因是該理論認爲，如果Web服務器被攻破，他們不直接到達數據庫，而是到達DAL框。
在我看來，作爲DAL框和Web Sever框 - 都運行Windows/IIS - 如果公共框已經被入侵，相同的漏洞可能會在DAL框上工作 - 因此我不認爲這是一個真正的安全利益。
我想建議我們刪除中間機器並允許Web服務器直接連接到數據庫。
這個中間盒真的是一個好處嗎？
Web UI和數據庫之間的Web服務層的安全優勢充其量是最少的。即使使用slugster建議的網絡基礎設施，攻擊者也只能從他/她的機器上訪問Web服務。考慮到這種折衷方案很可能也會給攻擊者某種形式的遠程訪問Web服務器本身，您的網絡訪問限制是完全沒有用的。您可能會設法阻止某些形式的連接，但是如果有人有興趣訪問該框，一旦他們得到它，網絡上就沒有任何東西能夠區分攻擊者和合法用戶。
更糟糕的是，你被一個額外的代碼層所困住，你必須維護它來支持這個額外的層，這意味着你將會有更多的錯誤，並且需要更長的時間來創建新的特徵。
對此的一種方法是利用一些在建築環境中討論CQRS的人所描述的技術。特別是在this presentation by Udi Dahan中，他建議將數據庫放在Web服務器上，並且只將數據存儲在其中，以便支持該Web站點。其他數據，業務數據，存儲在別處，存儲在一個單獨的數據庫中。您還可以使用NoSQL數據庫（如MongoDB或RavenDB）來呈現數據，並完全放棄關係數據庫。
這裏有很多選擇，其中一些甚至會給你的安全級別認爲你得到你當前的架構。給這些決定提供一些批判性思維總是一個好主意，我發現你提出這些問題是令人鼓舞的。
祝你好運。
這幾乎是安全的混淆，但中間框提供了額外的安全級別，如果它也由相應的防火牆進行備份。如果數據庫被保存在安全的私人防火牆區域，則可以將Web服務機器放置在公共網站可訪問的中間層DMZ箱上。儘管利用這個漏洞可以在所有3個盒子上運行，但攻擊者仍然必須妥協2級防火牆才能部署漏洞利用。
如果這種性質沒有防火牆分離（儘管通過描述聽起來好像存在），那麼你是正確的，這個漏洞可以重複部署。這聽起來像你的公司在網站和Web服務DAL之間有一個防火牆，所以只要連接受到限制和監控，漏洞幾乎就變成了非事件。
使Web應用程序通過Web服務聯繫DAL層可以爲數據的安全性添加很多數據。它可能仍然有可能危害網絡應用程序，但是您剛剛讓剝削者無法進入數據庫。
如果您有它設置了這種方式：
web app --> | DAL layer | database
external | network | internal
DMZ
你可以設置你的網絡的路由，這樣就不可能從外部直接去它位於DMZ中的DAL層，或者甚至可能在網絡的內部部分。如果您通過特定端口使用二進制編碼WCF，則可以將防火牆規則設置爲僅允許Web服務器通過該特定端口連接到包含DAL層的計算機。這意味着如果您的Web應用程序受到攻擊，攻擊者將獲得的最多WCF端點的詳細信息，除非他們的攻擊從Web服務器啓動，否則它們將無法到達。
如果您僅通過使用DAL層中的存儲過程等來進一步混淆事件，那麼攻擊者如果到達DAL就可以執行的操作與Web應用程序使用的數據庫功能相同。控制DAL層意味着他可以繞過Web服務器上的任何驗證，但理想情況下驗證也應該存在於DAL層或數據庫存儲過程中（這是構建WCF服務的安全方法，您不要總是知道你的Web服務將遠離公衆視野，也許有一天需求會改變，Web服務將以一種任何人都可以稱之爲的方式暴露出來）。
假設公共Web服務器被防火牆限制爲只有80端口，並且dal盒再次被隔離到只有80端口 - 你是否仍然看到了好處？非常感謝您的答覆。 – Jonno 2010-06-12 23:52:34
@Jonno - 只要防火牆在那裏，就有絕對的好處。在我工作的地方我們有類似的設置，並且防火牆由運行監視程序的安全小組維護，以檢查3個防火牆層之間的所有連接。必須獨立利用防火牆的每一層，每次利用攻擊都會留下更多足跡。 – 2010-06-13 00:00:56
感謝您的回覆 – Jonno 2010-06-13 00:08:36