透過的セキュリティ コード、レベル 1
透過性を使用すると、部分的に信頼されるコードに機能を公開する .NET Framework ライブラリのセキュリティを強化できます。 レベル 1 の透過性は、.NET Framework Version 2.0 で導入され、主に Microsoft 内でのみ使用されていました。 .NET Framework Version 4 以降では、レベル 2 の透過性を使用できます。 ただし、以前のセキュリティ規則で実行する必要があるレガシ コードを指定できるように、レベル 1 の透過性も残されています。
.gif "重要 :") 重要 |
|---|
レベル 1 の透過性は、互換性を確保するためにのみ指定してください。つまり、AllowPartiallyTrustedCallersAttribute を使用するか透過性モデルを使用しない .NET Framework 3.5 以前で開発されたコードに対してのみレベル 1 を指定してください。たとえば、部分的に信頼された呼び出し元からの呼び出しを許可する .NET Framework 2.0 アセンブリ (APTCA) にはレベル 1 の透過性を使用します。.NET Framework 4 用に開発されたコードには、常にレベル 2 の透過性を使用します。 |
このトピックは、次のセクションで構成されています。
レベル 1 の透過性モデル
透過性属性
透過的セキュリティの例
レベル 1 の透過性モデル
レベル 1 の透過性を使用するときは、透過的セキュリティ、セキュリティ セーフ クリティカル、およびセキュリティ クリティカルの各メソッドにコードを分離するセキュリティ モデルを使用します。
アセンブリ全体、アセンブリ内の一部のクラス、またはクラスの一部のメソッドを、透過的セキュリティとしてマークできます。 透過的セキュリティ コードは、特権を引き上げることができません。 この制限により、次の 3 つの効果があります。
透過的セキュリティ コードは、Assert アクションを実行できません。
透過的セキュリティ コードによって満たされるリンク確認要求は、すべてフル アクセス要求になります。
透過的セキュリティ コードで実行する必要のあるすべてのアンセーフ (検証不能な) コードは、UnmanagedCode セキュリティ アクセス許可に対するフル アクセス要求の原因になります。
これらの規則は、共通言語ランタイム (CLR: Common Language Runtime) による実行中に適用されます。 透過的セキュリティ コードは、呼び出すコードのすべてのセキュリティ要件を、呼び出し元に戻します。 透過的セキュリティ コードを通過する確認要求は、特権を引き上げることができません。 低信頼性アプリケーションによって透過的セキュリティ コードが呼び出され、高い特権の確認要求が発生した場合、その確認要求は低信頼性コードに戻されて失敗します。 透過的セキュリティ コードはアサート アクションを実行できないので、確認要求を停止できません。 同じ透過的セキュリティ コードが完全に信頼されているコードから呼び出された場合は、確認要求は成功します。
セキュリティ クリティカルは、透過的セキュリティの反対です。 セキュリティ クリティカル コードは完全な信頼で実行され、すべての特権操作を実行できます。 セキュリティ セーフ クリティカル コードは、広範なセキュリティ監査を経た特権コードであり、部分的に信頼された呼び出し元がアクセスを許可されていないリソースを使用するのを許可しないことが確認されています。
透過性の適用は明示的に行う必要があります。 通常、データ操作とロジックを処理するコードの大部分は透過的セキュリティとしてマークでき、特権の昇格を実行する少数のコードはセキュリティ クリティカルまたはセキュリティ セーフ クリティカルとしてマークします。
| 重要 |
|---|
レベル 1 の透過性は、アセンブリ スコープに限定されます。アセンブリ間には適用されません。レベル 1 の透過性は、主に Microsoft 内でセキュリティ監査を目的として使用されていました。レベル 1 アセンブリ内のセキュリティ クリティカルな型およびメンバーには、他のアセンブリの透過的セキュリティ コードからアクセスできます。重要なのは、すべてのレベル 1 のセキュリティ クリティカルな型およびメンバーで、完全な信頼のためにリンク確認要求を実行することです。セキュリティ セーフ クリティカルな型およびメンバーでも、それらの型またはメンバーがアクセスする保護されたリソースに対するアクセス許可を呼び出し元が有していることを確認する必要があります。 |
以前のバージョンの .NET Framework との下位互換性を維持するため、透過性属性が指定されていないメンバーはすべてセキュリティ セーフ クリティカルと見なされます。 指定のない型はすべて透過的と見なされます。 透過性を検証するためのスタティック分析規則はありません。 したがって、透過性エラーを実行時にデバッグすることが必要になる場合があります。
透過性属性
コードの透過性を指定するための 3 つの属性の説明を、次の表に示します。
属性 |
説明 |
|---|---|
アセンブリ レベルでのみ使用できます。 アセンブリ内のすべての型およびメンバーが透過的セキュリティになります。 アセンブリは、セキュリティ クリティカルなコードを含むことができません。 |
|
Scope プロパティを使用せずにアセンブリ レベルで使用すると、アセンブリ内のすべてのコードは既定で透過的セキュリティになりますが、アセンブリはセキュリティ クリティカル コードを含むこともできます。 クラス レベルで使用すると、クラスまたはメソッドはセキュリティ クリティカルになりますが、クラスのメンバーはセキュリティ クリティカルになりません。 すべてのメンバーをセキュリティ クリティカルにするには、Scope プロパティを Everything に設定します。 メンバー レベルで使用した場合、この属性はそのメンバーのみに適用されます。 セキュリティ クリティカルであるクラスまたはメンバーは、特権の昇格を実行できます。 重要
レベル 1 の透過性では、セキュリティ クリティカルな型およびメンバーは、アセンブリの外部から呼び出された場合に、セキュリティ セーフ クリティカルとして扱われます。認証されていない特権の昇格を防ぐために、セキュリティ クリティカルな型およびメンバーを完全な信頼のためのリンク確認要求で保護する必要があります。
|
|
アセンブリ内の透過的セキュリティ コードがアクセスできるセキュリティ クリティカル コードを指定します。 この属性を適用しないと、透過的セキュリティ コードは、同じアセンブリ内のプライベートまたは内部のセキュリティ クリティカルなメンバーにアクセスできません。 アクセスすると、セキュリティ クリティカルなコードに影響を与えて、予期しない特権の引き上げが可能になります。 セキュリティ セーフ クリティカル コードについては、厳しいセキュリティ監査を行う必要があります。 .gif "メモ") メモ
セキュリティ セーフ クリティカルな型およびメンバーでは、呼び出し元のアクセス許可を確認して、呼び出し元が保護されたリソースにアクセスする権限を有するかどうかを判断する必要があります。
|
SecuritySafeCriticalAttribute 属性を使用すると、透過的セキュリティ コードは、同じアセンブリ内のセキュリティ クリティカルなメンバーにアクセスできます。 1 つのアセンブリに含まれる、透過的セキュリティ コードとセキュリティ クリティカルなコードは、2 つのアセンブリに分離されていると考えることができます。 透過的セキュリティ コードは、セキュリティ クリティカルなコードのプライベートまたは内部のメンバーを参照できません。 さらに、セキュリティ クリティカルなコードは、通常、パブリック インターフェイスへのアクセスについて監査を受けます。 プライベートまたは内部の状態にはアセンブリの外部からアクセスできないようにし、状態を分離しておくのが一般的です。 SecuritySafeCriticalAttribute 属性は、透過的セキュリティ コードとセキュリティ クリティカルなコードの間で状態の分離を維持しながら、必要なときには分離を無視できるようにします。 セキュリティ クリティカル コードのプライベートまたは内部のメンバーが SecuritySafeCriticalAttribute でマークされていない場合、透過的セキュリティ コードはこれらのメンバーにアクセスできません。 SecuritySafeCriticalAttribute を適用する前に、パブリックに公開される場合と同じようにメンバーを監査してください。
アセンブリ全体の注釈
セキュリティ属性をアセンブリ レベルで使用する効果の説明を次の表に示します。
アセンブリ属性 |
アセンブリ状態 |
|---|---|
部分的に信頼されたアセンブリに属性なし |
すべての型およびメンバーは透過的です。 |
完全に信頼されたアセンブリ (グローバル アセンブリ キャッシュに存在または AppDomain で完全な信頼として指定) に属性なし |
すべての型は透過的であり、すべてのメンバーはセキュリティ セーフ クリティカルです。 |
SecurityTransparent |
すべての型およびメンバーは透過的です。 |
SecurityCritical(SecurityCriticalScope.Everything) |
すべての型およびメンバーはセキュリティ クリティカルです。 |
SecurityCritical |
すべてのコードは既定で透過的になります。 ただし、個別の型およびメンバーは他の属性を持つことができます。 |
透過的セキュリティの例
.NET Framework 2.0 の透過性規則 (レベル 1 の透過性) を使用するには、次のアセンブリの注釈を使用します。
[assembly: SecurityRules(SecurityRuleSet.Level1)]
アセンブリ全体を透過的にして、アセンブリがクリティカルなコードを含まず、どのような方法でも特権を引き上げないことを示す必要がある場合は、次の属性を使用して、アセンブリに透過性を明示的に追加できます。
[assembly: SecurityTransparent]
同じアセンブリの中にクリティカルなコードと透過的なコードを混在させる場合は、次に示すように、最初に SecurityCriticalAttribute 属性をアセンブリにマークして、アセンブリがクリティカルなコードを含むことができることを示します。
[assembly: SecurityCritical]
セキュリティ クリティカルな操作を実行する場合は、次のコード例で示すように、別の SecurityCriticalAttribute 属性を使用して、クリティカルな操作を実行するコードを明示的にマークする必要があります。
[assembly: SecurityCritical]
Public class A
{
[SecurityCritical]
private void Critical()
{
// critical
}
public int SomeProperty
{
get {/* transparent */ }
set {/* transparent */ }
}
}
public class B
{
internal string SomeOtherProperty
{
get { /* transparent */ }
set { /* transparent */ }
}
}
このコードは、セキュリティ クリティカルであることが明示的にマークされている Critical メソッドを除くと透過的です。 アセンブリ レベルで SecurityCriticalAttribute 属性が指定されていても、既定の設定は透過的です。