Email security デプロイの理解

メールは、人と組織をつなぐ業務上不可欠な通信手段です。同時に、アカウント乗っ取り、データ窃取、内部システムへの侵入を狙う攻撃者にとっても都合のよい経路です。スパムを減らし、フィッシングとマルウェア攻撃を防ぐことは、組織のセキュリティに欠かせません。サイバーセキュリティインシデントの 90% 以上は、メール攻撃から始まります。

Cloudflare Email security は、組織ごとのニーズに合わせて複数の方法で導入できるソリューションです。この文書では、Email security の導入方法と、各モデルを選ぶ理由を説明します。

メールは、規模を問わずビジネスの重要な通信チャネルです。一方で、フィッシング、スパム、マルウェアなど、サイバー攻撃の主要な標的にもなります。組織の機密データと信頼を守るには、堅牢なメールセキュリティが必要です。

Cloudflare Email security は、幅広い脅威からメール基盤を守るためのツールと技術を提供します。導入すると、メール経由の攻撃に対するセキュリティ態勢を強化し、リスクを下げられます。

このリファレンスアーキテクチャでは、Cloudflare Email security のデプロイと設定の進め方を詳しく説明します。既存の IT 基盤へスムーズに組み込むための主要コンポーネントと推奨事項を扱います。

このリファレンスアーキテクチャは、Cloudflare で事業の一部を保護したい IT / セキュリティ担当者向けです。次のような幅広い読者を想定しています。

• IT セキュリティ担当者: Email security ソリューションの設計、導入、運用を担うセキュリティエンジニア、アーキテクト、管理者。
• ネットワークエンジニア: ネットワーク基盤とメールゲートウェイを管理するネットワークエンジニア。
• クラウドアーキテクト: クラウド上の Email security ソリューションを設計・導入するクラウドアーキテクト。
• セキュリティ / IT の意思決定者: Email security の技術面を理解し、判断するマネージャーと経営層。

Email security の経験の有無にかかわらず、Cloudflare Email security を効果的に導入・運用するための情報を得られます。

Cloudflare の理解を深めるには、次の資料を推奨します。

• Cloudflare とは？ | Web サイト ↗（5 分の読み物）または 動画 ↗（2 分）
• Cloudflare Blog ↗ | Email security ↗ と Phishing ↗
• CISA | Phishing Guidance: Stopping the Attack Cycle at Phase One ↗

このリファレンスアーキテクチャを読み終えると、Cloudflare がメールをどう保護するか、どのデプロイを選ぶべきかがわかります。Cloudflare Email security のコンポーネント、技術、設定と、既存のメール基盤への統合、クラウドサービスの活用方法も学べます。

Cloudflare Email security は、フィッシング攻撃への現代的なアプローチです。AI と機械学習、弾性のあるサービス、Cloudflare の広範な脅威インテリジェンスネットワークを基盤にしています。Cloudflare Email security は、共有インテリジェンスと Supervised ML ↗ を備えた、メール向けに使えるデプロイ方法すべてに対応する Cloud Elastic Service として設計されています。ただし、効果を最大化するには、適切なデプロイモデルの選択が重要です。

この文書では、次の導入方法と、それぞれを使う場面を説明します。

• Inline または MX
• Microsoft 365 API 連携
• auto-move 付きの Journaling または BCC
• 混合デプロイ

デプロイを選ぶ前に、必要なことと望ましい体験を整理します。主たるフィッシング対策として使う場合の推奨は、MX デプロイです。主な理由は次のとおりです。

• 配信前 の対処では、件名 / 本文への追記、Cloudflare Remote Browser Isolation への URL Rewriting、迷惑メールフォルダーや下流のメール検疫への配信など、メッセージの届け方を調整できます。想定するユーザー体験に合わせて設計できます。
• ServiceNow やアーカイブソリューションなど、メールを取り込むシステムが消費する前に、メッセージを除去できます。
• 受信トレイへの配信と、受信トレイからの移動の間に時間差が出る滞留時間（dwell time）のリスクをなくせます。
• Microsoft 365 と Microsoft Exchange、Microsoft 365 と Google Workspace など、混合デプロイに対応できます。

