この記事では、部分信頼環境で Windows Communication Foundation (WCF) を実行する場合のベスト プラクティスについて説明します。
シリアル化
部分的に信頼されたアプリケーションで DataContractSerializer を使用する場合は、これらのプラクティスを適用します。
シリアル化可能なすべての型は、 [DataContract] 属性で明示的にマークする必要があります。 部分信頼環境では、次の手法はサポートされていません。
- SerializableAttributeを使用してシリアル化するクラスのマーキング。
- クラスがシリアル化プロセスを制御できるように、 ISerializable インターフェイスを実装します。
DataContractSerializer の使用
[DataContract]属性でマークされているすべての型はパブリックである必要があります。 部分信頼環境では、非パブリック型をシリアル化できません。シリアル化可能な
[DataContract]型のすべての[DataContract]メンバーはパブリックである必要があります。 パブリックでない[DataMember]を持つ型は、部分信頼環境ではシリアル化できません。シリアル化イベント (
OnSerializing、OnSerialized、OnDeserializing、OnDeserializedなど) を処理するメソッドは、パブリックとして宣言する必要があります。 ただし、 OnDeserialization(Object) の明示的な実装と暗黙的な実装の両方がサポートされています。[DataContract]AllowPartiallyTrustedCallersAttributeは逆シリアル化中に新しくインスタンス化されたオブジェクトのコンストラクターを呼び出さないため、DataContractSerializerでマークされたアセンブリに実装された型は、型コンストラクターでセキュリティ関連のアクションを実行してはなりません。 具体的には、[DataContract]の種類では、次の一般的なセキュリティ手法を避ける必要があります。型のコンストラクターを内部またはプライベートにすることで、部分信頼アクセスを制限しようとしています。
型のコンストラクターに
[LinkDemand]を追加して、型へのアクセスを制限する。オブジェクトが正常にインスタンス化されたため、コンストラクターによって適用されるすべての検証チェックが正常に成功したと仮定します。
IXmlSerializable の使用
IXmlSerializableを実装し、DataContractSerializerを使用してシリアル化される型には、次のベスト プラクティスが適用されます。
GetSchema静的メソッドの実装は
publicする必要があります。IXmlSerializable インターフェイスを実装するインスタンス メソッドは
publicする必要があります。
部分的に信頼された呼び出し元からの呼び出しを許可する完全に信頼されたプラットフォーム コードからの WCF の使用
WCF 部分信頼セキュリティ モデルは、WCF パブリック メソッドまたはプロパティの呼び出し元が、ホスト アプリケーションのコード アクセス セキュリティ (CAS) コンテキストで実行されていることを前提としています。 また、WCF では、各AppDomainに対して 1 つのアプリケーション セキュリティ コンテキストのみが存在し、このコンテキストは信頼されたホスト (たとえば、AppDomainの呼び出しや ASP.NET アプリケーション マネージャーによって) によってCreateDomain作成時に確立されることを前提としています。
注
コード アクセス セキュリティ (CAS) は、.NET Framework と .NET のすべてのバージョンで非推奨になりました。 最近のバージョンの .NET では、CAS に関連する API が使用されている場合、CAS 注釈は使用されず、エラーが発生します。 開発者は、セキュリティ タスクを実行するための代替手段を求める必要があります。
このセキュリティ モデルは、Medium Trust ASP.NET アプリケーションで実行されているユーザー コードなど、追加の CAS アクセス許可をアサートできないユーザー作成アプリケーションに適用されます。 ただし、完全に信頼されたプラットフォーム コード (たとえば、グローバル アセンブリ キャッシュにインストールされ、部分的に信頼されたコードからの呼び出しを受け入れるサード パーティ製アセンブリ) は、部分的に信頼されたアプリケーションの代わりに WCF を呼び出すときに明示的な注意を払って、アプリケーション レベルのセキュリティの脆弱性が発生しないようにする必要があります。
完全信頼コードでは、部分的に信頼されたコードの代わりに WCF API を呼び出す前に、現在のスレッドの CAS アクセス許可セット ( Assert、 PermitOnly、または Denyを呼び出すことによって) を変更しないようにする必要があります。 アプリケーション レベルのセキュリティ コンテキストに依存しないスレッド固有のアクセス許可コンテキストをアサート、拒否、またはその他の方法で作成すると、予期しない動作が発生する可能性があります。 アプリケーションによっては、この動作によってアプリケーション レベルのセキュリティの脆弱性が発生する可能性があります。
スレッド固有のアクセス許可コンテキストを使用して WCF を呼び出すコードは、発生する可能性のある次の状況を処理するために準備する必要があります。
操作の期間中、スレッド固有のセキュリティ コンテキストを維持できない可能性があるため、セキュリティ例外が発生する可能性があります。
内部 WCF コードとユーザー指定のコールバックは、呼び出しが最初に開始されたものとは異なるセキュリティ コンテキストで実行される可能性があります。 これらのコンテキストは次のとおりです。
アプリケーションのアクセス許可コンテキスト。
現在実行中の AppDomainの有効期間中に WCF への呼び出しに使用された、他のユーザー スレッドによって以前に作成されたスレッド固有のアクセス許可コンテキスト。
WCF では、WCF パブリック API を呼び出す前に完全に信頼されたコンポーネントによってこのようなアクセス許可がアサートされない限り、部分的に信頼されたコードが完全信頼のアクセス許可を取得できないことが保証されます。 ただし、完全信頼のアサートによる影響が特定のスレッド、操作、またはユーザー アクションに分離される保証はありません。
ベスト プラクティスとして、 Assert、 PermitOnly、または Denyを呼び出して、スレッド固有のアクセス許可コンテキストを作成しないようにします。 代わりに、 Assert、 Deny、または PermitOnly が不要になるように、アプリケーション自体に特権を付与または拒否します。