ASP.NET Core 資料保護概觀

  • 發行項

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 Core 資料保護 API 主要並非針對機密承載的無限期保存。 Windows CNG DPAPI 和 Azure Rights Management 等其他技術更適合無限期儲存體的案例，而且具有對應的強金鑰管理功能。 也就是說，沒有什麼可以禁止開發人員使用 ASP.NET Core 資料保護 API 來長期保護機密資料。

對象

資料保護系統分成五個主要套件。 這些 API 的各個層面都是針對三種主要受眾；

  1. 取用者 API 概觀 是針對應用程式和架構開發人員。

    「我不想了解堆疊的運作方式，或了解堆疊的設定方式。 我只想以盡可能簡單，而且成功使用 API 的可能性很高的方式來執行某些作業。」

  2. 設定 API 是針對應用程式開發人員和系統管理員。

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

  3. 擴充性 API 是針對負責實作自訂原則的開發人員。 這些 API 的使用僅限於罕見的情況和有經驗的安全性感知開發人員。

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

封裝配置

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

其他資源