情報処理安全確保支援士 2021年 春期 午後2 問02

解答の論理構成

1. 問題文では、下線①として「①上位2オクテットが169.254に設定されたIPアドレス」が示されています。
2. 169.254.0.0/16 は、RFC3927 で定義された「リンクローカルアドレス（Automatic Private IP Addressing: APIPA）」に割り当てられている特殊なアドレス帯です。
3. リンクローカルアドレスは DHCP から正規の割当てが受けられないときに OS が自動設定し、同一リンク内だけで通信する際に用いられます。
   － 問題文の K さんのコメント「“障害が発生したC-PCのIPアドレスは、DHCPサーバが正常に動作していない場合にしばしば確認される”」も、この特徴と合致します。
4. よって、①が示す IP アドレスの呼称は「リンクローカルアドレス」であり、解答群の「オ」に該当します。

誤りやすいポイント

• 169.254.. は “プライベート” と誤解しやすいですが、プライベートアドレスは「10.0.0.0/8」「172.16.0.0/12」「192.168.0.0/16」です。
• 127.0.0.1（ループバック）と混同するケースもあります。用途もアドレス帯も異なるので注意しましょう。
• DHCP で配られる＝プライベート、配られない＝グローバルと短絡的に覚えると誤答に繋がります。169.254.. は「DHCP が失敗した時に自動で付与される特別な帯域」です。

FAQ

解答の論理構成

1. 【問題文】には「個人所有機器のC社内LANへの接続は統制しておらず、多くの従業員は、個人所有機器をAPに接続して使用している。」とあります。ここで “多く” の接続端末＝貸与ＰＣ以外の端末が多数存在する状況が示されています。
2. DHCP サーバが割り当てるアドレス範囲は「192.168.1.20～192.168.1.240」の 221 個（240 – 20 + 1）しかありません。
3. 一方、従業員は 「従業員150名」 で、会社貸与の「C-PC」150台に加えて個人所有端末（スマートフォン等）が無制限に接続されます。貸与分だけで 150 アドレスを要し、個人端末が加われば 221 個を容易に超えます。
4. アドレス枯渇時に新たにネットワークへ参加した端末は DHCP からアドレスを取得できず、自動的に「①上位2オクテットが169.254に設定されたIPアドレス」（APIPA）を自分で設定します。
5. 169.254.. はローカルリンク専用であり、【問題文】のとおり「業務サーバにアクセスできず、メールの送受信もインターネット上のWebサイトの閲覧もできなかった」状態になります。
6. したがって下線②の指摘は、 ・多過ぎる個人所有機器接続 → DHCP アドレス枯渇
   ・結果として C-PC が 169.254.. になり通信不能
   という因果関係を説明しています。

誤りやすいポイント

• 偽 DHCP サーバや攻撃ツールの存在を疑ってしまい、純粋なアドレス枯渇という “資源不足” の可能性を見落とす。
• 169.254.. を“攻撃で設定された異常値”と誤解し、APIPA 自動設定の仕組みに気付かない。
• アドレスプール「192.168.1.20～192.168.1.240」が十分だと思い込み、貸与ＰＣ台数（150）と個人端末数を合算して検証しない。

FAQ

解答の論理構成

1. 目的の確認
   本文には「コメント2：念のために、③UTM以外にDHCPサーバが稼働しているかどうかも調査するとよい。」とある。
   したがって、UTMを基準に“他の DHCP サーバ”の有無を確認する方法を考える。
2. 稼働させたまま調査する理由と手順
   ・「UTMは…DHCPサーバの機能も備えており、APに接続する機器に192.168.1.20～192.168.1.240の範囲のIPアドレスを配布している。」とある。
   ・同一セグメントで複数の DHCP サーバが応答すると、クライアントは複数の DHCPOFFER を受信する。
   ・よって、L2SW でポートミラーリングを設定し、LAN モニタ（パケットキャプチャ）で DHCPDISCOVER／DHCPOFFER を観察すれば、OFFER 数＞1 で“他サーバ存在”を判定できる。
3. UTM を停止して調査する理由と手順
   ・「C社内LANのネットワークセグメントは一つだけである。」ため、UTM を停止すれば唯一の DHCP が不在になる。
   ・クライアントが 169.254.x.x（APIPA）になるか、DHCPDISCOVER へ応答がないことを確認できれば、“他サーバなし”と判断できる。
   ・もし IP アドレスが正常配布されれば、別の DHCP が動作している証拠となる。
