DMARC 対応の話 - MIXI CTO オフィスアワー #04

11月13日に株式会社 MIXI の開発者向け YouTube チャンネル MIXI TECH TALK の CTO Office Hour で話した時の資料です。
YouTube: https://www.youtube.com/watch?v=AEct8fWQ6TQ
SRE グループの採用はこちら: https://mixigroup-recruit.mixi.co.jp/occupation/engineer/1620/

Transcript

1. ©MIXI DMARC 対応の話 MIXI CTO オフィスアワー #04 2024/11/13 株式会社 MIXI 開発本部 CTO 室 SRE グループ 多⽻⽥俊
2. 2 ©MIXI ⾃⼰紹介 【名前】 多羽田 俊（たばた しゅん） 【所属】株式会社 MIXI 開発本部 CTO 室 SRE グループ 【来歴】 • 前職では主に Web アプリケーションのバックエンド開発を 中心に、フロントや iOS アプリの開発も経験 • 現在は主に会社の基盤システムの設計から開発・保守・運用 や、プロジェクトへの DevOps 支援などを行なっている -好きなこと- 猫（2匹飼ってます）、音楽、 作曲、お酒 - X (旧：Twitter) - @bbq_all_stars
3. 3 ©MIXI MIXI の開発本部 CTO 室 SRE グループ 特定のプロダクト・ サービスに所属するエンジニア 横断的に複数のサービス・ プロジェクトに関わるエンジニア SRE
4. 4 ©MIXI • ミッション ◦ 注⼒事業サービスにて開発‧運⽤のため の設計開発保守を遂⾏と新技術の検証‧ 研究 ◦ MIXI GROUP 全体で開発⽣産性の向上‧ コスト最適化のための取り組みを進める ◦ ⼈材の育成‧リスキリングを進めて課題 を解決していけるようにする • 業務内容 ◦ 注⼒事業の⽀援 ◦ 他事業を伸ばすための⽀援 ◦ 全社的な横軸での案件サポート 開発本部 CTO 室 SRE グループの紹介 注力事業の支援 ・サービスを支える基盤の 　構築や運用 ・パフォーマンス向上 ・負荷対策の検討/実施 他事業の成長支援 ・クローズしたサイトの 　メンテナンス ・eスポーツの円滑化/ 　安定化支援 ・コーポレートサイトの 　構築運用支援 ・技術教育のコンテンツ/ 　講師など 全社的な横軸での案件サポート ・全社横断での支援 ・社内ITと協力して最適なIT投資をする ・MIXI 社全社のツールの導入・推進
5. ©MIXI 5 • 今回のお話の背景 ◦ 全ての始まり「メール送信者のガイドライン」 ◦ DMARC とは？ ◦ DMARC レポートとは？ ◦ DMARC レポートの問題 ◦ MIXI の状況 • DMARC レポートの⽇次集計‧通知システム ◦ システムの設計⽅針 ◦ システムのアーキテクチャ ◦ できたもの ◦ 実装してみてわかったこと ◦ 課題‧展望 • まとめ ⽬次
6. ©MIXI 今回のお話の背景
7. ©MIXI 7 • 2023年10⽉に Google/⽶Yahoo が新しく公開したメール送信者向けのガイドライン • 5000通/⽇を送信している事業者は対応が必要 • これに従わずにメールを送ると、 Gmail 側で迷惑メールと判定されてユーザーにメールが届かな くなる可能性がある • 当時 SRE グループで運⽤していたシステム ◦ 数万通/⽇ ◦ Gmail が9割以上 ◦ => 対応が必須 • ガイドラインの内容のうち、ほとんどは既に対応済みだったが、DMARC の対応だけ新しく⾏う必 要があった 今回のお話の背景：全ての始まり「メール送信者のガイドライン」
8. ©MIXI 8 • メールの受信側（下記の例は Google）が、メールの送信元アドレス（mixi.co.jp）のドメインが 偽装されていないかを判断する仕組み（DMARC認証） • ドメインの所有者（上記の例はMIXI）は、DMARC認証に失敗したメールをユーザーのメールボッ クスに配信しないように、メールの受信側（Google）にお願いできる • ドメインの所有者（MIXI）は、DMARC認証に失敗したメールの情報を、メールの受信側 （Google）から定期的に報告を受けることができる（DMARC レポート） ◦ これにより、メール配信サービスの設定をミスして意図せず正規のメールが偽装メールと判 断されてしまったことに気づける 今回のお話の背景：DMARC とは？ 受信したメールの例
9. ©MIXI 9 • メールの受信側が、DMARC認証の状況をドメインの 所有者に報告する仕組み • ⼀定期間の間に、メールの受信側に何通メールが送 られてきて、そのうち何通が各種認証‧アライメント に失敗しているかが XML に記載されている DMARC レポートの問題 • 毎⽇さまざまな事業者から送られてくる • XML なので⼈間が読むには⾟い • ⾃社のメール配信に問題がないことを確認したら、 メールシステムを変更しない限り変化がないので、あ まり頻繁に⾒るものではなくなる ◦ => レポートの解析サービスもあるが、それを導 ⼊しても使うのは最初だけ 今回のお話の背景：DMARC レポートとは？ <?xml version="1.0" encoding="UTF-8" ?> <feedback> <report_metadata> <org_name>example.com</org_name> <email>noreply-dmarc-support@example.com</email> <extra_contact_info>http://example.com/dmarc/support</extra_contact_info> <report_id>9391651994964116463</report_id> <date_range> <begin>1335571200</begin> <end>1335657599</end> </date_range> </report_metadata> <policy_published> <domain>bix-business.com</domain> <adkim>r</adkim> <aspf>r</aspf> <p>none</p> <sp>none</sp> <pct>100</pct> </policy_published> <record> <row> <source_ip>203.0.113.209</source_ip> <count>2</count> <policy_evaluated> <disposition>none</disposition> <dkim>fail</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <header_from>bix-business.com</header_from> </identifiers> <auth_results> <dkim> <domain>bix-business.com</domain> <result>fail</result> <human_result></human_result> </dkim> <spf> <domain>bix-business.com</domain> <result>pass</result> </spf> </auth_results> </record> </feedback> DMARC レポートの例 https://support.google.com/a/answer/10032472?hl=ja より引用
10. ©MIXI 10 • MIXI ではプロジェクトごとにメール配信サービスを選定しているので、ガイドラインの対応は基 本的にプロジェクト側で⾏っている • ガイドラインの対応のほとんどは、メール配信サービスの設定や DNS の設定を⼀度するだけで済 む • ⼀⽅で、DMARC の対応だけは、定期的に DMARC レポートを受けて確認するフローが必要になる • 社内でヒアリングしたところ、⽇次で DMARC 認証の集計値を教えてくれるだけで⼗分そう ◦ => レポート解析サービスを全社で導⼊するほどの強い動機もない 簡易的なDMARC レポートの集計‧通知システムを開発することに 今回のお話の背景：MIXI の状況
11. ©MIXI DMARC レポートの ⽇次集計‧通知システム
12. ©MIXI 12 • スケールする • 安価 • フルマネージド • シンプル DMARC レポート通知システム：システムの設計⽅針
13. ©MIXI 13 • 処理の流れ 1. AWS SES で受信 2. 報告を受けたドメイン毎に S3 bucket を 分けて保存 3. S3 イベントをトリガーにして Lambda を実⾏ 4. レポートの集計期間ごとにディレクトリ に仕分けする 5. 毎⽇定時に Lambda を実⾏ 6. Lambda は通知したい⽇時のディレクト リのメールを取得してレポートを集計 7. 集計した内容を通知 • S3 のメールは、ライフサイクルルールで 1 週 間後に⾃動で消える仕様 • 念のため S3 イベントを記録する CloudTrail を設定 • その他、Lambda のステータス監視等 DMARC レポート通知システム：システムのアーキテクチャ Slack Slack
14. ©MIXI 14 • 以下の内容を通知 • 合計メール受信数 • DMARC 認証に失敗した数 • SPF or DKIM 認証に失敗した数 • 細かい認証失敗の状況は、CSV にまとめ てメッセージに添付 DMARC レポート通知システム：できたもの
15. ©MIXI 15 • レポートメールが1⽇以上かかってから送られてくることがある ◦ => Google/⽶Yahoo のみ集計することで対応 • UTC or JST… ◦ ⼀部のキャリアメールから送られてくる DMARC レポートが、 JST の⽇付で集計していた ◦ => 同じ⽇付として丸めちゃう ◦ => 詳細については CSV を⾒てもらう運⽤ ◦ => 今は Google/⽶Yahoo のみ集計対象なので、結果的に関係なくなった • 様々なドメインの DMARC レポートを受け取れる必要がある ◦ => アーキテクチャは、 Terraform Module を使⽤してドメインごとに複製する形にした ◦ => DMARC の仕様で、レポートを受け取るメールアドレスのドメインが違う場合は、別途レ ポートを受け取るドメインに設定が必要（DMARC External Destination Verification） ▪ *._report._dmarc.example.com というような DMARC レコードを登録する必要があっ た • レポートメール⾃体の DMARC 認証もチェックする必要がある ◦ メールアドレスは公開されているので、偽装メールが送られてくる可能性は当然ある ◦ AWS SES は DMARC 認証をチェックしてくれるので、その結果を利⽤ DMARC レポート通知システム：実装してみてわかったこと
16. ©MIXI 16 • 継続的な変化が⾒れない問題 • メールアドレスを公開していることによるリスク • Google / Yahoo のみを対象としていること • ⼀定の閾値に基づいたアラート DMARC レポート通知システム：課題‧展望
17. ©MIXI まとめ
18. ©MIXI 18 • メール送信者のガイドラインが公開されたので、DMARC の対応をする必要がありました • DMARC レポートを⽇次で集計して通知するツールを作り、各プロジェクトが使えるようにしまし た • サーバレスで実装しつつ、簡易的な作りにすることで、安価に利⽤できるものを⽬指しました • 実際に実装してみると、いくつか問題が出てきましたが、仕様を限定することで対応しました • まだまだ改善できるところはあるので、今後対応できればと思います まとめ
19. ©MIXI