プロフェッショナル サービス会社は、スタッフが別のメール テナントを使用している間に、ポータル、請求ツール、プロジェクト システムを通じてクライアント メッセージを送信できます。パートナーは、会社のドメインで送信されることを認識せずに、新しいツールを承認する場合があります。 ID を付与する前にサービス固有の委任レコードを作成し、実装後も指名されたビジネス所有者を保持します。
顧客対応の義務から始める
ポータルのドキュメント通知、請求書通知、プロジェクトの更新を個別にマップします。責任ある所有者として、クライアント プラットフォームのリード、財務システムのリード、および実践運用のリードを割り当てます。プロバイダーのテナント、From ドメインとエンベロープ ドメイン、署名セレクター、対象となるクライアントの人数、およびアクセスを取り消す権限のあるユーザーを記録します。中央の IT 部門がすでにツールを発見していると仮定するのではなく、実践に特化したツールを組み込みます。
架空の顧客、無害な文書が利用可能な通知、拘束力のない請求書の例を使用します。共有されるテスト証拠には、特権的なアドバイス、機密事項、料金残高、または銀行の指示を含めないでください。技術レビュー担当者には、基礎となるクライアントエンゲージメントへのアクセスではなく、メッセージ変換を再現するのに十分なコンテンツが必要です。
委任された ID のスコープを設定する
サービスを正確に表す、サポートされる範囲の狭い ID を選択してください。専用のサブドメインはインベントリと運用の分離を改善できますが、 DNS権限、署名アクセス、適用可能なセキュリティの分離を保証するものではありません。 DMARC 政策はまだ見直す必要がある。プロバイダーが便利なデフォルトを提供しているという理由だけで、企業に送信権を広範囲に付与することは避けてください。
架空のルート マップでは、billing.firm.test が From に表示され、billing-vendor.test が署名します。署名が検証されたと仮定しても、仮想ドメインは厳密には失敗します。 DKIM アライメント;ローカル署名テストは実行されませんでした。財務システムの所有者は、正しいテナントと対象となる作成者 ID を確立し、文書化されたカスタム ドメイン サポートまたは透過的にベンダー発信のメッセージ設計を確認する必要があります。ポータル テストでは請求は検証されません。
クライアントジャーニーと境界をテストする
制御されたテスト クライアント アカウントを通じて通知をトリガーし、受信したメッセージを保持します。表示された ID、応答処理、認証結果を確認します。別のクライアント ワークスペースのユーザーが、通知で未承認のドメインを使用したり、最初のクライアントのドキュメントにアクセスしたりできないことを別途確認してください。これらの申請テストは必要な受付作業となります。この仮説上の ID 比較では、これらのアプリケーション チェックはカバーされていません。ここではクロスクライアントテストは実行されませんでした。
調整されたメッセージは、法的アドバイスが承認されていること、請求書が正しいこと、または変更された銀行詳細に従う必要があることを証明するものではありません。エンゲージメントの承認、ドキュメントへのアクセス、支払いの検証を独立させます。プロバイダーが正しく署名されたメッセージを送信できるからといって、クライアントの同意した通信制限を放棄しないでください。
関係をきれいに終わらせる
契約終了時または実際の移行時には、在庫保留通知が送信され、許可されたレコードのみがエクスポートされ、正確な送信委任が取り消されます。誰が引き続き返信を受信するのか、誰が集計レポート データを保持するのかを確認します。放棄された資格情報を無期限にアクティブなままにしておくのではなく、偶発的な中断に備えて日付付きの回復計画を使用してください。職業上の機密保持、特権、契約上の通知および保持の要件には、資格のある審査が必要です。この記事は、認証がそれらを満足させるという法的な判断や保証を提供するものではありません。
架空の路線図
次の明示的な ID は入力例であり、実際の顧客の構成ではありません。これらのドメインと責任ある役割は仮説的なものであり、顧客の承認や提供された署名付きメッセージではありません。暗号化テストや配信は実行されませんでした。
- クライアント ポータル: クライアント プラットフォームのリード。 portal.firm.test から;エンベロープとDKIM署名者 portal.firm.test。
- 請求ツール: 財務システムの責任者。 billing.firm.test より;エンベロープとDKIM署名者 billing-vendor.test。
- プロジェクトコミュニケーション: 実践運営のリーダー。プロジェクトから.firm.test;エンベロープとDKIM署名者 project.firm.test。
委任とドキュメント アクセスを個別に解決する
請求送信者が修正されたが、通知リンクによって別のテスト クライアントのドキュメントが開かれたとします。アプリケーションのアクセス境界が失敗しても、電子メール ID タスクはその範囲指定されたチェックに合格する可能性があります。承認された制限内でインシデントの証拠を保存し、影響を受けるワークフローを保留し、クライアント プラットフォームの所有者に調査を割り当てます。有効な署名付き通知を、リンクされた資料を開示する許可と同一視しないでください。これらは仮説上の状況であり、観察されたクライアントのエクスポージャではありません。
OWASP のマルチテナント ガイダンスのセクション 1、3、および 6 では、トラステッド コンテキスト、オブジェクト認可、およびファイル分離がサポートされています。 RFC 9989セクション 4.4、5.3.5、および 5.4 ビジネス コンテンツの信頼からアラインメントとメッセージ処理を分離します。他の調整された認証は、完全な判定に影響を与える可能性があります。 p=reject 導入には、セクション 7.4 および 8 に基づく有効なDKIMが必要です。 SPF 一人で。