送信ドメイン認証対応を機に技術的負債に立ち向かってみた
404 Views
January 19, 24
スライド概要
2024年01月18日開催「CCoE実践者コミュニティ関西 #2」での発表資料です。
右投げ右打ち一部レフティー
関連スライド
各ページのテキスト
CCoE実践者コミュニティ関西 #2 送信ドメイン認証対応を機に 技術的負債に立ち向かってみた 2024年01月18日 chocopurin
Self-Introduction ● ● ● 名前：chocopurin 職業：とある企業の一般社員 主なお仕事 ● ITインフラ構築/維持管理 セキュア開発周りの整備（主にSAST/DAST） 永久AWS見習い 出没歴 OWASP Kansai, 総関西サイバーセキュリティLT大会 TKTKセキュリティ勉強会, Micro Hardening, SaaSセキュリティの会 nakanoshima.dev, Security-JAWS レトロゲーム勉強会, CCoE実践者コミュニティ関西 etc
Self-Introduction ● 「ハードニングファン！！2023」Chapter.4に寄稿しました
はじめに ● ● ● 本LTは事実をもとにしたフィクションです。このため、実際とは 異なる表現が含まれています。 DMARC/DKIMといった、送信ドメイン認証技術そのものの話は ありません。 本LTの内容は2023年12月11日現在の情報をもとにしています。
提供サービスと社内コミュニケーションの変遷 2010年頃 提供サービス コミュニケーション オンプレDC サーバ群（約200台） サービス利用者 オンプレDC サーバ群 (約160台) サービス利用者 EC2群 (約60台) イマ 2023年 ココ サーバレス 中心 サービス利用者
それはある秋の終盤に突然やってきた
【出展】Gmailメールヘルプより抜粋 2024年2月1日以降※「送信ドメイン認証がないGmail宛のメール はGoogle側で拒否するよ」ということらしい ※「5000件/日以上のメールを送信する場合は2月1日より前でも適用される」と読める記述もある
Gmailのメール送信者ガイドライン(超ざっくり) 対象 何をすればいいのか？ Gmailアカウ 全員 ● SPF,DKIMのいずれかもしくは両方に対応する ント宛にメー ● 送信元のドメインまたはIPアドレスに、有効な正引きおよび逆引きDNSレコード ルを送信する （PTR レコード）があること メール送信者 ● GmailのPostmaster Toolsが出力する迷惑メール率を0.3%以下にする ● 作成するメールの形式はInternet Message Format標準（RFC5322）に準拠させる ● GmailのFrom: ヘッダーのなりすましをしない ● メーリングリストや受信ゲートウェイを使用するなどして、メールを定期的に転送する場合 は、送信メールにARC ヘッダーを追加する 1日5,000件 全員 上記全員が行う対応に加えて下記を行う 以上発信する ● SPF,DKIM両方に対応する メール送信者 ● DMARCを設定する ● Postmaster Toolsが出力する迷惑メール率を0.10%未満に維持する（一時的に迷惑メール率 が上がるケースがありうるが、それでも0.30%以上にならないようにする） ダイレク ● 受信者がワンクリックで登録解除できる仕組みを用意する トメール ● 送信者の From: ヘッダー内のドメインをSPF ドメインまたは DKIM ドメインと一致させる ※Gmailメール送信者のガイドラインおよびNRIセキュアブログの内容をもとに作成。詳細は世間の先行事例をご確認ください。
スケジュール 年月 2023年 10月 Google 世間 しれっとアナウンス - 自社 某コミュニティ経由で情報を 入手＆何も考えずに内部展開 →実は重要案件だった… 11月 12月 アナウンス文に微妙に 一部セキュリティ系ブログで ● 影響調査 サイレント修正が入る 見かけるようになる ● Postmaster Toolsの導入 ● 無駄メールの削減 (クレームでも来た？) IT系メディアで取り上げられ 始める 2024年 1月 2月 送信ガイドライン施行 ※これまでの実施内容から主観で作成しています - （本件の対象） ● DNSの設定変更 ● その他必要な施策 経過観察
無駄メールの削減：現状把握 ● ブランド毎の独自ドメイン ● brand-A.com brand-B.net etc 多彩な用途 お客さまへのアナウンス • メールマガジン • 各種告知 管理者への通知 • バッチプログラムの実行結果（本件の対象） • エラーアラート などなど
無駄メールの削減：バッチPGM（技術的負債） ● 実行結果はすべてメール送信 正常終了/エラー不問 • • ● コミュニケーションがメールからチャットに変わった昨今では意味なし 「入門 監視」でいう、アラート運用のアンチパターンに極めて近い 受信側はフィルタルールで即削除・・・ 過去の試行錯誤をリファクタリングせずそのまま運用 試しながら作られたと思われるメール送信メソッド • サーバの機能ではなく、プログラム自身にmailコマンドをハードコード 同じ用途のサーバなのに、サーバによって設定が違う • 1号機には導入されているログ監視モジュールが2号機にはない 読まれないメールの大量発生（1日あたり約300通/人）
無駄メールの削減：サーバ設定による抑制 ● とりあえずすぐに実現できる施策を行うことで、無駄メールの 母集団を少しでも減らす 【例】cronからのメール送信の抑制※1（CentOS7系※2） • /etc/sysconfig/crondの変更（要crond再起動） CRONDARGS= ↓ CRONDARGS="-m off" • /etc/crontabの変更 MAILTO=root ↓ MAILTO="" ※1 メール抑制の設定方法は数多くあり、実際にはご自身の運用ルールにあったやり方の検討が必要です。 ※2 別途リプレース対応中
無駄メールの削減：効果と今後の予定 ● 効果：1日あたり約300通/人のメールを半分以上削減 ● 改修すべきプログラムのあぶり出しの効率化 受信者に対する心理的安全性の向上 一部効果がみられなかったケースあり 今後の予定 Postmaster Toolsによる詳細分析 さらなるメール削減策の検討 DNSの設定変更 バッチプログラムの改修 新規システム構築時の考慮事項への反映
まとめ ● Gmailの送信ガイドライン変更はそれなりのインパクトがある ● Gmailに限らず、送信ドメイン認証導入の流れは今後も続く 可能性があり、開発時の考慮事項の一つになるかもしれない ● 期間の猶予は残り少ない 不定期にサイレント修正が入るため、最新情報をキャッチアップして 対応する必要がある（工数に跳ね返る） 12月上旬の時点でも、一般ニュースであまり見かけないのが不気味 IPA 情報セキュリティ10大脅威 2023：組織部門第7位 米国Yahoo!のアナウンス システムライフサイクルは重要 古いシステムはとっとと引退させられる仕組みを整えるべし