5.2メール・DNSセキュリティと認証プロトコル

なりすましメールとDNSキャッシュポイズニングは、いずれも「本物のふりをした偽物」を見抜けないことが根本原因です。CSIRTメンバーや設計者は、この脅威にはどの対策が有効かを正確に判別できなければなりません。特にSPF・DKIM・DMARCは名前が似ていて役割を混同しやすいため、それぞれが「何を検証し」「検証結果をどう使うか」を分けて理解することが本節の核心です。

5.2.1送信ドメイン認証（SPF・DKIM・DMARC）

• SPF（Sender Policy Framework）＝送信元メールサーバのIPアドレスが、送信ドメインがDNSに公開した正規の送信元IPリストに含まれるかを検証する。エンベロープFrom（SMTP通信上の送信元）のドメインを検証するため、メール転送でエンベロープFromが変わるとSPF検証が失敗しやすい弱点がある。
• DKIM（DomainKeys Identified Mail）＝送信側が秘密鍵でメールヘッダ・本文にデジタル署名を付与し、受信側がDNSで公開された公開鍵で署名を検証する。ヘッダFromのドメインの正当性とメール内容の改ざん検知を提供し、転送で内容が変わらない限り署名は維持されるためSPFより転送耐性が高い。
• DMARC（Domain-based Message Authentication, Reporting & Conformance）＝SPFとDKIMの検証結果（の少なくとも一方が合格し、かつヘッダFromのドメインと整合すること＝アライメント）を踏まえ、不合格時にメールをどう扱うか（none/quarantine/reject）を送信ドメイン側がポリシーとして宣言し、受信側に適用させる上位の枠組み。認証結果のレポートを送信ドメインへ返す仕組みも持つ。DMARC自体は独自の署名検証を行わず、SPF/DKIMの結果を「使う」立場である点が最重要。

5.2.2メール送信インフラの保護（SMTP-AUTH・OP25B/IP25B）

• SMTP-AUTH＝メール送信（SMTP）時に利用者ID・パスワード等で送信者自身を認証する拡張機能。オープンリレー（誰でも中継送信できるサーバ）を防ぎ、正規の契約者だけがメール送信できるようにする。
• OP25B（Outbound Port 25 Blocking）＝ISPが動的IPアドレスを割り当てた利用者から、25番ポートでの直接の外部メール送信をブロックする対策。ボット化した利用者端末が直接スパムを送信するのを防ぐ。正規の送信にはサブミッションポート（587番）＋SMTP-AUTHを使わせる。
• IP25B（Inbound Port 25 Blocking）＝OP25Bとは逆に、動的IPアドレスからの受信側（25番ポート宛の着信）をブロックする対策。動的IPの割当元からのスパム着信の受け入れを抑制する。

5.2.3DNSセキュリティとOAuth・認証プロトコル

• DNSSEC（DNS Security Extensions）＝DNS応答にデジタル署名を付与し、応答の送信元認証と改ざん検知を提供する拡張。攻撃者が偽の名前解決結果を注入するDNSキャッシュポイズニングへの対策として最も直接的に有効。ただしDNSの通信内容自体を暗号化（機密性を提供）するものではない点に注意。
• DNSBL（DNS-based Blackhole List）＝スパム送信元として既知のIPアドレスをDNS形式で照会できるリスト（ブラックリスト）。受信側メールサーバが送信元IPをDNSBLに照会し、該当すれば拒否・隔離する迷惑メール対策。
• OAuth＝あるサービス（クライアント）が、利用者に代わって別サービス（リソースサーバ）上のリソースへ限定的にアクセスする権限（認可）を得るための標準プロトコル。パスワードそのものを渡さずアクセストークンを発行する点が本人認証（認証）との違い——OAuthは「認証」ではなく「認可」の標準である点が最頻出の混同ポイント。
• EAP（Extensible Authentication Protocol）＝多様な認証方式を拡張可能な形で運べる認証フレームワーク。EAP-TLSはクライアント証明書とサーバ証明書の相互認証で最も強固だが証明書配布の運用負荷が高い。PEAPはサーバ側だけ証明書で認証しTLSトンネルを確立した上で、その中でクライアント側の認証（ID/パスワード等）を行う方式で、運用負荷を抑えつつ盗聴からクライアント認証情報を保護できる。
• RADIUS（Remote Authentication Dial In User Service）＝利用者認証・認可・アカウンティング（AAA）を一元管理するプロトコル。無線LANのアクセスポイントやVPN機器が認証サーバ（RADIUSサーバ）に問い合わせる構成を取ることで、多数の機器で認証情報を分散管理せずに済む。PSK（Pre-Shared Key）＝事前に共有した固定の鍵で認証する方式で、小規模拠点など個別のRADIUSサーバ運用が見合わない場面に向くが、鍵が漏えい・共有されると全利用者の認証が形骸化する運用上のリスクがある。

あるCSIRTメンバーが、自社ドメインを騙るなりすましメール（BEC）が取引先に届いたという報告を受けたとします。まず調査すると、攻撃者は自社ドメインを詐称した送信元アドレスでメールを送っていたものの、実際の送信サーバのIPアドレスは自社の正規メールサーバとは異なっていました。この場合、受信側メールサーバがSPFレコードを検証していれば、エンベロープFromのドメインが公開する正規送信元IPリストに攻撃者のIPが含まれないためSPF不合格と判定できます。ただし、SPFはメール転送で失敗しやすいため、SPF単独では正規の転送メールまで誤って拒否するリスクがあります。そこで、DKIM署名も設定していれば、ヘッダFromの正当性とメール内容の改ざん有無を独立に検証でき、SPFかDKIMのいずれかが合格しヘッダFromとアライメントが取れていればDMARCは合格という判定ロジックが働きます。今回のなりすましメールはSPFもDKIMも失敗するため、自社がDMARCポリシーをrejectに設定していれば受信側で確実に拒否されます——このようにDMARCポリシーの強さ（none観測のみ→quarantine隔離→reject拒否）を段階的に引き上げる運用が、なりすましメール対策の実務標準です。一方、別の日には社内DNSサーバが不審な名前解決結果を返すDNSキャッシュポイズニングの疑いが報告されました。この場合はSPF/DKIM/DMARCは無関係で、DNSSECを導入し応答の署名検証を有効にすることが直接的な対策になります（DNSBLは送信元の評判照会であり、キャッシュポイズニングそのものの防止策ではない点に注意）。

5.2.4この節のまとめ

• SPF＝送信元IPを検証（エンベロープFrom）、DKIM＝署名でヘッダFromと内容を検証、DMARC＝両者の結果とアライメントを使いポリシー（none/quarantine/reject）を適用する上位の枠組み
• OP25Bは動的IPからの外部送信をブロックしボット由来スパムを防止、DNSSECはDNSキャッシュポイズニングに直接有効（暗号化ではなく署名検証）
• OAuthは認証でなく認可の標準。EAP-TLSは相互証明書認証で最強固、PEAPはサーバ証明書のみでトンネルを張り運用負荷を抑える