• 發行項

本文章是由機器翻譯。

深究 CLR

將 APTCA 組件移轉至 .NET Framework 4

Mike Rousos

在 Microsoft.NET Framework 4，通用語言執行階段 (CLR) 安全性模型已經過實質的某些變更。 這些的變更 (就像 Silverlight ’s 安全性模型)，一樣 Level2 透明度採用之一就是可能會影響作者 AllowPartiallyTrustedCallers APTCA 程式庫。

影響的原因是 APTCA 的基礎的運作方式已被變更在 CLR v4。 APTCA 屬性會保留能夠讓部分信任的呼叫端都可以使用完全受信任的程式庫，但所發生的事的詳細資料是不同，並 APTCA 程式庫程式碼的某些修改結果是有可能需要。

附註：本文中的第 2 版的參考參考其中包含所有項目從.NET Framework 版本 2.0 透過 3.5 SP1 的 CLR v2。

APTCA V4 之前

之前要 v4，帶正負號的所有組件已受從部分信任的呼叫端上所有的進入點的完全信任的隱含的連結要求。 這意味著任何部分信任程式碼嘗試存取強式名稱的組件就會失敗，安全性例外狀況。 這可防止惡意地從部分信任呼叫 (具有潛在危險性) 完全受信任的程式碼。

將 AllowPartiallyTrustedCallers 屬性加入至帶正負號的完全信任程式庫，供它為部分信任藉由移除這些隱含連結要求。 因此，APTCA 程式庫透過 APTCA 公開的方法允許部分信任的程式碼控制存取特殊權限的作業。 所以 APTCA 作者，以確保僅安全的作業已暴露於部分信任，以此方式及任何具有潛在危險性的作業已使用明確連結要求或完整的要求保護的責任。

在 [V4 APTCA

AllowPartiallyTrustedCallers 屬性已經變更。 在 v4，它不再具有與連結要求的任何項目。 在實際上已存在] 帶正負號的程式庫中 v2 的隱含連結需求是看不見了。 相反地，在 v4 所有完全受信任的組件是，預設 SecurityCritical。 在另一方面，所有部分受信任的組件位於自動 SecurityTransparent v4。 如透明度概觀下, 一節中所述，can’t 從 SecurityTransparent 的程式碼呼叫 SecurityCritical 程式碼。

因此，新 v4 透明度系統提供的完全信任程式碼為舊的連結要求相同保護 ； 由於的自動 
SecurityCritical 以和 SecurityTransparent 透明度層次部分受信任的程式碼 can’t 成完全受信任的程式庫呼叫預設。

您可能已經猜到，AllowPartiallyTrustedCallers v4 變更有關這。 在 v4，APTCA 的效果是從其套用組件中移除自動 SecurityCritical 行為。 組件然後 SecurityTransparent，以預設值，但允許 APTCA 組件作者，若要將更細微的 SecurityCritical 和 SecuritySafeCritical 屬性套用至特定的型別和方法，視。

在投影片中的損毀課程

透明度屬性像 SecurityTransparent SecurityCritical 會已知和 Silverlight 的安全性模型的讀者熟悉因為新 v4 透明度模型是相當類似效果。

let’s 看看三個主要的透明度屬性：SecurityTransparent、 SecuritySafeCritical 和 SecurityCritical。

SecurityTransparent 程式碼標記為 SecurityTransparent 平安無事從安全性觀點來看。 它 ’s 無法完成宣告權限、 執行未經驗證的程式碼或呼叫原生程式碼等的任何危險作業。 ’s 也無法直接呼叫 SecurityCritical 程式碼的位置。

  • 如所述，所有部分信任程式碼被強制為 SecurityTransparent 基於安全性考量。 它也 ’s APTCA 程式庫的預設透明度。

