横浜銀行、国内地銀で先進的な詐称メール対策を構築–DMARCとBIMIを併用
今回は「横浜銀行、国内地銀で先進的な詐称メール対策を構築–DMARCとBIMIを併用」についてご紹介します。
関連ワード （セキュリティ等） についても参考にしながら、ぜひ本記事について議論していってくださいね。
本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。
横浜銀行は、同行になりすますメールから顧客を保護するために、送信メールの正当性を示す送信ドメイン認証技術の「Domain-based Message Authentication Reporting and Conformance」（DMARC）と、メールロゴ認証の「Brand Indicators for Message Identification」（BIMI）を導入した。国内の地方銀行としては先進的な取り組みになり、同行の担当者と、同行にソリューションを提供した日本プルーフポイントおよびデジサート・ジャパンが経緯を説明した。
DMARCは、インターネット標準のメール認証プロトコルとして、2012年に発足したProofpointやGoogle、Microsoft、Metaなどが参加する「DMARC.org」により整備された。BIMIは、送信メールに送信元が正規であることを示す組織やブランドのロゴ画像を表示する仕組み。第三者機関により認証を受けた組織が送信するメールをBIMI対応のメールサービスやソフトで受信すると、送信者情報としてBIMIに基づくロゴ画像が表示され、受信者はひと目で正規の送信者からのメールと認識できる。
今回の取り組みで横浜銀行は、DMARCへの対応としてプルーフポイントのフィッシングメール対策ソリューション「Proofpoint Email Fraud Defense」、BIMIへの対応としてデジサートの認証マーク証明書（VMC）をそれぞれ活用している。
横浜銀行 ICT推進部 セキュリティ統括室の五十嵐俊行氏によると、まずDMARCへの対応は、2023年2月に経済産業省がクレジットカード事業者にフィッシング対策の一環としてDMARC対応を要請したことが契機だった。この時点で同行は要請の対象機関ではなかったものの、フィッシング対策強化の必要性を認識したという。
ところが同年5月に、同行のドメインに詐称したフィッシングメールのばらまき攻撃が発生。この事態を受けて同行はフィッシング対策を経営的な課題と位置付け、DMARCを推進することを意思決定したそうだ。
DMARCは、送信元ドメイン認証の「Sender Policy Framework」（SPF）と、メールに付与された送信者の電子署名を受信側で照合して正当性を判別する「DomainKeys Identified Mail」（DKIM）を導入していることが前提になる。DMARCでは、SPFとDKIMによる結果を用いて、詐称されたメールを受信側がどう扱うべきかの方針（ポリシー）をドメインの管理者側が宣言する。ポリシーには、「none（監視のみ）」「quarantine（隔離）」「reject（受信拒否）」の3つがあり、「reject」が最も厳格だが、DMARCを適切に実装、運用しなければ、受信者にメールが到達しない状況が発生し得る。
横浜銀行では、5月発生した事態を踏まえてBIMIの導入も視野に入れつつ、まずDMRACへの対応を検討したという。しかし、Googleが2024年2月に迷惑メール対策を強化するために「Gmail」のポリシーを改定。送信者がDMARCなどを設定していない場合は、1日に送信可能なメールが5000通未満に制限され、同行のドメインも対象になることから、DMARCの導入を決定した。
五十嵐氏は、「当行のメールマガジンなど受信されるお客さまの中でGmailの利用は多く、DMARCの導入が必達になった。ただし、DMARCの導入では苦労や注意すべき点も多くあった」と話す。
同行では、顧客向けや業務などでさまざまな部署が複数のメールシステムを利用しているといい、DMARCの対応では、ICT推進部がすぐに全てのメールシステムの状況を把握することが難しかったという。全量調査が必要なことからICT推進部では、全部署に通達を行ってメールシステムの全量調査を地道に進めたという。また、DMARC導入に伴うSPFやDKIMの設定にはベンダーの協力が必要だったため、メールシステムの利用部署に代わってICT推進部がベンダーとの調整を担当した。
また、ここではDNSの仕様からSPF設定で「include」を10件までしか登録できない状況も起きた。折しもそのタイミングで11件目のincludeを追加することになり、DNSに追加するにはベンダーの作業が必要だったことから、2024年1月にProofpoint Email Fraud Defenseをまず導入した。「このソリューションにより、DNSへのinclude登録の上限が解消され、DNSの設定変更なども都度行う必要がなくなり、SPFの設定が容易になった」（五十嵐氏）
上述のようにDMARCでは、最終的に「reject」のポリシーで運用することが望ましいが、同行は慎重を期して、まず「none」のポリシーで開始した。ただ、どのような基準でポリシーを「quarantine」や「reject」に変更するかが難しかったという。プルーフポイントは、失敗率が0.3％以下となることを目安として示しており、横浜銀行では、メールの状況を慎重に調査しながら判断を検討していった。
五十嵐氏によれば、DMARC導入に向けた全量調査で一部の漏れがあったこともあり、DMARC導入後の状況把握では、Proofpoint Email Fraud Defenseの機能を活用して集計レポート（RUA）から詳細を分析し、受信者側の転送でDMARCが失敗している理由など原因追究を進めたという。失敗については、送信先へ個別に案内を行い、設定変更などの対応を依頼。こうした対応を進めて同行は、2024年4月末に「reject」ポリシーに移行した。一部のドメインでは失敗率が0.3％以上であったものの、送信先ごとにきめ細かく対応したことで、ポリシーの移行を決断できたという。