マルチテナントは運命共同体：規制対象データのリージョナルクラウドホスティングに潜むリスク

主なポイント

1. 共有インフラは「運命共同体」を生む。マルチテナント型プラットフォームでは、数千社の顧客間でデータベース、ランタイム、オペレーティングシステムが共有されており、物理的な境界ではなくソフトウェアロジックによってのみ分離が実現されています。
2. 単一の脆弱性が全テナントに影響。共有レイヤーの脆弱性や設定ミスにより、プラットフォーム上のすべての顧客が影響を受ける可能性があり、被害範囲は最初に影響を受けたアカウントをはるかに超えて拡大します。
3. リージョナルホスティングでも共有構造は変わらない。データレジデンシーのラベルは、根本的なマルチテナントアーキテクチャを変更するものではなく、リージョンごとの展開でも通常はグローバルにデータベースや管理アクセスが共有され続けます。
4. シングルテナントで共有リスクを排除。専用のデータベース、ランタイム、限定された管理アクセスにより、ある顧客のリスクが他の顧客に波及することを防ぎ、インフラ層での「運命共同体」リスクを排除します。

はじめに

マルチテナント型クラウドプラットフォームは、物理的な境界ではなくソフトウェアロジックによってのみ分離された同一の基盤データベース、アプリケーションランタイム、オペレーティングシステム上で数千社の顧客を稼働させます。ほとんどのエンタープライズ顧客は、マルチテナンシーが主流SaaS製品の標準アーキテクチャであるため、このトレードオフを深く検証せずに受け入れています。

このトレードオフには、ベンダーのマーケティングではほとんど登場しない「運命共同体（shared fate）」という名前があります。インフラが共有されていれば、リスクも共有されます。単一の脆弱性の悪用、設定ミス、認証情報の侵害は、1社のデータにとどまらず、同じ共有レイヤー上のすべてのテナントに波及します。データセンターの国がどこであっても同様です。本記事では、プロバイダーのマーケティング表現の裏で実際に何が共有されているのか、そして規制対象組織がロケーションと同じくらいテナンシーモデルを慎重に評価すべき理由を解説します。

ポイント1：マルチテナント型プラットフォームは、数千社の顧客間でデータベース、ランタイム、オペレーティングシステムを共有しています。テナント間の分離は、物理的に独立したインフラではなく、ソフトウェアロジックによって実現されています。

ポイント2：単一のクロステナント脆弱性により、多数の顧客が同時に危険にさらされます。マルチテナント型侵害の被害範囲は、そのインフラ層を共有するすべての組織に及びます。

ポイント3：リージョナルホスティングのラベルでは、マルチテナントのリスクは排除できません。グローバルプラットフォームのリージョン展開でも、通常はデータベースや管理コンソール、サポートアクセスがプロバイダー全体で共有されています。

ポイント4：管理・サポートアクセスは隠れた攻撃対象領域です。マルチテナント型プロバイダーは、規制対象組織がほとんど精査しないまま、顧客環境への運用アクセス権を保持していることが一般的です。

ポイント5：シングルテナントアーキテクチャは、インフラ層での「運命共同体」リスクを排除します。専用のデータベース、ファイルシステム、ランタイムにより、ある顧客のリスクが他の顧客の侵害につながることを防ぎます。

エグゼクティブサマリー

マルチテナンシーはクラウドプロバイダーにとって効率的なモデルである一方、顧客にとってはリスクの集中を意味します。数千の組織が同じデータベース、ランタイム、管理ツールを共有しているため、その共有レイヤーの単一の欠陥が最初に発見された顧客をはるかに超えて影響を及ぼす可能性があります。エンタープライズのリスク・コンプライアンス部門にとって、テナンシーモデルは暗号化やアクセス制御、物理ロケーションと同じレベルの精査が必要です。ベンダーが「リージョナルホスティング」と保証しても、基盤となるプラットフォームが本質的に共有されているかどうかは別問題です。どこで共有が発生し、何が露出しているのかを理解することが、そのギャップを埋める第一歩となります。

マルチテナンシーが実際に共有しているもの

クラウドベンダーは、エンタープライズのリスク部門が使うような言葉でマルチテナンシーを説明することはほとんどありません。顧客向けの説明は、弾力性やコスト効率、迅速なプロビジョニングが中心です。しかし実際のアーキテクチャでは、1セットのデータベース、アプリケーションランタイム、オペレーティングシステムがすべての顧客に同時にサービスを提供し、テナントの境界は完全にソフトウェアで制御されています。

マルチテナント設計の効率性ロジック

マルチテナントアーキテクチャは、プロバイダーにとって本当に効率的だからこそ存在します。1つのインフラで多くの顧客をカバーでき、運用コストを分散し、メンテナンスを簡素化し、各アカウントごとに専用リソースをプロビジョニングせずに迅速なスケーリングが可能です。これはベンダーにとって合理的な商業判断です。しかし、その効率性ロジックが、規制データを扱う組織のリスクプロファイルに合致するかどうかは別問題であり、ベンダーの価格モデルが効率性に依存しているからといって両者を混同すべきではありません。

