マルチテナントSaaSにおけるIdPテナント分離：設計原則とセキュリティ検証チェックリスト

B2B SaaSでIdP（Identity Provider）をマルチテナントで運用するということは、1つのシステム内に複数の企業の認証情報を保管するということです。A社のOAuthクライアントシークレットがB社に漏洩したり、C社の監査ログにD社のユーザー記録が混ざってはなりません。それでもこの問題を本格的に検討する時期は、多くの場合データ漏洩事故の後です。

この記事では、マルチテナントIdPにおいてテナント分離がなぜ重要なのか、どのようなアーキテクチャの選択肢があるのか、そして導入前に必ず確認すべきセキュリティチェックリストを整理します。

テナント分離がIdPで特に重要な理由

一般的なSaaSと異なり、IdPはセキュリティの最前線で動作します。IdPが保管するデータは単なるビジネスデータではありません。

• ユーザー認証情報：メールアドレス、パスワードハッシュ、MFAシード • プロトコルシークレット：OAuth client_secret、SCIM Bearerトークン、SAML署名鍵 • アクセス記録：監査ログ全体 — ユーザーがいつ、どこにアクセスしたか

これらのデータのいずれかが別のテナントに漏洩すると、攻撃者はその情報を基に連鎖的な侵入を試みることができます。ビジネス上の損失を超えて、個人情報保護法違反、SOC 2 Type II不合格などの法的・規制的リスクに直結します。

テナント分離アーキテクチャ3種類

マルチテナントシステムの分離は、3つのレベルで設計できます。

1. データベースレベル分離（物理的分離）

テナントごとに別々のデータベースインスタンスを割り当てます。

• メリット：分離が物理的に完全に保証される。あるテナントのDBアクセスが別のテナントに影響を与えない • デメリット：テナントが増えるたびにDBインスタンスを管理する必要があり、運用コストが急増。スキーママイグレーションを全DBに一括適用する負担

小規模なテナント数（数十以下）では実用的ですが、SaaSスケールでは運用複雑度が幾何級数的に増加します。

2. スキーマレベル分離

同じデータベースインスタンス内でテナントごとに別々のスキーマを作成します。

• メリット：DBインスタンスを共有するためコスト削減。スキーマ単位でバックアップ・リストアが可能 • デメリット：コネクションプール管理が複雑になる。テナント数が増えるとスキーマ数も増加

中程度の分離が必要な場合に適していますが、SaaS運営ではかえって管理負担が大きい側面があります。

3. 行レベル分離（共有データベース）

全テナントが同じテーブルを共有し、各行に tenant_id を置いて論理的に分離します。

• メリット：スケールが容易。スキーママイグレーションが1回のみで済む。インフラコストが最も低い • デメリット：アプリケーション層ですべてのクエリに tenant_id フィルタを必ず適用する必要がある。1回のミスがクロステナント漏洩につながる可能性

成熟したB2B SaaS IdPの大部分（AxiPass含む）がこの方式を採用しています。運用効率が最も高いですが、それだけ分離保証メカニズムが徹底している必要があります。

行レベル分離の要：自動スコーピング

行レベル分離を信頼できるようにするには、開発者が毎クエリに手動で tenant_id 条件を入れる方式であってはなりません。ORMレベルで自動的に tenant_id = ? 条件を追加するメカニズムが必要です。

Railsの acts_as_tenant のようなライブラリがこの役割を担います。コントローラでテナントコンテキストを設定すると、そのリクエストのすべてのActiveRecordクエリに自動的に tenant_id 条件が含まれます。開発者がうっかり忘れる余地を根本的に排除する仕組みです。

ルーティング方式と分離の関係

テナントを識別する方式により、セッション・キャッシュ・CSRF保護の分離レベルが変わります。

Path-basedルーティング（/t/:tenant_slug）

URLパスにテナント識別子が含まれます。例：axi-pass.app/t/acme/members

• ルート解釈の段階でテナントコンテキストが確定するため、コントローラに入る前に tenant_id スコーピングが完了 • セッション、キャッシュキー、CSRFトークンをテナント単位で分離しやすい • 1つのドメインのみ管理すればよいため、SSL証明書とDNSの運用負担が少ない

サブドメインルーティング（tenant.app.com）

テナントごとにサブドメインを割り当てます。

• クッキーのドメインスコープがサブドメインで分離され、セッション分離が自然に保証される • 一方、サブドメインの作成・削除をDNSで管理する必要があり、ワイルドカードSSL証明書が必要

ドメインベース（顧客独自ドメイン）

顧客企業が自社ドメインを使用します。例：auth.acme-corp.com

• 顧客側でブランド体験が最も良い • ドメインごとのSSL証明書発行、DNSレコード管理が運用負担として増加

どの方式でも、重要なのはルーティング層で決定されたテナントコンテキストがセッションの全存続期間にわたり一貫して維持されることです。

バッチ処理とバックグラウンドジョブでの分離

WebリクエストではORMが自動スコーピングを処理しますが、バックグラウンド処理では異なります。

• ActiveJobやSidekiqで tenant_id を明示的にキューに含める必要がある • スケジューラがテナントを巡回する際、あるテナントのコンテキストが次のテナントに漏洩しないこと • データベースクエリではなく外部API呼び出し（SCIM同期、メール送信）でもテナントコンテキストが明確であること

この検証を怠ると、A社のオフボーディング処理がB社のSCIMエンドポイントにリクエストを送信する深刻な事故につながる可能性があります。

監査ログのテナント分離

監査ログはコンプライアンス証拠の核心であるため、テナント間の分離に格別な注意が必要です。

• ログ照会画面で管理者が別のテナントのログを閲覧できないこと • ログエクスポート（CSV/PDF）時に対象が明確にテナント範囲で限定されること • グローバル管理者（運営者）のみ全テナントログにアクセス可能で、その権限も監査対象であること

マルチテナントIdP評価チェックリスト

IdPを導入または構築する際、テナント分離の側面で必ず確認すべき項目です。

• すべてのクエリにtenant_idが自動的にフィルタリングされるか • API層でテナントコンテキストが欠落するとリクエストが拒否されるか • バッチ処理とバックグラウンドジョブでも分離が保証されるか • キャッシュ（Redis、Solid Cache）キーにtenant_idが含まれるか • ファイルストレージ（S3等）でテナントごとのパス分離がされているか • 監査ログがテナント単位で分離されているか • テナント分離に対する自動テスト（Integration Test）が存在するか

最後の項目が最も重要です。コードレビューと手動テストだけでクロステナント漏洩を完全に防ぐことはできません。「テナントAのリクエストがテナントBのデータにアクセスすると失敗する」というテストケースがCIに含まれている必要があります。

---

マルチテナントIdPにおけるテナント分離は、設計段階で決定すべき最初のセキュリティ事項です。アーキテクチャ選択からルーティング、バッチ処理、監査ログまで全レイヤーで一貫した分離が保証されて初めて、SaaS顧客に「お客様の認証情報は安全に分離されています」と言えるようになります。

AxiPassはpath-basedルーティングと行レベル分離を組み合わせて、すべてのレイヤーでテナント間のデータ分離を保証しています。SaaS企業の認証セキュリティにご関心がある場合は、無料で始めるください。