設計サンプル: 企業展開 (SharePoint Server 2010)
適用先: SharePoint Foundation 2010, SharePoint Server 2010
トピックの最終更新日: 2017-01-18
この記事では、実行可能な設計を実現する論理アーキテクチャ コンポーネントの実用的な実装について説明します。この記事は、次の設計サンプルと併せて使用してください。
設計サンプル: クラシック認証を使用する企業ポータル
設計サンプル: クレーム ベース認証を使用する企業ポータル
これらのモデルをダウンロードするには、「SharePoint Server 2010 design samples: Corporate portal with classic authentication or with claims-based authentication (英語)」(https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x411) (英語) を参照してください。
この記事の内容
設計サンプルについて
全体的な設計目標
サーバー ファーム
ユーザー、領域、認証
サービス
作成と発行の代替策
管理サイト
アプリケーション プール
Web アプリケーション
サイト コレクション
コンテンツ データベース
領域と URL
領域ポリシー
設計サンプルは、Microsoft SharePoint Server 2010 の標準的な企業展開を示しています。設計サンプルは、ほぼすべての論理アーキテクチャ コンポーネントを採用しており、それらのコンポーネントが全体の設計にどのように組み込まれているかを示しています。2 つのサンプルは同じサービスとサイトを示していますが、認証方法が異なります。これらの認証方法は次のとおりです。
クラシック認証: この設計サンプルは、サイトを Microsoft Office SharePoint Server 2007 から Microsoft SharePoint Server 2010 にアップグレードするためのパスを表しています。このサンプルはクラシック認証を組み込んでおり、サイトへのアクセスに Windows 認証方法を使用します。認証方法ごとに異なる領域が使用されます。SharePoint サイトには Windows 認証が使用されますが、フォーム認証を使用して Windows 資格情報 (SharePoint Server 2010 に転送される) を収集するようにファイアウォールやゲートウェイ製品を構成できます。パートナー従業員アカウントが企業ディレクトリに追加されます。
クレーム認証: この設計サンプルは、新しいクレーム認証モデルを組み込んでいます。複数の認証プロバイダーと認証の種類が 1 つの領域に実装されています。クレーム認証は、フォーム ベース認証、SAML トークン ベース認証、および Windows 認証をサポートしています。この設計サンプルは、パートナー ディレクトリに対して直接に認証を行うために SAML トークン ベース認証を使用してパートナー企業を追加しています。パートナー従業員アカウントに対して複数のプロバイダー オプションがあります。
実際の認証要件に最も合っている設計サンプルを使用してください。
この記事では、これらのサンプルの設計目標について説明し、サンプルで示している論理アーキテクチャ コンポーネントを使用して、それらの目標をどのように達成するかを説明します。
設計サンプルについて
設計サンプルは、Fabrikam, Inc. という架空の会社の企業展開を示しています。この展開には 2 つのサーバー ファームが含まれています。1 番目のサーバー ファームは、企業イントラネットとパートナー Web サイトをホストします。2 番目のサーバー ファームは、企業 Web サイト (www.fabrikam.com) をホストします。このセクションの以下の部分では、これらのトップレベル サイトについて説明します。
イントラネット
企業イントラネットには、以下のサイトが含まれます。
公開イントラネット コンテンツ (たとえば、HRweb)
グループ作業チーム サイト
個人用サイト
これらは、いずれも従業員が日常的に使用するコンテンツ サイトおよびグループ作業サイトですが、個別に見ると、これらのアプリケーションはそれぞれ固有の種類のコンテンツを表しています。各種類のコンテンツには以下の違いがあります。
SharePoint Server 2010 の異なる機能を重視します。
異なったデータ特性を持つデータをホストします。
異なる使用プロファイルに従います。
異なる方法の権限管理が必要です。
したがって、これら各アプリケーションの設計選択では、各アプリケーションのパフォーマンスとセキュリティを最適化することが目的となります。
サービス アプリケーションの設計により、これら 3 つのアプリケーションの統合により以下の機能が提供されます。
アプリケーション間のナビゲーション
企業全体の検索
共有のプロファイル データとエンタープライズ メタデータ
以下の図は、企業イントラネットを構成する 3 つのアプリケーションを示しています。
.gif "イントラネット サイト")
図中の URL は、クラシック認証設計サンプルからのものです。
パートナー Web アプリケーション
パートナー Web アプリケーションは、パートナー会社および個人パートナーと安全にグループ作業するための外部から利用可能なサイトをホストします。このアプリケーションは、安全なグループ作業のためのサイトを従業員が簡単に作成できることを目的としています。パートナーがそのサーバー ファームでホストされる他の種類のコンテンツにアクセスすることは許可されません。領域とサービス アプリケーションの設計は、この目標の達成に注力しています。
設計サンプルでは、パートナー Web アプリケーションとイントラネット コンテンツが同一のファームによってホストされています。
企業インターネット サイト
企業インターネット サイトは、企業のインターネット プレゼンスです。コンテンツは、読み取り専用の権限を持つ匿名アクセスを構成することにより、顧客から利用可能になります。このアプリケーションの設計選択では、以下の要素が重要です。
コンテンツの分離: 顧客はそのサーバー ファームでホストされる他の種類のコンテンツにアクセスできません。
対象を絞った管理: 管理作業や作成作業を行うことによって Web サイトを管理する従業員には、認証されたアクセスが提供されます。
コンテンツ作成および発行のセキュリティ保護: パートナー Web アプリケーションのファーム A で、作成用の個別のサイト コレクションがホストされます。これにより、内部の従業員とリモートの従業員だけでなく、Web サイト開発やコンテンツ作成を専門とする編集パートナーとも、セキュリティ保護されたグループ作業とコンテンツ開発が可能になります。コンテンツの発行は、1 番目のファームの作成サイト コレクションから 2 番目のファームの運用サイト コレクションに自動的にコンテンツを発行するように構成されます。発行プロセスは、以下の図のようになります。
.gif "発行済みサイト")
全体的な設計目標
設計サンプルは、いくつかの一般的な種類のアプリケーションにおける SharePoint Server 2010 機能の実用的な実装を示しています。この記事では、各アプリケーションの設計の実装について説明します。設計サンプルの主要な設計目標は以下のとおりです。
最小限のサーバー ファームを使用して、企業で通常必要とされる一般的な種類の Web サイト (イントラネット サイト、エクストラネット サイト、およびインターネット サイト) をホストします。
成長できる環境を設計するためのフレームワークを作ります。個々のアプリケーションの設計上の決定により、他のアプリケーションの追加が妨げられることはありません。たとえば、初期の展開には、グループ作業チーム サイトだけが含まれている場合もあれば、イントラネットを構成する 3 つのアプリケーション (チーム サイト、個人用サイト、および公開イントラネット コンテンツ) だけが含まれている場合もあります。同様の論理アーキテクチャ設計を使用することにより、初期アプリケーションの設計に影響を与えずに、ソリューションにアプリケーションを追加できます。つまり、環境の使用を制限するような設計上の選択は、設計に組み込まれません。
異なる種類のサイト内のコンテンツのセキュリティを低下させることなく、複数のユーザー グループにアクセスを提供します。認証プロバイダーの異なる別々のネットワーク領域 (内部と外部の両方) のユーザーが、グループ作業に参加できます。また、ユーザーがアクセスできるのは、ユーザーによるアクセスを想定したコンテンツだけです。同様の論理アーキテクチャ設計に従うことにより、異なった場所で作業する別々の目標を持ったさまざまなユーザーにアクセスを提供する機会が生まれます。たとえば、初期設計で内部の従業員のアクセスだけを想定する場合、同様のデザインを使用することにより、リモートの従業員、パートナーの従業員、パートナー企業、および顧客に対しても、アクセスを提供する機会が生まれます。
設計をエクストラネット環境で使用できるようにします。サーバー ファームを境界領域ネットワークに安全に展開できるように慎重な設計選択が行われます。
この記事の残りの部分では、設計サンプルに現れる個々の論理コンポーネントについて上位から下位へと順に説明し、設計サンプルに適用される設計上の選択について説明します。この方法をとるのは、アプリケーションに基づいた論理アーキテクチャ コンポーネントのさまざまな構成方法を明らかにするためです。
サーバー ファーム
設計サンプルには、2 つのサーバー ファームの使用が組み込まれています。このセクションでは、企業環境に必要なサーバー ファームの数に影響するライセンス要件について説明します。また、設計サンプルに示すサーバー ファームのトポロジも記載します。
ライセンス要件
イントラネット コンテンツとインターネット サイトの両方をホストするには、少なくとも 2 台のサーバーが必要です。これはライセンス要件を満たすための必須条件です。
SharePoint Server 2010 には、次の 2 種類のサーバー ライセンスがあります。
Microsoft SharePoint Server 2010, Server License: グループ作業イントラネット コンテンツ用のライセンスです。このライセンスでは、クライアント アクセス ライセンス (CAL) を使用する必要があります。パートナーとのグループ作業に使用するサイトを作成する場合は、パートナーの従業員のために必要数の CAL を購入するようにしてください。
Microsoft SharePoint Server 2010 for Internet Sites: インターネット向け Web サイトのみを対象としたライセンスです。このライセンスに CAL は必要ありません。パートナーとのグループ作業に使用するサイトを作成する場合、追加の CAL を購入する必要はありません。ただし、自社の従業員だけを対象にしたサイトは作成できません。
注意
これらのライセンスを、同じサーバー コンピューターまたは同じサーバー ファームで併用することはできません。
ライセンス オプションから考ると、設計上の最も重要な選択は、パートナー Web アプリケーションをホストするファームを決定することです。設計サンプルでは、1 番目のファームでイントラネット コンテンツをホストし、2 番目のファームで企業インターネット サイトをホストしています。ライセンス条件に応じて、どちらのファームでもパートナー Web アプリケーションをホストできます。
2 つのファームを選択する場合、パートナー Web アプリケーションをホストするファームを決める際の一般的な設計指針は、以下のようになります。
グループ作業の性質: パートナー向けエクストラネット サイトの主な目的が、多くのパートナーに安全に情報を伝えることである場合は、インターネット サーバー ファームが最も経済的な選択です。それに対し、主な目的がパートナーの少数の従業員とグループ作業することである場合は、イントラネット サーバー ファームの方が優れた選択です。必要な役割に合わせてファームを最適化できるオプションを選択してください。
パートナーの従業員の数: パートナーの多数の従業員とグループ作業する場合、コストの最小化が重要であれば、Internet Sites ライセンスを使用してインターネット向けファームでグループ作業コンテンツと匿名コンテンツの両方を安全にホストできます。
設計サンプルでは、企業インターネット サイトの開発、ステージングなど、パートナー会社と集中的なグループ作業を行うことがパートナー Web アプリケーションの目的となっています。パートナー Web アプリケーションを 1 番目のファームに配置すると、2 つのファームをそれぞれの目的の用途 (グループ作業か、読み取り専用コンテンツか) に合わせて最適化できます。ただし、どちらのファームでもパートナー Web アプリケーションをホストできます。
設計サンプルには Microsoft Office Web Apps が含まれています。Office Web Apps には Microsoft Office 2010 クライアント ライセンスが必要です。つまり、Office Web Apps をパートナーが使用できるようにする場合は、パートナー用の Office 2010 クライアント ライセンスも購入する必要があります。
サーバー ファームのトポロジ
設計サンプルのサーバー ファームは、それぞれ 5 台のサーバーから構成されています。サーバー ファームのトポロジは以下のとおりです。
2 台のフロントエンド Web サーバー
1 台のアプリケーション サーバー
2 台のデータベース サーバー (クラスター化またはミラー化)
設計サンプルを見ると、SharePoint Server 2010 の論理アーキテクチャは以下のようになっています。
すべてのサイトは、フロントエンド Web サーバー間でミラー化されています。
ユーザーの直接アクセスから保護するために、サーバーの全体管理サイトはアプリケーション サーバーにインストールされています。
実際は、サーバー コンピューターの数とサーバー ファームのトポロジは、必要に応じて容量を増やし、パフォーマンスを向上させるためには意味がありますが、論理アーキテクチャにとっては重要でありません。論理アーキテクチャは、サーバー ファームのトポロジとは別に設計できます。パフォーマンスと容量の計画プロセスは、パフォーマンスと容量の目標に合わせてサーバー ファームのサイズを決めるために役立ちます。詳細については、「パフォーマンスと容量の管理 (SharePoint Server 2010)」を参照してください。
3 つ以上のファームへのスケーリング
ここに示した 2 つのファームでは足りないこともあるでしょう。専用ファームでホストすることが考えられるサイトには次のものがあります。
個人用サイト: 多数の従業員や学生を抱える組織の多くは、専用サービス ファームで個人用サイトをホストしています。
作成サイトとステージング サイト: 公開コンテンツが複雑または巨大である場合は、Microsoft SharePoint Server 2010 for Internet Sites ライセンスを使用して、これらのサイトを専用の単一サーバー ファームでホストする方が作成とステージングがうまく最適化されることがあります。たとえば、タグ付けしたメタデータが含まれているコンテンツを発行すると、サービスをファーム間で共有したり、サービスを多目的ファーム内の他の種類の Web アプリケーションの間でどのように共有するかを決定するなど、作成ファームと公開ファームの間でサービス設計サンプルの複雑さが増します。
パートナー サイト: セキュリティと分離の要件によっては、パートナーとのグループ作業のための専用ファームを設けるのが妥当なこともあります。そうすれば、内部専用のコンテンツと、外部パートナーとのグループ作業で開発されるコンテンツとが物理的に分離されます。
ユーザー、領域、認証
SharePoint Server 2010 で Web アプリケーションを作成する場合、クレーム ベース認証またはクラシック モード認証を選択する必要があります。認証モードによって、アカウントが SharePoint Server 2010 で内部的にどのように使用されるかが決まります。この 2 つの認証の概要を次の表に示します。
認証の種類 |
説明 |
推奨 |
クラシック モード認証 |
ユーザー アカウントは、SharePoint Server 2010 によって従来の Windows Active Directory アカウントとして扱われます。サポートされる認証プロトコルは、Kerberos、NTLM、基本、ダイジェスト、および匿名です。 フォーム ベース認証はサポートされません。 1 つの領域について構成できる認証方法は 1 つだけです。 |
フォーム ベース認証が必須でない Microsoft Office SharePoint Server 2007 から環境をアップグレードする場合は、クラシック モードが推奨されます。 アップグレードでクラシック モード認証を選択した場合、ユーザーの移行を実行する必要はありません。 |
クレーム ベース認証 |
ユーザー アカウントは、SharePoint Server 2010 によってクレーム ID として扱われます。Windows アカウントは自動的にクレーム ID に変換されます。このモードでは、さらにフォーム ベース認証および信頼できる ID プロバイダーに対する認証もサポートされます。 1 つの領域について複数の認証方法を構成できます。 |
新しい SharePoint Server 2010 展開では、クレーム ベース認証が推奨されます。フォーム ベース認証が必須の Office SharePoint Server 2007 ソリューションをアップグレードする場合は、これが必要です。 |
この記事で説明している 2 つの設計サンプルは、この 2 つのオプションを表しています。以下のセクションでは、2 つの設計サンプルに認証がどのように組み込まれているのかを説明します。
クラシック モード認証設計サンプル
クラシック モード認証を使用する設計サンプルは、前のリリースに組み込まれていた従来型の認証アプローチ (1 種類につき 1 領域) を組み込んでいます。そのため、このサンプルは Office SharePoint Server 2007 から SharePoint Server 2010 にアップグレードするためのパスを提供しています。
クラシック モードではフォーム ベース認証がサポートされないので、その点は注意する必要があります。クラシック モード認証を使用する場合、認証されたすべてのアカウントが Active Directory ドメイン サービス (AD DS) 内にある必要があります。サイトにリモートからアクセスするユーザーについては、ファイアウォールやゲートウェイ製品でフォーム ベース認証を使用して、SharePoint ファームに転送される Windows 資格情報を収集することを推奨します。
クラシック モード サンプルは、それぞれ別々の領域に割り当てられる 4 つの異なるユーザー クラスを示しています。各 Web アプリケーション内には、利用可能な領域名 (既定、イントラネット、インターネット、ユーザー設定、またはエクストラネット) のいずれかを使用して、最大 5 つの領域を作成できます。
次の表は、クラシック モード設計サンプルで規定している領域とユーザーと認証の種類を示しています。
.gif "ゾーン、ユーザー、および認証を示す表")
検索クロール アカウントは、NTLM 認証を使用して最低 1 つの領域にアクセスすることが必要です。ユーザーのための領域のいずれも NTLM を使用するように構成されていない場合は、NTLM 認証を使用するようにユーザー設定領域を構成してください。
クレーム ベース認証設計サンプル
SharePoint Server 2010 の新しい展開では、クレーム ベース認証が推奨されます。フォーム ベース認証が必須の Office SharePoint Server 2007 ソリューションをアップグレードする場合は、クレーム ベース認証が必要です。クレーム ベース認証では、Windows の標準の認証方法がサポートされるだけでなく、Windows Live ID、Active Directory フェデレーション サービス 2.0、SAML トークンおよび WS Federation プロトコルをサポートするサード パーティの ID プロバイダーなど、他のディレクトリに対する認証も行えます。
クレーム ベース認証設計サンプルでは、グループ作業ファームでクレーム ベース認証が使用されています。クレーム ベース認証では、同じ領域で複数の種類の認証を使用できます。設計サンプルでは、すべての種類の認証に既定領域を使用しています。次の表は、グループ作業ファーム用にサンプルで規定している領域とユーザーと認証の種類を示しています。
.gif "ゾーン、ユーザー、および認証を示す表")
設計サンプルでは、公開イントラネット コンテンツ サイト、チーム サイト、および個人用サイトには従業員 (ネットワークの内部にいるか外部にいるかにかかわらず) だけがアクセスできるようになっています。設計サンプルは、内部でも外部でも使用できる URL を 1 つだけ (SSL を使用して) 実装しています。Active Directory アカウントが使用されています。必要なら、フォーム ベース認証または 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: An Introduction to Active Directory Federation Services 2.0, Windows CardSpace 2.0, and Windows Identity Foundation (英語)』(https://go.microsoft.com/fwlink/?linkid=196776&clcid=0x411) (英語) を参照してください。
クレーム ベース認証設計サンプルでは、公開ファームがクラシック モード認証を使用するように設定されています。代わりに、公開ファームにもクレーム ベース認証を使用し、匿名ユーザー用に別の領域を実装するという方法もあります。この設計の重要な要素は、どちらの認証モードを実装するにしても、匿名ユーザー用として別の領域を使用して、読み取り専用環境と読み取り書き込み環境とを分離することです。次の表は、公開ファームについて説明した領域とユーザーと認証の種類を示しています。
.gif "ゾーン、ユーザー、および認証を示す表")
検索クロール アカウントは、NTLM 認証を使用して最低 1 つの領域にアクセスすることが必要です。必要に応じて、クレーム認証領域に NTLM 認証を追加できます。クラシック モードで、ユーザーのための領域のいずれも NTLM を使用するように構成されていない場合は、NTLM 認証を使用するようにユーザー設定領域を構成してください。
領域
領域を設計するときには、いくつかの重要な決定が展開の成功を左右します。これらの決定事項の中に、以下の領域の設計と構成に関する決定があります。
既定領域
外部アクセス用の領域
以下のセクションでは、設計サンプルに組み込まれている決定事項について説明します。
既定領域の構成要件
最も慎重な考慮を要する領域は既定領域です。SharePoint Server 2010 は既定領域の構成方法に以下の要件を設けています。
ユーザーの要求を領域と関連付けることができない場合は、既定領域の認証とポリシーが適用されます。したがって、既定領域は最も安全な領域である必要があります。
管理用電子メールは、既定領域からのリンクを付けて送信されます。その一例が、クォータ制限に近づいているサイトの所有者に対する電子メールです。したがって、これらの種類の電子メールや通知を受信するユーザーは、既定領域を通じてリンクにアクセスできる必要があります。このことは、サイト所有者にとって特に重要です。
ホスト名付きサイト コレクションは、既定領域を経由してのみ利用できます。ホスト名付きサイト コレクションにアクセスするすべてのユーザーには、既定領域を経由したアクセスが必要です。
エクストラネット環境用の領域を構成する
エクストラネット環境では、次の 2 つの理由から、領域のデザインがきわめて重要になります。
ユーザーの要求は、さまざまなネットワークから開始できます。設計サンプルでは、ユーザーは内部ネットワーク、インターネット、およびパートナー会社から要求を開始します。
ユーザーは複数の Web アプリケーションでコンテンツを使用します。設計サンプルでは、イントラネットは 3 つの異なる Web アプリケーションから構成されています。また、内部の従業員とリモートの従業員は、すべての Web アプリケーション (イントラネット、パートナー Web、および企業インターネット サイト) でコンテンツを投稿および管理する可能性があります。
エクストラネット環境では、次の設計原則に従ってください。
複数の Web アプリケーションにまたがる領域は、互いにミラー化されるように構成します。認証の構成と対象ユーザーは、同じである必要があります。ただし、領域に関連付けられたポリシーは Web アプリケーション間で異なっていてもかまいません。たとえば、イントラネット領域は、どの Web アプリケーションでも同じ従業員に使用するようにします。つまり、イントラネット領域をある Web アプリケーションで内部の従業員用に構成し、別の Web アプリケーションでリモートの従業員用に構成することはしません。
各領域と各リソースについて、代替アクセス マッピングを適切かつ正確に構成します。代替アクセス マッピングは、領域を作成すると自動的に作成されます。ただし、SharePoint Server 2010 はファイル共有などの外部リソースのコンテンツをクロールするように構成できます。これらの外部リソースへのリンクは、代替アクセス マッピングを使用して、領域ごとに手動で作成する必要があります。
複数の Web アプリケーションにまたがる領域が互いにミラー化されていない場合は、外部リソースへのリンクが適切でないと、以下のリスクが生じます。
サーバー名、ドメイン ネーム システム (DNS) 名、および IP アドレスが、内部ネットワークの外に公開される可能性があります。
ユーザーが Web サイトなどのリソースにアクセスできない可能性があります。
サービス
ここで説明しているサービス アーキテクチャは、イントラネット、パートナー Web、企業インターネット サイトという 3 種類のサイトにサービスを展開するための最も複雑なオプションを示しています。専用サービスおよびパーティション分割されたサービスが、パートナー Web サイト用に展開されます。Managed Metadata Service アプリケーションの別インスタンスが、作成サイト コレクションと公開インターネット サイトで排他的に使用するために展開されます。
もっと単純な方法もあります。それは、サービス アプリケーションのセットを 1 つだけ展開し、必要に応じてサイト間で各サービスを共有するというものです。このアーキテクチャは、ユーザーがアクセスできるコンテンツだけを表示するためのセキュリティによるトリミング機能に依存しています。次の図は、この単純なアプローチを示しています。
.gif "サービス アーキテクチャ")
サービス アプリケーションの展開に関する設計上の最も重要な決定事項は、組織の分類 (タクソノミー) をどこまで広げるかという点です。すべての Web アプリケーションの間で管理されたメタデータ、ユーザー プロファイル、および検索を共有し、セキュリティによるトリミングを利用してコンテンツへのアクセスを管理すれば、サービス アーキテクチャを単純化できます。この記事で説明している単純化したアーキテクチャでは、Managed Metadata Service の 1 つのインスタンスがすべてのサイトで共有されます。ただし、この構成では、すべてのユーザーが企業の分類にアクセスできます。ソリューション アーキテクトは、Managed Metadata Service の複数のインスタンスを実装するかどうかを決める必要があります。また、ユーザー プロファイル データをどれだけ広範囲に共有するかも決める必要があります。
パートナー Web サイト
パートナー Web サイト (ファーム 1 のユーザー設定グループ) については、設計サンプルで規定している最小限のサービスは Search と Managed Metadata です。パートナー Web サイトで使用されるサービスのグループに Office Web Apps を追加する場合は、パートナーも含めて、このサイトのすべてのユーザーについて適切なライセンスがあることを確認してください。パートナーのユーザーから組織内のユーザーのデータがブラウズされるのを防ぐため、設計サンプルでは User Profile Service アプリケーションを組み込んでいません。
単純化したアーキテクチャでは、パートナーが企業の分類全体にアクセスでき、組織内のユーザーのデータをブラウズできます。ただし、検索の結果はパートナーがアクセスできるサイトとコンテンツに制限されます。
パートナーのサイトがプロジェクト間でコンテンツの分離を必要とする場合、設計サンプルで示しているように、専用サービスおよびパーティション分割されたサービス アプリケーションを展開するのが適切なやり方です。このようにすると、サービス アーキテクチャの複雑さは増しますが、パートナーがイントラネット コンテンツに関連付けられたメタデータやパートナー Web サイト内の他のプロジェクトにアクセスすることはなくなります。
企業インターネット サイト
単純化したアーキテクチャでは、企業の Managed Metadata Service アプリケーションが公開インターネット サイトと共有されています。設計サンプルでは、Managed Metadata Service アプリケーションの専用インスタンスが、作成サイト コレクションと公開ファームで排他的に使用するためにグループ作業ファームに展開されます。
公開ファームが匿名で読み取り専用である場合は、公開コンテンツに関連付けられていない管理されたメタデータが公開されるリスクはありません。匿名ユーザーは、公開されたコンテンツにアクセスするだけで、評価を送信したり他の種類のメタデータを作成したりすることはできません。
Managed Metadata Service アプリケーションを組織全体で共有すると (この記事の単純化されたアーキテクチャで示しています)、作成者が企業の分類を利用できます。それに対し、作成と公開用にサービスの専用インスタンスを展開すると (こちらは設計サンプルで示しています)、管理されたメタデータが確実に分離されます。
Search Service アプリケーションの専用インスタンスが、企業インターネット サイトをホストするファームに展開されます。これが公開インターネット向けサイトの推奨構成です。
作成と発行の代替策
企業インターネット サイトについては、設計サンプルで発行プロセスを示しています。このプロセスには、コンテンツを作成サイト コレクションから公開ファームに移すためのコンテンツ展開機能の使用が含まれます。これに代わるもっと単純な方法として、公開ファーム上で直接作成するという方法もあります。これは一般に運用環境での作成と呼ばれます。
運用環境で作成を行うと、サービスが 1 つのファームにまとめられ、コンテンツの展開が不要になるので、ソリューションが大幅に単純化されます。設計サンプルでは、匿名ユーザーに影響を与えずに安全に作業するために作成者が使用することのできる追加の領域を含めています。作成者が使用する領域に関連付けられたポートで外からの匿名アクセスを確実にブロックしてください。サイトへの書き込み回数が 1 時間の作成アクティビティあたり 500 未満であれば、運用環境での作成の際に公開サイトのパフォーマンスに悪影響を及ぼすことはないでしょう。
SharePoint Server 2010 には、このシナリオで使用できる発行機能が含まれており、それらの機能よって、準備ができるまでコンテンツが匿名ユーザーに公開されないようにすることができます。詳細については、以下の記事を参照してください。
Schedule the start and end date for a published page (英語) (https://go.microsoft.com/fwlink/?linkid=196777&clcid=0x411) (英語)
Approve or reject a pending submission (英語) (https://go.microsoft.com/fwlink/?linkid=196778&clcid=0x411) (英語)
Set permissions for publishing (英語) (https://go.microsoft.com/fwlink/?linkid=196779&clcid=0x411) (英語)
管理サイト
設計サンプルでは、各サーバー ファームのサーバーの全体管理サイトがアプリケーション サーバーにホストされています。これにより、サーバーの全体管理サイトへのユーザーの直接のアクセスが防止されます。パフォーマンスのボトルネックやセキュリティの低下によってフロントエンド Web サーバーの可用性が影響を受けても、サーバーの全体管理サイトは利用可能なままです。
管理サイト用の負荷分散される URL については、設計サンプルでもこの記事でも言及していません。推奨事項は以下のとおりです。
管理 URL でポート番号を使用する場合は、標準以外のポートを使用します。URL には既定でポート番号が含まれています。顧客向け URL でポート番号を使用することは通常ありませんが、管理サイトにポート番号を使用すると、これらのサイトへのアクセスを標準以外のポートに制限することにより、セキュリティを強化できます。
管理サイト用に個別の DNS エントリを作成します。
これらの推奨事項に加え、必要に応じて、サーバーの全体管理サイトを複数のアプリケーション サーバーに負荷分散すると、冗長性を確保できます。
アプリケーション プール
通常は、個別のインターネット インフォメーション サービス (IIS) アプリケーション プールを実装することにより、コンテンツ間のプロセス分離が実現されます。アプリケーション プールは、複数のサイトが同じサーバー コンピューターで動作しながら、独自のワーカー プロセスと ID を保持するための 1 つの手段を提供します。攻撃者があるサイトの弱点を悪用してサーバーにコードを送り込み、他のサイトを攻撃する危険性が小さくなります。
実際上は、以下のシナリオでそれぞれ専用のアプリケーション プールを使用することを検討してください。
認証コンテンツを匿名コンテンツと区別する。
外部ビジネス アプリケーションのパスワードを保存したり外部ビジネス アプリケーションと通信したりするアプリケーションを分離する (ただし、この目的には代わりに Secure Store Service を使用できます)。
サイトの作成と管理およびコンテンツに関するグループ作業をユーザーが自由に行えるアプリケーションを分離する。
設計サンプルではアプリケーション プールを以下のように使用しています。
各管理サイトは、専用のアプリケーション プールでホストされます。これは SharePoint 2010 Products の要件です。
イントラネット コンテンツは、2 つの異なるアプリケーション プールに分けられます。グループ作業コンテンツ (個人用サイトとチーム サイト) は、1 つのアプリケーション プールでホストされます。公開イントラネット コンテンツは、別のアプリケーション プールでホストされます。この構成は、ビジネス データ接続が使用される可能性が高い公開イントラネット コンテンツに、プロセスの分離を提供します。
パートナー Web アプリケーションは、専用のアプリケーション プールでホストされます。
企業インターネット サイトは、2 番目のファームにある専用のアプリケーション プールでホストされます。もしパートナーとのグループ作業に使用するコンテンツもこのファームでホストすることがあれば、これら 2 種類のコンテンツ (インターネットとパートナー) は 2 つの異なるアプリケーション プールでホストされます。
Web アプリケーション
Web アプリケーションは、SharePoint 2010 Products によって作成され使用される IIS Web サイトです。各 Web アプリケーションは、IIS のそれぞれ異なる Web サイトによって表現されます。
一般的に、専用の Web アプリケーションは次の目的で使用します。
認証されるコンテンツを匿名コンテンツから分離する。設計サンプルでは、企業インターネット サイトは専用の Web アプリケーションおよびアプリケーション プールでホストされています。
ユーザーを分離する。設計サンプルでは、パートナー Web を専用の Web アプリケーションおよびアプリケーション プールでホストして、パートナーがイントラネット コンテンツにアクセスできないようにしています。
権限を適用する。専用の Web アプリケーションは、サーバーの全体管理の [Web アプリケーションのポリシー] ページを使用してポリシーに基づいて権限を適用する機会をもたらします。たとえば、企業インターネット サイトのポリシーを作成して、1 つ以上のユーザー グループに対して書き込みアクセスを明示的に拒否できます。Web アプリケーションのポリシーは、Web アプリケーション内の個々のサイトまたはドキュメントに対して構成されたアクセス許可の有無に関係なく、適用されます。
パフォーマンスを最適化する。アプリケーションは、類似するデータ特性を持つ他のアプリケーションと共に Web アプリケーションに配置した場合の方が、パフォーマンスが高くなります。たとえば、個人用サイトには、サイトの規模は小さいが、数が多いというデータ特性があります。それに対し、チーム サイトには、数は少ないが規模が非常に大きいという傾向があります。これら 2 種類のサイトを別々の Web アプリケーションに配置することにより、データベースは特性の類似するデータで構成されるようになり、データベースのパフォーマンスが最適化されます。設計サンプルでは、個人用サイトとチーム サイトは、固有のデータ分離要件を持たず、同じアプリケーション プールを共有しています。それにもかかわらず、個人用サイトとチーム サイトを別々の Web アプリケーションに配置することにより、パフォーマンスを最適化しています。
管理性を最適化する。別々の Web アプリケーションを作成すると、サイトとベータベースも別々になるため、異なったサイト制限 (ごみ箱、有効期限、およびサイズ) を実装し、異なったサービス レベル契約を結ぶことができます。たとえば、組織内で最も重要な種類のコンテンツではない場合、個人用サイトのコンテンツの復元を急ぐ必要はありません。こうすると、個人用サイトのコンテンツを復元する前に、より重要なコンテンツを復元できます。設計サンプルでは、個人用サイトを別の Web アプリケーションに配置して、管理者が成長を他のアプリケーションより厳しく管理できるようにしています。
サイト コレクション
サイト コレクションは、論理アーキテクチャと情報アーキテクチャの橋渡しをするものです。設計サンプルでのサイト コレクションの設計目標は、URL 設計の要件を満たすことと、コンテンツを論理的にグループ分けすることです。
URL デザインの要件を満たすために、Web アプリケーションにはそれぞれ単一のルートレベル サイト コレクションが含まれています。管理パスを使用して、トップレベル サイト コレクションの第 2 層が組み込まれています。URL 要件、および管理パスの使用の詳細については、後の「領域と URL」を参照してください。サイト コレクションの第 2 層より上位では、各サイトがサブサイトです。
次の図は、チーム サイトのサイト階層を示しています。
.gif "チーム サイト")
ルートレベル サイト コレクションの要件を考えると、設計上の決定の中心になるのはサイト コレクションの第 2 層です。設計サンプルには、アプリケーションの性質に基づいた選択が組み込まれています。
公開イントラネット コンテンツ
公開イントラネット コンテンツ Web アプリケーションに関する前提は、企業内の複数の部門が公開コンテンツをホストすることです。設計サンプルでは、各部門のコンテンツがそれぞれ別のサイト コレクションでホストされています。この方法には以下の長所があります。
各部門のコンテンツの権限を、その部門で独自に管理できます。
各部門のコンテンツを、専用のデータベースに保存できます。
複数のサイト コレクションを使用する方法には、以下の短所があります。
マスター ページ、ページ レイアウト、テンプレート、Web パーツ、およびナビゲーションを、サイト コレクション間で共有できません。
サイト コレクション間でカスタマイズやナビゲーションを調整するために、より多くの手間がかかります。
イントラネット アプリケーションの情報アーキテクチャと設計によっては、ユーザーに公開コンテンツをシームレスなアプリケーションであるように見せることができます。また、各サイト コレクションをそれぞれ別の Web サイトであるように見せることもできます。
個人用サイト
個人用サイトには明確な特性があり、個人用サイトを展開するための推奨事項は簡単です。設計サンプルでは、個人用サイト アプリケーションに、http://my という URL のトップレベル サイトが組み込まれています。最初に作成されるトップレベル サイト コレクションは、個人用サイトのホスト テンプレートを使用します。管理パスが組み込まれており (ワイルド カードを使用した管理パスを使用)、このため、ユーザーが作成するサイトの数に制限はありません。管理パスより下位のすべてのサイトは、個人用サイトのホスト テンプレートを継承する独立したサイト コレクションです。URL には http://my personal/<ユーザー名> という形式でユーザー名が追加されます。個人用サイトを次の図に示します。
.gif "個人用サイト")
チーム サイト
チーム サイト アプリケーション内のサイト コレクションを設計するには、以下の 2 つの方法があります。
チームがセルフサービス サイト作成を使用してサイト コレクションを作成することを許可します。この方法の長所は、管理者がサポートしなくても、チームが必要に応じて簡単にサイトを作成できることです。ただし、この方法には以下に示す多くの短所があります。
高度な分類法を実装する機会が失われます。
アプリケーションの管理が難しくなる可能性があります。
サイトが放置されやすくなります。
1 つのサイト コレクションを共有できるはずの複数のプロジェクトやチームによるテンプレートやナビゲーションの共有が行えなくなります。
組織の活動状況に基づいて、組織に適した有限数のサイト コレクションを作成します。この方法では、SharePoint 管理者によってサイト コレクションが作成されます。サイト コレクションが作成された後で、チームが必要に応じてサイト コレクション内にサイトを作成できます。この方法では、チーム サイトの管理方法や成長の仕方に構造を提供する高度な分類法を実装する機会があります。サイト コレクションを共有するプロジェクトとチームがテンプレートやナビゲーションを共有する可能性も増えます。
設計サンプルには 2 番目の方法が組み込まれており、このため、チーム サイトのサイト コレクション階層は、公開イントラネット コンテンツと類似しています。情報アーキテクチャの課題は、組織に適したサイト コレクションの第 2 層を作成することです。以下の表は、さまざまな種類の組織に対する推奨事項を示しています。
| 組織の種類 | 推奨するサイト コレクション分類法 |
|---|---|
製品開発 |
|
研究 |
|
高等教育機関 |
|
県議会事務局 |
|
企業法務を扱う弁護士事務所 |
|
製造 |
|
パートナー Web アプリケーション
パートナー Web は、範囲または期間が限定されたプロジェクトで、外部パートナーとのグループ作業に使用されることを目的としています。設計上、パートナー Web アプリケーション内のサイトは、他のサイトから参照されることを想定していません。パートナー Web アプリケーションには、以下の要件があります。
パートナーとのグループ作業に使用するサイトを、プロジェクトの所有者が簡単に作成できる。
パートナーやその他の参加者は、作業対象のプロジェクトだけにアクセスできる。
権限はサイト所有者によって管理される。
あるプロジェクトからの検索結果により、他のプロジェクトからのコンテンツが公開されない。
使用されなくなったサイトを、管理者が簡単に識別し、削除できる。
これらの要件を満たすために、設計サンプルにはプロジェクトごとに 1 つのサイト コレクションが組み込まれています。これにより、以下の利点が得られます。
個別のサイト コレクションが、プロジェクト間に適切なレベルの分離を提供します。
セルフサービス サイト作成を実装できます。
パートナー Web アプリケーションは企業インターネット サイトのコンテンツ開発に使用するサイト コレクションもホストするため、作成用とステージング用の個別のサイト コレクションが作成されます。
企業インターネット サイト
企業インターネット サイトには、単一のルートレベル サイト コレクションが組み込まれています。このサイト コレクションの下のサイトは、すべてサブサイトです。この構造により、サイト内のページの URL が簡略化されます。次の図は、企業インターネット サイトのアーキテクチャを示しています。
.gif "会社のインターネット サイト")
コンテンツ データベース
コンテンツ データベースは、以下の 2 つの方法で設計に組み込むことができます (設計サンプルには両方の方法が組み込まれています)。
適切なサイズの警告しきい値を使用して、コンテンツ データベースの目標サイズを設定します。サイズが警告しきい値に達したら、新しいデータベースを作成します。この方法では、サイト コレクションは、サイズ目標のみに基づいて利用可能なデータベースに自動的に追加されます。これが最もよく使用される方法です。
サイト コレクションを特定のコンテンツ データベースに関連付けます。この方法では、1 つ以上のサイト コレクションを、他のデータベースとは別に管理できる専用のデータベースに配置できます。
サイト コレクションを特定のコンテンツ データベースに関連付ける場合は、次の方法を使用します。
Windows PowerShell を使用して、特定のデータベースにサイト コレクションを作成します。
以下のデータベース容量設定を適用して、1 つのデータベースを単一のサイト コレクションだけに使用します。
[警告イベントが生成される前のサイト数] = 1
[このデータベースに作成できるサイトの最大数] = 1
次の手順を実行して、専用のデータベースにサイト コレクションのグループを追加します。
Web アプリケーション内で、データベースを作成し、データベースの状態を [準備完了] に設定します。
他のすべてのデータベースの状態を [オフライン] に設定します。コンテンツ データベースがオフラインである間は、新しいサイト コレクションを作成できません。ただし、オフライン データベースの既存のサイト コレクションには、読み取り操作と書き込み操作の両方を実行できます。
サイト コレクションを作成します。作成したサイト コレクションは、自動的にデータベースに追加されます。
他のすべてのデータベースの状態を [準備完了] に戻します。
公開イントラネット コンテンツ
公開イントラネット コンテンツについては、設計サンプルでは管理を容易にするためにデータベースを 1 つだけ組み込んでいます。もし必要なら、目標サイズに基づいてデータベースを追加してください。
個人用サイト
個人用サイトについては、設計サンプルでは規模効率を得るためにデータベースを最大目標サイズまでに管理しています。この目標を実現するために以下の設定が構成されています。
[サイト記憶域の最大サイズを次の値に制限する]: この設定は、サーバーの全体管理の [クォータ テンプレート] ページで構成するもので、個人用サイトのサイズを制限します。
[削除済みデータ バックアップ]: この設定は、[Web アプリケーションの全般設定] ページで構成するもので、削除済みデータ バックアップに割り当てられる追加の容量を決定します。
[このデータベースに作成できるサイトの最大数]: この設定はデータベース作成時に構成します。前の 2 つの設定に指定する値から、サイト全体の許容サイズを計算します。次に、各データベースのサイズ目標に基づいて、データベースに収まるサイト数を決定します。
設計サンプルのサイズ設定例は、目標のデータベース サイズ 200 GB、目標の個人用サイト サイズ 1 GB に基づいて、以下のようになっています。
サイトごとのサイト サイズ制限 = 1 GB
データベースの目標サイズ = 175 GB
削除済みデータ バックアップ用に確保 = 15%
サイトの最大数 = 180
サイト レベルの警告 = 150
サイト レベルの警告値に達したら、新しいデータベースを作成します。新しいデータベースを作成した後、新しい個人用サイトは、作成したデータベースと既存のデータベースに、いずれかのデータベースがサイトの最大数に達するまで交互に追加されます。
チーム サイト
チーム サイトについても、設計サンプルでは規模効率を得るためにデータベースを最大目標サイズまでに管理しています。大部分の組織では、チーム サイトは個人用サイトより大きくなることが想定されます。設計サンプルでのデータベース設定は、サイト コレクションに対する 30 GB の制限に基づいています。実際の組織のチーム サイトに適した制限を選択してください。
大きな記憶域を必要とするチームのある組織については、トップレベル チーム サイト コレクションのそれぞれに専用のデータベースを使用するという方法もあります。
パートナー Web
個人用サイトと同様、パートナー Web についても規模効率を得るためにデータベースを最大目標サイズまでに管理しています。ただし、設計サンプルでは企業インターネット サイトの作成サイト コレクションもパートナー Web でホストしています。したがって、データベース設計には両方の方法が組み込まれています。
作成サイト コレクションを専用のデータベースでホストします。
データベース設定とサイズ設定を構成して、他のすべてのサイトとデータベースを管理します。
パートナー Web は専用の Web アプリケーションでホストされるため、作成されるサイトの種類により適したサイズ制限を設けることができます。設計サンプルのサイズ設定は、以下のようになっています。
データベースの目標サイズ = 200 GB
サイトごとの記憶域クォータ = 5 GB
サイトの最大数 = 40
作成サイト コレクションを専用のデータベースでホストする
企業インターネット サイト
企業インターネット サイトの設計で単一のサイト コレクションを使用することにより、この Web アプリケーションには単一のデータベースが使用されます。
領域と URL
設計サンプルは、企業展開の複数のアプリケーション間で URL を調整する方法を示しています。
設計目標
URL の設計上の決定には、以下の目標が影響します。
URL 規則では、どの領域を通じてコンテンツにアクセスできるかを制限しません。
標準の HTTP ポートおよび HTTPS ポート (80 および 443) を、設計サンプルの全アプリケーションで使用できます。
URL にポート番号は含まれません。実際に、運用環境でポート番号を使用することは通常ありません。
設計原則
これらの設計目標を達成するために、以下の設計原則が適用されます。
ホスト名が付いたサイト コレクションは使用されません。ここで注意する必要があるのは、ホスト名が付いたサイト コレクションが、IIS のホスト ヘッダーとは異なることです。ホスト名が付いたサイト コレクションは、代替アクセス マッピングと連動しません。同じコンテンツに複数のドメイン URL を通じてアクセスするには、代替アクセス マッピング機能が必要です。このため、ホスト名が付いたサイトが使用されている場合、これらのサイトは既定領域からしか利用できません。
各アプリケーションには、単一のルート サイト コレクションが組み込まれています。これは、代替アクセス マッピングを使用するための要件です。Web アプリケーションに複数のルート サイト コレクションが必要で、ユーザー アクセスに既定領域のみ使用することを予定している場合は、ホスト名が付いたサイト コレクションが適切な選択肢となります。
それぞれがトップレベル チームまたはトップレベル プロジェクトを表す、上位のサイト コレクションが複数含まれているアプリケーションについては (チーム サイトなど)、設計サンプルでは管理パスを組み込んでいます。管理パスを使用すると、これらの種類のサイトの URL をより詳細に制御できます。
設計上の代償
設計目標を満たした結果、以下の代償が生じます。
URL が長くなります。
ホスト名が付いたサイト コレクションは使用されません。
負荷分散される URL を設計する
Web アプリケーションを作成するときに、アプリケーションに割り当てる負荷分散される URL を選択する必要があります。また、Web アプリケーション内に作成する領域ごとに、負荷分散される URL を作成する必要があります。負荷分散される URL には、プロトコル、スキーム、ホスト名、およびポート (使用する場合) が含まれます。負荷分散される URL は、すべての Web アプリケーションおよび領域にわたって一意である必要があります。このため、各アプリケーション、および各アプリケーション内の各領域に、設計サンプル全体にわたって一意な URL が必要です。
イントラネット
イントラネットを構成する 3 つの Web アプリケーションそれぞれに一意な URL が必要です。設計サンプルでは、イントラネット コンテンツの対象ユーザーは内部の従業員とリモートの従業員です。クレーム認証設計サンプルでは、従業員は内部にいるかリモートにいるかに関係なく、これらのアプリケーションのそれぞれについて同じ URL を使用しています。この方法では、SharePoint 設計にセキュリティ レイヤーが 1 つ追加されますが (すべてのトラフィックが SSL)、ファイアウォールやゲートウェイ製品を通じてリモート トラフィックと共に内部トラフィックをルーティングするか、スプリット DNS 環境をセットアップして内部の要求を内部ネットワーク内で解決することが必要です。
クラシック認証設計サンプルでは、内部の従業員とリモートの従業員とで URL が異なります。次の表は、クラシック認証設計サンプルにおいて、内部の従業員とリモートの従業員が各アプリケーションへのアクセスに使用する URL を示しています。
| アプリケーション | 内部の従業員の URL | リモートの従業員の URL |
|---|---|---|
公開イントラネット コンテンツ |
http://fabrikam |
https://intranet.fabrikam.com |
チーム サイト |
http://teams |
https://teams.fabrikam.com |
個人用サイト |
http://my |
https://my.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 |
企業インターネット サイト
企業インターネット サイトは、パブリック サイトであり、すべてのユーザーが http://www.fabrikam.com という既定の URL を使用してアクセスできます。インターネット領域のポリシー (つまり、匿名アクセス、書き込み拒否) が適用されます。
ただし、パブリック サイトで管理作業と作成作業をサポートするために、設計サンプルには内部の従業員とリモートの従業員のための URL が組み込まれています。これらの領域にポリシーを使用して、作成作業とメンテナンス作業のために対象のセキュリティ グループへ適切なアクセスが行われるようにすることができます。クラシック認証設計サンプルでもクレーム認証設計サンプルでも、このファームに対して同じ方法を使用しています。次の表は、各領域の URL を示しています。
| 領域 | URL |
|---|---|
内部の従業員の URL |
http://fabrikamsite |
リモートの従業員の URL |
https://fabrikamsite.fabrikam.com |
顧客の URL |
http://www.fabrikam.com |
明示的な管理対象パスとワイルド カードを使用した管理対象パスを URL パスに使用する
管理パスを定義することにより、Web アプリケーションの URL 名前空間のどのパスをサイト コレクションに使用するかを指定できます。1 つのサイト コレクション、または複数のサイト コレクションが、ルート サイトより下位の特定のパスに存在することを指定できます。管理パスなしの場合、ルート サイト コレクションより下位に作成されるすべてのサイトは、ルート サイト コレクションに属します。
作成できる管理対象パスには、次の 2 種類があります。
明示的な管理対象パス: 割り当てた明示的な URL を持つサイト コレクション。明示的な管理対象パスは、単一のサイト コレクションに適用されます。ルート サイト コレクションの下位には、明示的な管理対象パスを多数作成できます。この方法で作成されるサイト コレクションの URL の一例は、http://fabrikam/hr です。明示的なパスを追加するたびにパフォーマンスへの悪影響が大きくなるので、明示的な管理対象パスを使用して作成するサイト コレクションの数は 20 個ほどに制限することをお勧めします。
ワイルド カードを使用した管理対象パス: URL に追加されるパス。このパスは、パス名の直後に指定されるすべてのサイトが、固有のサイト コレクションであることを示します。通常、この方法は個人用サイトなど、セルフサービス サイト作成をサポートするサイト コレクションに使用されます。この方法で作成されるサイト コレクションの URL の一例は、http://my/personal/user1 です。
以下のセクションで説明するように、設計サンプルには両方の種類の使用が組み込まれています。
明示的な管理対象パス: 公開イントラネット コンテンツ
設計サンプルでは、公開イントラネット Web アプリケーションに明示的な管理対象パスの使用が組み込まれています。
公開イントラネット コンテンツ
公開イントラネット コンテンツ Web アプリケーションでは、人事 (HR)、施設 (Facilities)、購買 (Purchasing) などの各サブサイトに明示的な管理対象パスが使用されます。これらのサイト コレクションに、必要に応じて、それぞれ異なるコンテンツ データベースを関連付けることができます。この例の明示的な管理対象パスの使用では、ワイルド カードを使用した管理対象パスを含めて、Web アプリケーション内に他の種類のサイトが作成されないことを前提にしています。
明示的な管理対象パスを使用して作成するサイトの数は 20 個ほどに制限することをお勧めします。それ以上のサイト コレクションを必要とする場合は、ワイルド カードを使用した管理対象パスまたはホスト名が付いたサイト コレクションの使用を検討してください。
クラシック認証設計サンプルでは、明示的な管理対象パスの使用によって 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 は、イントラネットの既定のホーム ページを表しています。このサイトはユーザーのコンテンツをホストするためのものです。
ワイルド カードを使用した管理対象パス: チーム サイト、個人用サイト、およびパートナー 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 は、必ずしもユーザーのコンテンツをホストしません。
個人用サイト
個人用サイトには、セルフサービス サイト作成機能があります。イントラネットを参照しているユーザーが初めて [個人用サイト] をクリックすると、そのユーザーの個人用サイトが自動的に作成されます。設計サンプルでは、個人用サイトに /personal というワイルド カードを使用した管理対象パスが含まれています (http://my/personal)。個人用サイトの機能によって、ユーザー名が URL に自動的に追加されます。
クラシック認証設計サンプルでは、これによって URL は次の表のようになります。
| 内部 (イントラネット領域) | リモートの従業員 (既定領域) |
|---|---|
http://my/personal/user1 |
https://my.fabrikam.com/personal/user1 |
http://my/personal/user2 |
https://my.fabrikam.com/personal/user2 |
http://my/personal/user3 |
https://my.fabrikam.com/personal/user3 |
パートナー 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 |
パートナー Web アプリケーションの例外は、設計サンプルに示してあるように、企業インターネット サイト用のコンテンツを作成するための専用のコレクションです。このサイト コレクションには、明示的な管理対象パスが使用されています。これは、同じ Web アプリケーションで明示的な管理対象パスとワイルド カードを使用した管理対象パスの両方を使用する一例です。
領域ポリシー
Web アプリケーションのポリシーを作成して、Web アプリケーション レベルで権限を適用できます。ポリシーは、Web アプリケーション全体に対して、または特定の領域のみに対して定義できます。ポリシーによって権限が適用されるのは、Web アプリケーションまたは領域内のすべてのコンテンツです。ポリシーの権限は、サイトとコンテンツに対して構成された他のすべてのセキュリティ設定より優先されます。ポリシーはユーザーまたはユーザー グループに基づいて構成できますが、SharePoint グループに基づいて構成することはできません。領域ポリシーを追加または変更する場合、検索でサイトを再クロールして新しい権限を得る必要があります。
1 つの領域で複数の種類の認証が有効になっているグループ作業ファームのクレーム認証設計サンプルではポリシーは使用されていません。ポリシーが実装されているのは、クラシック認証設計サンプルと、Windows 認証を規定しているクレーム認証設計サンプルの公開ファームです。公開ファームでは、ポリシーの使用によって、サイトを管理するためにアクセスするユーザーと匿名ユーザーとの間にセキュリティ レイヤーが 1 つ追加されます。
設計サンプルでのさまざまなポリシーの例では、以下のことを達成しています。
公開コンテンツへの書き込みアクセスを拒否する。
作成者とテスト担当者に、公開コンテンツへの適切なアクセスを与える。