Effective C# 優先選擇安全的程式碼

.Net運行時已經設計好了，一些懷有惡意的代碼不能滲透到遠端電腦上並執行。目前一些分部式系統依懶於從遠程機器上下載和執行代碼。如果你可以通過Internet或者乙太網路來發布你的軟體，或者直接從web上運行，但你須要明白CRL在你的程式集中的一些限制。如果CLR不是完全相信一個程式集，它會限制一些的行為。這些調用代碼要有訪問安全認證(CAS)。從另一方面來說，CLR強制要求基於角色的安全認證，這樣這些代碼才能或者不能在基於一個特殊的角色帳號下運行。

安全違例是運行時條件，編譯器不能強制它們。幸運的是，它們絕不會在你的開發機器上出現，而且你所編譯的代碼從你自己的硬體上載入，這就是說，它有更高的信任層級。討論所有潛在的.Net安全模型可以足足寫上幾本書，但你可以瞭解合理行為的一小部份，這樣可以讓你的程式集與.Net的安全模式更容易的互動。這些推薦只有在你建立一個組件程式庫時，或者是開發一些通過網路發布的組件和程式集是才可以參考應用。

通過這個討論，你應該記住.Net是一個託管的環境。這個環境保證有一個明確的安全環境。在安裝時可以用.Net的配置策略來管理安全性原則。大多數.Net架構庫是在安裝時對配置策略是安全信任的。它會查明安全問題，這就是說CLR可以檢測IL而且確保它不會有什麼潛在的危險行為，例如直接存取原始記憶體。它不會在訪問本地資源時要求特殊的安全許可權進行斷言。你應該試著遵守同樣的檢測，如果你的代碼不須要任何的安全許可權，就應該避免使用CAS的API來對斷定存取權限，否則你所做的只是降低程式效能。

你要使用CAS的API來訪問一些受保護的資源，而這些資源是要求增加的特權的。很多通用的受保護資源是非託管的記憶體和檔案系統。其它一些受保護的資源還包括資料庫，網路連接埠，windows註冊表，以及列印子系統。在每種情況下，如果調用代碼沒有足夠的許可，試著訪問這些資源都會引發一個異常。而且，訪問這些資源可能引發運行時建立一個安全棧上的詢訪，以確保當前棧上的所有的程式集有恰當的許可。讓我們看一下記憶體以及檔案系統，討論安全系統和機密問題中最實際的一些問題。

不管什麼時候，你都可以通過建立恰當的安全程式集來避免非託管記憶體訪問。一個安全的程式集，也就是一個不用使用任何指標來訪問其它非託管，或者託管的堆記憶體。不管你是否知道，你所建立的所有C#代碼幾乎都是安全的。除非你在C#編譯器上開啟了不安全的編譯開關/unsafe，否則你所建立的都是安全的程式碼(譯註：就算開啟了開關也不是說就編譯成不安全的程式碼了，還要看你的代碼是怎樣寫的。)。/unsafe充許使用者使用CLR不進行的驗證的指標。

要使用不安全的程式碼的原因很少，特別是一常規的任務中。指向原始記憶體的指標比要檢測的安全的引用快一些。在一些經典的數組中，它們可能要快上10倍以上。但當你使用不安全結構時，要明白任何的不安全的程式碼都會影響整個程式集。當你建立不安全塊時，應該考慮把這些演算法獨立到一個程式信中(參見原則32)。這樣可以在整個程式上限制不安全的程式碼的影響。如果它是獨立的，只有實際調用它的訪問者才會受到影響。其它剩下的，你還是可以在更嚴格的環境中使用安全機制。你可能還須要不安全的程式碼來處理一些須要直接指標的P/Invoke或者COM介面。同樣的推薦：獨立它。不安全的程式碼只會影響它自己的小程式集，不再有其它的。

對於訪問的建議很簡單：只要可能，都應該避免訪問非託管記憶體。