リージョナル展開で変わること・変わらないこと

リージョナルホスティングオプションは、通常、顧客データの保存場所（データレジデンシー）を変更するだけです。基盤となるプラットフォームアーキテクチャ自体は通常変わりません。グローバルなマルチテナント製品のリージョン展開でも、共有データベース、共有アプリケーションランタイム、共有管理コンソールがプロバイダー全体で利用され続けることが一般的です。リージョナルラベルは地理的な問題には答えますが、実際にリスクを決定する「共有」の問題には答えていません。

共有インフラが共有リスクとなる仕組み

共有インフラの現実的な結果として、セキュリティインシデントは契約上想定される顧客の境界を尊重しません。一度攻撃者や設定ミスが共有レイヤーに到達すると、リスクはアカウント構造ではなくアーキテクチャに従って広がります。

被害範囲：1つの脆弱性が多くの顧客に波及

シングルテナント環境では、ある顧客インスタンスの脆弱性は、そのインスタンス内に限定されます。しかしマルチテナント環境では、共有データベース層や共有ランタイム、共有ID・アクセス管理層の脆弱性が、悪用された瞬間にその層に依存するすべてのテナントを危険にさらす可能性があります。実際に公表されたマルチテナント型クラウドのセキュリティインシデントでも、共有インフラ層の欠陥が最初に影響を受けたアカウントを超えてクロステナントで波及する事例が繰り返し確認されています。規制対象組織にとっては、「自社データが侵害される可能性」から「プラットフォーム全体が侵害される可能性、それが自社にどんな意味を持つか」というリスク評価に変わります。

管理・サポートアクセスという隠れた攻撃対象領域

共有インフラには、通常、共有管理ツールが付随します。共有管理ツールがあるということは、ベンダーのスタッフやベンダーの代理で動作する自動化システムなど、複数顧客環境にまたがる運用アクセス権を持つ人員が存在することを意味します。このアクセス権は、顧客自身の設定に焦点を当てたセキュリティレビューではほとんど可視化されません。なぜなら、その権限はベンダー側の境界内に存在するからです。マルチテナントベンダーを評価する際は、自社データの保護方法だけでなく、「誰が」「何が」そのデータが存在するレイヤーへ恒常的にアクセスできるのかも確認すべきです。

エンタープライズリスク評価でテナンシーモデルを考慮すべき理由

ロケーションとテナンシーを同じ問題として扱うと、リスク・コンプライアンス部門はデータセンターの所在国を確認した時点でベンダーレビューを終えてしまい、そのデータセンターが1社専用なのか数千社で共有されているのかを問わなくなります。しかし、この2つの問いにはまったく異なる証拠が必要です。ロケーションはホスティング契約で説明できますが、テナンシーはデータベース、ファイルシステム、ランタイム、OSが専用か共有か、管理・サポートアクセスが1社限定か全体にまたがるかを示すアーキテクチャ文書で証明されます。暗号化やアクセス制御と並んでテナンシーモデルをベンダーリスク評価に組み込むことで、ロケーションだけのレビューでは見落とされがちなギャップを埋めることができます。

データコントロールプレーンが「運命共同体」リスクを排除する仕組み

「運命共同体」リスクを避けるために、組織が自前でインフラを構築・運用する必要はありません。必要なのは、テナント分離がソフトウェア上の境界ではなくアーキテクチャ上の特性として組み込まれており、どのチャネルを経由しても機密データのガバナンスが一貫して強制されるプラットフォームを選ぶことです。これこそがデータコントロールプレーンの役割です。データが通過するすべてのチャネル（メール、ファイル共有、API、AIエージェントなど）を横断するガバナンスレイヤーを構築し、誰がどの条件下で機密データにアクセス・送信・共有・移動できるかを、組織自身が境界を管理するインフラ上で強制します。

Kiteworksは設計段階からシングルテナントアーキテクチャを採用しており、顧客間でデータベース、ファイルシステム、アプリケーションランタイム、OSを一切共有しません。組織は自社インフラ上（完全オンプレミス、自社クラウドテナンシー内のセルフホスト、または専用ホスティングインスタンス）で導入でき、管理・サポートアクセスもその顧客専用に限定され、グローバルな共有プラットフォームにまたがることはありません。この分離された基盤の上に、データ認識型ゼロトラスト制御がすべての送信・共有・アクセス操作をガバナンスし、すべての操作は改ざん不可能かつ制限のない監査ログとしてSIEMツールに直接連携されます。これにより、セキュリティ・コンプライアンス部門はベンダーの分離保証ではなく、実際の強制証拠を得ることができます。テナンシー自体が組織が自ら行使するコントロールとなり、ベンダーのコスト構造から受け継ぐリスクではなくなります。

自社の規制環境でシングルテナントアーキテクチャがどのような意味を持つか評価したい組織は、get back in CTRL ― 専用データコントロールプレーンが現在利用中のプラットフォームとどう違うかをご確認ください。