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