電子メールのセキュリティ対策

N 社は、従業員数 500 名の情報サービス事業者である。N 社の情報システムの構成を図 1 に示す。

N 社の情報システムは、情報システム部（以下，情シ部という）の Q 部長と U 主任を含む 5 名で運用している。

各 PC 及び各サーバは脆弱性修正プログラムが自動的に適用され、導入済のマルウェア対策ソフトのマルウェア定義ファイルが自動的にアップデートされる設定になっている。外部メールサーバでは、スパムメールフィルタの機能を利用している。

N 社では、インターネットドメイン名 n-sha.co.jp（以下，N 社ドメイン名という）を取得しており、メールアドレスのドメイン名にも使用している。外部 DNS サーバは、電子メール（以下，メールという）に関して図 2 のように設定してある。

送信者メールアドレスには、SMTP の a コマンドで指定されるエンベロープの送信者メールアドレス（以下，Envelope-FROM という）と、メールデータ内のメールヘッダで指定される送信者メールアドレス（以下，Header-FROM という）がある。送信したメールが不達になるなど配送エラーとなった場合，Envelope-FROM で指定したメールアドレス宛てに通知メールが届く。N 社では、従業員が PC からメールを送信する場合，Envelope-FROM 及び Header-FROM ともに自身のメールアドレスが設定される。

昨今，メールを悪用して企業秘密や金銭をだまし取る攻撃が発生しており，N 社が属する業界団体の会員企業でも、なりすましメールによる攻撃によって被害が発生した。こうした被害を少しでも抑えるため，団体から送信者メールアドレスが許諾されているかをドメイン単位で確認する技術（以下，送信ドメイン認証技術という）を普及させるよう働きかけがあったことから，N 社でも情シ部が中心となって送信ドメイン認証技術の利用を検討することになった。

Q 部長と U 主任は、送信ドメイン認証技術の利用について検討を始めた。次は、その際の Q 部長と U 主任の会話である。

Q部長： 当社でも送信ドメイン認証技術を利用すべきだと経営陣に報告したい。まずは、どのような送信ドメイン認証技術を利用するかを検討しよう。

U主任： 送信ドメイン認証技術では、SPF，DKIM，DMARC が標準化されています。当社の外部メールサーバでは、いずれも利用が可能です。

Q部長は、図 3 のなりすましメールによる攻撃の例を示し，送信ドメイン認証技術が各攻撃の対策となるかどうかをまとめるよう U 主任に指示した。

U 主任は、SPF への対応と各攻撃に対する効果の関係を表 1 にまとめ、SPF が対策となるかどうかを同表を用いて Q 部長に説明した。

次は、その後の Q 部長と U 主任の会話である。

Q部長： SPF に対応するには、具体的にどのような設定が必要になるのか。

U主任： DNS サーバでの設定は、当社の外部 DNS サーバに図 4 に示す TXT レコードを登録します。

メールサーバでの対応は、当社の外部メールサーバの設定を変更します。SPF による検証（以下，SPF 認証という）が失敗したメールは、件名に[NonSPF]などの文字列を付加して、受信者に示すこともできます。

Q部長： なるほど。SPF の利用に注意点はあるのかな。

U主任： メール送信側の DNS サーバ，メール受信側のメールサーバの両方が SPF に対応している状態であっても、その間で SPF に対応している別のメールサーバが Envelope-FROM を変えずにメールをそのまま転送する場合は、①メール受信側のメールサーバにおいて、SPF 認証が失敗してしまうという制約があります。

Q部長： なるほど。それでは、DKIM はどうかな。

U主任： DKIM に対応したメールを送信するためには、まず、準備として公開鍵と秘密鍵のペアを生成し、そのうち公開鍵を当社の外部 DNS サーバに登録し、当社の外部メールサーバの設定を変更します。DKIM 利用のシーケンスは、図 5 及び図 6 に示すとおりとなります。

Q部長： DKIM の方が少し複雑なのだな。

U主任： はい。しかし、DKIM は、メール本文及びメールヘッダを基にディジタル署名を付与するので、転送メールサーバがディジタル署名，及びディジタル署名の基になったメールのデータを変更しなければ、たとえメールが転送された場合でも検証が可能です。SPF と DKIM は併用できます。

Q部長： 分かった。両者を導入するのがよいな。それでは、DMARC はどうかな。

U主任： DMARC は、メール受信側での、SPF と DKIM を利用した検証，検証したメールの取扱い，及び集計レポートについてのポリシを送信側が表明する方法です。DMARC のポリシの表明は、DNS サーバに TXT レコードを追加することによって行います。TXT レコードに指定する DMARC の主なタグを表 2 に示します。

これらの検討結果を経営陣に報告したところ，N 社は送信ドメイン認証技術として SPF，DKIM，DMARC を全て利用することになり，情シ部が導入作業に着手した。

送信ドメイン認証技術の導入作業着手から 1 週間後，N 社営業部で取引先宛てにニュースレターを配信する計画が持ち上がった。ニュースレターの配信には，X 社のクラウド型メール配信サービス（以下，X 配信サービスという）を利用する。ニュースレターは，X 社のメールサーバから配信され，配送エラーの通知メールは，X 社のメールサーバに届くようにする。Header-FROM には，N 社ドメイン名のメールアドレス（例：letter@n-sha.co.jp）を設定する。Envelope-FROM には，N 社のサブドメイン名 a-sub.n-sha.co.jp のメールアドレス（例：letter@a-sub.n-sha.co.jp）を設定する。

X 社のメールサーバのホスト名は，mail.x-sha.co.jp であり，グローバル IP アドレスは，x2.y2.z2.1 である。X 社の DNS サーバのグローバル IP アドレスは，x2.y2.z2.2 である。X 配信サービスでは，SPF，DKIM，DMARC のいずれも利用が可能である。

N 社は，ニュースレターの配信についても，3 種類の送信ドメイン認証技術を利用することにした。具体的には，N 社の外部 DNS サーバに図 7 のレコードを追加する。

ここで，受信側で検証に失敗したメールは隔離するポリシとするため，DMARC の p タグと aspf タグの設定は表 3 のとおりとする。

その後，N 社と主要な取引先での送信ドメイン認証技術の導入が完了した。