情報処理安全確保支援士 2024年 秋期 午後 問02

解答の論理構成

1. メールサーバの受信対象
   • 表1には「宛先メールアドレスのドメイン名が a であるメールをメールボックスに格納する。」とあります。
   • メールサーバが保存するのは自社あてのメールでなければなりません。
2. 自社で現在使用しているドメイン名の確認
   • 問題文に「10年前にドメイン名 a-sha.co.jp（以下、A社ドメイン名という）を取得して以降、A社のWebサイト…及びメールアドレスのドメイン名として利用している。」という記述があります。
   • すなわち、現行システムでメールアドレスに使われるドメイン名は「A社ドメイン名」です。
3. 結論
   • メールサーバが受信し、メールボックスに格納するべき対象は「A社ドメイン名」でなければ整合しません。
   • よって a には「A社ドメイン名」を挿入するのが適切です。

誤りやすいポイント

• 「a-sha.co.jp」と直接記載してしまう
  「A社ドメイン名」と問題文に定義されているため、正式な用語を用いる必要があります。
• 新ドメインへの先走り
  社名変更後の「Z社ドメイン名」はまだ導入前段階。現状を問う設問では使用しません。
• 表2のbと混同
  b は社内 LAN からの送信可否を判定する別項目であり、a とは用途が異なります。

FAQ

解答の論理構成

1. 【問題文】の引用
   • 表2 第三者中継防止のためのルールにおいて、項番2は
     「転送元　PC-LAN」「宛先メールアドレスのドメイン名　b」「転送処理　許可」と記載されています。
2. A社従業員が利用する PC-LAN からは、社内外を問わず日常業務で多数の宛先にメールを送る必要があります。従って、宛先ドメイン名を限定してしまうと通常業務が阻害されます。
3. 項番1ではインターネット→A社ドメイン名のみを許可し、項番3では業務サーバ→A社ドメイン名のみを許可しています。これらよりも前に「PC-LAN から外部を含むあらゆるドメイン名への転送を許可」する必要があります。
4. 以上より b には「全て」を入れることで、PC-LAN のメールクライアントが社外宛メールを問題なく送信でき、かつルール4（全て拒否）にフォールバックしない構成となります。

誤りやすいポイント

• 「PC-LAN＝社内だから宛先も社内限定」と誤解し、A社ドメイン名を入れてしまう。これでは外部顧客宛のメールが遮断されるため不正解となります。
• 項番4「全て拒否」が最後に適用されることを見落とし、上位ルールで網羅的に許可しておかないと送信できなくなる点を忘れがちです。
• 項番1と項番2の役割分担（外部→社内、社内→外部）を混同し、逆に設定してしまうミス。

FAQ

解答の論理構成

1. 【問題文】表5に次の記述があります。
   「・インターネットとの間は、SMTPをTLSで暗号化する c を使用してメールを転送することができる。」
   ここで求められているのは「SMTPをTLSで暗号化する方式」の正式名称です。
2. SMTPを TLS で暗号化する方式には
   ・SMTP のコマンドで TLS へ切り替える「STARTTLS」方式
   ・最初から TLS で接続する「SMTPS」方式
   の二つがあります。
3. 表5の文脈は「SMTPをTLSで暗号化する ○○ を使用してメールを転送する」とあり、接続時点で TLS が前提になっている表現です。これは SMTP の通信を最初から TLS で包む「SMTPS」に該当します。
4. 問題指示は「英字10字以内で答えよ」、正式表記「SMTPS」は要件を満たし、決定版の用語です。
5. 以上より c に入る適切な字句は
   c：SMTPS

誤りやすいポイント

• 「STARTTLS」と混同する
  STARTTLS は平文 SMTP セッション開始後に STARTTLS コマンドで暗号化へ切り替えます。設問は「TLSで暗号化する ○○ を使用」と記述しており、接続層で暗号化が完結する SMTPS が妥当です。
• 「SMTP over TLS」と書いてしまう
  語数条件と正式なプロトコル名を満たしません。
• TLS＝HTTPS の連想で「HTTPS」と回答するミス
  SMTP のプロトコルに関する設問であり、HTTP とは別です。

FAQ

解答の論理構成

1. DKIMレコードは“セレクタ”＋“_domainkey”＋“ドメイン名”で構成したFQDNを名前にします。これは DKIM の仕様（RFC 6376）で定められています。
2. 【問題文】表6にはタグの内容が示され、 ・タグ“s”の内容：z2024
   ・タグ“d”の内容：z-sha.co.jp
   と記載されています。
3. したがって、FQDN は
   z2024（セレクタ） + ._domainkey. + z-sha.co.jp（ドメイン名）
   ⇒ z2024._domainkey.z-sha.co.jp
4. 解答群と照合すると、該当するのは「エ：z2024._domainkey.z-sha.co.jp」であり、これが①で求められるFQDNです。

誤りやすいポイント

