アプリメールのリレー制御を取り戻す

先日、プルーフポイントは、Proofpoint Email Fraud Defenseを利用している325の顧客のDMARCデータを評価し、送信に使用されているソースを調べました。これらの顧客のドメインから送信されているメールのソースは、平均して以下のような割合でした。

• アプリケーション/システム (42%)
• マーケティング (57%)
• エンドユーザー (1%)

送信メールの42%をアプリケーションが占めていることから、メッセージング/セキュリティ チームの業務はこれらに向けられています。アプリケーション生成メッセージのうち、組織のドメインからどれを送信してどれを送信しないかは、従来はオンプレミスのSMTPリレーで制御できました。この制御があることで、メールにおけるブランド アイデンティティを簡単に保護できました。それができなければ、組織の評判と機密データは危険にさらされます。それに、受信者が詐欺に遭うおそれがあります。

しかし、アプリケーションが進化している中で、チームはこの制御の維持に苦労しています。メッセージングまたはセキュリティの担当者として、アプリケーションのモダナイゼーションと、これが組織のメール アイデンティティの制御を維持できる能力にどう影響するかについて懸念を抱いているのなら、それはあなただけではありません。

このブログ記事では、メールリレーの制御がどう変化しているのかを説明します。また、組織を保護するために制御を取り戻す方法についても触れます。

 

かつてはこの制御で保護

これまでは、チームは以下の制御を実装して維持することで、アプリケーション生成メッセージを管理してきました。

DMARC「拒否」ポリシー：これにより、攻撃者によるドメイン「なりすまし」を防ぎます。

アウトバウンド フィルタ：このフィルタは、迷惑メール、マルウェア、あるいは機密データが、故意あるいは偶発的に送信されるのを防ぎます。

アクセス制御による制限：この制限を用いて、SMTPリレーを使用できるアプリケーションやシステムを制御します。

オンプレミスのソリューションを用いた従来のリレー

アプリケーションのモダナイゼーションがメール アイデンティティにリスクをもたらした仕組みとして、以下の3つが挙げられます。

 

1: クラウドへの移行：

オンプレミスのアプリケーションは、クラウド環境へ移行しています。しかし、クラウドでは、セキュアなSMTPリレーオプションは使用できません。

理論上は、従来のオンプレミスのSMTPリレーにより、DMARCとアウトバウンド フィルタリングを維持できます。しかし、外部クラウド環境からメールをリレーさせるのは危険です。本来はオープンリレーではないものがオープンリレー化するからです。

オンプレミスのリレーを外部環境にさらすのは高リスク

 

2: メール サービスプロバイダー（ESP）

メールサービスプロバイダー（ESP）は、確かにDMARC準拠のメールを送信します。しかし、この場合、顧客は、SPFレコード経由で広く共有されているインフラを承認する必要があります。残念ながら、SPFレコードは、攻撃者にも見えてしまっています。また、多くの場合セキュアでなく、アウトバウンド フィルタリングもありません。

ESPは、セキュリティではなく、配信率を重視しています。

 

3: SaaS

SaaSアプリケーションはサードパーティ ベンダーにアウトソーシングされています。ESPにとって、メールセキュリティが最優先事項でないのと同様、こうしたベンダーのほとんどが製品開発と差別化に注力しているためです。

• SaaSプロバイダーは多くの場合、DMARC準拠のメールを送信できません。そのため、DMARC「拒否」ポリシーの実装と維持は簡単ではありません。
• ESPの場合と同様、このシナリオの場合、SPFレコードでセキュアでないインフラの承認が必要となります。

SaaSプロバイダーは、メールではなく製品開発に注力しています

 

Proofpoint SERが制御を提供

非常に多くの課題があることから、メッセージング/セキュリティ チームがアプリケーション メールの制御を取り戻すことは、難しい注文です。しかし、プルーフポイントは、Proofpoint SER (Secure Email Relay)でこれを実現しました。SERは以下のような側面で今日の課題を解決します。

 

モダナイゼーションされたリレー

