判断の出発点
テナント分離は最後に識別子を足す作業ではなく、設計して検証する境界です。各企業の所有物、境界を越えられる人、個別復旧の必要性を定めます。Microsoftの設計資料にも共有型と分離型がありますが、選択は運用要件次第です。
具体例で考える
異なる修理会社が使うSaaSなら、A社の技術者がIDを推測してB社の依頼を読めてはいけません。一覧、検索、添付、出力、背景処理、サポート操作を別々に試します。
日常業務の中で境界を定義する
会社ごとの記録と意図して共有する記録を分けます。共通の商品一覧でも価格、連絡先、作業依頼は非公開かもしれません。二社に所属する人が会社を切り替えたら、検索、ファイル取得、出力まで文脈を切り替えます。表示名だけで境界を作らず、サーバーが操作への所属を確認します。特別なサポート経路は許可、期間、利用記録を別途定めます。
間接的な漏えい経路を試す
似たデータの架空企業を二つ作り、別会社のIDを詳細、集計、添付、背景処理で使います。一方でキャッシュを作り、他方で似た照会をします。待機中の仕事があるまま所属を解除し、中止か明示的に許可されたサービスIDで継続かを決めます。ボタンが隠れたかではなく、実行時の正当な権限を確認します。新しい検索や連携の追加時にも繰り返します。
復旧と削除も分離の要件にする
一社の誤削除を戻す際、他社の仕事を巻き戻さない方法を確認します。個別DBでも添付、ID、連携先の照合は必要です。共有保存の選択的な復旧には手順と安全な環境を用意し、約束前に架空データで試します。派生索引やバックアップの保持手順を含め、出力と削除の範囲も決めます。通常アクセス、支援、復旧が説明できる同じ境界に従って初めて設計が運用に結び付きます。 復元後の識別子が添付や接続先の記録と正しく対応していることも確認してください。
選択肢とその負担
- 共有テーブルは運用をまとめやすい反面、一貫した所属確認が必要です。個別データベースは運用境界を作れますが、移行、接続、バックアップの管理が増えます。併用するならサポートも両方を理解します。
見落としやすい点
ブラウザが送る企業IDだけを信頼しないことです。所属を確かめ、キャッシュとファイル権限にも企業を反映します。待機中の処理がある状態でアクセス権を失うケースも試します。
依頼前に確認すること
一社だけを復元、出力できるか。サポートの閲覧は誰が承認し記録するか。データ保存図だけで済ませず、SaaS設計で決めてください。