【 支援士試験対策ドリル】情報処理安全確保支援士 厳選10問ドリル|午前II+午後ミックス

🛡️ 支援士試験対策ドリル

情報処理安全確保支援士
厳選10問ドリル|午前II+午後ミックス

よく狙われる分野を厳選。1問ごとに「なぜその答えになるか」をじっくり解説します。

📝 午前II 6問 ✍️ 午後 4問 🔐 暗号・認証・Web・ネットワーク・法令
01

🔑 暗号と認証技術

「暗号方式の特徴」「認証と認可の違い」は午前II・午後どちらでも狙われる王道分野です。

🧠

この分野のキモは「方式の名前」と「特徴」をペアで覚えること

ECC・RSA・SAML・OAuth・OIDC…名前だけ知っていても、選択肢に並ぶと混同しがちです。「何のために作られたか」から逆算して覚えるのがコツです。

午前II 問1 暗号技術

楕円曲線暗号(ECC)の特徴として、最も適切なものはどれか。

  • RSAと同等の安全性を、より短い鍵長で実現できる
  • 共通鍵暗号方式に分類される
  • ハッシュ関数の衝突耐性を利用した暗号方式である
  • 鍵交換には利用できず、署名専用の方式である
✅ 正解:ア

ECCは楕円曲線上の離散対数問題の困難さを利用した公開鍵暗号方式。RSAと同等の強度を、より短い鍵長で実現できるため、計算資源の限られるIoT機器やモバイル端末で重宝されます。鍵交換(ECDH)にも署名(ECDSA)にも使えるので、エも誤りです。

⚠ 紛らわしいポイント

「鍵長が短い=安全性が低い」と早合点しがちですが、ECCは方式自体の数学的強度が高いため短い鍵長でも十分な安全性を確保できる、という点が出題の核心です。

🚨 絶対に覚えておく定番知識

目安として「RSA 2048bit ≒ ECC 224bit」程度の強度比較がよく出題されます。鍵長の数値だけ見て判断しないよう注意しましょう。

午前II 問2 認証プロトコル

SAML、OAuth 2.0、OpenID Connectに関する記述のうち、最も適切なものはどれか。

  • OAuth 2.0は本来「認可」のためのプロトコルであり、単体では利用者の「認証」を保証しない
  • SAMLはモバイルアプリ向けに設計された軽量なJSON形式のプロトコルである
  • OpenID ConnectはOAuth 2.0より古くから存在する認証専用プロトコルである
  • OAuth 2.0のアクセストークンには、利用者の本人確認情報が必ず含まれる
✅ 正解:ア

OAuth 2.0は「リソースへのアクセス権限を委譲する=認可」のためのプロトコルで、それ単体では「この人は誰か=認証」を保証しません。認証機能を持たせるためにOAuth 2.0を拡張して作られたのがOpenID Connect(OIDC)で、ID Tokenという形で本人確認情報を提供します。

⚠ 紛らわしいポイント

「OAuthでログインする」という見た目から認証プロトコルだと誤解しがちです。SAMLはXMLベースで主にエンタープライズのSSOに使われる、比較的古い(2005年頃策定)プロトコルなので、イ・ウも誤りです。

🚨 絶対に覚えておく定番知識

「認証(Authentication:あなたは誰か)」と「認可(Authorization:何をしてよいか)」の違いは午前II・午後ともに繰り返し問われる超頻出ポイントです。

02

🌐 ネットワークセキュリティ

DNS・ファイアウォール構成は、知識問題(午前II)と設計の不備を見抜く問題(午後)の両方で出題されます。

🧩

「機密性」と「完全性」を取り違えていないか?

DNSSECのように、「改ざんを防ぐ仕組み」と「盗聴を防ぐ仕組み」が紛らわしい用語ほど狙われます。仕組みの「目的」を一言で言えるようにしておきましょう。

午前II 問3 DNSセキュリティ

DNSSECの目的として、最も適切なものはどれか。

  • DNS応答の偽造・改ざんを検知できるようにする
  • DNSクエリの内容を暗号化して通信内容を秘匿する
  • DNSキャッシュサーバの負荷を分散する
  • ゾーン転送の通信を暗号化する
✅ 正解:ア

DNSSECは公開鍵暗号によるデジタル署名をDNSレコードに付与し、応答の「完全性(改ざんされていないこと)」と「出自認証(正しいサーバからの応答であること)」を保証する仕組みです。これによりDNSキャッシュポイズニングなどの攻撃を検知できます。

⚠ 紛らわしいポイント

「DNSSEC=DNS通信の暗号化」と誤解しがちですが、DNSSECは通信内容の秘匘(機密性)は提供しません。秘匘を担うのはDNS over HTTPS(DoH)やDNS over TLS(DoT)です。

🚨 絶対に覚えておく定番知識

DNSSEC=改ざん検知(完全性・認証性)、DoH/DoT=盗聴防止(機密性)。この対比は午前IIで非常に出やすいので、セットで覚えておきましょう。

午後 問8 DMZ構成

