SaaSで他社のデータを見せないには？企業ごとの分け方

一人が複数社を担当すると、何が変わるか

説明用の例として、代理店が複数の顧客企業の申込みを管理するSaaSを考えます。代理店の担当者はA社とB社を支援しますが、C社とは関係がありません。この人を単に「代理店管理者」にすると、どの会社まで見てよいかを表現できません。個人のアカウントと、企業ごとの所属・役割を分ける必要があります。

サービス内で情報や設定を区切る単位を、テナントと呼びます。必ず法人一社と同じとは限らず、部門を独立させる場合もあります。誰がメンバーを招待し、誰が契約を管理し、誰がデータを見るかを先に描きます。請求を本社へまとめることと、全支店の情報を本社担当者に見せることも、別の判断です。

共同作業がある場合は、何でも企業ごとに閉じればよいとも限りません。発注側と受注側が同じ申請を見るサービスなら、共有する情報と、各社だけの社内メモを分けます。共有関係が終わったときに、どちらが何を残せるかも考えます。代理店の例でも、ある会社への支援を終了しても、別会社の仕事は続きます。一人のアカウントを丸ごと消す方法で済ませず、どの関係を解除するかを表現できる設計が必要です。

全社で同じ仕組みを使うか、企業ごとに専用化するか

AWSの資料では、資源を共有するPool、専用化するSilo、それらを組み合わせるBridgeが紹介されています。多くの顧客へ共通機能を提供するなら、共有構成は一括して更新しやすい選択肢です。一方、顧客ごとに独立した保管や復旧を求められるなら、専用化の価値を検討できます。

専用なら自動的に安全、共有なら必ず安い、とは言えません。専用環境が増えれば更新や監視の仕事も増え、共有では一社だけ復元する手順が複雑になり得ます。顧客が望む条件を開発会社へ伝え、「どこを共有し、どこを分けるか」を説明してもらいましょう。方式名より、運営を続けられるかが比較の中心です。

営業から「専用環境が必要」と言われたら、顧客が何を分けたいのかを確認します。保存するデータなのか、処理の負荷なのか、更新する時刻なのかで、専用化する場所は変わります。すべてを個別にする前に、その条件を満たす構成を比較します。顧客ごとの個別対応を増やすと、契約と実装の組み合わせも増えるため、標準で提供する条件と個別相談の条件を整理しておくと、後の運用を見通しやすくなります。

表が収まらない場合は横にスクロールできます。

参考：Amazon Web Services：SaaS Tenant Isolation Strategies: Silo isolation ／ Amazon Web Services：SaaS Tenant Isolation Strategies: Pool isolation ／ Amazon Web Services：SaaS Tenant Isolation Strategies: The bridge model

一覧が正しくても、添付ファイルから漏れることがある

画面の一覧でA社だけを表示していても、添付ファイルのURLを知っていれば誰でも開けるなら分離はできていません。検索結果、ダウンロード、集計ファイル、通知メールにも同じ考え方が必要です。企業IDを付けた保存先に置くことと、読む権限を確かめることは別の作業になります。

時間のかかる集計を後から実行する場合も、どの企業の誰の依頼かを引き継ぎます。待機中に担当を外された人へ、古い権限のまま結果を送ってよいかは判断が必要です。開発会社には、通常の画面だけでなく、ファイルと裏側の処理で企業をどう判別するかを尋ねると、確認すべき範囲が見えます。

複数社を切り替える画面では、利用者が今どの会社として操作しているかも重要です。切り替え前に開いていた書類や、入力途中の画面が残ると、別会社へ誤って登録する原因になります。会社名を表示するだけでなく、切り替え時に引き継ぐ入力と破棄する状態を決めます。企業間で情報を取得できない仕組みと、正規の利用者が操作を取り違えにくい画面は、別の角度から同じ情報の境界を支えます。

「分離機能を使っています」の、もう一歩先を聞く

データベース側で行ごとのアクセスを制限する方法もあります。PostgreSQLのRLSがその一つですが、強い管理権限には適用されない場合があります。公式資料では、スーパーユーザーとBYPASSRLSを持つロールは制御を迂回し、テーブル所有者も通常は対象外と説明されています。機能を有効にしただけでは、実際のアプリで効くかは分かりません。

発注側が設定の詳細を暗記する必要はありません。「本番の接続権限で、別企業の情報を要求しても取得・変更できないかを試す」と確認すれば、実際の検証につながります。閲覧だけでなく更新や削除、運営者の横断操作も対象です。横断操作が業務上必要なら、目的と範囲を限定し、誰が何をしたかを残します。

参考：PostgreSQL Global Development Group：PostgreSQL Documentation: Row Security Policies

一社の誤削除で、他社まで昨日に戻さない

説明用の例として、A社が誤って申込データを削除した場面を考えます。全社分のバックアップをそのまま本番へ戻すと、B社が今日追加した情報も失われるおそれがあります。一社だけ戻したいなら、別環境に復元し、関連するデータとファイルを取り出して照合するなど、選択した構成に合う手順が必要です。

復旧では、データが読めることに加え、現在の権限が保たれているかも確かめます。過去の状態から戻した結果、契約終了した代理店の所属まで復活しては困ります。出力、解約後の削除、個別復旧は、企業の境界を本当に扱えているかが分かる場面です。顧客へ約束する前に、どこまで実行できるかと費用を確認してください。

初期開発で決めることと、利用が増えてから決めること

最初から全顧客に専用環境を用意する必要はありません。ただし、複数企業の非公開情報を扱うなら、所属とデータの関係、越えてはいけない境界は初回から決めます。一社の大量集計が他社の通常操作を待たせる可能性もあるため、処理量の上限や混雑時の扱いは利用条件に応じて検討します。

将来の専用化を考える場合は、今すぐ全機能を作るより、データの持ち主と配置を追える状態を保つことが先です。提案を比べる際は、初回費用だけでなく、顧客の追加、更新、解約、復旧の作業も聞きます。予測した顧客数だけで構成を決めず、実際に求められた条件と維持できる体制から、段階的に広げましょう。

利用が増えたときは、全体の件数だけでなく、企業ごとの偏りを見ます。大半の顧客が小さな入力を行う一方、一社だけ大量の一覧出力を使うなら、単純な利用者数では負荷を説明できません。通常の操作を続けながら大きな処理を動かす試験を行い、待たされる相手がいないかを確かめます。処理を分ける、同時実行数を調整する、専用化するといった案を、利用の実態と追加費用から比較する材料になります。

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □個人・企業への所属・契約・請求の関係を説明できる。確認状況・メモ：
• □代理店や兼務者の閲覧範囲を決めた。確認状況・メモ：
• □共有する資源と企業ごとに分ける資源が分かる。確認状況・メモ：
• □ファイル・検索・通知も分離の確認に含めた。確認状況・メモ：
• □別企業の情報を取得・変更できない試験を依頼した。確認状況・メモ：
• □一社だけの出力・削除・復旧方法を確認した。確認状況・メモ：
• □顧客追加と定期更新に必要な運営の仕事を把握した。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• SaaS Tenant Isolation Strategies: Silo isolationAmazon Web Services
• SaaS Tenant Isolation Strategies: Pool isolationAmazon Web Services
• SaaS Tenant Isolation Strategies: The bridge modelAmazon Web Services
• PostgreSQL Documentation: Row Security PoliciesPostgreSQL Global Development Group