SecurityCritical SecurityCritical 程式碼與之相反就可以執行任何它希望的作業。 它可以宣告呼叫原生程式碼等等。 它可以呼叫其他方法，不論透明度標記。

  • 只有完全受信任的程式碼可以是 SecurityCritical。 然後在實際上 (非-APTCA) 完全受信任程式碼會假設為 SecurityCritical，依預設保護不透明，部分信任呼叫者。

SecuritySafeCritical SecuritySafeCritical 程式碼做為一個橋接允許到重要的方法呼叫的透明程式碼。 SecuritySafeCritical 程式碼有完全相同的權限為 SecurityCritical 程式碼，但是 ’s 可從 SecurityTransparent 程式碼呼叫。 因此，它的是)，極為重要 SecuritySafeCritical 程式碼公開的基礎 SecurityCritical 方法只能在安全的方式中 (lest 某些惡意、 部分受信任的程式碼會嘗試利用透過 SecuritySafeCritical 層方法)。

  • 像是 SecurityCritical 程式碼 SecuritySafeCritical 程式碼必須完全受信任。

圖 1 說明 SecurityTransparent、 SecuritySafeCritical 和 SecurityCritical 程式碼互動。

圖 1 的 SecurityTransparent、 SecuritySafeCritical 和 SecurityCritical 程式碼的互動

請注意除了圖所示轉換，所有透明度層次可以都存取本身和任何比較不重要的程式碼 (比方說 SecuritySafeCritical 程式碼可以都存取 SecurityTransparent 程式碼)。 因為 AllowPartiallyTrustedCallers 屬性會使整個組件，以依預設是 SecurityTransparent，組件 ’s 作者必須特別Mark為 SecurityCritical 或 SecuritySafeCritical 執行特殊權限的操作所需要的方法。 沒有這類標示 APTCA 作者會發現他的程式碼失敗 MethodAccessExceptions、 TypeAccessExceptions 與其他錯誤指出 APTCA 程式庫正在嘗試從 SecurityTransparent 程式碼呼叫危險的 API。

這是只是簡短介紹到模型，在 MSDN 文件和由 Andrew Dai，可以在 msdn.microsoft.com/magazine/ee677170.aspx 的 CLR 內深究前一篇文章中，您找到更徹底的檢查結果。

從 V2 遷移至 V4：要套用何種樣式

大部分的必要遷移 v2 APTCA 組件到 v4 工作牽涉到識別，並將正確的透明度屬性套用至需要它們的方法。 以下是指出每個屬性為適當的要領。

SecurityTransparent 並不會執行任何安全性機密作業的程式碼應該 SecurityTransparent。

不像其他透明度設定，SecurityTransparent 行為 APTCA 組件中的，預設值是且，因此，不需要明確地標記。 程式碼會被視為透明在沒有其他屬性。

透明的程式碼的優點之一是 (因為危險的作業不允許) ’s 安全且的結果不會需要為徹底安全性為 SecurityCritical 或特別，SecuritySafeCritical 程式碼的檢閱。 但建議的最多的程式碼可能被 SecurityTransparent。

以下是中不允許 SecurityTransparent 程式碼：

  • 呼叫 SecurityCritical 方法
  • 判斷提示使用權限或使用權限設定
  • 未經驗證的程式碼
  • 呼叫 Unmanaged 程式碼
  • 覆寫 SecurityCritical 虛擬方法
  • 實作 SecurityCritical 介面
  • 衍生自不是 SecurityTransparent 任何型別

SecuritySafeCritical 可從部分信任呼叫但需要呼叫具有潛在危險的 API 的程式碼應標示成 SecuritySafeCritical。 通常，要求權限的方法會落入這個分類，因為它們代表部分受信任的程式碼和特殊權限的操作之間的受保護的界限]。

因為 SecuritySafeCritical 程式碼允許部分信任的呼叫端來間接存取危險的 API，它 ’s 非常強大的屬性，並且應該在仔細，並盡量不要套用。 它 ’s 重要 SecuritySafeCritical 程式碼只能在特定的安全方式公開 SecurityCritical 功能，它的呼叫端。 它通常 ’s SecuritySafeCritical 包含要求來確保呼叫端可以存取 SecuritySafeCritical 程式碼將會使用的特定資源的程式碼是個不錯的作法。 ’s 也很重要的 SecuritySafeCritical 程式碼來驗證輸入和輸出，以便務必透過，不傳遞無效值，而任何傳回的資訊是安全讓部分信任) 的位置。

