Excel Services ベスト プラクティス
最終更新日: 2010年4月14日
適用対象: SharePoint Server 2010
この記事の内容
セキュリティの脅威の軽減
Excel Services ユーザー定義関数 (UDF)
全般
ここでは、Excel Services の操作に関して推奨されるベスト プラクティスを紹介します。
セキュリティの脅威の軽減
匿名アクセスおよび情報開示
以下の設定の組み合わせでは、プロセス アカウントがアクセスできる共有内のあらゆるファイルに対して匿名ユーザー アクセスが与えられます。したがって、情報開示の可能性があるため、以下の設定の組み合わせはお勧めしません。
Microsoft SharePoint Foundation への匿名アクセスがオンになっている。
UNC 形式の信頼できる場所があり、[プロセス アカウント] がオンになっている。
注意
[プロセス アカウント] は、すべての信頼できる場所に影響を与えるグローバルな Excel Services 設定です。
プロセス アカウント オプションを表示するには
[スタート] メニューの [すべてのプログラム] をクリックします。
[Microsoft SharePoint 2010 製品] をポイントし、[SharePoint サーバーの全体管理] をクリックします。
[アプリケーション構成の管理] で、[サービス アプリケーションの管理] をクリックします。
[サービス アプリケーションの管理] ページで、[Excel Services アプリケーション] をクリックします。
[Excel Services アプリケーション] ページで、[グローバル設定] をクリックします。
[セキュリティ] セクションで、[ファイル アクセス方法] の下の [プロセス アカウント] オプションを確認します。
サービス拒否攻撃
Web サービスに対するサービス拒否攻撃で、攻撃者は Web サービスに対する非常に大きな個別の要求を生成します。その目的は、Web サービスの 1 つ以上の入力値の制限を悪用することです。
Microsoft インターネット インフォメーション サービス (IIS) 設定を使用して Web サービスの最大要求サイズを設定することをお勧めします。
system.web 要素内の httpRuntime 要素の maxRequestLength 属性を使用して、サーバーに大きなファイルを投稿するユーザーによって引き起こされるサービス拒否攻撃を防ぎます。既定のサイズは 4096 KB (4 MB) です。
詳細については、「<httpRuntime> Element」と「<maxRequestLength> Element」を参照してください。
呼び出し側アプリケーションと Web サービス コンピューターとの間のスニッフィング
呼び出し側アプリケーションと Excel Web Services が異なるコンピュータに展開されている場合、攻撃者は、ネットワーク トラフィックで呼び出し側アプリケーションと Web サービスとの間のデータ転送をリッスンすることができます。この脅威は、"スニッフィング" または "傍受" とも呼ばれます。
この脅威を軽減するために、次の処理を行うことをお勧めします。
Secure Sockets Layer (SSL) を使用して、クライアントとサーバーとの間のデータ転送を保護するためのセキュリティで保護されたチャネルをセットアップします。SSL プロトコルは、ネットワークへの物理アクセスを持つユーザーによるパケット スニッフィングからデータを保護するのに役立ちます。
Excel Web Services を使用するカスタム アプリケーションが限定的なネットワークで実行されている場合 (たとえば、Excel Web Services が企業内の Web フロントエンド コンピューターに展開されている場合) は、関連ネットワークを物理的に保護します。
詳細については、「Securing Your Network」と「SOAP Security (英語)」を参照してください。
Excel Services のトポロジ、スケーラビリティ、パフォーマンス、およびセキュリティについては、Microsoft SharePoint Server 2010 の「TechCenter」を参照してください。
スプーフィング
SSL を使用して、Web サービスのインターネット プロトコル (IP) アドレスおよびポートのハイジャックの脅威を軽減し、攻撃者が Web サービスに代わって要求を受信および返信するのを防ぐことをお勧めします。
複数のプロパティについて SSL 証明書が照合されます。プロパティの 1 つは、メッセージの発信元 IP アドレスです。攻撃者は、Web サービス SSL 証明書を持っていない場合、IP アドレスをスプーフィングできません。
詳細については、「Securing Your Network」を参照してください。
Excel Services ユーザー定義関数 (UDF)
厳密な名前の依存関係
場合によっては、ユーザー定義関数 (UDF) アセンブリは、共に展開される他のアセンブリに依存します。このような依存 DLL は、グローバル アセンブリ キャッシュ内にあるか、UDF アセンブリと同じフォルダーにある場合に正しく読み込まれます。
ただし、後者では、同じ名前を持つ別のアセンブリを Excel Calculation Services が既に読み込んでいる場合、読み込みが失敗する可能性があります (アセンブリに厳密な名前が付けられていないか、同じ名前を持つ別のバージョンが展開されて読み込まれているために失敗します)。
次のようなディレクトリ構造のシナリオについて考えます。
C:\Udfs\Udf01
Udf01 フォルダの内容 :
Udf01.dll
dependent.dll (厳密な名前が付けられていません)
Udf01.dll ファイルは dependent.dll ファイルに依存します。
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 ファイルと同じではありません。
以下のフローを前提とします。
Udf01.dll は最初に読み込まれる DLL です。Excel Calculation Services は、dependent.dll を探し、Udf01.dll の依存関係を読み込みます。この場合は dependent.dll です。
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 を使用します。