DMARCの導入：メールセキュリティにおける人的側面への対応

導入電子メール技術セキュリティに関する知見

DMARCの導入における課題は、必ずしも技術的なものとは限らない

DMARCの基本はごく単純なので、1日勉強すればしっかりと理解できます。すぐに導入できるだけの知識は身につくでしょう。 

• SPFは、あなたのドメインに対して送信を許可されているサーバーを公開します。 
• DKIMは、DNSに公開した鍵を使用してメッセージに署名を行います。 
• DMARCは、受信者が実際に目にするドメインとこれらを関連付け、両者が一致しない場合に受信側がどう対応すべきかを指示します。 

以前は手間がかかっていた部分が解決されました。dmarcianのようなDMARCベンダーは、集計レポートのXMLを処理し、IPアドレスなどの送信データを既知の送信元と照合し、どの送信元が合格で、どの送信元が不合格かを、人間が読みやすい形式で表示してくれます。これらを自分で構築する必要はありません。 

レポートも非常に詳細です。DMARCレポートに対応しているすべての受信側は、検知した内容を報告するため、自社ドメインから送信されたすべてのもののリストを確認できます。そこには、メールプラットフォーム、チケット管理システム、給与計算サービス、2019年に誰かが登録したアンケートツール、昨年マーケティング部門が導入したキャンペーンプラットフォームなどが含まれます。自社が利用しているシステムを推測する必要はありません。データがすべてを明らかにしてくれるのです。 

技術的な作業は把握可能かつ測定可能であり、必要なツールも整っており、発見すべき課題の大部分は解決済みです。レポートからは、どのシステムがデータを送信しているかが分かります。しかし、それらのシステムの責任者が誰なのかについては何も記載されていません。この「発見」の段階こそが、プロジェクトのスケジュールを左右するのです。 

メールのエコシステムは2つの部分から構成されています

送信元を2つのグループに分けましょう： 

IT部門が管理：メールプラットフォーム、メールセキュリティゲートウェイ、監視・アラートシステム、サービスデスクソフトウェア、エンタープライズリソースプランニング（ERP）システム、およびIT予算で賄われるその他のすべてのシステム。IT部門は管理者権限を持ち、直接変更を加えることができます。 

各部門が独自に導入していたシステム：マーケティングオートメーション、顧客関係管理（CRM）システム、人事・給与管理、採用候補者管理、経費精算ツール、イベント登録システム、アンケートプラットフォーム、および請求システム。これらは各部門の予算で購入され、部門のスタッフが登録・管理を行っていました。IT部門は、DMARCレポートに表示されるまで、ログイン情報すら持たず、そのツールの存在すら知らないことがよくありました。 

企業が所有するシステム群は、たいてい誰もが予想するよりも規模が大きく、そこがデプロイメントが頓挫する場所となっている。 

ソースの準拠を確保するには、単にSPFを変更するだけでは不十分な場合がほとんどです

「ベンダーのインクルードをSPFレコードに追加すれば完了だ」というのは、よくある誤解です。そうすれば、その送信元はDMARCに準拠したことになる、というわけです。これはごく一部の送信元については正しいですが、ほとんどのサードパーティについては、まったく効果がありません。 

DMARCでは整合性が求められます。受信者が受信トレイで確認する「From」ヘッダーのドメインは、SPFまたはDKIMの検証に合格したドメインと一致している必要があります。多くのベンダーは独自のリターンパスのドメインを使用してメールを送信するため、SPFによる認証の対象となるのはベンダーのドメインであり、あなたのドメインではありません。あなたのSPFレコードは、そもそもチェックされることさえありません。「include」を追加しても（ベンダーのドキュメントには「include」を追加するよう記載されている場合さえありますが、それは誤りです）、DMARCの結果は依然として「失敗」のままです。 

整合性は、ベンダーアプリケーション内部での変更によって生じます。その変更は、以下の2つの方法のいずれかで行われます： 

セルフサービス：プロバイダーには送信ドメインまたは認証ページが用意されています。自分のドメインを追加すると、DKIMキーまたは公開用のCNAMEレコードが発行されるため、それらを公開した後、再びページに戻って「検証」をクリックします。そのプラットフォームの管理者権限を持つユーザーであれば、この作業は数分で完了します。 

ご要望に応じて：プロバイダー側ではこの設定項目が公開されていません。サポートチケットを開き、ご自身のドメインでのカスタムDKIM署名を有効にするよう依頼します。サポートリクエストが処理された後、追加すべきDKIMレコードまたはCNAMEレコードが提供されます。多くの場合、このオプションは無料で利用できますが、プランのアップグレードが必要な場合や、必要な設定を得るまでに3週間かかり、2回の確認と打ち合わせが必要になる場合もあります。 