由於潛在的安全性風險它建議 SecuritySafeCritical 程式碼保持在最小值。

SecurityCritical 是不安全公開部分信任的呼叫端的程式碼應標示成 SecurityCritical。 先前已受連結要求的方法很可能會需要這個屬性。

SecurityCritical 程式碼是比 SecuritySafeCritical 較不危險，因為不 ’s 直接可從透明 (部分信任) 的呼叫端呼叫。 程式碼可以執行許多高安全性作業，不過，所以，以保持需要的安全性檢閱至最少，它 ’s 將保持 SecurityCritical 程式碼在最小，也是個不錯的作法。

良好的一般指導是應該可以是 SecurityTransparent 任何程式碼。 其他程式碼應該 SecurityCritical，除非它特別預期透明的程式碼會透過它案例 SecuritySafeCritical 是適當存取 SecurityCritical 程式碼。

使用 SecAnnotate.exe

若要協助正確的應用程式的透明度屬性有是一個新的.NET Framework SDK 工具，安全性 Annotator (SecAnnotate.exe)。 這個工具會消耗使用者 ’s 二進位檔 (或二進位碼檔案的集合)，並提供指導應該套用透明屬性。 移轉至 v4 的 APTCA 程式庫時，它可以是很有幫助。

藉由數個 SecAnnotate 運作通過目標二進位尋找，CLR ’s 規則需要的用透明度屬性來標記的方法。 在後續傳遞工具會尋找因為修改先前通過所建議的必要的屬性。 例如，請考慮這個簡短的程式碼片段 (這假設為來自 APTCA 組件)：

static void Method1()
{
      Console.WriteLine("In method 1!");
      Method2();
}

static void Method2()
{
      PermissionSet ft = new PermissionSet(PermissionState.Unrestricted);
      ft.Assert();
      DangerousAPI();
      PermissionSet.RevertAssert();
}

SecAnnotate.exe 會立即注意到 Method2 can’t 是透明因為它會判斷提示的某些權限。 在第一階段之後工具會知道 Method2 必須 SecurityCritical 或 SecuritySafeCritical (與 SecurityCritical 除非透明的程式碼需要特別存取這個方法所慣用)。

透過二進位檔在第一階段，Method1 會不覺得有趣工具。 在第二階段不過，它會注意 Method1 正在呼叫的第一階段 SecAnnotate 建議期間會變得 SecurityCritical Method2。 有鑑於此，Method1 也需要被 SecurityCritical (或，在作者 ’s 慎重 SecuritySafeCritical)。 兩個會傳遞後指引，以Mark為 SecurityCritical 會提供給這兩種方法中。

瞭解 SecAnnotate.exe 輸出

安全性 Annotator ’s 輸出是 XML 檔包含已識別的問題和建議的修正程式。 有時候，安全性 Annotator 反轉較早的建議之後後續的傳遞。 在這種情況下這兩個建議會顯示在 XML 中。 您需要查看在這些情況下行程數目若要了解哪一種建議的較新，並因此，更正。

例如，考慮 的 圖 2 中從安全性 Annotator 輸出。 請注意註解標記的方法 Logging.MethodA—a SecuritySafeCritical 標記和 SecurityCritical 標記] 下的兩個項目。 這表示 SecAnnotate 建議其分析期間使用這個方法的 SecurityCritical 和 SecuritySafeCritical 屬性。

圖 2 的 安全性 Annotator 的輸出

