SharePoint Server の設計サンプル: 企業ポータルおよびエクストラネットサイト

2023-03-08

適用対象: yes-img-13 2013 yes-img-16 2016 yes-img-19 2019 yes-img-se Subscription Edition no-img-sop SharePoint in Microsoft 365

この記事では、SharePoint サイトの出発点となるアーキテクチャとして使用できるいくつかの設計サンプルについて説明します。この記事で説明している設計サンプルは、会社や組織内で展開する一般的な種類の SharePoint サイトの標準アーキテクチャを示しています。

重要

この記事の情報は、SharePoint Foundation 2013 と SharePoint Server に適用されます。ただし、この記事では個人用サイトやエンタープライズ検索など、SharePoint Foundation 2013 では使用できない特定の機能について説明しています。

設計サンプルについて

この記事では、以下の設計サンプルについて説明します。

設計サンプルは、Fabrikam, Inc という架空の会社のサイトを示しています。設計サンプルは、ほぼすべての論理アーキテクチャコンポーネントを適用し、これらを全体的な設計にどのように組み込むかを示しています。この記事では、サンプルの設計目標について説明し、サンプルに示されている論理アーキテクチャコンポーネントがこれらの目標を達成した方法について説明します。

注:

モデルのタイトルには SharePoint 2013 とありますが、SharePoint Server 2016 にも適用されます

企業ポータル設計サンプル — 2 つのバージョン

SharePoint Server のホスト名付きサイトコレクションは、1 つの Web アプリケーション内のサイトの URL 管理とスケーラビリティを提供します。企業ポータル設計サンプルの 2 つのバージョンでは、従来のパスベースのサイトコレクションまたはホスト名付きサイトコレクションの使用に基づく実装を示しています。これらの設計サンプルはどちらも単一領域でのクレームベース認証を使用します。この記事では、これらのサンプルについてさらに詳しく説明しています。

代替アクセスマッピングを備えたパスベースのサイトの要件がない限りは、ホスト名付きサイトコレクションに基づく設計を使用することをお勧めします (詳細は、「Host-named site collection architecture and deployment (SharePoint 2013)」をご覧ください)。この設計は、Microsoft 365 環境で使用されるアーキテクチャと同じであるため、推奨されます。そのため、これは最もテストの厳しい構成です。新しい機能 (アプリモデルや依頼管理など) はこの構成に対して最適化されているため、これが今後に向けて最も信頼性のある構成になります。

認証の専用領域を使用するエクストラネット

認証の専用領域を使用するエクストラネット設計サンプルには、パートナー Web サイトのみが含まれます。パートナーとのグループ作業用の代替構成が用意され、各認証方法に専用の領域が使用されます。各設計サンプルでは、Web アプリケーションのクレームモード認証を使用します。企業ポータル設計サンプルとエクストラネット設計サンプルの違いは、領域の構成方法にあります。認証の専用領域を使用するエクストラネット設計サンプルでは複数の領域を使用し、各領域につき 1 つの認証方法が構成されます。企業ポータル設計サンプルでは 1 つの領域を使用して、異なるクラスのユーザーに対する複数の認証方法が構成されます。

認証用の専用ゾーンを備えたエクストラネットの設計サンプルでは、リモート従業員アクセスに関する新しい推奨事項 (Windows Server 2012 を使用した直接アクセス) も紹介されています。この推奨方法に対する代替策では、仮想プライベートネットワーク (VPN) を作成します。また、必要に応じてファイアウォールまたはゲートウェイ製品でフォームベース認証を使用して、資格情報を収集および転送できます。

設計サンプルでのサイトコレクションの実装方法

以前のバージョンの企業ポータル設計サンプルではパスベースのサイトコレクションを使用していましたが、代替アクセスマッピング (AAP) を使用した従来のパスベースのサイトの必要性が要件に含まれていない限り、今後はホスト名付きサイトコレクションをお勧めします。これは、設計サンプルに次のように反映されています。

