SharePoint 2013 の新しいアプリ モデルで必要とされるインフラストラクチャの計画

  • Article

原文の記事の投稿日: 2012 年 9 月 4 日 (火曜日)

SharePoint 2013 には最新のアプリケーション モデルが伴います。このアプリケーション モデルは "アプリ モデル" または "クラウド アプリ モデル" と婉曲的に呼ばれています。これにより、開発の観点からまったく新しい機会がもたらされますが、その一方で、このアプリケーション モデルをサポートするインフラストラクチャ要件を計画し、構築する必要があります。アプリ モデルについて実際に考える場合、以下の 3 つの重要な検討事項があります。

  1. 開発モデル – どのようにアプリケーションを開発するか、またどのような新しい機能を利用するかということです。これは主に開発者のアクティビティです。
  2. セキュリティ モデル – この新しいアプリケーションのセキュリティ モデルは、興味深い "要素" の総合体です。まず、アプリケーションの権限を定義する方法であるアプリケーション プリンシパルの新しい概念があります。アクセス可能なコンテンツを定義する OAuth モデルのほかに、ユーザーに関する情報を記述するトークン (アプリケーションのクレームにとてもに似ています) を SharePoint に提示するメカニズムがあります。これらのトークンの作成および提示に使用するセキュリティ モデルおよびセキュリティ手段は、アプリケーションをホストする場所が SharePoint かどうかや、アクセス制御サービス (ACS) を信頼ブローカーとして使用するかどうかによって大きく異なります。多くの要素があり、このブログ投稿ですべてをカバーできるものではありませんが、それらの要素は開発者および IT 担当者のアクティビティです。
  3. インフラストラクチャ – ここでは、組織内でアプリケーションを正常に機能させるすべての "付着物" について説明します。これには、サービス アプリケーション、アプリケーション ドメインとプレフィックス、DNS、SSL、および Web アプリケーション構成が含まれます。これは、主に IT 担当者のアクティビティであり、このブログ投稿の基礎となります。この投稿では、SharePoint 自体でホストされるアプリケーションと、別のサイトまたはクラウド (Windows Azure など) で外部的にホストされるアプリケーションにも焦点を当てます。SharePoint でホストされるアプリケーションをインストールすると、そのアプリケーション用の新しい SPWeb が作成されます。このように、各アプリケーションは独自のデータ セットを取得し、別のアプリケーションのデータを上書きできません。また、1 つのアプリケーションに対する権限を持つユーザーが、現在のユーザーの権限を使用する悪意のあるコードでファーム内の別のサイトのデータにアクセスできないように、セキュリティ層が提供されています。これは、新しいアプリ モデルに基づくアプリケーションの重要な基本プリンシパル (1 つのアプリケーションに 1 つの SPWeb) であり、覚えておく必要があります (アプリケーションが SharePoint でホストされる場合)。

では、これらのさまざまなインフラストラクチャ コンポーネントを使って作業を開始しましょう。まず、ファームで作成されて実行されている App Management および Subscription Settings Service アプリケーションのインスタンスがあることを確認する必要があります。アプリケーションと展開を追跡したり、ライセンスを発行したりするのに App Management サービスを使用します。Subscription Settings Service は、マルチテナント展開で使用するサービス アプリケーションと同じです。また、アプリ モデルでは、一意の URL を作成するために Subscription Settings Service が使用されます。

これらの URL はどのように作成されるのでしょうか。まずは、サーバーの全体管理でアプリケーション構成を行います。サーバーの全体管理に移動すると、[アプリケーション] と呼ばれる新しいセクションを見つけることができます。それをクリックすると、[アプリケーション URL の構成] オプションが表示されます。そこには、アプリケーションの URL を作成するのに使用する 2 つの値、アプリケーション ドメインとアプリケーション プレフィックスが表示されています。アプリケーション ドメインは、ファーム内のすべてのアプリケーションで使用されるホスト名に該当します。この名前を計画するときの 3 つの考慮事項を以下に示します。

  1. ファーム全体で使用されるので、他の Web アプリケーションで使用する場合と同じレベルの計画と検討を行う必要があります。
  2. さらに、完全修飾ドメイン名を使用する必要があります。NetBIOS スタイルの名前を使用すると、名前解決が適切に機能しません。
  3. 最後に、Web アプリケーションの子ドメインとすることができません。