これらの要件が重要でない場合、または API ベースではない多層防御を使っている場合は、メールフローを変えずに素早く導入できる API 方式が向いています。API の利点を得つつ API Throttling のリスクを避けたい場合は、取り込みに API 呼び出しを使わない Journal/BCC が最適です。MX デプロイの保護に加え、内部メール向けの API の利点も欲しい場合は、混合デプロイが適しています。

ニーズが変わっても、再購入せずにデプロイ方法を切り替えられます。例外は、Advantage と CyberSafe のお客様が Inline デプロイに限られる点です。Enterprise ライセンスではすべての機能を使えます。

特定のデプロイに決める前に、すべての選択肢を確認し、要件を比較し、必要に応じてアカウントチームに相談してください。

Inline デプロイでは、1 つ以上のドメイン宛てのメールがすべて、ユーザーの受信トレイに届く前に Cloudflare を通ります。Cloudflare は、メール処理チェーンの任意の位置に置けます。最初の ホップ として置く場合は、ドメインの DNS MX レコードを Cloudflare に向けます。既存の SEG（Secure Email Gateway）のあとで検査したい場合は、処理チェーンの 1 ホップとして挿入し、処理済みメッセージを次のホップへ転送します。ポリシーに応じて、Spam、Malicious、Bulk などと判定されたメッセージをブロックまたは隔離します。

上の図は次の流れです。

1. MX レコード ↗ に基づき、メールが Cloudflare に届きます。
2. Cloudflare はメール本文、ヘッダー、添付ファイルを検査し、適切な判定（disposition）を付けます。
   • Malicious
   • Spam
   • Bulk
   • Suspicious
   • Spoof
   • Clean
3. 特定ドメインの許可やブロックなど、ポリシーを適用します。
4. 高リスクのメールを隔離します。
5. Cloudflare が 判定 を付けたメッセージには、ヘッダー X-CFEmailSecurity-Disposition が追加されます。下流システムはこのヘッダーで、再ルーティングや外部隔離などの特別な処理を行えます。
6. 有効なメールトラフィックをすべて転送します。
7. 件名や本文を変更し、判定についてエンドユーザーに見える情報を追加できます。

セキュリティの観点では、Inline デプロイが推奨です。すべてのメールをスキャンし、悪意のある内容がユーザーの受信トレイに届く前に止められるため、ユーザーへの露出リスクがなくなります。

• メッセージは処理され、ユーザーのメールボックスに届く前にブロックされます。
• 件名に [SPAM] や [EXTERNAL SPAM] を付けるなど、メッセージを変更できます。
• 高可用性と適応型メッセージプーリングを提供します。下流サービスが利用できないときも、Cloudflare は受信メールをキューで受け付け続けます。下流が復旧すると、キューからの配信を再開します。
• 隔離されない 判定 付きメッセージには、下流での高度な処理に使える X-header が付きます。
• Microsoft Exchange On-Prem、Postfix、Lotus Notes、Google Workspace、Microsoft 365 など、すべてのメールシステムと互換です。

Inline デプロイで Email security を導入する前に、次を検討します。

1. メールが先に Microsoft Exchange または Microsoft 365 に入り、メールフロールールで Email security へ送ってスキャン / 対処したあと、再び Microsoft 365 に戻すリダイレクト構成は、Microsoft がサポートしていません。Cloudflare はこの構成を技術的には実現できますが、帰属（元の送信者の認識）と配信の問題が起きます。
2. Cloudflare を MX にする場合は DNS の変更が必要です。ドメインが多い場合は、各 DNS ゾーンを更新します。
3. Cloudflare を MX にせず、従来の SEG（Mimecast / Proofpoint）の後ろに Inline で置くと、SMTP 構成が複雑になることがあります。
4. Inline デプロイでは、複数のソリューションと MTA でポリシーを重複させる必要がある場合があります。たとえば、Cloudflare、SEG、MTA は許可ポリシーの扱いが大きく異なり、同じメッセージに対してそれぞれ例外処理が必要になることがあります。
5. 多層デプロイでは、Mimecast や Barracuda のように MX としてしか動作できないベンダーがあります。この場合は、それらのベンダーの後ろに Cloudflare Inline を置きます。
6. Mimecast を使う場合は、URL Rewriting を無効にすることを推奨します。有効だと Cloudflare が URL をデコードしてクロールできません。この機能を残すと、リンク追跡はドメインのレピュテーションと経過期間に限られます。

