マルチテナントアプリケーションにおけるテナントの分離
テナントの分離はマルチテナントアプリケーションにおける重要な概念です。この記事では、その内容と実現方法について説明します。
Product & Design
こんにちは、皆さん！この章では、以前のマルチテナントに関する議論を基に発展させていきます。まだ以前の記事を読まれていない方は、まずそちらから始めることをお勧めします！
マルチテナントアプリケーションを論じる際には、テナントの分離を考えることが重要です。これにより、異なるテナントのデータやリソースを共有システム内で（例えば、クラウドインフラやマルチテナントアプリケーション）分けて安全に保つことができます。
テナントの分離の目的は、各テナントのデータと操作が同じ基盤のリソースを使用していても、お互いに独立して安全であることを確保することです。
Software as a Service (SaaS) シナリオでは、テナントの分離には SaaS フレームワーク内でリソースアクセスを厳格に規制する構造を作成することが含まれます。これにより、他のテナントのリソースへの不正アクセスの試みを防ぎます。
説明が抽象的に思えるかもしれませんが、例や重要なポイントを使って、分離の考え方をさらに説明していきます。
テナントの分離はマルチテナンシーの「共有」理念に反しない
それは、テナントの分離が必ずしもインフラのリソースレベルの構造ではないからです。マルチテナンシーと分離の領域では、分離を実際のインフラリソース間の厳格な区分と見る人もいます。これは通常、各テナントが個別のデータベース、コンピューティングインスタンス、アカウント、またはプライベートクラウドを持つモデルに導きます。マルチテナントアプリのような共有リソースのシナリオでは、分離を達成する方法は論理的構造となり得ます。
テナントの分離は「テナント」コンテキストを使用してリソースへのアクセスを制限することに専念しています。それは、現在のテナントのコンテキストを評価し、そのコンテキストを使用して、そのテナントにアクセス可能なリソースを決定します。この分離をそのテナント内のすべてのユーザーに適用します。テナントリソースへのアクセスの試みは、そのテナントに属するリソースにのみ限定されるべきです。
分離は異なるレベルで行われる
分離がインフラのリソースレベルに厳密に結びついていないこと、物理的インフラ間の明確な分離ではないことを理解すると、次のような結論に至ります：
分離を単純な「はい」または「いいえ」と見るのではなく、それをスペクトラムとして考えてみてください。システムの一部を必要に応じてより隔離または少し隔離して設定できます。
以下の図は、この隔離のスペクトラムを示しています。
認証と認可は「分離」とは異なる
SaaS 環境へのアクセスを制御するために認証と認可を使用することは重要ですが、それだけでは完全な分離は達成できません。これらのメカニズムはセキュリティパズルの一部に過ぎません。
多くの人がこう質問します、一般的な認可ソリューションとロールベースのアクセス制御を使ってテナントの分離を達成することは可能ですか？ マルチテナントアプリを構築できますが、テナントの分離戦略を最善の慣行として達成し採用したとは言えません。一般的には推奨しません。
例を挙げると、SaaS システムの認証と認可を設定した状況を考えてみてください。ユーザーがログインすると、アプリで何ができるかを指示する役割の情報を含むトークンを受け取ります。このアプローチはセキュリティを高めますが、分離を保証するものではありません。
ここでの落とし穴は、「テナント」コンテキスト（例えばテナント ID）を組み込んでリソースへのアクセスを制限しない限り、認証と認可だけに依存しても適切な役割を持つユーザーが他のテナントのリソースにアクセスす るのを防ぐことはできません。
ここでテナントの分離が役立ちます。それは、テナント特有の識別子を使って境界を設定し、壁や扉、鍵のようにテナント間に明確な分離を確保します。
マルチテナンシーアプリケーションにおけるアイデンティティ
テナントの分離について話しましたが、アイデンティティはどうでしょうか？ あなたのアイデンティティが「分離」される必要があるかどうかはどのようにして決めますか？
「アイデンティティの分離」という概念にはしばしば混乱があります。それは、一般的な理解において1人の実世界のユーザーが2つのアイデンティティを持つ状況を指すことがあります。
- 両方のアイデンティティが1つのアイデンティティシステム内で存在します。例えば、サラが個人用のメールアドレスを登録し、企業のメールをシングルサインオン (SSO) を通じて接続している場合です。
- ユーザーが異なるアイデンティティシステム内で2つの別々のアイデンティティを維持し、完全に無関係な製品を表す場合です。
時折、これらのシナリオは「アイデンティティが分離されている」と呼ばれることがあります。しかし、このラベルは意思決定には役立たないかもしれません。
「アイデンティティの分離」が必要かどうかを決定する代わりに、ビジネスや製品の一部が別のアイデンティティシステムを維持する必要があるかどうかを考えてみてください。この答 えはあなたのアイデンティティとアクセス管理 (IAM) システムのデザインを導くことができます。マルチテナントアプリに関する簡潔な回答としては、
ほとんどの場合、マルチテナントアプリでは、テナント特有のリソースとデータとは異なり、アイデンティティは複数のテナント間で共有されます。
マルチテナントアプリケーションでは、アイデンティティは、テナント特有のリソースやデータとは異なり、複数のテナント間で共有されます。ビルの管理者としての自分を想像してみてください。テナントのアイデンティティを管理するために2つの別々の名簿を持ちたいとは思わないでしょう。
テナントの分離を目指す際に、マルチテナントアプリケーションを構築するためのベストプラクティスとされる「組織」という用語に繰り返し注目しているのに気づくかもしれません。
「組織」という概念を採用することで、一体化したアイデンティティシステムを維持しながら、マルチテナントアプリケーションでテナントの分離を達成できます。これにより、複数の「組織」が独立しながらもアプリケーション内でテナントに依存しないリソースを共有して共存できます。まるでビルに住む住人のように、各組織が隣人を気にせず、アプリケーションを利用します。「組織」は壁、廊下、ドア、鍵の形式で必要な分離を提供します。彼らは全体的なビルのインフラ、インテリアデザインシステム、さまざまな有形または無形のコンポーネントを共有します。
Logto が「組織」機能を 11 月に導入
Logto は現在、「組織」機能を積極的に開発しており、2023 年 11 月にローンチを予定しています。この機能は、業界標準とベストプラクティスに沿った SaaS 製品を構築するために必要なテナントの分離要件を満たすために特別に設計されています。
次の章では、「組織」機能についてより深く掘り下げ、Logto がマルチテナントアプリケーションを構築するためのベストプラクティスの実装をどのように促進するかについて詳しく説明します。