情報処理安全確保支援士
厳選10問ドリル｜午前II＋午後ミックス
無線LAN・コンテナ・デシリアライズ・監査/ISMS・脆弱性診断という、まだ手薄だった分野を一気に潰します。
📶 無線LANセキュリティ編
WPA3の「何が強化されたか」と、Personal/Enterpriseの認証方式の違いを押さえます。
「耐性が高い」と「絶対安全」は別物
WPA3は確かにWPA2より安全ですが、「原理的に不可能」「完全に防げる」のような言い切りには要注意です。技術が進歩しても、運用（パスフレーズの強度等）が甘ければリスクは残ります。
WPA3に関する記述のうち、最も適切なものはどれか。
- アDiffie-Hellman鍵交換を応用したSAE（Simultaneous Authentication of Equals）を採用し、オフライン辞書攻撃への耐性を高めている
- イWPA2と同じ4ウェイハンドシェイクを用いるため、KRACK攻撃に対する耐性はWPA2と変わらない
- ウWPA3-Personalでは、利用者ごとに異なる暗号鍵を自動生成するため、辞書攻撃は原理的に不可能である
- エWEPやWPAとの後方互換性を完全に維持しており、設定変更なしにそのまま置き換えることができる
WPA3はSAE（Dragonflyハンドシェイクとも呼ばれる）を採用し、WPA2のPSK方式で問題となっていたオフライン辞書攻撃への耐性を大幅に高めています。
イは誤りで、WPA3はKRACK攻撃の原因となった脆弱性を解消するためハンドシェイク方式自体を変更しています。ウのように「原理的に不可能」と言い切るのも誤り。耐性が高まっただけで、弱いパスフレーズへの注意は依然必要です。
WPA3の核心はSAEによるオフライン辞書攻撃への耐性強化です。WPA2のKRACK脆弱性と対比して覚えましょう。エのように脆弱なWEP/WPAとの後方互換性を安全側の特徴として書く選択肢にも注意です。
WPA2/WPA3のPersonalモードとEnterpriseモードに関する記述のうち、最も適切なものはどれか。
- アEnterpriseモードでは、IEEE 802.1XとRADIUSサーバを用いて利用者ごとに個別の認証情報で認証を行う
- イPersonalモードでは、利用者ごとに異なる認証サーバを用意する必要がある
- ウEnterpriseモードは、家庭用の小規模なネットワークに最適化された、設定が簡単な認証方式である
- エPersonalモードとEnterpriseモードは、暗号化方式が異なるだけで、認証の仕組みは同一である
Enterpriseモードは、IEEE 802.1X（ポートベース認証）とRADIUSサーバを用いて、利用者ごとに異なるID・パスワードや証明書で認証を行う方式です。企業など利用者を個別に管理したい環境に向きます。
「Personal」「Enterprise」という名称から規模感だけで判断しがちですが、本質的な違いは認証方式（共有鍵 vs 個別認証）です。ウのようにEnterpriseを家庭用と説明するのは誤りです。
Personal＝PSK（共有鍵）、Enterprise＝802.1X＋RADIUS（個別認証）。退職者対応のしやすさ（Enterpriseなら退職者のアカウントだけ無効化できる、Personalだと全員分のPSK変更が必要）もセットで覚えておくと運用面の問題にも対応できます。
📦 コンテナ・Kubernetes編
「カーネルを共有する」というコンテナの構造上の特性が、分離の弱さに直結する点を理解します。
「便利だから」で広げた権限が事故の入口になる
特権モードでのコンテナ起動は、開発時の便利さから安易に使われがちですが、ホストとの分離を実質的に無効化してしまいます。便利さとリスクのトレードオフを意識しましょう。
コンテナ技術のセキュリティ上の特性に関する記述のうち、最も適切なものはどれか。
- アコンテナは、ホストOSのカーネルを共有して動作するため、仮想マシン（VM）に比べてプロセス間の分離レベルが相対的に低くなりやすい
- イコンテナは、ホストOSとは独立したカーネルを持つため、VMと同等以上の分離レベルを常に実現する
- ウコンテナイメージは、公式に公開されているものであれば、脆弱性スキャンを行う必要はない
- エコンテナを特権モード（privileged）で実行することは、セキュリティ上のリスクを増やさない安全な標準的運用である
コンテナはホストOSのカーネルを共有するため、カーネルレベルの脆弱性や設定不備があれば、コンテナを脱出してホストや他のコンテナに影響を及ぼす（コンテナエスケープ）リスクがあり、VM（独立したカーネルによる強い分離）に比べて分離レベルが相対的に低くなりやすいです。
ウのように「公式イメージだから安全」と思い込むのは危険です。依存ライブラリの脆弱性等があり得るため、公式イメージでも脆弱性スキャンは必要です。エの特権モードも安全とは言えません。
コンテナのセキュリティ対策は「最小権限での実行（非特権・非root）」「イメージの脆弱性スキャン」「ホストカーネルとの分離を補強する仕組み（seccomp、AppArmor等）」がセットです。
📄 ケース
某社では、開発の効率化のため、コンテナを特権モード（–privileged）で起動し、ホストのデバイスファイルへの直接アクセスを許可する運用をしていた。ある日、コンテナ内で稼働していたWebアプリケーションの脆弱性を突かれ、攻撃者がコンテナ内に侵入したところ、特権モードの設定によりホストOS側のファイルシステムにまでアクセスでき、最終的にホスト全体が侵害される事案が発生した。
設問：このインシデントの根本原因と、再発防止のために講じるべき対策をそれぞれ30字以内で述べよ。
原因：「コンテナを特権モードで起動し、ホストへのアクセス権限を不必要に広げていた」
対策：「コンテナの実行に必要な最小限の権限のみを付与し、特権モードでの起動を原則禁止する」
特権モードはコンテナにホストのほぼ全てのデバイス・カーネル機能へのアクセスを許可してしまうため、コンテナ内への侵入がそのままホストの侵害に直結します。
「Webアプリケーションの脆弱性を修正する」だけでは不十分です。個別の脆弱性対応だけでは、コンテナの権限設定という構造的な問題が残ります。「特権モードの使用を避ける」「最小権限の原則」がキーワードです。
特権モード（–privileged）は開発時の便利さから安易に使われがちですが、ホストとの分離を実質的に無効化してしまう設定です。最小権限の原則はコンテナ環境にもそのまま当てはまります。
🧬 デシリアライズ攻撃編
「暗号化していれば安全」という思い込みを崩す、データの「内容」を信頼してしまう脆弱性です。
機密性（暗号化）と完全性・信頼性（内容の正しさ）は別の話
盗聴されないこと（暗号化）と、改ざんされたデータをそのまま処理してしまわないこと（入力の信頼性）は、まったく別の論点です。セットで守る必要があることを意識しましょう。
安全でないデシリアライズ（Insecure Deserialization）に関する記述のうち、最も適切なものはどれか。
- ア信頼できない入力をオブジェクトに復元する処理を通じて、攻撃者が意図しないコードの実行などを引き起こす脆弱性である
- イWebブラウザ上でJavaScriptを実行させることを目的とした攻撃である
- ウデシリアライズ処理は、シリアライズ処理と異なり、入力データの構造を一切解釈しないため、安全性に問題が生じることはない
- エデシリアライズ攻撃への対策は、通信を暗号化することで十分である
安全でないデシリアライズは、攻撃者が改ざんしたシリアライズデータをアプリケーションが検証せずにオブジェクトへ復元してしまうことで、意図しないコードの実行（リモートコード実行）などを引き起こす脆弱性です。OWASP Top 10にも繰り返し挙げられる重大なリスクです。
エのように「暗号化していれば安全」と思いがちですが、通信の暗号化（機密性の確保）とデシリアライズ処理自体の安全性は別の論点です。ウもデシリアライズが構造を解釈する処理であることを否定しており誤りです。
安全でないデシリアライズの対策は「信頼できないデータのデシリアライズを避ける」「許可された型のみをデシリアライズ対象にする（allowlist化）」が基本です。
📄 ケース
某社のWebアプリケーションでは、利用者のログイン状態を保持するために、シリアライズ化したオブジェクトをCookieに保存し、リクエストごとにそのCookieの値をデシリアライズして利用者情報を復元する実装になっていた。セキュリティ診断の結果、Cookieの値を改ざんすることで、アプリケーションサーバ上で任意のコードが実行できる脆弱性が確認された。
設問：このWebアプリケーションが実装すべき対策を、その理由も含めて40字以内で述べよ。
「利用者の状態管理にはシリアライズ化したオブジェクトを使わず、セッションIDのみをCookieに保持し、実データはサーバ側で管理する」
クライアント側に渡したシリアライズデータは利用者によって自由に改ざんできます。状態管理はサーバ側のセッションストアで行い、クライアントには推測困難なセッションIDのみを渡すのが安全な設計です。
「Cookieの値を暗号化する」のみでは不十分です。暗号化しても、復号後にデシリアライズする処理自体に脆弱性が残れば同じ問題が起きる可能性があります。「サーバ側でのセッション管理」がキーワードです。
安全でないデシリアライズは、対症療法的な対策（暗号化、署名の付与）だけでは限界がある場合が多く、「信頼できない入力をそもそもデシリアライズしない」という設計上の見直しが最も効果的な対策とされます。
📋 監査・ISMS編
「一度やれば終わり」ではない継続的改善の考え方と、規程と実態のギャップへの向き合い方を押さえます。
「規程はあるが守られていない」は重大な指摘事項
規程と実態が食い違っている状態を放置すると、規程そのものが形式的なものになってしまいます。内部監査の役割は、このギャップを見つけ、組織として向き合うきっかけを作ることです。
ISMS（情報セキュリティマネジメントシステム）に関する記述のうち、最も適切なものはどれか。
- アPlan（計画）・Do（実行）・Check（点検）・Act（改善）のサイクルを継続的に繰り返すことで、情報セキュリティ水準を維持・向上させる
- イISMSの認証を一度取得すれば、その後は内部監査や見直しを行う必要はない
- ウリスクアセスメントは、ISMS構築時に一度実施すればよく、その後の見直しは不要である
- エ内部監査は、被監査部門の担当者自身が実施することが望ましい
ISMSはPDCAサイクルを継続的に回すことで、情報セキュリティリスクの変化や組織の状況変化に対応し、セキュリティ水準を維持・向上させる仕組みです。
イ・ウのように「一度やれば終わり」とする選択肢に注意。ISMSの本質は継続的な改善サイクルです。エも内部監査の客観性確保の観点で誤りで、被監査部門から独立した者が実施することが望ましいです。
PDCAサイクルの各フェーズ（Plan＝リスクアセスメントと対策計画、Do＝対策の実施、Check＝内部監査・モニタリング、Act＝見直し・改善）の対応関係を覚えておきましょう。内部監査の独立性（自己監査の回避）も頻出ポイントです。
📄 ケース
某社では、情報セキュリティ管理規程に「特権IDの利用申請は、利用開始の3営業日前までに申請書を提出し、上長の承認を得ること」と定められていた。内部監査の結果、実際の運用では、緊急時を中心に多くの特権ID利用が事後申請（利用後の事後報告）で済まされており、規程どおりの事前承認が行われていないケースが過半数を占めていることが判明した。
設問：この監査結果を踏まえ、組織がとるべき対応として適切な考え方を、35字以内で述べよ。
「実態の業務に即した運用となるよう規程を見直すか、規程どおりの運用を徹底するよう統制を強化する」
「規程はあるが守られていない」状態は重大な不適合であり、放置すれば規程自体が形式的なものになってしまいます。実態に合わせて規程を整備し直すか、規程どおりの運用を徹底できるよう統制を強化するか、いずれかを選択し一致させる必要があります。
「すべて事前申請を徹底させる」という運用面の徹底のみでも一定の評価はできますが、緊急時対応など現実的な業務上の制約も考慮し、「規程の見直し」と「運用の徹底」の両方の可能性に言及できているとより高評価です。「特に問題ない」という現状維持の判断は誤りです。
内部監査で発見される典型的な指摘事項は「規程と実態の不一致」です。対応は、規程を現実に合わせて見直すか、運用を規程に合わせて統制を強化するか、のいずれかであり、見て見ぬふりをすることは不適合の放置にあたります。
🔍 脆弱性診断・ペネトレーションテスト編
「見つけること」と「直されたか確認すること」は別の工程、という診断後のプロセスを押さえます。
診断は「広く浅く」、ペネトレーションテストは「狭く深く」
脆弱性診断とペネトレーションテストは目的が違います。そしてどちらも、「実施した」だけでは終わらず「修正されたか」までの追跡が伴って初めて意味を持ちます。
脆弱性診断とペネトレーションテストに関する記述のうち、最も適切なものはどれか。
- ア脆弱性診断は既知の脆弱性を網羅的に検出することを目的とし、ペネトレーションテストは特定の目標の達成可能性を実際に試みることを目的とする
- イ脆弱性診断とペネトレーションテストは同じ手法であり、呼び方が異なるだけである
- ウペネトレーションテストは、必ず自動化されたスキャナのみを用いて実施される
- エ脆弱性診断によって「脆弱性なし」と判定されれば、システムへの侵入は不可能であると保証できる
脆弱性診断は既知の脆弱性を網羅的かつ広く検出することを目的とし、主にツールによる自動スキャンが中心です。ペネトレーションテストは、実際に「攻撃者の視点」で特定の目標の達成を試み、実際の侵入可能性や被害の深刻度を検証することを目的とします。
ウのように自動スキャナのみで実施されるとするのは誤りで、ペネトレーションテストは手動でのシナリオベースの試行が中心です。エのように「脆弱性なし＝侵入不可能」と保証する記述も言い過ぎです。
脆弱性診断＝「広く浅く（網羅性）」、ペネトレーションテスト＝「狭く深く（実証性）」という対比で覚えましょう。
📄 ケース
某社では、半年前に実施した脆弱性診断で「重要度：高」と判定されたWebアプリケーションの脆弱性が報告されていたが、開発担当者の人員不足を理由に対応が先送りされ、修正されないまま放置されていた。先日、当該の脆弱性を悪用した攻撃により、顧客情報が外部に流出する事案が発生した。
設問：この事案を踏まえ、脆弱性診断の実施に加えて整備すべき仕組みを、その理由も含めて40字以内で述べよ。
「検出された脆弱性の対応状況を期限付きで管理し、重要度に応じた対応期限内に修正されたことを確認・追跡する仕組みを整備する」
脆弱性診断を実施して問題点を発見するだけでは不十分で、検出された脆弱性が実際に修正されるまでを追跡管理（脆弱性管理プロセス）しなければ、診断結果が報告されただけで放置されてしまいます。
「診断の頻度を増やす」だけでは、既に検出済みの脆弱性が放置されている根本問題（対応プロセスの欠如）には対応できません。「修正状況の追跡・管理」という運用プロセスのキーワードが採点上の核心です。
脆弱性診断は「見つけること」がゴールではなく、「見つけた脆弱性が適切に修正されること」までを管理する脆弱性管理プロセスの一部です。「診断したのに直さない」問題は、実際のインシデントでも頻発する典型パターンです。
コメント