パスベースのサイトコレクションを使用する企業ポータル — このサンプルは、従来型のパスベースのサイトコレクションを示し、サイトは専用の Web アプリケーションと Web アプリケーションごとに 1 つのトップレベルサイトコレクションに編成されます。複数の Web アプリケーションと個別のアプリケーションプールによって実現する追加のセキュリティが必要な場合は、この方法を使用します。
ホスト名付きサイトコレクションを使用する企業ポータル — このサンプルは、ホスト名付きサイトコレクションの使用を示し、すべてのサイトはファームの単一の Web アプリケーションに展開されます。この方法は非常にスケーラブルであり、URL 管理の柔軟性が向上します。
認証用の専用ゾーンを持つエクストラネット - このサンプルでは、(最上位のサイトコレクションの下にプロジェクトサイトを整理するのではなく) プロジェクトサイトごとにホスト名付きサイトを使用して、バニティ URL を持つ多くのトップレベルのプロジェクトサイトを示します。この方法でホスト名付きサイトコレクションを使用する利点の 1 つは、パートナーコラボレーションソリューションで必要になる可能性があるドメイン URL 間の分離を追加することです。ただし、この方法のトレードオフは、SSL 証明書の管理など、より多くのホスト名を管理するための追加コストです。また、SAML 認証を使用する場合は、追加の構成が必要です (この記事の後半の「ホスト名付きサイトでの SAML 認証の使用」を参照してください)。

SharePoint Server のクレームベース認証

SharePoint Server に対して認証が機能する方法は、これらの設計サンプルで表される選択肢の実装に関連する設計上の決定に影響を与える可能性があります。次に、いくつかの例を示します:

SharePoint Server では、要求ベースの認証が既定のモードであり、サーバーの全体管理で使用できる唯一のオプションです。クラシックモード認証は、PowerShell を使用して実装できます。
SharePoint Server では、SAML 要求認証を使用するようにロードバランサーでサーバーアフィニティを構成する必要はありません。 SharePoint Server では、アフィニティ以外の負荷分散が完全にサポートされています。

SharePoint Server では、検索クロールアカウントでは、統合 Windows 認証 (NTLM または Kerberos) を使用して、既定のゾーンを介してコンテンツにアクセスする必要があります。クレームベース認証では 1 つの領域で複数の種類の認証を使用できるため、この要件は他の認証要件に影響しません。

設計サンプルの機能の概要

次の表に、この記事で説明している 3 つの設計サンプルの概要を示します。

表: 設計サンプルの概要

設計サンプル	含まれる内容	主な設計要素
パスベースのサイトを使用する企業ポータル	組織内に展開される最も一般的な種類のサイト。	パスベースのサイトコレクションクレームベース認証複数の認証プロバイダーと認証の種類が 1 つの領域に実装されています。
ホスト名付きサイトを使用する企業ポータル	組織内に展開される最も一般的な種類のサイト。	ホスト名付きサイトコレクションクレームベース認証複数の認証プロバイダーと認証の種類が 1 つの領域に実装されています。
認証の専用領域を使用するエクストラネット	パートナー Web サイトのみ。パートナーとのグループ作業用の代替構成が用意されています。	ホスト名付きサイトコレクションクレームベース認証各認証方法用の異なる領域

設計サンプルに含まれるサイト

ここでは、設計サンプルに含まれるトップレベルサイトについて説明します。

イントラネットサイト

企業ポータルには、イントラネットで使用する以下のサイトが含まれています。

公開されたイントラネットコンテンツ (HRweb など)
グループ作業チームサイト
個人用サイト

これらは、従業員が日常的に使用するコンテンツとコラボレーションサイトです。これらのアプリケーションはそれぞれ個別の種類のコンテンツを表します。コンテンツの種類ごとに、次のプロパティがあります。

SharePoint Server の異なる機能を重視します。
異なったデータ特性を持つデータをホストします。
異なる使用プロファイルに従います。
異なる方法の権限管理が必要です。

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

サービスアプリケーションの設計では、これら 3 つのアプリケーションの統合により以下の機能が提供されます。

企業全体の検索
共有のプロファイルデータとエンタープライズメタデータ

次の図は、パスベースのサイトコレクションを使用する企業ポータル設計サンプルからのものですが、企業イントラネットを構成する 3 種類のサイトを示しています。

企業イントラネットを構成するサイトの種類

イントラネットサイト

パートナー Web アプリケーション

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

エクストラネット設計サンプルでは、この種類のサイトのみが表示されます。

全体的な設計目標

設計サンプルでは、いくつかの一般的な種類のサイト内で SharePoint Server 機能の実用的な実装を提供します。この記事では、各アプリケーションの設計の実装について説明します。設計サンプルの主要な設計目標は以下のとおりです。

成長できる環境を設計するためのフレームワークを作成します。

