Excel Services のベスト プラクティス

  • [アーティクル]

このトピックでは、Excel Services を使用する際のベスト プラクティス推奨事項について説明します。

脅威の軽減

匿名アクセスと情報開示

以下の設定の組み合わせでは、プロセス アカウントがアクセスできる共有内の任意のファイルに匿名ユーザーがアクセスできるようになります。 したがって、情報が開示される恐れがあるため、以下の設定の組み合わせは推奨されません。

  • Microsoft SharePoint Foundation に対する匿名アクセスがオンになっている。
  • UNC の信頼できる場所があり、[プロセス アカウント] がオンになっている。

注:

[プロセス アカウント] は、すべての信頼できる場所に影響を与える Excel Services のグローバル設定です。

[プロセス アカウント] オプションを表示するには

  1. [ スタート] メニューで [ すべてのプログラム] をクリックします。
  2. [Microsoft SharePoint 2010 製品] をポイントし、[SharePoint サーバーの全体管理] をクリックします。
  3. [アプリケーション構成の管理] の下で、[サービス アプリケーションの管理] をクリックします。
  4. [サービス アプリケーションの管理] ページで、[Excel Services アプリケーション] をクリックします。
  5. [Excel Services アプリケーション] ページで、[グローバル設定] をクリックします。
  6. [セキュリティ] セクションで、[ファイル アクセス方法] の下に、[プロセス アカウント] オプションが表示されます。

サービス拒否攻撃

Web サービスに対するサービス拒否攻撃では、攻撃者は非常に大きい、それぞれ異なる要求を Web サービスに対して生成します。 その目的は、Web サービスの入力値の 1 つ以上の限界値を探ろうとすることです。

Microsoft インターネット インフォメーション サービス (IIS) の設定を使用して、Web サービスの最大要求サイズを設定することをお勧めします。

system.web 要素の中の httpRuntime 要素にある maxRequestLength 属性を使用して、サーバーに対して大きいファイルを送信することによって行われるサービス拒否攻撃を防止します。 既定のサイズは 4096 KB (4 MB) です。

詳細については、「httpRuntime> 要素」と「maxRequestLength 要素」を参照してください<。><

呼び出し元のアプリケーションと Web サービス コンピューターとの間のスニッフィング

呼び出し元のアプリケーションと Excel Web Services が異なるコンピューターに展開されている場合、攻撃者は、呼び出し元のアプリケーションと Web サービス間のデータ転送ネットワーク トラフィックを傍受することがあります。 この脅威は "スニッフィッング" または "盗聴" とも呼ばれます。

この脅威を軽減するために、以下のことをお勧めします。

  • SSL (Secure Sockets Layer) を使用してセキュリティで保護されたチャネルをセットアップし、クライアントとサーバー間のデータ転送を保護します。 SSL プロトコルは、ネットワークに物理的にアクセスしてパケットのスニッフィッングを行う攻撃者からデータを保護するために役立ちます。
  • Excel Web Services を使用するカスタム アプリケーションが閉じたネットワーク内で実行されている場合 (たとえば、Excel Web Services が企業内の Web フロントエンド コンピューターに展開されている場合) は、該当するネットワークを物理的に保護します。

詳細については、「ネットワークと SOAP セキュリティのセキュリティの保護」を参照してください。

Excel Services のトポロジ、スケーラビリティ、パフォーマンス、およびセキュリティについては、Microsoft SharePoint Server 2010 TechCenter を参照してください。

なりすまし

Web サービスのインターネット プロトコル (IP) アドレスおよびポートを乗っ取られる脅威を軽減するため、SSL を使用することをお勧めします。これは、攻撃者が要求を受け取って Web サービスの代わりに応答するようになる事態を防止するために役立ちます。

SSL 証明書は、いくつかのプロパティと照合され、そのうちの 1 つはメッセージが送信される IP アドレスです。 Web サービスの SSL 証明書がない場合、攻撃者は IP アドレスを偽装できません。

詳細については、「 ネットワークのセキュリティ保護」を参照してください。

Excel Services のユーザー定義関数 (UDF)

厳密な名前の依存関係

場合によっては、ユーザー定義関数 (UDF) アセンブリが、一緒に展開される他のアセンブリに依存していることがあります。 依存関係にあるこれらの DLL がグローバル アセンブリ キャッシュに入っている場合、または UDF アセンブリと同じフォルダーに入っている場合は、DLL の読み込みが成功します。

ただし、後者の場合、Excel Calculation Services で同じ名前の別のアセンブリが既に読み込まれている場合、読み込みが失敗する可能性があります。 (アセンブリに厳密な名前が付けられないため、または同じ名前の別のバージョンがデプロイされて読み込まれたため、失敗します)。

次のシナリオについて考えてみましょう。次のようなディレクトリ構成になっています。

  1. C:\Udfs\Udf01

    Udf01 フォルダーの内容は次のとおりです。

    • Udf01.dll
    • dependent.dll (厳密な名前が付いていない)

    Udf01.dll ファイルは dependent.dll ファイルに依存しています。

  2. C:\Udfs\Udf02

    Udf02 フォルダーの内容は次のとおりです。

    • Udf02.dll (Interop.dll に依存している)
    • dependent.dll (厳密な名前が付いていない)

    Udf02.dll ファイルは dependent.dll ファイルに依存しています。 Udf01.dll の依存関係と Udf02.dll の依存関係では、同じ名前が共有されています。 しかし、Udf02.dll の dependent.dll ファイルは、Udf01.dll の dependent.dll ファイルと同じではありません。

次のようなフローを想定します。

  1. Udf01.dllは、読み込まれる最初の DLL です。 Excel Calculation Services はdependent.dllを検索し、Udf01.dllの依存関係を読み込みます。この場合はdependent.dll。
  2. Udf02.dll は、Udf01.dll より後に読み込まれます。 Excel Calculation Services は、Udf02.dll が dependent.dll に依存していることを認識します。 しかし、"dependent.dll" という名前の DLL は既に読み込まれています。 したがって、Udf02.dll の dependent.dll ファイルは読み込まれず、現在読み込まれている dependent.dll ファイルが依存関係として使用されます。

この結果、Udf02.dll が必要とするオブジェクト (この例では、dependent.dll ファイル) がメモリに読み込まれていない状態になります。

名前の衝突を防止するため、依存関係にあるオブジェクトには厳密な名前を付け、一意の名前を使用することをお勧めします。

全般

マネージ コード DLL の名前

アセンブリの名前を確実に一意にするため、「Namespace Naming Guidelines」に従った完全修飾クラス名を使用してください。

たとえば、 のNamespace.ClassName代わりに を使用CompanyName.Hierarchichal.Namespace.ClassNameします。

関連項目

タスク

概念