マルチテナンシーとは何ですか？
ソフトウェアマルチテナンシーは、 ソフトウェアアーキテクチャ であり、単一の インスタンス の ソフトウェア がサーバー上で実行され、複数のテナントにサービスを提供します。このように設計されたシステムは「共有」されており、（「専用」または「分離」されているわけではありません）。
テナントは、ソフトウェアインスタンスへの特定のアクセス権を共有するユーザーグループです。
マルチテナントアーキテクチャは、サービスプロバイダーが複数の顧客に標準化されたサービスを提供する際によく選ばれます。これらのサービスは通常、カスタマイズが最小限であり、すべての顧客が同じアプリケーションインスタンスを共有します。アプリケーションが更新されると、すべての顧客に一度に適用されます。
たとえば、CRM（顧客関係管理）システムは、すべてのクライアントに同じサービスを提供するためにマルチテナントアーキテクチャを使用することがよくあります。
マルチテナンシーの主要な原則は「共有」です。これはすべての部分が共有されることを意味するのではなく、少なくとも一部のコンポーネントが複数のテナント間で再利用されることを意味します。この広範な概念を理解することで、クライアントのニーズにより的確に対応することができます。
マルチテナント製品のユースケースは何ですか？
マルチテナントアプリは、生産性ツールやコラボレーションソフトウェアなどのソフトウェア・アズ・ア・サービス (SaaS) 製品で一般的に使用されます。このセットアップでは、各「テナント」は通常、複数のユーザー（通常は従業員）を持つビジネス顧客を表します。異なる製品では、コンテキストに応じて、テナント、ワークスペース、またはプロジェクトと呼ばれることがあります。単一の企業が異なる部門や組織を表す複数のテナントを持つこともあります。
より複雑なケースでは、SaaSを超えたB2Bアプリケーションのように、マルチテナントアプリは、さまざまなチーム、ビジネスクライアント、パートナー会社があなたのサービスにアクセスするための共有プラットフォームを提供します。
SaaS製品にマルチテナンシーを導入すべき理由
マルチテナンシーによるスケーリング
エンタープライズビジネスのために、マルチテナンシーは可用性、リソース管理、コスト管理、データセキュリティの要件を効果的に満たすための鍵です。技術的なレベルでは、マルチテナントアプローチを採用することで、開発プロセスの合理化、技術的な課題の最小化、シームレスな拡張が促進されます。
統一されたエクスペリエンスの創出
SaaS製品のルーツを検討する際、さまざまなアパートを含む建物に例えることができます。すべてのテナントは水、電気、ガスのような共通のユーティリティを共有しますが、自分のスペースとリソースを管理する独立したコントロールを維持します。このアプローチは物件管理を簡素化します。
テナント隔離によるセキュリティの確保
マルチテナンシーアーキテクチャでは、用語「テナント」は境界を作り、共有インスタンス内で異なるテナントのリソースとデータを分離し、安全に保つために導入されます。これにより、テナントが同じ基盤リソースを利用している場合でも、各テナントのデータと操作が明確に区別され、安全に保たれます。
マルチテナンシーアーキテクチャでテナント隔離を達成するにはどうすればよいですか？
マルチテナントアプリケーションを議論するときは、常にテナント隔離を達成する必要があります。これは、異なるテナントのデータとリソースを共有システム（たとえば、クラウドインフラストラクチャまたはマルチテナントアプリケーション）内で分離し、安全に保つことを意味します。これにより、他のテナントのリソースへ不正にアクセスしようとする試みを防止します。
説明が抽象的に感じられるかもしれませんが、例と重要な詳細を使用して、隔離の考え方とテナント隔離を達成するためのベストプラクティスをさらに説明します。
テナント隔離はマルチテナンシーの「共有」思考に反するものではありません
それは、テナント隔離が必ずしもインフラストラクチャリソースレベルの構造ではないためです。マルチテナンシーと隔離の領域で、一部の人々は隔離を実際のインフラストラクチャリソース間の厳密な区分と見なします。通常、これは各テナントが個別のデータベース、コンピューティングインスタンス、アカウント、またはプライベートクラウドを持つモデルにつながります。共有リソースシナリオでは、マルチテナントアプリのように、隔離を達成する方法は論理的な構造である場合があります。
アーキテクチャの設計において、テナント間でさまざまなレベルのリソース隔離を実現できます：
一般に、テナント間で多くのリソースが共有されるほど、システムの反復とメンテナンスのコストは低下します。逆に、共有リソースが少ないほど、コストは上昇します。
テナント隔離は、主に「テナント」コンテキストを使用してリソースへのアクセスを制限することに焦点を当てています。現在のテナントのコンテキストを評価し、そのコンテキストを使用してそのテナントにアクセス可能なリソースを決定します。
Authentication と authorization は「隔離」と同等ではありません
あなたの SaaS 環境へのアクセスを制御するために authentication と authorization を使用することは重要ですが、完全な隔離には十分ではありません。これらのメカニズムはセキュリティパズルの一部としての機能にすぎません。
人々はよく一般的な authorization ソリューションやロールベースの access control を使用してテナント隔離を達成できるかどうかを尋ねます。
あなたはマルチテナントアプリを構築することができますが、テナント隔離戦略を達成および採用したとは言えません。テナント隔離は authentication と authorization とは別であるため、一般的には推奨されません。
例として、あなたが SaaS システムのために authentication と authorization を設定した状況を考えてみましょう。ユーザーがログインすると、彼らの役割に関する情報を含むトークンを受け取り、そのアプリケーションで何ができるかが決まります。このアプローチはセキュリティを高めますが、隔離を保証するものではありません。
SaaS製品のテナントを表すために「組織」をコンテキストとして使用し、テナント隔離を達成する
単に authentication と authorization に依存するだけでは、正しい役割を持つユーザーが他のテナントのリソースにアクセスするのを防ぐことはできません。そのため、テナントIDなどの「テナント」コンテキストを組み込んでリソースへのアクセスを制限する必要があります。
これがテナント隔離が果たす役割です。これは、壁、ドア、鍵のように境界を確立するために、テナント固有の識別子を使用し、テナント間の明確な分離を確保します。
マルチテナントアプリでのアイデンティティ管理はどのように行われますか？
テナント隔離について議論しましたが、アイデンティティについてはどうでしょうか？アイデンティティを「隔離」する必要があるかどうかはどのように判断しますか？
「アイデンティティ隔離」に関する概念には混乱がしばしばあります。これは一般的な理解で、1人の実世界のユーザーが2つのアイデンティティを持つ状況を指すことがあります。
- 両方のアイデンティティは、単一のアイデンティティシステム内で共存できます。たとえば、サラは個人のメールとともに、シングルサインオン (SSO) で接続された法人メールを登録しているかもしれません。
- ユーザーは、まったく別の製品を表す別々のアイデンティティシステム内で2つの異なるアイデンティティを維持します。これらの製品は互いにまったく関係がありません。
時々、これらのシナリオは「アイデンティティ隔離」と呼ばれることがありますが、その用語は意思決定には役立たないかもしれません。
「アイデンティティ隔離」が必要かどうかを問うのではなく、ビジネスまたは製品の一部が別々のアイデンティティシステムを必要としているかどうかを考えます。これがシステム設計を導きます。多くの場合、マルチテナントアプリでは、アイデンティティは共有されていますが、各テナントのリソースは分かれて保持されています。
マルチテナントアプリでは、アイデンティティはテナント固有のリソースやデータとは異なり、テナント間で共有されます。それはビルの管理者であることに似ています。テナントの名前のリストを2つ持ちたくないでしょう。
テナント隔離を目指す場合、「組織」という用語が出てくることが多いです。これはマルチテナントアプリを構築するためのベストプラクティスです。
多くのCIAM（カスタマーアイデンティティ管理）または Auth サービスで「組織」を使用することにより、統一されたアイデンティティシステムを維持しながらマルチテナントアプリでテナント隔離を達成できます。
より良い access control のために適切な authorization モデルをどのように選択しますか？
適切な authorization モデルを選択する際には、次の質問を考慮してください：
- B2C、B2B、またはその両方の種類の製品を開発していますか？
- あなたのアプリにはマルチテナントアーキテクチャがありますか？
- ビジネスユニットによって決定される、アプリに特定の隔離レベルが必要ですか？
- 組織のコンテキスト内で定義する必要がある権限と役割は何ですか、そしてどれがそうではないのですか？