透過的セキュリティ コード、レベル 2
レベル 2 の透過性は、.NET Framework Version 4 で導入されました。 このモデルには、透過的なコード、セキュリティ セーフ クリティカル コード、およびセキュリティ クリティカル コードの 3 つの基本思想があります。
完全に信頼されているコードを含む透過的なコードは、他の透過的なコードまたはセキュリティ セーフ クリティカル コードのみを呼び出すことができます。 ドメインの部分信頼アクセス許可セット (存在する場合) で許可されるアクションのみを実行できます。 透過的なコードでは、次のアクションは実行できません。
特権の Assert または昇格を実行する。
アンセーフ コードまたは検証不可能なコードを含める。
クリティカル コードを直接呼び出す。
ネイティブ コードまたは SuppressUnmanagedCodeSecurityAttribute 属性を持つコードを呼び出す。
LinkDemand によって保護されているメンバーを呼び出す。
クリティカルな型を継承する。
また、透過的メソッドでは、クリティカルな仮想メソッドをオーバーライドしたりクリティカルなインターフェイス メソッドを実装したりすることはできません。
セーフ クリティカル コードは完全に信頼されていますが、透過的なコードから呼び出すことができます。 完全に信頼されているコードの限られた領域しか外部に公開されないようにします。正確性とセキュリティの検証はセーフ クリティカル コードで実行されます。
セキュリティ クリティカル コードは任意のコードを呼び出すことができ、完全に信頼されていますが、透過的なコードから呼び出すことはできません。
このトピックは、次のセクションで構成されています。
使用例と動作
オーバーライドのパターン
継承規則
追加情報と規則
使用例と動作
.NET Framework 4 の規則 (レベル 2 の透過性) を指定するには、アセンブリに対して次の注釈を使用します。
[assembly: SecurityRules(SecurityRuleSet.Level2)]
.NET Framework 2.0 の規則 (レベル 1 の透過性) を指定するには、次の注釈を使用します。
[assembly: SecurityRules(SecurityRuleSet.Level1)]
アセンブリに注釈を付けない場合は、.NET Framework 4 の規則が既定で使用されます。 ただし、既定値に頼らずに SecurityRulesAttribute 属性を使用することをお勧めします。
アセンブリ全体の注釈
次の規則は、アセンブリ レベルで、属性の使用に適用されます。
属性なし: 属性を指定しない場合は、ランタイムによってすべてのコードがセキュリティ クリティカルとして解釈されます。ただし、セキュリティ クリティカルであると継承規則に違反する場合 (たとえば、透過的な仮想メソッドまたはインターフェイス メソッドをオーバーライドまたは実装する場合) は除きます。 このような場合、メソッドはセーフ クリティカルになります。 属性を指定しない場合は、共通言語ランタイムによって透過性規則が自動的に判断されます。
SecurityTransparent: すべてのコードが透過的になります。アセンブリ全体で特権操作または安全でない操作は実行されません。
SecurityCritical: このアセンブリの型によって導入されるすべてのコードがクリティカルになります。他のすべてのコードが透過的になります。 このシナリオは属性を指定しない場合に似ていますが、共通言語ランタイムによって透過性規則が自動的に判断されることはありません。 たとえば、仮想メソッドまたは抽象メソッドをオーバーライドしたりインターフェイス メソッドを実装したりする場合、既定では、そのメソッドは透過的になります。 メソッドに SecurityCritical または SecuritySafeCritical の注釈を明示的に付ける必要があります。そうしないと、読み込み時に TypeLoadException がスローされます。 この規則は、基本クラスと派生クラスの両方が同じアセンブリに存在する場合にも適用されます。
AllowPartiallyTrustedCallers (レベル 2 のみ): すべてのコードが既定で透過的になります。 ただし、個別の型およびメンバーは他の属性を持つことができます。
レベル 2 とレベル 1 のアセンブリ レベルの動作の比較を次の表に示します。
アセンブリ属性 |
レベル 2 |
レベル 1 |
|---|---|---|
部分的に信頼されたアセンブリに属性なし |
型およびメンバーは既定で透過的になりますが、セキュリティ クリティカルまたはセキュリティ セーフ クリティカルになる場合もあります。 |
すべての型およびメンバーは透過的です。 |
属性なし |
属性を指定しない場合は、共通言語ランタイムによって透過性規則が自動的に判断されます。 セキュリティ クリティカルであると継承規則に違反する場合を除き、すべての型およびメンバーがセキュリティ クリティカルになります。 |
完全に信頼されたアセンブリ (グローバル アセンブリ キャッシュに存在または AppDomain で完全な信頼として指定) では、すべての型は透過的であり、すべてのメンバーはセキュリティ セーフ クリティカルです。 |
SecurityTransparent |
すべての型およびメンバーは透過的です。 |
すべての型およびメンバーは透過的です。 |
SecurityCritical(SecurityCriticalScope.Everything) |
適用なし。 |
すべての型およびメンバーはセキュリティ クリティカルです。 |
SecurityCritical |
このアセンブリの型によって導入されるすべてのコードがクリティカルになります。他のすべてのコードが透過的になります。 仮想メソッドまたは抽象メソッドをオーバーライドしたりインターフェイス メソッドを実装したりする場合、メソッドに SecurityCritical または SecuritySafeCritical の注釈を明示的に付ける必要があります。 |
すべてのコードは既定で透過的になります。 ただし、個別の型およびメンバーは他の属性を持つことができます。 |
型およびメンバーの注釈
型に適用されるセキュリティ属性は、型によって導入されるメンバーにも適用されます。 ただし、基本クラスまたはインターフェイス実装の仮想オーバーライドや抽象オーバーライドには適用されません。 次の規則は、型およびメンバー レベルで、属性の使用に適用されます。
SecurityCritical: 型またはメンバーはクリティカルで、完全に信頼されているコードからのみ呼び出すことができます。 セキュリティ クリティカルな型で導入されるメソッドはクリティカルです。
.gif "重要 :")
重要基本クラスまたはインターフェイスで導入されてセキュリティ クリティカルなクラスでオーバーライドまたは実装される仮想メソッドおよび抽象メソッドは、既定では透過的です。これらのメソッドは、SecuritySafeCritical または SecurityCritical として指定する必要があります。
SecuritySafeCritical: 型またはメンバーはセーフ クリティカルです。 ただし、型またはメンバーは透過的な (部分的に信頼された) コードから呼び出すことができ、機能的に他のクリティカル コードと同等になります。 コードはセキュリティ監査を受ける必要があります。
ページのトップへ
オーバーライドのパターン
レベル 2 の透過性で使用できるメソッドのオーバーライドを次の表に示します。
基本クラスの仮想/インターフェイス メンバー |
オーバーライド/インターフェイス |
|---|---|
Transparent |
Transparent |
Transparent |
SafeCritical |
SafeCritical |
Transparent |
SafeCritical |
SafeCritical |
Critical |
Critical |
ページのトップへ
継承規則
このセクションでは、アクセスおよび機能に基づいて、次の順序が Transparent、Critical、および SafeCritical の各コードに割り当てられています。
Transparent < SafeCritical < Critical
型の規則: 左から右に向かってアクセス制限がより厳しくなります。 派生型は、基本型と少なくとも同じレベルで制限する必要があります。
メソッドの規則: 派生メソッドと基本メソッドのアクセシビリティは同じである必要があります。 既定の動作では、注釈のない派生メソッドはすべて Transparent になります。 クリティカルな型の派生型では、オーバーライドしたメソッドに SecurityCritical の注釈が明示的に付けられていない場合は例外がスローされます。
使用できる型の継承パターンを次の表に示します。
[基本クラス] |
派生クラスでは以下が可能 |
|---|---|
Transparent |
Transparent |
Transparent |
SafeCritical |
Transparent |
Critical |
SafeCritical |
SafeCritical |
SafeCritical |
Critical |
Critical |
Critical |
使用できない型の継承パターンを次の表に示します。
[基本クラス] |
派生クラスでは以下が不可 |
|---|---|
SafeCritical |
Transparent |
Critical |
Transparent |
Critical |
SafeCritical |
使用できるメソッドの継承パターンを次の表に示します。
基本メソッド |
派生メソッドでは以下が可能 |
|---|---|
Transparent |
Transparent |
Transparent |
SafeCritical |
SafeCritical |
Transparent |
SafeCritical |
SafeCritical |
Critical |
Critical |
使用できないメソッドの継承パターンを次の表に示します。
基本メソッド |
派生メソッドでは以下が不可 |
|---|---|
Transparent |
Critical |
SafeCritical |
Critical |
Critical |
Transparent |
Critical |
SafeCritical |
.gif "メモ") メモ |
|---|
これらの継承規則は、レベル 2 の型およびメンバーに適用されます。レベル 1 アセンブリ内の型は、レベル 2 のセキュリティ クリティカルな型およびメンバーを継承できます。したがって、レベル 2 の型およびメンバーでは、レベル 1 の継承先に対して個別の継承確認要求が必要です。 |
ページのトップへ
追加情報と規則
LinkDemand のサポート
レベル 2 の透過性モデルでは、LinkDemand は SecurityCriticalAttribute 属性に置き換えられます。 レガシ (レベル 1) コードでは、LinkDemand は自動的に Demand として扱われます。
リフレクション
クリティカル メソッドを呼び出したりクリティカル フィールドを読み取ったりすると、完全信頼の確認要求がトリガーされます (プライベート メソッドまたはプライベート フィールドを呼び出す場合と同様)。 したがって、完全に信頼されているコードではクリティカル メソッドを呼び出すことができるのに対し、部分信頼コードでは呼び出すことができません。
型、メソッド、またはフィールドが SecurityCritical、SecuritySafeCritical、または SecurityTransparent のいずれであるかを判断するために、IsSecurityCritical、IsSecuritySafeCritical、および IsSecurityTransparent の各プロパティが System.Reflection 名前空間に追加されました。 これらのプロパティによって、属性が存在するかどうかを確認するのではなくリフレクションを使用して透過性を判断します。 透過性規則は複雑で、属性の確認では十分でない場合があります。
| メモ |
|---|
SafeCritical メソッドは、IsSecurityCriticalと IsSecuritySafeCritical の両方に対して true を返します。SafeCritical が実際にクリティカルであるためです (クリティカル コードと同じ機能を持ちますが、透過的なコードから呼び出すことができます)。 |
動的メソッドは、関連付けられているモジュールの透過性を継承します。型の透過性は継承しません (型に関連付けられている場合)。
完全信頼における検証のスキップ
完全に信頼されている透過的なアセンブリの検証をスキップするには、SecurityRulesAttribute 属性の SkipVerificationInFullTrust プロパティを true に設定します。
[assembly: SecurityRules(SecurityRulesSet.Level2, SkipVerificationInFullTrust = true)]
SkipVerificationInFullTrust プロパティは既定では false なので、検証をスキップするにはこのプロパティを true に設定する必要があります。 これは、最適化のためだけに行ってください。 transparent オプションを PEVerify ツールで使用して、アセンブリ内の透過的なコードが検証可能であることを確認する必要があります。
ページのトップへ