Cisco には、コネクタを MX として使う、または Cloudflare の後ろに置いてサポート対象の Hairpin デプロイとする独自の連携があります。このデプロイは、ほかの点では Inline と同じです。Cisco as MX Record と Cisco - Email security as MX Record を参照してください。

別の方法は、Microsoft 365 の Graph API で連携することです。このモデルでは、メールはユーザーの受信トレイに直接届き、Cloudflare がメッセージのコピーを受け取ってスキャンし、判定 に応じて移動します。

認可済みドメイン上のすべてのユーザーメールボックスをサブスクライブして行います。認可時に、対象を Inbox のみにするか、All Folders にするかを選べます。メールボックスへの配信後、サブスクリプションが Microsoft 365 内のアクションを起動し、スキャンと判定のためにメールのコピーを Cloudflare へ送ります。判定が付くと、auto-move ポリシーを参照して目的の操作を実行します。

上の図は次の流れです。

1. 既存の経路で、メールがユーザーの受信トレイに直接届きます。
2. Cloudflare はメールベンダーの API で検査対象メッセージを取得します。本文、ヘッダー、添付ファイルを検査し、適切な判定を付けます。
   • Malicious
   • Spam
   • Bulk
   • Suspicious
   • Spoof
   • Clean
3. 特定ドメインの許可やブロックなど、ポリシーを適用します。
4. Cloudflare のポリシーに従ってメッセージを移動します。次の操作が使えます。
   • Inbox
   • Junk
   • Trash
   • Soft Delete（ユーザーが復元可能）
   • Hard Delete（管理者が復元可能）

通常、受信トレイへの配信から移動リクエストまで 2〜3 秒未満です。操作の所要時間について、Google や Microsoft 365 の SLA はありません。移動が失敗した場合、ソリューションは 5 分ごとに何度も再試行します。

• 複雑なメール構成でも、メールフローを変えずに保護を追加しやすいです。
• Microsoft 365 ではエージェントレスで導入できます。
• Microsoft 365 Defender / ATP が先にメッセージを処理します。
• メールフローを変えずにメールを収集・レポートする価値検証（Proof of Value）に使えます。この場合は、対処が行われないよう remediation ポリシーを未設定のままにします。

API デプロイ で Email security を導入する前に、次を検討します。

• API 基盤の都合で、Microsoft 365 または Google の障害やメンテナンス中は、配信後までスキャンや対処ができず、受信トレイ内の滞留時間が延びます。これは API ベンダー共通の制約です。
• Microsoft 365 は、サービスごとに Graph API へのリクエストをスロットルすることがあります。Graph の Mail API は Outlook Services に含まれます。脅威アクターがこの上限を悪用すると、API ベースのデプロイを事実上無効化し、攻撃の時間窓を広げられます。上限は次のとおりです。
  • 10 分間に 10,000 API リクエスト
  • 同時リクエスト 4 件
  • 5 分間に 150 メガバイト（MB）のアップロード（PATCH、POST、PUT）
  • Outlook service limits ↗ を参照してください
• Gmail API には、アプリケーションからの全リクエストに適用される日次利用上限と、ユーザーごとのレート制限があります。各上限は quota units（Gmail リソース使用量を表す抽象単位）で識別されます。主なリクエスト上限は次のとおりです。
  • ユーザーあたり 1 秒 250 quota units のレート制限（移動平均。短いバーストは許容）
  • メソッドごとの Quota Usage は、呼び出したメソッドに応じて消費する quota units 数で決まります。
  • たとえば、messages.get と messages.attachments.get は 5 quota units を消費します。Per-method quota usage ↗ を参照してください
• メールボックスへの読み取り / 書き込みアクセスが必要です。セキュリティ / メールチームが許可しない場合があります。
• 真の API 対応は Microsoft 365 だけです。Google は API での対処が可能ですが、スキャン用に SMTP でメールを届ける Compliance Rule が必要です。オンプレミスの Exchange は PowerShell が必要で、auto-move 用の API はありません。
• Microsoft 365 / Google の要件により、配信後にメッセージを変更できません。そのため、Cloudflare email link isolation への URL Rewriting や、件名 / 本文へのテキスト追記はできません。これらの機能は Inline デプロイでのみ使えます。

BCC/Journaling は API デプロイとよく似ていますが、Cloudflare へのメールの届け方が異なります。API と同様にメールは先にメールボックスへ届きますが、同時にアカウント固有のメールアドレスが追加され、評価用のコピーが SMTP で Cloudflare に送られます。

