Windows XP Service Pack 2およびWindows Server 2003 Service Pack 1でのDCOMのセキュリティ強化

Windows Server XP Service Pack 2 (SP2) およびWindows Server 2003 Service Pack 1 (SP1) では、分散コンポーネントオブジェクトモデル (DCOM) の既定のセキュリティ設定が強化されました。 具体的には、管理者がCOMサーバーの起動、アクティブ化、およびアクセスのためのローカルおよびリモートのアクセス許可を個別に制御できる、より詳細な権限が導入されています。

DCOM の機能

Microsoft Component Object Model (COM) は、対話可能なバイナリソフトウェアコンポーネントを作成するための、プラットフォームに依存しない分散型のオブジェクト指向システムです。 分散コンポーネントオブジェクトモデル (DCOM) を使用すると、ユーザーとアプリケーションにとって最適な場所にアプリケーションを分散できます。 DCOMワイヤプロトコルは、信頼性が高く、安全で、効率的なCOMコンポーネント間の通信を透過的にサポートします。

この機能は誰に適用されますか？

インプロセスCOMコンポーネントに対してのみCOMを使用する場合、この機能は適用されません。

この機能は、次のいずれかの条件を満たすCOMサーバーアプリケーションがある場合に適用されます。

• アプリケーションのアクセス許可は、アプリケーションの実行に必要な起動許可よりも厳格ではありません。
• 通常、アプリケーションは、管理者アカウントを使用せずにリモートCOMクライアントによってアクティブ化されます。
• アプリケーションはローカルでのみ使用されます。 これは、リモートからアクセスできないようにCOMサーバーアプリケーションを制限できることを意味します。

Windows XP Service Pack 2およびWindows Server 2003 Service Pack 1では、この機能にどのような新機能が追加されますか?

コンピューター全体の制限

コンピューター上のすべての呼び出し、アクティブ化、または起動要求へのアクセスを制御するコンピューター全体のアクセス制御を提供するために、COMに変更が加えられました。 これらのアクセス制御の最も簡単な例は、コンピューター上のCOMサーバーの呼び出し、アクティブ化、または起動ごとにコンピューター全体のアクセス制御リスト(ACL)に対して実行される追加のAccessCheck 呼び出しです。 AccessCheckが失敗すると、呼び出し、アクティブ化、または起動要求は拒否されます。 これは、サーバー固有のACLに対して実行されるAccessCheck とは別に追加で行われます。 実際には、コンピューター上の任意のCOMサーバーにアクセスするために渡す必要がある最小限の承認標準を提供します。 アクティブ化と起動の権限をカバーする起動アクセス許可のコンピューター全体のACLと、呼び出し権限をカバーするアクセス許可のコンピューター全体のACLがあります。 これらは、コンポーネント サービスの Microsoft 管理コンソール (MMC) を使用して構成できます。

これらのコンピューター全体のACLは、CoInitializeSecurity またはアプリケーション固有のセキュリティ設定を使用して、特定のアプリケーションで指定された脆弱なセキュリティ設定をオーバーライドする手段を提供します。 これにより、特定のサーバーの設定に関係なく、満たす必要がある最低限のセキュリティ標準が提供されます。

これらのAclは、RPCSSによって公開されるインターフェイスにアクセスするときにチェックされます。 これにより、このシステムサービスへのアクセスを制御する方法が提供されます。

これらのAclは、管理者がコンピューター上のすべてのCOMサーバーに適用される全般的な承認ポリシーを設定できる一元的な場所を提供します。

既定では、Windows XP SP2のコンピューターの制限設定は次のとおりです。

Windows Server 2003 SP 1のコンピュータ制限のデフォルト設定は次のとおりです。

この変更が重要なのはなぜですか。 どのような脅威の軽減に役立ちますか。

多くのCOMアプリケーションには、CoInitializeSecurity の呼び出しなどのセキュリティ固有のコードが含まれていますが、弱い設定を使用しているため、多くの場合プロセスへの認証されていないアクセスを許可しています。 現在、管理者がこれらの設定を上書きして、以前のバージョンのWindowsでセキュリティを強化する方法はありません。

COMインフラストラクチャには、システムの起動時に実行され、その後常に実行されるシステムサービスであるRPCSSが含まれています。 COMオブジェクトと実行中のオブジェクトテーブルのアクティブ化を管理し、DCOMリモート処理にヘルパーサービスを提供します。 リモートで呼び出すことができるRPCインターフェイスを公開します。 一部のCOMサーバーは認証されていないリモートアクセスを許可するため、認証されていないユーザーを含むすべてのユーザーがこれらのインターフェイスを呼び出すことができます。 その結果、RPCSSは、リモートの認証されていないコンピューター上の悪意のあるユーザーによって攻撃される可能性があります。

