ドメインベースのメッセージ認証
今年初め、インターネットセキュリティセンター（CIS）の「 」（）および「20 Critical Security Controls」（ ）（新しいタブで開きます）（）（）に準拠するための全社的な取り組みの一環として、Taniumでは、社内の電子メールに対して、ドメインベースのメッセージ認証・報告・準拠（DMARC）を用いた、より厳格な設定を導入いたしました。 予想通り、スパムメールや のフィッシングメールの数が大幅に減少しました。 しかし、導入の過程では、予期していなかったいくつかの課題にも直面しました。 DMARCの設定を行わない企業も数多くあることを踏まえ、DMARCの概要、導入に伴う一般的な課題、そして導入過程で得た役立つヒントをいくつかご紹介することで、当社の経験を共有することがお役に立てばと考えました。
DMARCでは、Sender Policy Framework（SPF）とDomainKeys Identified Mail（DKIM）という2つの技術を用いて、そのメールが なりすまし （つまり、貴社から送信されたかのように偽装されたもの）であるか、それとも貴社から正当に送信されたものであるかを判断します。 SPFもDKIMも、どこからでも参照可能なパブリックDNSレコードとして公開されています。 これらの制御機能により、受信側のSMTPサーバーは、受信ヘッダーを検証し、その送信元および整合性キーを貴組織が公開しているものと照合した上で、メッセージを配信するか、あるいは隔離するなどの措置を講じるかを判断することができます。 この情報はその後、個別のメールアドレスに報告され、そこで解析や分類を行うことで、異常や問題の有無を確認することができます。
SPFとは、企業が承認済みのSMTP送信元として指定した、完全修飾ドメイン名（FQDN）またはIPアドレスのリストに他なりません。 受信側のSMTPサーバーは、受信メッセージのヘッダーを解析して、送信元のSMTPサーバーを特定することができます。 DKIMは、非対称暗号化を利用した、よりきめ細かな制御手段です。 Taniumは、DNSを介して公開鍵を公開し、それに対応する非公開の秘密鍵を安全に保管しています。 当社に代わって電子メールを送信したい第三者は、公開鍵・秘密鍵のペアを生成するとともに、 および の公開鍵をDNSにも登録する必要があります。
メールが届くと、受信サーバーはメッセージヘッダーから添付されたDKIMキーを取得し、送信元サーバーに照会を行ってその正当性を確認します。 提供されたDKIMキーが送信元サーバーの秘密鍵と一致しない場合、そのメッセージはなりすましとみなされます。 一致した場合、リモートサーバーはそのメールが送信者から送信されたものであることを認識し、安全に配信することができます。
導入における課題
SPFもDKIMも実装自体は比較的簡単ですが、他の組織がこれに参加し、DNSレコードを正しく設定することが必要となります。 自社に代わってメールを送信するサードパーティ製ソフトウェアを検討する際は、そのベンダーがSPFおよびDKIMを完全にサポートしているかどうかを確認する必要があります。 ベンダーがSPFおよびDKIMを適切に実装しなかった場合、これらの仕組みを完全に適用することが困難になるか、あるいは不可能になる可能性があります。
とはいえ、他の組織がSPFやDKIMを正しく設定していたとしても、以下の課題があることにご留意ください：
SPFのスケーラビリティ
SPFでは、いくつかの異なるレコードタイプ（A、MX、PTR、EXISTS、INCLUDE、REDIRECTレコードなど）に限定して、最大10件のDNSクエリしか実行できません。 この制限は、レコードの検索が無限に続くのを防ぐために設けられていますが、SPFのスケーラビリティを制限することにもなります。 リダイレクトや、複数のルックアップを必要とするその他のDNSメカニズムは、制限をすぐに使い果たしてしまう可能性があり、トラブルシューティングの際に混乱を招く恐れがあります。 そのため、SPFを実装する際にDNSレコードをどのように活用するかを慎重に検討することが極めて重要です。 IPアドレスやIPアドレス範囲は、この制限の対象外ですが、FQDNを使用する場合と比較すると、変化するIPアドレスに対応し続けるには、多くのリソースを要する可能性があります。
サブドメインは含まれません
SPFは、レコードに指定されている正確なドメイン名のみを評価します。サブドメインには、 や が含まれますが、や は含まれません。 たとえば、company.com や の @ レコードに対して SPF レコードの IP アドレスを指定し、その IP アドレスから @_subdomain.company.com 宛てにメールが送信された場合、SPF チェックは失敗します。 各サブドメインには、それぞれ独自のSPFレコードを設定する必要があります。
他のドメインのDKIMキーの使用
DKIMキーを使用することで、他の組織が貴社のドメインに対して完全に認証されるようになります（その結果、貴社に代わって認証済みのメールを送信できるようになります）。 適切に設定されたサードパーティは、セレクタキーを提供することができます（このキーは、本質的には が に公開鍵を貸し出すものであり、その間、サードパーティは秘密鍵の管理権限を保持し続けます）。 秘密鍵を所有していなくても、DNS内のセレクタキーを適切に設定することで、復号リクエストをサードパーティに転送し、検証を完了させることができます。
組織は、以下のオプションを使用して、SPF または DKIM による失敗をどの程度厳格に制御するかを指定することができます：
-なし： メッセージは確認のためにダイジェスト化され、ログに記録されますが、問題のあるメッセージの配信自体は許可されます
-隔離：このアクションの内容は各メールプロバイダーによって異なりますが、多くの場合、メッセージがユーザーのスパムフォルダに直接移動することを意味します
-拒否：SPFまたはDKIMのいずれかによる検証に合格しない場合、メッセージは即座に拒否されます
ご注意ください：DMARCの出力内容は、読み取りにくいものです。 結果はXMLファイルとして出力され、メッセージを受信したすべてのSMTPサーバーから、DMARCポリシーで指定されたメールアドレス宛てに送信されます。 メールのトラフィック量によっては、1日に数千通ものメッセージが送信される可能性があり、その結果、潜在的な問題の特定やトラブルシューティングが困難になる恐れがあります。
お客様の環境を正しく把握するために、DMARC/SPF/DKIMレコード自体に存在する問題を特定するだけでなく、SMTPサーバーがメッセージがポリシーに違反していると判断した際に返送されるDMARC XMLレポートに隠れた問題を特定するのに役立つツールがいくつか用意されています。 Taniumでは、設定の解析や結果の集計を支援するために、 （）、Dmarcian（ ）（新しいタブで開きます）、、、 といったサービスを利用しています。
完璧とは言えませんが、DMARCを導入することで、組織は自社のドメイン名を使用してメールを送信しているのが誰であるかを把握し、管理できるようになります。 これらのツールを効果的に活用することで、組織は自社に届く悪意のあるメールの量を大幅に減らし、悪意のあるユーザーによるドメインのなりすましを防ぐことができます。 DMARCにより、組織は、送信元「@yourdomain.com」を名乗る正当なメールおよび不正なメールについて、受信側のSMTPサーバーがどのように検証を行い、どのような対応をとるかについて制御を行うことができます。
適切なDMARCの実装を構成することで、Taniumは 3 の異なるCIS領域において、補完的な統制範囲を追加することができました：
- CSC 7：電子メールとウェブブラウザのセキュリティ対策
- CSC 8：マルウェア対策
- CSC 9：ネットワークポート、プロトコル、およびサービスの制限と制御
結論
メールサービスを提供するドメインを管理されている場合は、DMARCの導入を強くご検討ください。 これは個々の企業にとって最善の利益となるだけでなく、偽装可能なドメインの数が事実上ますます減少していくにつれて、電子メールのエコシステム全体にとってもメリットがあります。 ドメインのなりすましのリスクを低減することは、ユーザーが被害に遭う可能性を減らすことにつながり、インシデントへの対応やその他の法的責任問題への対処にかかる費用を抑えることにもつながります。 これは、CIS Top 20 コントロールのような予防的なセキュリティ対策の完全な実施において、小規模ながらも重要な一環であり、ISO 27002 などの標準的なコンプライアンス・フレームワークの認証取得要件を満たすのに役立ちます。 これは、あらゆる規模の企業の健全性と繁栄にとって、当然のことと言えます。
著者「」について：エリック・フィッシャー氏は、ノースカロライナ州ローリーにあるTanium社に所属する情報セキュリティアナリストであり、エンタープライズ運用設計の専門家です。 エリック氏は情報セキュリティおよびフォレンジクスの修士号を取得しており、以前はセキュリティコンサルタントとして、フォーチュン 500 にランクインする複数の銀行、小売企業、テクノロジー企業において、SOC（セキュリティオペレーションセンター）やインシデント対応プログラムの構築に携わってきました。 また、ペンシルベニア州立大学応用研究所およびレイセオン社の社員として、複数の政府機関や軍向けに、大規模なコンピューティングアーキテクチャやネットワークの設計・構築に携わってきました。
