.NET Framework 4 におけるセキュリティの変更点
.NET Framework Version 4 では、セキュリティに 2 点の大幅な変更が加えられています。 コンピューター全体のセキュリティ ポリシーは削除されましたが、アクセス許可システムは引き続き有効で、透過的セキュリティが既定の適用機構になっています。 (詳細については、「透過的セキュリティ コード、レベル 2」を参照してください)。 さらに、セキュリティ上の脆弱性が発生する可能性があったいくつかのアクセス許可操作が廃止されました。
.gif "重要 :") 重要 |
|---|
コード アクセス セキュリティ (CAS) は削除されていないので、セキュリティ ポリシーは CAS から削除されましたが、証拠およびアクセス許可は引き続き有効です。いくつかのアクセス許可は削除され、透過性によってセキュリティの適用が簡略化されました。変更点の概要については、「コード アクセス セキュリティにおける変更内容の概要」を参照してください。 |
以下の主要なポイントに注意する必要があります。
透過性によって、アプリケーションの一部として実行されるコードがインフラストラクチャの一部として実行されるコードから分離されます。 これは .NET Framework Version 2.0 で導入された機能で、強化されてコード アクセス セキュリティ適用機構になりました。 セキュリティ ポリシーとは異なり、レベル 2 の透過性規則は、アセンブリの読み込み時ではなく実行時に適用されます。 この規則は、既定で完全に信頼されて実行されるアセンブリの場合でも必ず有効になります。 ただし、レベル 2 の透過性は、デスクトップ アプリケーションなどの指定のない完全に信頼されたコードには影響しません。 SecurityTransparentAttribute でマークされたアセンブリおよび SecurityCriticalAttribute でマークされたメソッドを呼び出すアセンブリ (デスクトップ アセンブリを含む) は、MethodAccessException を受け取ります。 この動作を変更するには、SecurityRulesAttribute を適用して SecurityRulesAttribute.RuleSet プロパティを Level1 に設定します。ただし、これは下位互換性のためだけに実行してください。デスクトップ アプリケーションを透過的セキュリティとして明示的にマークし、透過性の制約を適用する必要があります。
セキュリティ ポリシー API を呼び出すコードは、実行時にコンパイラの警告に加えて NotSupportedException を受け取ります。 ポリシーを再び有効にするには、<NetFx40_LegacySecurityPolicy> 構成要素を使用します。 ポリシーが有効になっても、透過的セキュリティは引き続き有効です。 セキュリティ ポリシーはアセンブリの読み込み時に適用されるので、実行時に適用される透明性には影響しません。
アクセス許可要求 (RequestMinimum、RequestOptional、および RequestRefuse) は、.NET Framework 4 は廃止されたので、コンパイラの警告を受け取って機能しませんが、例外はスローされません。 Deny 要求では、実行時に NotSupportedException がスローされます。
LinkDemand セキュリティ アクションは使用できないわけではありませんが、アクセス許可の検証には使用しないでください。 代わりに、完全信頼を要求する型およびメソッドには SecurityCriticalAttribute、アクセス許可を個別に要求する型およびメソッドには Demand メソッドを使用してください。
アプリケーションが Visual Studio 2010 を使用してビルドされている場合は、Visual Studio プロジェクトの設定で対象となる .NET Framework のバージョンを .NET Framework 4 より前のバージョンに指定すると、これらの変更なしでアプリケーションを実行できます。 ただし、.NET Framework 4 の新しい型およびメンバーは使用できません。 アプリケーションの構成ファイルでスタートアップ設定スキーマの <supportedRuntime> 要素を使用すると、旧バージョンの .NET Framework を指定することもできます。
以降では、.NET Framework 4 におけるこれらの変更点およびその他の変更点について説明します。
セキュリティ ポリシーの簡略化
透過的セキュリティ レベル 2
アクセス許可要求の廃止
条件 APTCA
証拠オブジェクト
証拠コレクション
セキュリティ ポリシーの簡略化
.NET Framework 4 以降では、共通言語ランタイム (CLR: Common Language Runtime) がコンピューターにセキュリティ ポリシーを提供しなくなります。 従来、.NET Framework では、マネージ コードの機能を厳密に制御および構成するための機構としてコード アクセス セキュリティ (CAS: Code Access Security) ポリシーが用意されていました。 CAS ポリシーは強力ですが、複雑で限定的になる場合があります。 さらに、CAS ポリシーはネイティブ アプリケーションには適用されないので、セキュリティの保証は制限されます。 システム管理者は、CAS ポリシーの代替として、Windows のソフトウェアの制限のポリシー (SRP: Software Restriction Policy) や Windows 7 および Windows Server 2008 R2 の AppLocker などのオペレーティング システム レベルのソリューションに頼る必要があります。 SRP および AppLocker のポリシーは、マネージ コードとネイティブ コードの両方に適用される簡単な信頼機構を実現します。 セキュリティ ポリシー ソリューションとしては、SRP および AppLocker の方が CAS よりも簡単に使用でき、セキュリティの保証を向上できます。
.NET Framework 4 では、コンピューター全体のセキュリティ ポリシーが既定でオフになっています。 ホストされないアプリケーション (Windows エクスプローラーまたはコマンド プロンプトから実行されるアプリケーション) は、完全に信頼されているアプリケーションとして実行されます。 これには、ローカル ネットワークの共有に存在するすべてのアプリケーションが含まれます。 ホストされるアプリケーションまたはサンドボックス化されたアプリケーションは、引き続きホスト (Internet Explorer、ClickOnce、ASP.NET など) によって決定される信頼ポリシーを使用して実行されます。 サンドボックス内で実行されるアプリケーションまたはコントロールは、部分的に信頼されていると見なされます。
セキュリティ ポリシーを簡略化するために、.NET Framework に透過性モデルが適用されました。 サンドボックスによって制限付きのアクセス許可セットが付与されているホストまたはサンドボックス内で実行されるアプリケーションおよびコントロールは、透過的と見なされます。 透過的とは、部分的に信頼されたアプリケーションの実行時に CAS ポリシーのチェックについて考慮する必要がないことを意味します。 透過的なアプリケーションは、単に許可セットを使用して実行されます。 プログラマは、アプリケーションがサンドボックスの許可セットを対象としていること、および完全信頼を必要とするコード (セキュリティ クリティカル コード) を呼び出さないことを考慮するだけで済みます。
| 重要 |
|---|
このようなセキュリティ ポリシーの変更のため、旧式の CAS ポリシーの型とメンバーを明示的に呼び出すか、その他の型とメンバーを介して暗黙的に呼び出すと、コンパイル警告およびランタイム例外が発生する場合があります。旧式の型とメンバー、およびそれらに代わる型とメンバーの一覧については、「コード アクセス セキュリティ ポリシーの互換性と移行」を参照してください。 ランタイム設定スキーマの <NetFx40_LegacySecurityPolicy> 構成要素を使用してレガシ CAS ポリシーの動作を有効にすることで、この警告およびエラーを回避できます。ただし、.NET Framework 4 に移行する場合を除き、レガシ セキュリティ ポリシーの使用の指定には、そのバージョンのカスタム CAS ポリシーは含まれません。 レガシ CAS ポリシーを有効にするには、Visual Studio プロジェクトの対象となる .NET Framework のバージョンを .NET Framework 4 より前のバージョンに設定することもできます。これにより、レガシ CAS ポリシーが有効になり、そのバージョンの指定したカスタム CAS ポリシーが含まれるようになります。ただし、.NET Framework 4 の新しい型およびメンバーは使用できません。以前のバージョンの .NET Framework を指定するには、スタートアップ設定スキーマの <supportedRuntime> 要素を使用することもできます。 |
ページのトップへ
透過的セキュリティ レベル 2
透過的セキュリティは .NET Framework Version 2.0 で導入されましたが、非常に限定的で、主にコード検証の効率を上げるために使用されていました。 .NET Framework 4 では、透過性は、アプリケーションの一部として実行されるコードをインフラストラクチャの一部として実行されるコードから分離する適用機構になりました。 透過性は、ネイティブ コードの呼び出しなどの特権的な処理を実行できるコード (クリティカル コード) と、そのような処理を実行できないコード (透過的なコード) との間に、障壁を設けます。 透過的なコードでは、コードに適用されたアクセス許可セットの範囲内のコマンドを実行できますが、クリティカル コードを実行したり呼び出したりすることはできません。また、クリティカル コードから派生したりクリティカル コードを含めたりすることもできません。
透過性を適用する主な目的は、特権に基づいてさまざまなコード グループを分離する簡単で効果的な機構を実現することです。 サンドボックス モデルでは、これらの特権グループは完全に信頼されるか (制限がありません) 部分的に信頼されます (サンドボックスに付与されたアクセス許可セットに制限されます)。
デスクトップ アプリケーションは完全に信頼されて実行されます。したがって、透過性モデルの影響を受けません。 透過的セキュリティの変更点の詳細については、「透過的セキュリティ コード、レベル 2」を参照してください。
ページのトップへ
アクセス許可要求の廃止
Deny、RequestMinimum、RequestOptional、および RequestRefuse の各アクセス許可要求を適用するためのランタイム サポートは削除されています。 一般に、これらの要求はあまり理解されておらず、適切に使用しないとセキュリティ上の脆弱性が発生する可能性がありました。
Deny アクションは、Assert アクションで簡単にオーバーライドできていました。 アセンブリの許可セットにアクセス許可があれば、アセンブリ内のコードでそのアクセス許可の Assert アクションを実行できていました。 Assert によって Deny がスタックに表示されなくなり、その効果がなくなっていました。
RequestMinimum は、アプリケーションのスコープ外では効果的に使用できませんでした。 RequestMinimum が実行可能 (.exe) ファイルに示されており、許可セットが満たされていない場合、ファイルのエンド ユーザーは、問題の解決方法の情報が示されていないハンドルされない FileLoadException 例外を受け取っていました。 アセンブリ内の型およびメンバーには、通常、それぞれ異なるアクセス許可要件があるので、ライブラリ (.dll ファイル) に単一の最小要求セットを使用することはできませんでした。
RequestOptional はわかりにくく、使い方が間違っていたために予期しない結果が生じることがよくありました。 開発者は、リストからアクセス許可を削除するとそのアクセス許可が暗黙的に拒否されると知らずに簡単に削除を行っていました。
RequestRefuse では、必要なアクセス許可を指定するのではなく、不要なアクセス許可を明示的に指定する必要があったので、効果的な最小特権モデルを実現できませんでした。 また、新しいアクセス許可が使用できるようになっても、リストに含まれませんでした。 さらに、一部のアクセス許可では拒否は意味を成しませんでした。 たとえば、IsolatedStoragePermission の UserQuota プロパティの値を拒否できていました。
最後に、不要なアクセス許可のみを指定する場合は、害を及ぼす可能性のあるアクセス許可をすべて指定しないと、セキュリティ上の脆弱性が発生する可能性がありました。
RequestOptional および RequestRefuse を使用すると、開発者は、ドメイン内に複数のアクセス許可セットを作成することで、同種のドメインを分割できていました。
.NET Framework 4 では、これらの列挙値のランタイム適用が削除されています。 これらの SecurityAction 値を使用する属性を含むアセンブリは引き続き読み込まれます。ただし、CLR は、参照アセンブリの読み込みまたはアクセス許可セットに基づく許可セットの変更を拒否しません。
ページのトップへ
条件 APTCA
AllowPartiallyTrustedCallersAttribute (APTCA) 属性の条件付き使用により、ホストでは、ホストのコンテキスト内に読み込まれた部分信頼の呼び出し元に公開するアセンブリを指定できます。 候補となるアセンブリは、既に部分信頼用に設計されている必要があります。つまり、それらのアセンブリは、APTCA (透過性モデルでセキュリティ セーフ クリティカル) であるか、完全に透過的である必要があります。 AllowPartiallyTrustedCallersAttribute の新しいコンストラクターにより、ホストでは、コンストラクターの呼び出しで PartialTrustVisibilityLevel 列挙型を使用することによって APTCA アセンブリの可視性のレベルを指定できます。
ページのトップへ
証拠オブジェクト
.NET Framework 4 の前は、ホスト コードを証拠として適用する場合にほとんどすべてのオブジェクトを証拠オブジェクトとして使用できました。 たとえば、.NET Framework コードの中には、System.Uri オブジェクトを証拠として認識するものもありました。 ランタイムは証拠オブジェクトを System.Object 参照として見なしていたので、証拠オブジェクトにタイプ セーフが適用されませんでした。
.NET Framework では証拠オブジェクトとして使用できる型に暗黙の制限があるため、これには問題がありました。 特に、証拠として使用されるオブジェクトはシリアル化される必要があり、null にできませんでした。 これらの要求が満たされない場合、これらの前提が必要な操作が実行されるたびに、CLR が例外をスローしていました。
証拠として使用できるオブジェクトの型の制約を有効にして、すべての証拠オブジェクトに新機能と要求を追加できるようにするために、すべての証拠オブジェクトが派生する新しい基本クラスである System.Security.Policy.EvidenceBase が .NET Framework 4 に導入されています。 インスタンス化時に、EvidenceBase クラスは証拠オブジェクトをシリアル化できることを保証します。 さらに、新規の既定の実装を基本クラスに追加することにより、新規の証拠の要求を将来作成できるようになります。
下位互換性
証拠オブジェクトとして CLR によって使用されるすべての型が、EvidenceBase から派生するために .NET Framework 4 で更新されました。 ただし、サードパーティ アプリケーションで使用されるカスタムの証拠型は不明なので、更新できません。したがって、このような証拠型は、EvidenceBase から派生した証拠を受け取る新しいメンバーでは使用できません。
ページのトップへ
証拠コレクション
.NET Framework 4 の前は、アセンブリが読み込まれるときにアセンブリに適用される証拠オブジェクトの完全なセットが CLR によって生成されていました。 これらのオブジェクトはリストに格納され、それをコンシューマーが反復処理して特定のオブジェクトを検索していました。 したがって、使用されるかどうかに関係なく、すべての証拠が使用できるようになっていました。 ほとんどの証拠オブジェクトでは、この動作は問題になりません。ただし、System.Security.Policy.Publisher (Authenticode 検証を必要とする) などの証拠オブジェクトでは、この動作は非効率でした。
この動作を改善するために、.NET Framework 4 では証拠コレクションの操作が再設計されました。 証拠コレクションは、リストではなくディクショナリのように動作するようになりました。 コンシューマーは、証拠コレクションを反復処理して必要な証拠オブジェクトが存在するかどうかを確認するのではなく、特定の型の証拠を要求できるようになりました。見つかった場合、コレクションから証拠が返されます。 たとえば、StrongName name = evidence.GetHostEvidence<StrongName>(); という呼び出しでは、存在する場合は StrongName オブジェクトが返され、存在しない場合は null が返されます。
このディクショナリ モデルでは、証拠オブジェクトが要求されるまでその生成は遅延されます。 Publisher の証拠の例では、アセンブリの Authenticode 署名を検証する際のパフォーマンス オーバーヘッドが、その情報が必要になるまで遅延されます。 Publisher の証拠が不要な完全に信頼されているアプリケーションでは、一般的に、検証プロセスは完全に回避されます。
ページのトップへ