SPFの落とし穴：不要なデータがセキュリティ対策の足かせになる
SPFはメールドメインのセキュリティを確保するための強力なツールですが、誤解されがちです。dmarcianの米国事業担当ディレクター、フレッド・ビアンキ氏が、混乱を招き、結果としてセキュリティが不十分なSPFレコードにつながるよくある間違いについて解説します。
DMARC導入の専門家として、私たちは世界中のさまざまな規模や組織構造を持つ企業と接してきました。その中で学んだことの一つは、組織のメール環境の状態を判断する最も手っ取り早い方法は、SPFレコードから確認することだということです。なぜなら、一般的にSPFは管理が不十分であり、その詳細についても誤解されていることが多いからです。
組織がSPFについて表面的な理解しか持っていないことは珍しくなく、その結果、レコードに不要な項目が追加されたり、情報が散らかったりすることがあります。SPFの導入に成功している組織は数多く見てきましたが、その後の運用において、SPFレコードへのルックアップ追加を求める内部からの要望に対して、十分な検討がなされていないケースが少なくありません。
組織が自然に成長するにつれ、新たなメール送信元が散発的に増加していきます。オンライン請求書の導入からニュースレターの配信開始までには、長い期間を要する場合があります。そして、ニュースレターのベンダー変更などサービスの変更が行われる際、DNSの健全性を考慮した正式な内部の「廃止」プロセスが整備されていないことがよくあります。また、今後に向けてそのようなプロセスを導入した組織であっても、既存のルックアップは通常評価されないため、レコードに残ったまま未使用の状態となります。
SPFの過剰使用がもたらす危険性
SPFレコードの冗長化は、使用されなくなったサービスだけでなく、不要なトップレベルドメインの記載によっても引き起こされる可能性があります。多くの人は、ある組織が自組織の名義でメールを送信する場合、その組織をSPFレコードに含めるべきだと理解しています。しかし、これはすべて使用されているリターンパスドメインに基づいており、SPF認証の際にはそのドメインが評価の対象となるからです。
例を挙げましょう。ある組織がSendGridを使用して、newsletter.domain.comのようなサブドメイン経由でメールを送信しているとします。ところが、SendGrid自体がトップレベルドメイン（domain.com）のSPF includeステートメントに含まれていることが判明しました。この場合、トップレベルドメインのSPF includeステートメントにSendGridを含める必要はなく、SPFの冗長化や不要なルックアップの原因となります。
SPFレコードは一般に公開されているため、整理されていないSPFレコードがあると、外部に対して、自社のメールドメインがどのように使用されているかを把握できていない可能性があるという印象を与えてしまいます。 SPFレコードに未使用のルックアップや不要なトップレベルインクルードが多いほど、攻撃対象領域は広がります。これは事実上、何千ものIPアドレスに対して、そのドメインを名乗ってメールを送信することを許可しているのと同じです。それは、ホームセンターに行って自宅の鍵の複製を大量に作らせ、それを無差別に配りまくるようなものです。
情報セキュリティにおいては、「最小権限の原則」という概念があり、これによれば、個人やアプリケーションには、タスクを実行するために必要な最低限の権限のみが付与されます。SPFレコードの管理においても、悪意のある攻撃者による攻撃の機会やリスクを最小限に抑えるため、同様の配慮を行う必要があります。
散らかったものを片付ける
SPFは、管理が不適切であるために不当に悪い評判を得ていると思います。組織を責めるのは難しいでしょう。なぜなら、サードパーティ製のツールを使わなければ、SPFレコードのどの要素が実際に使用されているかを把握するのは困難だからです。メールは送信されるものであるため、検証のために受信先の企業のメールログを確認する以外にネイティブな手段はありませんが、それはせいぜい不可能な作業です。 DMARCの導入と、それによって生成されるレポートにより、インターネット上でドメインがSPF認証に合格している場所や失敗している場所を把握できるようになります。dmarcianのようなサードパーティ製ツールは、生データを可視化し、相関関係を分析する機能を提供します。
前述の通り、ベンダーとの取引関係を終了する際、組織の契約終了プロセスには、SPFレコードを含むDNSの確認作業を含めるべきです。現在、このような方針が確立されていない場合は、SPFレコードの全面的な確認を行い、稼働中のベンダーのみがリストに含まれていることを確認する必要があります。
SPFに関するよくある間違い
- 不要なトップレベルドメインのインクルード
前述のSendGridの例でも触れたように、不要なトップレベルドメインのインクルードは問題となります。リターンパスにトップレベルドメインが含まれることはありますが、ほとんどの場合、ESPプロバイダーはリターンパスにサブドメインを使用するため、そのようなケースは極めて稀です。また、この点は頻繁に確認されるため、改めて強調しておきますが、SPF認証で評価されるのは「from:」ドメインではなく、リターンパス（バウンス）ドメインです。 - 不要なゲートウェイには、
が含まれます。セキュアゲートウェイを使用してメールの送受信を行っている場合、Office 365またはGoogle G Suite向けのSPFインクルードが存在すると、そのいずれかが数十万ものIPアドレスに対して開放された状態になります。 - DNSルックアップの制限や、その計算方法について理解されていない
SPFレコードには「ルックアップ」が10回という厳格な制限がありますが、この制限がどのように適用されるかについては、これまでの経験上、誤解が生じやすい点となっています。
IPアドレス自体は、この検索制限の対象にはなりませんが、「解決」が必要なものはすべて対象となります。SPFレコードに、IPアドレスへの解決が必要なドメインが含まれている場合、それは制限の対象となります。 「a」（Aレコード用）、「mx」（メールエクスチェンジャーレコード用）、および「ptr」（ポインタ照会用）などのメカニズムが含まれる場合も、ルックアップ制限の対象となります。SPFメカニズムに関する詳細はこちらをご覧ください。
もう一つの難点は、「ネストされたインクルード」という概念です。これは、インクルード文（例：include:vendor.com）を展開したところ、その中にさらに別のインクルード文が存在していることが判明する現象で、マトリョーシカ（一般にロシアの入れ子人形として知られる）に似ています。 これにより、全く関係のない他のインクルード文やネットブロックが発見されることがあります。このような状況では、意図せずしてSPFレコードに追加のサービスやIPアドレスが追加されてしまう可能性があります。
ネストされたインクルードの例は、以下のbluehost.comで確認できます。このドメインを当社のSPF Surveyorで解析すると、実際には13件の異なるルックアップが含まれていることがわかります。
SPFレコードを確認・検証するには、当社の無料ツール「SPF Surveyor」をご利用ください。
私たちがお手伝いします
dmarcianは、メールセキュリティの専門家チームを擁し、「ドメインセキュリティを通じてメールとインターネットの信頼性を高める」ことを使命としています。私たちは、組織が保有するドメイン群の現状評価から、DMARCの導入、そして長期的な運用管理に至るまで、手厚くサポートいたします。
この会話を続けたいですか？dmarcianフォーラムへどうぞ。
