.NET Framework 中的安全性支持在版本 2.0 中備受關愛，本月我將帶您快速瀏覽在其中發現的引人之處。我不會討論所有內容，但您將會了解從哪里開始查看，并在哪里停留以查看新的變化。我每次討論一個命名空間。對了，要提出這樣顯而易見的警告：這是測試版軟件，所以我這里講述的所有內容在最終版本發行之前都有可能更改。
System.Security
托管字符串對機密內容來說并不是好的存儲媒體。的確沒有辦法刪除一個。垃圾回收對改寫所收集的內存沒有任何擔保，在很多情況下，在由堆壓縮進行改寫之前，成為垃圾的字符串仍會在托管堆中保留一段時間。并且，垃圾回收器可能會在托管堆中到處移動它們。將其與不能將舊內存清零的事實結合起來，您可能會終止地址空間中您試圖保存機密的許多字符串實例。引入了一個新類 SecureString 來幫助解決這些問題。
該類使用數據保護 API (DPAPI) 保護的內存模型存儲其數據。換句話說，數據總是以其加密的形式存儲在 SecureString 內。密鑰是由本地安全性授權子系統 (LSASS.EXE) 通過 DPAPI托管的，這些數據可以通過進程間通信解密。
為了使該類更加有效，任何讀取機密數據（可能是來自控制臺的密碼，也可能是來自 Web.config 的連接字符串）的 .NET Framework 方法都需要直接封裝 SecureString 中的數據并將它返回給您。您不能僅通過用 SecureString來包裝普通字符串，就期望會更加安全 — 為了更加有效，不能在一個普通托管字符串中放置機密內容。
同樣的規則也適合于將機密返回給 .NET Framework。例如，ProcessStartInfo 中的 Password 新屬性（隨后將講到）是 SecureString 類型的。在內部，當需要機密數據時，.NET Framework 將通過 Marshal.SecureStringToBSTR 等新函數使用 Marshal 類來檢索機密數據的實際內容。因為 Marshal 類是在非托管內存中處理的，所以當框架使用結束后，可以將這些內存正確地清零。毫無疑問，您不能使用 ToString 來檢索來自 SecureString 的機密。記住，永遠不能將機密數據最終保存在普通字符串對象中。
但是我弄不明白的一件事就是在交換文件之外保守機密的方法。當機密數據未進行封送處理就進入本機內存時，我想沒有什么辦法可以保證未進行封送處理的頁面可以通過 VirtualLock 進行鎖定。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