• “a”タグの値 rsa-sha256 をセレクタと誤認し、rsa-sha256._domainkey... を選んでしまう。
• _domainkey を付けずに z2024.z-sha.co.jp を選択してしまう。
• _dkim という誤ったラベルを付けてしまう（DKIM では _domainkey が正しい）。
• セレクタとドメイン名の順序を逆に書き、z-sha.co.jp.z2024._domainkey などと混乱する。

FAQ

解答の論理構成

• 図4にはDMARCレコードとして
  v=DMARC1;　p=d;　rua=mailto:rua-report@z-sha.co.jp
  が示されています。p=タグは送信ドメインが受信側に要請する処理方針（ポリシー）を指定します。
• 【問題文】「Mail-Step1」の記述に
  「送信対応では、DMARCポリシーを、特定のアクションを要求しないこととし、メールを受信してもらう。」
  とあります。
  すなわち“ブロックも隔離も指示せず、統計レポートのみ要求する”状態です。
• DMARCで“特定のアクションを要求しない”場合に設定する値は RFC 7489 で定義された none です。
  選択肢では
  イ：none
  が該当します。
  よって d に入る字句は イ です。

誤りやすいポイント

• 「メールを受信してもらう」という文言を「受信＝accept／receive」と誤読しやすいですが、DMARCの正式なポリシー値に accept や receive は存在しません。
• quarantine と reject は隔離・拒否を指示する値で、Mail-Step1 の方針と逆です。
• SPF・DKIMが整備されていても、DMARCポリシーが none の場合は実質的なブロック効果がないことを混同しがちです。

FAQ

解答の論理構成

1. 【問題文】では、A‐Webサイトが「自社製の工作機械管理用アプリケーションプログラムとそのソフトウェア修正プログラム」を公開していると明記されています。
2. さらに表7の下線②は、第三者がA‐Webサイトを見た目だけ同じにしつつ「顧客に影響を及ぼす攻撃」を行う場面です。
3. ドメイン名が本物と同じで見た目も変わらなければ、顧客は正規サイトと誤認してダウンロードを実行します。
4. 書き換えやすいポイントは「ソフトウェア修正プログラム」のリンクであり、マルウェアへ置き換えても表面的には気付きにくい構成です。
5. したがって、具体的な攻撃方法として「ソフトウェア修正プログラムに見せかけたマルウェアをダウンロードさせる」が妥当となります。

誤りやすいポイント

• フィッシングメールと混同し、Webではなくメール経由の攻撃と答えてしまう。
• 「ダウンロード」ではなく「情報改ざん」とだけ書き、顧客にどんな実害が及ぶかを示せず減点になる。
• A社側への影響（情報漏えいなど）を中心に書き、設問が求める「顧客に影響」を外してしまう。

FAQ

解答の論理構成

1. 事の発端
   問題文には、 「従業員が業務で用いる社外サービスがあり、メールでの連絡先として、A社ドメイン名のメールアドレスを登録していたとする。」
   とあります。つまり、社外サービスの「連絡先＝本人確認先」が旧ドメインのまま残っている状況です。
2. A社ドメイン名を第三者が取得した場合の結果
   同じく問題文の③下線部
   「第三者が、社外サービスからA社ドメイン名のメールアドレスへのメールを受信し、そのメールを使って続きの攻撃を行う」
   によって、攻撃者は“本人用”の通知メールを合法的に受信できてしまいます。
3. 社外サービスが送りがちなメール内容を想定
   社外サービスが本人確認やアカウント管理のために送る代表的なメールは「パスワード再設定用URL」付きメールです。これはリンクをクリックした人がパスワードを変更できる仕様になっています。
4. 受信メールの内容と攻撃シナリオ
   以上を踏まえると、 • 受信するメールの内容：社外サービスから送信される「パスワード再設定画面へのURL」が記載されたメール
   • 続きの攻撃：攻撃者がそのURLを開き「任意のパスワードを設定」→正規従業員になりすまし「アカウントを乗っ取る」
   が最も直接的で重大な被害に結びつきます。これが模範解答の根拠です。

誤りやすいポイント

• 「確認コード」「通知メール」などを答えても抽象的過ぎると減点されやすいです。URLが書かれており、クリックで即変更できるメールを明示する必要があります。
• 攻撃内容を「不正ログイン」だけで止めると、メールの内容との因果が弱く加点されにくいです。URL→パスワード変更→乗っ取りという手順を具体的に書きましょう。
• フィッシングサイトへの誘導と混同しないよう注意します。本設問は“第三者が正規メールを受信する”ケースであり、偽サイトを作る話ではありません。

FAQ

解答の論理構成

1. 【問題文】では、Mail-Step4 の後に
   「・DMARCの受信対応を行った組織がA社ドメイン名からのメールを拒否できるようにする。」
   と明記されています。すなわち、A社ドメイン名を名乗る “すべて” のメールを不正と宣言し、受信側が確実に拒否できる状態を作ることが目的です。