以前のバージョンのWindowsでは、管理者がコンピューター上のCOMサーバーの公開レベルを理解する方法はありませんでした。 管理者は、コンピューター上に登録されているすべてのCOMアプリケーションに対して構成されているセキュリティ設定を体系的にチェックすることによって公開レベルのアイデアを得ましたが、Windowsの既定のインストールには約150のCOMサーバーがあることを考えると、そのタスクは困難でした。 ソフトウェアのソースコードを確認する以外に、ソフトウェアにセキュリティが組み込まれているサーバーの設定を表示する方法はありませんでした。

DCOMコンピューター全体の制限により、これらの問題が軽減されます。 また、管理者は着信DCOMのアクティブ化、起動、および呼び出しを無効にすることもできます。

動作の相違点

既定では、Everyoneグループにはローカル起動、ローカルアクティブ化、およびローカルアクセス呼び出しのアクセス許可が付与されます。 これにより、ソフトウェアまたはオペレーティングシステムを変更せずに、すべてのローカルシナリオを機能させることができます。

既定では、Windows XP SP2では、Everyoneグループにリモートアクセス呼び出しのアクセス許可が付与されます。 Windows Server 2003 SP1では、EveryoneグループとAnonymousグループにリモートアクセスのアクセス許可が付与されます。 これにより、ほとんどのCOMクライアントシナリオが有効になります。これには、COMクライアントがローカル参照をリモートサーバーに渡し、クライアントをサーバーに変換する一般的なケースが含まれます。 Windows XP SP2では、認証されていないリモートアクセス呼び出しを必要とするシナリオが無効になる場合があります。

また、既定では、Administratorsグループのメンバーにのみ、リモートアクティベーションと起動のアクセス許可が付与されます。 これにより、インストールされているCOMサーバーに対する管理者以外によるリモートアクティベーションが無効になります。

これらの問題を解決するにはどうすればよいですか。

COMサーバーを実装し、管理者以外のCOMクライアントによるリモートアクティベーションをサポートする場合は、このプロセスを有効にすることに関連するリスクが許容されるかどうか、または管理者以外のCOMクライアントまたはリモートの認証されていない呼び出しによるリモートアクティベーションを必要としないように実装を変更する必要があるかどうかを検討する必要があります。

リスクが許容され、管理者以外のCOMクライアントまたはリモートの認証されていない呼び出しによるリモートアクティベーションを有効にする場合は、この機能の既定の構成を変更する必要があります。

構成設定は、コンポーネント サービスの Microsoft 管理コンソール (MMC) または Windows レジストリを使用して変更できます。

コンポーネントサービスMMCスナップインを使用する場合は、管理しているコンピューターの[プロパティ]ダイアログボックスの[COM セキュリティ]タブでこれらの設定を構成できます。 [アクセス許可]領域が変更され、COMサーバーの標準の既定の設定に加えて、コンピューター全体の制限を設定できます。 また、制限と既定の両方で、ローカルアクセスとリモートアクセスに対して個別のACL設定を指定できます。

[起動とライセンス認証のアクセス許可]領域では、ローカルおよびリモートのアクセス許可と、コンピューター全体の制限と既定値を制御できます。 ローカルとリモートの両方のアクティブ化と起動のアクセス許可を個別に指定できます。

または、レジストリを使用してこれらのACL設定を構成することもできます。

これらのAclは、レジストリの次の場所に格納されます。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineAccessRestriction=ACL
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineLaunchRestriction=ACL

これらは、コンピューター上の任意のCOMクラスまたはCOMオブジェクトにアクセスできるプリンシパルのACLを記述するデータを含むREG_BINARY型の名前付き値です。 ACLのアクセス権は次のとおりです。

COM_RIGHTS_EXECUTE 1
COM_RIGHTS_EXECUTE_LOCAL 2
COM_RIGHTS_EXECUTE_REMOTE 4
COM_RIGHTS_ACTIVATE_LOCAL 8
COM_RIGHTS_ACTIVATE_REMOTE 16

これらのACLは、通常のセキュリティ機能を使用して作成できます。

Windows XP Service Pack 2およびWindows Server 2003 Service Pack 1で変更される既存の機能は何ですか?

RPCSSはネットワークサービスとして実行されます。

