次の方法で共有

Office ソリューションのセキュリティに関するベスト プラクティス (2003 システム)

  • [アーティクル]

更新 : 2007 年 11 月

対象

このトピックの情報は、指定された Visual Studio Tools for Office プロジェクトおよび Microsoft Office のバージョンにのみ適用されます。

プロジェクトの種類

  • ドキュメント レベルのプロジェクト

  • アプリケーション レベルのプロジェクト

Microsoft Office のバージョン

  • Microsoft Office 2003

詳細については、「アプリケーションおよびプロジェクトの種類別の使用可能な機能」を参照してください。

ドキュメント レベルのカスタマイズおよびアプリケーション レベルのアドインにおいてセキュリティ ポリシーを計画する場合は、次の事項を考慮してください。

セキュリティ ポリシーへの条件の追加

Microsoft .NET Framework では、主に 2 つの方法を使用してポリシーを配置します。

Windows インストーラ ファイルを使用すると、全体のポリシー レベル (一般にはエンタープライズまたはマシン) がエンド ユーザーのコンピュータにコピーされるため、ポリシー評価が予測しやすいものとなりますが、会社内の異なるグループが互いに独立してポリシーを発行したり、個人がポリシーに変更を加える必要がある場合には、競合が発生することがあります。

Caspol.exe を使用してポリシーを変更する場合、異なるユーザーが互いに独立してポリシーを更新できますが、異なるコード グループ間の影響が不明であるため、指定したポリシーの変更が目的の効果を実現するかどうかは保証されません。たとえば、ある部門が、特定のイントラネット サイトへの完全な信頼を付与するポリシーの変更を配置する場合、その部門では、そのサイトから来るすべてのコードは信頼できると見なします。しかし、別の部門が、そのサイトへのアクセスを拒否する Exclusive 属性を使用してポリシーを配置すると、コードは実行されません。Exclusive 属性の詳細については、「コード グループ属性を使用した管理」および「方法 : コード グループを exclusive または final レベルに設定する」を参照してください。

管理者は、ポリシーの更新方法を決定する際には、Windows インストーラ ファイルの予測可能性と Caspol.exe の柔軟性のバランスをとる必要があります。

Microsoft .NET Framework API を使用して、ポリシーを直接操作するマネージ コードを作成することもできますが、この方法でポリシーを正しく作成するのは難しいので、できる限り避けてください。

現在のポリシーの確認

アセンブリが実行しない場合は、そのアセンブリに割り当てられているアクセス許可を確認することによって、考えられる原因を調べることができます。Microsoft .NET Framework では、2 つの方法でアセンブリの現在のポリシーを確認できます。

これらのツールは、アセンブリに適用されるセキュリティ ポリシーを表示し、アセンブリの証拠が共通言語ランタイム (CLR: Common Language Runtime) のルールにどのようにマップされているかを示します。これによって、ポリシーが正しく設定されているかどうか、およびアセンブリが正しいコード グループに対応しているかどうかがわかります。この方法で明らかになる主な問題には、次のエラーが含まれます。

  • LocalIntranet になければならないネットワーク ルール (https://server/への完全信頼の割り当てなど) が、MyComputer ゾーンに追加されています。または、TrustedSites になければならないのに、LocalIntranet に追加されています。

  • ファイル名または URL にエラーがあります。

  • 目的のフォルダの下にあるすべてのファイルとサブフォルダをポリシーに含む必要があることを指定するアスタリスク (*) が、ディレクトリ パスに含まれていません。

詳細については、「Caspol.exe によるセキュリティ ポリシーの問題の解決」を参照してください。

エンタープライズの既定ポリシーの設定

Visual Studio では、エンタープライズが独自の既定ポリシーを定義できます。通常は、セキュリティ ポリシーをリセットすると、ポリシーは、Framework をインストールしたときの既定の設定に戻ります。エンタープライズ固有の既定ポリシーを使用すると、リセットによって、特定のエンタープライズによって定義された基本ポリシーが復元されます。たとえば、エンタープライズは、信頼できる発行者をエンタープライズ レベルに追加したり、Internet ゾーンからのすべてのコードをブロックしたりできます。

既定ポリシーへの復帰の詳細については、「方法 : Caspol.exe を使用して既定のセキュリティ ポリシー設定に戻すには」および「.NET Framework 構成ツール (Mscorcfg.msc)」を参照してください。既定のセキュリティ ポリシーの詳細については、「既定のセキュリティ ポリシー」を参照してください。

一般的な推奨事項

Office ソリューションのポリシーを決定する場合は、次のガイドラインを考慮してください。

  • 番号に頼らず、常に名前付きのコード グループを使用します (たとえば、1.1 ではなく、MyComputer_Zone を使用します)。ユーザーがグループの名前を変更することもあり得ますが (たとえば、Internet を MyComputer に変更)、番号の変更より、その可能性は低くて済みます。

  • ルールが適用されるコードは、できるだけ限定します。マシン レベルで All_Code グループにルールを追加しないでください。常に、Zone または Zones の下の別のサブグループにルールを追加します。不要なコードを管理するルールは使用しないことをお勧めします。

  • より広範囲に適用されるルールを最初に指定します。たとえば、発行者、サイト、ゾーンではなく、ゾーン、サイト、発行者の順に指定します。このように、特定のゾーンのルールは、特定のコードに適用でき、制限が必要かどうかがわかるまで、発行者のすべてのコードには適用されません。

  • LocalIntranet_Zone グループなど、親グループが存在しない場合は、親グループを再作成する必要があります。Nothing アクセス許可セットを使用して、この操作を行う必要があることに注意してください。Nothing アクセス許可セットは、コード グループを削除することによって管理者がオフにした既定のアクセス許可が適用されることを防ぎます。たとえば、管理者が LocalIntranet_Zone を削除すると、ローカル イントラネット コードのすべてが実行を停止します。コード グループを再作成し、Nothing アクセス許可セットを使用すると、以前存在しなかったアクセス許可は追加されません。

  • バッチ ファイルでポリシー変更の警告をオフにします。警告が開始時にオンであった場合は後で必ず再びオンにします。このように、バッチ ファイルは停止せずに、ユーザー入力を待ちます。この設定は、現在のユーザーだけでなく、すべてのユーザーに影響します。詳細については、「方法 : Caspol.exe を使用してポリシーの変更の警告を非表示にする」を参照してください。

  • Caspol.exe を使用する場合は、既定値に依存せずに、変更するポリシー レベル (エンタープライズ、マシン、またはユーザー) を明示的に指定します。既定値は、変更するポリシーに対して適切ではない場合があります。詳細については、「セキュリティ ポリシー レベル」を参照してください。

  • 新規のコード グループが追加されると予期せぬ動作を引き起こすため、どうしても必要な場合以外は Exclusive 属性または Level-Final 属性を使用しないでください。詳細については、「コード グループ属性」を参照してください。

参照

概念

Office ソリューションの実行に必要なセキュリティ条件 (2003 システム)

Office ソリューションに固有のセキュリティに関する考慮事項

その他の技術情報

一般的なセキュリティ ポリシー管理

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