マルチテナント認証と認可の設定に関する究極のガイド
マルチテナントアプリケーションの作成は複雑です。この記事では、マルチテナントと組織戦略に関する過去の記事をすべて集めています。時間を節約し、簡単に始めるお手伝いができれば幸いです。
Product & Design
マルチテナントアプリを構築することは多くの側面を考慮すべきで、挑戦的です。この記事は、マルチテナントと組織の実践を理解するための過去のブログ記事をすべてまとめています。すぐに始めるために時間を節約したい場合は、この記事を確認するだけで、必要な情報がすべて含まれています！
一般的なガイドラインは次のステップに概説されています。
- マルチテナントアーキテクチャを理解する
- マルチテナントアプリのユースケースをマッピングする
- テナントの分離を達成する
- アイデンティティを管理する方法を定義する
- 適切な認可モデルを選択する
マルチテナントアーキテクチャとは何か
ソフトウェアのマルチテナンシーとは、サーバ上で単一のインスタンスのソフトウェアが動作し、複数のテナントにサービスを提供するソフトウェアアーキテクチャです。このように設計されたシステムは「共有」されており（「専用」や「分離」されているわけではありません）。
テナントとは、特定の特権を持ち、ソフトウェアインスタンスに共通アクセスするユーザーのグループです。
マルチテナンシーの主要な考え方の一つは「共有」です。マルチテナンシーのより広い定義では、マルチテナントアプリケーションであるということはソリューションのすべてのコンポーネントが共有されることを意味するわけではありません。むしろ、ソリューションの少なくとも一部のコンポーネントが複数のテナントで再利用されることを意味します。この用語を広く理解することが、クライアントのニーズと彼らがどこから来ているかをよりよく理解する助けになります。
マルチテナントアーキテクチャを理解したら、次はアプリを実際のシナリオに適用し、特定の製品とビジネスニーズに焦点を当てます。
マルチテナントアプリケーションのユースケースとは？
SaaSにおけるマルチテナント
ビジネス向けの生産性ツール、コラボレーションソフトウェア、その他のSaaS製品のようなB2Bソリューションで、マルチテナントアプリはしばしばその場所を見つけます。この文脈では、それぞれの「テナント」は通常、複数のユーザー（従業員）を持つビジネス顧客を表します。さらに、ビジネス顧客は、異なる組織やビジネス部門を表現するために複数のテナントを持つことがあります。
一般的なB2Bユースケースにおけるマルチテナント
B2BアプリケーションはSaaS製品を超えて進化し、多くの場合マルチテナントアプリが含まれます。B2Bの文脈では、これらのアプリはさまざまなチーム、ビジネスクライアント、パートナー企業がアプリケーションにアクセスするための共通プラットフォームとして機能します。
例えば、B2CとB2Bアプリを提供するライドシェア会社を考えてみましょう。B2Bアプリは複数のビジネスクライアントにサービスを提供し、マルチテナントアーキテクチャを採用することで、従業員やリソースの管理を支援できます。例えば、会社が統一されたユーザーアイデンティティシステムを維持したい場合、次のようなアーキテクチャを設計できます。
サラはパーソナルとビジネスの両方のアイデンティティを持っています。彼女はライドシェアサービスを乗客として利用し、また空き時間でドライバーとしても働いています。プロフェッショナルな役割では、自分のビジネスを管理し、このビジネスアイデンティティを使ってビジネス1のパートナーになります。
なぜSaaS製品にマルチテナンシーを採用 する必要があるのか
マルチテナンシーによるスケーリング
エンタープライズビジネスにとって、マルチテナンシーは、可用性、リソース管理、コスト管理、データセキュリティの要件を効果的に満たすための鍵です。技術的には、マルチテナントアプローチを採用することで、開発プロセスが合理化され、技術的な課題が最小限に抑えられ、スムーズな拡張が促進されます。
統一された体験の作成
SaaS製品の根本を調べると、それは様々なアパートを抱える建物に似ています。すべてのテナントが水道、電気、ガスなどの共通の設備を共有していますが、それぞれが自分のスペースとリソースを管理する独立した権限を持っています。このアプローチは物件管理を簡素化します。
テナント分離を通じたセキュリティの保証
マルチテナンシーのアーキテクチャでは、「テナント」という用語が導入され、共有インスタンス内での異なるテナントのリソースとデータを分離して保護する境界を作成します。これにより、各テナントのデータと操作が、同じ基盤リソースを利用していても明確に分離され、安全であること が保証されます。
なぜテナント分離を達成する必要があるのか？
マルチテナントアプリケーションについて話すときは、常にテナント分離を達成する必要があります。これは、異なるテナントのデータとリソースを、共有システム（たとえばクラウドインフラストラクチャやマルチテナントアプリケーション）内で分離して保護することを意味します。これにより、または許可されていない試みが他のテナントのリソースにアクセスしようとすることを防ぎます。
説明が抽象的に感じられるかもしれませんが、例と重要な詳細を使用して、分離の考え方とテナント分離を達成するためのベストプラクティスをさらに説明します。
テナント分離はマルチテナンシーの「共有」思考に反しているわけではない
それは、テナント分離が必ずしもインフラストラクチャーレベルの資源構成ではないからです。マルチテナンシーと分離の領域では、一部の人は分離を実際のインフラストラクチャーリソース間の厳格な区分と見なす。これは通常、各テナントが個別のデータベース、コンピューティングインスタンス、アカウントまたはプライベートクラウドを持つモデルにつながります。共有リソースのシナリオでは、マルチテナントアプリのように 、分離を達成する方法は論理的な構成です。
テナント分離は、「テナント」コンテキストを使用して、リソースへのアクセスを制限することに主に集中しています。それは現在のテナントのコンテキストを評価し、そのコンテキストを使用してそのテナントにアクセス可能なリソースを決定します。
認証と認可は「分離」と同じではない
SaaS環境へのアクセスを制御するために認証と認可を使用することは重要ですが、完全な分離を保証するには十分ではありません。これらのメカニズムは、セキュリティパズルの一部に過ぎません。
人々はよく、一般的な認可ソリューションや役割ベースのアクセス制御を使用してテナント分離を達成できますか？と質問します。
要点は、マルチテナントアプリを構築することはできますが、ベストプラクティスとしてテナント分離戦略を達成および採用しているとは言えません。一般的には推奨しません。
例を挙げると、SaaSシステムのために認証や認可を設定した場合を考えます。ユーザーがログインすると、アプリケーションでできることを示す情報を含むトークンを受け取り ます。このアプローチはセキュリティを向上させますが、分離を保証するものではありません。
SaaS製品のテナントを表現するために「組織」を使用してテナント分離を達成
認証と認可のみに依存しても、適切な役割を持つユーザーが他のテナントのリソースにアクセスすることを防ぐことはできません。そのため、「テナント」コンテキスト、例えばテナントIDを取り入れてリソースへのアクセスを制限する必要があります。
これがテナント分離が登場するところです。それはテナント固有の識別子を使用して境界を確立し、壁、ドア、ロックのように、テナント間の明確な分離を確保します。
マルチテナントアプリにおけるアイデンティティ管理
テナント分離を議論しましたが、アイデンティティについてはどうでしょうか？アイデンティティが「分離」されるべきかどうかをどのように決定しますか？
「アイデンティティの分離」という概念には混乱が伴うことがよくあります。それは一般的には、1人の現実世界のユーザーが2つのアイデンティティを持つ状況を指します。
- 両方のアイデンティティが単一のアイデンティティシステム内に存在できます。例えば、サラは、シングルサインオン（SSO）で接続された 企業メールと並んでパーソナルメールを登録しているかもしれません。
- ユーザーが完全に無関係な2つの製品を表現する別々のアイデンティティシステム内で2つの異なるアイデンティティを維持します。
これらのシナリオが「アイデンティティの分離」と呼ばれることがありますが、このラベルは意思決定に役立たないかもしれません。
「アイデンティティの分離」が必要かどうかを考えるよりも
この答えはシステム設計の指針となります。マルチテナントアプリに関して短い答えを提供するなら、
マルチテナントアプリケーションでは、テナント固有のリソースやデータとは異なり、アイデンティティは複数のテナント間で共有 されます。あなた自身を建物管理者として想像してください。あなたはテナントのアイデンティティを管理するために2つの別々の名前リストを維持することを望まないでしょう。
テナント分離を目指すとき、しばしば「組織」という用語に繰り返し強調されることに気付くかもしれませんが、これはマルチテナントアプリケーションを構築するためのベストプラクティスと見なされています。
「組織」の概念を利用することで、マルチテナントアプリケーションでテナント分離を達成し、統一されたアイデンティティシステムを維持できます。
適切な認可モデルを選択し設計する方法
適切な認可モデルを選択するときは、次の質問を考慮してください。
- あなたはB2C、B2B、または両方のタイプの製品を開発していますか？
- あなたのアプリにはマルチテナントアーキテクチャがありますか？
- ビジネスユニットによって決定される、アプリ内にある特定レベルの分離が必要ですか？
- 組織のコンテキスト内で定義する必要がある権限と役割は何であり、そうでないものは何ですか？
Logtoで利用可能な異なる認可モデルは何か？
役割ベースのアクセス制御
RBAC（Role-Based Access Control）は、ユーザーの役割に基づいて権限を付与し、リソースへのアクセス管理を効果的に行う方法です。
この一般的な手法はアクセス制御の基盤となっており、Logtoの認可機能の重要な要素です。包括的なアイデンティティ管理プラットフォームとして、Logtoはさまざまなレイヤーとエンティティに向けたカスタムソリューションを提供し、開発者と企業に多様な製品アーキテクチャを提供します。
API役割ベースのアクセス制御
特定の組織に固有でなく、コンテキスト制限が必要ない一般的なAPIリソースを保護するには、API RBAC機能が理想的です。
APIを登録し、各リソースに権限を割り当てるだけです。それから、役割とユーザーの関係を通じてアクセスを制御します。
APIリソース、役割、権限はここで統一されたアイデンティティシステムの下で「民主化」されます。これは階層が少なく、非常に深いレベルの分離が必要ないB2C製品で一般的です。
組織役割ベースのアクセス制御
B2Bおよびマルチテナント環境では、テナント分離が必要です。これを達成するために、組織は分離のコンテキストとして使用され、RBACは特定の組織に属するユーザーのみに効果的です。
組織RBACは、APIレベルよりもむしろ組織レベルでのアクセス制御に焦点を当てています。これは長期的に組織レベルでの自己管理に大きな柔軟性を提供しつつ、統 一されたアイデンティティシステム内でのものです。
組織RBACの重要な機能は、役割と権限がデフォルトで全組織において同じであり、これがLogto「組織テンプレート」を極めて開発効率を向上させる意味を持ちます。これはSaaS製品で一般的な実践である、すべてのテナント（アプテンナント）間で共通インフラストラクチャコンポーネントのアクセス制御ポリシーとアイデンティティが共有されるという考え方に一致しています。
閉会
この記事は、マルチテナントアプリの準備と設定に必要なすべてを提供します。今日Logtoを試して、組織を使ったマルチテナントアプリ開発のベストプラクティスを適用し始めましょう。