📄 ケース

某社のネットワークは、インターネットとDMZの間にファイアウォールFW1、DMZと社内LANの間にファイアウォールFW2を設置する構成である。DMZにはWebサーバとDNSサーバが設置されている。FW2の設定を確認したところ、DMZから社内LANへの通信について、宛先ポート番号にかかわらずすべて許可する設定になっていた。

設問:このFW2の設定がセキュリティ上問題となる理由を、35字以内で述べよ。

✅ 解答例と解説

「DMZのサーバが侵害された場合、社内LANへの侵入経路として悪用される恐れがあるため」
DMZは「インターネットに公開され、侵害リスクをある程度前提とするゾーン」です。DMZ上のサーバが乗っ取られた場合、FW2が全通信を許可していると、攻撃者はそのまま社内LAN内部へ自由にアクセスできてしまいます。これは多層防御(Defense in Depth)の考え方に反します。

⚠ 採点ポイント

「DMZが侵害された場合、社内LANへの侵入経路になる」という趣旨が必須。単に「セキュリティ設定が甘い」など抽象的な記述は減点対象になりやすいです。

🚨 絶対に覚えておく定番知識

FW2の原則は「DMZから社内LANへの通信は原則拒否、必要な通信のみ個別に許可(最小権限の原則)」。DMZ構成の不備を問う問題は午後で非常に頻出です。

03

💻 Webアプリケーションセキュリティ

XSS・CSRF・SQLiの「対策キーワード」を取り違えないことが、午前IIの即答力につながります。

🛠️

攻撃名と対策キーワードをワンセットで覚える

XSS=「エスケープ」、CSRF=「トークン検証」、SQLi=「プレースホルダ」。この3点セットが頭に入っていれば、午前IIの選択肢のすり替えにすぐ気づけます。

午前II 問4 CSRF対策

CSRF(クロスサイトリクエストフォージェリ)対策として、最も適切なものはどれか。

  • 重要な処理の実行時にトークンを検証し、リクエストの正当性を確認する
  • 入力値に含まれるHTMLタグをエスケープ処理する
  • パスワードをハッシュ化して保存する
  • SQL文を組み立てる際にプレースホルダを使用する
✅ 正解:ア

CSRF対策の基本は、フォーム等にワンタイムのCSRFトークンを埋め込み、サーバ側でリクエストごとに正当性を検証する方式です。SameSite Cookie属性の設定も有効な対策の一つです。

⚠ 紛らわしいポイント

イはXSS対策、ウは認証情報保護、エはSQLインジェクション対策です。攻撃名と対策をすり替えた選択肢が並ぶのが午前IIの定番パターンです。

🚨 絶対に覚えておく定番知識

XSS=エスケープ・サニタイズ、CSRF=トークン検証・SameSite、SQLi=プレースホルダ。この3点セットを即答できるようにしておきましょう。

📄 ケース

某社のECサイトの商品検索機能では、利用者が入力した検索キーワードを文字列連結によってSQL文に組み込み、データベースへ問い合わせている。セキュリティ診断の結果、検索キーワードに特殊な文字列を入力すると、想定外のデータが返却されることが確認された。

設問:このWebアプリケーションがとるべき対策を、その理由も含めて40字以内で述べよ。

✅ 解答例と解説

「プレースホルダを使ったプリペアドステートメントを用い、SQL文の組み立てと値を分離する」
SQLインジェクションの根本原因は、利用者の入力をSQL文の一部として直接連結していることです。プレースホルダ(バインド変数)を使うと、入力値は常に「データ」として扱われ、SQL構文として解釈されなくなります。

⚠ 採点ポイント

「入力値のエスケープ処理」も部分点になり得ますが、根本対策としてはプリペアドステートメント(パラメータ化クエリ)が最も適切です。「WAFを導入する」は緩和策(多層防御の一部)にとどまり、根本対策の代替にはなりません。

🚨 絶対に覚えておく定番知識

SQLi対策の優先順位は「①プレースホルダ > ②入力値の厳格なバリデーション > ③WAFによる多層防御」。「最も適切な対策」を問われたら、まず①を軸に解答しましょう。

04

🦠 インシデント対応とマルウェア対策

「まず何をすべきか」という初動対応の順序を問う問題は、午後の鉄板テーマです。

🚑

インシデント対応の基本ステップを身体に染み込ませる

検知 → 隔離(初動) → 調査・原因特定 → 復旧 → 再発防止。午後問題ではこの順序のどこかを問われることが非常に多いです。

ランサムウェア対策として、最も適切なものはどれか。

  • オフラインまたは隔離されたネットワーク上にバックアップを定期的に取得し、復元テストも行う
  • 重要なファイルは社内の共有フォルダにのみ保存し、外部記憶媒体へのコピーは一切禁止する
  • ウイルス対策ソフトを導入していれば、バックアップは不要である
  • 感染した場合は、速やかに身代金を支払い復号鍵を入手する
✅ 正解:ア