個々のサイトの種類の設計上の決定によって他の種類のサイトの追加が妨げられることはありません。たとえば、初期の展開には、グループ作業チームサイトだけが含まれている場合もあれば、イントラネットを構成する 3 種類のサイト (チームサイト、個人用サイト、公開イントラネットコンテンツ) だけが含まれている場合もあります。同様の論理アーキテクチャ設計を使用する場合は、初期ソリューションの設計に影響を与えずに、ソリューションにサイトを追加できます。つまり、環境の使用を制限するような設計上の選択は、設計に組み込まれません。
異なる種類のサイト内でコンテンツのセキュリティを侵害することなく、複数のユーザーグループにアクセス権を付与します。

異なる認証プロバイダーを使用する、異なるネットワーク領域からのユーザー (内部および外部の両方) がグループ作業に参加できます。また、ユーザーはアクセスを意図しているコンテンツにのみアクセスできます。同様の論理アーキテクチャ設計に従うと、複数の場所に配置され異なる目的を持つユーザーにアクセス権を付与できます。たとえば、初期設計では内部の従業員のアクセスのみを意図している場合があります。ただし、同様の設計を使用すると、リモートの従業員、パートナーの従業員、パートナー会社、顧客のアクセス権を有効にできます。
エクストラネット環境内で設計を確実に使用できるようにします。

設計上の選択を計画的に行い、境界ネットワーク内でソリューションを安全に展開できるようにします。

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

サーバーファーム

ここでは設計サンプルに示したサーバーファームのトポロジと、単一ファームを超えたスケーリングについて説明します。

サーバーファームのトポロジ

設計サンプルのサーバーファームは、それぞれ 6 台のサーバーで構成されています。フォールトトレラントのトポロジは以下のとおりです。

2 台のフロントエンド Web サーバー
2 台のアプリケーションサーバー
SQL Server クラスタリング、ミラーリング、または Always On をサポートするように SQL Server がインストールされ、構成されている 2 つのデータベースサーバー。 Always On には SQL Server 2012 が必要です。

フロントエンドサーバーとアプリケーションサーバーの概念は、SharePoint Server 2016 では異なります。「SharePoint Server の MinRole Server ロールの概要」を参照してください。

設計サンプルでは以下を示すことによって、SharePoint Server の論理アーキテクチャを示します。

すべてのサイトは、フロントエンド Web サーバー間でミラー化されています。
ユーザーの直接アクセスから保護するために、サーバーの全体管理サイトはアプリケーションサーバーにインストールされています。

実際は、サーバーコンピューターの数とサーバーファームのトポロジは、容量を増やし、パフォーマンスを向上させる場合にのみ、論理アーキテクチャにとって意味を持ちます。論理アーキテクチャは、サーバーファームトポロジとは関係なく設計できます。パフォーマンスと容量の計画プロセスは、パフォーマンスと容量の目標に合わせてサーバーファームのサイズを計画するために役立ちます。詳細については、「 SharePoint Server 2013 でのパフォーマンス計画」を参照してください。

ユーザー、領域、認証

要求は SharePoint Server の認証の既定のモードであり、各設計サンプルにはクレームベースの認証が組み込まれています。 Windows PowerShell を使用して、クラシックモード認証を実装できます。ただし、SharePoint Server の一部の機能はクラシックモードでは使用できません。クラシックモード認証を組み込んだ設計サンプルの詳細については、「デザインサンプル: 企業展開 (SharePoint Server 2010)」を参照してください。

次の表に、企業ポータル設計サンプルとエクストラネット設計サンプルで表される 2 つの方法の違いを示します。

表: 設計サンプルの領域の構成方法の比較

方法	ホスト名付きサイトを使用する企業ポータルとパスベースのサイトを使用する企業ポータル	認証の専用領域を使用するエクストラネット
認証方法	クレーム	クレーム
領域構成	異なるクラスのユーザーに対して複数の認証方法が構成された 1 つの領域。	領域ごとに 1 つの認証方法が構成された複数の領域。
URL	すべてのクラスのユーザーは各サイトの同じ URL を使用します。企業ネットワークの内部にいるかリモートで作業しているかどうかに関係なく、従業員は同じ URL を使用します。	各クラスのユーザーは異なる URL を使用してサイトにアクセスします。従業員は企業ネットワークの内部にいるかリモートで作業しているかによって、異なる URL を使用します。
内部要求	企業ネットワーク内部で開始された要求は、ネットワーク外部にルーティングされ、ゲートウェイまたはプロキシサーバーを通じて戻ります。これらの要求は Secure Sockets Layer (SSL) プロトコルを使用して保護されています。または、スプリット DNS を使用してサーバーの内部インターフェイスに要求を直接ルーティングすることもできます。	企業ネットワーク内部で開始された要求は、ネットワーク内部に留まります。
ユーザーエクスペリエンス	すべてのユーザーは、ログインに使用するアカウントの種類を選択するように求められます。	認証方法は事前に定義されています。ログオンページでアカウントの種類を選択する必要はありません。