4. 上記を55字以内で具体化
   模範解答のように、 ・稼働時：ミラーポート＋DHCPOFFER の数確認
   ・停止時：IP アドレス配付有無確認
   という二本立てとなる。

誤りやすいポイント

• ARP や ping で DHCP サーバを探そうとし、ブロードキャストで応答しない機器を見落とす。
• クライアントが取得した IP アドレスだけを見て「UTM 以外はない」と早合点する。OFFER をすべて捕捉して初めて判定できる。
• UTM 停止時に静的 IP 設定端末が通信できるのを見て“DHCP が生きている”と誤認する。

FAQ

解答の論理構成

1. 事故の背景
   ・【問題文】では「状況1」で、サービスRのチャットエリアが第三者により改ざんされた可能性が示されています。
   ・しかし「状況3」にあるとおり、無料プランでは「アクセスログを提供できない」という制約があります。
2. E部長の指示内容
   ・E部長は「仮に情報漏えいがあった場合、最大でどの程度の被害となり得るか」を把握するために、下線部④「アクセスログの調査以外に実施できる調査」を指示しました。
3. 被害規模を推定するために確認すべき対象
   ・アクセスログが取れない以上、攻撃者が読み取れた・持ち出せた可能性のある情報を把握する必要があります。
   ・サービスRでは「企画部の部員がアクセスできるチャットエリア」で情報共有が行われているため、チャット内の投稿・添付ファイルが流出対象となり得ます。
4. 結論
   したがって、④で実施すべき調査は「企画部の部員がアクセスできるチャットエリアで共有されている情報」を網羅的に洗い出すことになります。

誤りやすいポイント

• 「チャット以外の全社共有フォルダ」など別サービスの情報を答えてしまう。
• 「部員全員の端末ログ」などアクセスログの範疇に入る調査を挙げてしまう。
• 「チャットエリアの書き込み履歴」とだけ書き、添付ファイルや共有リンクを含め忘れる。
• 40字以内を意識するあまり、主語（調査対象）を欠落させて意味不明になる。

FAQ

解答の論理構成

1. 802.1Xの三者
   802.1Xでは「サプリカント（端末）―認証装置（ネットワーク機器）―認証サーバ」という三者で認証を行います。
2. サプリカントに該当する機器
   本文には
   ――「図2中のサプリカントには図1中の a が該当する。」
   とあります。サプリカントは無線LANに接続しようとする端末です。図1で従業員が利用する端末は「C-PC」だけです。したがって
   a：C-PC
3. 認証装置に該当する機器
   本文には
   ――「図2中の認証装置には図1中の b が該当する。」
   とあります。無線LAN側で端末と認証サーバの間に立つ機器はアクセスポイントです。図1の該当機器名は「AP」です。したがって
   b：AP

誤りやすいポイント

• 802.1Xの「認証装置」をUTMやL2SWと誤認する。認証装置は無線区間で端末と直接やり取りするアクセスポイントです。
• サプリカントを「AP」と逆に覚えてしまう。サプリカントは“クライアント側ソフトウェア”であり、端末（C-PC）に載ります。

FAQ

解答の論理構成

1. 問題文の前提
   • 「C-PCのIPアドレスは、図2中の c 、DHCPサーバから割り当てられる。」と明記されています。
   • 図2の802.1Xシーケンスでは、1. 認証要求の開始 から 6. 暗号鍵の配布 までが無線 LAN 接続確立のための認証・鍵配布フェーズです。
2. DHCPによる IP アドレス割当のタイミング
   • DHCP のブロードキャスト通信が成立するためには、無線区間が暗号化／復号化できる状態、すなわち暗号鍵が確立済みである必要があります。
   • 鍵が確立するのは「6. 暗号鍵の配布」完了時点です。したがって DHCP はその“後”に初めて機能します。
3. 選択肢との対応
   • 解答群のうち、暗号鍵配布後を示すのは「エ：“6. ”より後に」です。
   • よって c に入るのは「エ」。

誤りやすいポイント

