安全な配置 (2003 システム)

更新 : 2007 年 11 月

Visual Studio Tools for Office ソリューションを作成すると、ローカルのセキュリティ ポリシーが自動的に更新され、プロジェクト内のコードの実行が許可されます。ただし、ソリューションを配置する場合は、ソリューションを使用する各コンピュータのセキュリティ ポリシーを明示的に更新して、Office オブジェクト モデルの実行とアクセスの許可をアセンブリ コードに付与する必要があります。

ドキュメント レベルのカスタマイズでは、ドキュメントをネットワーク上に配置する場合、ドキュメントのセキュリティ ポリシーも更新する必要があります。エンド ユーザー コンピュータにおけるセキュリティ ポリシーの設定の詳細については、「セキュリティ ポリシーの配置」を参照してください。ドキュメント レベルのカスタマイズの詳細については、「ドキュメント レベルのカスタマイズのアーキテクチャ」を参照してください。

厳密な名前と証明書

ソリューションを安全に配置するには、アセンブリに厳密な名前を付けるか、Authenticode (x.509) 証明書を使ってアセンブリに署名することを推奨します。また、特別なセキュリティと管理のしやすさが求められる場合には、この両方を採用することをお勧めします。厳密な名前や署名を無効にせずにコードを変更することは非常に難しいため、厳密な名前と Authenticode 署名を利用すれば、高度なセキュリティを実現できます。また、Authenticode 署名には、次の利点もあります。

• Authenticode 署名にはタイム スタンプを付けることができます。

• 証明書は失効できます。

• 証明書が発行者の ID となります。

厳密な名前付きアセンブリの詳細については、「厳密な名前付きアセンブリ」および「厳密な名前付きアセンブリの作成と使用」を参照してください。

Authenticode 署名の詳細については、「配置と Authenticode 署名」を参照してください。

セキュリティ レベルの選択

厳しい規則を設定した場合のセキュリティ上のメリットと、緩い規則を設定した場合の管理上のメリットを比較したうえで、適切なレベルの信頼を選択する必要があります。たとえば、ソリューションを \\appserver\ というサーバーに常に配置し、企業の証明書で常に署名する場合は、\\appserver\ 上の企業証明書のみを信頼する規則を選択します。\\appserver\ からのコードでない限りコードは信頼されないので、この選択は、悪意を持つユーザーが証明書を盗み、インターネットにコードを発行することを防止するには有効です。ただし、将来、アセンブリを別のサーバーに保存する場合は、セキュリティ ポリシーを再度更新する必要があります

ソリューションの配置場所が不明な場合は、ローカル コンピュータとローカル イントラネットの証明書または厳密な名前を信頼するのが妥当です。Web にコードを配布する場合は、Internet Explorer のセキュリティ オプションの信頼済みサイト ゾーンを使用することもできます。インターネット ゾーン、制限付きサイト ゾーン、またはトップ レベル (すべてのコード) の証明書の信頼を強く求めるビジネス ニーズが存在しない限り、これらの証明書を信頼しないでください。これらの証明書を信頼する場合は、悪意を持つユーザーの手にコードが渡っても安全であることを保証する、適切な対策を講じます。詳細については、「コード アクセス セキュリティ」を参照してください。

発生する可能性のある脅威については、「Office ソリューションに固有のセキュリティに関する考慮事項」を参照してください。

アセンブリへのアクセスの付与

ドキュメント レベルのカスタマイズの配置オプションの 1 つとして、ドキュメントをローカルで各ユーザーに配置し、アセンブリをネットワーク上の場所に配置する方法があります。同様にアプリケーション レベルのアドインでも、アドイン アセンブリをネットワーク上の場所に配置できます。アセンブリは、信頼されるまでは Office ソリューション内で実行されません。アセンブリにデジタル署名し、システム管理者 (またはアセンブリを変更する必要のある人) にだけ、配置場所に対する書き込みアクセス許可を付与します。配置前のアセンブリのセキュリティ保護の詳細については、「アセンブリのセキュリティに関する考慮事項」を参照してください。

Microsoft .NET Framework 2.0 構成ツールや、コード アクセス セキュリティ ポリシー ツール (Caspol.exe) を使用すると、アセンブリを信頼するエンタープライズ レベルのポリシーを設定できます。

.NET Framework 構成ツールの詳細については、「.NET Framework 構成ツール (Mscorcfg.msc)」を参照してください。Caspol.exe の詳細については、「コード アクセス セキュリティ ポリシー ツール (Caspol.exe)」および「コード アクセス セキュリティ ポリシー ツール (Caspol.exe) によるセキュリティ ポリシーの構成」を参照してください。

最終的な配置場所にアセンブリを配置する (または配置されたアセンブリを更新する) 前に、セキュリティ ポリシーを調べて、どのような証拠を使用して脆弱性を最小限に抑えるかを決定してください。詳細については、「Office ソリューションの実行に必要なセキュリティ条件 (2003 システム)」を参照してください。

ネットワーク上のドキュメントのセキュリティ保護

