若有任何問題請來信：gss_crm@gss.com.tw
❗ 保護敏感資料不一定需要用 Data Protection API，但 .NET Core 有提供這一方案給各位參考，使用上也非常單純！
簡單科普編碼、加密、雜湊之區別
編碼（Encode）
編碼是將資訊從一種形式或格式轉換為另一種形式的過程，是可逆的（解碼）。
常見：URL、HTML、Base64、Unicode、UTF-8、Big5...等等編碼。
加密（Encrypt）
類似於編碼也是將資訊從一種形式轉換為另一種形式，但不同的是加密會需要特定的金鑰及其相對應的解密過程，也是可逆的（解密）。而加密又有區分為對稱及非對稱加密。
對稱：透過一把金鑰就能加解密，常見：DES、AES...等等對稱加密。
非對稱：透過搭配私鑰和公鑰才能正確加解密，常見：RSA...等等非對稱加密。
雜湊（Hash）
將任意長度的資料轉換為固定長度的資料（類似人的指紋，各有不一，但能識別其人），過程是不可逆的。
只要輸入資料有一點小變化，雜湊出來的資料就會有很大的變化。
雜湊還有一個特性，若輸入資料相同，雜湊結果就會相同，所以很適合拿來對密碼做處理。
常見：MD5、SHA256、SHA512...等等雜湊函式。
資料保護 Data Protection API
DPAPI（Data Protection API）是一個單純的密碼學應用程式介面，最早出現在 Windows 2000，其後的 Windows 作業系統也都有其影子存在…
DPAPI 理論上可以對任何種類的資料進行對稱式加密（Symmetric Encryption）…
Windows 作業系統中主要被用來將非對稱私鑰做對稱式加密，而其中運用使用者或系統的秘密（Secret）作為熵（Entropy）的重要來源…
❗ DPAPI 本身不會自己儲存持久性資料，它只將明文轉換為密文（反之亦然）…
⭐ Entropy (information theory)
.NET Core Data Protection
所以在經過一段時間淬鍊下 .NET Core Data Protection 就誕生了，其實微軟他們也想了很多，才把它實現出來…
- 問題陳述
- 設計理念
- API 受眾
- 套件佈局
⭐ ASP.NET Core Data Protection
❤️ .NET Core Data Protection 旨在取代舊有 .NET Framework 1.x – 4.x 中大家熟悉的 MachineKey 加解密，同時可為現代應用程式隨即使用的解決方案！
實際演練
- 從 DataProtectionProvider 取得 DataProtector
- 呼叫 Protect 方法保護你/妳想保護的資料
- 呼叫 Unprotect 方法將被你/妳保護的資料解回原貌
1️⃣ 建立一個 Security 資料夾並創建一個儲存目的字串（Purpose Strings）的類別…
2️⃣ 將儲存目的字串的類別註冊為 Singleton，方便之後注入…
❗ 以上兩步供各位參考，但實際怎麼做會更好，還有討論空間…
❓ 至於為什麼需要定義目的字串類別？往下看就知道囉！
3️⃣ 引入 Microsoft.AspNetCore.DataProtection 並從 DataProtectionProvider 取得 DataProtector
- CreateProtector(string purpose)
- CreateProtector(IEnumerable<string> purposes)
- CreateProtector(string purpose, params string[] subPurposes)
換句話說，當今天我是以字串 "A" 建立 Protector 的話，若是以字串 "B" 建立 Protector 就無法解除由 A Protector 保護的資料哦！
❗ Purpose Strings 不用特別去加密它，它主要是用來呈現你/妳的使用意圖！
⭐ Purpose strings in ASP.NET Core
官方對於 Purpose Strings 如何定義有給出一個建議答案…
眼尖的你/妳可能有發現我把它定義為字串陣列如下：
new string[] { "Web.Controllers.RegionController", "RegionIdRouteValue" }
你/妳可以把它理解成我的意圖如下：
在 RegionController 中去保護 RegionIdRouteValue 實際數值…
既然它是陣列，也並沒有侷限只能傳兩個，就看你/妳如何去定義。但數值當中不能有 null 哦（文件有寫明）！
4️⃣ 對需要保護的資料呼叫 Protect 來保護，反之呼叫 Unprotect 解除保護…
因範例專案並沒有實際去接資料庫，所以你/妳可以把 Region 當成回傳給 View 的 Model，應該會清楚不少。
❤️ 實務上我並不想讓前端知道 Region 實際的 Id 是什麼，所以透過 Data Protection API 就可以幫忙我們保護實際數值，直到它真正需要被利用時才解除保護！
情境測試
❗ 注意觀察 URI 的變化…
資料保護前：
資料保護後：
範例專案可參考…
額外參考
結尾
感謝各位花時間看完此篇文章，如果本文中有描述錯誤，還請各位多多指教。
.NET Core 其實有 DPAPI 這一現成方案可以來幫忙我們保護敏感資料，以往若是有這種需求通常都會自己造輪子來做…
造輪子也不是不好，但就難在如何把整個加解密架構做得很好很安全，理論上開發人員只需要知道如何使用加解密程式，而不能太深入了解內部如何加解密…
微軟針對 .NET Core Data Protection 就有想了 3 方面的受眾，你/妳就知道為什麼了…
因為開發人員的職責並沒有一定包含管理密碼，如果搞得大家都知道如何管理密碼，這樣的密碼相當於沒有安全性可言…
❗ ❗ ❗ 如果想要知道更多 DPAPI 私鑰的管理做法，可以參考接下來出的第二篇，重點將會著重於此！！
本文章也曾發表於我的 Blog 中，歡迎到裡面查查我其他分享的文章哦！