リレー経由でのアプリケーション メールの制御の原則は、必ずしも変わってはいません。ただし、リレーの導入方法・管理方法は変わりました。

構造の観点から見ると、アプリケーションの先進化と乱立に対応する最適な方法は、「ハブ アンド スポーク（hub and spoke)」モデルです。中心や拠点となる場所は以下のとおりです。

• すべてのメールは、ソース環境にかかわらず、「ハブ」を通過します。これは、メールのフィルタリング、ポリシーの適用、ペイロードの暗号化、その他の機能が使用される中心地です。
• 「スポーク」は、メールをさまざまな環境からメインの「ハブ」に送信するオプションの経路です。例えば、軽量のネットワーク内「スポーク」は、数百または数千のアプリケーションからメールを収集できます。続いて、顧客のネットワークと「ハブ」を往来する仕組みを正規化できます。または、Amazon Simple Email Service (SES)は、「スポーク」として、SES Mail Managerを使用して条件に従って、メールを「ハブ」にルーティングすることができます。

セキュリティ

一般的に、モダナイゼーションについて語るとき、よりセキュアになることを想像します。しかし、メールリレーに当てはまる、いくつかの側面を見てみましょう。

• ソリューションの開発と導入プロセスは、最新のセキュリティ規格とベストプラクティスに準拠している必要があります。例えば、Proofpoint SERは、モノリシックなメールサーバーではなく、マイクロサービスを使用してクラウドで構築されています。マイクロサービスのアーキテクチャを採用することで、攻撃対象領域を狭くしながら、目的に合った設計の小型システムを構築できます。また、マイクロサービスは、先進的なCI/CDシステムを使用しています。そのため、ダウンタイムなく、またはごくわずかで、迅速にセキュリティパッチを適用したり変更をデプロイしたりできます。
• このソリューションで処理されるメールは、エンドツーエンドで暗号化する必要があります。インバウンドの接続レベルでは、厳格な認証がアプリケーションに必要です（TLS 1.2。推奨されるのはそれ以上）。
• ソリューションには、迷惑メール（「AS」）やマルウェア（「AV」）のフィルタリングなどのセキュリティ機能が必要です。また、機密情報を保護し、情報漏えい対策 （DLP）機能を導入する必要もあります。システムからインターネットに送信されるメールは、6か月ごとに変更される、2048ビットの鍵でDKIM署名する必要があります。DKIM2が今後どのように展開していくかもご覧ください。

 

サービス

人的要素を避ける術はありません。オンプレミスのリレーをやめる場合は特にそうです。こうしたシステムは多くの場合、さまざまなメールをアクティブに処理しています。これには以下が含まれます。

• 数百（ないし数千）のアプリケーションのメール：移行戦略に応じて、こうしたアプリケーションのオーナーに確認し、移行プロセスにおいてサポートが必要になる場合があります。
• パスワードリセットやMFAコードなどのミッションクリティカルなメール：一部のアプリは、処理や移行のタイミングにおいて優先する必要があります。

Proofpoint SERの「ハブ アンド スポーク」アーキテクチャ

 

プルーフポイントでメールの保護を向上

Proofpoint SERにより、組織は、組織を代表してメールを送信する、すべてのアプリケーションやサードパーティSaaSパートナーの管理を向上させることができます。Proofpoint SERにより、これらのソースのいずれかが侵害されても、即座に停止させることができます。これは、これまでは制御外でありながらも、ブランドに重大な損害をもたらしうるサードパーティ アプリケーションに対し非常に重要です。

そのため、オンプレミスのリレーの廃止、DKIMを用いたセキュリティの向上、またはすべてのアプリケーション メールの制御向上を計画している組織にとって、Proofpoint SERはおすすめのソリューションです。

 

詳細について

ショート動画またはProofpoint Secure Email Relay製品ページをご覧ください。また、プルーフポイントの営業担当者までお問い合わせください。Proofpoint SERが組織にとってふさわしいツールであるかご案内させていただきます。