具体的な例を見てみましょう。team.contoso.com、my.contoso.com、portal.contoso.com のような Web アプリケーションがあると仮定します。まず、アプリケーション ドメインに "contoso.com" を使用したいとはおそらく思わないでしょう。これを使用すると、contoso.com のすべてに対して、アプリケーション エンドポイントを指すワイルドカード DNS エントリを作成する必要があります (詳細は後で述べます)。また、"apps.contoso.com" のような名前も使用することはないでしょう。これは、Web アプリケーションで使用するもの (これらはすべて "contoso.com" をルートとします) に対する子ドメインだからです。したがって、これらのルールに基づいて、"contosoapps.com" のような名前を選択することをお勧めします。

アプリケーション プレフィックスの値には何を使用してもかまいません。これはアプリケーション URL の最初の部分に挿入されます。これについて以下で説明します。

上でワイルドカード DNS エントリの使用について述べましたが、そのことについてこれから説明します。アプリケーションをインストールし、そのアプリケーションを SharePoint で使用する場合、そのアプリケーションには次のような URL が指定されます。https://apps-87e90ada14c175.contosoapps.com/myapp/pages/default.aspx。この URL の各要素の詳細は以下のとおりです。

  • "apps" – 上で説明されている、サーバーの全体管理で入力したアプリケーション プレフィックスの値です。
  • "87e90ada14c175" – アプリケーションがインストールされたサイトコレクションと Web に基づく一意の値です。
  • "contosoapps.com" – サーバーの全体管理で入力したアプリケーション ドメインです。
  • "myapp" – インストールされたアプリケーションの名前です。URL の残りの部分 "pages/default.aspx" は、アプリケーションがインストールされている SPWeb に含まれるものです。

この URL とその形式を見ると、ワイルドカード DNS エントリを使用する理由がわかります。URL の最初の部分は (同じアプリケーションを複数のサイト コレクションにインストールする場合も) インストールするアプリケーション インスタンスごとに異なります。つまり、インスタンスごとに DNS を絶えず更新することは実現できません。というわけで、ここで述べたシナリオの DNS については、*.contosoapps.com 用のワイルドカード DNS エントリを使用する必要があります。これで、この URL が指す IP アドレスはここで説明されたものになります。

ワイルドカード DNS エントリにはワイルドカード SSL エントリが関連します。念のため、この点についてはっきりさせておきますが、アプリケーションを使用する場合、SSL を使用する必要があります。アプリ モデルでは、現在のユーザーとアプリケーションを記述する OAuth アクセス トークンを回す必要があります。ユーザーの SAML トークンを回した場合のように、トークンが流れるチャネルを暗号化し、外部のユーザーによる再生スタイルのあらゆる攻撃 (コンテンツへのアクセスを付与する攻撃) によってネットワーク トラフィックが傍受されないようにする必要があります。SSL を使用することで、このようなシナリオが起きなくなります。また、インストールされたインスタンスごとにこれらのアプリケーションの URL が異なるので、管理できるようにするには、ここでもワイルドカード SSL 証明書が必要になります。同様に、このシナリオでは、*.contosoapps.com 用にワイルドカード SSL 証明書を取得します。

ここまで、必要なサービス アプリケーション、アプリケーション ドメインとアプリケーション プレフィックスに必要な構成、URL の形式、および必要な DNS および SSL エントリについて説明してきました。ここで、これらすべてを束ねるには、アプリケーション要求がどのようにルーティングされるかについて説明する必要があります。一般的には、アプリケーション要求のルーティングを行うためだけの独立した SharePoint Web アプリケーションが必要です。その理由を考えてみます。たとえば、以下のように定義された 3 つの Web アプリケーションがあると仮定します。これらのすべてが SSL を使っているので、それぞれに対して一意な IP アドレスを使用します。

  • team.contoso.com – 192.168.1.10
  • my.contoso.com – 192.168.1.11
  • portal.contoso.com – 192.168.1.12

上で説明したとおり、ファーム内に持つことができるアプリケーション ドメインは 1 つだけです。また、そのアプリケーション ドメインを子ドメインとすることはできません。これにより、上のアプリケーションに関する 2 つの非常に現実的な問題が発生します。

  • これらの各 Web アプリケーションにアプリケーションをインストールする場合、適切なアプリケーション要求を適切な Web アプリケーションにどのようにルーティングできるでしょうか。アプリケーション ドメインは 1 つしかありませんが、Web アプリケーションは 3 つあります。
  • アプリケーション要求をこれらの既存の Web アプリケーションの 1 つにルーティングする場合、SSL は壊れます。なぜでしょう。ここでは、すべての Web アプリケーションで SSL を使用している (アプリケーションを使用しているため) ので、すべての Web アプリケーションに *.contoso.com のような SSL 証明書があります。したがって、アプリケーション要求をそれらの Web アプリケーションにどうしてもルーティングすることができません。*.contoso.com と *.contosoapps.com の両方に対して有効な SSL ワイルドカード (アプリケーションで使用するワイルドカード) を取得できないためです。

