情報処理安全確保支援士試験 令和元年度 秋期 午後1 問1 設問2
【出典：情報処理安全確保支援士試験 令和元年度 秋期 午後1 問1（一部、加工あり）】
【送信ドメイン認証技術の検討】
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を全て利用することになり、情シ部が導入作業に着手した。
b：×、c：×
SPF（Sender Policy Framework）は、DNSを用いて受信メールのIPアドレスを検証する送信ドメイン認証技術です。
メール送信元のドメイン管理者は、メールサーバのIPアドレスを自ドメインのDNS情報にSPFレコードとして追加しておきます。（SPFレコードの代わりに任意のテキストデータを記載できるTXTレコードを使う方法もあります）
メール受信側のメールサーバは、受信メールの送信元IPアドレスと、ドメイン名のDNSサーバにSPFレコード（又はTXTレコード）を問合せ、両者を比較し、一致すれば認証に成功し、正規の送信者からのメールと判断します。
問題文の攻撃1は送信側が取引先であるため、取引先のDNSサーバへのSPFレコード登録と、N社の外部メールサーバでのSPFの実施が必要になります。
逆に、攻撃2は送信側がN社であるため、N社のDNSサーバへのSPFレコード登録と、取引先のメールサーバでのSPFの実施が必要になります。
これを考慮して、それぞれのSPFへの対応状況での効果を確認します。
項番6は、N社と取引先のメールサーバが未対応であり、攻撃1、2のいずれもSPF認証が成立しないため、判断不可となります。
d：×、e：×
項番6は、N社と取引先のメールサーバが未対応であり、攻撃1、2のいずれもSPF認証が成立しないため、判断不可となります。
f：×、g：○
項番7は、N社のメールサーバが未対応であり、攻撃1についてはSPF認証が成立しないため、判断不可となります。
攻撃2については、取引先のメールサーバによるN社のDNSサーバへのSPFレコード問合せにより、SPF認証が成立するため、判断可となります。
h：×、i：×
項番13は、N社でのDNSサーバ、メールサーバとも未対応であり、攻撃1、2のいずれもSPF認証が成立しないため、判断不可となります。
j：x1.y1.z1.1
SPF認証のためのTXTレコードには、メールサーバのIPアドレスを記述します。
N社のメールサーバは、図2から「x1.y1.z1.1」であることが分かるので、これを記述します。
①について、SPF認証が失敗する理由を、SPF認証の仕組みを踏まえて、50字以内で具体的に述べよ。：送信側のDNSサーバに設定されたIPアドレスとSMTP接続元のIPアドレスが一致しないから。
別のメールサーバがメール転送した場合、メール受信側が取得する送信元IPアドレスは、メール転送サーバのIPアドレスになります。
メール転送サーバがEnvelope-FROMを変えない場合は、メール受信側が行うTXT（SPF）レコードの問合せ先はメール送信側のDNSサーバになります。
したがって、送信側のDNSサーバに設定されたIPアドレスと、SMTP通信の接続元であるメール転送サーバのIPアドレスが一致しないため、SPF認証が失敗してしまうことになります。
②の検証によってメールの送信元の正当性以外に確認できる事項を、20字以内で述べよ。：メール本文及びメールヘッダの改ざんの有無
メールに付与したディジタル署名は、メールの送信元の正当性の確認と、送信メッセージが改ざんされていないかどうかを確認できるものです。
「署名対象としたメール本文及びメールヘッダを基に生成したハッシュ値」とあるので、改ざん有無は、メール本文及びメールヘッダを対象に確認することができます。