メインコンテンツまでスキップ

【メモ】メール要件定義整理

はじめに（前提）​

メールを扱うシステムの要件定義では、メールを「通知のための機能」として見るだけだと危険です。メールは同時に、なりすまし／フィッシング／情報漏えい（誤送信含む）／マルウェア侵入／踏み台化の攻撃経路にもなり得ます。

要件整理のステップ（全体像）​

Step 0. メールの「使い方」を分類する​

最初にユースケースを確定します。ここがズレると、以降の要件が全部ズレます。

区分代表例重点になりやすい論点
A送信のみ（通知、OTP、請求書送付など）送信ドメイン保護、誤送信、踏み台化
B受信のみ（問い合わせ窓口、添付受領など）偽装検知、添付/URL 対策、調査ログ
C送受信（チケット化、ワークフロー連携など）上記の両方＋権限/連携の境界
D本文/添付の保存（監査、証跡、検索）保管の権限・改ざん耐性・保持期間

Step 1. データとリスクを洗い出す（何が守る対象か）​

メールで扱う「情報（データ）」を粒度を落として列挙します。

  • 宛先（To/Cc/Bcc）
  • 差出人（From、Return-Path 等）
  • 件名／本文（個人情報・機密情報の有無）
  • 添付（機密度が一段上がりやすい）
  • メールヘッダ（トレース情報、認証結果）
  • ログ／保管データ（メールそのもの、送信履歴）

次に「起きて困ること（リスク）」を言語化します。

  • なりすましで社名・ドメインを悪用される（ブランド毀損）
  • フィッシングで利用者が被害に遭う
  • 誤送信／宛先ミスで情報漏えい
  • 添付マルウェアで社内侵入
  • メール基盤が踏み台化して大量送信される（レピュテーション悪化）
  • 監査／調査の証跡が残らず、原因追跡できない

Step 2. 信頼境界と責任分界を確定する（どこまで自分の範囲か）​

メールは外部事業者・外部環境が絡みます。境界（信頼境界）を明確にします。

  • 自社システム（アプリ／バッチ／送信ロジック）
  • 送信サービス（例：SES、SendGrid など）
  • 受信ゲートウェイ（MTA、クラウドメール、メールセキュリティ製品）
  • エンドユーザのメーラ（Outlook、Gmail 等）
  • DNS（SPF/DKIM/DMARC は DNS に依存）123

これを決めると、次が決まります。

  • 「どの設定を誰がやるか（RACI）」
  • 障害／事故時に「どこから切り分けるか」
  • 監査のときに「誰の証跡を見ればよいか」

Step 3. 機能要件をセキュリティ観点で分解する（脅威ごとに）​

メール要件を、脅威に対応する観点へ分解すると漏れにくくなります。

  1. 送信元の正当性（なりすまし対策）
  2. 受信時の検証（偽装メールを見抜く）
  3. 内容の安全性（添付／URL、マルウェア）
  4. 宛先と誤送信（人為ミス対策）
  5. 通信の保護（暗号化）
  6. アカウント／権限（誰が送れるか）
  7. 監視と証跡（ログ、監査）
  8. 可用性と悪用対策（大量送信、DoS、スパム）

この分解を Step 0 のユースケース（A〜D）に当てはめ、必要な項目だけを確定させます。

Step 4. 必須／推奨／将来にランク付けして合意する​

要件定義では、最初から完璧にしない判断もあります。だからこそ、優先度を明示します。

  • 必須（リリースゲート）
  • 推奨（短期改善）
  • 将来（ロードマップ）

例：DMARC をいきなり reject にせず、まず可視化（レポート受領）から入る。43

Step 5. 受入条件（テスト観点）に落とす​

「設定したつもり」を防ぐには、要件の時点で「どう確認するか」まで書きます。

  • SPF／DKIM／DMARC が期待どおり評価されること（外部から検証）123
  • DMARC 集計レポート（rua）を受領し、解析できること34
  • 添付がブロック／隔離され、例外フローが回ること
  • 誤送信対策（警告・承認・ディレイ送信等）が運用で機能すること
  • ログから追跡（誰が／どこへ／何を）ができること

