電子メールサービスの認証と運用設計
電子メールの配送経路と送信ドメイン認証を組み合わせ、正規のメールを届けながらなりすましを見分けるための設計である。DNS、SPF、DKIMの設定を送信経路に合わせ、業務の委託先を含めて送信権限と鍵の管理範囲を決める。
イマシルちゃんの解説
電子メールサービスの認証と運用設計では、差出人の表示と認証で調べる情報を区別するんだ。
SPFは主に、配送時の差出人指定であるMAIL FROMのドメインについて、接続元サーバの送信許可を調べる技術だよ。
DKIMは電子署名を検証して、署名したドメインと署名対象の改ざんの有無を確かめるんだ。
ただし、どちらも通過しただけでは画面の差出人ドメインとの対応は分からないよ。
その対応を確かめる認証の仕組みがDMARCなんだ。
委託先からも送るなら、その経路に合う認証設定にして、担当者が使える差出人や鍵の管理範囲も決めよう。
正規のメールを届けつつ、他人に自社を名乗られにくくするためだよ。
この解説はわかりやすかったですか?
より深い解説
最初にメールの配送経路を整理する
メールを送る端末、メールボックスを持つ社内メールサーバ、インターネットとの間で配送するメール中継サーバでは役割が異なる。送信側から受信側まで、SMTPの接続をどの機器が開始するかを順番に追う。
DNSに登録する情報も、その役割に合わせて使い分ける。
| DNSの情報 | メール配送での役割 |
|---|---|
| MXレコード | 宛先ドメインのメールを受け付けるサーバを指定する |
| Aレコード・AAAAレコード | サーバ名をIPv4・IPv6アドレスへ対応付ける |
| PTRレコード | IPアドレスからサーバ名を調べる逆引きに使う |
| TXTレコード | SPFの送信許可情報やDKIMの公開情報を掲載する |
| DNSのTTL | 情報をキャッシュして再利用できる時間を指定する |
複数のMXレコードがあるときは、Preferenceの値が小さいサーバを優先する。接続できない場合にほかの候補へ切り替える動作と、一つの名前に複数のIPアドレスを登録するDNSラウンドロビンは分けて考える。
DNSラウンドロビンではキャッシュが残る間、同じアドレスが続けて使われることがある。特に一台の社内メールサーバから配送を始める構成では、そのサーバ側の名前解決結果の再利用が振り分けに影響する。DNSのTTLを短くすると再問合せの機会を増やせるが、均等な振り分けや故障検知まで保証されるわけではない。障害時の再送や別候補への接続機能も確認する。
名前とIPアドレスを混同しない
社内DNSが返すプライベートIPアドレスと、外部DNSが返すグローバルIPアドレスが異なる構成もある。NATを使う場合は変換前後を分けて記録する。例えば社内の中継サーバが10.20.30.15から送信していても、受信側に198.51.100.25として見えるなら、外部からの送信元判定では後者が対象になる。ここでのアドレスは説明用の例である。
逆引きで得た名前が差出人のドメインと似ていても、それだけで送信を許可されたとは判断できない。逆引きゾーンを管理できる者が、自分のIPアドレスに他社を連想させる名前を登録する可能性がある。ドメインの管理者自身が許可した情報を確認するために送信ドメイン認証を使う。
メールには複数の「送信者を表す情報」がある。どの情報を検証しているかを先に整理すると設定ミスを防げる。
| 情報 | どこにあるか | 認証との関係 |
|---|---|---|
| エンベロープFrom | SMTPのMAIL FROMコマンドで指定する | SPFの主な確認対象のドメインになる |
| ヘッダーFrom | メール本文の前にあるヘッダーに記録する | メールソフトが差出人として表示する |
| DKIMの署名ドメイン | DKIM-Signatureのd=に記録する | DKIMで署名の責任を確認する対象になる |
同じ値になる構成もあるが、必ず一致するわけではない。表示された差出人と認証されたドメインの整合は、DMARCで確認する設計につながる。
SPFは接続元と送信許可を照合する
SPFでは送信側のドメイン管理者が、使用を許可する送信サーバの情報を権威DNSサーバへTXTレコードとして公開する。受信側はSMTPで接続してきた相手のIPアドレスと、MAIL FROMで指定されたドメインの情報を照合する。
- 受信側がSMTPの接続元IPアドレスを確認する。
- MAIL FROMで指定されたアドレスからドメインを取り出す。
- そのドメインのSPFレコードをDNSで調べる。
- 接続元が許可されているかを判定し、結果を受信側のポリシーに従って扱う。
NAT経由の送信では、受信側から見える変換後のIPアドレスが照合の対象になる。送信端末の社内IPアドレスや、メールのヘッダーに書かれた文字列だけを見て設定してはいけない。
SPFはメール本文の改ざんを検証する技術ではない。また、メール転送で接続元のサーバが変わると正規のメールでも認証結果が変わることがある。エンベロープFromが空の場合やHELOの確認も規定されているため、運用では通常メールと配送エラー通知の両方を試す。
DKIMは署名と公開情報を対応させる
DKIMでは送信側が秘密鍵を使ってメールへ電子署名を付ける。受信側は署名対象のヘッダーと本文に対する検証を行い、署名したドメインと内容の整合を確認する。メールを配送するサーバのIPアドレスが変わっても、署名対象が保たれていれば検証できる点がSPFと異なる。
鍵の取得先はDKIM-Signatureのd=とs=から決まる。d=は署名ドメイン、s=は鍵を選ぶセレクターである。例えばd=example.com、s=vendorなら、DNSの問合せ先は vendor._domainkey.example.com となる。
| 記録場所 | タグ | 内容 |
|---|---|---|
| DKIM-Signature | d= | 署名したドメインを示す |
| DKIM-Signature | s= | そのドメイン内で使うセレクターを示す |
| DKIM-Signature | b= | 電子署名のデータを示す |
| DKIM-Signature | bh= | 署名対象となる本文のハッシュ値を示す |
| DNSのDKIMレコード | k= | RSAなどの鍵の種類を示す |
| DNSのDKIMレコード | p= | Base64で表した公開鍵を掲載する |
送信側は秘密鍵を保管し、受信側はDNSで取得した公開鍵で検証する。DKIMの鍵をDNSへ掲載するために、認証局の証明書を必須とする仕組みではない。
DKIMで確認できるのは署名ドメインの責任と署名対象の整合である。署名が正しいことだけで、メールの主張が事実であることや特定の担当者本人が操作したことまで保証されるわけではない。
委託先を追加するときは送信権限と鍵を分ける
自社ドメインを使って委託先からメールを送るなら、送信経路が増えた分だけ認証設定を調整する。例えば自社のexample.comを委託先の中継サーバから使う場合、SPFの変更先はexample.comの権威DNSサーバである。
| 変更するもの | 必要な対応 |
|---|---|
| SPF | 委託先の送信経路から受信側に見えるIPアドレスを許可する |
| DKIMの署名ドメイン | 自社として署名するならd=に自社ドメインを設定する |
| セレクターと鍵 | 自社用と委託先用を分け、委託先ごとに更新や失効を行えるようにする |
| DNSの掲載先 | 委託先用セレクターの公開鍵を自社ドメイン側へ登録する |
| 送信権限 | 認証した利用者やチームが使える差出人アドレスを制限する |
別鍵にすれば、自社用の秘密鍵を委託先へ渡さずに運用できる。委託先用の鍵が漏えいしても自社用の鍵まで交換する必要はなく、問題のあるセレクターを対象に対処できる。ただし漏えいした鍵が有効な間は、自社ドメインを名乗る署名が作られる危険がある。DNSキャッシュの残存時間も含めて失効・切替えの手順を決める。
同じ中継サーバから送信できる利用者が、自由に自社の窓口アドレスを名乗れる状態は避ける。中継サーバがそのメールにも署名するとSPFとDKIMを通過し得るためである。SMTP AUTHなどで確認した利用者と送信可能な差出人を対応付け、認可を通ったメールに署名する。監査では認証利用者、差出人、送信時刻、配送先を追えるようにする。
鍵を公開するDNSも運用対象にする
DKIMの検証はDNSの情報を使うため、鍵の更新時には新しい鍵の公開から署名側の切替えまでを一連の作業として扱う。旧鍵で署名済みのメールが配送中に残る可能性も考慮し、通常の更新と漏えい時の緊急失効を分けて設計する。
従来のDNSでは、EDNSを使わないUDP応答は512バイトに制限される。EDNSではより大きな応答を扱えるが、応答が収まらず切り詰められた場合などにTCPで再取得できることも必要である。ファイアウォールではUDPだけでなくTCPの53番ポートも含めて通信要件を確認する。RSA鍵の長さだけでDNS応答全体の大きさが決まるわけではない。
DKIMのDNSレコードにあるt=sは、署名識別子i=のドメインをd=のドメインと同一に限定するフラグである。テストを示すのはt=yであり、t=sを単に「本番運用モード」として覚えない。署名ヘッダーにある同名のt=は署名時刻を示すため、どちらのレコードを見ているかにも注意する。
個人や窓口の署名を確認する場合
利用者や窓口に対応する証明書を使ってメールの署名を確認する技術がS/MIMEである。受信側は証明書の信頼性と署名を検証し、証明書が示す送信者との対応を確かめる。メールサーバ単位で実施するSPF・DKIMとは、確認する単位と鍵の管理場所が異なる。
S/MIMEの署名では秘密鍵で署名を作り、対応する公開鍵と署名方式に従って検証する。暗号化も可能だが、署名による確認と内容を読めなくする処理は別である。署名の作成・検証をすべて「暗号化・復号」と同一視しない。
複数人で同じ窓口用の鍵を共有する構成では、署名だけから操作した一人を特定できない。担当者の異動や契約終了時の利用停止、証明書の更新・失効、鍵の利用権限と記録まで含めて設計する。
この年度の設問について
IPAは令和6年度春期ネットワークスペシャリスト午後Ⅱの問2について、設問5に不備があるため、問2を選択した受験者全員の設問5(1)〜(3)を正解として扱うと公表している。IPAの公式告知で確認できる。
この範囲には通常の正答・解法を付けず、S/MIMEは規格に基づく一般的な技術として学ぶ。公式告知には不備の詳しい技術的理由は記載されていない。
参考資料
出題範囲はIPA 令和6年度春期ネットワークスペシャリスト午後Ⅱ 問題冊子の問2と、採点講評を参照した。本文はメールシステムの運用に共通する考え方として整理している。
- RFC 5321:SMTPは配送手順とMXの利用を定めている。
- RFC 7208:SPFは送信許可の確認方法と限界を説明している。
- RFC 6376:DKIMは署名、セレクター、鍵の取得、各タグの意味を定めている。
- RFC 9989:DMARCは表示上の差出人ドメインと認証結果の整合を扱う。
- RFC 6891:EDNSはDNSメッセージの拡張を説明している。
- RFC 8551:S/MIMEはメールの署名と暗号化の仕組みを説明している。
午後での問われ方
| 問われ方 | 判断のポイント |
|---|---|
| 配送先の決定 | MXの優先順位と、内部の中継先を決める名前解決を分けて追う |
| DNSによる振り分けの偏り | どの機器が名前解決し、どこにキャッシュが残るかを考える |
| SPFへ登録する情報 | 受信側が見る接続元のIPアドレスと、認証対象ドメインの管理者を確認する |
| DKIMの鍵取得先 | d=とs=を組み合わせてDNSの問合せ名を作る |
| 委託先と鍵を分ける理由 | 漏えい時にどの送信系統の鍵を止める必要があるかを説明する |
| 認証を通過するなりすまし | 同じ中継サーバを使える利用者の権限と署名処理を確認する |
実際の試験ではここに出る!全1問
ネットワークスペシャリスト
- 午後Ⅱ