情報処理安全確保支援士 2011年 春期 午前2 問05

SMTP送信認証【午前2解説】

正解の理由

解法ステップ

1. 問題の主題を確認：「SMTP-AUTH」が何をするか（送信時の認証）を思い出す。
2. 各選択肢と主題を照合する：
   • 「送信を許可するためにクライアントを認証する仕組み」かどうかを見る。
3. 他の選択肢が別の仕組み（POP-before-SMTP、TLSクライアント証明書、受信時認証の説明等）を表していないかを除外する。
4. 最終的に、送信時に利用者認証を行い、許可された利用者のみ受け付けることを述べている イ を選ぶ。

選択肢別の誤答解説

• ア：
  • 説明しているのは「受信（POP）を行ったクライアントのIPに対して一定時間送信を許可する」方式で、通称「POP-before-SMTP」です。SMTP-AUTHとは別の古い手法で、POP受信が先にあることが前提になります。よって不正解です。
• イ：
  • SMTP-AUTH の本質的な説明です。クライアント接続時に認証を行い、認証済み利用者からのみ送信を受け付けます。サブミッション（通常はポート587）で使われることが多く、認証により不正なリレー防止ができます。
• ウ：
  • 「サーバが CA 証明書を持ち、クライアント証明書の妥当性を確認する」は TLS のクライアント証明書（相互 TLS / mutual TLS）による認証の説明です。これは TLS 層で行われる方式であり、SMTP-AUTH（SASL に基づくアプリケーション層の認証）とは別の仕組みとして扱われます。したがって不正解です。
• エ：
  • 「パスワードからハッシュ値を計算してその値で認証する」との記述は一般化しすぎています。チャレンジ応答型の SASL（例：CRAM-MD5）は確かにハッシュ/MAC を用いる方式で、SMTP-AUTH で利用されることがありますが、すべての場面でこれが行われるわけではありませんし、設問文は「受信時の認証情報を秘匿するため」と受信（POP/IMAP）を前提に記述しており、SMTP-AUTH（送信認証）の説明としては不適切です。また、CRAM-MD5 はサーバ側でパスワード相当の秘密（平文または変換可能な形）を保持する必要があり、必ずしも安全性が高いとは限りません。

よくある誤解

1. POP-before-SMTP と SMTP-AUTH を混同する
   • 「受信したら送信を許す（IPベース）」の仕組みは POP-before-SMTP であり、SMTP-AUTH（接続時に直接ユーザ認証を行う）とは別物です。
2. ハッシュ・チャレンジ方式は万能に安全だと思い込む
   • CRAM-MD5 のようなチャレンジ応答方式はパスワードを平文で送信しない利点がありますが、サーバ側で平文や同等の秘密を保持する必要があり、現代では SCRAM 系などより安全な方式が推奨されます。
3. クライアント証明書認証＝SMTP-AUTH と考える誤り
   • クライアント証明書は TLS 層で行う認証手段で、SMTP-AUTH（SASL によるアプリケーション層認証）とは運用的に別扱いです。両者は併用可能ですが、区別して理解する必要があります。

補足コラム

• 一般的な運用：
  • メール送信の標準的な構成では、送信（サブミッション）用にポート587を使い、クライアントはまず STARTTLS により TLS を確立してから SMTP-AUTH（SASL）で認証するのがベストプラクティスです。これにより PLAIN/LOGIN のような「平文ベース」メカニズムでも通信路が暗号化されるため安全性が確保されます。
• 主な SASL メカニズムの例：
  • PLAIN / LOGIN（簡単だが TLS で保護する必要あり）
  • CRAM-MD5（チャレンジ応答、サーバ側の秘密管理に注意）
  • SCRAM-SHA-1 / SCRAM-SHA-256（より安全でサーバ側に平文を残さない方式）
• クライアント証明書：
  • 企業や高セキュリティ環境では TLS のクライアント証明書を用いて接続段階で認証することがあるが、これは SMTP-AUTH の代替ではなく、異なる層の認証方式です。

FAQ