セキュリティ対策の内容（要件のひな形）​

以下は「要件として書ける形」を意識したテンプレです（括弧内は非専門向け補足）。

A) 送信側の送信ドメイン保護要件（なりすまし対策）​

狙い：自社ドメインを名乗る偽メールを減らす。

要件例​

  • SPF レコードを設定する（このドメインから送って良い送信元を DNS で宣言）1
  • 送信メールに DKIM 署名を付与する（改ざん検知と責任主体の主張に利用）2
  • DMARC を設定する（SPF/DKIM の結果と From 整合を条件に、受信側へ扱い方を宣言）35
  • DMARC ポリシー（p=none/quarantine/reject）を定義し、段階的に強化する計画を持つ34
  • DMARC 集計レポート（rua）を受領し、定期的に送信元棚卸しを行う34

注意点（事故を減らす書き方）​

  • SPF は転送で成立しないケースがあるため、DKIM 併用を前提とする12
  • 「From の整合（alignment）を満たす」ことを要件化する（DMARC の中核）35

B) 受信側の偽装メール検知要件​

狙い：利用者が騙される確率を下げる。

  • 受信時に SPF/DKIM/DMARC の評価結果を判定できること123
  • DMARC 失敗時の扱い（拒否／隔離／注意表示）を定義する3
  • なりすましが多いドメイン／自社ブランドに対する保護ルールを持つ（例：類似ドメイン対策、表示名ポリシー）
  • 認証結果が含まれるヘッダ情報をログとして保持する（調査・証跡）3

C) 内容の安全性（添付／URL／マルウェア）​

狙い：受信メールを入口とした侵入を減らす。

  • 添付ファイルをウイルススキャンする（隔離・破棄・通知ルール含む）
  • 危険な拡張子／実行形式／マクロ付き文書の扱い（拒否／隔離）を定義する
  • URL の評価（フィッシング／マルウェア）を行う（URL 書き換え、クリック時検査等）
  • サンドボックス（隔離環境）解析の要否を定義する
  • 隔離／ブロック時の通知と、例外申請（業務都合の解除）フローを定義する

D) 誤送信対策（宛先ミス／情報漏えい）​

狙い：人為ミスを前提に、漏えいを起こしにくくする。

  • Bcc 強制、外部ドメイン宛の警告、承認フロー等のルールを定義する
  • 機密ラベル（社外秘等）に応じて外部送信を制御できること
  • 添付の自動暗号化／ダウンロードリンク化の要否を定義する
  • 宛先候補の制御（オートコンプリート制限等）の要否を定義する
  • 送信取り消し猶予（ディレイ送信）の要否を定義する

補足​

ここは技術というより運用設計が支配的です。要件定義で決めないと、現場は後で揉めます。

E) 通信の保護（暗号化）​

狙い：盗聴・改ざんの難易度を上げる。

  • SMTP 通信を TLS で暗号化する（STARTTLS 等）6
  • 受信側・中継でも TLS を必須化するか（強制範囲）を定義する7
  • メール本文そのものの暗号化（S/MIME、OpenPGP 等）が必要かを要件化する（必要なら鍵配布・管理が主タスク）89

F) アカウント／権限​

狙い：送信機能の悪用（踏み台化）を防ぐ。

  • 送信 API キー／SMTP 資格情報の保管は秘密情報管理に統一する（リポジトリ直置き禁止等）
  • 送信権限を最小化する（システムごとにキー分離、環境分離）
  • 送信上限（レート制限）を設ける（誤作動・大量送信の抑止）
  • テンプレート／差出人表示名の変更権限を制御する（フィッシング誘発を防ぐ）

G) 監視・証跡（ログ／監査）​