以下のセクションでは、2 つの異なる方法を使用して認証がどのように組み込まれているかについて具体的に説明します。

専用領域を使用するエクストラネット設計サンプル

エクストラネット設計サンプルではユーザーの 3 つの異なるクラスが示されていますが、これらはそれぞれ別の領域に割り当てられています。各 Web アプリケーション内には、利用可能な領域名 (既定、イントラネット、インターネット、ユーザー設定、またはエクストラネット) のいずれかを使用して、最大 5 つの領域を作成できます。検索クロールアカウントは統合 Windows 認証 (NTLM または Kerberos プロトコル) を使用して、既定領域を通じてコンテンツにアクセスする必要がありますが、これは設計サンプルで説明されています。次の表に、エクストラネット設計サンプルでの領域の設定方法を示します。

表: エクストラネット設計サンプルに規定された領域、ユーザー、認証の種類

領域	ユーザー	認証
イントラネット	内部の従業員とリモートの従業員検索クロールアカウント	NTLM または Kerberos プロトコル直接アクセスまたは VPN を使用して接続するリモートの従業員
既定	個人パートナー	オプション: フォームベース認証を使用する LDAP ディレクトリ内部フォレストへの一方向の信頼と統合 Windows 認証を使用する、外部向け Active Directory Domain Services (AD DS) フォレスト SAML 認証を使用する信頼できる ID プロバイダー
エクストラネット	パートナー会社	SAML 認証を使用する信頼できるパートナー ID プロバイダー

企業ポータル設計サンプル

クレームベース認証では、同じ領域で複数の種類の認証を使用できます。 2 つのバージョンの企業ポータル設計サンプルでは、すべての認証の種類に既定領域を使用します。

次の表に、設計サンプルに規定された領域、ユーザー、認証の種類を示します。

表: 企業ポータル設計サンプルの領域、ユーザー、認証

ゾーン	ユーザー	プロバイダーと認証の種類
Default	内部の従業員とリモートの従業員	フォームベース認証または SAML 認証を使用する Active Directory Domain Services (AD DS) または LDAP ストア
既定	個人パートナー	SAML 認証を使用する信頼できる ID プロバイダー、またはフォームベース認証を使用する SQL Server データベース
Default	パートナー会社	SAML 認証を使用する信頼できるパートナー ID プロバイダー
既定	検索クロールアカウント	Windows NTLM 認証を使用する AD DS

デザインサンプルでは、発行済みのイントラネットコンテンツサイト、チームサイト、個人用サイトにアクセスできるのは、従業員がネットワークの内部か外部かを問わずのみです。設計サンプルでは、内部と外部の両方で使用できるこれらのサイトごとに 1 つの URL (SSL を使用) のみを実装しています。 AD DS アカウントが使用されます。必要に応じて、フォームベースの認証または SAML で LDAP を使用できます。これには追加の構成が必要です。

設計サンプルでは、パートナー Web アプリケーションはパートナーの従業員およびパートナー会社がアクセスできるエクストラネットサイトを表しています。このシナリオのクレームベース認証では、1 つ以上の外部 ID プロバイダーとの信頼を構成する必要があります。以下のいずれかの方法を使用できます。

パートナー企業に配置されたプロバイダーなどの外部 ID プロバイダーを信頼するように SharePoint ファームを構成できます (パートナーディレクトリに対して直接認証を行います)。
企業環境内の ID プロバイダーが外部 ID プロバイダーを信頼するように構成できます。 2 つの組織の管理者は、この関係を明示的に設定する必要があります。このシナリオでは、SharePoint ファームは自社の企業環境内の ID プロバイダーを信頼します。 ID プロバイダーがトークンを送信すると、ファームでは信頼が確立された際に指定された証明書に署名するトークンを使用して、トークンの妥当性を確認します。この方法をお勧めします。

フォームベース認証は、パートナーを認証するためのクレームベース環境の代替策です。これらのアカウントを管理するには、データベースなどの個別のストアを使用します。

領域

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

既定領域
外部アクセス用の領域

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

既定領域の構成要件

