マルチテナントSaaSは危険なのか？データ漏洩について考える

■ デプロイモデルとテナントデータ漏洩を正しく理解する
■ マルチテナントSaaSとは何か
■ デプロイモデルは「安全性」ではなく「トレードオフ」で見る
■ テナントデータ漏洩はどこで起きるのか
■ サイロ型でも漏洩は起こる
■ おわりに

2026-04-08

デプロイモデルとテナントデータ漏洩を正しく理解する

マルチテナントSaaSの話をすると、ほぼ必ずと言っていいほど「データ漏洩が怖い」という懸念が出てきます。特にプール型のように複数テナントが同じアプリケーションやデータベースを共有する構成では、「論理分離で本当に大丈夫なのか」という不安が生まれやすいものです。

しかし、ここで重要なのは「リソースを共有しているかどうか」そのものではありません。重要なのは、どこにテナントの境界を置き、どのレイヤーでそれを強制し、事故が起きたときにどこまで影響を閉じ込められるかです。逆に言えば、サイロ型、いわゆるシングルテナントに見える構成であっても、それだけで安全が保証されるわけではありません。

本稿では、マルチテナントSaaSの基本的なデプロイモデルを整理したうえで、なぜテナントデータ漏洩が起こるのか、そしてなぜ「サイロ型だから安全」という理解が危ういのかを考えていきます。

マルチテナントSaaSとは何か

SaaSにおけるテナントとは、一般に顧客企業や部署、チームなどの契約単位を指します。SaaS提供事業者は、複数のテナントに対して同じサービスを継続的に提供しながら、それぞれのデータや権限を適切に分離しなければなりません。つまりSaaSとは、単にソフトウェアを提供するだけではなく、運用と分離の責任まで引き受けるサービス型の事業モデルだと言えます。

この時、スケーラビリティや運用効率を得るためには、できるだけ共通のリソースで多くのテナントを扱いたくなります。一方で、共通化を進め過ぎれば、境界の設計やアクセス制御の精度がより重要になります。マルチテナントSaaSにおける設計は、常にこの緊張関係の中にあります。

なお、顧客ごとにアプリケーションだけでなく、契約管理や請求、テナント管理といった管理基盤まで丸ごと複製していくと、共通の運用基盤を持つSaaSというより、MSP的なモデルに近づいていきます。どこまでを共有し、どこからを個別化するのかは、単なる技術論ではなく事業モデルの設計そのものなのです。

デプロイモデルは「安全性」ではなく「トレードオフ」で見る

サイロ型

サイロ型は、テナントごとにコンピュートやデータベースを分ける構成です。分離レベルが高く、ノイジーネイバーの影響も受けにくいため、厳しいセキュリティ要件やコンプライアンス要件を持つ顧客には適しています。一方で、テナント数が増えるほど環境数も増え、運用負荷とコストが重くなります。

プール型

プール型は、複数テナントでアプリケーションやデータベースを共有する構成です。クラウドネイティブなSaaSではもっとも基本的な選択肢であり、コスト効率と運用効率に優れます。データ分離の実装としては、行分離、スキーマ分離、データベース分離などがあり、PostgreSQLのRow Level Security(RLS)のような仕組みも有力です。ただし、テナント境界をアプリケーションとデータストアの両方で正しく表現しなければなりません。

ハイブリッド型

実際のSaaSでは、サイロとプールを組み合わせたハイブリッド型もよく採用されます。例えば、コンピュートは共有しつつデータベースはテナントごとに分離する、あるいは通常プランは共有基盤、上位プランだけ専有基盤にする、といった形です。これはセキュリティ、性能、価格、運用のバランスを取るための現実的な設計です。

つまり、どのモデルが「正しい」かではなく、どのリスクをどこまで受け入れ、どのコストを払うのかが重要なのです。

テナントデータ漏洩はどこで起きるのか

テナントデータ漏洩は、プール型だから起きるのではありません。多くの場合は、テナントコンテキストの扱いを誤ることで発生します。典型例は、書き込み、読み込み、キャッシュです。

1. 書き込み時のミス

同じワーカーや接続プールの中でテナントコンテキストを曖昧に扱うと、別テナントの領域にデータを書き込んでしまう危険があります。

// NG: テナント情報の受け渡しが暗黙的
$db = getConnection();
$orderRepository->save($db, $order);

このような実装では、どのテナントに保存されるべきデータなのかがコード上で明示されません。安全側に倒すなら、リポジトリやデータアクセス層が tenant_id の受け取りを必須にし、保存前に検証するべきです。

// OK: tenant_id を明示的に渡す
$orderRepository->save($tenantId, $order);

2. キャッシュによる漏洩

AIとのやり取りやFAQ応答でキャッシュを使う場合、キーにテナント情報が含まれていないと危険です。

NG: cache_key = hash(question)
OK: cache_key = tenant_id + user_id + hash(question)

