dmarcianのシニアデプロイメントマネージャーであるFred Bianchiが、SPFレコードの安全性を低下させる、よくある間違いについて語ります。
DMARC導入のスペシャリストとして、私たちは世界中のさまざまな規模や構造の組織に遭遇します。私たちが学んだことの一つは、組織の電子メールの健全性を判断する最も手っ取り早い方法は、SPFレコードから始めることだということです。というのも、SPFは一般的に管理が誤っており、詳細が誤解されているからです。
SPFを表面的にしか理解していない組織は珍しくなく、その結果、レコードに不必要なものが含まれてしまったり、乱雑になってしまったりすることがあります。私は、SPFの導入に成功した多くの組織を見てきたが、今後、SPFレコードにルックアップを追加するという内部リクエストに関しては、あまり考慮されていない。
組織が組織的に成長するにつれて、メール配信元は不定期に増えていきます。オンライン請求書発行からニュースレター配信開始まで、長いビジネスサイクルがあるかもしれません。また、ニュースレターベンダーの変更などサービスの変更に伴い、DNSの衛生面を考慮した正式な社内「オフボーディング」プロセスが存在しないこともよくあります。また、今後プロセスを採用する組織であっても、既存のルックアップは一般的に評価されないため、記録されたまま未使用のままとなります。
SPFの乱雑さの危険性
SPFの乱雑さは、使われなくなったサービスのインクルードだけでなく、不要なトップレベルドメインのインクルードにもなり得る。多くの人は、あるエンティティが自分の代わりに送信するのであれば、SPFレコードに含めるべきだと理解している。しかし、SPF認証の際に評価されるのは、使用されているリターンパス・ドメインなのだ。
例えば、ある組織がSendGridを使用して、newsletter.domain.comのようなサブドメイン経由で送信している場合、SendGrid自体がトップレベルドメイン（domain.com）のSPF includeステートメントに含まれていることがわかります。この場合、トップレベルドメインのSPFインクルードステートメントに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）を展開すると、マトリョーシカ人形（一般的にはロシアの入れ子人形として知られている）のように、その中にさらにインクルード文が存在することが判明する。その結果、全く関係のないinclude文やネットブロックが発見されることもあります。このようなシナリオは、潜在的に、そしておそらく知らず知らずのうちに、SPFレコードに追加のサービスやIPアドレスを追加することになります。
ネストされたインクルードの例を、bluehost.comで以下に示す。このドメインをSPFサーベイヤーにかけると、実際には13のユニークなルックアップが含まれていることがわかります。
SPF記録を点検・確認するには、無料のSPFサーベイヤーをご利用ください。
私たちがお手伝いします
Brandkeeperでは、メールセキュリティの専門家チームによるDMARCの導入から運用サポート及びコンサルテーション行っています。一旦はDMARCの導入をやってみたが運用を断念したお客様、または、導入時点でいくつものハードルであきらめた企業様のサポートも行っています。
お気軽にご連絡ください