<requiredAnnotations>
    <assembly name="Logging">
      <type name="Logging">
        <method name="MethodA()">
          <annotations>
            <safeCritical>
              <rule name="MethodsMustOverrideWithConsistentTransparency">
                <reason pass="2" sourceFile="d:\repro\aptca\logging.cs" sourceLine="67">Critical method Logging.MethodA()’ is overriding transparent or safe critical method ‘Logging.MethodA()’ in violation of method override rules.  Logging.MethodA()’ must become transparent or safe-critical in order to override a transparent or safe-critical virtual method or implement a transparent or safe-critical interface method.</reason>
              </rule>
            </safeCritical>
            <critical>
              <rule name="TransparentMethodsMustNotSatisfyLinkDemands">
                <reason pass="1" sourceFile="d:\repro\aptca\logging.cs" sourceLine="68">Security transparent method Logging.MethodA()’ satisfies a LinkDemand for ‘FileIOPermissionAttribute’ on method ‘Logging.set_LogLocation(System.String)’.  Logging.MethodA()’ should become critical or safe-critical in order to call ‘Logging.set_LogLocation(System.String)’.</reason>
              </rule>
            </critical>
          </annotations>
        </method>
      </type>
    </assembly>
  </requiredAnnotations>

SecurityCritical 項目 ’s 解釋說這個方法會呼叫具有連結要求保護的東西，因為它必須是 SecurityCritical 或 SecuritySafeCritical。 安全建議 SecurityCritical 因為 ’s 更多的 SecAnnotate.exe 預設值。 請注意傳遞屬性表示此建議造成程式碼的第一個通過 SecAnnotate.exe ’s 從這裡，1 的值。

下一個建議 — 如 SecuritySafeCritical — 備忘稿 MethodA 透明的基底方法，因此會覆寫必須 SecurityTransparent 或 SecuritySafeCritical (它必須有相同的存取範圍，做為基底方法)。 再放入此資訊與先前建議一起，SecAnnotate.exe 建議 MethodA 應該 SecuritySafeCritical。

請注意該通過 = 「 2 」 代表這個建議附在程式碼的第二個通過 SecAnnotate.exe ’s 期間。 這是因為在第一階段期間工具 didn’t 知道 MethodA 不可以是透明，所以 wasn’t 知道此 SecuritySafeCritical 需求。

因為 SecuritySafeCritical 建議進行第二次的 (較新) 傳遞期間，不正確的註解在這種情況下。

SecAnnotate.exe 最佳作法

在種情況下] 其中 SecurityCritical 和 SecuritySafeCritical 兩者會正確標記安全性 Annotator 先慣用任何屬性已經在程式碼，然後再 SecurityCritical 上的因為 ’s 較有風險。 不幸的是，這通常會導致很安全，但是在沙箱中無法使用，因為所有的進入點封鎖以部分信任的呼叫端的程式碼。

請記住 SecuritySafeCritical 適當上是用來呼叫直接從透明/部分信任程式碼，並檢閱記住，與安全性的 API。 因為安全性 Annotator can’t 知道哪些 API 是用來從部分信任呼叫，或都是安全這種方法中呼叫，它會將Mark為 SecuritySafeCritical 非常少。 文件庫 ’s 作者必須 手動 將 SecuritySafeCritical 屬性套用至某些方法即使使用安全性 Annotator。

因為禁止透明的程式碼中的單一動作可以 「 連環新 Web 」 出許多 SecurityCritical 標記中安全性 Annotator ’s 連續傳遞至沒有 SecuritySafeCritical 屬性的策略位置，它 ’s 不錯的作法 SecAnnotate.exe 使用/p 命令列參數。 (其中 x 是一個數字) 的參數 /p:x 指示要執行的安全性 Annotator 只 x 代替執行，直到沒有更多的變更是必要的傳遞。 以下是到使用安全性 Annotator 好：

  1. 執行 SecAnnotate.exe /p:1 /d: < 參考的組件的路徑 > < FileName.dll >
    一個。 這將透明度屬性加入在需要時，但只能與單一行程。 在這個時候停止允許作者，以手動方式檢查屬性。
    b。 預設情況下，SecAnnotate.exe 看起來只在相依性組件上加附注的 GAC 中。 其他組件必須使用/d 切換控制指定其路徑。
  2. 使用建議的屬性來更新媒體櫃 ’s 原始程式檔。 考慮具有多個可能屬性的情況下，不過，並決定它正確。 在某些情況下 SecuritySafeCritical 會儘管 SecAnnotate favoring SecurityCritical 正確屬性。
  3. 重建組件，然後在步驟 1 而 /p:1 不重複。 您可以重新執行重複，使用 /p:1 程式但 shouldn’t 需要 — 必要 SecuritySafeCritical 屬性已存在的步驟 2 中第一個反覆項目之後。

