ASP.NET 核心資料保護概觀

  • 發行項

ASP.NET Core 資料保護提供密碼編譯 API 來保護資料，包括金鑰管理和輪替。

Web 應用程式通常需要儲存安全性敏感性資料。 Windows 提供資料保護 API DPAPI，但 Windows DPAPI不適用於 Web 應用程式。

ASP.NET Core 資料保護堆疊的設計目的是要長期取代 < ASP.NET 1.x - 4.x 中的 machineKey > 元素。 其設計目的是要解決舊密碼編譯堆疊的許多缺點，同時為大部分的使用案例提供現用的解決方案，而新式應用程式可能會遇到。

問題陳述

整體問題聲明可以在單一句子中簡潔地陳述：我需要保存信任的資訊以供稍後擷取，但我不信任持續性機制。 在 Web 詞彙中，這可能以「我需要透過不受信任的用戶端來回信任的狀態」撰寫。

這個標準範例是驗證 cookie 或持有人權杖。 伺服器會產生「我為 Groot，並具有 xyz 許可權」權杖，並將它交給用戶端。 在未來的日期，用戶端會將該權杖呈現回伺服器，但伺服器需要某種保證，用戶端尚未偽造權杖。 因此，第一個需求： (完整性、竄改) 。

由於伺服器信任持續性狀態，因此我們預期此狀態可能包含作業環境特有的資訊。 這可能是檔案路徑、許可權、控制碼或其他間接參考的形式，或伺服器特定資料的其他部分。 這類資訊通常不應該洩漏給不受信任的用戶端。 因此，第二個需求：機密性。

最後，由於新式應用程式已元件化，因此我們所看到的是，個別元件會想要利用此系統，而不考慮系統中的其他元件。 例如，如果持有人權杖元件使用此堆疊，它應該會運作，而不會干擾可能也使用相同的堆疊的反 CSRF 機制。 因此，最終需求：隔離。

我們可以提供進一步的條件約束，以縮小需求的範圍。 我們假設在密碼編譯系統內運作的所有服務都同樣受信任，而且資料不需要在直接控制下的服務外部產生或取用。 此外，我們需要儘快執行作業，因為對 Web 服務的每個要求可能會經歷密碼編譯系統一或多次。 這可讓對稱密碼編譯適合我們的案例，而且我們可以將非對稱式密碼編譯折扣，直到需要這類時間為止。

設計原理

我們一開始會找出現有堆疊的問題。 一旦完成，我們調查了現有解決方案的架構，並認為沒有任何現有的解決方案具有我們尋求的功能。 接著，我們已根據數個指導方針來設計解決方案。

  • 系統應該提供設定的簡單性。 在理想情況下，系統會是零組態，而開發人員可以達到執行基礎。 在開發人員需要設定特定層面 (，例如金鑰存放庫) 的情況下，應考慮讓這些特定設定變得簡單。

  • 提供簡單的取用者面向 API。 API 應該很容易正確使用，而且難以正確使用。

  • 開發人員不應該瞭解主要管理原則。 系統應該代表開發人員處理演算法選取和金鑰存留期。 在理想情況下，開發人員應該永遠不會存取原始金鑰資料。

  • 盡可能保護待用金鑰。 系統應該找出適當的預設保護機制，並自動套用它。

請記住這些原則，我們開發了簡單、 容易使用的 資料保護堆疊。

ASP.NET 核心資料保護 API 主要不適合無限期保存機密承載。 Windows CNG DPAPI和Azure Rights Management等其他技術更適合無限期儲存的案例，而且其具有對應的強金鑰管理功能。 也就是說，沒有任何禁止開發人員使用 ASP.NET 核心資料保護 API 來長期保護機密資料。

適用對象

資料保護系統分成五個主要套件。 這些 API 的各個層面都以三個主要物件為目標;

  1. 取用者 API 概觀以應用程式和架構開發人員為目標。

    「我不想瞭解堆疊的運作方式，或瞭解其設定方式。 我只想以盡可能簡單的方式執行某些作業，並成功使用 API 的機率很高。」

  2. 組 態 API 是以應用程式開發人員和系統管理員為目標。

    「我需要告訴資料保護系統，我的環境需要非預設路徑或設定。」

  3. 擴充性 API 是以負責實作自訂原則的開發人員為目標。 這些 API 的使用方式僅限於罕見的情況，且具有安全性感知的開發人員。

    「我需要取代系統中的整個元件，因為我確實有獨特的行為需求。 我願意學習不常使用的 API 介面元件，以建置符合我需求的外掛程式。」

封裝配置

資料保護堆疊包含五個套件。

其他資源