• 「EAP 認証が成功すればすぐに DHCP が始まる」と早合点し、「ウ：“6. ”と同時に」を選んでしまう。実際には鍵配布が完了してから無線リンクが開通します。
• 「認証装置が認証サーバへ転送した時点で IP が付く」と誤解する。IEEE 802.1X では認証成功前にデータフレームは遮断されています。
• シーケンス番号と電文内容を結び付けず、図を暗記頼みで判断してしまう。

FAQ

解答の論理構成

1. まず本文には、アクセス制御を強化した場合の懸念として
   「総務Gが契約したSaaS、企業情報検索、出張先への経路検索及びC社の情報システムへのアクセスだけを許可し、それ以外へのアクセスを全て遮断すると、⑤支障が出る業務がある。」
   と記載されています。
2. どの業務が支障を受けるかを探すため、社内でインターネットを幅広く利用している部署・業務を確認します。
   • 「事業部及び企画部では、顧客への提案や企画の立案時にインターネット上にある多くの情報を収集、取捨選択、加工することによって付加価値を生み出すことが不可欠である」
     という記述があり、多様なサイトへのアクセスが前提であると分かります。
3. したがって “許可リスト以外のサイトは全て遮断” という方針を取ると、上記の「多くの情報を収集」する活動が不可能または極めて困難になります。
4. 以上より、⑤で指摘する「支障が出る業務」は
   「インターネットを使って情報収集する業務」
   すなわち「事業部や企画部の顧客への提案や企画の立案」に他なりません。

誤りやすいポイント

• 「企業情報検索」「出張先への経路検索」もインターネット利用だが、これらは例外として許可対象に含まれている点を見落とす。
• “情報収集” を単に Web サイト閲覧全般と捉え、具体的な業務名を答えずにしまう。
• 「営業部の活動」と誤答する。営業部は主に取引先検索であり、許可対象に含まれるため支障は小さい。

FAQ

解答の論理構成

1. 要件の整理
   【問題文】では要件4として
   「“業務で利用するSaaSは、総務Gが契約したSaaSだけに制限する。また、業務に不要なWebサイトへのアクセスを制限する。”」
   と明記されています。ここで求められているのは
   ① 指定された SaaS 以外へのアクセス遮断
   ② 不要な Web サイト遮断
   という“URL を基準にしたアクセス制御”です。
2. 表3 の機能確認
   表3 にはサービスNが提供する機能が並んでおり、番号「2」は
   「“URLフィルタリング機能”」であり、内容として
   「“サービスNが中継する際に、アクセス可能なURLを制限する。”」
   と説明されています。この機能は URL 単位で許可／遮断を設定でき、要求①②を同時に満たせます。
3. 他機能との比較
   • 番号「1」は「“利用者IDによるフィルタリング機能”」で ID に基づく制御であり、Web サイト遮断までは対象外です。
   • 番号「3」は可視化、番号「4」は暗号化であり、いずれも URL 制限には直接関与しません。
4. 結論
   したがって要件4を実現する機能は表3中の番号「2」です。

誤りやすいポイント

• 「総務Gが契約したSaaSだけに制限」という文言から番号「1」を選択してしまう。ID 制御は“誰が”を決められますが、“どこへ”を制御できず Web サイト制限要件を満たしません。
• 番号「4」の“保管時の自動暗号化機能”は情報漏えい対策（要件7 対応）であり、アクセス制御とは目的が異なります。
• URL フィルタリング＝ブラックリストと思い込み、「情報収集を妨げない」という条件に合わないと判断してしまう。実際にはホワイト／ブラックの両方で細かい調整が可能です。

FAQ

解答の論理構成

1. 要件5の狙い
   • 【問題文】では要件5を「総務Gが契約したSaaSには、総務Gが管理するアカウントでアクセスする。C-PCからは、従業員が個人で管理するアカウントでのアクセスができないようにする。」と定義しています。
   • つまり「許可した利用者 ID だけを SaaS に通し、それ以外は遮断する」機能が必要です。
2. 表3の機能を照合
   • 表3の番号「1」は「利用者IDによるフィルタリング機能」であり、内容は「Pソフトで、SaaSへのログイン時に、許可された利用者IDの場合だけ通信を許可し、その他の利用者IDの場合は通信を遮断する。」「許可する利用者IDは、管理者がSaaSごとに設定できる。」です。
   • この説明は要件5の「総務Gが管理するアカウントのみ許可し、個人アカウントを禁止する」要求に完全に合致します。
