設計サンプル: グループ作業サイト (SharePoint Foundation 2010)

 

適用先: SharePoint Foundation 2010

この記事では、実行可能な設計を実現する論理アーキテクチャ コンポーネントの実用的な実装について説明します。この記事は、次の設計サンプルと併せて使用してください。

• 設計サンプル: クラシック認証を使用するグループ作業サイト

• 設計サンプル: クレーム ベース認証を使用するグループ作業サイト

これらのモデルをダウンロードするには、「SharePoint Foundation 2010 design samples: Collaboration with classic authentication or with claims-based authentication (英語)」(https://go.microsoft.com/fwlink/?linkid=219157&clcid=0x411) (英語) を参照してください。

この記事の内容:

• 設計サンプルについて

• 全体的な設計目標

• サーバー ファーム

• ユーザー、領域、認証

• 管理サイト

• サービス

• アプリケーション プール

• Web アプリケーション

• サイト コレクション

• コンテンツ データベース

• 領域と URL

• 領域ポリシー

設計サンプルは、SharePoint Foundation 2010 の標準的な企業展開を示しています。設計サンプルは、ほぼすべての論理アーキテクチャ コンポーネントを採用しており、それらのコンポーネントが全体の設計にどのように組み込まれているかを示しています。2 つのサンプルは同じサービスとサイトを示していますが、認証方法が異なります。これらの認証方法は次のとおりです。

• クラシック認証: この設計サンプルは、サイトを Windows SharePoint Services 3.0 から SharePoint Foundation 2010 にアップグレードするためのパスを表しています。このサンプルはクラシック認証を組み込んでおり、サイトへのアクセスに Windows 認証方法を使用します。認証方法ごとに異なる領域が使用されます。SharePoint サイトには Windows 認証が使用されますが、フォーム ベース認証を使用して Windows 資格情報 (SharePoint Foundation 2010 に転送される) を収集するようにファイアウォールやゲートウェイ製品を構成できます。パートナー従業員アカウントが企業ディレクトリに追加されます。

• クレーム ベース認証: この設計サンプルは、新しいクレーム ベース認証モデルを組み込んでいます。複数の認証プロバイダーと認証の種類が 1 つの領域に実装されています。クレーム ベース認証は、フォーム ベース認証、SAML トークン ベース認証、および Windows 認証をサポートしています。この設計サンプルは、パートナー ディレクトリに対して直接に認証を行うために SAML トークン ベース認証を使用してパートナー企業を追加しています。パートナー従業員アカウントに対して複数のプロバイダー オプションがあります。

実際の認証要件に最も合っている設計サンプルを使用してください。

この記事では、これらのサンプルの設計目標について説明し、サンプルで示している論理アーキテクチャ コンポーネントを使用して、それらの目標をどのように達成するかを説明します。

設計サンプルについて

設計サンプルは、Fabrikam, Inc. という架空の会社の展開を示しています。このモデルで表現されているようなグループ作業サイトを 1 つ以上使用するソリューションを計画している場合は、このモデルを独自の設計の基礎として使用できます。

このモデルは、SharePoint Foundation 2010 の一般的な展開を示しており、次の 3 種類のグループ作業サイトを表します。

• チーム サイト

• セルフサービス サイト

• パートナーとのグループ作業用のサイト

設計サンプルは、ほぼすべての論理アーキテクチャ コンポーネントを採用しており、それらのコンポーネントが全体の設計にどのように組み込まれているかを示しています。この記事では、これらのサンプルの設計目標について説明し、モデルで示している論理アーキテクチャ コンポーネントを使用して、それらの目標をどのように達成するかを説明します。

これら異なる種類のグループ作業サイトの各々は、

• 異なったデータ特性を持つデータをホストします。

• 異なる使用プロファイルに従います。

• 異なる方法の権限管理が必要です。

したがって、モデルでの設計選択では、各アプリケーションのパフォーマンスとセキュリティを最適化することが目的となります。

チーム サイト

チーム サイトは、次の特性を持つ高度に構造化され管理されたグループ作業サイトを表します。

• 少数のトップレベル サイト コレクションがあり、これらのサイト コレクションは (セルフサービス サイトに比べて) 大量のデータを格納することを意図しています。

• チームごとにトップレベル URL に意味があります。

• サイトの階層、分類、およびカスタマイズに対して、さらなる検討が加えられます。

• 各チームのコンテンツは、個別のデータベースに置かれ、別々に管理できます。

セルフサービス サイト

セルフサービス サイトは、高度に管理されたチーム サイトの代わりになるものです。セルフサービス サイト管理を使用することで、ユーザーとチームが独自のサイト コレクションを作成できるようになります。それには、サーバーの全体管理でセルフサービス サイト管理を有効にします。この方法は、グループまたはコミュニティにサイトの作成を許可するときに最適です。また、サイトをホストしていて、ユーザーが詳細なプロセスを待たずにサイトを作成できるようにする場合にも適しています。

通常、セルフサービス サイトの特性は、高度に管理されたサイトとは異なります。たとえば、次のような特性が考えられます。

• 多数のトップレベル サイト コレクションがあります。

• サイト コレクションあたりのデータが少量です。

• URL が自動的に生成されても、通常は意味がありません。

セルフサービス サイトの実装を計画する際には、トレードオフがいくつかあることに留意してください。以下に示すトレードオフは、セルフサービス サイトの管理方法に影響を及ぼします。

• 高度な分類法を実装せず、サイト横断的な編成原則なしに随意にサイトが作成されます。新しい各サイトがサイト コレクションなので、セルフサービス サイト間でテンプレートとナビゲーションを共有できません。

• 各サイト コレクションでの検索は当のサイト コレクションのコンテンツだけを対象とするので、サイト コレクション横断的に検索結果が集計されることはありません。

• サイト コレクションごとにサイズと用途が大きく異なる可能性があります。

• サイトが放置されやすくなります。

セルフサービス サイトの管理では、コンテンツ データベースの目標サイズに基づいてコンテンツ記憶域を管理すると共に、使用されなくなったサイトの定期的な削除が必要になることもあります。

セルフサービス サイト管理の実装方法の詳細については、「セルフサービス サイト作成をオン/オフする (SharePoint Foundation 2010)」を参照してください。

パートナーとのグループ作業用のサイト

パートナー Web アプリケーション、パートナー会社および個人パートナーと安全にグループ作業するための外部から利用可能なサイトをホストします。このアプリケーションは、安全なグループ作業のためのサイトを従業員が簡単に作成できることを目的としています。パートナーがそのサーバー ファームでホストされる他の種類のコンテンツにアクセスすることはできません。領域とサービス アプリケーションの設計は、この目標の達成に注力しています。さらに、個々のサイト所有者が自分のサイトのアクセス許可を管理して、グループ作業に必要な参加者のみがアクセスできるようにします。

全体的な設計目標

このモデルは、何種類かのグループ作業アプリケーション (チーム サイト、セルフサービス サイト、およびパートナー サイト) 内での SharePoint Foundation 2010 の機能の実用的な実装を示しています。この記事では、各サイト アプリケーションの設計の実装について説明します。このモデルの主要な設計目標は以下のとおりです。

• 成長できる環境を設計するためのフレームワークを作ります。個々のグループ作業アプリケーションの設計上の決定により、他のアプリケーションの追加が妨げられることはありません。たとえば、初期の展開には、グループ作業チーム サイトだけが含まれている場合もあれば、パートナー サイトだけが含まれている場合もあります。同様の論理アーキテクチャ設計を使用することにより、初期グループ作業サイトの設計に影響を与えずに、ソリューションに他の種類のグループ作業サイトを追加できます。つまり、環境の使用を制限するような設計上の選択は、設計に組み込まれません。

• 異なるグループ作業アプリケーション内のコンテンツのセキュリティを低下させることなく、さまざまなクラスのユーザーにアクセスを提供します。認証プロバイダーの異なる別々のネットワーク領域 (内部と外部の両方) のユーザーが、グループ作業に参加できます。また、ユーザーがアクセスできるのは、ユーザーによるアクセスを想定したコンテンツだけです。同様の論理アーキテクチャ設計に従うことにより、異なった場所で作業する別々の目標を持ったさまざまなユーザーにアクセスを提供する機会が生まれます。たとえば、初期設計で内部の従業員のアクセスだけを想定するとしても、同様の設計を使用することにより、リモートの従業員、パートナーの従業員、パートナー企業、または顧客に対しても、アクセスを提供する機会が生まれます。

• 設計をエクストラネット環境で使用できるようにします。サーバー ファームを境界領域ネットワークまたは任意のエクストラネット トポロジ内に安全に展開できるように慎重な設計選択を行えます。

この記事の残りの部分では、モデルに現れる各論理コンポーネントについて上位から下位へと順に説明し、モデルに適用される設計上の選択について説明します。この方法をとるのは、アプリケーションに基づいた論理アーキテクチャ コンポーネントのさまざまな構成方法を明らかにするためです。

サーバー ファーム

このモデルでは、5 つのサーバーから成るファームを示しています。ただし、このモデルは、単一のサーバーを含めて、任意のサイズのファームに実装できます。モデルのサーバー ファームは、5 つのサーバーから構成されています。サーバー ファームのトポロジは以下のとおりです。

• 2 台のフロントエンド Web サーバー

• 検索サーバーまたはサービス アプリケーション (オプション) 用の 1 台のアプリケーション サーバー

• 2 台のデータベース サーバー (クラスター化またはミラー化)

このモデルでは、次のことを示すことにより、SharePoint Foundation 2010 の論理アーキテクチャを示しています。

• すべてのサイトは、フロントエンド Web サーバー間でミラー化されています。

• ユーザーの直接アクセスから保護するために、サーバーの全体管理 Web サイトはアプリケーション サーバーにインストールされています。

実際は、サーバー コンピューターの数とサーバー ファームのトポロジは、必要に応じて容量を増やし、パフォーマンスを向上させるためには意味がありますが、論理アーキテクチャにとっては重要でありません。論理アーキテクチャは、サーバー ファームのトポロジとは別に設計できます。パフォーマンスと容量の計画プロセスは、パフォーマンスと容量の目標に合わせてサーバー ファームのサイズを決めるために役立ちます。詳細については、「パフォーマンスと容量のテスト結果と推奨事項 (SharePoint Foundation 2010)」を参照してください。

ユーザー、領域、認証

SharePoint Foundation 2010 で Web アプリケーションを作成する場合、クレーム ベース認証またはクラシック モード認証を選択する必要があります。認証モードによって、アカウントが SharePoint Foundation 2010 で内部的にどのように使用されるかが決まります。この 2 つの認証の概要を次の表に示します。

認証の種類	説明	推奨事項
クラシック モード認証	ユーザー アカウントは、SharePoint Foundation 2010 によって従来の Active Directory ドメイン サービス (AD DS) アカウントとして扱われます。サポートされる認証プロトコルは、Kerberos、NTLM、基本、ダイジェスト、および匿名です。 フォーム ベース認証はサポートされません。 1 つの領域について構成できる認証方法は 1 つだけです。	フォーム ベース認証が必須でない Windows SharePoint Services 3.0 から環境をアップグレードする場合は、クラシック モードが推奨されます。 アップグレードでクラシック モード認証を選択した場合、ユーザーの移行を実行する必要はありません。
クレーム ベース認証	ユーザー アカウントは、SharePoint Foundation 2010 によってクレーム ID として扱われます。Windows アカウントは自動的にクレーム ID に変換されます。このモードでは、さらにフォーム ベース認証および信頼できる ID プロバイダーに対する認証もサポートされます。 1 つの領域について複数の認証方法を構成できます。	新しい SharePoint Foundation 2010 展開では、クレーム ベース認証が推奨されます。フォーム ベース認証が必須の Windows SharePoint Services 3.0 ソリューションをアップグレードする場合は、これが必要です。

この記事で説明している 2 つの設計サンプルは、この 2 つのオプションを表しています。以下のセクションでは、2 つの設計サンプルに認証がどのように組み込まれているのかを説明します。

クラシック モード認証設計サンプル

クラシック モード認証を使用する設計サンプルは、前のリリースで使用されていた従来型の認証アプローチ (1 種類につき 1 領域) を組み込んでいます。そのため、このサンプルは Windows SharePoint Services 3.0 から SharePoint Foundation 2010 にアップグレードするためのパスを提供しています。

クラシック モードではフォーム ベース認証がサポートされないので、その点は注意する必要があります。クラシック モード認証を使用する場合、認証されたすべてのアカウントが Active Directory ドメイン サービス (AD DS) 内にある必要があります。サイトにリモートからアクセスするユーザーについては、ファイアウォールやゲートウェイ製品でフォーム ベース認証を使用して、SharePoint ファームに転送される Windows 資格情報を収集することを推奨します。

クラシック モード サンプルは、それぞれ別々の領域に割り当てられる 3 つの異なるユーザー クラスを示しています。各 Web アプリケーション内には、利用可能な領域名 (既定、イントラネット、インターネット、ユーザー設定、またはエクストラネット) のいずれかを使用して、最大 5 つの領域を作成できます。

次の表は、クラシック モード設計サンプルで規定している領域とユーザーと認証の種類を示しています。

領域	ユーザー	認証
イントラネット	内部の従業員	NTLM または Kerberos
既定	リモートの従業員	NTLM または Kerberos (ファイアウォールやゲートウェイ製品でフォーム ベース認証を使用して資格情報を収集および転送する)
エクストラネット	個人パートナー	NTLM または Kerberos (ファイアウォールやゲートウェイ製品でフォーム ベース認証を使用して資格情報を収集および転送する)

クレーム ベース認証設計サンプル

SharePoint Foundation 2010 の新しい展開では、クレーム ベース認証が推奨されます。フォーム ベース認証が必須の Windows SharePoint Services 3.0 ソリューションをアップグレードする場合は、クレーム ベース認証が必要です。クレーム ベース認証では、Windows の標準の認証方法がサポートされるだけでなく、Windows Live ID、Active Directory フェデレーション サービス (AD FS) 2.0、SAML トークンおよび WS Federation プロトコルをサポートするサード パーティの ID プロバイダーなど、他のディレクトリに対する認証も行えます。

クレーム ベース認証設計サンプルでは、グループ作業ファームでクレーム ベース認証が使用されています。クレーム ベース認証では、同じ領域で複数の種類の認証を使用できます。設計サンプルでは、すべての種類の認証に既定領域を使用しています。次の表は、グループ作業ファーム用にサンプルで規定している領域とユーザーと認証の種類を示しています。

領域	ユーザー	認証
イントラネット	内部の従業員とリモートの従業員	AD DS (またはフォーム ベース認証または SAML 認証を使用する LDAP ストア)
既定	個人パートナー	SAML 認証を使用する Windows Live、またはフォーム ベース認証を使用する SQL Server データベース
エクストラネット	パートナー企業	SAML 認証を使用する信頼できるパートナー ID プロバイダー

設計サンプルでは、チーム サイトおよびセルフサービス サイトには従業員 (ネットワークの内部にいるか外部にいるかにかかわらず) だけがアクセスできるようになっています。設計サンプルは、内部でも外部でも使用できる URL を 1 つだけ (SSL を使用して) 実装しています。AD DS アカウントが使用されています。必要なら、フォーム ベース認証または SAML で LDAP を使用できます。これには追加の構成が必要です。

設計サンプルでは、パートナー Web アプリケーションはパートナーの従業員およびパートナー会社がアクセスできるエクストラネット サイトを表しています。このシナリオでクレーム ベース認証を使用するには、1 つ以上の外部 Security Token Service (STS) を使用するように信頼を構成する必要があります。これは次のアプローチのどちらかを使用して提供できます。

• 外部 STS を信頼するように SharePoint ファームを構成できます。たとえば、Windows Live と関連付けられた STS (個人パートナーの認証用) や、パートナー会社にある STS (パートナー ディレクトリに対する直接の認証用) です。

• 外部 STS を信頼するように企業環境内の STS を構成できます。この関係は 2 つの組織の管理者が明示的に確立する必要があります。このシナリオにおいて、SharePoint ファームは自社の企業環境にある STS のみを信頼するように構成されます。この内部 STS は、外部 STS から受け取ったトークンを検証し、パートナーのユーザーによる SharePoint ファームへのアクセスを可能にするトークンを発行します。これが推奨アプローチです。

パートナーを認証するためにクレーム ベース環境を実装する代わりに、フォーム ベース認証を使用し、別のストア (データベースなど) を使ってこれらのアカウントを管理するという方法もあります。

クレーム ベース認証環境の実装方法の詳細については、ホワイト ペーパー『Claims-based Identity for Windows: Technologies and Scenarios (英語)』(https://go.microsoft.com/fwlink/?linkid=196776&clcid=0x411) (英語) を参照してください。

領域

領域を設計するときには、いくつかの重要な決定が展開の成功を左右します。これらの決定事項の中に、次の領域の設計と構成に関する決定があります。

• 既定領域

• 外部アクセス用の領域

以下のセクションでは、モデルに組み込まれている決定事項について説明します。

既定領域の構成要件

最も慎重な考慮を要する領域は既定領域です。SharePoint Foundation 2010 は既定領域の構成方法に以下の要件を設けています。

• ユーザーの要求を領域と関連付けることができない場合は、既定領域の認証とポリシーが適用されます。したがって、既定領域は最も安全な領域である必要があります。

• 管理用電子メールは、既定領域へのリンクを付けて送信されます。その一例が、クォータ制限に近づいているサイトの所有者に対する電子メール メッセージです。したがって、これらの種類のメッセージや通知を受信するユーザーは、既定領域を通じてリンクにアクセスできる必要があります。このことは、サイト所有者にとって特に重要です。

• ホスト名付きサイト コレクションは、既定領域を経由してのみ利用できます。ホスト名付きサイト コレクションにアクセスするすべてのユーザーには、既定領域を経由したアクセスが必要です。

エクストラネット環境用の領域を構成する

エクストラネット環境では、次の 2 つの理由から、領域の設計がきわめて重要になります。

• ユーザーの要求は、さまざまなネットワークから開始できます。モデルでは、ユーザーは内部ネットワーク、インターネット、およびパートナー会社から要求を開始します。

• ユーザーは複数の Web アプリケーションでグループ作業に参加できます。たとえば、内部の従業員とリモートの従業員が、すべての Web アプリケーション (チーム サイト、セルフサービス サイト、およびパートナー Web) でコンテンツを投稿および管理する可能性があります。

エクストラネット環境では、次の設計原則に従ってください。

• 複数の Web アプリケーションにまたがる領域は、互いにミラー化されるように構成します。認証の構成と対象ユーザーは、同じである必要があります。ただし、領域に関連付けられたポリシーは Web アプリケーション間で異なっていてもかまいません。たとえば、イントラネット領域は、どの Web アプリケーションでも同じ従業員に使用するようにします。つまり、イントラネット領域をある Web アプリケーションで内部の従業員用に構成し、別の Web アプリケーションでリモートの従業員用に構成することはしません。

• 各領域および各リソースについて代替アクセス マッピングを適切かつ正確に構成します。

設計サンプルでは、各 Web アプリケーションの既定領域はまったく同じになるように構成されています。さらに、他の領域は必要に応じてすべての Web アプリケーションでまったく同じになるように構成されています。

代替アクセス マッピングは、領域の作成時に自動的に作成されます。しかし、プロキシ サーバーまたはゲートウェイ製品を使用して、インターネットから利用できるサイトを作成する場合は、領域ごとに代替アクセス マッピング エントリを追加する必要があります。これにより、内部ネットワークの外のユーザーに返される URL を、ユーザーが各自の領域のコンテキストに従って確実に利用できるようになります。

複数の Web アプリケーションにまたがる領域が互いにミラー化されていない場合は、外部リソースへのリンクが適切でないと、以下のリスクが生じます。

• サーバー名、ドメイン ネーム システム (DNS) 名、および IP アドレスが、内部ネットワークの外に公開される可能性があります。

• ユーザーが Web サイトなどのリソースにアクセスできない可能性があります。

管理サイト

モデルでは、サーバーの全体管理サイトがアプリケーション サーバーにホストされています。これにより、サーバーの全体管理サイトへのユーザーの直接のアクセスが防止されます。パフォーマンスのボトルネックやセキュリティの低下によってフロントエンド Web サーバーの可用性が影響を受けても、サーバーの全体管理サイトは利用可能なままです。また、サーバーの全体管理サイトは専用のアプリケーション プールおよび Web アプリケーションの内部にホストされています。

管理サイト用の負荷分散される URL については、モデルでもこの記事でも明示していません。推奨事項は以下のとおりです。

• 管理 URL でポート番号を使用する場合は、標準以外のポートを使用します。URL には既定でポート番号が含まれています。顧客向け URL でポート番号を使用することは、通常、ありませんが、管理サイトにポート番号を使用すると、これらのサイトへのアクセスを標準以外のポートに制限することにより、セキュリティを強化できます。

• 管理サイト用に個別の DNS エントリを作成します。

サービス

モデルで示しているサービス アーキテクチャは、SharePoint Foundation 2010 に含まれている 2 つのサービス アプリケーションのみを表現しています。2 つのサービス グループ (赤い枠線および青い点線の枠線で表現されている) は、与えられている例では必須ではありません。なぜなら、これらには同じ 2 つのサービス アプリケーションが含まれているからです。しかし、パートナー Web サイト用にどのサービス アプリケーションが必要なのかを検討し、それに応じて 2 つのサービス アプリケーションを構成してください。考慮すべきオプションとしては次のものがあります。

• パートナー Web サイト用に Business Data Connectivity Service アプリケーションの別個のインスタンスが必要かどうかを検討します。それが必要であれば、パートナー サイト用にこのサービス アプリケーションをパーティション分割モードで展開することを検討してください。こうすると、パートナーがパートナー サイト全体のデータにアクセスすることはなくなります。

• サード パーティの会社が SharePoint Foundation 2010 用のサービス アプリケーションを開発できます。それらのアプリケーションを使用する場合は、すべてのサイトで使用するのが適切かどうかを判断してください。

アプリケーション プール

通常は、個別の インターネット インフォメーション サービス (IIS) アプリケーション プールを実装することにより、サイト間のプロセス分離が実現されます。アプリケーション プールを使用すると、複数のサイトが同じサーバー コンピューターで動作しながら、独自のワーカー プロセスと ID を保持することができます。そのため、攻撃者があるサイトの弱点を悪用してサーバーにコードを送り込み、他のサイトを攻撃する危険性が小さくなります。

実際上は、以下のシナリオで専用のアプリケーション プールを使用することを検討してください。

• 認証コンテンツを匿名コンテンツと区別する。

• 外部のパートナーや顧客とのグループ作業を主目的とするサイトを分離する。これにより、外部アカウントを 1 つのアプリケーション プール内のサイトに分離する。

• サイトの作成と管理およびコンテンツに関するグループ作業をユーザーが自由に行えるサイトを分離する。

モデルではアプリケーション プールを以下のように使用しています。

• 管理サイトは、専用のアプリケーション プールでホストされます。これは SharePoint Foundation 2010 の要件です。

• すべてのサービス アプリケーションが単一のアプリケーション プールに展開されます。サービス アプリケーションをどうしても別々のアプリケーション プールに展開しなければならない理由がない限り、これが推奨構成です。すべてのサービス アプリケーションに 1 つのアプリケーション プールを使用すれば、パフォーマンスが最適化され、管理するアプリケーション プールの数を減らすことができます。

• 内部グループ作業サイト (チーム サイトとセルフサービス サイト) は、1 つのアプリケーション プールでホストされます。

• パートナー Web アプリケーションは、専用のアプリケーション プールでホストされます。

Web アプリケーション

Web アプリケーションは、SharePoint 2010 Productsによって作成され使用される IIS Web サイトです。各 Web アプリケーションは、IIS のそれぞれ異なる Web サイトによって表現されます。各 Web アプリケーションには一意のドメイン名を割り当てます。これはクロスサイト スクリプト攻撃を防ぐのに役立ちます。

一般的に、専用の Web アプリケーションは次の目的で使用します。

• 認証コンテンツを匿名コンテンツから分離する。

• ユーザーを分離する。モデルでは、パートナー Web を専用の Web アプリケーションおよびアプリケーション プールでホストして、パートナーが内部グループ作業コンテンツにアクセスできないようにしています。

• 権限を適用する。専用の Web アプリケーションは、サーバーの全体管理の [Web アプリケーションのポリシー] ページを使用して権限を適用する機会をもたらします。たとえば、内部グループ作業サイトのポリシーを作成して、パートナー アカウントに対してアクセスを明示的に拒否できます。Web アプリケーションのポリシーは、Web アプリケーション内の個々のサイトまたはドキュメントに対して構成されたアクセス許可の有無に関係なく、適用されます。

• パフォーマンスを最適化する。サイトは、類似するデータ特性を持つ他のアプリケーションと共に Web アプリケーションに配置した場合の方が、パフォーマンスが高くなります。たとえば、セルフサービス サイトには、サイトの規模は小さいが数が多いというデータ特性があります。それに対し、チーム サイトには、数は少ないが規模が非常に大きいという傾向があります。これら 2 種類のサイトを別々の Web アプリケーションに配置することにより、データベースは特性の類似するデータで構成されるようになり、データベースのパフォーマンスが最適化されます。モデルでは、チーム サイトとセルフサービス サイトは、固有のデータ分離要件を持たず、同じアプリケーション プールを共有しています。それにもかかわらず、チーム サイトとセルフサービス サイトを別々の Web アプリケーションに配置することにより、パフォーマンスを最適化しています。

• 管理性を最適化する。別々の Web アプリケーションを作成すると、サイトとベータベースも別々になるため、異なったサイト制限 (ごみ箱、有効期限、およびサイズ) を実装し、異なったサービス レベル契約を結ぶことができます。たとえば、セルフサービス サイトのコンテンツが組織内で最も重要な種類のコンテンツでなければ、セルフサービス サイトの復元を急ぐ必要はないでしょう。こうすると、セルフサービス サイトを復元する前に、より重要なコンテンツを復元できます。モデルでは、セルフサービス サイトを別の Web アプリケーションに配置して、管理者が成長を他のアプリケーションより厳しく管理できるようにしています。

サイト コレクション

サイト コレクションは、論理アーキテクチャと情報アーキテクチャの橋渡しをするものです。モデルでのサイト コレクションの設計目標は、URL 設計の要件を満たすことと、コンテンツを論理的にグループ分けすることです。

URL デザインの要件を満たすために、Web アプリケーションにはそれぞれ単一のルートレベル サイト コレクションが含まれています。管理パスを使用して、トップレベル サイト コレクションの第 2 層が組み込まれています。URL 要件、および管理パスの使用の詳細については、後の「領域と URL」を参照してください。サイト コレクションの第 2 層より上位では、各サイトがサブサイトです。

次の図は、チーム サイトのサイト階層を示しています。

ルートレベル サイト コレクションの要件を考えると、設計上の決定の中心になるのはサイト コレクションの第 2 層です。モデルには、アプリケーションの性質に基づいた選択が組み込まれています。

セルフサービス サイト

モデルでは、セルフサービス サイトに http://sites という URL のトップレベル サイトが組み込まれています。管理パスが組み込まれており (ワイルド カードを使用した管理パスを使用)、そのためにユーザーが作成するサイトの数に制限はありません。管理パスより下位のすべてのサイトは、トップレベル サイトの作成に使用されたサイト テンプレートを継承する独立したサイト コレクションです。

セルフサービス サイトの詳細については、「サイトを作成するためのプロセスを計画する (SharePoint Foundation 2010)」を参照してください。

チーム サイト

チーム サイト アプリケーション内のサイト コレクションを設計するときは、組織での運用方法に基づいて限定された数のサイト コレクションを作成することをお勧めします。この方法では、SharePoint Foundation 2010 管理者によってサイト コレクションが作成されます。サイト コレクションが作成された後で、チームが必要に応じてサイト コレクション内にサイトを作成できます。

この方法では、チーム サイトの管理方法や成長の仕方に構造を提供する高度な分類法を実装する機会があります。サイト コレクションを共有するプロジェクトとチームがテンプレートやナビゲーションを共有する可能性も増えます。情報アーキテクチャの課題は、組織に適したサイト コレクションの第 2 層を作成することです。次の表は、さまざまな種類の組織に対する推奨事項を示しています。

組織の種類	推奨するサイト コレクション分類法
製品開発	開発中の製品ごとにサイト コレクションを作成します。参加チームがサイト コレクション内にサイトを作成することを許可します。 長期間の開発プロジェクトそれぞれについて、製品開発に参加する大規模チームごとにサイト コレクションを作成します。たとえば、設計者チーム、技術者チーム、およびコンテンツ開発者チームについて、それぞれ 1 つのサイト コレクションを作成します。
研究	長期研究プロジェクトごとに、サイト コレクションを作成します。 研究プロジェクトのカテゴリごとに、サイト コレクションを作成します。
高等教育機関	学部ごとにサイト コレクションを作成します。
県議会事務局	政党ごとにサイト コレクションを作成します。同じ政党を担当する職員は、テンプレートとナビゲーションを共有できます。 委員会ごとにサイト コレクションを作成します。または、全委員会用のサイト コレクションを 1 つ作成します。
企業法務を扱う弁護士事務所	企業クライアントごとにサイト コレクションを作成します。
製造	製品シリーズごとにサイト コレクションを作成します。

パートナー Web

パートナー Web は、範囲または期間が限定されたプロジェクトで、外部パートナーとのグループ作業に使用されることを目的としています。設計上、パートナー Web アプリケーション内のサイトは、他のサイトから参照されることを想定していません。パートナー Web アプリケーションには、以下の要件があります。

• パートナーとのグループ作業に使用するサイトを、プロジェクトの所有者が簡単に作成できる。

• パートナーやその他の参加者は、作業対象のプロジェクトだけにアクセスできる。

• 権限はサイト所有者によって管理される。

• あるプロジェクトからの検索結果により、他のプロジェクトからのコンテンツが公開されない。

• 使用されなくなったサイトを、管理者が簡単に発見し、削除できる。

これらの要件を満たすために、モデルにはプロジェクトごとに 1 つのサイト コレクションが組み込まれています。これにより、以下の利点が得られます。

• 個別のサイト コレクションが、プロジェクト間に適切なレベルの分離を提供します。

• セルフサービス サイト作成を実装できます。

コンテンツ データベース

コンテンツ データベースは、以下の 2 つの方法で設計に組み込むことができます。モデルには両方の方法が組み込まれています。

• 適切なサイズの警告しきい値を使用して、コンテンツ データベースの目標サイズを設定します。サイズが警告しきい値に達したら、新しいデータベースを作成します。この方法では、サイト コレクションは、サイズ目標のみに基づいて利用可能なデータベースに自動的に追加されます。

• サイト コレクションを特定のコンテンツ データベースに関連付けます。この方法では、1 つ以上のサイト コレクションを、他のデータベースとは別に管理できる専用のデータベースに配置できます。

サイト コレクションを特定のコンテンツ データベースに関連付ける場合は、次の方法を使用します。

• Windows PowerShell を使用して、特定のデータベースにサイト コレクションを作成します。

• 以下のデータベース容量設定を適用して、1 つのデータベースを単一のサイト コレクションだけに使用します。

  • [警告イベントが生成される前のサイト数] = 1

  • [このデータベースに作成できるサイトの最大数] = 1

• 次の手順を実行して、専用のデータベースにサイト コレクションのグループを追加します。

  1. Web アプリケーション内で、データベースを作成し、データベースの状態を [準備完了] に設定します。

  2. 他のすべてのデータベースの状態を [オフライン] に設定します。コンテンツ データベースがオフラインである間は、新しいサイト コレクションを作成できません。ただし、オフライン データベースの既存のサイト コレクションには、読み取り操作と書き込み操作の両方を実行できます。

  3. サイト コレクションを作成します。作成したサイト コレクションは、自動的にデータベースに追加されます。

  4. 他のすべてのデータベースの状態を [準備完了] に戻します。

チーム サイト

設計サンプルには、チーム サイト コレクションごとに専用のデータベースが組み込まれています。この方法では、バックアップ、復元、および移行用に各チームのデータベースを別々に管理できます。また、プロジェクトが完了したら、そのプロジェクトに関係するデータベースを簡単にアーカイブできます。設計サンプルでのデータベース設定は、サイト コレクションに対する 30 GB の制限に基づいています。実際の組織のチーム サイトに適した制限を選択してください。

セルフサービス サイト

セルフサービス サイトについては、モデルでは規模効率を得るためにデータベースを最大目標サイズまでに管理しています。この目標を実現するために以下の設定が構成されています。

• [サイト記憶域の最大サイズを次の値に制限する]   この設定は、サーバーの全体管理の [クォータ テンプレート] ページで構成するもので、サイトのサイズを制限します。

• [削除済みデータ バックアップ]   この設定は、[Web アプリケーションの全般設定] ページで構成するもので、削除済みデータ バックアップに割り当てられる追加の容量を決定します。

• [このデータベースに作成できるサイトの最大数]   この設定はデータベース作成時に構成します。前の 2 つの設定に指定する値から、サイト全体の許容サイズを計算します。次に、各データベースのサイズ目標に基づいて、データベースに収まるサイト数を決定します。

設計サンプルのサイズ設定例は、目標のデータベース サイズ 175 GB、目標の個人用サイト サイズ 1 GB に基づいて、以下のようになっています。

• サイトごとのサイト サイズ制限 = 1 GB

• データベースの目標サイズ = 175 GB

• 削除済みデータ バックアップ用に確保 = 15%

• サイトの最大数 = 180

• サイト レベルの警告 = 150

サイト レベルの警告値に達したら、新しいデータベースを作成します。新しいデータベースを作成した後、新しいセルフサービス サイトは、作成したデータベースと既存のデータベースに、いずれかのデータベースがサイトの最大数に達するまで交互に追加されます。

パートナー Web

セルフサービス サイトと同様、パートナー Web についても規模効率を得るためにデータベースを最大目標サイズまでに管理しています。

パートナー Web は専用の Web アプリケーションでホストされるため、作成されるサイトの種類に適したサイズ制限を設けることができます。設計サンプルのサイズ設定は、以下のようになっています。

• データベースの目標サイズ = 200 GB

• サイトごとの記憶域クォータ = 5 GB

• サイトの最大数 = 40

領域と URL

モデルは、企業展開の複数のアプリケーション間で URL を調整する方法を示しています。

設計目標

URL の設計上の決定には、以下の目標が影響します。

• URL 規則では、どの領域を通じてコンテンツにアクセスできるかを制限しません。

• 標準の HTTP ポートおよび HTTPS ポート (80 および 443) を、設計サンプルの全アプリケーションで使用できます。

• URL にポート番号は含まれません。実際に、運用環境でポート番号を使用することは、通常、ありません。

設計原則

これらの設計目標を達成するために、以下の設計原則が適用されます。

• ホスト名が付いたサイト コレクションは使用されません。ここで注意する必要があるのは、ホスト名が付いたサイト コレクションが、IIS のホスト ヘッダーとは異なることです。ホスト名が付いたサイト コレクションは、代替アクセス マッピングと連動しません。同じコンテンツに複数のドメイン URL を通じてアクセスするには、代替アクセス マッピング機能が必要です。このため、ホスト名が付いたサイトが使用されている場合、これらのサイトは既定領域からしか利用できません。

• 各アプリケーションには、単一のルート サイト コレクションが組み込まれています。これは、代替アクセス マッピングを使用するための要件です。Web アプリケーションに複数のルート サイト コレクションが必要で、ユーザー アクセスに既定領域のみ使用することを予定している場合は、ホスト名が付いたサイト コレクションが適切な選択肢となります。

• それぞれがトップレベル チームまたはトップレベル プロジェクトを表す、上位のサイト コレクションが複数含まれているアプリケーションについては (チーム サイトなど)、モデルでは管理パスを組み込んでいます。管理パスを使用すると、これらの種類のサイトの URL をより詳細に制御できます。

設計上の代償

設計目標を満たした結果、以下の代償が生じます。

• URL が長くなります。

• ホスト名が付いたサイト コレクションは使用されません。

負荷分散される URL を設計する

Web アプリケーションを作成するときに、アプリケーションに割り当てる負荷分散される URL を選択する必要があります。また、Web アプリケーション内に作成する領域ごとに、負荷分散される URL を作成する必要があります。負荷分散される URL には、プロトコル、スキーム、ホスト名、およびポートが含まれます。負荷分散される URL は、すべての Web アプリケーションおよび領域にわたって一意である必要があります。このため、各アプリケーション、および各アプリケーション内の各領域に、設計サンプル全体にわたって一意な URL が必要です。

内部グループ作業サイト

2 種類の内部グループ作業サイトのそれぞれに一意な URL が必要です。設計サンプルでは、イントラネット コンテンツの対象ユーザーは内部の従業員とリモートの従業員です。クレーム認証設計サンプルでは、従業員は内部にいるかリモートにいるかに関係なく、これらのアプリケーションのそれぞれについて同じ URL を使用しています。この方法では、SharePoint 設計にセキュリティ レイヤーが 1 つ追加されますが (すべてのトラフィックが SSL)、ファイアウォールやゲートウェイ製品を通じてリモート トラフィックと共に内部トラフィックをルーティングするか、スプリット DNS 環境をセットアップして内部の要求を内部ネットワーク内で解決することが必要です。

クラシック認証設計サンプルでは、内部の従業員とリモートの従業員とで URL が異なります。次の表は、クラシック認証設計サンプルにおいて、内部の従業員とリモートの従業員が各アプリケーションへのアクセスに使用する URL を示しています。

アプリケーション	内部の従業員の URL	リモートの従業員の URL
チーム サイト	http://teams	https://teams.fabrikam.com
セルフサービス サイト	http://sites	https://sites.fabrikam.com

パートナー Web

設計サンプルでは、パートナー Web サイトに内部の従業員、リモートの従業員、およびパートナーの従業員がアクセスします。クレーム ベース認証設計サンプルでは、それぞれのユーザーが認証方法に関係なく、いずれも同じ URL を入力します。クラシック認証設計サンプルでは、ユーザーの種類によって、それぞれ異なる URL を入力します。リモートの従業員とパートナーの従業員は、どちらも外部から SSL (HTTPS) を使用してパートナー Web サイトにアクセスしますが、別々の領域を使用する利点を活かすには、それぞれのグループに異なる URL が必要です。それらの利点は、異なる認証方法と異なる領域ポリシーです。次の表は、クラシック認証設計サンプルにおいて、内部の従業員、リモートの従業員、およびパートナーがパートナー Web サイトへのアクセスに使用する URL を示しています。

領域	URL
内部の従業員の URL	http://partnerweb
リモートの従業員の URL	https://remotepartnerweb.fabrikam.com
パートナーの URL	https://partnerweb.fabrikam.com

明示的な管理対象パスとワイルド カードを使用した管理対象パスを URL パスに使用する

管理パスを定義することにより、Web アプリケーションの URL 名前空間のどのパスをサイト コレクションに使用するかを指定できます。1 つのサイト コレクション、または複数のサイト コレクションが、ルート サイトより下位の特定のパスに存在することを指定できます。管理パスなしの場合、ルート サイト コレクションより下位に作成されるすべてのサイトは、ルート サイト コレクションに属します。

作成できる管理パスには、次の 2 種類があります。

• 明示的な管理対象パス   割り当てた明示的な URL を持つサイト コレクション。明示的な管理対象パスは、単一のサイト コレクションに適用されます。ルート サイト コレクションの下位には、明示的な管理対象パスを多数作成できます。この方法で作成されるサイト コレクションの URL の一例は、http://team/team1 です。明示的なパスを追加するたびにパフォーマンスへの悪影響が大きくなります。そのため、明示的な管理対象パスを使用して作成するサイト コレクションの数は 20 個ほどに制限することをお勧めします。

• ワイルド カードを使用した管理対象パス   URL に追加されるパス。このパスは、パス名の直後に指定されるすべてのサイトが、固有のサイト コレクションであることを示します。通常、この方法はセルフサービス サイト作成をサポートするアプリケーションに使用されます。この方法で作成されるサイト コレクションの URL の一例は、http://sites/selfservice/site1 です。

以下のセクションで説明するように、設計サンプルには両方の種類の使用が組み込まれています。

明示的な管理対象パス

設計サンプルには、現在のところ、明示的な管理対象パスの使用は組み込まれていません。次の表には、クラシック認証を使用している Fabrikam のイントラネット サイトの URL の例が記載されています。従業員の内部アクセスとリモート アクセスで URL が異なります。

内部の従業員 (イントラネット領域)	リモートの従業員 (既定領域)
http://fabrikam	https://intranet.fabrikam.com
http://fabrikam/hr	https://intranet.fabrikam.com/hr
http://fabrikam/facilities	https://intranet.fabrikam.com/facilities
http://fabrikam/purchasing	https://intranet.fabrikam.com/purchasing

この例で、ルート サイト コレクション http://fabrikam は、イントラネットの既定のホーム ページを表しています。このサイトはユーザーのコンテンツをホストできます。パスの次のサイト (たとえば、http://fabrikam/hr と http://fabrikam/facilities) は、明示的な管理対象パスです。

ワイルド カードを使用した管理対象パス: チーム サイト、セルフサービス サイト、パートナー Web

チーム サイト、セルフサービス サイト、およびパートナー Web アプリケーションには、ワイルド カードを使用した管理対象パスの使用が組み込まれています。ワイルド カードを使用した管理対象パスは、ユーザーによる各自のサイト コレクションの作成を可能にするアプリケーション、および多数のサイト コレクションが含まれている Web アプリケーションに適しています。ワイルド カードを使用した管理対象パスは、ワイルド カードの後の項目がサイト コレクションのルート サイトであることを示しています。

チーム サイト

チーム サイト アプリケーションでは、各チーム サイト コレクションにワイルド カードを使用した管理対象パスが使用されます。健全な運営のためには、トップレベル チーム サイトの数は、扱いやすい数を超えないよう維持することをお勧めします。また、チーム サイトの分類法は、組織の活動状況に適したものである必要があります。

クラシック認証設計サンプルでは、ワイルド カードを使用した管理対象パスの使用によって URL は次の表のようになります。

内部の従業員 (イントラネット領域)	リモートの従業員 (既定領域)
http://teams/sites/team1	https://teams.fabrikam.com/sites/team1
http://teams/sites/team2	https://teams.fabrikam.com/sites/team2
http://teams/sites/team3	https://teams.fabrikam.com/sites/team3

この例で、ルート サイト コレクション http://team は、必ずしもユーザーのコンテンツをホストしません。

セルフサービス サイト

モデルでは、セルフサービス サイトにワイルド カードを使用した管理対象パスとして /selfservice (http://sites/selfservice) が含まれています。

これによって URL は次の表のようになります。

内部 (イントラネット領域)	リモートの従業員 (既定領域)
http://sites/selfservice/site1	https://sites.fabrikam.com/selfservice/site1
http://sites/selfservice/site2	https://sites.fabrikam.com/selfservice/site2
http://sites/selfservice/site3	https://sites.fabrikam.com/selfservice/site3

パートナー Web

パートナー Web は、外部のパートナーとグループ作業するためのサイトを、従業員が簡単に作成できることを目的としています。この目標を支援するために、セルフサービス サイト作成が可能になっています。

クラシック認証設計サンプルでは、パートナー Web アプリケーションにワイルド カードを使用した管理対象パスとして /sites (http://partnerweb/sites) が含まれています。これによって URL は次の表のようになります。

内部の従業員 (イントラネット領域)	リモートの従業員 (既定領域)
http://partnerweb/sites/project1	https://remotepartnerweb.fabrikam.com/sites/project1
http://partnerweb/sites/project2	https://remotepartnerweb.fabrikam.com/sites/project2
http://partnerweb/sites/project3	https://remotepartnerweb.fabrikam.com/sites/project3

パートナーの参加者は、次の表に示す URL を使用してパートナー Web サイトにアクセスできます。

パートナー (エクストラネット領域)
https://partnerweb.fabrikam.com/sites/project1
https://partnerweb.fabrikam.com/sites/project2
https://partnerweb.fabrikam.com/sites/project3

AAM と DNS で URL を調整する

ファーム内のサイト URL ごとに代替アクセス マッピングを構成します。そうすることにより、Web 要求が確実に正しいサイトにマップされるようになります。負荷分散やリバース プロキシの技術を使用している環境では特にそうです。

次の表に、クラシック認証バージョンの論理アーキテクチャ設計サンプルに基づいて代替アクセス マッピングを作成または変更するために必要な情報を示します。

サイト	ホスト ヘッダー	領域	ポート	AAM パブリック URL
チーム サイト	teams	イントラネット	80	http://teams
teams.fabrikam.com	既定	443	https://teams.fabrikam.com
セルフサービス サイト	sites	イントラネット	80	http://sites
sites.fabrikam.com	既定	443	https://sites.fabrikam.com
パートナー Web	partnerweb	イントラネット	80	http://partnerweb
remotepartnerweb.fabrikam.com	既定	443	https://remotepartnerweb.fabrikam.com
partnerweb.fabrikam.com	エクストラネット	443	https://partnerweb.fabrikam.com

イントラネット アクセス用に http://teams などの単一名 URL を構成できます。これらの URL はクライアントによって解決されます。この解決は、クライアントの DNS サフィックス (fabrikam.com など) を付加し、そのサフィックスを持つ名前に関して DNS 参照を発行することによって行われます。たとえば、fabrikam.com ドメイン内のクライアント コンピューターが http://teams を要求する場合、このコンピューターは http://teams.fabrikam.com に関して DNS に要求を送ります。

完全修飾ドメイン名 (FQDN) ごとに A レコードを使用するように DNS を構成する必要があります。A レコードは、サイトをホストしている Web サーバーの負荷分散された IP アドレスを指します。一般的な運用展開では、サーバーは、DNS で静的に割り当てられた A レコードに加え、静的に割り当てられた IP アドレスを使用するように構成されます。

クライアント ブラウザーは、ロード バランサーの仮想 IP アドレスを受け取った後、ファーム内のフロントエンド Web サーバーとの通信を確立し、元の単一名 URL (http://teams) を使用して HTTP 要求を送ります。IIS と SharePoint 2010 Productsは、代替アクセス マッピングで構成された設定に基づいて (上記の表を参照)、これをイントラネット領域に対する要求と見なします。ユーザーが http://teams ではなく、https://teams.fabrikam.com を要求したとすると、IIS と SharePoint 2010 Productsは、代わりにこの FQDN を受け取ることになり、したがって、これを既定領域に対する要求と見なします。

複数のドメインを持つ環境では、サイトが置かれていないドメインの DNS に対して CNAME レコードを入力します。たとえば、Fabrikam ネットワーク環境に europe.fabrikam.com という第 2 のドメインが存在するとすれば、Europe ドメインでこれらのサイトについて CNAME レコードが入力されます。チーム サイトのイントラネット サイト (http://teams) の場合、europe.fabrikam.com ドメインに teams という CNAME レコードが追加されます。これは teams.fabrikam.com を指すものです。その後、クライアントの DNS サフィックスが DNS 参照要求に付加されると、Europe ドメインからの http://teams に対する要求で teams.europe.fabrikam.com の DNS 参照が発行され、この要求は CNAME レコードによって teams.fabrikam.com に向けられます。

領域ポリシー

Web アプリケーションのポリシーを作成して、Web アプリケーション レベルで権限を適用できます。ポリシーは、Web アプリケーション全体に対して、または特定の領域のみに対して定義できます。ポリシーによって権限が適用されるのは、Web アプリケーションまたは領域内のすべてのコンテンツです。ポリシーの権限は、サイトとコンテンツに対して構成された他のすべてのセキュリティ設定より優先されます。ポリシーはユーザーまたはユーザー グループに基づいて構成できますが、SharePoint グループに基づいて構成することはできません。

1 つの領域で複数の種類の認証が有効になっているグループ作業ファームのクレーム ベース認証設計サンプルではポリシーは使用されていません。ポリシーが実装されているのは、クラシック認証設計サンプルと、Windows 認証を規定しているクレーム ベース認証設計サンプルの公開ファームです。公開ファームでは、ポリシーの使用によって、サイトを管理するためにアクセスするユーザーと匿名ユーザーとの間にセキュリティ レイヤーが 1 つ追加されます。

設計サンプルには 1 つの例があります。それは内部グループ作業サイトへのパートナー アカウントのアクセスを拒否することです。