認証しても守れない？ ― SaaS開発で外せないテナント分離の設計

皆さんこんにちは、タカシです。今日は SaaS 開発の中でもかなり重い論点、テナント分離を扱います。実は、ちゃんとログインできて権限もあるのに、別会社のデータへ触れてしまう事故は設計次第で起こりえます。

そこが大事な誤解です。AWS も、認証や認可はセキュリティの一部であって、tenant isolation そのものではないと説明しています。今日はその違いと、経営者がどこまで統制すべきかを整理しましょう。

テナント分離の本質は、いま誰のデータに触ってよいのかを示す tenant context を、リクエストから最後まで落とさないことです。画面だけ守っても、SQL やキャッシュ、バッチ、ログで境界が抜ければ意味がありません。

その通りです。さらに Microsoft は、外部 ID を招待してリソースを分けても、それは resource isolation であって identity isolation ではないと説明しています。社内アカウント侵害が顧客向け SaaS に波及する余地が残るんです。

まさにそこです。テナント分離はデータモデルの話に見えますが、実態は誰がどう本番へ入るかまで含んだ統制設計です。技術と運用を別々に考えると、境界は一番弱いところから破れます。

Atlassian が分かりやすい例です。Jira と Confluence Cloud では tenant context service を使い、各顧客のデータ配置先や機能設定を tenant ID と結び付けて処理しています。誤った DB 接続への追加防波堤になると公式資料で説明しています。

しかも Atlassian は 2025 年末時点で 350,000 超の顧客を持ち、Jira Cloud は単一サイトで 100,000 ユーザーまで対応すると公表しています。この規模で shared を回すには、境界を属人運用にできません。

さらに面白いのは、Atlassian が Isolated Cloud も準備している点です。標準はマルチテナントで伸ばしつつ、高統制の顧客には dedicated virtual private cloud を用意する。一部だけ isolated にする混在運用も想定しています。

一番多いのは、認証と RBAC を入れた時点で安心することです。CSV エクスポート、非同期ジョブ、サポート用管理画面、共有キャッシュは tenant context が抜けやすい。OWASP も cross-tenant vulnerability の典型原因として設計漏れを挙げています。

もう一つは、顧客ごとに例外構成を増やしすぎることです。Azure も、個別カスタマイズや専用インフラの乱立は運用を複雑にし、境界の一貫性を壊すと示しています。例外が多いほど、人の判断に依存します。

その通りです。shared と dedicated の切り替え条件を決めず、営業案件ごとに場当たり対応すると危険です。専用鍵、個別バックアップ、地理要件、大口契約など、分離を上げる条件は先に経営ルールにしておくべきです。

加えて、どの条件で shared から dedicated へ上げるのか、営業条件まで含めて文章にしてください。テナント分離はセキュリティだけでなく、粗利、受注力、運用再現性を守る SaaS の経営基盤です。