リモート処理でのセキュリティ
一般的に、.NET Framework リモート処理を使用するアプリケーションには、ローカル アプリケーションよりも複雑なセキュリティ上の課題があります。
分散アプリケーションのセキュリティを保つうえで、パフォーマンスを低下させずに対処することが難しい、1 つの問題があります。通信の一方のエンドポイントで呼び出しがリッスンされている場合、それを検出している未承認のクライアントが、シリアル化された情報を送ることができます。その結果、情報はもう一方のエンドポイントで逆シリアル化されたり呼び出されたりします。信頼されているコンポーネント間で通信が行われていることを合理的に確認する方法は、相互認証と内容の暗号化以外にありません。したがって、まずリモート処理アプリケーションのセキュリティ要件について検討し、次にパフォーマンス要件について検討する必要があります。認証および暗号化を行わないデータおよびエンドポイントの公開は、アプリケーションに対して必要なデータの整合性を満たす程度にとどめてください。
この問題を、リモート処理のデリゲートの場合を例にして考えてみましょう。デリゲートは、リモートからは絶対に実行できない静的メソッドの型情報をラップできるため、サーバー アプリケーションは、常に、カスタム パラメータを受け取るカスタム デリゲート型を宣言し、サーバー コンピュータ上で呼び出せる静的メソッドとは一致しないようにします。クライアントには、サーバーが逆シリアル化を実行するような型を定義したり、アプリケーションに渡したりすることを許可しないでください。
.NET Framework リモート処理インフラストラクチャを使用する分散アプリケーションをデザインする場合に重要なのは、どこにどの程度のセキュリティが必要かを明らかにするということです。このセクションでは、デザイン上の一定の決定に基づいた、セキュリティへのさまざまなアプローチについて説明します。すべてのシナリオを取り上げることはできませんが、以下に示すトピックは決定を行うための良い出発点となります。
コード アクセス セキュリティ
コード アクセス セキュリティは、実行可能コードがリソースや操作に対して持つアクセス権限を、コンピュータの管理者によって設定されたセキュリティ ポリシーに基づいて制御します。ただし、コード アクセス セキュリティはリモート接続経由でスタックをウォークすることはないため、リモート処理アプリケーションの開発者は、リモート処理インフラストラクチャではクライアントとサーバーのどちらの実行でも完全な信頼度が要求されることを明確に理解しておく必要があります。リモート処理アプリケーションの不正使用が可能になると、FullTrust アクセス許可への不正アクセスが可能になります。
注意
AppDomain オブジェクトに対し、リモート処理できるラッパーは絶対に作成しないでください。作成すると、この AppDomain への参照をリモートで公開できるようになるため、AppDomain.CreateInstance などのメソッドがリモートで公開され、その AppDomain のコード アクセス セキュリティが実質的に破壊される可能性があります。リモートから AppDomain に接続している承認されていないクライアントが、AppDomain がアクセスできる任意のリソースへのアクセス権を入手する可能性があります。実際には、MarshalByRefObject を拡張し、承認されていないクライアントが使用してセキュリティ システムを回避する可能性のあるメソッドを実装するすべて型に対して、リモート処理可能なラッパーを作成しないようにしてください。
.gif) メモ : |
|---|
一般的には、MarshalByRefObject を拡張するいくつかのシステム型では、実行時にセキュリティ チェックを行い、アプリケーション ドメイン外から MarshalByRefObject 型のオブジェクトをリモート呼び出しできないようにしています。たとえば、AppDomain と System.Windows.Forms.Form は、そのようなシステム型の例です。MarshalByRefObject を拡張して参照をリモートから取得する場合も考えられますが、これらの特殊な型では、そうすることができないようになっています。インプロセス参照を別のリモート処理可能な型でラップすると便利であるように思えますが、コード アクセス セキュリティを回避することになってしまうため、絶対に行わないでください。 |
リモート処理アプリケーションのセキュリティに関する考慮事項
一般に、分散アプリケーションのセキュリティを計画する場合には、想定されているシナリオに基づいて 2 つの領域のセキュリティについて考える必要があります。つまり、通信チャネルとメッセージ自体をセキュリティ保護するか、またはアプリケーションを不正な使用からセキュリティ保護するかです。また、両方の領域で、ある程度のセキュリティ保護を行うこともできます。
通常、通信チャネルをセキュリティで保護するには、チャネル自体を暗号化するか、メッセージの内容をストリームの一方の端で暗号化し、もう一方の端で復号化するか、またはその両方を行います。メッセージの内容が改ざんされていないことを確認するために、整合性の確認が必要な場合もあります。クライアントまたはサーバー (または両方) の ID の確認が必要なこともあります。
第一に、常にクライアントに対して認証を行い、リソースを使用するアクセス許可を持っていることを確認する必要があります。第二に、すべての通信を暗号化し、伝送中のデータを保護する必要があります。これらのステップはどちらも、HttpChannel と TcpChannel の両方で完全にサポートされています。IPC チャネルは同じコンピュータ上でのみ動作するので暗号化はサポートしていませんが、Windows 認証はサポートしています。
上記の 2 つの規則には例外がいくつかあります。パフォーマンスの要件が高く、データの監視と操作があまり重要でないような価値の低いデータ値の場合、暗号化は除外されることがあります。また、IPsec でセキュリティ保護されたネットワークなどのように暗号化されたネットワークで通信が行われる場合にも、暗号化は無効にされることがあります。
さらに、ユーザーの操作をログに記録し、後で使用パターンを再構築すると、承認されていない使用からアプリケーションを保護するのに役立ちます。
注意
.NET Framework リモート処理では、既定では認証または暗号化を行いません。したがって、クライアントやサーバーとリモートで対話する前に、ID の確認に必要な手順をすべて実行することをお勧めします。.NET Framework リモート処理アプリケーションの実行には、FullTrust アクセス許可が必要です。そのため、承認されていないクライアントがサーバー上でのアクセスを許可された場合は、完全な信頼を与えられているものとして、コードを実行できてしまいます。常にエンドポイントに対して認証を行い、通信ストリームを暗号化します。これは、インターネット インフォメーション サービス (IIS : Internet Information Services) でリモート型をホストするか、これを行うカスタム チャネル シンク ペアを構築することによって可能になります。.NET Framework バージョン 2.0 では、通信をセキュリティで保護するためにカスタム シンクを構築する必要はなくなりました。認証および暗号化機能 (TCP チャネルに対して secure = true を設定することによって有効化する機能) によって、セキュリティで保護された通信が可能です。TCP チャネルでは、接続ユーザーの認証、ワイヤ上のデータの暗号化、および接続クライアントの ID と IP アドレスの判別が可能になりました。
参照
関連項目
RemotingConfiguration
ChannelServices
Context
MethodCall
RemotingServices