最も慎重な考慮を要する領域は既定領域です。 SharePoint Server では、既定のゾーンの構成方法に関して次の要件が満たされます。

ユーザーの要求を領域と関連付けることができない場合は、既定領域の認証とポリシーが適用されます。したがって、既定領域は最も安全な領域である必要があります。
管理用電子メールメッセージには、既定領域からのリンクが含まれています。その一例が、クォータ制限に近づいているサイトの所有者に対するメッセージです。したがって、これらの種類のメッセージや通知を受信するユーザーは、既定領域を通じてリンクにアクセスできる必要があります。このことは、サイト所有者にとって特に重要です。

SharePoint Server では、ホスト名付きサイトコレクションに任意の領域からアクセスできます。

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

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

複数の異なるネットワークがユーザー要求を開始できます。設計サンプルでは、ユーザーは内部ネットワーク、インターネット、パートナー会社から要求を開始します。
ユーザーは複数の Web アプリケーションでコンテンツを使用します。設計サンプルでは、イントラネットは 3 つの Web アプリケーションから構成されています。また、内部の従業員とリモートの従業員は、パートナー Web アプリケーションでコンテンツを投稿および管理する可能性があります。

エクストラネット環境に複数の領域が含まれている場合は、以下の設計原則に必ず従ってください。

複数の Web アプリケーションにまたがる領域は、互いにミラー化されるように構成します。認証の構成と対象ユーザーは、同じである必要があります。ただし、領域に関連付けられたポリシーは Web アプリケーション間で異なっていてもかまいません。たとえば、イントラネット領域は、どの Web アプリケーションでも同じ従業員に使用するようにします。つまり、イントラネット領域をある Web アプリケーションで内部の従業員用に構成し、別の Web アプリケーションでリモートの従業員用に構成することはしません。
パスベースのサイトコレクションを使用する場合は、各領域と各リソースについて、代替アクセスマッピングを適切かつ正確に構成します。代替アクセスマッピングは、領域を作成すると自動的に作成されます。ただし、ファイル共有などの外部リソースのコンテンツをクロールするように SharePoint Server を構成できます。これらの外部リソースへのリンクは、代替アクセスマッピングを使用して領域ごとに手動で作成する必要があります。
ホスト名付きサイトコレクションを使用する場合は、PowerShell を使用して URL を適切な領域にマップするようにします。

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

サーバー名、ドメインネームシステム (DNS) 名、IP アドレスが、内部ネットワークの外に公開される可能性があります。
ユーザーが Web サイトなどのリソースにアクセスできない可能性があります。

ホスト名付きサイトで SAML 認証を使用する

ホスト名付きサイトでの SAML 認証の使用が設計に含まれている場合、各バニティ URL では以下が必要になります。

SPTrustedIdentityTokenIssuer の新しい領域
ID プロバイダー内の対応する証明書利用者

サービス

サービスアーキテクチャは設計サンプルによって異なります。ホスト名付きサイトを使用する企業ポータル設計サンプルには、サービスの最も単純なアーキテクチャが含まれています。これは、使用する Web アプリケーションが 1 つであり、1 つのサービスアプリケーショングループ (プロキシグループとも呼ばれる) にのみ対応できるためです。

パスベースのサイトを使用する企業ポータルの例では、パートナーサイトのパーティション分割されたサービスを使用してプロジェクト間でデータを分離します。この設計サンプルには 2 つのサービスグループが組み込まれており、1 つはイントラネットサイト用、もう 1 つはパートナーとのグループ作業用サイト用です。パートナーサイトには管理されたメタデータおよび Search の個別のインスタンスが展開され、これらのサービスはパーティション分割されています。パーティション分割されたサービスには、PowerShell を使用してのみデプロイできるサブスクリプション設定サービスが必要です。

パスベースのサイトを使用する企業ポータルのサービスアーキテクチャ

サービスアーキテクチャ

パーティション分割されたサービスを展開すると、アーキテクチャが複雑になり、後でサイトを Microsoft 365 に移行するのが困難になります。パートナーサイトのより単純なオプションは、Managed Metadata Service と Search Service を分離する必要がある場合に、パーティション分割されていない、これらの専用のインスタンスを展開することです。多くの組織では、Search Service の専用インスタンスを展開する代わりに Search のセキュリティによるトリミング機能に依存しています。

エクストラネット設計サンプルにはプロキシグループが 1 つのみ含まれていますが、Managed Metadata Service アプリケーションおよび Search Service アプリケーションのパーティション分割されたサービスも使用されます。

