SaaSのテナント分離とは、顧客が自組織に許された記録と操作だけにアクセスできることです。画面のテナント選択だけでは足りません。要求、バックグラウンド処理、キャッシュ、ファイル取得が基盤へ届いても、境界を保つ必要があります。
別組織、通常ユーザーの役割、意図した越境試行でテナント分離をテストします。同じアクセスルールで参照、更新、ファイル、キャッシュ応答、背景処理を検証します。機密性や商業上の重要性がある顧客記録を受け入れる前に、強制されるバックエンド境界の証拠を求めてください。
各組織が自分の発注書を見る顧客ポータルを考えます。一覧は正しくても、ダウンロードした出力に別組織の行が含まれる場合があります。ログインと通常画面が予定通りでも、これは分離の失敗です。
本記事は責任者が検証と是正の範囲を定める助けとなります。一つのデータベース配置が安全を保証したり、チェックリストが完全なアプリ評価に代わったりするという主張ではありません。
保存方式を選ぶ前にSaaSのテナント分離を定義する
製品内でテナントが何を意味するかを特定します。顧客組織、法人、ワークスペースかもしれません。参加、離脱、切り替えと、越境できるサポート役割を記録します。ルールの曖昧さはテストの曖昧さになります。
OWASPのマルチテナントセキュリティガイド はデータベース、キャッシュ、保存、計算境界の分離を説明します。クライアントが送るテナント選択とサーバーが検証する権限も区別しています。実際の要求経路を評価するときに使ってください。
データの所有を明示します。共有商品一覧は複数顧客へ意図的に見せる一方、注文メモはテナント所有かもしれません。漏えいを見つけ、意図した共有を欠陥と扱わないために、テストは違いを知る必要があります。
管理例外を図にします。サポート担当が顧客記録を調べられるなら、誰がアクセスを与え、範囲を限定し、利用を記録するか説明します。強力なサポート経路は通常モデルの外へ隠さず、意図した機能としてテストすべきです。
要求を通してテナント情報を追う
認証済みユーザーから始め、現在の所属またはサービス権限を検証します。選んだテナントを業務ロジックとデータアクセスまで追います。ヘッダー、経路値、要求本文の変更で別組織の権限にすり替えられないことを確認します。
ランダムに見える識別子は推測を難しくしても、権限を成立させません。OWASPの認可ガイド は要求ごとのアクセス確認を勧めます。推測できるかに頼らず、別テナントから正当に取得した識別子で試験します。
| 境界 | 試みる変更の例 | 受け入れる結果 |
|---|---|---|
| 記録検索 | 別テナントの既知注文番号を要求 | 記録を開示せず拒否 |
| 更新 | 有効な入力へ別テナントの識別子を入れる | 未認可の変更がない |
| テナント切り替え | 所属しない組織を選ぶ | サーバーが範囲を拒否 |
| 一括エンドポイント | 複数テナントの識別子を混ぜる | 一部開示もない明確な拒否 |
| サポート操作 | 通常役割で高権限経路を使う | 拒否と役立つ調査証拠 |
検索、出力、代替APIでも同じ考え方を繰り返します。最初の詳細画面が正しくても、一括レポート、モバイルAPI、古い互換経路が同じ境界を強制する証明にはなりません。
実際の制御でデータベース方式を比較する
個別データベース、スキーマ、共有テーブルは異なる運用上の得失を生みます。どれも認証情報、役割、クエリ、管理経路の検証を省けません。提案は境界の強制場所と、コードがフィルターを省いた場合の動作を特定すべきです。
| 方式 | 調べる境界 | 含める運用作業 |
|---|---|---|
| 個別データベース | 接続と認証情報の権限 | 作成、移行、バックアップ分離 |
| 個別スキーマ | データベース役割と名前空間選択 | 権限付与、移行規律、管理アクセス |
| 共有テーブル | テナント所有と強制アクセス方針 | クエリ網羅、要求役割、否定テスト |
| 混合 | データ分類ごとの文書ルール | 明確な経路と一貫した事故調査 |
全欠陥の既定修正として個別データベースへ移行しないでください。限定的な認可不具合には対象修復があるかもしれません。一方、出力、ジョブ、支援ツールが無制限アクセスのままなら、一つのコントローラーのフィルター追加では不十分です。
本番要求が実際に使う役割をテストする
PostgreSQLの行セキュリティ文書 は、特権役割とテーブル所有などの重要例外を説明します。行方針に依存するなら、実際の制限された要求役割で検証します。管理者としてのテストは、通常アプリの境界を表しません。
デプロイと移行のアカウントを一覧に含めます。正当に広いアクセスを必要とするかもしれませんが、顧客要求の日常的な身元にすべきではありません。実行時の権限取得と、導入後の確認方法を文書化します。
キャッシュ、ファイル、派生出力を確認する
キャッシュキーと結果の範囲を調べます。共通経路や便利なフィルターだけを理由に、ある組織の項目が別組織の答えになってはいけません。第一テナントがキャッシュを埋めた後、第二テナントで試します。
ファイルには固有の検収証拠が必要です。アップロード所有、プレビュー、取得、生成報告を確認します。画面が正しく拒否しても、添付URLが別経路で取得できる場合があります。古いリンクや以前発行したリンクも範囲に含めます。
検索索引、推薦、分析出力などの派生データを調べます。挿入時だけでなく取得時にテナント制限を強制するか確立します。元記録APIが守られていても、要約で情報が越境することがあります。
別組織に属する管理テストデータを使います。実顧客文書を評価へコピーせず、混入が分かる十分な特徴を各組に与えます。不意のキャッシュヒットや混合出力を診断しやすくします。
背景ジョブと所属変更を試す
背景処理は検証済みテナント情報をキューから操作まで運ぶべきです。遅延、再試行、別ワーカーによる処理を確認します。Web要求の有効範囲は、後のジョブが保つ証拠ではありません。
所属変更をテストします。組織から削除されたユーザーが、合意方針に反してキャッシュセッション、保存出力、待機操作から通常アクセスを保ってはいけません。取り消し前に受け付けた仕事の動作を定義します。
サポートの代理操作とテナント削除も意図的に網羅します。高権限セッションからの退出、残存ファイル、ジョブ、参照の処理を説明します。削除方針は製品の保存義務に依存します。評価は方針を創作せず、選んだものを検証すべきです。
現チームが経路を説明できないなら、当社のソフトウェアプロジェクト引き継ぎガイド が関連します。デプロイ、データアクセス、運用文書の管理回復も、保守できる境界作りの一部になり得ます。
有用な検証報告を指定する
主体、テナント、操作、観測効果を示す発見を求めます。機密値を管理して要求と接続先証拠を含めます。アクセス制御というラベルだけで再現経路がない発見は、修復と再試験が困難です。
OWASP ASVS は広いアプリセキュリティ要件を支えられます。テナント固有の検収表も併せて残し、試した組織、役割、資源種類をレビュー担当が確認できるようにします。
確定した欠陥と未試験経路を分けます。私的保存サービスや管理出力を調べられなかったら記載します。全テナントデータは分離されるという根拠のない結論より、正直な範囲制約が有用です。
是正後、元の失敗ケースと周辺の正当なケースを繰り返します。全ダウンロードを止める修復は漏えいを止めても製品を壊すことがあります。検収には未認可アクセスの拒否と、許可された仕事の継続の両方が必要です。
製品の実際の境界に予算を付ける
ページ数だけでなく資源種類、役割、運用経路で評価範囲を定めます。テナント情報を露出できる外部ファイル、キャッシュ、背景ジョブ、支援アクセスも含めます。小さなポータルでも画面より広い境界があるかもしれません。
| 作業項目 | 成果物 | 明確にする前提 |
|---|---|---|
| 境界整理 | テナントと役割モデル | 構成知識の取得可否 |
| 検証 | 許可・拒否アクセスの証拠 | 管理アカウントと環境 |
| 是正 | 修正した強制制御と回帰確認 | 構造変更の必要性 |
| 引き継ぎ | 繰り返せるテストと除外事項 | 顧客受け入れ後の責任 |
評価と是正を分けたGBP提案を求めます。ログイン試験や自動スキャンだけの万能保証は避けます。価値ある成果物は顧客が頼るアクセス境界の証拠です。
当社のアプリケーションセキュリティサービス が範囲相談の起点です。製品のテナントモデルと顧客受け入れ判断をお知らせください 。検証、限定修復、次の顧客アカウントを開く前の証拠を相談できます。
よくある質問
SaaSのテナント分離とは何ですか? 顧客組織のデータと許された操作を強制的に分けることです。製品の管理例外を含め、要求、保存、キャッシュ、ファイル、背景処理で境界が保たれる必要があります。
個別データベースで分離を保証できますか? いいえ。認証情報、経路、支援ツール、出力、バックアップが越境することがあります。設計の一部にはなりますが、実際のアクセス経路はテストが必要です。
ランダムな記録識別子で十分ですか? いいえ。簡単な列挙を減らしても権限確認ではありません。別の管理テナントの実識別子で試し、サーバーの拒否を確認します。
拒否だけでなく許可アクセスもテストすべきですか? はい。全要求を拒否する是正は製品の破損を隠すことがあります。通常ユーザーの予定操作を保ち、越境試行を拒否することを検証します。
キャッシュにはなぜ別テストが必要ですか? 元のデータアクセス経路を繰り返さずデータを返せるからです。一テナントで埋め、別テナントで結果を確認します。便利なキーを共有するだけでなく、意図した権限を範囲が保持することを確認します。
サポートアクセスはどう動くべきですか? 取得できる人、範囲、期間、記録方法を定義します。高権限情報への入り方、使用、退出をテストします。例外を明示しレビューできる設計にすべきです。
行レベルセキュリティを使う場合は? 実際の要求役割で試し、通常コントローラーを迂回する操作も含めます。特権役割や別経路は異なる場合があります。行方針は検証する制御であり、評価省略の理由ではありません。
見積もり前に業者へ何を渡しますか? テナント、役割、資源種類、外部保存、背景操作の説明です。利用できるテスト環境と管理アカウント、評価が支えるべき判断を特定します。