安全地存儲數據

Question

我理解大多數情況下安全存儲數據的概念，包括將數據存儲在一個單獨的服務器上，該服務器只允許來自應用程序的連接，加密的密鑰對等等。但是，我仍然不明白如何分離服務器它更加安全。

例如，假設我有一個強化且安全的Web服務器，它從用戶輸入中捕獲數據以進行存儲。 數據經過加密並通過db查詢或Web服務提交給數據庫服務器。 數據庫服務器僅允許來自Web服務器的連接，並以加密形式存儲數據。 因此，如果有人訪問數據庫，則數據毫無價值。

但是，如果有人訪問Web服務器，他們將可以訪問數據庫以及加密算法和密鑰，不是嗎？ 既然如此，為什么甚至將數據放在不同的服務器上，因為數據傳輸只是另一個潛在的攻擊點？

有沒有辦法在Web服務器上隱藏連接信息和加密算法，這樣如果它被泄露，就無法訪​​問數據庫服務器？ 混淆是不夠的，我不會想到。 歡迎任何想法。

謝謝Brian

Answer 1

人們為安全設計的方式有一定的神奇思維和民間傳說，你是對的：將數據存儲在不同的服務器上並不一定能讓事情變得更加安全，除非你做過各種各樣的事情。太。

管理密鑰是其中很重要的一部分; 在Web應用程序的上下文中這樣做是一個獨立的主題，我不知道任何強大的PHP解決方案。 你是對的 - 如果你的web應用程序需要能夠解密某些東西，它需要訪問密鑰，如果web應用程序被泄露，攻擊者也可以訪問密鑰。

這就是為什么我傾向於使用公鑰加密，並將面向公眾的Web服務器視為“只寫” - 即Web服務器使用公鑰加密，存儲在數據庫中，並且永遠不能解密它; 只有一個單獨的進程（在公共互聯網上不可用）才能使用私鑰對其進行解密。 這樣，您可以在您的數據庫中存儲信用卡詳細信息，只有為卡充電的應用程序才有私鑰來解密它; 此應用程序在安全的環境中運行，無法從Internet訪問。

其次，有多種級別的妥協 - 例如，攻擊者可能獲得對服務器文件系統的只讀訪問權限。 如果該文件系統包含數據庫，則他們可以獲取數據文件，將其還原到他們控制的服務器，並使用解密密鑰竊取您的私人數據。 如果數據庫在單獨的服務器上運行（無法從Internet訪問），則此攻擊路徑將變得不可能。

一條攻擊路線讓你打開的事實並不意味着你無法抵御其他攻擊。

Answer 2

在我的大多數設置中，Web服務器位於防火牆的DMZ中，而DB位於防火牆后面。 我永遠不想把數據庫服務器放在防火牆之外。 額外的安全級別使得某人在未經授權的情況下更難獲取數據。

順便說一句，網上沒有網絡服務器應被視為“硬化和安全”。 如果它可供公眾使用，則可以被黑客入侵。 這只是他們想要嘗試的難度的問題。

你的假設是正確的，如果有人攻擊網絡服務器，他們可以作為管理員登錄，他們可以讀寫數據庫。 但這並不意味着您應該通過將數據庫放在Web服務器上來進一步削弱您的設置。 您需要更多安全性，而不是更少。

編輯：

始終考慮安全性中的層次 。 將關鍵部件分成單獨的層。 這樣做有兩件事。 它使perp有更多的問題需要解決，它給你更多的時間進行檢測和響應。

因此，在您的方案中，訪問Web服務器是一層，然后您可以為第二層（防火牆后面，另一層）調用加密服務器，並且加密服務器可能是唯一允許與之交互的機器。數據庫服務器，這是另一個層。

圖層使其更安全。 但是，它們也增加了負擔，減緩了響應時間。 因此，請根據您的實際需求保持平衡。

Answer 3

這里的問題是密鑰位於面向公眾的服務器上，可能會受到損害 - 即使服務器本身“硬化”，您的應用程序中可能存在漏洞，攻擊者可以訪問密鑰或數據。

為了提高安排的安全性，您可以將處理加密數據的代碼（以及密鑰）移動到只能由Web服務器訪問的安全機器上，並且只能通過非常有限的API（即最低限度的API）需要）。 記錄每個操作以發現異常行為，這可能是嘗試提取秘密數據的症狀。

Answer 4

從安全角度來看，將數據庫放入單獨的服務器並沒有多大幫助。 如果身份驗證令牌受到損害，則游戲結束。

但是 ，將數據庫和數據訪問層（DAL）與業務邏輯和表示分開是有意義的。 這樣，如果應用程序服務器成為不擇手段的犧牲品，則數據庫訪問僅限於特定的DAL操作，如果正確實施，這可能會使數據擺脫危害。

除此之外，將數據存儲隔離到單獨的服務器中沒有太大的安全益處。