接下來的安全核心就是檔案系統。程式要儲存資料。從Internet上下載回來的代碼，檔案系統中的大多數地方都不能訪問，否則會有很大的安全性漏洞。是的，完全不許訪問檔案系統就很難建立能使用的程式。通過使用隔離儲存區 (Isolated Storage)可以解決這一問題。隔離儲存區 (Isolated Storage)可以穿越基於程式集而獨立的虛擬目錄，以及應用程式定義域，以及當前的使用者。選擇性的，你可以使用更一般的隔離儲存區 (Isolated Storage)虛擬目錄，該目錄是基於程式集或者目前使用者的。

實際上，受信任的程式集可以訪問他們自己特殊的隔離儲存區 (Isolated Storage)地區，但不能是檔案系統的其它地方。獨立的儲存目錄是隱藏在其它程式集以及其它使用者中的。你可以使用System.IO.IsolatedStorage名字空間中的類來訪問獨立的儲存。IsolatedStorageFile類包含的方法可以很簡單的訪問System.IO.File類。實際上，它是從 System.IO. FileStream 類派生下來的。寫內容到隔離儲存區 (Isolated Storage)的代碼幾乎與寫內容到任何檔案裡是一樣的：

  IsolatedStorageFile iso =
IsolatedStorageFile.GetUserStoreForDomain( );

IsolatedStorageFileStream myStream = new
IsolatedStorageFileStream( "SavedStuff.txt",
FileMode.Create, iso );
StreamWriter wr = new StreamWriter( myStream );
// several wr.Write statements elided
wr.Close();

讀操作也是完全和其它使用檔案I/O相似的： IsolatedStorageFile isoStore =
IsolatedStorageFile.GetUserStoreForDomain( );

string[] files = isoStore.GetFileNames( "SavedStuff.txt" );
if ( files.Length > 0 )
{
StreamReader reader = new StreamReader( new
    IsolatedStorageFileStream( "SavedStuff.txt",
    FileMode.Open,isoStore ) );

// Several reader.ReadLines( ) calls elided.

reader.Close();
}

你可以隔離儲存區 (Isolated Storage)來持久大小合適的資料元素，這些元素可以被代碼部分信任，用於從一個安全分離的本地磁碟上的某個地方儲存和載入資訊。.Net環境為每個程式定義和限制了隔離儲存區 (Isolated Storage)的大小。這可以預防一些惡意的代碼佔用磁碟空間，讓系統就得不可用。隔離儲存區 (Isolated Storage)對於其它程式和其它使用者來說是不可見的。也就是說，它不應用於要管理員手動操作才能布署或者配置設定的情況。即使這它是隱藏的，然而，隔離儲存區 (Isolated Storage)對於從受信任的使用者那來裡來的Unmanaged 程式碼來說也是不受保護的。不要用隔離儲存區 (Isolated Storage)來儲存一些高度機密的內容，除非你的程式給它加過密。

在檔案系統中建立一個可能要許可安全性原則的程式集時，要隔離儲存區 (Isolated Storage)流的內容。當你的程式集可能在web上運行，或者可能被運行在web上的代碼訪問時，應該考慮使用隔離儲存區 (Isolated Storage)。

你可能須要正確的使用一個受保護的資源。一般情況下，訪問這些資源要指出你的程式要被完全信任。唯一可選的就是完全避免使用這些受保護的資源。例如，考慮windows的註冊表，如果你和程式須要訪問註冊表，你必須安裝你的程式到終端使用者的機器上，這樣才能有必須的許可權來訪問註冊表。你想簡單點，從web上啟動並執行程式是不能建立註冊表的修改的。安全性原則就應該是這樣的。

.Net的安全模型意味著你的程式的行為是要權得進行核對的。注意你的程式所要求的權利，而且試著最小化它們。不必要求你不使用的權利。你的程式集越是少的要求受保護資源，那麼它們就越是可以保證安全性原則異常不拋出。避免使用機密資源，如果可能，要考慮其它可選方案。當你在某個演算法上確實須要更高安全的許可時，應該獨立這些代碼到它們自己的程式集中。