RPCSS は、RPC エンドポイント マッパーおよび DCOM インフラストラクチャの主要なサービスです。 このサービスは、以前のバージョンのWindowsではローカルシステムとして実行されていました。 Windowsの攻撃対象領域を減らし、多層防御を提供するために、RPCSSサービス機能は2つのサービスに分割されました。 ローカルシステム特権を必要としないすべての元の機能を備えたRPCSSサービスは、ネットワークサービスアカウントで実行されるようになりました。 ローカルシステム特権を必要とする機能を含む新しいDCOMLaunchサービスは、ローカルシステムアカウントで実行されます。

この変更が重要なのはなぜですか。

この変更により、RPCSSサービスの特権の昇格がネットワークサービス特権に制限されるようになったため、攻撃対象領域が減少し、RPCSSサービスの多層防御が提供されます。

動作の相違点

RPCSSサービスとDCOMLaunchサービスの組み合わせは、以前のバージョンのWindowsで提供されていた以前のRPCSSサービスと同等であるため、この変更はユーザーに対して透過的である必要があります。

より具体的なCOMアクセス許可

COMサーバーアプリケーションには、起動許可とアクセス許可の2種類のアクセス許可があります。 起動アクセス許可は、サーバーがまだ実行されていない場合に、COMのアクティブ化中にCOMサーバーを起動するための承認を制御します。 これらのアクセス許可は、レジストリ設定で指定されているセキュリティ記述子として定義されます。 アクセス許可は、実行中のCOMサーバーを呼び出すための承認を制御します。 これらのアクセス許可は、CoInitializeSecurityAPIまたはレジストリ設定を使用することにより、COMインフラストラクチャに提供されるセキュリティ記述子として定義されます。 起動アクセス許可とアクセス許可はどちらも、プリンシパルに基づいてアクセスを許可または拒否し、呼び出し元がサーバーまたはリモートに対してローカルかどうかを区別しません。

最初の変更では、距離に基づいてCOMアクセス権が区別されます。 定義されている2つの距離は、ローカルとリモートです。 ローカルCOMメッセージは、ローカルリモートプロシージャコール (LRPC) プロトコルを使用して到着します。リモートCOMメッセージは、伝送制御プロトコル (TCP) などのリモートプロシージャコール (RPC) ホストプロトコルを使用して到着します。

COMアクティブ化とは、CoCreateInstanceまたはそのバリアントの1つを呼び出して、クライアントでCOMインターフェイスプロキシを取得する動作です。 このアクティブ化プロセスの副作用として、クライアントの要求を満たすためにCOMサーバーを開始する必要がある場合があります。 起動アクセス許可ACLは、COMサーバーを起動できるユーザーをアサートします。 アクセス許可ACLは、COMオブジェクトをアクティブ化するか、COMサーバーが既に実行されている場合にそのオブジェクトを呼び出すことができるユーザーをアサートします。

2番目の変更は、呼び出しとアクティブ化の権限が分離され、2つの異なる操作を反映し、アクティブ化権限をアクセス許可ACLから起動アクセス許可ACLに移動することです。 アクティブ化と起動は両方ともインターフェイスポインターの取得に関連しているため、アクティブ化と起動のアクセス権は論理的に1つのACLに属しています。 また、常に構成(プログラムによって指定されることが多いアクセス許可と比較して)を使用して起動アクセス許可を指定するため、起動アクセス許可ACLにアクティブ化権限を配置すると、管理者はアクティブ化を制御できます。

起動許可アクセス制御エントリ (ACE) は、次の4つのアクセス権に分割されます。

• ローカル起動 (LL)
• リモート起動 (RL)
• ローカルアクティブ化 (LA)
• リモートアクティブ化 (RA)

アクセス許可のセキュリティ記述子は、次の2つのアクセス権に分割されます。

• ローカルアクセス呼び出し (LC)
• リモートアクセス呼び出し (RC)

これにより、管理者は特定のセキュリティ構成を適用できます。 たとえば、管理者からのリモートアクセス呼び出しのみを受け入れる一方で、すべてのユーザーからのローカルアクセス呼び出しを受け入れるようにCOMサーバーを構成できます。 これらの区別は、COMアクセス許可のセキュリティ記述子を変更することによって指定できます。

この変更が重要なのはなぜですか。 どのような脅威の軽減に役立ちますか。

以前のバージョンのCOMサーバーアプリケーションには、DCOM経由でネットワーク上のアプリケーションを公開せずにローカルでのみ使用できるようにアプリケーションを制限する方法がありません。 ユーザーがCOMサーバーアプリケーションにアクセスできる場合は、ローカルとリモートの両方で使用できます。