サービスアプリケーションの展開に関する設計上の最も重要な決定事項は、組織の分類 (タクソノミー) をどこまで広げるかという点です。サービスアーキテクチャを単純化するには、すべての Web アプリケーションの間で管理されたメタデータ、User Profile、Search を共有し、セキュリティによるトリミングを利用してコンテンツへのアクセスを管理します。パスベースのサイトを使用する企業ポータル設計サンプルでは、すべてのサイト間で Managed Metadata Service の 1 つのインスタンスが共有されます。ただし、この構成では、すべてのユーザーが企業の分類にアクセスできます。ソリューションアーキテクトは Managed Metadata Service の複数のインスタンスを実装するかどうかを決定する必要があります。また、ユーザープロファイルデータを共有する範囲を決定する必要もあります。

パスベースのサイトコレクションを使用する企業ポータルのサンプルでは、パートナー Web がカスタムサービスグループを使用して、専用の Search Service アプリケーションと Managed Metadata Service アプリケーションを使用するように構成されています。他のサービスアプリケーションはカスタムグループに追加され、既定のグループと共有されます。設計サンプルには、パートナーユーザーが組織内のユーザーデータを参照できないようにする User Profile Service アプリケーションは含まれていません。

ホスト名付きサイトコレクション (1 つのサービスグループ) を使用する企業ポータルの単純化されたアーキテクチャでは、パートナーが企業の分類全体にアクセスし、組織内のユーザーデータを参照できます。ただし、検索の結果はパートナーがアクセスできるサイトとコンテンツに制限されます。

パートナーのサイトがプロジェクト間でコンテンツの分離を必要とする場合は、この記事で説明しているように、専用サービスアプリケーションを展開するのが適切なやり方です。このようにすると、サービスアーキテクチャの複雑さは増しますが、パートナーがイントラネットコンテンツに関連付けられたメタデータやパートナー Web サイト内の他のプロジェクトにアクセスできなくなります。エクストラネット設計サンプルでは、パーティション分割されたサービスも使用します。

管理サイト

設計サンプルでは、アプリケーションサーバーが各サーバーファームの SharePoint サーバーの全体管理 Web サイトをホストします。これにより、サーバーの全体管理サイトへのユーザーの直接のアクセスが防止されます。パフォーマンスのボトルネックまたはセキュリティ侵害がフロントエンド Web サーバーの可用性に影響する場合、SharePoint サーバーの全体管理 Web サイトは引き続き使用できます。

管理サイト用の負荷分散される URL については、設計サンプルとこの記事では言及していません。推奨事項は以下のとおりです。

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

これらの推奨事項に加え、必要に応じて、SharePoint サーバーの全体管理 Web サイトを複数のアプリケーションサーバーに負荷分散すると、冗長性を確保できます。

アプリケーションプール

通常は、個別のインターネットインフォメーションサービス (IIS) アプリケーションプールを実装することにより、コンテンツ間のプロセス分離が実現されます。アプリケーションプールは、複数のサイトが同じサーバーコンピューターで動作しながら、独自のワーカープロセスと ID を保持するための 1 つの手段を提供します。これにより、他のサイト上の他のサーバーやサイトに作用して、あるサイトにコードを送り込む攻撃者から保護するのに役立ちます。

ホスト名付きサイトコレクションで 1 つのアプリケーションプールと Web アプリケーションを使用する場合は、スクリプトレベルでのみ、ドメイン URL 間で分離が実現します。

複数のアプリケーションプールを実装する場合は、次の各シナリオで専用のアプリケーションプールを検討してください。

認証コンテンツを匿名コンテンツと区別する。企業のインターネットサイトを同じファームでホストする場合は、このサイトを専用の Web アプリケーションとアプリケーションプールに配置してください。
バックエンドデータシステムのパスワードを保存したりバックエンドデータシステムと通信したりするサイトを分離する (ただし、この目的には代わりに Secure Store Service を使用できます)。

ホスト名付きサイトを使用する企業ポータル設計サンプルと認証の専用領域を使用するエクストラネット設計サンプルはどちらも、すべてのコンテンツに対して 1 つのアプリケーションプールと Web アプリケーションを実装します。サービスアプリケーションと SharePoint サーバーの全体管理 Web サイトには、個別のアプリケーションプールが必要です。

パスベースのサイトを使用する企業ポータル設計サンプルでは、個別のアプリケーションプールを以下のように使用して、コンテンツ間でプロセスの分離を実装します。

