テスト環境では、実稼働 ID に対して不必要な権限を付与せずに変更を検証できるようにする必要があります。送信者登録内の個別のアプリケーション環境では、 DNS 、署名、リレー、受信者のアクセス許可を個別に確認します。ステージングと呼ばれるラベルは、実稼働資格情報または同じ無制限の署名キーを使用する場合、分離制御ではありません。
環境境界を定義する
アプリケーションの目的、環境、所有者、重要度、可視の From ドメイン、エンベロープ ドメイン、 DKIM 署名 ID、エンドポイント、承認された受信者、最後のテストと承認の参照。プラットフォームが許可する場合は、個別のサービス ID と資格情報ストアを使用します。プロダクション シークレットをフィクスチャやドキュメントのサンプルにコピーしないでください。
専用のテスト サブドメインは、名前付けとポリシーを分離するのに役立ちますが、自動的にセキュリティ境界になるわけではありません。 DMARC リラックスした アライメント プロトコルの適用可能な検出および調整ルールに応じて、組織ドメイン レベルでドメインを関連付けることができます。左端のラベルが異なるとメールが無関係になると仮定するのではなく、実際の配置動作を確認してください。 RFC 9989.
権限を命名から分離する
各署名サービス、 DNS委任、リレー ルールで何ができるかを調べます。運用ドメイン用に署名を許可されたテスト サービスは、引き続き運用環境に合わせたメールを生成できます。専用ドメインを持つテスト送信者は、受信者の制御が制限されていない場合、実際の顧客に到達できる可能性があります。認証と受信者の封じ込めはさまざまな問題を解決します。
のために SPF、実際のエンベロープ ID とその承認された送信インフラストラクチャを調べます。 DKIMについては、調べてください。 セレクタ 表示アドレスだけではなく、所有権と署名ドメインも含めてください。 RFC 7208 そして RFC 6376。共有権限を、目に見えない利便性ではなく、影響、所有者、有効期限を伴う明示的な例外として扱います。
2 つのステージング障害を分離する
ステージング サービスには専用のテスト From ドメインがあり、その署名資格情報は運用環境用にも署名できるとします。 2 番目のサービスには署名権限が制限されていますが、制限のない実際の受信者に送信できます。 1 つ目は署名許可のレビューが必要です。 2 つ目は受信者の封じ込めが必要です。テスト ドメイン ラベルでは、どちらの権限のギャップも解決できません。
これらは、仮想的なアクセス許可の結果であり、実行されたガードやプラットフォームの監査ではありません。承認された ID と受信者を記録し、承認された構成証拠と制限付きテストを通じて適用を検証します。スプレッドシートは不一致を明らかにすることはできますが、メッセージを停止することはできません。コントロールが利用できない場合は、名前だけからの分離を宣言するのではなく、明示的な保留または狭義に承認された代替案を保持します。
非表示の状態ではなく、レビュー済みの構成を促進する
各環境の意図した構成と正確な差分を保存します。 NISTのベースラインと変更管理の原則を使用して、何が促進されているかを確認します。 SP800-128。パブリックDNS名、セレクター、証明書 ID など、環境間で同一にすることができない依存関係を記録します。
安全な環境で候補者をテストし、本番展開に必要な承認を取得します。ステージング テストに合格しても、運用環境のDNS 、アクセス許可、またはルートの動作が証明されるわけではありません。承認された受信者による運用と、実装後の制限付きテストを検証します。テスト中に環境が変化した場合は、古い結果を現在の承認として扱うのではなく、ベースラインを再確立します。
証拠とアクセスを明確に保つ
環境ラベルとタイムスタンプを含む個別のテスト証拠を保持します。必要がない場合は実際の受信者データを編集し、実際の顧客メッセージをテスト フィクスチャとして使用することを避けます。運用DNS編集、署名 ID の割り当て、受信者制御の変更を担当オペレーターに制限します。
共有依存関係を定期的に確認します。テストと運用環境でリレー アカウントまたはプロバイダー アカウントを共有する必要がある場合は、ID と受信者の使用を制限する実際の制御を文書化します。本番環境のロールバックは、テストのクリーンアップとは別に定義します。テスト セレクターの削除は、それに依存する運用ストリームがないことを確認した後でのみ安全です。名前だけではその依存関係を確立できません。