此反覆的程序手動開發人員互動的情況會導致正確有註釋的組件，將最大化透明的程式碼。

識別並檢閱 SecuritySafeCritical API

如先前所述，’s 常見 SecAnnotate.exe 建議 API 應該 SecurityCritical 或 SecuritySafeCritical。 索引鍵的區分文字是是否 API 可以放心地從呼叫部分信任。 如果 API 會必須確定基礎嚴重或原生 API 會被呼叫安全地的所有驗證 (透過要求或輸入和輸出驗證，例如)，則它可以是 SecuritySafeCritical，這是有時令人滿意，因為它可以讓使它變為透明 API 的呼叫端。 如果在另一方面，沒有任何惡意程式碼可以存取受保護的資源，透過 API 的方式，API 必須維持 SecurityCritical。

它 ’s 重要 SecuritySafeCritical 的所有程式碼進行仔細檢閱安全性影響的曝光度為部分信任的。 雖然 SecuritySafeCritical 和 SecurityCritical 程式碼應該會縮小，如果有懷疑為到哪一個屬性是正確的 SecurityCritical 會是更安全的選項。

套用透明度屬性

套用透明度屬性是越簡單越套用程式碼中的其他任何.NET 屬性。 可以在這些類型的 MSDN 文件中找到有關所使用的屬性的文件：

  • SecurityTransparentAttribute
    請注意這個屬性可能只能在組件層級套用。 它表示，在這種情況下就是所有型別和組件中的方法透明。 它 ’s 在型別或方法層級不必要的因為 ’s APTCA 組件中的預設透明度設定。
  • SecuritySafeCriticalAttribute
  • SecurityCriticalAttribute

在 C# 中套用屬性外觀如下：

[SecurityCritical]
public static void Method1()
{ /* Do something potentially dangerous*/ }

[SecuritySafeCritical]
public static void Method2()
{ /* Do something potentially dangerous in a safe way that can be called from partial trust */ }

Level1 和 Level2

關於透明度和 APTCA 一個最終的附註是 ’s 可能透過使用舊的 v2 APTCA 行為，而不是新的 v4 行為的一個組件層級屬性的使用。 建議您不要因為新的模型是更安全、 更容易地稽核及常見 Silverlight 和桌面 CLRs 之間。 仍然，有時相容性被需要在短期直到您可以遷移。 在這些情況下 SecurityRules 屬性可用來強制使用的舊 v2 規則組件。

SecurityRules 屬性採用 SecurityRuleSet 列舉型別的參數。 SecurityRuleSet.Level1 指定相容性。 SecurityRuleSet.Level2 指定新的模型，但因為 ’s 預設值是不必要 Level2 屬性。 它是很有用的不過，以明確地指出哪些透明度規則集是使用中，並可防止對未來所做的任何變更有關哪些規則集是.NET Framework ’s 預設。

在 C# 應用程式的這個屬性會出現像這樣：

[assembly:SecurityRules(SecurityRuleSet.Level1)]

常見的陷阱