管理サイトは、専用のアプリケーションプールでホストされます。これは SharePoint Server の要件です。
すべてのサービスアプリケーションが単一のアプリケーションプールに展開されます。サービスアプリケーションをどうしても別々のアプリケーションプールに展開しなければならない理由がない限り、これが推奨構成です。すべてのサービスアプリケーションに 1 つのアプリケーションプールを使用すれば、パフォーマンスが最適化され、管理するアプリケーションプールの数を減らすことができます。
イントラネットコンテンツは、2 つの異なるアプリケーションプールに分けられます。グループ作業コンテンツ (個人用サイトとチームサイト) は、1 つのアプリケーションプールでホストされます。公開イントラネットコンテンツは、別のアプリケーションプールでホストされます。この構成は、ビジネスデータ接続が使用される可能性が高い公開イントラネットコンテンツに、プロセスの分離を提供します。
パートナー Web アプリケーションは専用のアプリケーションプールでホストされます。

Web アプリケーション

Web アプリケーションは、SharePoint Server が作成して使用する IIS Web サイトです。各 Web アプリケーションは、IIS のそれぞれ異なる Web サイトによって表現されます。

複数の Web アプリケーションを実装する場合は、以下の使用例を検討してください。

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

企業のインターネットサイトを同じファームでホストする場合は、このサイトを専用の Web アプリケーションとアプリケーションプールに配置してください。
ユーザーを分離する

設計サンプルでは、パートナー Web サイトは専用の Web アプリケーションとアプリケーションプールによってホストされ、パートナーがイントラネットコンテンツにアクセスできないようになっています。
権限を適用する

専用の Web アプリケーションを使用すると、Web アプリケーション内の領域に対するポリシーを実装して、権限を適用できます。たとえば、企業インターネットサイトのポリシーを作成して、1 つ以上のユーザーグループに対して書き込みアクセスを明示的に拒否できます。ポリシーは個々のサイトまたは Web アプリケーション内のドキュメントに構成された権限に関係なく適用されます。
パフォーマンスを最適化する

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

別々の Web アプリケーションを作成すると、サイトとデータベースも別々になるため、異なるサイト制限 (ごみ箱、有効期限、サイズ) を実装し、異なるサービスレベル契約を適用できます。たとえば、組織内で最も重要な種類のコンテンツではない場合、個人用サイトのコンテンツの復元を急ぐ必要はありません。こうすると、個人用サイトのコンテンツを復元する前に、より重要なコンテンツを復元できます。設計サンプルでは、個人用サイトを別の Web アプリケーションに配置して、管理者が成長を他のアプリケーションより厳しく管理できるようにしています。

ホスト名付きサイトコレクションを 1 つの Web アプリケーションで実装すると、各トップレベルサイトが個別のドメインになり、これらの目標のうちの一部が達成されます (異なるサイト制限の実装による管理性の最適化など)。

サイトコレクション

サイトを展開する際に推奨される構成は、1 つの Web アプリケーション内に配置されたすべてのサイトに、ホスト名付きサイトコレクションを使用することです。この構成は、Microsoft 365 環境で使用されるのと同じアーキテクチャであるため、サイトを展開することをお勧めします。要するに、この構成は最も多くテストされた構成です。新しい機能 (アプリモデルや依頼管理など) はこの構成に対して最適化されているため、これが今後に向けて最も信頼性のある構成になります。

ほとんどのアーキテクチャに対してホスト名付きサイトコレクションが推奨されますが、以下のいずれかの条件に該当する場合は、従来のパスベースのサイトコレクションと代替アクセスマッピングを使用する必要があります。

SharePoint Server 2016 の既定のインストールに含まれるセルフサービスサイト作成機能を使用する必要がある場合。

これは、カスタムのセルフサービスサイト作成ソリューションには該当しません。
Web アプリケーションで一意のワイルドカードを使用した管理対象パスや明示的な管理対象パスが必要な場合。

ファームレベルでホスト名付きサイトコレクションの管理対象パスを作成すると、すべてのホスト名付きサイトで使用できます。ファーム内のすべてのホスト名付きサイトコレクションでは同じ管理対象パスを共有しますが、それらを使用する必要はありません。これに対して、パスベースのサイトコレクションで作成された管理対象パスは 1 つの Web アプリケーションのみに適用されます。
SSL ターミネーションが必要な場合に、必要なカスタム HTTP ヘッダーを生成するように SSL ターミネーションデバイスを構成できない場合。

