multi-tenancy

マルチテナンシー

テナント ID は、クエリを便利にするためのものではなく、認可境界として扱ってください。

分離モデルを選択する

• テナントごとにデータベースを分ける：分離が最も強固で、運用コストも最も高くなります。
• テナントごとにスキーマを分ける：インフラを共有しながら、強力な論理的分離を実現できます。
• tenant_id を含む共有スキーマ：運用は最も簡単ですが、すべてのアクセス経路でスコープを適用する必要があります。
• 選択したモデルを文書化し、リポジトリがそれを迂回することを禁止してください。

テナント ID を解決する

• 検証済みトークンのクレーム、信頼できるホストのマッピング、または認証済み API キーからテナントを特定してください。
• テナント ID がない場合、不明な場合、無効化されている場合、または競合している場合は拒否してください。
• 公開されている X-Tenant-Id ヘッダーだけを信頼してはいけません。
• finally でサーブレットのスレッドローカルコンテキストをクリアし、リアクティブなフローでは Reactor Context を使用してください。

分離を強制する

• 永続化セッションまたはトランザクションを開始する前に、テナントを選択してください。
• 一意制約、キャッシュキー、冪等性キー、オブジェクトストレージのパスにテナント ID を含めてください。
• テナントをまたぐ結合や、制限のない管理者向けリポジトリを防止してください。
• サポート目的のなりすましを明示的に認可し、使用するたびに監査ログを記録してください。

運用

• 再開可能な進捗管理とバージョン報告を備え、データベース／スキーマごとにマイグレーションを実行してください。
• スケジュール済みジョブ、メッセージ、非同期タスクには、テナント ID を明示的に引き継いでください。
• 上限付きの識別子を使用したクォータとテナントごとの可観測性により、過剰なリソース消費を抑制してください。
• テナントをまたぐアクセスが成功しないことをテストしてください。テナントのクエリが成功することだけを確認してはいけません。

例

• examples/good-tenant-filter.java と examples/bad-tenant-filter.java を参照してください。

注意点

• エージェントが呼び出し元から渡されたテナントヘッダーを信頼する場合 — 認証済みコンテキストからテナントを特定してください。
• エージェントがサーブレットの ThreadLocal をクリアし忘れる場合 — プールされたスレッドを介して、あるテナントの情報が別のリクエストに漏れる可能性があります。
• エージェントがデータベースのクエリにはスコープを適用しても、キャッシュキーには適用しない場合 — キャッシュデータがテナント間で共有される可能性があります。
• エージェントがテナントを選択する前にトランザクションを開始する場合 — 誤ったデータベースにルーティングされる可能性があります。
• エージェントがテナントコンテキストなしでバックグラウンドジョブを実行する場合 — テナントをジョブの明示的なパラメーターにしてください。