いずれにせよ、どちらの方法にも必要なものを見てみましょう。それは、ベンダーのプラットフォーム上の管理者権限を持つアカウントです。ほとんどの場合、サポートチケットを提出するだけでも、そのアカウントの担当者として登録されている必要があり、ログインすることで本人確認が行われ、サポート利用権限も確認されます。

IT部門は一日中DNSレコードを公開し続けることができます。しかし、業務システムへのアクセス権がなければ、IT部門の権限はそこで終わりを告げます。 

ステークホルダーの特定

この点において、このプロジェクトは主に探偵仕事のようなものだ。 

• この情報源の所有者は誰ですか？ 
• 管理者アカウントを持っているのは誰ですか？ 
• そのベンダーの担当者は誰ですか？ 
• 有料のアドオンが必要になった場合、誰が承認するのですか？ 

やがてその人を見つけることになるが、その探求の過程には、それだけで一冊のガイドブックを執筆する価値があるほど、独自の課題が伴う。

主体性は高いが、リスクは低い

高い裁量権。システムは彼らが管理しています。アクセス権も彼らが握っています。ベンダーとの関係も築いており、承認や変更を行う権限も持っています。彼らなしでは、ソースに何の変化も起こりません。 

関与度は低い。彼らはDMARCという言葉を聞いたこともない。それは彼らの責任でも目標でもなく、職務内容にも含まれていない。彼らからすれば、IT部門がニュースレター用に利用しているツールにログインして設定を変更するよう求めているに過ぎない。そして彼らは困惑している――IT部門は、目に見えない期限までに将来発生しうる問題を解決するよう求めているからだ。彼らは問題の原因ではなく、自分たちには何の不利益も生じない上、その設定について発言権もなかったのだ。

これらはすべて同時に当てはまり、その組み合わせこそが、スケジュールというものを台無しにしてしまうのです。関係者にとって、その依頼は取るに足らないものに感じられます。その依頼は、彼らの業績が左右される業務で既に埋まっているリストの一番下に追いやられてしまいます。2週間後にフォローアップをしても、その2週間後にもまたフォローアップをしなければならなくなるのです。 

DMARCレポートに記載されている10～20の企業所有の送信元について、この手順を繰り返してください。多くの場合、各送信元には異なる担当者がおり、それぞれ独自のスケジュールが設定されています。これこそが真のボトルネックです。これらの担当者は、妨害しようとしているわけでも、無能なわけでもありません。単に、なぜそうすべきでないのかを理解していないため、合理的にあなたの要望を無視しているに過ぎないのです。 

DMARCプロジェクトのスポンサーシップ

確実に変化をもたらす唯一の要素は、IT部門と事業部門の両方を統括できる十分な地位にある人物からの指示、あるいは経営陣間の真の横断的な連携です。この点については、高等教育機関におけるDMARC導入の複雑さについて述べた前回の記事でも触れました。その人物の職務の一環として、上司も把握している日程を明記した依頼が届いた場合、その提案は単なる空論ではなくなり、勢いを得ることになります。 

ただし、スポンサーシップは具体的なものでなければなりません。それを実現するためにできることをいくつか挙げます：

• できるだけ早い段階で所有者リストを作成してください。送信元ごとに、名前を割り当ててください。 
• スポンサーから書面による承認を得て、それを基にオーナーへの連絡に向けたコミュニケーション計画を策定してください。その内容を、オーナーの上司にも周知させてください。 
• 可能であれば、そのベンダー固有の設定要件について、具体的な手順を提示してください。要件が不明な場合は、当社のソースデータベースを活用するか、サポートサービスの利用をご検討ください。それがまさに、私たちが日々取り組んでいる業務なのです。 
• 数ヶ月間音沙汰がなくなる前に、スポンサーを通じて予定通りにエスカレーションを行ってください。 

また、このプロセスを救うことができないものについても留意しておくことが重要です。AIでは不可能です。AIはアウトリーチの草案を作成したり、ある程度までレポートを読み上げたりすることはできますが、認証情報がないマーケティングプラットフォームにログインしたり、多忙な人の関心を引いたりすることはできません。自動化ツールも同様です。なぜなら、こうしたベンダーのほとんどは、変更が必要な設定に対してAPIを公開しておらず、公開している場合でも、おそらくあなたが持っていないアカウントが必要になるからです。 

これは、ステークホルダーの特定、実権を持つスポンサー、明確な要求事項、コミットメントの追跡、そしてエスカレーションのスケジュール化を伴うプロジェクト管理です。必ずしも華やかな仕事ではありませんが、今四半期中に実施段階に到達できるか、それとも来年になるかを決める重要な部分なのです。 

プロジェクトは人を中心に計画しましょう。DNSレコードの設定は、決して難しい部分にはなりません。 

---

さらに詳しく議論を続けたい方は、ぜひ dmarcian Forum へお越しください。