論理アーキテクチャ モデル : 企業展開
この記事の内容 :
モデルについて
全体的なデザイン目標
サーバー ファーム
ユーザー、領域、認証
SSP
管理サイト
アプリケーション プール
Web アプリケーション
サイト コレクション
コンテンツ データベース
領域と URL
領域ポリシー
ここでは、実行可能なデザインをもたらす論理アーキテクチャ コンポーネントの実用的な実装について説明します。この記事は、次のモデル「Logical Architecture Sample Design: Corporate Deployment (英語)」(https://go.microsoft.com/fwlink/?linkid=82151&clcid=0x411) と併せて使用してください。
モデルは、Microsoft Office SharePoint Server 2007 の標準的な企業展開を示しています。モデルは、ほぼすべての論理アーキテクチャ コンポーネントを採用し、それらのコンポーネントが全体のデザインにどのように組み込まれているかを表しています。ここでは、モデルのデザイン目標と、モデルに示す論理アーキテクチャ コンポーネントを使用してそれらの目標を実現する方法について説明します。
モデルについて
モデルは、Fabrikam, Inc. という架空の会社の企業展開を示しています。展開には 2 つのサーバー ファームが含まれています。1 番目のサーバー ファームは、企業イントラネットとパートナー Web サイトをホストします。2 番目のサーバー ファームは、企業 Web サイト (www.fabrikam.com) をホストします。
イントラネット
企業イントラネットには、以下のアプリケーションが含まれます。
公開イントラネット コンテンツ (たとえば、HRweb)
グループ作業チーム サイト
個人用サイト
これらは、いずれも従業員が日常的に使用するコンテンツ サイトおよびグループ作業サイトですが、個別に見ると、これらのアプリケーションはそれぞれ固有の種類のコンテンツを表しています。各種類のコンテンツには以下の違いがあります。
Office SharePoint Server 2007 の異なる機能を重視します。
異なったデータ特性を持つデータをホストします。
異なる使用プロファイルに従います。
異なる方法の権限管理が必要です。
したがって、これら各アプリケーションのデザイン選択では、各アプリケーションのパフォーマンスとセキュリティを最適化することが目的となります。
単一の共有サービス プロバイダ (SSP) を使用すると、これら 3 つのアプリケーションの統合により以下の機能が提供されます。
アプリケーション間のナビゲーション
企業全体の検索
共有のプロファイル データ
以下の図は、企業イントラネットを構成する 3 つのアプリケーションを示しています。
.jpg "企業モデル用の論理アーキテクチャ")
パートナー Web
パートナー Web アプリケーションは、パートナー会社の従業員と安全にグループ作業するための外部から利用可能なサイトをホストします。このアプリケーションは、安全なグループ作業のためのサイトを、従業員が簡単に作成できることを目的としています。このアプリケーションのデザイン選択では、以下の要素が重要です。
コンテンツの分離 パートナーがそのサーバー ファームでホストされる他の種類のコンテンツにアクセスすることは許可されません。また、専用の SSP により、以下の方法でコンテンツをさらに分離できます。
検索範囲をサイト レベルに制限します。
サイト コレクション間のナビゲーションを許可しません。
プロファイル データをサイト コレクションにまたがって利用できるようにはしません。
パートナー アカウントの認証の分離 パートナー アカウントはフォーム認証を通じて管理されます。パートナー アカウントは企業ディレクトリに追加されません。
権限管理 個々のサイトの所有者は、グループ作業に必要な参加者だけを招待して、各自のサイトに対する権限を管理します。
モデルでは、パートナー Web アプリケーションとイントラネット コンテンツが、同一のファームによってホストされています。
企業インターネット サイト
企業インターネット サイトは、企業のインターネット プレゼンスです。コンテンツは、読み取り専用の権限を持つ匿名アクセスを構成することにより、顧客から利用可能になります。このアプリケーションのデザイン選択では、以下の要素が重要です。
コンテンツの分離 顧客はそのサーバー ファームでホストされる他の種類のコンテンツにアクセスできません。
対象を絞った管理 管理作業、オーサリング作業など、Web サイトの運営を行う従業員には、認証済みのアクセスが提供されます。
コンテンツ作成および発行のセキュリティ保護 パートナー Web アプリケーションのファーム A で、オーサリング用とステージング用の個別のサイト コレクションがホストされます。これにより、内部の従業員とリモートの従業員だけでなく、Web サイト開発やコンテンツ作成を専門とする編集パートナーとも、セキュリティ保護されたグループ作業とコンテンツ開発が可能になります。コンテンツの発行は、オーサリング サイト コレクションからステージング サイト コレクション (ファーム A) に、ファーム A のステージング サイト コレクションからファーム B の稼働サイト コレクションに、自動的にコンテンツを発行するように構成されます。発行プロセスは、以下の図のようになります。
.jpg "論理ファーム アーキテクチャ - 発行モデル")
全体的なデザイン目標
モデルは、いくつかの一般的な種類のアプリケーションにおける Office SharePoint Server 2007 機能の実用的な実装を示しています。ここでは、各アプリケーションのデザインの実装について説明します。モデルの主要なデザイン目標は以下のとおりです。
最小限のサーバー ファームを使用して、企業で通常必要とされる一般的な種類の Web サイト (イントラネット サイト、エクストラネット サイト、およびインターネット サイト) をホストします。
成長できる環境を設計するためのフレームワークを作ります。個々のアプリケーションのデザイン決定により、他のアプリケーションの追加が妨げられることはありません。たとえば、初期の展開には、グループ作業チーム サイトだけが含まれている場合もあれば、イントラネットを構成する 3 つのアプリケーション (チーム サイト、個人用サイト、および公開イントラネット コンテンツ) だけが含まれている場合もあります。同様の論理アーキテクチャ デザインを使用することにより、初期アプリケーションのデザインに影響を与えずに、ソリューションにアプリケーションを追加することができます。つまり、環境の使用を制限するようなデザイン選択は、デザインに組み込まれません。
さまざまなアプリケーション内のコンテンツのセキュリティを低下させることなく、複数のユーザー クラスにアクセスを提供します。認証プロバイダの異なる別々のネットワーク領域 (内部と外部の両方) のユーザーが、グループ作業に参加できます。また、ユーザーがアクセスできるのは、ユーザーによるアクセスを想定したコンテンツだけです。同様の論理アーキテクチャ デザインに従うことにより、異なった場所で作業する別々の目標を持ったさまざまなユーザーに、アクセスを提供する機会が生まれます。たとえば、初期デザインで内部の従業員のアクセスだけを想定する場合、同様のデザインを使用することにより、リモートの従業員、パートナーの従業員、および顧客に対しても、アクセスを提供する機会が生まれます。
デザインをエクストラネット環境で使用できるようにします。サーバー ファームを境界領域ネットワークに安全に展開できるよう、慎重なデザイン選択が行われます。
この記事の残りの部分では、モデルに現れる個々の論理コンポーネントについて上位から下位へと順に説明し、モデルに適用されるデザイン選択について説明します。この方法をとるのは、アプリケーションに基づいた論理アーキテクチャ コンポーネントのさまざまな構成方法を明らかにするためです。
サーバー ファーム
モデルには、2 つのサーバー ファームの使用が組み込まれています。ここでは、企業環境に必要なサーバー ファームの数に影響するライセンス要件について説明します。また、モデルに示すサーバー ファームのトポロジも記載します。
ライセンス要件
注意
以前のライセンス要件では、イントラネット コンテンツとインターネット サイトの両方をホストするには、少なくとも 2 台のサーバーが要件として指定されていました (ライセンスの種類ごとに 1 台のサーバー)。現在では、これはライセンス要件には含まれません。このセクションは更新され、2008 年 9 月に導入された新しいライセンス要件が反映されています。
Office SharePoint Server 2007 には 2 種類のサーバー ライセンスがあります。これらのライセンスを、同じサーバー コンピュータまたは同じサーバー ファームで併用できます。
Microsoft Office SharePoint Server 2007, Server License イントラネット コンテンツ用のライセンスです。このライセンスでは、クライアント アクセス ライセンス (CAL) を使用する必要があります。パートナーとのグループ作業に使用するサイトを作成する場合は、パートナーの従業員のために必要数の CAL を購入するようにしてください。
Microsoft Office SharePoint Server 2007 for Internet sites インターネット向け Web サイトを対象としたライセンスです。このライセンスに CAL は必要ありません。パートナーとのグループ作業に使用するサイトを作成する場合に、追加の CAL を購入する必要はありません。ただし、自社の従業員だけを対象にしたサイトは作成できません。
組織で利用する内部コンテンツや、従業員以外のユーザーが利用するインターネット用コンテンツを同じファームから展開しようと計画している場合は、そのファームについて両方のライセンスの種類を購入する必要があります。可能な展開シナリオに対応するために、単一の展開で Office SharePoint Server 2007 のニーズを統合しようとする顧客は両方の製品のライセンスを取得し、これらのライセンスを同じサーバーに割り当て、両方のライセンスで同時にソフトウェアの同じ実行インスタンスを使用できます。ただし、顧客は、インターネット サイト使用権用の Office SharePoint Server 2007 では一切許可されていないコンテンツにアクセスするユーザーおよびデバイスの Office SharePoint Server 2007 使用権で必要となる、CAL を取得する必要があります。
必要なサーバー ファームの数がライセンス要件によってどのような影響を受けるのかについては、「サーバー ファームを計画する」を参照してください。
サーバー ファームは 1 つだけ必要ですが、モデルでは、2 つのサーバー ファームの使用を示しています。1 つは内部コンテンツ用、もう 1 つは顧客向けコンテンツ用です。2 つの独立したファームを導入するように選択した場合、最も重要なデザイン選択は、パートナー Web アプリケーションをホストするファームを決定することです。モデルでは、サーバー ファーム A でイントラネット コンテンツをホストし、サーバー ファーム B で企業インターネット サイトをホストしています。 ライセンス条件に応じて、どちらのファームでもパートナー Web をホストできます。
2 つのファームを選択する場合、パートナー Web アプリケーションをホストするファームを決める際の一般的なデザイン指針は、以下のようになります。
グループ作業の性質 パートナー向けエクストラネット サイトの主な目的が、多くのパートナーに安全に情報を伝えることである場合は、インターネット サーバー ファームが最も経済的な選択です。逆に、主な目的がパートナーの従業員少数とグループ作業することである場合は、イントラネット サーバー ファームの方が優れた選択です。必要な役割 (グループ作業対読み取り専用コンテンツ) に合わせてファームを最適化できるオプションを選択してください。
パートナーの従業員の数 パートナーの従業員多数とグループ作業する場合、コストの最小化が重要であれば、Internet sites ライセンスのインターネット向けファームで、グループ作業コンテンツと匿名コンテンツの両方を安全にホストできます。
モデルでは、企業インターネット サイトの開発、ステージングなど、パートナー会社と集中的なグループ作業を行うことが、パートナー Web の目的となっています。パートナー Web をファーム A に配置すると、2 つのファームをそれぞれの目的の用途 (グループ作業か、読み取り専用コンテンツか) に合わせて最適化できます。
ライセンス要件の詳細を含めて、組織に適したファーム数の選択の詳細については、「サーバー ファームを計画する」を参照してください。
サーバー ファームのトポロジ
モデルのサーバー ファームは、それぞれ 5 台のサーバーから構成されています。サーバー ファームのトポロジは以下のとおりです。
2 台のフロントエンド Web サーバー
1 台のアプリケーション サーバー
2 台のデータベース サーバー (クラスタ化またはミラー化)
モデルを見ると、Office SharePoint Server 2007 の論理アーキテクチャは以下のようになっています。
すべてのサイトは、フロントエンド Web サーバー間でミラー化されています。
ユーザーの直接アクセスから保護するために、サーバーの全体管理サイトはアプリケーション サーバーにインストールされています。
実際は、サーバー コンピュータの数とサーバー ファームのトポロジは、必要に応じて容量を増やし、パフォーマンスを向上させるためには意味がありますが、論理アーキテクチャにとっては重要でありません。論理アーキテクチャは、サーバー ファームのトポロジとは別に設計できます。パフォーマンスと容量の計画プロセスは、パフォーマンスと容量の目標に合うよう、サーバー ファームのサイズを決めるために役立ちます。詳細については、「パフォーマンスと容量を計画する (Office SharePoint Server)」を参照してください。
ユーザー、領域、認証
モデルは、それぞれ別々の領域に割り当てられる 5 つの異なるユーザー クラスを示しています。各 Web アプリケーション内には、利用可能な領域名 (既定、イントラネット、インターネット、ユーザー設定、またはエクストラネット) のいずれかを使用して、最大 5 つの領域を作成できます。複数の Web アプリケーションをホストするファームは、5 つを超えるネットワーク領域からのユーザー要求に対応できます (Web アプリケーションあたり最大 5 領域)。ただし、モデルには 5 つの領域だけが示されています。
ユーザーと認証
モデルには、別々なネットワーク領域のユーザー、または、管理者である場合は権限の要件がそれぞれ大きく異なるユーザーが示されています。モデルは、ユーザーにどのように認証が適用されるかを表しています。各領域のユーザーの認証方法は、以下の表のとおりです。
| 領域 | ユーザー | 認証 |
|---|---|---|
ユーザー設定 |
管理者 |
Kerberos (統合 Windows) |
イントラネット |
内部の従業員 |
NTLM (統合 Windows) |
既定値 |
リモートの従業員 |
NTLM (統合 Windows)、または LDAP (ライトウェイト ディレクトリ アクセス プロトコル) を使用したフォーム認証 |
エクストラネット |
パートナーの従業員 |
フォーム認証 |
インターネット |
顧客 |
匿名 |
モデルでは、両方のサーバー ファームへのアクセスは、ユーザー全員には与えられていません。したがって、いずれのファームも 5 つの領域すべてを使用することはありません。
管理者
サイトへの安全な管理アクセスには、ユーザー設定領域が使用されます。この方法は、以下の機会を提供します。
独立した一連の URL およびポリシーを実装します。たとえば、管理者はユーザー設定領域に関連付けられた URL を使用して、領域のポリシーに従って管理作業を実行できます。その他すべての作業は、イントラネット URL を使用して、イントラネットを構成するアプリケーションに対して設定されたポリシーに従って実行できます。この方法では、2 つのコンテキストが分離され、ポリシーの権限が競合しないようになっています。
管理者用により安全な認証方法を実装します。これにより、ソリューション全体のセキュリティが強化されます。
サイトへのサポートが外部ベンダによって提供されるシナリオでは、別のプロバイダに対して認証を行います。
モデルは、管理者が Fabrikam の従業員であり、ネットワークへの内部アクセスを与えられていることを前提にしたものです。モデルには、管理者への統合 Windows 認証 (つまり、Kerberos 認証または NTLM) の使用が組み込まれています。
内部の従業員
内部の従業員のアクセスには、イントラネット領域が使用されます。統合 Windows 認証が使用されます。
リモートの従業員
リモートの従業員のアクセスには、既定領域が使用されます。モデルのデザイン目標は、以下のとおりです。
内部 Active Directory ディレクトリ サービス環境に対して認証を行います。
内部の従業員とリモートの従業員の両方に Windows 認証を使用することにより、権限管理を簡略化します。この目標が重要なのは、ユーザーが 2 つの異なる認証プロバイダを通じてサイトに接続する場合、Office SharePoint Server 2007 はユーザーごとに 2 つの異なるアカウントを作成し、2 つのアカウントそれぞれに権限を必要とするためです。
モデルには、リモートの従業員を認証するための 2 つの異なる選択肢が提示されています。1 番目の方法 (NTLM を使用した統合 Windows 認証) では、両方のデザイン目標が達成されます。2 番目の方法 (フォーム認証) では、最初の目標は達成されますが、2 番目の目標を実現できません。したがって、推奨されるのは 1 番目の方法です。
以下の表は、これら 2 つの方法の違いを要約したものです。
| 認証方法 | NTLM を使用した統合 Windows 認証 | LDAP プロバイダを使用したフォーム認証 |
|---|---|---|
動作のしくみ |
この方法では、ユーザーを認証するため、およびユーザー資格情報を Office SharePoint Server 2007 に送信するために、Internet Security and Acceleration (ISA) Server 2006 または Intelligent Application Gateway (IAG 2007) を使用します。これらのサーバーは、フォーム認証を使用して、Active Directory 環境に対するユーザーの認証を行います。そのうえで、Windows 資格情報を Office SharePoint Server 2007 に転送します。詳細については、次のリソースを参照してください。
領域が既定領域なので、NTLM 認証を使用してインデックス コンポーネントの要件が満たされます。詳細については、後の「既定領域の構成要件」を参照してください。 |
Office SharePoint Server 2007 は、LDAP プロバイダによるフォーム認証を使用して、内部 Active Directory 環境に対するリモートの従業員の認証を行います。 この方法を選択する場合は、インデックス コンポーネントが代替領域を通じて認証を行えるようにしてください。詳細については、後の「既定領域の構成要件」を参照してください。 |
長所 |
Office SharePoint Server 2007 は、内部とリモートの両方で作業するユーザーに、2 つの異なるアカウントを作成しません。これにより、権限管理が大幅に簡略化されます。 |
プロキシ サーバーがユーザーを認証して資格情報を転送する必要がありません。 |
短所 |
ISA Server 2006 または他のプロキシ サーバー製品について、追加の調整および構成が必要です。 |
ユーザーが内部とリモートの両方で Office SharePoint Server 2007 に接続する場合は、Office SharePoint Server 2007 で 2 つの異なるユーザー アカウントが作成されます。このため、両方のアカウントにサイトとドキュメントへの権限が必要になります。従業員は 2 つの個人用サイトを作成する可能性があります。内部ネットワークからの作業とリモートでの作業の両方を行う予定である場合、従業員は自分のサイトとドキュメントに対する両方のユーザー アカウントの権限を管理する必要があります。 |
パートナーの従業員
パートナーの従業員は、エクストラネット領域を通じてネットワークにアクセスし、フォーム認証を使用して認証されます。これには、パートナー アカウントをエクストラネットに保存するために、Microsoft SQL Server のデータベースとプロバイダなど、別のディレクトリとプロバイダが必要です。この方法の長所は、パートナー アカウントを別に管理することができ、内部の従業員のディレクトリにパートナー アカウントを追加する必要がないことです。
Web シングル サインオン (SSO) を使用して、パートナー自身のディレクトリに対する認証を行う方法もあります。ただし、この方法ではパートナー ディレクトリごとに別々の領域が必要です。
モデルは Fabrikam が同じパートナー アプリケーション内でさまざまな会社のパートナーとグループ作業していることを前提にしたものなので、フォーム認証が使用されています。ディレクトリとプロバイダは指定されません。
顧客
顧客のアクセスには、インターネット領域が使用されます。この領域は、読み取り専用の権限を持つ匿名アクセスを許可するように構成されます。
領域
領域を設計するときには、いくつかの重要な決定が展開の成功を左右します。これらの決定事項の中に、以下の領域のデザインと構成に関する決定があります。
既定領域
外部アクセス用の領域
この後のセクションでは、モデルに組み込まれている決定事項について説明します。
既定領域の構成要件
最も慎重な考慮を要する領域は既定領域です。Office SharePoint Server 2007 は既定領域の構成方法に以下の要件を設けています。
ユーザーの要求を領域と関連付けることができない場合は、既定領域の認証とポリシーが適用されます。したがって、既定領域は最も安全な領域である必要があります。
インデックス コンポーネントには、コンテンツをクロールするために、少なくとも 1 つの領域を通じたコンテンツへのアクセスが必要です。既定では、インデックス コンポーネントは NTLM 認証を使用します。SSP 管理者は、特定の範囲の URL をクロールする際に基本認証またはクライアント証明書を使用するように、クロール ルールを構成できます。したがって、コンテンツをクロールするには、少なくとも 1 つの領域を、NTLM 認証、基本認証、または証明書を使用するように構成する必要があります。また、クローラは、認証に使用できる領域が見つかるまで、既定領域、イントラネット領域、インターネット領域、ユーザー設定領域、エクストラネット領域の順に領域をポーリングします。ただし、Kerberos 認証を使用するように構成された領域が最初に見つかった場合、クローラは認証を行わず、次の領域へのアクセスを試みません。このため、Kerberos 認証を使用する領域の構成が、インデックス コンポーネントによるコンテンツのクロールを妨げないようにしてください。コンテンツのクロールに関連する認証要件の詳細については、「認証方法を計画する (Office SharePoint Server)」を参照してください。
管理用電子メールは、既定領域からのリンクを付けて送信されます。その一例が、クォータ制限に近づいているサイトの所有者に対する電子メールです。したがって、これらの種類の電子メールや通知を受信するユーザーは、既定領域を通じてリンクにアクセスできる必要があります。このことは、サイト所有者にとって特に重要です。
ホスト名が付いたサイト コレクションは、既定領域を通じてのみ利用できます。ホスト名が付いたサイト コレクションにアクセスすることを想定するすべてのユーザーには、既定領域を通じたアクセスが必要です。
モデルでは、以下の理由から、リモートの従業員のアクセスに既定領域が使用されています。
従業員は、作業する場所に関係なく、管理用電子メール内のリンクにアクセスできます。
ユーザーの要求に関連付けられた領域を判断できない場合に、内部サーバー名および URL が公開されないよう保護されます。既定領域は既にリモートの従業員用に構成されているため、この領域が適用された場合、URL によって機密データが公開されることはありません。
エクストラネット環境用の領域を構成する
エクストラネット環境では、以下の 2 つの理由から、領域のデザインがきわめて重要になります。
ユーザーの要求は、さまざまなネットワークから開始できます。モデルでは、ユーザーは内部ネットワーク、インターネット、およびパートナー会社から要求を開始します。
ユーザーは複数の Web アプリケーションでコンテンツを使用します。モデルでは、イントラネットは 3 つの異なる Web アプリケーションから構成されています。また、内部の従業員とリモートの従業員は、すべての Web アプリケーション (イントラネット、パートナー Web、および企業インターネット サイト) でコンテンツを投稿および管理する可能性があります。
エクストラネット環境では、以下のデザイン原則に従ってください。
複数の Web アプリケーションにまたがる領域は、互いにミラー化されるように構成します。認証の構成と対象ユーザーは、同じである必要があります。ただし、領域に関連付けられたポリシーは Web アプリケーション間で異なっていてもかまいません。たとえば、イントラネット領域は、どの Web アプリケーションでも同じ従業員に使用するようにします。つまり、イントラネット領域をある Web アプリケーションで内部の従業員用に構成し、別の Web アプリケーションでリモートの従業員用に構成することはしません。
各領域と各リソースについて、代替アクセス マッピングを適切かつ正確に構成します。
モデルでは、各 Web アプリケーションの既定領域は、等しく、リモートの従業員のアクセス用に構成されています。また、イントラネット領域は、どの Web アプリケーションでも等しく、内部の従業員のアクセス用に構成されています。エクストラネット領域とインターネット領域は、それぞれ 1 つの Web アプリケーション専用に構成されています。
代替アクセス マッピングは、領域を作成すると自動的に作成されます。ただし、Office SharePoint Server 2007 はファイル共有などの外部リソースのコンテンツをクロールするように構成できます。これらの外部リソースへのリンクは、代替アクセス マッピングを使用して、領域ごとに手動で作成する必要があります。たとえば、ファイル共有を内部 URL で内部ユーザーに公開するとします (file://)。このファイル共有は、同時に FTP リンクとして外部ユーザーに公開できます (ftp://)。こうすると、ユーザーはこれらのリソースを各自の領域のコンテキストに従って利用できます。ユーザーが検索結果でこれらのリソースへのリンクを受信したとき、そのリンクにはアクセスできます。
複数の Web アプリケーションにまたがる領域が互いにミラー化されていない場合は、外部リソースへのリンクが適切でないと、以下のリスクが生じます。
サーバー名、ドメイン ネーム システム (DNS) 名、および IP アドレスが、内部ネットワーク以外に公開される可能性があります。
ユーザーが Web サイトなどのリソースにアクセスできない可能性があります。
SSP
SSP は、Web アプリケーションの論理グループとそれらに関連するサイトに、一連の共通サービスとサービス データを提供します。サービスとサービス データには以下のものがあります。
個人用設定サービス
対象ユーザー
ビジネス データ カタログ
Excel Services
Office SharePoint Server Search
ポータル利用状況レポート
論理アーキテクチャに複数の SSP が必要かどうかを判断するために最も重要な条件は、コンテンツを分離する必要があるかについてです。たとえば、サーバー ファームで複数ユーザー クラス用のアプリケーションをホストする場合は、個別の SSP を使用することにより、ユーザー クラス間の分離を実現できます。
モデルには、以下のアプリケーションごとに別々の SSP が組み込まれています。
イントラネット
パートナー Web
顧客のインターネット Web サイト
.gif "企業展開用の SSP モデル")
イントラネット
イントラネットを構成する個別のアプリケーション 3 つ (公開イントラネット コンテンツ、個人用サイト、およびチーム サイト) は、1 つの SSP によってまとめられます。モデルに示すイントラネット アプリケーションは、アプリケーション間で情報を共有し、プロファイル データを利用するという業務上のニーズと、安全な分離とのバランス調整の一例です。
Web アプリケーションとアプリケーション プールによって、個々のアプリケーションが分離されます。個別のアプリケーション プールにより、プロセスの分離が確保されます。専用の Web アプリケーションにより、コンテンツの種類ごとに異なる権限ポリシーを実装する機会が得られます。
3 つのアプリケーションを 1 つの SSP の下にまとめると、すべてのアプリケーションで個人用設定と企業全体の検索に対応できます。
.jpg "共有サービス プロバイダのアーキテクチャ")
パートナー Web
パートナー Web アプリケーションに別の SSP を使用すると、イントラネット環境内の機密情報にパートナーのユーザーが検索やアクセスを行えません。以下の方法でこの SSP を構成して、サイト コレクション間をさらに分離することができます。
検索範囲を個別のサイト コレクションに制限します。
対象ユーザーを使用して、コンテンツの対象を特定のユーザー グループに限定します。
Stsadm コマンド ライン ツールを使用して、サイト コレクションのメンバであるユーザーだけを表示するように、ユーザー選択ウィンドウを構成します。この構成では、ユーザー名がわかっていれば任意のユーザーをディレクトリから追加できます。ただし、表示されるのはサイト コレクションに既に追加されているユーザーだけです。これにより、ユーザー ディレクトリをパートナーのユーザーがユーザー選択ウィンドウを通じて参照することを防止できます。
この構成を有効にするには、以下のコマンドを使用します。
Stsadm.exe -o setproperty –url https://server –pn "peoplepicker-onlysearchwithinsitecollection" -pv yes
この構成を無効にするには、以下のコマンドを使用します。
Stsadm.exe -o setproperty –url https://server –pn "peoplepicker-onlysearchwithinsitecollection" -pv no
SSP 内のサービスを構成して分離を実現することに加えて、以下の方法で権限を構成することを検討してください。
サイトへのアクセスを、特定のユーザーまたはグループに制限します。
SharePoint グループを使用して、コンテンツへのアクセスを承認します。
企業インターネット サイト
モデルでは、企業インターネット サイトを匿名ユーザーが利用できるようになっています。匿名ユーザーを対象とするサイトは、認証ユーザーを対象とするサイトから、常に分離されている必要があります。モデルの企業インターネット サイトには、以下の分離方法が使用されています。
個別のアプリケーション プールにより、プロセスの分離を確保します。
個別の Web アプリケーションにより、対象に応じてポリシーを適用できるようにします。
専用の SSP により、検索結果が匿名アプリケーションに制限されるようにします。
管理サイト
モデルでは、各管理サイトは専用のアプリケーション プールおよび Web アプリケーション内でホストされています。それぞれの管理 Web サイトの説明を次に示します。
共有サービス管理 Web サイト モデルは各 SSP の専用管理サイトを示しています。共有サービス管理サイトは、単一のサーバーまたは一連のサーバーに分離できません。これらのサイトは、自動的にすべてのフロントエンド Web サーバー間でミラー化されます。
サーバーの全体管理 Web サイト モデルでは、各サーバー ファームのサーバーの全体管理サイトがアプリケーション サーバーでホストされています。これにより、サイトがユーザーの直接アクセスから保護されます。パフォーマンス ボトルネックやセキュリティ低下により、フロントエンド Web サーバーの可用性に影響が出ている場合でも、サーバーの全体管理サイトは利用できます。
管理サイト用の負荷分散される URL は、モデルまたはこの記事には明記しません。推奨事項は以下のとおりです。
管理 URL でポート番号を使用する場合は、標準以外のポートを使用します。URL には既定でポート番号が含まれています。顧客向け URL では、通常、ポート番号を使用しませんが、管理サイトにポート番号を使用すると、これらのサイトへのアクセスを標準以外のポートに制限することにより、セキュリティを強化できます。
管理ドメインからのみ、管理サイトへのアクセスを許可します。
管理サイト用に個別の DNS エントリを作成します。
これらの推奨事項に加え、必要に応じて、サーバーの全体管理サイトを複数のアプリケーション サーバーにわたって負荷分散すると、冗長性を確保できます。
アプリケーション プール
通常は、個別のインターネット インフォメーション サービス (IIS) アプリケーション プールを実装することにより、コンテンツ間のプロセス分離が実現されます。アプリケーション プールは、複数のサイトが同じサーバー コンピュータで動作しながら、独自のワーカー プロセスと ID を保持するための 1 つの手段を提供します。攻撃者があるサイトの弱点を悪用してサーバーにコードを送り込み、他のサイトを攻撃する危険性が小さくなります。
実用的には、以下のシナリオにはそれぞれ専用のアプリケーション プールを使用することを検討します。
匿名コンテンツと認証コンテンツを区別します。
外部ビジネス アプリケーションのパスワードを保存し、外部ビジネス アプリケーションと通信するアプリケーションを分離します (たとえば、ビジネス データ カタログとの接続)。
サイトの作成、管理、およびコンテンツに関するグループ作業をユーザーが自由に行えるアプリケーションを分離します。
モデルではアプリケーション プールを以下のように使用しています。
各管理サイトは、専用のアプリケーション プールでホストされます。これは Office SharePoint Server 2007 の要件です。
イントラネット コンテンツは、2 つの異なるアプリケーション プールに分けられます。グループ作業コンテンツ (個人用サイトとチーム サイト) は、1 つのアプリケーション プールでホストされます。公開イントラネット コンテンツは、別のアプリケーション プールでホストされます。この構成は、ビジネス データ接続が使用される可能性が高い公開イントラネット コンテンツに、プロセスの分離を提供します。たとえば、多くの人事 (HR) サイトでは、従業員が各自の個人データにアクセスできるように、ビジネス データ接続を使用します。
パートナー Web アプリケーションは、専用のアプリケーション プールでホストされます。
企業インターネット サイトは、ファーム B にある専用のアプリケーション プールでホストされます。もしパートナーとのグループ作業に使用するコンテンツもこのファームでホストすることがあれば、これら 2 種類のコンテンツ (インターネットとパートナー) は 2 つの異なるアプリケーション プールでホストされます。
Web アプリケーション
Web アプリケーションは、SharePoint 製品とテクノロジによって作成され、使用される IIS Web サイトです。各 Web アプリケーションは、IIS のそれぞれ異なる Web サイトによって表現されます。Web アプリケーションにはそれぞれ固有のドメイン名を割り当てます。これにより、クロスサイト スクリプト攻撃を防ぐことができます。
一般的に、専用の Web アプリケーションは以下の目的で使用します。
+認証されるコンテンツを匿名コンテンツから分離する。モデルでは、企業インターネット サイトは専用の Web アプリケーションおよびアプリケーション プールでホストされています。
ユーザーを分離する。モデルでは、パートナー Web を専用の Web アプリケーションおよびアプリケーション プールでホストして、パートナーがイントラネット コンテンツにアクセスできないようにしています。
権限を適用する。専用の Web アプリケーションは、サーバーの全体管理の [Web アプリケーションのポリシー] ページを使用してポリシーに基づいて権限を適用する機会を提供します。たとえば、企業インターネット サイトのポリシーを作成して、1 つ以上のユーザー グループに書き込みアクセスを明示的に拒否することができます。Web アプリケーションのポリシーは、Web アプリケーション内の個々のサイトまたはドキュメントに対して構成された権限とは無関係に適用されます。
パフォーマンスを最適化する。アプリケーションは、類似するデータ特性を持つ他のアプリケーションと共に Web アプリケーションに配置した場合の方が、パフォーマンスが高くなります。たとえば、個人用サイトには、サイトの規模は小さいが、数が多いというデータ特性があります。一方、チーム サイトは、サイトの規模がきわめて大きく、数が少ないのが通常です。これら 2 種類のサイトを別々の Web アプリケーションに配置することにより、結果のデータベースは特性の類似するデータで構成されるようになり、その結果、データベースのパフォーマンスが最適化されます。モデルでは、個人用サイトとチーム サイトは、固有のデータ分離要件を持たず、同じアプリケーション プールを共有しています。それにもかかわらず、個人用サイトとチーム サイトを別々の Web アプリケーションに配置することにより、パフォーマンスを最適化しています。
管理性を最適化する。別々の Web アプリケーションを作成すると、サイトとベータベースも別々になるため、異なったサイト制限 (ごみ箱、有効期限、およびサイズ) を実装し、異なったサービス レベル契約を結ぶことができます。たとえば、組織内で最も重要な種類のコンテンツではない場合、個人用サイトのコンテンツの復元を急ぐ必要はありません。こうすると、個人用サイトのコンテンツを復元する前に、より重要なコンテンツを復元できます。モデルでは、個人用サイトを別の Web アプリケーションに配置して、管理者が成長を他のアプリケーションより厳しく管理できるようにしています。
サイト コレクション
サイト コレクションは、論理アーキテクチャと情報アーキテクチャの橋渡しをするものです。モデルのサイト コレクションのデザイン目標は、URL デザインの要件を満たすことと、コンテンツを論理的にグループ分けすることです。
URL デザインの要件を満たすために、Web アプリケーションにはそれぞれ単一のルートレベル サイト コレクションが含まれています。管理対象パスを使用して、トップレベル サイト コレクションの第 2 層が組み込まれています。URL 要件、および管理対象パスの使用の詳細については、後の「領域と URL」を参照してください。サイト コレクションの第 2 層より上位では、各サイトがサブサイトです。
以下の図は、チーム サイトのサイト階層を示しています。
.jpg "グループ作業サイトの論理アーキテクチャ")
ルートレベル サイト コレクションの要件を考えると、デザイン決定の中心になるのはサイト コレクションの第 2 層です。モデルには、アプリケーションの性質に基づいた選択が組み込まれています。
公開イントラネット コンテンツ
公開イントラネット コンテンツ アプリケーションに関する前提は、企業内の複数の部門が公開コンテンツをホストすることです。モデルでは、各部門のコンテンツがそれぞれ別のサイト コレクションでホストされています。この方法には、以下の長所があります。
各部門のコンテンツの権限を、その部門で独自に管理できます。
各部門のコンテンツを、専用のデータベースに保存できます。
複数のサイト コレクションを使用する方法には、以下の短所があります。
マスタ ページ、ページ レイアウト、テンプレート、Web パーツ、およびナビゲーションを、サイト コレクション間で共有できません。
サイト コレクション間でカスタマイズやナビゲーションを調整するために、より多くの手間がかかります。
イントラネット アプリケーションの情報アーキテクチャとデザインによっては、ユーザーに公開コンテンツをシームレスなアプリケーションであるように見せることができます。また、各サイト コレクションをそれぞれ別の Web サイトであるように見せることもできます。
個人用サイト
個人用サイトには明確な特性があり、個人用サイトを展開するための推奨事項は簡単です。モデルでは、個人用サイト アプリケーションに、http://my という URL のトップレベル サイトが組み込まれています。最初に作成されるトップレベル サイト コレクションは、個人用サイトのホスト テンプレートを使用します。管理対象パスが組み込まれており (ワイルド カードを使用した管理対象パスを使用)、このため、ユーザーが作成するサイトの数に制限はありません。管理対象パスより下位のすべてのサイトは、個人用サイトのホスト テンプレートを継承する独立したサイト コレクションです。URL には http://my personal/username という形式でユーザー名が追加されます。個人用サイトを以下の図に示します。
.jpg "個人用サイトの論理ネットワーク アーキテクチャ")
個人用サイト アプリケーションの設計の詳細については、「個人用サイト アーキテクチャを設計する」を参照してください。
チーム サイト
チーム サイト アプリケーション内のサイト コレクションを設計するには、以下の 2 つの方法があります。
チームが Self-Service Site Creation を使用してサイト コレクションを作成することを許可します。この方法の長所は、管理者がサポートしなくても、チームが必要に応じて簡単にサイトを作成できることです。ただし、この方法には以下に示す多くの短所があります。
高度な分類法を実装する機会が失われます。
アプリケーションの管理が複雑になる可能性があります。
サイトが放置されやすくなります。
1 つのサイト コレクションを共有できるはずの複数のプロジェクトやチームによるテンプレートやナビゲーションの共有が行えなくなります。
組織の活動状況に基づいて、組織に適した有限数のサイト コレクションを作成します。この方法では、SharePoint 管理者によってサイト コレクションが作成されます。サイト コレクションが作成された後で、チームが必要に応じてサイト コレクション内にサイトを作成できます。この方法では、チーム サイトの管理方法や成長の仕方に構造を提供する高度な分類法を実装する機会があります。サイト コレクションを共有するプロジェクトとチームがテンプレートやナビゲーションを共有する可能性も増えます。
モデルには 2 番目の方法が組み込まれており、このため、チーム サイトのサイト コレクション階層は、公開イントラネット コンテンツと類似しています。情報アーキテクチャの課題は、組織に適したサイト コレクションの第 2 層を作成することです。以下の表は、さまざまな種類の組織に対する推奨事項を示しています。
| 組織の種類 | 推奨するサイト コレクション分類法 |
|---|---|
製品開発 |
|
研究 |
|
高等教育機関 |
|
県議会事務局 |
|
企業法務を扱う弁護士事務所 |
|
製造 |
|
パートナー Web
パートナー Web は、範囲または期間が限定されたプロジェクトで、外部パートナーとのグループ作業に使用されることを目的としています。設計上、パートナー Web アプリケーション内のサイトは、他のサイトから参照されることを想定していません。パートナー Web には、以下の要件があります。
パートナーとのグループ作業に使用するサイトを、プロジェクトの所有者が簡単に作成できる。
パートナーやその他の参加者は、作業対象のプロジェクトだけにアクセスできる。
権限はサイト所有者によって管理される。
あるプロジェクトからの検索結果により、他のプロジェクトからのコンテンツが公開されない。
使用されなくなったサイトを、管理者が簡単に識別し、削除できる。
これらの要件を満たすために、モデルにはプロジェクトごとに 1 つのサイト コレクションが組み込まれています。これにより、以下の利点が得られます。
個別のサイト コレクションが、プロジェクト間に適切なレベルの分離を提供します。
Self-Service Site Creation を実装できます。
パートナー Web アプリケーションは企業インターネット サイトのコンテンツ開発に使用するサイト コレクションもホストするため、オーサリング用とステージング用の個別のサイト コレクションが作成されます。
企業インターネット サイト
企業インターネット サイトには、単一のルートレベル サイト コレクションが組み込まれています。このサイト コレクションの下のサイトは、すべてサブサイトです。この構造により、サイト内のページの URL が簡略化されます。以下の図は、企業インターネット サイトのアーキテクチャを示しています。
.jpg "論理展開アーキテクチャ")
コンテンツ データベース
コンテンツ データベースは、以下の 2 つの方法でデザインに組み込むことができます (モデルには、両方の方法が組み込まれています)。
適切なサイズの警告しきい値を使用して、コンテンツ データベースの目標サイズを設定します。サイズが警告しきい値に達したら、新しいデータベースを作成します。この方法では、サイト コレクションは、サイズ目標のみに基づいて利用可能なデータベースに自動的に追加されます。
サイト コレクションを特定のコンテンツ データベースに関連付けます。この方法では、1 つ以上のサイト コレクションを、他とは別に管理できる専用のデータベースに配置できます。
サイト コレクションを特定のコンテンツ データベースに関連付ける場合は、以下の方法を使用します。
Stsadm コマンド ライン ツールを使用して、特定のデータベースにサイト コレクションを作成します。
以下のデータベース容量設定を適用して、1 つのデータベースを単一のサイト コレクションだけに使用します。
[警告イベントが生成される前のサイト数] = 1
[このデータベースに作成できるサイトの最大数] = 1
以下の手順を実行して、専用のデータベースにサイト コレクションのグループを追加します。
Web アプリケーション内で、データベースを作成し、データベースの状態を [準備完了] に設定します。
他のすべてのデータベースの状態を [オフライン] に設定します。コンテンツ データベースがオフラインである間は、新しいサイト コレクションを作成できません。ただし、オフライン データベースの既存のサイト コレクションには、読み取り処理と書き込み処理の両方を実行できます。
サイト コレクションを作成します。作成したサイト コレクションは、自動的にデータベースに追加されます。
他のすべてのデータベースの状態を [準備完了] に戻します。
公開イントラネット コンテンツ
公開イントラネット コンテンツの場合、モデルには部署サイト コレクションごとに専用のデータベースが組み込まれています。
この方法では、各部署のコンテンツをその部署で独自に管理できます。
個人用サイト
個人用サイトの場合、モデルでは、規模効率を得るために、データベースを最大目標サイズまでに管理しています。このために、以下の設定が構成されています。
[サイト記憶域の最大サイズを次の値に制限する] この設定は、サーバーの全体管理の [クォータ テンプレート] ページで構成するもので、個人用サイトのサイズを制限します。
[削除済みデータ バックアップ] この設定は、[Web アプリケーションの全般設定] ページで構成するもので、削除済みデータ バックアップに割り当てられる追加の容量を決定します。
[このデータベースに作成できるサイトの最大数] この設定はデータベース作成時に構成します。前の 2 つの設定に指定する値から、サイト全体の許容サイズを計算します。次に、各データベースのサイズ目標に基づいて、データベースに収まるサイト数を決定します。
モデルのサイズ設定例は、目標のデータベース サイズ 100 GB、目標の個人用サイト サイズ 500 MB に基づいて、以下のようになっています。
サイトごとのサイト サイズ制限 = 500 MB
データベースの目標サイズ = 100 GB
サイトの最大数 = 200
サイト レベルの警告 = 150
サイト レベルの警告値に達したら、新しいデータベースを作成します。新しいデータベースを作成した後、新しい個人用サイトは、作成したデータベースと既存のデータベースに、いずれかのデータベースがサイトの最大数に達するまで交互に追加されます。
個人用サイトのデータベース設定の設計の詳細については、「個人用サイト アーキテクチャを設計する」を参照してください。
チーム サイト
チーム サイトの場合、モデルにはチーム サイト コレクションごとに専用のデータベースが組み込まれています。この方法では、バックアップ、復元、および移行のために、各チームのデータベースを独自に管理できます。また、プロジェクトの完了時に、プロジェクトに関連するデータベースを簡単にアーカイブできます。
パートナー Web
個人用サイトと同様に、パートナー Web では、規模効率を得るために、データベースを最大目標サイズ以内に管理しています。ただし、モデルでは、企業インターネット サイトのオーサリング サイト コレクションとステージング サイト コレクションも、パートナー Web がホストしています。したがって、データベース デザインには両方の方法が組み込まれています。
オーサリング サイト コレクションとステージング サイト コレクションを、それぞれ専用のデータベースでホストします。
データベース設定とサイズ設定を構成して、他のすべてのサイトとデータベースを管理します。
パートナー Web は専用の Web アプリケーションでホストされるため、作成されるサイトの種類により適したサイズ制限を設けることができます。モデルのサイズ設定は、以下のようになっています。
データベースの目標サイズ = 100 GB
サイトごとの記憶域クォータ = 5 GB
サイトの最大数 = 20
オーサリング サイト コレクションとステージング サイト コレクションを、専用のデータベースでホストします。
企業インターネット サイト
企業インターネット サイトのデザインで単一のサイト コレクションを使用することにより、この Web アプリケーションには単一のデータベースが使用されます。
領域と URL
モデルは、企業展開の複数のアプリケーション間で URL を調整する方法を示しています。
デザイン目標
URL のデザイン決定には、以下の目標が影響します。
URL 規則では、どの領域を通じてコンテンツにアクセスできるかを制限しません。
標準 HTTP および HTTPS ポート (80 および 443) を、モデルの全アプリケーションで使用できます。
ポート番号は URL に含まれません。稼働環境では、通常、ポート番号を使用しません。
デザイン原則
これらのデザイン目標を達成するために、以下のデザイン原則が適用されます。
ホスト名が付いたサイト コレクションは使用されません。ここで注意する必要があるのは、ホスト名が付いたサイト コレクションが、IIS のホスト ヘッダーとは異なることです。ホスト名が付いたサイト コレクションは、代替アクセス マッピングと連動しません。同じコンテンツに複数のドメイン URL を通じてアクセスするには、代替アクセス マッピング機能が必要です。このため、ホスト名が付いたサイトが使用されている場合、これらのサイトは既定領域からしか利用できません。また、代替アクセス マッピング機能は Secure Sockets Layer (SSL) のオフボックス ターミネーションをサポートしており、これを利用して、リモートの従業員のアクセスとパートナーの従業員のアクセスに、SSL (https) を使用できます。
各アプリケーションには、単一のルート サイト コレクションが組み込まれています。これは、代替アクセス マッピングを使用するための要件です。Web アプリケーションに複数のルート サイト コレクションが必要で、ユーザー アクセスに既定領域のみ使用することを予定している場合は、ホスト名が付いたサイト コレクションが適切な選択肢となります。
それぞれがトップレベル チームまたはトップレベル プロジェクトを表す、上位のサイト コレクションが複数含まれているアプリケーションの場合 (チーム サイトなど)、モデルには管理対象パスが組み込まれています。管理対象パスを使用すると、これらの種類のサイトの URL をより詳細に制御できます。
デザイン上の代償
デザイン目標を満たした結果、以下の代償が生じます。
URL が長くなります。
ホスト名が付いたサイト コレクションは使用されません。
負荷分散される URL を設計する
Web アプリケーションを作成するときに、アプリケーションに割り当てる負荷分散される URL を選択する必要があります。また、Web アプリケーション内に作成する領域ごとに、負荷分散される URL を作成する必要があります。負荷分散される URL には、プロトコル、スキーム、ホスト名、およびポート (使用する場合) が含まれます。負荷分散される URL は、すべての Web アプリケーションおよび領域にわたって一意である必要があります。このため、各アプリケーション、および各アプリケーション内の各領域に、モデル全体にわたって一意な URL が必要です。
イントラネット
イントラネットを構成する 3 つのアプリケーションそれぞれに一意な URL が必要です。モデルでは、イントラネット コンテンツの対象ユーザーは、内部の従業員とリモートの従業員です。以下の表は、内部の従業員とリモートの従業員が各アプリケーションにアクセスするための URL を示しています。
| アプリケーション | 内部の従業員の URL | リモートの従業員の URL |
|---|---|---|
公開イントラネット コンテンツ |
http://fabrikam |
https://intranet.fabrikam.com |
チーム サイト |
http://teams |
https://teams.fabrikam.com |
個人用サイト |
http://my |
https://my.fabrikam.com |
パートナー Web
モデルでは、パートナー Web に内部の従業員、リモートの従業員、およびパートナーの従業員がアクセスします。リモートの従業員とパートナーの従業員は、どちらも外部から 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 です。
ワイルド カードを使用した管理対象パス URL に追加されるパス。このパスは、パス名の直後に指定されるすべてのサイトが、一意なサイト コレクションであることを示しています。この方法は、個人用サイトなど、Self-Service Site Creation をサポートするアプリケーションに通常使用されます。この方法で作成されるサイト コレクションの URL の一例は、http://my/personal/user1 です。
この後のセクションで説明するように、モデルには両方の種類の使用が組み込まれています。
明示的な管理対象パス : チーム サイトと公開イントラネット コンテンツ
モデルでは、チーム サイト アプリケーションと公開イントラネット コンテンツ アプリケーションの両方に、明示的な管理対象パスの使用が組み込まれています。
チーム サイト
チーム サイト アプリケーションでは、各チーム サイト コレクションに明示的な管理対象パスが使用されます。明示的な管理対象パスを使用して作成されるサイト コレクションの規模の限界は、おおよそ 100 サイトです。健全な運営のためには、トップレベル チーム サイトの数は、扱いやすい数を超えないよう維持することをお勧めします。また、チーム サイトの分類法は、組織の活動状況に適したものである必要があります。通常は、推奨する 100 サイトで十分に間に合いますが、より大規模なチーム サイトが必要な場合は、ワイルド カードを使用した管理対象パスを使用します。
モデルでは、明示的な管理対象パスの使用により、URL は以下の表のようになります。
| 内部の従業員 (イントラネット領域) | リモートの従業員 (既定領域) |
|---|---|
http://team/Team1 |
https://team.fabrikam.com/Team1 |
http://team/Team2 |
https://team.fabrikam.com/Team2 |
http://team/Team3 |
https://team.fabrikam.com/Team3 |
この例で、ルート サイト コレクション http://team は必ずしもユーザー用コンテンツをホストしません。
公開イントラネット コンテンツ
公開イントラネット コンテンツ アプリケーションでは、人事 (HR)、施設 (Facilities)、および購買 (Purchasing) の各サブサイトに明示的な管理対象パスが使用されます。これにより、これらの各サイトを独自に管理できます。これらのサイト コレクションに、必要に応じてそれぞれ異なるコンテンツ データベースを関連付けることにより、成長を管理することや、これらのサイトを別々にバックアップおよび復元する機会を提供することができます。
モデルでは、明示的な管理対象パスの使用により、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 と個人用サイトには、ワイルド カードを使用した管理対象パスの使用が組み込まれています。ワイルド カードを使用した管理対象パスは、ユーザーが各自のサイト コレクションを作成することを許可するアプリケーションに適しています。ワイルド カードを使用した管理対象パスは、ワイルド カードの後の項目がサイト コレクションのルート サイトであることを示しています。
個人用サイト
個人用サイトには、Self-Service Site Creation 機能があります。イントラネットを参照しているユーザーが初めて [個人用サイト] をクリックすると、そのユーザーの個人用サイトが自動的に作成されます。モデルでは、個人用サイトに /personal というワイルド カードを使用した管理対象パスが含まれています (http://my/personal)。個人用サイトの機能によって、ユーザー名が URL に自動的に追加されます。
この結果、URL の形式は以下の表のようになります。
| 内部 (イントラネット領域) | リモートの従業員 (既定領域) |
|---|---|
http://my/sites/user1 |
https://my.fabrikam.com/personal/user1 |
http://my/sites/user2 |
https://my.fabrikam.com/personal/user2 |
http://my/sites/user3 |
https://my.fabrikam.com/personal/user3 |
パートナー Web
パートナー Web は、外部のパートナーとグループ作業するための安全なサイトを、従業員が簡単に作成できることを目的としています。この目標を支援するために、Self-Service Site Creation が許可されています。
モデルでは、パートナー 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 の例外は、モデルに示すように、企業インターネット サイト用のコンテンツをオーサリングおよびステージングするために専用に設けられた 2 つのサイト コレクションです。これら 2 つのサイト コレクションには、明示的な管理対象パスが使用されています。これは、同じ Web アプリケーションで明示的な管理対象パスとワイルド カードを使用した管理対象パスの両方を使用する一例です。
管理用 URL
以下の表は、サーバー ファームでホストされる各アプリケーションの管理用領域の URL を示しています。
| アプリケーション | URL |
|---|---|
公開イントラネット コンテンツ |
http://fabrikam.admin |
チーム サイト |
http://teams.admin |
個人用サイト |
http://my.admin |
パートナー Web |
http://partnerweb.admin |
企業インターネット サイト |
http://fabrikamsite.admin |
モデルは、管理者が企業ネットワークへの内部アクセスを与えられていることを前提にしたものです。
領域ポリシー
Web アプリケーションのポリシーを作成して、Web アプリケーション レベルで権限を適用することができます。ポリシーは、Web アプリケーション全体に対して、または特定の領域のみに対して定義できます。ポリシーによって権限が適用されるのは、Web アプリケーションまたは領域内のすべてのコンテンツです。ポリシーの権限は、サイトとコンテンツに対して構成された他のすべてのセキュリティ設定より優先されます。ポリシーはユーザーまたはユーザー グループに基づいて構成できますが、SharePoint グループに基づいて構成することはできません。
モデルにあるさまざまなポリシーの例は、以下のことを達成しています。
管理者がすべてのコンテンツにアクセスすることを許可する。
公開コンテンツへの書き込みアクセスを拒否する。
作成者とテスト担当者に、公開コンテンツへの適切なアクセスを与える。
このブックをダウンロードする
このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なブックに収められています。
入手できるすべてのブックの一覧については、「Office SharePoint Server 2007 のダウンロード可能なブック」を参照してください。