一般的に、.NET リモート処理を使用するアプリケーションには、ローカル アプリケーションよりも複雑なセキュリティ上の課題があります。
分散アプリケーションのセキュリティを保つ上で、パフォーマンスを低下させずに対処することが難しい、1 つの問題があります。通信の一方の端で呼び出しが待機されている場合、それを知っている未認証のクライアントが、シリアル化された情報を送り、それがもう一方の端で逆シリアル化されたり実行されたりすることをねらう可能性があります。信頼性の高いコンポーネント間通信を行うには、相互認証とコンテンツの暗号化が必要になります。このため、まずセキュリティの要件を考慮し、次にパフォーマンスの要件を考慮するという方法で、リモート処理アプリケーションのデザインを評価する必要があります。これらのセキュリティ対策をせずにデータとエンドポイントを公開する場合は、アプリケーションのデータの整合性がどの程度必要か、データへの投資がどの程度であったかなどを考慮して、公開の度合いを決定してください。
この問題を、リモート処理のデリゲートの場合を例にして考えてみましょう。デリゲートは、リモートからは絶対に実行できない静的メソッドの型情報をラップできるため、サーバー アプリケーションは、常に、カスタム パラメータを受け取るカスタム デリゲート型を宣言し、サーバー コンピュータ上で呼び出せる静的メソッドとは一致しないようにします。クライアントには、意図的かどうかにかかわらず、サーバーが逆シリアル化を実行するような型を定義したり、アプリケーションに渡したりすることを許可しないでください。
リモート処理インフラストラクチャを使用する安全な分散アプリケーションをデザインする場合に重要な点は、どこにどの程度のセキュリティが必要かを明らかにすることです。このセクションでは、デザイン上の一定の決定に基づいた、セキュリティへのさまざまなアプローチについて説明します。すべてのシナリオを取り上げることはできませんが、以下に示すトピックは決定を行うための良い出発点となります。
コード アクセス セキュリティ
コード アクセス セキュリティは、実行可能コードがリソースや操作に対して持つアクセス権限を、コンピュータの管理者によって設定されたセキュリティ ポリシーに基づいて制御します。ただし、コード アクセス セキュリティはリモート接続経由でスタックをウォークすることはないため、リモート処理アプリケーションの開発者は、リモート処理インフラストラクチャではクライアントとサーバーのどちらの実行でも完全な信頼度が要求されることを明確に理解しておく必要があります。
**注意 **AppDomain オブジェクトに対し、リモート処理できるラッパーは絶対に作成しないでください。作成すると、この AppDomain への参照がリモートで公開できるようになるため、AppDomain.CreateInstance などのメソッドがリモートで公開され、AppDomain のコード アクセス セキュリティが破壊される可能性があります。リモートから AppDomain に接続している未認証のクライアントが、AppDomain がアクセスできる任意のリソースへのアクセス権を入手する可能性があります。実際には、MarshalByRefObject を拡張するすべての型や、認証されていないユーザーがセキュリティ システムを回避するために使うようなメソッドを実装しているすべての型で、このようなことが起きないようにする必要があります。
一般的には、MarshalByRefObject を拡張するいくつかのシステム型では、実行時にセキュリティ チェックを行い、アプリケーション ドメイン外からこの型のオブジェクトをリモート呼び出しできないようにしています。たとえば、AppDomain と System.Windows.Forms.Form は、そのようになっています。MarshalByRefObject を拡張して参照をリモートから取得する場合も考えられますが、これらの特殊な型では、そうすることができないようになっています。インプロセス参照を別のリモート型でラップすることは便利であるように思えますが、コード アクセス セキュリティを回避することになってしまうため、絶対に行わないでください。
リモート処理アプリケーションのセキュリティに関する考慮事項
一般に、分散アプリケーションのセキュリティを計画する場合には、想定されているシナリオに基づいて 2 つの領域のセキュリティについて考える必要があります。つまり、通信チャネルとメッセージ自体を安全にするか、またはアプリケーションを不正な使用に対して安全にする (またはこの両方をある程度まで行う) 必要があります。
通常、通信チャネルを安全にするには、メッセージの内容をストリームの一方の端で暗号化し、もう一方の端で復号化するか、チャネル自体を暗号化するか、またはその両方を行います。メッセージの内容が改ざんされていないことを確認するために、整合性の確認が必要な場合もあります。クライアントまたはサーバー (または両方) の ID の確認が必要なこともあります。
認証されていない使用からアプリケーションを保護するには、通常、ユーザーがそのアプリケーションを使用するためのアクセス許可を持っているかどうかを最初に確認したり、場合によっては後で使用パターンを構成するためにユーザーの操作を記録したりします。
リモート処理でのセキュリティのデザイン
安全で構築しやすいアプリケーションをデザインするために、明らかにしておく必要のある 2 つの主要な問題があります。
- どのようなチャネルが使用可能か。
- サーバーでどのようなユーザー認証モデルおよびユーザー認定モデルを使用するか。
HttpChannel オブジェクトと TcpChannel オブジェクトのどちらを使用するか選択できる場合は、ユーザー認証モデルやユーザー認定モデルの種類に関係なく、HttpChannel を使用し、リモート オブジェクトをインターネット インフォメーション サービス (IIS: Internet Information Services) で管理することをお勧めします。IIS 管理では、SSL (Secure Sockets Layer) を使用したネットワーク レベルでの保護や、Integrated Windows Authentication (以前の NTLM 認証) や Kerberos を使用した認証がサポートされます。
伝送制御プロトコル (TCP: Transmission Control Protocol) の実装である TcpChannel は、HTTP 規格でサポートされている信頼性の高い認証規格の一部が、既定ではサポートされません。IPSec などによりネットワーク レベルで保護されている環境内では、高速の TcpChannel を使用できますが、これはインターネットや暗号化されていないイントラネットではお勧めできません。
注意 .NET リモート処理では、既定では認証または暗号化を行いません。したがって、クライアントやサーバーとリモートで対話する前に、ID の確認に必要な手順をすべて実行することをお勧めします。.NET リモート処理アプリケーションの実行には、FullTrust アクセス許可が必要です。そのため、認証されていないクライアントがサーバー上でのアクセスを許可された場合は、完全な信頼を与えられているものとして、コードを実行できてしまいます。リモート処理される型を IIS で管理するか、カスタム チャネル シンクのペアを作成することによって、常にエンドポイントを認証し、通信ストリームを暗号化してください。
サーバーのユーザー認証モデルやユーザー認定モデルには数多くの種類がありますが、リモート オブジェクトを IIS で管理する場合には、最も複雑なソリューションがサポートされます。このソリューションでは、ほとんどコーディングの必要がなく、サーバーでのクライアントの WindowsPrincipal オブジェクトや GenericPrincipal オブジェクトの探索も既定でサポートされます。これは、ユーザーに代わってなんらかの処理を実行するためにクライアントを偽装する必要がある場合に便利です。詳細については、「偽装と復帰」を参照してください。
GenericPrincipal オブジェクトは、Windows ドメインに依存しない任意のユーザー認証方式を表します。このため、これらのオブジェクトを拡張して、ユーザー データベースと共に動作させたり、他のプラットフォームと相互運用させることができます。
参照
.NET リモート処理の概要 | HttpChannel による Web セキュリティ | マネージ アプリケーションでのロール ベース セキュリティ | コード アクセス セキュリティ | RemotingConfiguration | ChannelServices | Context クラス | MethodCall | RemotingServices