一見便利な共通キャッシュも、テナント境界を失った瞬間に情報漏洩の媒体になります。特に生成AIでは、似た質問に対して高速化のために応答を再利用したくなるため、この論点は今後さらに重要になるでしょう。

3. 読み込み時のミス

もっとも典型的なのは、SQLのWHERE句から tenant_id が抜け落ちるケースです。

-- NG
SELECT * FROM invoices WHERE status = 'open';

-- OK
SELECT * FROM invoices WHERE tenant_id = :tenant_id AND status = 'open';

ただし、アプリケーション側の注意だけに依存するのは危険です。可能であれば、RLSやビュー、権限分離などを活用し、アプリケーション層でミスをしてもデータベース側で越境を防げるようにしておくべきです。境界は一箇所ではなく、多層で守るのが基本です。

サイロ型でも漏洩は起こる

1. 共通アプリケーション脆弱性による漏洩

たとえばRemote Code Execution(RCE)や認証バイパス、Server Side Request Forgery(SSRF)の脆弱性が共通アプリケーションに存在すると、攻撃者は個別テナント環境の外側から横断的に侵入できます。管理APIや内部メタデータ、テナント切替機能に到達されると、別テナント環境への接続情報や一時資格情報を取得される危険があります。サイロ型であっても、同じアプリケーションバージョンを全テナントに配っていれば、脆弱性は全テナントに共通です。結果として、ある脆弱性が「1テナントの事故」ではなく「全顧客横断の事故」になりえます。対策としては、一般的なWebアプリ対策に加えて、コントロールプレーンの分離、Instance Metadata Service(IMDS)v2の活用、最小権限の徹底、Web Application Firewall(WAF)の導入、脆弱性診断、依存ライブラリ更新の継続が必要です。さらに、テナント切替や内部管理機能は通常機能より厳しく監査し、特権操作を多要素認証や承認付きにするなども考えられます。

2. IAM / 認証基盤の侵害による漏洩

ソーシャルハッキングやフィッシング、トークン窃取により、運用者やContinuous Integration(CI)用の認証情報が奪われると、攻撃者はインフラへ正規ユーザーのように侵入できます。この場合、サイロ型でデータベースが個別に分かれていても、十分な権限を持つアカウントなら複数環境を横断して参照できます。特に、全テナント共通の管理者ロール、秘密情報ストア、踏み台、SSO管理画面が侵害されると被害は一気に広がります。「物理的に分かれているから安心」と考えていても、認証の入口が共有されていれば境界は簡単に跨がれます。対策としては、多要素認証の強制、短命資格情報、Just-In-Time権限付与、ブレイクグラス管理、操作監査などが考えられます。加えて、人とシステムの権限を分離し、テナントごとの管理権限も極力スコープダウンする設計が重要です。

3. CI/CD・デプロイパイプライン侵害による漏洩

ビルド環境やGitHub Actions、アーティファクトレジストリ、署名鍵が侵害されると、攻撃者は正規リリースに見える形でマルウェアや不正コードを混入できます。そのコードが監視回避やデータ外送信を行うものであれば、サイロ型で分かれている各テナント環境から順番に情報を吸い上げることが可能です。これは「環境が分かれていても、同じソフトウェアを配っている」というSaaSの宿命に近いリスクです。侵害が発覚しにくいまま全顧客へ展開されると、被害の検知も封じ込めも遅れます。対策としては、ブランチ保護、レビュー強制、ビルドの再現性確保、成果物署名、デプロイ承認、CIシークレット分離、サプライチェーン監査が必要です。さらに、テナントごとに段階展開できる仕組みを持つと、異常時のロールバックと影響の局所化がしやすくなります。

4. 共通ログ・バックアップ・運用ツールからの漏洩

本番データそのものを分離していても、ログ基盤、分析基盤、バックアップ、サポート用管理画面が共通であれば、そこから漏洩することがあります。例えば、アプリケーションログに個人情報やトークンを出力していたり、バックアップに複数テナント分のデータが集約されていたりすると、閲覧権限のある担当者や侵入者が横断的に取得できます。特に障害対応やカスタマーサポート用のツールは、利便性を優先して広い参照権限を持ちがちです。この種の漏洩は、本番DBの分離だけを見ていると設計レビューから抜け落ちやすいのが厄介です。対策としては、ログのマスキング、機微情報の非出力、バックアップ暗号化、閲覧権限の分離、サポート操作の監査証跡、テナント単位の検索制御が必要です。「運用のための共通基盤」こそ、サイロ型の盲点になりやすいと理解しておくべきです。

つまり、サイロ型は「いくつかの事故のBlast Radiusを小さくする」ための有効な手段ではあっても、「それだけで安全」という意味ではありません。重要なのは、どの脅威に対して何が効くのかを切り分けて理解することです。データの分離モデルはあくまで防御の一層であり、認証、配布経路、監査、運用統制まで含めてはじめて実効的なテナント保護になります。