3. 他の機能との比較
   • 番号「2」は URL フィルタリングであり、ID 単位の制御を行いません。
   • 番号「3」「4」は可視化や暗号化であり、アクセス可否の判定には直接関与しません。
   • よって、要件5を直接実現できるのは番号「1」のみです。
4. 結論
   • 表3中の番号「1」が該当するため、解答は「1」となります。

誤りやすいポイント

• URL フィルタリング（番号「2」）と混同する
  「Web サイトへのアクセス制限」と聞くと URL フィルタリングを連想しがちですが、要件5は ID ベースの制御が目的です。
• サービスQの認証機能と誤解する
  シングルサインオンは「誰がログインできるか」を決めるだけで「個人アカウントの通信を遮断する」までは行いません。実際の遮断はサービスNの「利用者IDによるフィルタリング機能」が担います。
• 「暗号化＝セキュリティ強化」と短絡的に考える
  番号「4」の自動暗号化機能は情報漏えい対策であり、アカウント統制とは別の目的です。

FAQ

解答の論理構成

1. どこで遮断されるか
   • 本文の下線⑥は「総務Gが管理していない機器からのサービス要求があった場合は、シーケンスが途中で遮断される」と説明しています。
   • その判定は、サービスNが「機器からインターネットへの通信を全てサービスN経由で行うなどの制御」を担う Pソフトと連携して行われます。Pソフトはエージェントのため「一般利用者権限では動作の停止やアンインストールができない」とあり、運用管理下か否かを区別できます。
   • 認証自体は「サービスQ」の「2 接続元の認証」で明記されている「ディジタル証明書によるTLSクライアント認証1)」によって行われます。
   • 図3のシーケンスを見ると、サービスNがサービスQに「5. 認証要求」を送り、利用者が「6. 利用者の認証」を行います。ここで TLS クライアント認証に失敗すれば 7 以降には進めません。
   • したがって遮断箇所は「5.〜6.」すなわち解答群「ウ」に該当します。
2. どう判定するか
   • 管理下機器の判断材料として本文には「ディジタル証明書」「TLSクライアント認証」が示されています。
   • 管理下であれば Pソフトとともに社内 CA が発行した端末証明書が格納されており、サービスQでの TLS クライアント認証に成功します。
   • 管理外機器は証明書を持たないため TLS ハンドシェイク時に失敗し、サービスQ側で拒否されます。

誤りやすいポイント

• 「1.〜2.」や「3.〜4.」と早い段階で遮断されると誤解する
  → 図3ではまだ認証要求が発生しておらず、判定材料が不足しています。
• URLフィルタリングと混同し、サービスN側だけで遮断できると思い込む
  → 機器管理の有無は TLS クライアント証明書で担保され、URL フィルタは別用途です。
• 「ディジタル証明書＝ユーザ証明書」と早合点
  → 本文では「クライアント認証」であり、端末証明書（機器証明書）を想定しています。

FAQ

解答の論理構成

• 【問題文】には、要件6について「⑦SaaS又はSaaS事業者が何らかのセキュリティ規格に準拠していることの第三者による認証を確認する」と明記されています。
• ここで求められているのは「第三者認証」を受けている具体的な“規格又は認証”の名称の例です。
• 金融・クラウドサービス分野で代表的な第三者認証としては、監査報告書規格の「ISAE3402/SSAE16」や、情報セキュリティマネジメントシステムの「ISMS認証」（ISO/IEC 27001）が広く知られています。
• いずれもクラウド事業者が取得していれば、利用企業は客観的にセキュリティ体制を確認できるため、上記【問題文】の要件を満たす“例”となります。

誤りやすいポイント

• SOC1, SOC2 など英語表記のみで「20字以内」を超えてしまう書き方をする。
• 自社の内部規程や「プライバシーマーク」のような個人情報保護認証を挙げてしまい、クラウドサービスの総合的な情報セキュリティ認証とずれてしまう。
• 「ISO27017」「ISO27018」などガイドライン系の番号を出し、第三者認証を取得できる体系かどうかを確認せずに回答してしまう。

FAQ

解答の論理構成

