我們真的需要應用服務器嗎？

Question

我即將開始編寫可通過互聯網訪問的網絡應用程序（Asp.Net/IIS7）。它將放置在接受http和https的防火牆後面。

我們要替換的以前的系統不讓這個Web服務器直接與數據庫對話，而是讓它通過一個只允許這種調用的新防火牆進行高度專業化的Web服務調用一個單獨的應用服務器，然後去數據庫操作數據。

我已經在我的今天，很多系統的工作，但是這是一個已經採取安全這個嚴肅的第一個。這是一個常見的設置？我的第一個想法是在Web服務器上的連接字符串中使用Windows身份驗證，並讓用戶成爲一個殘缺的DB用戶（只能查看和更新​​自己的數據），然後允許通過內部防火牆訪問數據庫。

上午我天真？似乎我將不得不做大量的數據映射，如果我們使用當前的新系統設置。

編輯：這個應用程序的領域是在線訂購商品（企業對企業），用戶（企業）登錄，輸入他們可以在任何給定的時間段內交付什麼，查看以前的交易歷史，查看預計的商品需求等沒有實際的資金通過這個系統交換，但系統提供了在其產品可供銷售的信息，這是數據輸入到訂貨系統

Answer 1

在某些類型的環境中，特別是在大型交易系統（例如在線公司銀行業務）中，這種類型的安排（帶有Web服務器的DMZ，通過防火牆與應用服務器通信，通過防火牆與db通信）非常普遍

有這樣做的很好的安全方面的原因，其中最主要的是它會減慢你的系統的攻擊。它的傳統期限爲深度防禦（或防禦，如果你是在水面上的那一側）

合理的安全假設：你的網絡服務器會不斷受到攻擊

所以你堅持在DMZ並限制使用防火牆可以實現的連接類型。您還限制爲僅是一個網絡服務器的網絡服務器 - 這減少了可能的攻擊（攻擊面）

第二個合理的安全假設數：在某一點零日漏洞會被發現，將得到您的Web服務器，並允許它被破壞，這可能導致對用戶/客戶數據庫

攻擊所以，你有防火牆限制到應用服務器的連接數。

3合理安全的假設：零天將在應用服務器中找到，但如果你經常打補丁發現零天，同時在網絡和應用服務器的機率顯着減少。

因此，如果您的數據/交易的價值足夠高，那麼添加額外的圖層對於保護您自己而言可能至關重要。

Answer 2

配置用戶的訪問權限似乎是一個更強大的解決方案給我。你的DataAccess層也應該內置一些安全性。添加這個附加層可能最終會導致性能下降，但這取決於您使用什麼機制將數據從「WebServer1」移動到「WebServer2」。沒有這方面的更多具體信息，就不可能給出更加可靠的答案。

Answer 3

我們有一個類似配置的應用程序。接口層駐留在DMZ中的Web服務器上，DAL位於防火牆內的服務器上，並通過Web服務橋接它們之間的空隙。與此相關的是，我們在防火牆內部有一個授權管理器，該管理器公開另一個用於控制允許用戶在應用程序中查看和執行的Web服務。這個應用程序在我們的主要客戶數據跟蹤系統之一，並可供我們的內部員工和外部承包商使用。它還處理醫療信息，所以它屬於HIPAA規則。因此，雖然我認爲這種設置並不常見，但在高度敏感的數據或需要由監管機構處理審計的情況下尤其如此。

Answer 4

任何合理可擴展，合理安全的傳統Web應用程序都將使用一個或多個服務和緩存層將數據庫從Web計算機中提取出來。 SQL注入是滲透/破解/破解的主要載體之一，數據庫往往是整體架構/ TOC中更復雜，最昂貴的部分之一。使用服務層允許您將邏輯移出數據庫，使用進程外高速緩存，屏蔽數據庫以避免注入嘗試等。您可以通過這種方式獲得更好，更便宜，更安全的性能。當涉及升級，冗餘或維護時，它還允許更大的靈活性。