2. その手段として「A社ドメイン名について、SPFレコードを図5のように設定する。」とし、図5は
   「v=spf1 e」
   だけを公開する形になっています。ここに許可する送信元を一切記述しないことで、ドメイン所有者自身が「正当な送信元は存在しない」と表明する意図であることが読み取れます。
3. SPF で「正当な送信元は存在しない」と宣言する書き方は、-all（hard‐fail）です。RFC 7208 において -all は「マッチしない場合は fail とし、受信側は拒否してよい」意思表示であると定義されています。
4. よって e には -all を入れ、「v=spf1 -all」とするのが要件を満たします。
5. 解答群の中で -all に一致するのは「ア」です。

誤りやすいポイント

• ?all を選ぶと「認証結果は neutral（判断保留）」となり、受信側は拒否しないため目的を達成できません。
• SPF では block、deny、refuse といったキーワードは存在しません。類似語に惑わされないようにしましょう。
• 「メールを受信しないようにしたい＝MX レコードを削除すれば十分」と誤解しがちですが、MX がなくてもエンベロープ From で詐称メールは送信できます。DMARC/SPF で陽に “拒否してよい” と示すことが必要です。

FAQ

解答の論理構成

1. 課題の発生箇所
   • Mail-Step3 以降は「送信対応のDMARCポリシーを隔離に変更し、その6か月後、拒否に変更する。」とあり、SPFかDKIMどちらも失敗するとメールは隔離／拒否されます。
2. 一斉配信メールの仕様
   • 図6より、Tサービスは「Fromは、サービス契約者が所属する組織が保有するドメイン名を用いたメールアドレスだけを設定できる。」つまりz-sha.co.jpを使用します。
   • しかし送信自体は Tサービスの SMTP サーバから行われるため、現在登録済みの SPF 送信元(IPアドレスや include)には含まれていません。
3. 見直し対象の指示
   • 下線④ 「表3の項番3での登録内容を見直す」とある。表3 項番3は「DMARCレコード、SPFレコード及びDKIMレコードをSサービスに登録する。」です。
   • DMARC・DKIMは変更不要でも、SPFは送信元の IP／ドメインを列挙しておく必要があります。
4. 結論
   • 受信側で SPF 認証を成功させるため、「SPFレコードに、Tサービスのメール送信元IPアドレスを追加する。」という対策になります。

誤りやすいポイント

• DKIM で解決と誤解する
  Tサービスが DKIM 署名を付与する保証は問題文にないため、SPF を優先すべきです。
• DMARC ポリシー自体を緩めるという誤答
  ポリシーを変えると全体のセキュリティ水準が低下してしまいます。送信元を正しく列挙する方が適切です。
• include の書式ミス
  SPF に IP を列挙するか、include:example.com を使うかは Tサービスの提供仕様に従います。書式が誤ると“PermError”になります。

FAQ

解答の論理構成

1. SPF 判定の流れ
   • 受信側はエンベロープ From のドメイン名に対して SPF レコードを問い合わせる。
   • 図8の⑤のケースでは「ヘッダーFrom設定1」を使うので、エンベロープ From／ヘッダー From ともにドメイン名は「z-sha.co.jp」のままです。
   • 「表3　送信対応方針」の項番3には
     「DMARCレコード … SPFレコード及びDKIMキー・レコード（以下、DKIMレコードという）をSサービスに登録する。」
     とあり、権威 DNS は「Sサービス」です。
   • しかし SPF レコードに登録した送信経路は、U 社のメールサーバだけであり、メーリングリストを提供する「Yサービス」の IP／ include 句は登録していません。
     これは図7で「メールサービス事業者であるY社のサービス（以下、Yサービスという）を利用する計画」と記載されているとおりです。
   • そのため “z-sha.co.jp” の SPF レコードには Y 社の送信ホストが含まれず、Y サービスから送られたメールは SPF で Fail になります。
2. DKIM 判定の流れ
   • U サービスが送信時に付与する DKIM 署名の h タグは、表6に
     「h　From:To:Subject:Date:Message-ID:MIME-Version」
     と明示されています。Subject ヘッダーも署名対象です。
   • 図7の仕様(5)では、Subject設定2を選ぶと
     「Subject設定2：メーリングリスト宛てに送信されたメールのSubjectにメールの通番情報を付加する。」
     とあり、Y サービスが Subject を書き換えます。
   • Y サービスは(8)で「ARCには、対応していない。」と明記されており、再署名もしないので DKIM-Signature は送信元（U サービス）が付けたままになります。
   • したがって受信側が検証する際、署名時とは異なる Subject になっているためハッシュが一致せず DKIM は Fail になります。

誤りやすいポイント

• SPF ＝「送信元 IP とドメインのひも付け」と理解せず、ヘッダー From に Y 社のドメインを使わなければ問題ないと誤解する。
• DKIM は本文だけを保護すると勘違いし、Subject の書き換えでも失敗することに気付かない。
• Y サービスが ARC や再署名を行わない点を読み落とし、DKIM が通ると思い込む。

FAQ