COMサーバーアプリケーションは、COMコールバックシナリオを実装するために、認証されていないユーザーに公開される場合があります。 このシナリオでは、アプリケーションは認証されていないユーザーにもアクティブ化を公開する必要がありますが、これは望ましくない場合があります。

正確なCOMアクセス許可により、管理者はコンピューターのCOMアクセス許可ポリシーを柔軟に制御できます。 これらのアクセス許可により、説明されているシナリオのセキュリティが有効になります。

動作の相違点 依存関係はありますか。

下位互換性を提供するために、既存のCOMセキュリティ記述子は、ローカルとリモートの両方のアクセスを同時に許可または拒否するように解釈されます。 つまり、アクセス制御エントリ (ACE) は、ローカルとリモートの両方を許可するか、ローカルとリモートの両方を拒否します。

呼び出し権限または起動権限には、下位互換性の問題はありません。 ただし、アクティブ化権限の互換性の問題があります。 COMサーバーの既存のセキュリティ記述子で、構成されている起動許可がアクセス許可よりも制限が厳しく、クライアントのアクティブ化シナリオに最低限必要なものよりも制限が厳しい場合は、起動許可ACLを変更して、承認されたクライアントに適切なアクティブ化アクセス許可を付与する必要があります。

既定のセキュリティ設定を使用するCOMアプリケーションの場合、互換性の問題はありません。 COMアクティブ化を使用して動的に起動されるアプリケーションの場合、起動アクセス許可にはオブジェクトをアクティブ化できるユーザーが既に含まれている必要があるため、ほとんどの場合、互換性の問題はありません。 それ以外の場合、このようなアプリケーションは、Windows XP SP2またはWindows Server 2003 SP1を適用する前でも、起動アクセス許可のない呼び出し元がオブジェクトをアクティブ化しようとしたときに、COMサーバーがまだ実行されていない場合に、アクティブ化エラーを生成します。

互換性の問題が最も懸念されるアプリケーションは、エクスプローラーやサービス コントロール マネージャーなど、他のメカニズムによって既に起動されている COM アプリケーションです。 これらのアプリケーションは、以前の COM アクティブ化によって起動することもできます。これにより、既定のアクセスと起動のアクセス許可が上書きされ、呼び出しのアクセス許可よりも制限の厳しい起動アクセス許可が指定されます。 この互換性の問題への対処の詳細については、次のセクションの「これらの問題を解決するにはどうすればよいですか? 」を参照してください。

Windows XP SP2 または Windows Server 2003 SP1 にアップグレードされたシステムが以前の状態にロールバックされた場合、ローカル アクセス、リモート アクセス、またはその両方を許可するように編集された ACE は、ローカル アクセスとリモート アクセスの両方を許可するように解釈されます。 ローカル アクセス、リモート アクセス、またはその両方を拒否するように編集された ACE は、ローカル アクセスとリモート アクセスの両方を拒否するように解釈されます。 Service Pack をアンインストールするときは常に、新しく設定された ACE によってアプリケーションの動作が停止しないようにする必要があります。

これらの問題を解決するにはどうすればよいですか。

COM サーバーを実装し、既定のセキュリティ設定をオーバーライドする場合は、アプリケーション固有の起動アクセス許可 ACL が適切なユーザーにアクティブ化アクセス許可を付与していることを確認します。 そうでない場合は、アプリケーション固有の起動アクセス許可 ACL を変更して、DCOM を使用するアプリケーションと Windows コンポーネントが失敗しないように、適切なユーザーにアクティブ化権限を付与する必要があります。 これらのアプリケーション固有の起動アクセス許可は、レジストリに格納されます。

COM ACL は、通常のセキュリティ機能を使用して作成または変更できます。

Windows XP Service Pack 2 で追加または変更される設定は何ですか?

次の表では、これらの省略形が使用されています。

LL: ローカル起動

LA: ローカルアクティブ化

RL: リモート起動

RA: リモート アクティブ化

LC: ローカル アクセス コール

RC: リモート アクセス コール

ACL: アクセス制御リスト

Windows Server 2003 Service Pack 1では、どのような設定が追加または変更されますか?

次の表では、これらの省略形が使用されています。

LL: ローカル起動

LA: ローカルアクティブ化

RL: リモート起動

RA: リモートアクティブ化

LC: ローカルアクセスコール

RC: リモートアクセスコール

ACL: アクセス制御リスト

関連トピック

COM でのセキュリティ