ランサムウェア対策の本質は「感染を完全に防ぐことは難しい」という前提に立ち、感染後も復旧できる体制を整えることです。バックアップ自体が暗号化されないよう、ネットワークから隔離して保管することが重要です(いわゆる3-2-1ルール)。

⚠ 紛らわしいポイント

イは共有フォルダ上のファイルも暗号化されるため不十分、ウはウイルス対策ソフトだけでは新種・標的型を防ぎきれないため誤りです。

🚨 絶対に覚えておく定番知識

「身代金を払えば解決する」(エ)は、復号が保証されない上に攻撃者への資金供与となるため、IPA・警察庁も非推奨を明言しています。試験では必ず誤答として用意される定番の罠です。

午後 問7 インシデント初動対応

📄 ケース

某社の従業員が業務用PCで添付ファイルを開いたところ、ファイルが次々に暗号化される事象が発生した。情報システム部門が状況を確認したところ、社内ファイルサーバ上の共有フォルダのファイルも一部暗号化されていることが判明した。

設問:この事象に気付いた従業員が真っ先に取るべき行動を、25字以内で述べよ。

✅ 解答例と解説

「該当PCをネットワークから切断する(LANケーブルを抜く、Wi-Fiを切る)」
ランサムウェアは共有フォルダなどネットワーク経由で他端末・サーバへ感染を拡大させます。被害拡大を防ぐ最優先の初動対応は「ネットワークの隔離」です。

⚠ 採点ポイント

「ネットワークからの切断・隔離」という趣旨が書けていれば加点。「PCの電源を切る」と書くと、揮発性メモリ上の攻撃の証跡(フォレンジック調査に必要な情報)が失われる可能性があるため、部分点または減点対象になりやすい点に注意です。

🚨 絶対に覚えておく定番知識

インシデント対応の基本ステップ「検知 → 隔離 → 調査・原因特定 → 復旧 → 再発防止」。午後問題では常に「まず何をすべきか」を時系列で問われます。

05

⚖️ アクセス制御と法令

「認証はできているが、認可が甘い」設計不備と、個人情報保護法の改正ポイントを押さえます。

📜

「ログインできる=何でもアクセスしてよい」ではない

認可制御の不備(IDOR)も、個人情報保護法の漏えい報告義務も、「言い切り表現の選択肢を疑う」という読み方が共通して有効です。

午前II 問6 個人情報保護法

個人情報保護法における「漏えい等」が発生した場合の対応として、最も適切なものはどれか。

  • 一定規模以上の個人データの漏えい等が発生した場合、個人情報保護委員会への報告が義務付けられている
  • 漏えいした個人データが暗号化されていれば、報告義務は一切免除される
  • 個人情報保護委員会への報告は、発覚後1年以内であれば任意の時期に行えばよい
  • 漏えいの報告義務は、上場企業にのみ適用される
✅ 正解:ア

2022年4月施行の改正個人情報保護法では、要配慮個人情報の漏えいや一定数以上の個人データ漏えいなど、一定の要件を満たす場合に個人情報保護委員会への報告と本人への通知が義務化されています。報告は速報(概ね3〜5日以内)と確報(概ね30日または60日以内)の2段階です。

⚠ 紛らわしいポイント

イのように「暗号化していれば一切免除」と言い切る選択肢は要注意です。高度な技術的措置により報告対象から除外される可能性はありますが、状況による個別判断であり「一切免除」は言い過ぎです。

🚨 絶対に覚えておく定番知識

漏えい時の報告義務化(速報・確報の2段階)は近年の法改正の重要ポイントとして頻出です。報告義務は上場企業に限らず、個人情報を取り扱う事業者全般に適用されます。

午後 問10 アクセス制御(IDOR)

📄 ケース

某社の会員制Webサービスでは、マイページの注文履歴を「https://example.co.jp/order?id=1002」のようなURLで表示している。あるユーザが、自分のID番号の前後の数値にURLを書き換えてアクセスしたところ、他の利用者の注文履歴が表示されてしまった。

設問:この事象の原因と、とるべき対策をそれぞれ30字以内で述べよ。

✅ 解答例と解説

原因:「サーバ側でリクエストが本人のものかという認可チェックが行われていない」
対策:「注文IDがログイン中の利用者本人のものかをサーバ側で検証する処理を追加する」
これはIDOR(安全でない直接オブジェクト参照)と呼ばれる典型的な認可制御の不備です。認証(ログイン)はできていても、「そのリソースに本人がアクセスする権限があるか(認可)」のチェックが欠けていると発生します。

⚠ 採点ポイント

「IDを推測されにくいランダムなUUIDに変更する」だけでは不十分という点に注意。IDが何らかの形で漏えいすれば同じ問題が再発するため、本質的な対策にはなりません。

🚨 絶対に覚えておく定番知識

「認証されている=何でもアクセスしてよい」ではありません。リクエストごとに「このユーザがこのリソースにアクセスする権限を持つか」をサーバ側で必ず検証する、というのが認可制御の大原則です。IDORは午後試験のWebセキュリティ分野で頻出のテーマです。

コメント