以下是幾個常見 「 因素 」 應該注意的當它們從 v2 遷移到 v4 APTCA 程式庫作者：

  • SecAnnotate.exe 會建議 LinkDemands 成為 SecurityCritical 屬性 (也就是與完全信任的 LinkDemands 非常相似)。 如果不過，型別 (而不是方法) 已加上一個 LinkDemand 保護，這不是與套用 SecurityCritical v4 中為型別相同。 因為這將會更作用類似 v2 型別層級 LinkDemand，它 ’s 套用到該型別的所有成員的 SecurityCritical 會更好。
  • 請注意，某些部分信任程式碼是某些低權限 LinkDemands 應該是無法滿足可能不是最能轉譯成 SecurityCritical。 如果一個 LinkDemand 低權限 (比方說到特定的安全路徑的讀取權限)，’s 更好，移除 [LinkDemand 並以相同的權限的完全要求取代。 這可讓部分信任程式碼仍然呼叫 API (但要求會確定，只有部分信任的程式碼具有高使用權限不足，無法成功中進行呼叫)。
  • 在一般型別層級透明度屬性套用至以及它們的修改)，型別的成員。 而且最外層屬性 trumps 其他人。 所以，[SecurityCritical] 套用至方法是 ineffectual 如果 ’s 型別具有 [SecuritySafeCritical] 套用至它，例如。 通常，[SecuritySafeCritical] 不是很有用的屬性型別層級上。 它 ’s 太可能會有人將稍後介紹新的成員型別，並不瞭解 [它 ’s SecuritySafeCritical (感謝至型別層級屬性中)，可能導致安全性漏洞。

雖然型別層級屬性套用至新的介面槽成員，他們修改的型別的，它們並不適用於覆寫成員。 務必如果您使用 [屬性型別層級透明度您也將屬性加入覆寫成員特別，視。

移轉範例

圖 3 是 v2 以撰寫一個簡單且不完整的記錄程式庫。

圖 3 的 V2 APTCA 程式庫

using System;
using System.IO;
using System.Security;
using System.Security.Permissions;

// This assembly is meant to be representative of a simple v2 APTCA assembly
// It has some dangerous code protected with demands/link demands
// It exposes some dangerous code in a controlled way with an assert

[assembly: AllowPartiallyTrustedCallers]
public class Logging
{
    private string logLocation = @"C:\temp\firstfoo.txt";

    public virtual string Usage()
    {
        return "This is a helpful string";
    }

    public virtual string LogLocation
    {
        get
        {
            return logLocation;
        }

        [FileIOPermissionAttribute(SecurityAction.LinkDemand, Unrestricted=true)]
        set
        {
            logLocation = value;
        }
    }

    public virtual void SetLogLocation(int index)
    {
        switch (index)
        {
            case 1: 
                LogLocation = @"C:\temp\foo.txt";
                break;
            case 2:
                LogLocation = @"D:\temp\foo.txt";
                break;
            case 3:
                LogLocation = @"D:\repro\temp\foo.txt";
                break;
            default:
                break;
        }
    }


    public virtual void DeleteLog()
    {
        FileIOPermission fp = new FileIOPermission(FileIOPermissionAccess.AllAccess, LogLocation);
        fp.Assert();
        if (File.Exists(LogLocation)) { File.Delete(LogLocation); }
        SecurityPermission.RevertAll();
    }

    // TODO : Put other APIs (creating log, writing to log, etc) here
}

public class OtherLogging : Logging
{
    public override string Usage()
    {
        LogLocation = null;
        return "This is a different useful string";
    }

    // TODO : Put other APIs (creating log, writing to log, etc) here
}

同一個程式庫也會顯示在 圖 4 ，移轉到 v4 與註解 (以斜體顯示) 解釋所做的變更。

圖 4 的 V4 APTCA 程式庫

using System;
using System.IO;
using System.Security;
using System.Security.Permissions;

// This assembly is meant to be representative of a simple v2 APTCA assembly
// It has some dangerous code protected with demands/link demands
// It exposes some dangerous code in a controlled way with an assert

[assembly: AllowPartiallyTrustedCallers]
public class Logging
{
    private string logLocation = @"C:\temp\firstfoo.txt";
    
    // This API can be transparent because it does nothing dangerous.
    // Transparent APIs need no attributes because it is the default behavior of a v4
    // APTCA assembly
    public virtual string Usage()
    {
        return "This is a helpful string";
    }

    // Note that transparency attributes do not go directly on properties.
    // Instead, they go on the getters and setters (even if the getter and setter
    // get the same attributes)
    public virtual string LogLocation
    {
        get
        {
            return logLocation;
        }

        // This API is made critical because it sets sensitive data (the path to write to)
        // which partial trust code should not be able to do.
        [SecurityCritical]
        // The previous LinkDemand is removed as the SecurityCritical attribute replaces it
    //[FileIOPermissionAttribute(SecurityAction.LinkDemand, Unrestricted=true)]
        set
        {
            logLocation = value;
        }
    }

    // This API accesses a critical member (LogLocation) and, therefore, cannot be transparent
    // However, the access is done in a limited, safe way and we expect transparent code
    // should be able to call this API. Therefore, it is SecuritySafeCritical
    [SecuritySafeCritical]
    public virtual void SetLogLocation(int index)
    {
        switch (index)
        {
            case 1: 
                LogLocation = @"C:\temp\foo.txt";
                break;
            case 2:
                LogLocation = @"D:\temp\foo.txt";
                break;
            case 3:
                LogLocation = @"D:\repro\temp\foo.txt";
                break;
            default:
                break;
        }
    }

    // This API is potentially dangerous; it asserts which means it can’t be transparent
    // Because setting LogLocation is protected, however, partial trust code can safely
    // call this API. In fact, it is intended that it is safe for partial trust code
    // to call this method. Therefore, it is SecuritySafeCritical
    [SecuritySafeCritical]
    public virtual void DeleteLog()
    {
        FileIOPermission fp = new FileIOPermission(FileIOPermissionAccess.AllAccess, LogLocation);
        fp.Assert();
        if (File.Exists(LogLocation)) { File.Delete(LogLocation); }
        SecurityPermission.RevertAll();
    }

    // TODO : Put other APIs (creating log, writing to log, etc) here
}

public class OtherLogging : Logging
{
    // The logic for attributing this method is complicated and it is an example of when
    // SecAnnotate.exe can be very helpful. This API cannot be transparent because it 
    // calls a critical member (LogLocation). However, because it overrides a transparent
    // method (Usage) it cannot be critical. Therefore, the only possible annotation here
    // is SecuritySafeCritical and it is the author’s responsibility to make sure that
    // a malicious caller cannot abuse that access.
    [SecuritySafeCritical]
    public override string Usage()
    {
        LogLocation = null;
        return "This is a different useful string";
    }

    // TODO : Put other APIs (creating log, writing to log, etc) here
}

CLR 和 Silverlight CoreCLR 安全性系統在同步

雖然合併 APTCA，並在 v4 透明度好像很複雜，它最後提供簡單且有效保護機密的系統資源從部分信任的呼叫端。 該怎麼辦 ’s 更變更對齊桌面的 CLR 和 Silverlight CoreCLR 安全性系統。

例如 SecAnnotate.exe 和 FxCop 規則 (可驗證透明度) 的 SDK 工具協助簡化移轉。 V4 APTCA 組件會更容易地稽核 — 請仔細查看 SecuritySafeCritical API (及他們所做的 SecurityCritical 呼叫) 就是所有所需具有組件是安全的信心。

透明的程式碼通常是由到 90%的 80%或更多組件所構成，因為這是很棒的洩壓的稽核負擔。 讀者 delving 有興趣進一步成透明度可以更完整解釋並遵循連結內容閱讀相關說明中找到 MSDN 文件。

 

Mike Rousos   Microsoft ’s CLR 團隊的測試中的軟體設計工程師後已經 2005年。 他的工作主要是負責確保設計和實作的 CLR 安全性系統的品質。

多虧來檢閱本文的下列的技術專家：   Andrew Dai 郭 Eigel 和 Shawn Farkas