ドキュメント レベルのカスタマイズでは、ドキュメントをサーバーやネットワーク共有に配置する場合、ドキュメントの URL に完全な信頼を付与する必要があります。こうした信頼の付与は、信頼されるユーザーだけに修正を許可するテンプレートや個々のドキュメントの場合に最適です。信頼されていないユーザーには、共有上のドキュメントを修正したり、置き換えたりするアクセス許可を付与しないでください。

SharePoint ポータルなどの公開された共有に配置されたドキュメントに、ユーザーがアクセスできるようにする場合、管理者は、ポリシーを変更してドキュメントに新しいコード グループを含める必要があります。コード グループは、メンバシップ条件とは別に重要です。メンバシップ条件では、Office ドキュメントを証拠の一部として検索し、管理者はそれに応じて信頼を決定できます (管理者がコード グループを追加して明示的にアセンブリを信頼する必要がある場合と同じ)。詳細については、「方法 : 共有の場所にあるドキュメントおよびブックにアクセス許可を与える (2003 システム)」を参照してください。

電子メールの配信

既定で、ドキュメント レベルのカスタマイズでは、ドキュメントが電子メール メッセージから直接開かれた場合、アセンブリは実行されません。ただし、このドキュメントをローカル ハード ディスクに保存した後であれば、通常どおりに開くことができます。ドキュメントのアプリケーション マニフェストに、完全に信頼されたアセンブリへの完全パスが指定されている場合は、ソリューションが実行されます。

推奨される方法ではありませんが、Outlook の一時フォルダのドキュメントを使ってコードをホストできます。この方法では、安全性に低～中程度のリスクが生じます。これは、完全な信頼が付与された配置済みのアセンブリに脆弱性がある場合、悪意を持つユーザーは、そのアセンブリを指すドキュメントを電子メール メッセージに添付し、受信者にそのドキュメントを開かせることによって、その脆弱性を悪用できるためです。これが成功すると、攻撃者はターゲット ユーザーの資格情報を利用して、たとえば、セキュリティ保護されたイントラネット サイトにアクセスすることが可能となります。アセンブリには完全な信頼を明示的に付与する必要があります。これにより、攻撃者は自分で選んだドキュメントやアセンブリを作成し、ユーザーを騙してそれを実行させることができなくなります。

セキュリティ ポリシーの変更

管理者がドキュメントまたはアセンブリのアクセス許可を調整する場合、このような調整を強制的に実行するには、ユーザーがすべての Office アプリケーションを終了して再起動する必要があります。

しかし、ユーザーが Office アプリケーションを終了した後も、アプリケーションのプロセスが継続する場合があります。この場合、セキュリティ ポリシーの変更が有効になりません。タスク マネージャを調べて、Office アプリケーションが、アクティブなプロセスの一覧に表示されていないことを確認します。

Office アプリケーションをホストする他のアプリケーションにより、新しいアクセス許可の強制適用が妨げられる場合もあります。セキュリティ ポリシーを変更するときは、Office (ホストされているか、スタンドアロンであるかを問わず) を使用するすべてのアプリケーション (Internet Explorer を含む) を終了してください。

ドキュメント レベルのカスタマイズによるコード実行の防止

すべてのドキュメント レベルのカスタマイズがコンピュータ上で実行されないようにするために、管理者はレジストリを使用できます。マネージ コード拡張機能を含んでいる Word 文書または Excel ブックを開いたときには、Visual Studio Tools for Office ランタイムによって、コンピュータ上の次のレジストリ キーのいずれかの下に Disabled という名前のエントリが存在するかどうかが確認されます。

• HKEY_CURRENT_USER\Software\Microsoft\VSTO

• HKEY_LOCAL_MACHINE\Software\Microsoft\VSTO

ドキュメント レベルのカスタマイズでコードを実行しないようにするには、上記のレジストリ キーのいずれかまたは両方の下に Disabled エントリを作成し、Disabled に対して次のデータ型および値のいずれかを指定します。

• REG_SZ または REG_EXPAND_SZ。"0" (ゼロ) 以外の文字列に設定します。

• REG_DWORD。0 (ゼロ) 以外の値に設定します。

ドキュメント レベルのカスタマイズが無効になっていても、ユーザーは引き続きドキュメントを開いて変更を加えることができます。ただし、アセンブリ内のコードは実行されません。ドキュメント レベルのカスタマイズがコードを実行できるようにするには、両方の Disabled エントリを 0 に設定するか、レジストリ エントリを削除します。

参照

処理手順

方法 : Office ソリューションを配置する (2003 システム)

方法 : マネージ コード拡張機能をドキュメントから削除する (2003 システム)

方法 : オフライン使用のドキュメントを配置する (2003 システム)

概念

配置モデル (2003 システム)

ドキュメント レベルのカスタマイズの配置 (2003 システム)

Office ソリューションの配置 (2003 システム)

アプリケーション レベルのアドインの配置 (2003 システム)

その他の技術情報

Office ソリューションにおけるセキュリティ (2003 システム)

Office ソリューションのトラブルシューティング