いま見直すべき「メールのなりすまし対策」と迫る「証明書47日時代」 〜 JAPANSecuritySummit 2025レポート 

フィッシング被害が増え続ける一方で、対策の“導入率”だけを見て安心してしまう空気もあります。フィッシング対策協議会 証明書普及促進WGの田上氏は、「今こそ対策と見直しが必要」として、メールの送信ドメイン認証（SPF / DKIM / DMARC）と、サーバー証明書（SSL / TLS証明書）の有効期間短縮がもたらす運用インパクトを解説しました。 

フィッシング対策協議会が見ている“現場の変化” 

田上氏が所属するフィッシング対策協議会は2005年設立。会員・オブザーバーが約140まで増えている背景には、当然ながらフィッシング詐欺の増加があります。協議会は注意喚起だけでなく、動向データベースの整備、手口分析、利用者向け・事業者向けガイドラインの公開、海外機関との連携など、実務に近いところで情報発信を続けているといいます。 

その中で証明書普及促進ワーキンググループは、ブラウザの仕様変更やSSL / TLS証明書の業界要件、S/MIMEや送信ドメイン認証（DMARC等）を整理し、事業者・利用者へ啓発する役割を担っています。 

送信ドメイン認証の基本：SPF / DKIM / DMARCは“セット”で効く 

本題の「送信ドメイン認証」とは、受信したメールが“正規の送信元から来たか”を検証し、なりすましを防ぐ技術です。中心となるのが次の3つ。 

• SPF：そのドメインから送信してよいIPアドレスをDNSに登録し、送信元IPを照合 

• DKIM：送信メールにデジタル署名を付け、改ざんされていないことを検証 

• DMARC：SPF / DKIMの結果を踏まえ、受信側がどう扱うか（拒否・隔離・監視など）をポリシーとして定義 

DMARCの普及が進めば、フィッシングメールが届く割合は下がっていく──期待はそこにあります。 

導入は進んだ。でも日本は「監視のみ」が多すぎる 

田上氏が最も強調したのはここです。DMARCの導入率は上がっている。しかし設定内容を見ると、日本は「監視のみ（p=none）」が多く、拒否（reject）や隔離（quarantine）が極端に少ない。 

日経225企業の調査例では、導入率は約81%まで進んでいる一方で、「監視のみ」が63%と大半を占める状況が示されました。国際比較でも、日本はreject / quarantineが低く、監視に偏っている傾向が目立つといいます。 

さらに、データ通信協会の調査結果をもとにワーキンググループで再集計したデータでも、導入自体は伸びているが、reject 1.9%、quarantine 8.2%と低水準で、監視のみが多い構図は変わりません。 

田上氏のメッセージは明快でした。 
「監視のみでは、DMARCの効果はほぼ出ない。次の段階に上げる必要がある」 

ポリシー強化の鍵は「受信側設定」と「レポート活用」 

DMARCは送信側だけの話ではありません。受信側での適切なポリシー設定、レポーティングの設定・活用が進むことで、監視のみから段階的にquarantine、rejectへ移行しやすくなります。 

そして田上氏は、政府からの要請にも触れました。2025年9月1日付で、DMARCポリシーを隔離・拒否へ進めること、送信側だけでなく受信側も含めた適切な設定を行うことが関連団体へ通知されている、という説明です。加えて、ロゴ表示などに関わる仕組み（BIMI）やドメインレピュテーションの活用も、対策強化の方向性として示されています。 

もうひとつの爆弾：サーバー証明書が“47日”になる 

後半はTLSサーバー証明書の有効期間短縮です。これは突然の話ではなく、2012年の「最大5年」から段階的に短縮され、現在は最大398日。ここから先が本当に厳しい。 

段階的に以下のように短縮されます。 

• 2026年3月15日以降：最大200日 

• 2027年3月15日以降：最大100日 

• 2029年3月以降：最大47日 

最大47日になると、単純計算で年8回程度の更新が必要になります。決定はCA/Browser Forum（パブリック証明書の要件を定める業界団体）で投票により可決された、と説明されました。加えて、有効期間だけでなく、ドメイン名の認証情報や組織審査に関する情報の再利用条件も変わるため、証明書を取得・更新する側は注意が必要です。 

最大のリスクは「失効」ではなく「更新漏れによるサービス停止」 

証明書の期限切れは、ブラウザ警告で済みません。状況によってはサービスが停止し、インシデント化します。過去にも大手事業者での停止事案があったように、有効期限切れは“確実に起きうる運用事故”です。 

そして、期間が短くなるほど、人手更新は現実的ではなくなります。更新頻度増加は運用コスト増を直撃します。 

打ち手は「自動化」一択。APIとACMEを前提に設計し直す  

田上氏が提示した解は、証明書ライフサイクル全体の自動化です。具体的には、証明書発行事業者が提供するポータルのAPIを活用する方法、あるいは標準プロトコルACME対応の仕組みを使う方法が挙げられました。 

段階的に短縮が進む以上、「いつか」ではなく「早めに」発行事業者へ相談し、実運用で回るかどうかの検証まで進めるべきだ、という提言で締めくくられます。 

まとめ：DMARCは“監視”から“拒否へ”、証明書は“手動”から“自動へ” 

田上氏の結論は、どちらも「次の段階に進め」という一点に集約されます。 

• DMARC：導入率ではなく、ポリシーを監視のみから隔離・拒否へ移行して初めて効果が出る 

• TLS証明書：47日時代に向け、更新の自動化を検討ではなく実装・検証へ進めるべき 

メールもWebも、企業の“顔”であり、攻撃者が最初に狙う入口です。設定が“ある”だけで安心せず、効く設定へ、回る運用へ。今このタイミングでの棚卸しが、近い将来の事故を減らします。