認証は呼び出し元について何かを証明します。承認により、呼び出し元がこの顧客のレポートを取得できるか、この操作を実行できるかが決まります。有効な API 認証情報がテナント境界を越えるショートカットになってはなりません。エンドポイントまたはバックグラウンド ジョブを追加する前に、権限マトリックスから始めます。
リクエストされたオブジェクトに ID をバインドします
サポートされている認証メカニズムを通じて呼び出し元の ID を解決し、その承認されたテナントと操作スコープを信頼されたサーバー側の状態から取得します。 URL またはリクエスト本文内のテナント ID を、許可の証明ではなく、リクエストされたターゲットとして扱います。レポート、エクスポート ジョブ、ダウンロード アーティファクトを呼び出し元の実際の許可と照合して確認します。
OWASP の認証チートシート 最小限の権限、デフォルトで拒否、リクエストごとに権限の検証を推奨します。これらの原則を非同期ワーカーに適用し、リンクと最初の API 呼び出しをダウンロードします。正当に作成されたエクスポートは、そのオブジェクト ID が推測されやすいため、後で別のテナントによってダウンロードできてはなりません。
読み取りアクセスを変更権限から分離する
レポート閲覧者は、承認されたドメイン データを取得できますが、 DNS書き込み許可を自動的に取得するべきではありません。 DNSオペレーターは、保存されたレポート履歴にアクセスする必要がない場合があります。監査人は、生のメッセージではなく、制限付きの証拠ビューを必要とする場合があります。各役割で許可されているオブジェクトと操作を文書化し、通常のログやエクスポート以外で機密管理を行います。
テナント A のレポートを読み取るためだけに自動化資格情報が承認されているとします。テナント A のDNS変更とテナント B のレポート読み取りは両方とも、認証が有効であっても、その許可に基づいて拒否する必要があります。明示的に承認された別のオペレーター許可には、独自のオブジェクトと操作のチェックが必要になります。これらは想定される予想される決定であり、実装された権限マトリックスやEmailAuthロールの説明ではありません。
陰性検査を受け入れの一部にする
許可された同一テナントのレポート読み取りを実行し、要求されたテナントのみを変更します。欠落している読み取りスコープと取り消されたプリンシパルを使用して繰り返します。また、オブジェクト レベルの ID、保存されたエクスポート、キューに入れられたジョブ、変更されたグループ メンバーシップについての実際のテストも計画します。別の顧客のアカウントを調査するのではなく、承認された合成テナントと無害なデータを使用します。
認可されたテストごとに、実際の決定と開示された応答フィールドを記録します。拒否されたリクエストでは、メタデータ、カウント、ダウンロード リンク、キャッシュされた結果を通じてプライベート オブジェクトの詳細が漏洩してはなりません。正しい適用と全員を拒否するエンドポイントを区別するために、有効なスコープ付き読み取りを含めます。ここでは、トークン システム、OAuth フロー、実稼働認証テストは提供または実行されません。
補助金をライフサイクル全体にわたって運用する
付与所有者、承認された目的、テナントの範囲、有効期限またはレビューのトリガー、および取り消しパスを記録します。承認されたシークレット システムに認証情報を保存し、制御された手順に従ってローテーションし、シークレット自体を記録することなく使用を監査します。遅れた作業を実行するときに権限を再確認します。キューに入れられたタスクは、取り消し後にアクセス許可を無期限に保持すべきではありません。
基礎となるデータの機密性を確認します。 RFC 9990 説明します 集計レポート コンテンツとセキュリティに関する考慮事項。レポートのメタデータは依然として制御された開示に値します。承認が失敗した場合は、別のテナントのプライベート オブジェクトを確認せずに、適切な拒否を返します。テナント間データが発見された場合は、漏洩を阻止し、組織のインシデント手順を発動します。単に UI を変更して、API が安全であると想定しないでください。
OWASP のマルチテナント ガイダンス、特に非同期作業、キャッシュ/セッション、およびファイル ストレージ セクションでは、最初のリクエストを超えたスコープの強制と、遅延実行中の時間に敏感なアクセス許可の再チェックがサポートされています。