解決策は 4 番目の Web アプリケーションを作成することです。Web アプリケーションをホスト ヘッダー名なしで作成し、それに共有 IP の 192.168.1.13 を割り当てることができます。DNS では、*.contosoapps.com のワイルド カード エントリが 192.168.1.13 を指すようにします。これにより、アプリケーション Web アプリケーションがその IP アドレスを "リッスン" し、ルーティングを行う SharePoint http モジュールがアプリケーションの要求を取得します。次に、SharePoint http モジュールは、App Management サービス アプリケーションを使用して、そのアプリケーションを実際にホストする Web アプリケーションを決定し、要求をその Web アプリケーションに再度ルーティングします。その後、要求は、その Web アプリケーション、サイト コレクション、およびアプリケーション自身が置かれている SPWeb から送信されます。したがって、それらに対するすべてのセキュリティおよび認証設定は適切に適用されます。

これで、ファーム構成は以下のようになります。

  •  アプリケーション構成
    • アプリケーション ドメイン – contosoapps.com
    • アプリケーション プレフィックス – apps
  • Web アプリケーション

    • team.contoso.com

      • IP アドレス: 192.168.1.10
      • SSL 証明書: *.contoso.com

    • my.contoso.com

      • IP アドレス: 192.168.1.11
      • SSL 証明書: *.contoso.com

    • portal.contoso.com

      • IP アドレス: 192.168.1.12
      • SSL 証明書: *.contoso.com

    • ホスト ヘッダーはありません。または、contosoapps などを使用することもできます。ここでは、ホスト ヘッダーに基づくルーティングではなく、IP アドレスに基づくルーティングを行っているので、これは重要ではありません。ただし、ホスト ヘッダーを使用し、すべての Web アプリケーションで同じ IP アドレスを使用する場合は、このリスナー Web アプリケーションにホスト ヘッダー値を一切持たせないでください。 そうしないと、IIS は、すべての Web アプリケーションのアプリケーション要求を取得しなくなります。

      • IP アドレス: 192.168.1.13
      • SSL 証明書: *.contosoapps.com
  • DNS
    • team.contoso.com – 192.168.1.10
    • my.contoso.com – 192.168.1.11
    • portal.contoso.com – 192.168.1.12
    • *.contosoapps.com – 192.168.1.13

これで、アプリケーションのインフラストラクチャ構成に関する側面はすべて説明しました。ただし、SharePoint 2013 の新しいアプリケーションのロールアウトを計画する場合、以下の 2 つの考慮事項を覚えておく必要があります。

  • SharePoint アプリケーションは、SAML を使用する Web アプリケーションで正常に動作しません。SAML 認証を使用する場合、それらの Web アプリケーションで SharePoint アプリケーションを使用できません。これは、今後のサービス パックまたはその他の種類の修正プログラムで解決することが期待されますが、SharePoint 2013 RTM 版の制限です。
  • SharePoint アプリケーションでは、複数のゾーン (つまり、AAM) がサポートされません。すべての要求は既定のゾーンから送信されます。AAM を使用して複数ゾーンをサポートする場合、SharePoint アプリケーションを使用できなくなる可能性があります。すべてのアプリケーションは、既定のゾーンから提供されます。したがって、理論的には、既定のゾーンを公開し、すべてのユーザーが既定のゾーンにアクセスできるようにして、すべてのゾーンで同じ認証メカニズムを使用する場合 (いくつかの制限がある可能性がありますが、この場で説明するには内容が細かすぎます)、SharePoint アプリケーションは正常に動作する可能性があります。ただし、通常、ゾーンを使用する場合、その理由は、a) すべてのエンドポイントをすべてのユーザーに公開することが望まれない、または b) 異なる認証方法を使用するのどちらかです。これは、今後変更される可能性がありますが、今のところ、SharePoint 2013 RTM 版にはこの制限があります。

 

最後に重要な注意事項があります。それは、ご想像のとおり、多くの構成があることです。ただし、Office 365 を使用する場合、構成は自動的に設定されることを覚えておいてください。面倒なことや、ややこしいことは一切ありません。アプリケーションを簡単にインストールして使用できます。オプションを検討する場合は、この点を考慮する必要があります。

これでご理解いただけたでしょうか。SharePoint アプリケーションは SharePoint 2013 の大きな部分を占めますが、SharePoint アプリケーションを実行するには、SharePoint アプリケーションをサポートするインフラストラクチャを適切に配置するように、計画と設計をあらかじめ行っておく必要があります。

 

これはローカライズされたブログ投稿です。原文の記事は、「Planning the Infrastructure Required for the new App Model in SharePoint 2013」をご覧ください。