Google Workspaceのメールセキュリティ向上 MTA-STSを設定してみる 1/4（概論編）

誤解を恐れず申し上げると「我々にメールを送るときには必ず有効な証明書とともにTLSを使って送ってください、そうじゃない場合は受け取りません！」というように送り元に対して自ドメインへの送信方法を指定することができる仕組みとなります。ざっくり絵にするとこのようなイメージです。

現在主流となっているSTARTTLSの弱点である「MTA同士でお互いTLSを使えたら使う（使えない場合は平文でOK）」を強化するものとなります。

MTA-STSを採用すると何が嬉しいのか？

メール中継ホスト間のメールの盗聴/改ざんリスクを軽減することができます。

特に受信者にとってのセキュリティ強化の意味合いが強いものとなります。

MTS-STSを導入すると自ドメイン宛てに送信されたメールに対する認証チェックや暗号化を必須とすることができます。

メールの発信から受信までの一連の経路において、発信時はSMTPs、受信時は IMAPs/POP3sと通信の安全性は利用者がコントロールでき、保護できるようになっていますし実際されている方も多いかと思います。

しかしながら送信ボタンを押した後〜受信者のメールボックスへ配送される間のメール中継部分は、必ずしも安全性を保証されていない仕組みで成り立っており、両端はしっかり守っているが間がブラックボックスという状態となっています。

この中継部分の暗号化送信は送信者、受信者ともコントロールができませんでした。

例えば、現実の世界で荷物を送る場合を想定します。

• 発送する人は荷物を送る際に箱に入れてきちんと封をして運送会社に預けます。
• 運送会社が荷物を預かった後、封を勝手に開けて全開の状態で配達店に輸送します。
• 受け取る人は、配達店で再度封をされたものを受け取りますので実際に中身が見られたかどうかは気づくことができません。

なんてことが行われていたらどう思うでしょうか？

送る側も受け取る側も気持ち悪くないでしょうか？

こんなことが現実世界で実際に行われていたら大問題ですよね？

これと同じことが今のメールの世界では正しい動作として認められており、

• 荷物を送る際に箱に入れてきちんと封をして運送会社に預けます。（＝送信時暗号化）
• 運送会社が荷物を預かった後、封を勝手に開けて全開の状態で配達店に輸送します。（=転送中は平文）
• 配達店で再度封をしてお届けする（＝受信時暗号化）

という状態になっている可能性があります。

メール中継における盗聴リスクを受信者側で守ることができる状態にすること、これこそがMTA-STSを適用することの最大のメリットだと考えています。

MTA-STSの実装はどのくらい大変なのか？

ただ安全になるとなったとしても適用が大変だったらやりたくないですよね。

次に気になるのがどのくらい導入が大変なのか、ではないでしょうか。

詳細は今後お伝えしますが、以下が概要となります。

実際やってみた感想として、SPFレコードを記述するレベルで終わるという簡単さではありません。

ただ、思ったより大変ではないというのが印象です。

正直な話、今回の検証で一番大変だったのはWebサイトの準備でした。

Webサーバーの準備に困難がなければ比較的導入のハードルは高くないと考えています。

また管理者作業だけで完結しますので、ユーザー側での対応は必要ありません。

まとめ

MTA-STSはスパム・なりすまし対策として当たり前となっているSPF/DMARK/DKIMと違って、現状では知名度と普及率は低いですが、適用することで今まで守れていなかったメール中継部分の安全性を高めることができるようになります。

ご利用中のメール環境をより安全にするという意味ではオススメの設定です。

少なくともMicrosoft365、Google Workspaceは送信側の対応は完了しており、受け取り側が宣言すればMTA-STSを使って送信するようになっています。あとは受信者側が利用を宣言すれば良いだけです。本記事をきっかけに1社でもMTA-STSを採用される企業が増え、自社のメール環境がより安全になっていくとともに普及していくことでメールの世界全体がより安全になっていくことを願っております。

今後の記事にて具体的な実装をご紹介できればと思います。

最後まで読んでいただきありがとうございました。

関連サービス