マルチテナントSaaSアプリにおけるテナント分離のテスト方法

マルチテナントSaaSアプリケーションには、シングルテナントアプリにはないテスト上の課題があります。すべての機能がすべてのテナントに対して正しく動作し、テナント間のデータ分離が完全でなければなりません。
テナント間アクセスのバグにより、あるユーザーのレコードが別のユーザーに露出する可能性があります。アクセス拒否と正規のオーナーによるアクセスの両方をテストし、一括失敗がセキュリティコントロールとして誤認されないようにしてください。
テナントフィルターや認可チェックが欠落していても、開発データにテナントが1つしか存在しない場合は発見されないことがあります。テナントAとテナントBに別々のアカウントとシードデータを使用してください。実際の顧客データをこのテストに使用しないでください。
再現可能な2テナントテスト
1. テナントAとテナントBに異なるユーザーとレコードをシードします。テナントごとに1件のレコードIDを保存します。拒否チェックを実行する前に、各オーナーが自身のレコードを読み取れることを確認します。
2. AユーザーとしてサインインしてUIとAPIからBのレコードにアクセスを試みます。パスおよびクエリパラメータでBのIDを試し、検索・レポート・エクスポートの結果も確認します。直接アクセスには403または404が返り、AのどのレスポンスにもBのレコードが含まれないことを期待します。
3. Aのテナント管理者として、Bのレコードの更新・削除およびBの設定変更を試みます。拒否されることを確認し、Bのデータが変更されていないことを検証します。Bの正規の管理者で同じ操作を繰り返し、オーナーに対しては操作が正常に機能することを確認します。
4. 別々のセッションでテナント固有の機能フラグとブランディングを比較します。ノイジーネイバーのリスクが重要な場合は、Aに制御された負荷をかけながらBのp95レイテンシを自社ベースラインと比較します。テスト前にプロジェクト固有のしきい値を設定してください。
チェックの実行とレビュー
AIテストエージェントを含むブラウザまたはHTTPテストを使用して、安全なステージング環境でこれらのシナリオを実行します。実際のリクエスト・アサーション・レスポンスを確認してください。汎用的な「緑」のセキュリティ結果は、すべてのテナント境界がテストされたことを証明しません。
各パスについて、アクター・テナント・対象リソース・期待されるステータス・実際のステータス・外部データが出現したかどうかを記録します。修正後は失敗したケースをリグレッションチェックに追加してください。データベースレベルのコントロールはUIおよびAPIテストとは別にレビューしてください。
TestSpriteを無料で試す →