狙い：事故時に追えること、平時に異常に気づけること。

  • 送信ログ（いつ／誰が／どの宛先へ／どのテンプレートで）を保持する
  • 受信側は認証評価結果（SPF/DKIM/DMARC）と隔離／ブロック理由を記録する3
  • ログの保管期間、参照権限、改ざん耐性（監査で否認されない形）を定義する
  • 異常検知（大量送信、バウンス急増、DMARC 失敗急増）をアラート化する4

H) 可用性と悪用対策​

狙い：止まらない、悪用されない。

  • 送信失敗時のリトライ方針、重複送信防止、キュー上限を定義する
  • バウンス／苦情（complaint）処理を設計する（送信停止リスト等）
  • ブラックリスト入りを防ぐ運用（送信品質）を定義する4
  • BCP 観点で、送信サービス障害時の代替手段の要否を定義する

要件定義で使える最小チェックリスト​

最低限これを埋めると、大事故が減ります。

  1. 送信か受信か、両方か（Step 0）
  2. 扱う情報の機密度（本文／添付）
  3. 送信ドメイン対策：SPF、DKIM 署名、DMARC（p= とレポート運用）123
  4. 受信側の評価：SPF/DKIM/DMARC の扱い（拒否／隔離／警告）3
  5. 添付／URL 対策（スキャン、隔離）
  6. 誤送信対策（警告、承認、暗号化／リンク化）
  7. 認証情報管理と送信権限（キー分離、レート制限）
  8. ログと保管（監査、アラート、保管期間）
  9. 受入条件（どうテストするか）

要件の書き方のまとめ​

  • 「SPF/DKIM/DMARC を導入する」ではなく、合格条件／失敗時の扱い／誰がレポートを見て改善するかまで書く34
  • 設定要件と運用要件を分けて書く（例：DMARC は設定だけでは価値が出にくい）3
  • 責任分界（DNS、メール基盤、アプリ）を明確にする（事故時に揉めない）

参考資料（出典）​

Footnotes​

  1. IETF, RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1（2014）。SPF の仕組み（MAIL FROM/HELO に基づく送信元認可）と評価結果の扱いを定義。https://datatracker.ietf.org/doc/html/rfc7208 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. IETF, RFC 6376: DomainKeys Identified Mail (DKIM) Signatures（2011）。DKIM 署名による改ざん検知と署名ドメインの責任主体主張の仕組みを定義。https://datatracker.ietf.org/doc/html/rfc6376 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  3. IETF, RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)（2015）。SPF/DKIM の結果と From 整合（alignment）に基づくポリシー宣言とレポーティング（rua 等）を定義。https://datatracker.ietf.org/doc/html/rfc7489 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16

  4. M3AAWG, Email Authentication Recommended Best Practices（PDF, 2020/09）。DMARC の段階的強化（p=none 等は移行状態）や rua 運用、reject/quarantine 推奨などの実務的ベストプラクティスを提示。https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  5. JPNIC, インターネット用語1分解説～DMARCとは～（2018/02/15）。DMARC の位置づけ（SPF/DKIM と組み合わせた送信ドメイン認証）を平易に解説。https://www.nic.ad.jp/ja/basics/terms/dmarc.html ↩ ↩2

  6. IETF, RFC 3207: SMTP Service Extension for Secure SMTP over TLS（2002）。SMTP における STARTTLS 拡張仕様を定義。https://datatracker.ietf.org/doc/rfc3207/ ↩

  7. IETF, RFC 8314: Cleartext Considered Obsolete: Use of TLS for Email Submission and Access（2018）。メール送信/アクセス系プロトコルでの TLS 利用推奨（平文廃止の方向性）を整理。https://datatracker.ietf.org/doc/html/rfc8314 ↩

  8. IETF, RFC 8551: S/MIME Version 4.0 Message Specification（2019）。S/MIME による署名・暗号化（機密性/完全性等）の枠組みを定義。https://datatracker.ietf.org/doc/html/rfc8551 ↩

  9. IETF, RFC 4880: OpenPGP Message Format（2007）。OpenPGP のメッセージ形式（暗号化・署名）を定義。https://datatracker.ietf.org/doc/html/rfc4880 ↩

に最終更新