A セレクタ モニターは、検証データが変更または消失したことを通知できます。サービスがまだ送信中であること、その秘密鍵が公開された鍵と一致すること、またはそのメッセージが整列して到着することを確立できません。 DKIM。公開された構成と観察されたメッセージの動作について個別のチェックを作成します。
既知の送信ルートから始める
承認された送信者の構成と代表的な受信メッセージからインベントリを作成します。各ルートのレコードには、ビジネス所有者、d ドメイン、セレクター、 DNS所有者、予想されるTXTまたは CNAME 配置、最後に観察された署名時刻、ライフサイクル状態。共通セレクターを推測することですべての署名者が検出されるとは考えないでください。 DKIM 、完全なDNS列挙サービスを定義するのではなく、各署名でセレクターを提供します。
s=invoice2とd=brand.example,以下のinvoice2._domainkey.brand.exampleを調べてください。 RFC 6376 §3.6.2.1。期待されるCNAMEその検証データに従います。変更を承認されたローテーションと比較できるように、観察タイムスタンプと公開キーのフィンガープリントを保存します。秘密キーを監視システムに収集しないでください。
モニターの結果を分離する
応答の欠落、 DNSタイムアウト、取り消されたキー、および変更されたキーは、別のイベントです。 RFC 6376 §6.1.2 キークエリの失敗とキーの不在を区別し、空の p 値は取り消しを表します。 RFC 6376 §3.6.1。すべてのエラーを一般的な停止に変換するのではなく、応答の詳細を記録します。
現在のキーには構文とアルゴリズムのチェックが必要です。 RFC 8301 §3.1 rsa-sha1 の署名と検証を禁止します。 RFC 8301 §3.2 RSA サイズ要件を更新: 署名者は少なくとも 1024 ビットを使用し、少なくとも 2048 ビットを使用する必要があります。製品サポートと現在の組織の暗号化ポリシーはより厳格になる可能性があります。指紋の変更だけでは、ローテーションが承認されたかどうかを判断することはできません。
ライブ証拠ループを追加する
制御されたメッセージは、重要な各運用ルートを通じてメールボックスに送信され、その生のメッセージと信頼できる認証結果を検査できます。観察された d と s、検証結果、および アライメント フロムと。 HTML や添付ファイルなど、ダウンストリーム処理が影響する可能性のあるメッセージのバリエーションを実行します。
モニターの例: DNS引き続き invoice2 を処理しますが、新しいメッセージには何も含まれていません DKIM-Signature。公開チェックは合格しますが、署名チェックは失敗します。別のケースでは、署名は存在しますが、 ボディハッシュ ゲートウェイのフッター変更後に失敗します。どちらのインシデントも、 DNSレコードが正常であると宣言しても解決されません。これらは合成テスト ケースであり、測定されたサービス インシデントではありません。
合成テストにも限界があります。毎日のプローブでは、通過したプローブ間のすべてのメッセージが証明されるわけではありません。報告対象範囲と遅延を認識しながら、それを受信者のレポートやインシデントの証拠と組み合わせます。
実用的なアラートをルーティングする
ルートと所有者にアラートを添付します。明示的に承認されたメンテナンス期間のみを抑制し、イベント履歴を保存し、ローテーション後に新しいメールで新しい署名者を確認します。予期しない主要な変更は、変更だけによる侵害を宣言することなく、セキュリティ イベントの可能性としてエスカレーションします。
古い在庫行を意図的に廃棄します。新しい署名が停止した場合でも、遅延メッセージの検証のために古い公開キーが残る場合があります。その計画された状態と放棄された代表団を区別してください。ダッシュボードには、いつ、どの方法で何が観察されたのかが表示される必要があります。そうすることで、 DNS健全性がライブ署名の証拠に偽装されることはありません。
アラートの決定を再現する
4 つの合成プローブを使用して、アラート レイヤーを分離します。 d=brand.exampleおよびs=invoice2を含む署名は、 invoice2._domainkey.brand.exampleにマップされます。公開キーは存在するが、指定された受信者の結果がボディハッシュの失敗である場合は、メッセージ検証アラートを生成します。キーが存在しない場合は、キー不在アラートを生成します。予期したレコードは存在するが、メッセージに署名がない場合は、署名不足アラートを生成します。現在のキーと提供された合格結果では、そのプローブだけに対するアラートは生成されません。
これら 4 つの決定は、発明されたDNS状態と提供された受信者の結果を含む例示的な決定モデルです。このレビューでは、ライブDNSクエリ、署名テスト、暗号検証は実行されませんでした。モニターを委託するには、それらを、信頼できる受信境界からの結果を伝える日付付きの公開回答と生のメッセージに置き換えます。運用が検証されたルートを説明する前に、リンクされた証拠を保存してください。
次の決断に必要な証拠
ボディハッシュ アラートの場合は、提供された結果を保存し、ボディ表現、C/L 設定、bh 値、実装動作を調査します。不一致だけでは、ゲートウェイでコンテンツが変更されたことを証明することはできません。キーが存在する場合でも、新しいプローブがないルートを未観測としてマークします。 DKIMパスだけでは位置合わせされたパスではないため、位置合わせがチェックされたかどうかを別途記録します。