Cloudflare はメールを受信するとスキャンし、判定 を決めます。判定が付くと、API 認可と auto-move ポリシーを参照して目的の操作を実行します。Microsoft 365 と Google の API は対処にだけ使うため、API Throttling のリスクは低くなります。

価値検証では、BCC 受信者を追加できる任意の Email security ソリューションやメール基盤でこのデプロイを設定し、それらのソリューションが見逃して Cloudflare ならブロックする内容を確認できます。

• 複雑なメール構成でも、メールフローを変えずに保護を追加しやすいです。
• Microsoft 365 ではエージェントレスで導入できます。Microsoft 365 は配信後にメールを Cloudflare へ送り、API Authorization に Remediation ポリシーを設定すると、判定付きメールを受信トレイから移動できます。
• Google は BCC に Compliance Rules を使い、API Authorization と組み合わせて配信後にメールを移動できます。結果は上記の API デプロイと同じです。
• Microsoft 365 と Google が先にメッセージを処理します。Microsoft 365 / Google のセキュリティ機能と Cloudflare を重ねた多層防御になります。
• 検査対象の範囲（外部、内部、または両方）を制御できます。
• メールフローを変えずにメールを収集・レポートする価値検証に使えます。API Authorization は必須ではありません。Microsoft 365 または Google 向けに API を設定した場合は、対処が行われないよう Remediation ポリシーを未設定のままにします。

BCC/Journaling デプロイで Email security を導入する前に、次を検討します。

• API と同じ制約があります。
• Google または Microsoft 365 が SMTP でメッセージを届ける必要があります。
• 直接通信のために、Microsoft 365 で Connector が必要になる場合があります。
• Microsoft 365 / Google の要件により、配信後にメッセージを変更できません。そのため、Cloudflare Email Link Isolation への URL Rewriting や、件名 / 本文へのテキスト追記はできません。これらの機能は Inline デプロイでのみ使えます。

混合デプロイは、外部メールに Inline、内部メールに BCC/Journaling を使います。両方の方法を使い、BCC/Journal モードで Cloudflare を 2 ホップに設定します。外部メッセージには MX 配信の利点をすべて得つつ、内部からの不正メールも対処できます。役立つ場面は次のとおりです。

混合デプロイは、外部メール向け Inline の利点と、内部メール向け BCC/Journaling の利点を組み合わせます。

混合デプロイを選ぶときは、次を検討します。

• 内部メールの検出は、Email Authentication、送信サーバー、配信経路などの情報がないため制限されます。分析できるのはメール本文の内容だけです。
• なりすましレジストリでユーザーを保護している場合、内部メールでは誤検知が増えることがあります。

Cloudflare は、継続的な分析と提出に基づく自動ワークフローを提供します。これらの機能により、配信後に API の auto-move ポリシーでメッセージを移動できます。フィッシング提出やサードパーティのユーザー提出との組み合わせが適しています。

Cloudflare は、誤検知と見逃しについて、Cloudflare ダッシュボード経由の管理者提出を優先します。レビューが早くなり、複数ユーザーに影響しうる問題を先回りして修正し、製品体験を改善できます。管理者はユーザー提出を確認し、関連メッセージをすべて特定したうえで、確認済みの誤検知 / 見逃しとして Cloudflare ダッシュボードから提出することを推奨します。これらの提出はレビューされ、今後の機械学習モデル、検出、エンジンの改善に使われます。

まとめると、Email security には 3 つの中核デプロイモデルがあります。API、BCC/Journaling、Inline（または MX）です。推奨は Inline です。悪意のあるメッセージをユーザーの受信トレイに届く前にフィルタして対処し、滞留時間のリスクをなくし、URL Rewriting やメッセージ変更などの機能も使えます。

API と BCC/Journaling は配信後のソリューションです。Microsoft 365 や Google Workspace と連携し、ユーザーのメールボックスに届いたあとで検査し、auto-move します。これらの配信後方式は導入が容易でメールフローの変更は不要ですが、API Throttling のリスクや、件名や本文などのメッセージ内容を変更できない制約があります。

最後に、混合デプロイは、外部メール保護（CRM やチケットシステムなど、メールを取り込むシステムに重要）向けの Inline と、内部メール評価向けの BCC/Journaling を組み合わせます。