SSL ターミネーションが必要ない場合は、これらのデバイスでホスト名付きサイトコレクションと SSL ブリッジを引き続き使用できます。
追加のセキュリティを実現する、異なるアプリケーションプールの使用を計画している場合、または複数のプロキシグループを使用する必要がある場合。

パスベースのサイトコレクションとの比較を含む、ホスト名付きサイトコレクションの詳細については、「ホスト名付きサイトコレクションのアーキテクチャと展開 (SharePoint 2013)」をご覧ください。

サイトコレクションの設計目標

サイトコレクションは、論理アーキテクチャと情報アーキテクチャの橋渡しをするものです。サイトコレクションの設計目標は、URL 設計の要件を満たすことと、コンテンツを論理的にグループ分けすることです。各サイトコレクションでは、トップレベルサイトコレクションの第 2 層が管理パスに組み込まれています。 URL 要件、および管理パスの使用の詳細については、後の「領域と URL」をご覧ください。サイトコレクションの第 2 層より上位では、各サイトがサブサイトです。

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

チームサイトのサイト階層

チームサイト

パスベースのサイトコレクションとホスト名付きコレクションでは、どちらも情報アーキテクチャがサイトコレクションの第 2 層の周囲を取り囲んでいます。以下のセクションでは、サイトの特性に基づいて設計サンプルで選択肢がどのように具体化されているかについて説明します。

公開イントラネットコンテンツ

公開イントラネットコンテンツ Web アプリケーションに関する前提は、企業内の複数の部門が公開コンテンツをホストすることです。設計サンプルでは、各部門のコンテンツがそれぞれ別のサイトコレクションでホストされています。この方法には以下の長所があります。

各部門がコンテンツと管理権限を独自に管理できます。
各部門がコンテンツを専用のデータベースに格納できます。

複数のサイトコレクションには、以下のような短所があります。

マスターページ、ページレイアウト、テンプレート、Web パーツ、およびナビゲーションを、サイトコレクション間で共有できません。
サイトコレクション間でカスタマイズやナビゲーションを連携させるために必要な作業が増えます。

イントラネットサイトの設計と情報アーキテクチャによっては、ユーザーに公開コンテンツをシームレスに見せることができます。また、各サイトコレクションをそれぞれ別の Web サイトであるように見せることもできます。

個人用サイト

個人用サイトには明確な特性があり、個人用サイトを展開するための推奨事項は簡単です。設計サンプルでは、個人用サイトサイトコレクションには、の URL を含むトップレベルサイトが組み込まれています。 http://my. 最初に作成されるトップレベルサイトコレクションは、個人用サイトのホストテンプレートを使用します。管理パスが組み込まれており (ワイルドカードを使用した管理対象パスを使用)、このため、ユーザーが作成するサイトの数に制限はありません。管理パスより下位のすべてのサイトは、個人用サイトテンプレートを使用する独立したサイトコレクションです。ユーザー名は、個人用/ユーザー名 http://my フォームの URL に追加 されます。個人用サイトを次の図に示します。

個人用サイトのサイト階層

個人用サイト

チームサイト

チームサイトアプリケーション内のサイトコレクションを設計するには、以下の 2 つの方法があります。

チームがセルフサービスサイト作成を使用してサイトコレクションを作成することを許可します。この方法の長所は、管理者がサポートしなくても、チームが必要に応じて簡単にサイトを作成できることです。この方法には、以下のような短所があります。
- 高度な分類法を実装する機会が失われます。
- 1 つのサイトコレクションを共有できるはずの複数のプロジェクトやチームによるテンプレートやナビゲーションの共有が行えなくなります。
組織の活動状況に基づいて、組織に適した有限数のサイトコレクションを作成します。この方法では、SharePoint 管理者がサイトコレクションを作成します。サイトコレクションが作成された後で、チームはサイトコレクション内にサイトを作成できます。この方法では、チームサイトの管理方法や成長の仕方に構造を提供する高度な分類法を実装する機会があります。サイトコレクションを共有するプロジェクトとチームがテンプレートやナビゲーションを共有する可能性も増えます。ただし、この方法にもいくつか短所があります。

設計サンプルには 2 番目の方法が組み込まれており、このため、チームサイトのサイトコレクション階層は、公開イントラネットコンテンツと類似しています。情報アーキテクチャの課題は、組織に適したサイトコレクションの第 2 層を作成することです。以下の表は、さまざまな種類の組織に対する推奨事項を示しています。

表: 推奨するサイトコレクション分類法

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