# インフラストラクチャ保護
| SaaS SEC 2: テナントリソースがクロステナントアクセスから保護されることをどのように確認していますか? |
| --- |
| |
テナントの分離は、すべての SaaS プロバイダーが取り組む必要のある基本的なトピックの 1 つです。独立系ソフトウェアベンダー (ISV) は、SaaS にシフトし、共有インフラストラクチャモデルを採用してコスト効率および運用効率を達成する際に、マルチテナント環境において、テナントが他のテナントのリソースにアクセスできないようにする方法を決定するという課題にも取り組みます。SaaS ビジネスにとって、どのような形でもテナントの境界線を超えることは、重大かつ回復不能に至る可能性のあるイベントに相当します。
テナントの分離は SaaS プロバイダーにとって不可欠と考えられますが、この分離を達成するための戦略およびアプローチは一様ではありません。SaaS 環境でテナントの分離を実現する方法には、非常に多くの要素が影響を与えます。ドメイン、コンプライアンス、デプロイモデル、AWS サービスの選択など、すべてがテナント分離の方法にそれぞれの検討事項として関わってきます。
**Topics**
+ [分離の考え方](isolation-mindset.md)
+ [基本的な分離の概念](core-isolation-concepts.md)
# 分離の考え方
テナントリソースを保護して分離する重要性と価値について、概念レベルでは多くの SaaS プロバイダーの意見が一致します。しかし、分離戦略の実装を詳しく掘り下げていくと、多くの場合、SaaS ISV ごとに*十分な*分離について独自の定義があることがわかります。
さまざまな考え方があるという点を踏まえて、テナントの分離の価値システム全体を理解しやすくする基本的な概念をいくつか説明します。すべての SaaS プロバイダーは、チームが SaaS 環境の分離フットプリントを定義する際に、チームを導く明確な一連の分離要件を確立する必要があります。以下は、一般的に SaaS テナントの分離モデル全体を作成するいくつかの重要な基本的概念です。
**分離は任意ではない** – 分離は SaaS の基本要素であり、マルチテナントモデルでソリューションを提供するすべてのシステムで、テナントリソースが確実に分離される手段を講じる必要があります。
**認証と承認は分離と同じではない** – 認証と承認により SaaS 環境へのアクセスを制御できますが、ログイン画面または API のエントリポイントを越えたからといって、分離が実現されたことにはなりません。これは分離パズルの 1 つにすぎず、それだけでは十分ではありません。
**分離の実施をサービスデベロッパーに任せるべきではない** – デベロッパーが分離に違反する可能性のあるコードを組み込むことはありませんが、テナントの境界を無意識に越えることはないと想定するのは非現実的です。これを軽減するために、分離ルールを適用する共有メカニズムを介してリソースへのアクセス範囲を (デベロッパーの観点外で) 制御する必要があります。
**すぐに利用できる分離ソリューションがない場合は自分で構築する必要がある** - AWS Identity and Access Management (IAM) など、テナントを分離するパスの簡素化に役立つセキュリティメカニズムがいくつかあります。これらのツールをより広範なセキュリティスキームと組み合わせて分離プロセスを簡素化できます。ただし、対応するツールまたはテクノロジーによって分離モデルが直接処理されないシナリオが存在する場合もあります。独自の何かを構築する場合であっても、明確なソリューションのないことが分離要件を引き下げる機会を表すべきではありません。
**分離はリソースレベルの構造ではない** – マルチテナンシーと分離の世界では、分離を、明確なインフラストラクチャリソース間に厳密な境界線を引く手法と考える人もいます。これは、多くの場合、テナントごとに個別のデータベース、コンピューティングインスタンス、アカウント、または Virtual Private Cloud (VPC) がある分離モデルという形になります。これらは一般的な分離の形式ですが、テナントを分離する唯一の方法ではありません。リソースが共有されるシナリオでも、特にリソースが共有される環境では分離を実現する方法があります。この共有リソースモデルにおいて、分離は、実行時に適用されるポリシーによって実施される論理構造にすることができます。ここで重要なのは、分離はリソースのサイロ化と同一にすべきではない点です。
**ドメインは特定の分離要件を課す場合がある** – テナントの分離を実現するアプローチは多数ありますが、ドメインによっては特定の種類の分離が必要になる制限が課される場合があります。例えば、コンプライアンスの厳しい業界ではテナントごとに独自のデータベースが必要になる場合があります。このような場合、共有ポリシーベースのアプローチでは、分離に不十分である可能性があります。
# 基本的な分離の概念
分離には、テナントの分離に複数の定義が存在するという課題があります。一部の人にとって、分離とは概してビジネスの構造であり、独自の環境を必要とする顧客全体を想定します。一方、分離とは、マルチテナント環境のサービスと構造をオーバーレイするアーキテクチャ構造のようなものと考える人もいます。後続のセクションでは、さまざまなタイプの分離について説明し、特定の用語を各分離構造に関連付けます。
**Topics**
+ [サイロ分離](silo-isolation.md)
+ [プール分離](pool-isolation.md)
+ [ブリッジモデル](bridge-model.md)
+ [階層ベースの分離](tier-based-isolation.md)
+ [的を絞った分離](targeted-isolation.md)
# サイロ分離
多くの場合、SaaS プロバイダーはリソース共有の価値を重視しますが、完全にサイロ化されたリソースのスタックを実行しているモデルに一部 (またはすべて) のテナントをデプロイすることを SaaS プロバイダーが選択するシナリオもあります。このフルスタックモデルは SaaS 環境を表すものではないと考える人もいます。ただし、これらの個々のスタックを共有のアイデンティティ、オンボーディング、計測、メトリクス、デプロイ、分析、運用に含めている場合、これは、スケールのメリットと運用効率をコンプライアンス、ビジネス、またはドメインとトレードする SaaS の有効なバリアントになります。このアプローチでは、分離は顧客スタック全体にまたがるエンドツーエンドの構造です。図 16 に示す概念ビューは、この分離のビューの概念ビューを示しています。
![\[Diagram showing multiple tenants with isolated web app, microservices, and database stacks.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/saas-lens/images/image17.png)
*図 16: サイロ分離モデル*
この図は、サイロ化されたデプロイモデルの基本的なフットプリントを示しています。これらのスタックの実行に使用されるテクノロジーは、ここではほとんど関係ありません。これは、モノリス、サーバーレスである場合や、さまざまなアプリケーションアーキテクチャモデルの任意の組み合わせである場合もあります。重要な概念は、テナントが持つスタックすべてを一部の構造に含めて、そのスタックの可動部すべてをカプセル化することです。これが分離の境界になります。完全にカプセル化された環境からテナントがエスケープするのを防止できる場合、分離が実現されたことになります。
一般に、この分離モデルは実施がはるかに簡単です。多くの場合、堅牢な分離モデルを実装できるようにする構造は明確に定義されています。このモデルは SaaS 環境のコストと俊敏性の目標達成に関して難しい課題を抱えているものの、非常に厳格な分離要件のあるユーザーにとっては、魅力的なものとなり得ます。
## サイロモデルのメリットとデメリット
各 SaaS 環境とビジネスドメインが持つ独自の要件一式によっては、サイロが適している場合があります。しかし、この方向性に傾いている場合には、当然サイロモデルに関連する課題と経費について、細かく確認しておきたいでしょう。SaaS ソリューションにサイロモデルを検討している場合に考慮しておくべきメリットとデメリットがいくつかあります。
### メリット
+ **困難なコンプライアンスモデルをサポート** – 一部の SaaS プロバイダーは厳格な分離要件が課せられている規制のある市場で販売しています。サイロモデルによって、これらの ISV はテナントの一部またはすべてに対して、専用モデルにデプロイするというオプションを提供できています。
+ **他のテナントによる影響の懸念がない** – すべての SaaS プロバイダーは他のユーザーの状況によって生じる影響を抑制しようとしていますが、それでも一部の顧客はシステムを使用している他のテナントのアクティビティによって、自分のワークロードが影響を受ける可能性に難色を示します。サイロモデルではこの懸念に対応し、他のテナントによる影響を受ける可能性がない、専用の環境を提供します。
+ **テナントコストの追跡** – SaaS プロバイダーは大抵の場合、各テナントがどれほどインフラストラクチャコストに影響を与えているかを把握することに重点を置いています。テナントあたりのコストの計算は一部の SaaS モデルでは困難です。しかし、サイロモデルでは複数に分かれているという特性によって、簡単な方法でインフラストラクチャコストを把握し、各テナントに紐付けられます。
+ **影響範囲を軽減** – サイロモデルは通常、SaaS ソリューションで停止状態やイベントが発生した場合、その影響を軽減します。各 SaaS プロバイダーは独自の環境で実行しているため、特定のテナントの環境内で発生した障害は、大抵の場合その環境内に限定されます。1 つのテナントは停止に陥るものの、システムを使用している残りのテナントで、次々とエラーが発生することはありません。
### デメリット
+ **スケーリングの問題** – プロビジョンできるアカウント数に制限があります。この制限のため、アカウントベースモデルを選択できない場合があります。また、急激にアカウント数が増加することによって、SaaS 環境の管理およびオペレーション上の操作性を低下させるという一般的な懸念もあります。例えば、テナントにつき 20 のサイロ化されたアカウントは管理できますが、千ものテナントがいる場合、その数はオペレーションの効率性と俊敏性に影響を与えるようになる場合があります。
+ **コスト** – 独自の環境で実行しているすべてのテナントに関して、従来の SaaS ソリューションに伴うコスト効率性のほとんどは実現しません。これらの環境を動的にスケーリングしたとしても、おそらく使われない無駄なリソースが発生する期間が発生します。このモデルは完全に許容範囲のモデルであるものの、SaaS モデルに欠かせないスケールメリットと増益を実現できる可能性は低くなります。
+ **俊敏性** – SaaS への移行は、迅速なペースでのイノベーション実行という願望が直接の動機となっていることがほとんどです。これは組織が迅速に市場動向に応え、対応できるようにするモデルの採用を意味します。この観点で重要となるのは、カスタマーエクスペリエンスを統一し、迅速に新しい機能や性能をデプロイできることです。サイロモデルによる俊敏性への影響を抑えるためにできる対策はあるものの、細かく分散化されているというサイロモデルの特性によって、テナントの管理、運営、サポートを容易に行えるという機能に影響を及ぼす複雑さが付加されます。
+ **オンボーディング自動化** – SaaS 環境は新規テナント追加の自動化に対してプレミアムが発生します。これらのテナントがセルフサービスモデルまたは内部管理のプロビジョニングプロセスのどちらでオンボーディングを行う場合でも、オンボーディングを自動化する必要があります。各テナントに個別のサイロがある場合、この作業はさらに負担の大きいプロセスとなることがしばしばあります。新規テナントのプロビジョニングは、新規インフラストラクチャのプロビジョニングを必要とするほか、新規アカウント制限の設定も必要となる場合があります。このような可動部の追加は、全体的なオンボーディングの自動化に追加の側面での複雑さをもたらす経費につながり、顧客に注力できる時間が少なくなります。
+ **分散管理およびモニタリング** – SaaS での目標は、1 つの画面ですべてのテナントアクティビティの管理およびモニタリングができるようになることです。この要件は特に、サイロ化したテナント環境の場合に重要となります。この場合の課題は、より分散化したテナントフットプリントからデータを蓄積しなければならないことです。テナントの集計ビューを作成するメカニズムはあるものの、このメカニズムを構築し、管理するために必要な手間と労力は、サイロ化モデルにおいてはより複雑になります。
# プール分離
分離サイロモデルは多くの SaaS 企業で非常にうまく位置づけられていることがわかります。SaaS に移行している企業の多くは、テナントに基盤インフラストラクチャの一部またはすべてを共有できる、効率性、俊敏性、コスト面での利点を求めています。この共有インフラストラクチャアプローチは、プールモデルと呼ばれ、分離の議論に一定の複雑さを付加しています。図 17 はプールモデルでの分離の実装に関連する課題を表しています。
![\[Microservice architecture diagram showing tenant isolation and shared compute resources for a SaaS application.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/saas-lens/images/image18.png)
*図 17: プール分離モデル*
このモデルでは、すべてのテナントで共有しているインフラストラクチャを、テナントが利用していることがわかります。これにより、リソースをテナントによる実際の負荷に正比例してスケーリングできます。図の右側は 1 つのサービスをコンピューティングの観点から詳しく表したものです。テナント 1 から N までがすべて、特定の時間に共有コンピューティング内で隣り合って実行する可能性があることを示しています。この例のストレージもまた共有されており、個別のテナント識別子でインデックス付けされたテーブルとして示しています。
このモデルは SaaS プロバイダーにとっては適切に機能しますが、分離の議論全体を複雑にする可能性があります。共有されたリソースで分離を実装することは、それほどわかりやすく典型的なネットワーキングではなく、テナント間の境界作成は IAM 構造に依存できません。
この重要な点は、分離がより難しい環境であるものの、それを理由にして環境の分離要件の緩和はできないということです。共有モデルではクロステナントアクセスの可能性が増加するため、リソースが分離されていることの確認を徹底する必要がある領域といえます。
プール分離モデルを掘り下げると、このアーキテクチャ上のフットプリントは課題が独自に交じり合っており、テナントのリソースを適切に分離するには、それぞれに独自のタイプの分離構造が必要となることがわかります。
## プールモデルのメリットとデメリット
すべてを共有することで高い効率性と最適化を実現できますが、SaaS プロバイダーはこのモデルの採用に伴ういくつかのトレードオフを強調する必要があります。多くの場合、プールモデルのメリットとデメリットは、サイロモデルで取り上げたメリットとデメリットの逆となります。以下は一般的にプール分離モデルに関わる主なメリットとデメリットです。
### メリット
+ **俊敏性** – テナントを共有インフラストラクチャモデルに移行すると、その特性である効率性とシンプルさを利用して、SaaS サービスの俊敏性を整備できます。基本的にプールモデルは、SaaS プロバイダーが統一された単一の操作性でテナントすべての管理、スケーリング、運営ができるようにするためのものです。操作性の一元化と標準化は、SaaS プロバイダーがより簡単に管理を行い、テナントごとに 1 回限りのタスクを実行する必要なく、すべてのテナントに変更を適用できるようにする基盤となります。このオペレーション上の効率性は、SaaS 環境の全体的な俊敏性のフットプリントの鍵となります。
+ **コスト効率性** – 多くの企業は SaaS の高いコスト効率性に魅力を感じています。このコスト効率性の大部分は、一般的に分離のプールモデルによるものです。プールされた環境では、システムはすべてのテナントによる実際の負荷とアクティビティに基づきスケーリングします。すべてのテナントがオフラインであれば、インフラストラクチャコストは最小限になります。この主要な概念としては、プールされた環境はテナント負荷に動的に適応でき、テナントアクティビティをリソース使用量により最適に合わせられることにあります。
+ **管理と運営の簡素化** – 分離のプールモデルでは、システム内のすべてのテナントを一括で確認できます。すべてのテナントの管理、更新、デプロイが、システム内のすべてのテナントに対応する単一の操作で可能です。これにより、管理と運営に関わるフットプリントのほとんどの部分が簡素化されます。
+ **イノベーション** – プールされた分離モデルによって実現する俊敏性は、SaaS プロバイダーが迅速なペースでイノベーションを実行するための中核となり得ます。分散型の管理、サイロモデルの複雑さから離れるほど、製品の性能と機能により重点を置けるようになります。
### デメリット
+ **他のテナントによる影響** – リソースが共有されるほど、あるテナントが他のテナントの操作性に影響を及ぼす可能性は高くなります。例えば、あるテナントのアクティビティによってシステムに大きな負荷がかかると、他のテナントに影響を生じさせる場合があります。適切なマルチテナントアーキテクチャと設計ではこれらの影響を抑制しようとしますが、プールされた分離モデルでは、他のテナントの状況によって 1 つ以上のテナントが影響を受ける可能性が常にあります。
+ **テナントコストの追跡** – サイロモデルでは、非常に簡単にリソースの消費を特定のテナントに紐付けられます。一方、プールされたモデルでは、リソースの消費を紐付けることはより難しくなります。各 SaaS プロバイダーはシステムを測定して、効果的に消費量を個々のテナントに紐付けるために必要な詳細データを取得する方法を見つける必要があります。
+ **影響範囲を軽減** – すべての共有リソースを共有することは、オペレーションリスクにもつながります。サイロモデルでは、あるテナントに障害が発生すると、大抵の場合その障害の影響はそのテナントのみに限定されます。一方、プールされたモデルでは、停止はシステム内のすべてのテナントに影響する可能性が高く、ビジネスに大きな影響を及ぼす場合があります。通常、障害を特定して明らかにし、スムーズに障害から復旧できるよう、耐障害性の高い環境の構築に対して、より高いコミットメントを必要とします。
+ **コンプライアンスによる抵抗** – プールモデルのテナントを分離できる手段はあるものの、インフラストラクチャの共有という概念によって、このモデルで実行することを躊躇させる状況になる場合があります。特に、ドメインのコンプライアンスまたは規制ルールで、リソースのアクセシビリティと分離に厳格な制限がある環境が該当します。そのような場合、システムの一部分については、サイロ化する必要性が生じる場合があります。
# ブリッジモデル
サイロモデルとプールモデルは分離に対してまったく異なるアプローチをしますが、多くの SaaS プロバイダーの分離の状況はそれほど絶対的なものではありません。実際のアプリケーションの問題を確認し、システムをより小さいサービスに分解すると、大抵の場合、ソリューションにはサイロモデルとプールモデルを混合したものが必要だとわかります。この混合モデルを分離のブリッジモデルと呼んでいます。図 18 は SaaS ソリューションでのブリッジモデルの実装方法の例を示しています。
![\[Multi-tenant architecture with shared web tier and separate app tiers for three tenants.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/saas-lens/images/image19.png)
*図 18: ブリッジ分離モデル*
この図は、ブリッジモデルによってどのようにサイロモデルとプールモデルを組み合わせられるかを示しています。こちらでは、従来型のウェブとアプリケーション層のモノリシックアーキテクチャがあります。ウェブ層はこのソリューションの場合、すべてのテナントが共有するプールモデルにデプロイされています。ウェブ層は共有されていますが、アプリケーションの基盤となるビジネスロジックとストレージは実はサイロモデルにデプロイされており、各テナントは独自のアプリケーション層とストレージを持っています。
モノリスをマイクロサービスに分解すると、システム内のさまざまなマイクロサービスそれぞれで、サイロモデルとプールモデルを組み合わせて利用できます。このアプローチの詳細については、さまざまな AWS 構成へのサイロモデルとプールモデルの適用に関する詳細説明で取り上げます。こちらでの重要なポイントは、サイロモデルとプールモデルに対する見方は、異なる分離要件を持つサービスの集合体に分解される環境において、より粒度が細かくなることです。
# 階層ベースの分離
分離に関する議論のほとんどがクロステナントアクセスを回避するメカニズムに特化していますが、サービスの階層化が分離戦略に影響を与える可能性がある場合もあります。そのような場合、テナントをどのように分離するかよりも、異なるプロファイルを持つ異なるテナントに対して、どのように異なるタイプの分離をパッケージ化し、提供するかが重要となります。また、対象とする幅広い顧客に対応するために、どの分離モデルが必要かを判断するうえで、別の考慮事項もあります。図 19 は階層による分離の違いを示した例です。
以下の例では、サイロ分離モデルとプール分離モデルの組み合わせを使って、階層としてテナントに提供しています。シルバー階層のテナントはプールされた環境で実行しています。これらのテナントは共有のインフラストラクチャモデルで実行しているものの、自分のリソースがクロステナントアクセスから保護されることを完全に期待できます。右側のテナントには、完全に専用の (サイロ) 環境を提供する必要があります。それを実現するため、SaaS プロバイダーはプレミアム階層モデルを作り、テナントがこの専用モデルで実行できるようにしています。これは通常非常に高価となります。
SaaS プロバイダーは一般的に顧客にサイロモデルを提供することを制限しようとし、多くの SaaS ビジネスではこのモデルにデプロイするにはテナントがプレミアムを支払うという、個別料金の概念があります。実際に、SaaS 企業はこのオプションを選択する顧客の数を制限するため、これをオプションとして公表することもなければ、階層として認識もしていません。あまりにも多くのテナントがこのモデルに該当する場合には、完全にサイロ化したモデルを再検討し、先ほど説明した課題の多くを受け入れることになります。
![\[Comparison of pool and silo models for multi-tenant microservice architecture.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/saas-lens/images/image20.png)
*図 19: 階層ベースの分離*
こういった単発の環境の影響を制限するために、SaaS プロバイダーは大抵の場合、これらのプレミアム顧客に対して、プールされた環境にデプロイされた製品の同じバージョンを実行することを求めます。これにより ISV は単一の画面から両方の環境の管理および運営が引き続きできます。基本的に、サイロ環境はたまたま 1 つのテナントをサポートしているプールされた環境のクローンとなります。
# 的を絞った分離
システムでの分離オプションは、非常に細分化されることを理解しておくことが重要です。システムの各マイクロサービス、およびそのサービスが使用する各リソースには、異なる分離モデルを設定できるオプションがあります。マイクロサービスの例をいくつか確認し、異なるマイクロサービス間で分離モデルを変える方法について理解を深めましょう。図 20 は、分離のサイロモデルとプールモデル両方を使用するマイクロサービスを表しています。
この図から、システムは 3 つの異なるマイクロサービスである、製品、注文、アカウントを実装していることがわかります。これらのマイクロサービスそれぞれのデプロイおよびストレージモデルは、どのように SaaS 環境で分離 (セキュリティまたは他のテナントによる影響の分離) が行われているかを示しています。
これらサービスそれぞれの分離モデルを確認していきましょう。右上にある製品のマイクロサービスは、完全なプールモデルにデプロイされており、コンピューティングとストレージの両方がすべてのテナントに共有されています。すべてのテナントが同じテーブルでインデックス付けされた個別のアイテムとなっていることを、こちらのテーブルでは反映しています。前提として、このテーブルのテナントアイテムへのアクセスを制限できるポリシーでもって、データは分離されます。注文のマイクロサービスは、テナント 1 から 3 専用で、プールモデルに実装されています。こちらの唯一の違いは、テナントのサブセットをサポートしている点です。基本的には、注文のマイクロサービスの専用 (サイロ) デプロイがされていないテナントは、このプールされたデプロイで実行します (サイロマイクロサービスとして除外された一部のテナント以外のテナント 1 から N とします)。
この点を説明するため、専用の*注文*のマイクロサービス (右上) とアカウントのマイクロサービス (下) で表されているサイロ化したサービスに注目しましょう。テナント 4 と 5 に対して、注文のマイクロサービスのスタンドアロンインスタンスをデプロイしていることがわかります。この理由は、これらのテナントは注文処理に関する要件 (コンプライアンス、他のテナントによる影響など) があり、このサービスをサイロモデルでデプロイする必要があったためです。こちらでは、コンピューティングとストレージは両方とも、完全に各テナント専用となっています。
最後に、下にあるアカウントのマイクロサービスはサイロモデルを表していますが、ただしストレージレベルのみです。マイクロサービスのコンピューティングはすべてのテナントに共有されていますが、各テナントにはアカウントデータを保持するための専用*データベース*があります。このシナリオでは、分離に関わる懸念事項は、データの分離のみに絞られます。コンピューティングは共有することが可能です。
![\[Microservices architecture diagram showing product, order, and account services with tenant data distribution.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/saas-lens/images/image21.png)
*図 20: 的を絞った分離*
このモデルはサイロに関する議論がより細分化することを示しています。セキュリティ、他のテナントによる影響、さまざまな要因によって、どのようにかつどういう場合にサイロ分離モデルをサービスに採用するかが決まります。こちらでの重要なポイントは、サイロモデルは使うか、使わないかのみの判断に限らないということです。サイロモデルをアプリケーションの特定のコンポーネントで使用することを検討できます。また、見込み顧客がこのモデルの使用を求めた場合など、必要な場合にのみこのモデルの課題を受け入れます。この場合、顧客とのより詳細な議論で、ストレージと処理における特定の領域にのみ懸念があることがわかります。そうすることにより、サイロ分離を必要としないシステムのその部分のプールモデルの効率性が得られると同時に、階層ストラクチャを提供できる柔軟性が確保でき、個々のサービスにおいてサイロモデルとプールモデル両方の組み合わせをサポートできます。