分離中 DKIM メール ストリームによるキーにより、ローテーション、インシデントの封じ込め、トラブルシューティングが容易になります。自動的に個別のドメイン レピュテーションを作成したり、キーをメッセージのカテゴリに限定したりすることはありません。各署名者が受け取る権限と、それを使用する実際のサービスを中心に設計します。
ストリームを操作的に定義する
トランザクション メッセージ、キャンペーン、従業員メールの背後にあるアプリケーションとプロバイダーをリストします。スケジュールされたジョブと少量の重要なメッセージが含まれます。各ルートについて、From ドメイン、期待される署名ドメイン、 セレクタ、秘密キー管理者、 DNS所有者、およびビジネス回復の要件。
プラットフォームがサポートしている場合は、個別のセレクターを使用してください。下 RFC 6376 §3.1、セレクターは署名ドメインの下の検証データを識別するため、異なるセレクターは、独立して管理されるキーが 1 つのルックアップ名で衝突するのを防ぐことができます。セレクターの名前を変更すると新しい秘密キーが作成される、またはプラットフォームがすべてのストリームを個別にローテーションできるとは想定しないでください。
ドメインも分離する必要があるかどうかを決定する
セレクターは、メッセージの目的ではなく、キーの検索を整理します。 d=brand.exampleで認証された秘密キーは、セレクター ラベルによって請求書またはキャンペーンに制限されません。より細かい権限境界が必要な場合は、アクセス制御および明示的な From ドメインの選択とともに、サポートされている署名サブドメインを検討してください。
DMARC アライメント その設計の一部として残らなければなりません。組織とドメインの関係が満たされている場合、サブドメインからの署名は、緩和されたルールの下で親作成者ドメインと一致することができます。厳密な位置合わせには、以下の正確なドメインが必要です RFC 9989 §3.2.10.2。組織ドメインの検出は次に行う必要があります RFC 9989 §4.10.2 単純な最後の 2 つのラベルの比較ではありません。
分離の例を見てみる
例示的なデザイン: トランザクション メールはセレクター tx1 を使用し、キャンペーンは mk1 を使用し、スタッフ メールは emp1 を使用します。すべてd=brand.exampleを使用しますが、個別の秘密キーを使用します。 mk1 を取り消す場合は、tx1 または emp1 の公開キーを削除する必要はありません。ただし、mk1 秘密鍵を保持している攻撃者は、 brand.exampleの下でメッセージに署名することができます。 mk1 という名前は、マーケティングのみの権限を強制しません。
これは、個別のセレクターにより、共有ドメイン権限を残したまま、運用上の結合がある程度軽減されることを意味します。境界を強化するには、個別の資格情報、承認された送信者制御、および場合によっては署名ドメインが必要です。これらは提案されたコントロールであり、すべてのプロバイダーがそれらを公開しているという主張ではありません。
ストリームごとにローテーションと障害回復を計画する
各ストリームに独立した変更ウィンドウとテスト セットを与えます。トランザクション テストには、時間に敏感なアカウント メッセージを含める必要があります。キャンペーンのテストには、テンプレートと登録解除の処理を含める必要があります。従業員のテストでは、関連する送信ゲートウェイを実行する必要があります。コンテンツを変更するコンポーネントが、最終的に意図された署名者より前に動作するようにします。
通常のローテーションの場合、承認されたキューと有効期限の条件が満たされるまで、必要な古い検証資料を保存します。侵害されたキーの場合は、重複をやみくもに保持するのではなく、封じ込め要件によって廃止を決定します。共有秘密キーは、個別のセレクター名の利点の多くを無効にします。
あなたが築いた境界線を測ってください
ルートからキーへのレジスターと日付の入った受信メッセージの証拠を保管します。あるストリームの回転が別のストリームに影響を与えるかどうかをテストしますが、実際にテストを実行しない限り、これが起こったとは主張しないでください。セレクター レコードとアカウント権限の両方について、プロバイダーのオフボーディングを確認します。
成功とは、独立した管理者、変化、回復の道筋の説明可能なセットです。評判と受信箱の配置には独自の証拠が必要です。 DKIMセレクター アーキテクチャもそれを約束することはできません。
コンクリート免震モデルを確認する
合成レジスタは、tx1/key-T をアプリケーション チームに、mk1/key-M をキャンペーン プロバイダーに、emp1/key-E をメール操作に割り当てます。すべてはbrand.exampleとして署名します。この例示的な在庫モデルでは、mk1 を削除すると、保持セットに tx1 と emp1 が残ります。このレビューでは、実際のローテーションの実行や秘密キーの検査は行っていません。実際のテナントで秘密キーが異なること、またはそれらのルートが依然として送信していることを証明するものではありません。すべてのセレクターが同じ秘密キーを代わりに使用した場合、このインベントリ レベルの分離により、独立したキーマテリアルの格納が提供されなくなります。
タイムリーな受信は、 DKIMキーの分離の証拠にはなりません。設計をテスト済みとして扱う前に、実際のストリームごとにキーの保管場所、サポートされているローテーション制御、および受信メッセージの結果を検証します。
次の決断に必要な証拠
この例を承認する前に、tx1、mk1、および emp1 に個別の公開検証マテリアル、個別に制御される署名アクセス、および独立したローテーション サポートがあるかどうかを確認してください。公開指紋は資料を比較できますが、プロバイダーが個人的な保管場所や資格情報を隔離していることを証明することはできません。管理が共有されている場合は、ストリームを完全に分離したと呼ぶのではなく、残りの共通の障害パスを文書化します。