共用方式為


ASP.NET Core 資料保護概觀

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

Web 應用程式通常需要儲存機密資料。 Windows 資料保護 API (DPAPI) 不適用於 Web 應用程式。

ASP.NET Core 資料保護堆疊的設計旨在:

  • 為大部分的 Web 案例提供內建解決方案。
  • 解決先前加密系統的許多不足問題。
  • 做為 ASP.NET 1.x - 4.x 中 <machineKey> 項目的取代項目。

問題陳述

我需要保存信任的資訊以供稍後擷取,但我不信任持續性機制。 若使用 Web 術語,這可能會表達為我需要透過不受信任的用戶端來回往返信任狀態

真實性、完整性和防竄改是必要條件。 這個標準範例是驗證 cookie 或持有人權杖。 伺服器會產生我是 Groot,並具有 xyz 權限的權杖,並將其傳送給用戶端。 用戶端會將該權杖呈現回伺服器,但伺服器需要用戶端並未偽造權杖的某種保證。

機密性是必要條件。 由於伺服器信任保存狀態,因此此狀態可能包含不應向不受信任用戶端公開的資訊。 例如:

  • 檔案路徑。
  • 權限。
  • 控點或其他間接參考。
  • 某些伺服器特定的資料。

隔離是必要條件。 由於新式應用程式已元件化,因此個別元件需要利用這個系統,而不考慮系統中的其他元件。 例如,請考慮使用此堆疊的持有人權杖元件。 其應該在沒有任何干擾的情況下運作,例如,來自也使用相同堆疊的反 CSRF 機制。

一些常見的假設可以縮小需求範圍:

  • 在密碼編譯系統內運作的所有服務都同樣受信任。
  • 資料不必在我們直接控制的服務外部產生或取用。
  • 作業必須快速,因為對 Web 服務的每個要求可能會經歷一次或多次密碼編譯系統。 速度需求會使對稱密碼編譯變得理想。 除非必要,否則不會用到非對稱密碼編譯。

設計理念

ASP.NET Core 資料保護是易於使用的資料保護堆疊。 其是以下列原則為基礎:

  • 輕鬆設定。 系統會努力進行零設定。 在開發人員需要設定特定層面 (例如金鑰存放庫) 的情況下,這些特定設定並不困難。
  • 提供基本的取用者面向 API。 API 使用上很簡單,且難以不正確地使用。
  • 開發人員不必學習金鑰管理原則。 系統會代表開發人員處理演算法選取和金鑰存留期。 開發人員無法存取原始金鑰資料。
  • 金鑰在 rest 會盡可能受到保護。 系統會找出適當的預設保護機制,並自動套用該機制。

資料保護 API 主要不適合無限期保存機密承載。 Windows CNG DPAPIAzure Rights Management 等其他技術更適合無限期儲存體的案例,且具有對應的強金鑰管理功能。 其具有對應的強式金鑰管理功能。 也就是說,ASP.NET Core 資料保護 API 可用於長期保護機密資料。

受眾

資料保護系統提供以三個主要物件為目標的 API:

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

    我不想了解堆疊的運作方式,或了解堆疊的設定方式。 我只想以成功使用 API 可能性很高的方式來執行某些作業。

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

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

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

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

封裝配置

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

其他資源

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

Web 應用程式通常需要儲存機密資料。 Windows 資料保護 API (DPAPI) 不適用於 Web 應用程式。

ASP.NET Core 資料保護堆疊的設計旨在:

  • 為大部分的 Web 案例提供內建解決方案。
  • 解決先前加密系統的許多不足問題。
  • 做為 ASP.NET 1.x - 4.x 中 <machineKey> 項目的取代項目。

問題陳述

我需要保存信任的資訊以供稍後擷取,但我不信任持續性機制。 若使用 Web 術語,這可能會表達為我需要透過不受信任的用戶端來回往返信任狀態

真實性、完整性和防竄改是必要條件。 這個標準範例是驗證 cookie 或持有人權杖。 伺服器會產生我是 Groot,並具有 xyz 權限的權杖,並將其傳送給用戶端。 用戶端會將該權杖呈現回伺服器,但伺服器需要用戶端並未偽造權杖的某種保證。

機密性是必要條件。 由於伺服器信任保存狀態,因此此狀態可能包含不應向不受信任用戶端公開的資訊。 例如:

  • 檔案路徑。
  • 權限。
  • 控點或其他間接參考。
  • 某些伺服器特定的資料。

隔離是必要條件。 由於新式應用程式已元件化,因此個別元件需要利用這個系統,而不考慮系統中的其他元件。 例如,請考慮使用此堆疊的持有人權杖元件。 其應該在沒有任何干擾的情況下運作,例如,來自也使用相同堆疊的反 CSRF 機制。

一些常見的假設可以縮小需求範圍:

  • 在密碼編譯系統內運作的所有服務都同樣受信任。
  • 資料不必在我們直接控制的服務外部產生或取用。
  • 作業必須快速,因為對 Web 服務的每個要求可能會經歷一次或多次密碼編譯系統。 速度需求會使對稱密碼編譯變得理想。 除非必要,否則不會用到非對稱密碼編譯。

設計理念

ASP.NET Core 資料保護是易於使用的資料保護堆疊。 其是以下列原則為基礎:

  • 輕鬆設定。 系統會努力進行零設定。 在開發人員需要設定特定層面 (例如金鑰存放庫) 的情況下,這些特定設定並不困難。
  • 提供基本的取用者面向 API。 API 使用上很簡單,且難以不正確地使用。
  • 開發人員不必學習金鑰管理原則。 系統會代表開發人員處理演算法選取和金鑰存留期。 開發人員無法存取原始金鑰資料。
  • 金鑰在 rest 會盡可能受到保護。 系統會找出適當的預設保護機制,並自動套用該機制。

資料保護 API 主要不適合無限期保存機密承載。 Windows CNG DPAPIAzure Rights Management 等其他技術更適合無限期儲存體的案例,且具有對應的強金鑰管理功能。 其具有對應的強式金鑰管理功能。 也就是說,ASP.NET Core 資料保護 API 可用於長期保護機密資料。

受眾

資料保護系統提供以三個主要物件為目標的 API:

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

    我不想了解堆疊的運作方式,或了解堆疊的設定方式。 我只想以成功使用 API 可能性很高的方式來執行某些作業。

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

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

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

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

封裝配置

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

其他資源