1. 【問題文】では要件7を次のように定義しています。
   ――「要件7：業務で利用するSaaSからの情報漏えいを防ぐための技術的対策を導入する。」
2. 要件7を実現するための方策として、本文は以下の手順を示します。
   ――「SaaSで重要な情報を扱う場合、当該SaaSで利用可能ならば表3中の番号dの機能を利用する。それによって、サービスNを経由しない不正アクセスによるSaaSからの情報漏えいを防ぐ」
3. ここで求められているのは、「サービスN」を経由しない経路であっても情報が漏えいしないようにする仕組みです。
   すなわち、SaaS側に保存されるデータ自体を保護できる機能が必要です。
4. 表3の各機能を照合すると、該当するのは次の項目です。
   ・番号「4」「保管時の自動暗号化機能」
    ―「一部のSaaSに対し、そのSaaSが提供するAPIを使って、特定フォルダに保管するファイルを自動的に暗号化することができる。」
5. 「保管時の自動暗号化」は保存データを暗号化し、アクセス経路とは無関係に漏えいリスクを低減します。よって要件7の趣旨に完全に合致します。
6. 以上より、d に入る番号は「4」です。

誤りやすいポイント

• 「利用者IDによるフィルタリング機能（番号1）」を選ぶミス
  → アクセス制御は経路依存であり“サービスNを経由しない”場合の保護には不十分です。
• 「可視化機能（番号3）」を選ぶミス
  → ログ取得は事後対策であり、漏えいそのものを直接防ぐ機能ではありません。
• 「URLフィルタリング機能（番号2）」と混同
  → URL制御も経路依存であり、保存データの保護にはつながりません。

FAQ

解答の論理構成

1. 要件2は「業務での個人所有機器の利用を禁止する」と明記されています。
   引用: 「要件2：業務での個人所有機器の利用を禁止する。テレワークに必要なPCは貸与する。」
2. その実現策として本文は「機器をクライアント認証することにした」と記述し、ディジタル証明書方式を採用しています。
   引用: 「要件2については、業務で利用するC社の情報システムやSaaSへのアクセスの際、機器をクライアント認証することにした。」
3. クライアント証明書を持出C-PCにだけ入れておけば個人所有機器からの接続は不可能になります。しかし、従業員が証明書の秘密鍵をエクスポートできてしまうと個人端末へコピーして接続される恐れがあります。
4. したがって「従業員によって無効にされない」ためには、証明書の秘密鍵を端末外へ持ち出せないよう OS 証明書ストアで「秘密鍵のエクスポート禁止」を設定する必要があります。
5. 以上から解答は「秘密鍵を書き出しできないように設定する」となります。

誤りやすいポイント

• 「一般利用者権限だけを与える」だけでは、管理者権限を奪取された場合に証明書が持ち出されてしまう危険を見落としやすい。
• BIOS／UEFIやディスク暗号を答えにしてしまい、クライアント認証に使われる証明書管理の観点を外してしまう。
• 「証明書にパスワードを掛ける」と答え、コピー自体は許してしまう点に気付かない。

FAQ

解答の論理構成

1. 要件4・5では「総務Gが契約したSaaSだけ利用させ、従業員個人のアカウントや不要なWebサイトを排除する」ことが求められています。
2. これを実現・維持するための仕組みとして本文は「機器からインターネットへの通信を全てサービスN経由で行うなどの制御を行う端末制御エージェントソフトウェア（以下、Pソフトという）」と記述し、さらに「管理者は、Pソフトを、一般利用者権限では動作の停止やアンインストールができないように設定することができる。」と明示しています。
3. また、移行時の方針として「C-PCは管理者権限による管理を総務Gが行い、従業員には一般利用者権限だけを与える」としており、従業員が勝手に設定を変えられない状態が前提です。
4. 以上より、要件4・5を確実に担保するには「Pソフト」を「一般利用者権限では変更できないように設定する」必要がある、との結論になります。

誤りやすいポイント

• ソフトウェア名をサービスQと勘違いしやすい。サービスQは認証基盤、通信制御はPソフトが担当します。
• 「インストールする」だけでは不十分で、「一般利用者権限では停止・削除できない」設定が必須である点を見落としやすいです。
• 要件6・7の暗号化機能と混同して、保管時暗号化の設定を書いてしまうケースがあります。

FAQ