SharePoint セキュリティ: SharePoint 展開環境のセキュリティ保護の基礎
Brien Posey
経験の浅い管理者でも、Microsoft Office SharePoint Server 2007 は数時間で展開できます。ただし、基本の展開は機能していても、おそらくセキュリティが最適になるようには構成されていない可能性が高いでしょう。SharePoint Server 2007 は、簡単にインストールできますが、適切にインストールすることが難しいアプリケーションの 1 つです。
セキュリティをこれほどまで難しくしている原因は、SharePoint 2007 が万人向けの万能な統合製品として位置付けられているためです。SharePoint 2007 は Web アプリケーションですが、コラボレーション ツール、ドキュメント サーバー、または開発フレームワークであると考えることもできます。SharePoint の抽象的でカスタマイズしやすい性質が、セキュリティ保護を難しくしています。
おそらくご推察だと思いますが、SharePoint のセキュリティを確保する、魔法のようなソリューションはありません。すべての SharePoint 展開環境は一意であるため、画一的なソリューションは実用的ではありません。ただし、すべての展開に有効な基本的な方法があります。
SharePoint サイトを作成したことがある場合、SharePoint は、SharePoint サイト、サイト コレクション、リスト、ライブラリなどの作成に使用できるビルド ブロックを使用する、モジュラー型の製品となるように設計されていることをご存じだと思います。セキュリティについては、このモジュラー型の性質を利用できます。
考え方としては、SharePoint 展開環境の個々のコンポーネントのセキュリティ保護に重点を置きます。SharePoint がモジュラー型であるということは、通常、展開環境には何台もの SharePoint サーバーが必要になります。したがって、展開環境をセキュリティで保護する場合は、これらの個々のサーバーのセキュリティを確保する必要があります。
SQL Server
SharePoint のリストとライブラリに含まれるすべてのデータは、基盤となっている SQL Server データベースに格納されます。SharePoint の構成設定のほとんどが、この SQL Server データベースに格納されています。そこで当然、SQL Server を適切にセキュリティで保護することが不可欠になります。
小規模な組織では、サーバー ハードウェアのコストを抑えるために、SQL Server と SharePoint を 1 台のサーバーにインストールすることがよくあります。しかし、SQL Server と SharePoint を 1 台のコンピューターに展開することは、セキュリティとパフォーマンスのどちらから見ても、よい考えではありません。
IT セキュリティで最も基本的な概念の 1 つは、サーバーの攻撃対象領域を最小限に抑えることです。SQL Server と SharePoint が同じサーバーにインストールされている場合、このサーバーはかなり大きな攻撃対象領域を持つことになります。したがって、まず、SQL Server を専用のコンピューターで実行することをお勧めします。SQL Server 専用のサーバーを用意する予算がない場合は、サーバー仮想化を使用して SQL Server と SharePoint を分離することを検討してください。
また、未使用のサービスやコンポーネントを無効にすることもお勧めします。基本の SharePoint 展開環境では、SQL Server のデータベース エンジン、SQL Server エージェント、および SQL Server ブラウザー コンポーネントを使用します。より高度なインストールでは、フルテキスト インデックス作成、Analysis Services、または Reporting Services を使用する場合があります。
無効にする対象はどのようにしたら決定できるでしょうか。マイクロソフトでは、無効にする対象の選定に役立つ、SQL Server セキュリティ構成ツール (図 1 参照) を提供しています。このツールは、SQL Server の実装を分析し、使用されていないサービスやコンポーネントを無効にするように設計されています。SharePoint をセットアップして実行できる状態になったら、このユーティリティを実行します。
このツールにアクセスするには、サーバーの [スタート] ボタンをクリックし、[すべてのプログラム] をクリックします。次に、[Microsoft SQL Server 2005] をクリックし、[構成ツール] をクリックして、[SQL Server セキュリティ構成] をクリックします。
.png)
図 1 無効にするコンポーネントやサービスの特定に役立つ SQL Server セキュリティ構成ツール
また、SQL Server のセキュリティに使用する認証方法も、十分に検討して選定する必要があります。混在モードまたは Windows 認証モードを選択できますが、可能な限り Windows 認証を使用するように SQL Server を構成します。Windows モードでは、認証プロセスで Kerberos セキュリティ プロトコルが使用されるため、混在モードよりも高度なセキュリティが得られます。また、Windows 認証では、ドメイン ユーザー アカウントが使用されるため、Active Directory で実施しているパスワード ポリシーがそのまま適用されます。
サービス アカウント
SharePoint 2007 を展開するときに管理者が犯す最大のセキュリティの誤りは、サービス アカウントを適切に構成しないことです。SharePoint 2007 をインストールしたことがある場合は、展開および構成時に、サービス アカウントの指定が求められる場面が何度かあることをご存じだと思います。
管理者はたいてい、サービス アカウントを 1 つだけ作成して、これを SharePoint のインストール プロセス全体で使用しています。このようにインストールした SharePoint サーバーは機能しますが、これはセキュリティの観点からはリスクが高い方法です。
問題は、SharePoint にサービス アカウントを提供すると、指定のアカウントには、その時点のタスクを実行する権利が与えられることです。SharePoint では、その作業の実行に必要な最低限のアクセス許可しかアカウントに提供しません。しかし、展開時に同じサービス アカウントを何度も使用すると、そのアカウントを使用するたびに権利が追加されるため、過剰なアクセス許可が付与されたアカウントが生まれます。その結果、SharePoint サーバーに対して、このような過剰な権利を悪用して、サーバーを制御するようなコードが実行されるおそれがあります。
SharePoint で使用するアカウントを構成する方法については、さまざまな相反する情報が混在し、推奨されるベスト プラクティスを確認することさえ、困難になっています。それでも、基本的な SharePoint 展開を実行する場合は、少なくとも 5 つのアカウントを使用することをお勧めします。
また、SharePoint と SQL Server のインストール専用のユーザー アカウントを作成することもお勧めします。一般的に、SharePoint を展開する際には、管理者自身の個人アカウントまたはドメイン管理者アカウントがログインに使用されています。インストールに使用するアカウントには、セットアップ プロセスを完了するために、追加の権利が付与されるため、既存のアカウントを使用することは、セキュリティの観点では不適切です。
インストール専用のアカウントを使用する場合は、そのアカウントを各 SharePoint サーバーのローカルの Administrators グループのメンバーにする必要があります。また、アカウントが SQL Server インスタンスにログインできるように、SQL Server ログイン グループのメンバーにする必要もあります。
さらに、SQL Server の SQL Server Database Creator ロールと SQL Server Security Administrator ロールをアカウントに割り当てる必要もあります。これらのロールによって、データベースを作成および変更する権限と SQL Server のセキュリティを管理する権限が、アカウントに付与されます。専用のユーザー アカウントの使用をお勧めするのは、これらの特殊な権限が付与されるためです。
SharePoint のインストール専用のアカウント以外に、いくつか次のようなサービス アカウントを作成する必要があります。
データベース アクセス アカウント: SharePoint が SQL Server データベースとの通信に使用するアカウントです。
SharePoint Search サービス アカウント: SharePoint Search サービスで、コンテンツ インデックス ファイルのインデックス サーバーへの書き込みと、ファーム内に存在するクエリ サーバーへのインデックス情報のレプリケーションに使用するアカウントです。
コンテンツ アクセス アカウント: 特定の共有サービス プロバイダー内のコンテンツのクロールに使用されるアカウントです。場合によっては、複数のコンテンツ ソースを個別にクロールできるように、複数のコンテンツ アカウント アクセスを作成しなければならないことがあります。
アプリケーション プール サービス アカウント: IIS 内のワーカー プロセスで使用するアカウントです。プール内の Web アプリケーションは、SharePoint コンテンツ データベースにアクセスする手段が必要で、アプリケーション プール ID アカウントはこのプロセスを容易にします。
SQL Server サービス アカウント: SQL Server にもサービス アカウントが必要です。この場合も、専用のアカウントを使用します。
より高度な SharePoint 展開環境では、追加のサービス アカウントを使用しなければならない可能性があります。この記事の最後にある「関連コンテンツ」のセクションには、必要になる可能性がある他のサービス アカウントのいくつかについて詳細情報を提供する TechNet 記事へのリンクを掲載しています。
名前付け規則
SharePoint を展開する前に、さまざまなアカウントを作成しなければならないことは、おわかりいただけたと思います。滞りなく展開できるようにする秘訣は、サービス アカウントを作成する前に、名前付け規則を決めることです。
サービス アカウントの名前付け規則を確立する方法は複数ありますが、従うべき基本的なルールがいくつかあります。できる限り説明的な名前にし、指定した名前と各アカウントの目的を文書化するようにします。たとえば、SharePoint Search アカウントには、SPT_Search のような名前を付けることができます。
古い制限により、SharePoint の略称を使用しています。Windows では 100 文字を超えるユーザー名を使用できますが、以前はユーザー名が 16 文字以下に制限されていたことがありました。古いハードウェアやソフトウェアによって、長いユーザー名では予期しない問題が突然発生することがあります。このようなことはめったに起こりませんが、実際に発生しているので、短い名前を使用するのが無難です。
説明的なサービス アカウント名を使用することをお勧めしていて、その結果、確かに管理は楽になりますが、説明的な名前を使用することで最適なセキュリティが必ずしも得られるというわけではないことに注意してください。サービス アカウントは、通常のユーザー アカウントよりも多くの権限を持つため、ハッカーにとって格好の標的になります。また、サービス アカウントには、多くの場合、静的で変更されないパスワードが使用されています。このような場合は、サービス アカウントを偽装することを検討してください。偽装する場合は、サービス アカウントの名前と機能を必ず文書化します。
トラフィックを暗号化する
SharePoint の展開を計画する段階になると、管理者はサーバー アーキテクチャの設計に多くの時間を費やします。この際、見過ごされがちな要素の 1 つは、公開キー基盤 (PKI) です。SharePoint トラフィックを適切に暗号化するには、SharePoint の展開前に PKI が導入されている必要があります。また、SharePoint サーバーとエンド ユーザー間の HTTP トラフィックは、SSL によって暗号化 (HTTPS を使用) される必要があります。
同様に、SharePoint サーバー間のトラフィックも、IPSec を使用して暗号化する必要があります。どちらの暗号化も、証明書と基盤の PKI インフラストラクチャに依存しています。
この記事で紹介したセキュリティのベスト プラクティスは、決して包括的なものではありません。ですが、SharePoint インストールをできる限り安全なものにするうえでの確かな基盤として利用できます。
Brien Posey は、MVP であり、数千件の記事と数十冊の書籍を執筆している、フリーランスのテクニカル ライターです。彼の Web サイトのアドレスは brienposey.com (英語) です。