「サニタイザー」をメール無害化に使用する場合について

CIO Contribution Sanitizer

はじめに

お問合わせの多かった、メール無害化におけるサニタイザーの使い方について解説します。併せて、メール無害化についての考え方について整理しておきます。

サニタイザーを使ったメール無害化の構成イメージ

サニタイザーをメール無害化で使う場合、下図のような構成になると思われます。

%e3%82%b5%e3%83%8b%e3%82%bf%e3%82%a4%e3%82%b6%e3%83%bc%e3%82%92%e4%bd%bf%e3%81%a3%e3%81%9f%e3%83%a1%e3%83%bc%e3%83%ab%e7%84%a1%e5%ae%b3%e5%8c%96%e3%81%ae%e6%b5%81%e3%82%8c

以下に、メール無害化の考え方について示します。

メール無害化について

メール無害化の中には2つの要素が含まれています。

  1. メール本文の無害化
  2. メールの添付ファイルの無害化

このうち、1.メール本文の無害化の代表的な対応策は次のとおり。

  • URLやメールアドレスのリンクの削除
  • 本文中のHTMLレンダリングの抑制

ただし、これらの対応策はメールサーバ側の対応ではなく、メールクライアント(メールソフト)側の対応で処理することが一般的でしょう。特に技術的な難易度が高いものではありません。

したがって、以降は2.メールの添付ファイルの無害化について検討することにします。

メールの添付ファイルの無害化について

少し技術的な話になりますが、メールサーバ上に到達したメールは、mbox形式あるいはMaildir形式で保持されることが一般的です。いずれの形式の場合も、添付ファイルはメール本文とともに、MIMEのmultipartとして保持されており、この状態ではバイナリではないため、仮にマルウェアが含まれていた場合でも起動することはありません。

ちなみに、Maildir形式の場合、メールサーバ上には下図のような感じで、一通のメールが一つのファイルとして保存されています。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-12-17-6-39-11

サニタイザーVer.1.10では、このメールファイル(この中にメール本文と添付ファイルが一緒になっています)を分解して添付ファイルを取り出し、併せてそれぞれの添付ファイルをサニタイズできるようになりました。

つまり、このファイルをサニタイザーに通すことができれば、添付ファイルの無害化については解決します。

最も手軽なのは、手動でメールファイルをサニタイズすることでしょう。ファイルをドラッグ&ドロップするだけですので、さほど手間はかからないと思われますが、メールサーバ中のファイルを手動で扱うのは、メールの消失のリスクもあり少々危険です。

そこで、この作業を自動化したいという要望が多く寄せられています。その場合は、メールサーバ上のメールが保存されているフォルダとサニタイザーのinputフォルダを連携するか、メールファイルをサニタイザーのinputフォルダにコピーする仕組みを実装すれば解決します。

サニタイザーVer.1.10ではフォルダ間の同期が行える仕組みとなりましたので、サニタイズしたいメールファイルが指定されたフォルダと同期されるのであれば、対応は可能かと思われます。

サニタイザーVer.1.10でのデモ動画

今回のデモ動画の範囲は、下図の赤色で示した範囲です。

具体的にはメールサーバにメールファイルが記録されたタイミングでフォルダ同期しているサニタイザーが添付ファイルの処理をして、パソコンにサニタイズ後のファイルが到達するまでの様子です。

%e3%82%b5%e3%83%8b%e3%82%bf%e3%82%a4%e3%82%b6%e3%83%bc%e3%82%92%e4%bd%bf%e3%81%a3%e3%81%9f%e3%83%a1%e3%83%bc%e3%83%ab%e7%84%a1%e5%ae%b3%e5%8c%96%e3%81%ae%e6%b5%81%e3%82%8c%ef%bc%92

メールサーバはどこに配置すべきなのか

さて、サニタイザーの適用については、一応ケリがついたということにして、自治体のみなさまには少し本質的な問題を提起したいと思います。

trans-network1

上図はネットワークが分割された様子を簡略化して示したものです。ここで少なくともインターネット経由で届くメールは「インターネット系ネットワーク」上のメールサーバで受けることになると思いますので、添付ファイルもインターネット系ネットワーク上のフォルダに保持されます。

添付ファイルのサニタイズは、ファイル受け渡しの過程で行うことになります。これは以前ご説明したとおりです。

一方、LGWAN経由で到達するメールもあります。省庁からのメールやLGドメインを使っている自治体からのメールがこれに該当します。このメールを受けるために、LGWAN系ネットワーク上にメールサーバを配置すれば、今までどおりのメールの受信が可能となります。

職員の利便性を(多少)犠牲にして、整備コストを抑えるのであれば、職員はインターネット経由、LGWAN経由のそれぞれのメールをチェックする運用となるでしょう。なお、この運用に不満があるのならば、インターネット経由のメールとLGWAN経由のメールをある段階で統合し、まとめて受信する仕組みを検討することになります。

では、この統合したメールサーバはどのネットワーク上に配置することが望ましいのでしょうか。

ここで気になったのが、NISCから出されている平成29年度当初予算要求における総務省のセキュリティ対策予算の説明資料です。

http://www.nisc.go.jp/active/kihon/pdf/yosan2017.pdf

これの4ページ目下段の内容を読んで考えてみましょう。図を拡大して引用します。

soumu_sec2017要はLGWANの外部(おそらく省庁)から来たファイルをLGWANの中で無害化し、自治体に送付するという仕組みを整備したいという意図のようです。ただ、これは少し奇妙だと思いませんか?

なぜLGWANの中で無害化処理が必要なのでしょうか? そもそもLGWANはセキュアな回線ということではなかったのでしょうか? 私が示す答えは次のとおりです。

LGWANはトラストだが、セキュアではない

通信の相手先は限定されていますので、少なくともトラスト(信頼される)と言えますが、相手方が十分セキュリティ対策を行った後に、ファイルを送信しているかというと、決してそういうことではないのです。

ならば、LGWAN経由のメールもインターネット経由のメールも怪しさの程度は同じだと言えます。その事実に気がついたので、慌ててこの対策を来年度予算に盛り込んだというのが実際のところかもしれません。

さて、LGWAN経由のファイルの無害化は少なくとも来年度でなければ実現しません。一方、総務省が求める強靭性向上のリミットは来年7月の情報連携開始の前後の時期でしょう。それまでにLGWAN側の対応ができないのならば、自治体ではLGWAN経由のメールについても独自にサニタイズを行う必要が出てくるということです。

LGWAN経由のメールが怪しいとなると、総務省の示す強靭性向上モデルの説明は根底から崩れてしまいますので、対応方法は次のいずれかとなります。

  1. LGWAN経由のメールを一度インターネット系ネットワーク上のメールサーバに統合し、まとめてサニタイズする。
  2. LGWAN系ネットワークの中でインターネット経由のメールを統合し、まとめてサニタイズする。
  3. インターネット系ネットワーク、LGWAN系ネットワークのそれぞれでサニタイズの仕組みを整備する。

どれでもよいと思いますが、個人的にはLGWAN経由のメールは一度外に追い出して、普通のメールとしてまとめて処理するのが良いように感じます。これはあくまでも個人的見解ということで。

 


« »