Email Security Conference 2016 IAjapan 第 14-15 回迷惑メール対策カンファレンス DMARC による新しいメール認証と導入の留意点 2016 年 10 月株式会社コミュニティネットワークセンターニコライボヤジエフ Page-1
自己紹介 名前 : ニコライボヤジエフ 在日ブルガリア人 : < 300 人 出身 : ブルガリア България 所属 : 株式会社コミュニティネットワークセンター技術本部システムグループ 担当 : メールサービス運用 企画 開発サーバ系システム全般 (DB/DNS/DHCP/RADIUS etc ) キリル文字読めるので ロシア語スパムメール判別が得意 Page-2
会社概要 $ dig _dmarc.cnci.co.jp TXT +short $ dig _dmarc.cnci.nagoya TXT +short "v=dmarc1 ; p=none ; adkim=s ; aspf=s Page-3
グループ会社紹介 東海地方のケーブル MSO です Page-4
事業紹介 ~ 放送事業 ~ 放送配信事業 番組販売事業 Page-5
事業紹介 ~ 通信事業 ~ ISP 事業 XX 万のエンドユーザ向けメールサービス提供中 (AS9354 等 ) Page-6
ISP ユーザにとってメールサービスにおける重要なこと ここ当たり前 サービスが安定していること (NO MORE 総務省報告 ) メールが届くこと メールがなくならないこと 迷惑メール対策含む 肯定的な使用感 ( 利便性 セキュリティ スピード ) ここが重要但し かなり難しい Page-7
Receiver/ISP の立場からみた DMARC とは 名称がカッコいい (D= ドメイン +MARC= 印 ) Sender の認証方針 (policy) が明確 DKIM/SPF の認証識別子の標準的な利用を定義 MUA で見える RFC5322.From ドメインに対してのチェック (Sender が宣言していれば ) 確実ななりすまし対策が可能 ISP としてここが重要 Sender として メール到達性を重視しているため p=none 以外宣言できない レポーティングもあんまり興味ない Page-8
DMARC の仕組み ( おさらい ) 7 ポリシー適用せず ボックス配送 : DMARC ポリシーなし DMARC 検証 OK DMARC 検証結果のヘッダ付与 安心 / 警告 マーク表示 など LEVEL2 ラベリング / レピュテーション 6SPF/DKIM 検証 DMARC 検証 4SPF/DKIM 問い合わせ 5DMARC ポリシ問い合わせ 1SPF/DKIM レコード登録 DNS サーバ 2DMARC ポリシー登録 ユーザメールボックス ポリシー A 何もしない (p=none) 8 DMARC ポリシーの適用 受信者メールサーバ 3 メール送信 DKIM の場合署名付与実施 送信者メールサーバ LEVEL1 ポリシー公開 (Sender) LEVEL3 ポリシー適用 ポリシー B 拒否 (p=reject) ポリシー C 隔離 (p=quarantine) 9 DMARC レポート作成 10 DMARC ポリシーに登録された告知先アドレス宛にレポートを送信 IP アドレス (rua,ruf) 回数 (rua,ruf) メール本文 (ruf) レポート告知先メールアドレス LEVEL4 レポート送信 Page-9
当社の DMARC 導入について (Sender) LEVEL1 DMARC ポリシー公開 済 2014 年 7 月より 全ドメイン公開 (p=none, 商用ドメイン rua/ruf なし ) JANOG 34 資料 : https://www.janog.gr.jp/meeting/janog34/doc/janog34-op25b-akagiri-katoh-kase-1.pdf LEVEL2 ラベリング / レピュテーション 済 DMARC 検証結果のヘッダ付与 (Authentication-Results) ( 一部システム ) LEVEL3 ポリシー適用 LEVEL4 レポート送信 未 未 課題ありのため現状未実施 Page-10
DMARC 導入に関する課題 ( 法的課題 ) 項目 LEVEL1 ポリシー公開 (Sender) LEVEL2 ラベリング / レピュテーション LEVEL3 ポリシー適用 LEVEL4 レポート送信 違法性 ( 通信の秘密 を 侵害する行為 の有無 ) 電気通信事業法第 4 条 有 (ruf/rua タグ ) 有有有 違法性阻却理由 無 現時点解釈が未整理 (ruf/rua タグ ) 有 正当業務行為 無 現時点解釈が未整理 無 現時点解釈が未整理 備考 p タグ (policy) の公開については問題ないが rua タグ (aggregate report) および ruf タグ (failure report) の公開についてはレポーティング機能を利用して 通信の秘密 を漏えいさせる教唆に該当する可能性がある 受信側における送信ドメイン認証導入に関する法的な留意点 ページ 3 参照 URL http://www.soumu.go.jp/ main_sosiki/joho_tsusin/d_ syohi/pdf/domain-j.pdf 通信当事者の同意無しにメールの拒否 隔離を行っているため 通信の秘密 を 侵害する行為 に該当する 違法性阻却事由 に関する解釈がまだ整理されてないので 現時点では 違法状態 と考えられる レポーティング機能では 通信当事者の同意無しに fail した送信元の IP アドレス 受信回数 メール本文などを第三者に通知するため 通信の秘密 を 侵害する行為 に該当する 違法性阻却事由 に関する解釈がまだ整理されてないので 現時点では 違法状態 と考えられる 困難 Maybe? 困難 Page-11
DMARC 導入に関する課題 ( コストメリット ) DMARC 対応導入コスト ISP にとってのメリット LEVEL1 ポリシー公開 (Sender) 無 DMARC の認知度向上に貢献し 最終的に DMARC の普及につながる LEVEL2 ラベリング / レピュテーション 低 ~ 中 1 なりすまし対策が実装できる ( 但し DMARC 普及が条件 ) LEVEL3 ポリシー適用 高 なりすまし対策が実装できる ( 但し DMARC 普及が条件 ) ポリシー適用によるクレームの可能性あり LEVEL4 レポート送信 高 ( 低 ) 2 Sender にフィードバックすることによって Sender が DMARC 導入しやすくなるため 最終的に DMARC の普及につながる 1 DMARC 対応ソフト及びサービス情報 :https://dmarc.org/resources/products-and-services/ OSS ソフト (by IIJ) : yenma (https://github.com/iij/yenma) 2 一部のメールアプライアンスでレポート送信機能を標準搭載 Page-12
まとめ DMARC は優れた技術 ( 標準的でわかりやすい ) 有効ななりすまし対策になるために もっと普及が必要 法的課題があるので レポーティング要注意 DMARC をもっと普及させましょう! Page-13