情報処理安全確保支援士
厳選10問ドリル｜午前II＋午後ミックス
Vol.1・2で手薄だった「脆弱性管理・クラウド・サプライチェーン・ログ管理・ゼロトラスト」を集中的に潰します。
🩹 脆弱性管理編（CVSS・パッチ運用）
「CVSS基本値だけで優先順位を一律に決めてよいか」が、午前IIで繰り返し狙われるポイントです。
「数字だけで判断してよい」選択肢を疑う
CVSSスコアのような客観的な指標が出てくると、それだけで優先順位が決まると思いがちです。しかし実際には「自組織の環境」と「実際の悪用状況」を組み合わせて判断する、という流れが頻出です。
CVSS（共通脆弱性評価システム）の基本評価基準（Base Metrics）に関する記述のうち、最も適切なものはどれか。
- ア脆弱性そのものの技術的な特性に基づくスコアであり、対象システムでの対応状況や時間経過による変化を反映しない
- イCVSSスコアが同じであれば、どの組織においても対応の優先順位は常に同一になる
- ウ基本評価基準には、攻撃に必要な特権レベルや影響範囲（機密性・完全性・可用性）は含まれない
- エCVSSスコアが低い脆弱性は、自組織の環境においても優先度を下げて対応してよいと一律に判断できる
CVSS基本評価基準は、攻撃元区分・攻撃の複雑さ・必要な特権レベル・影響範囲（機密性・完全性・可用性）など、脆弱性そのものの技術的特性に基づくスコアです。現状評価基準（Temporal）や環境評価基準（Environmental）とは異なり、対応状況や時間経過、自組織の環境は反映しません。
イ・エのように「スコアだけで一律に優先順位や対応を判断できる」とする選択肢に注意。実際には各組織の資産の重要度や公開状況によって優先順位は変わります。ウは特権レベルや影響範囲が含まれないとする点が誤りです。
CVSSは「基本評価基準（Base）」「現状評価基準（Temporal）」「環境評価基準（Environmental）」の3種類から構成されます。基本値だけでパッチ適用の優先順位を機械的に決めるのは不十分、という考え方が頻出です。
脆弱性対応の優先順位付けに関する記述のうち、最も適切なものはどれか。
- ア脆弱性の実証コード（PoC）や攻撃ツールが既に公開されている場合は、CVSS基本値が低くても優先的に対応を検討する
- イパッチが提供されたら、検証環境での動作確認を行わず直ちに全ての本番環境へ適用すべきである
- ウインターネットに公開していないサーバの脆弱性は、対応の優先順位を検討する必要がない
- エベンダーから注意喚起が出ていない脆弱性は、危険度が低いと判断してよい
脆弱性対応の優先順位付けでは、CVSS基本値に加えて「実際に攻撃で悪用されているか」「悪用が容易な実証コードが公開されているか」という実際の脅威状況を踏まえることが重要です。
ウのように「非公開サーバだから検討不要」と思い込みやすいですが、内部ネットワークに侵入された場合の横展開（ラテラルムーブメント）のリスクがあるため、優先度は下げられても検討自体は必要です。
脆弱性対応の優先順位は「CVSS基本値」＋「実際の悪用状況（実証コード・攻撃事例の有無）」＋「自組織の環境（資産の重要度・公開範囲）」の3要素を組み合わせて判断します。
☁️ クラウドセキュリティ編
「責任共有モデル」と、最も多発するインシデント原因である「公開設定の放置」を押さえます。
「クラウドに預けたら安全」という誤解を捨てる
クラウド事業者が担う範囲と、利用者が担う範囲は分かれています。アクセス権限やデータの設定は基本的に利用者の責任、という前提を常に持っておきましょう。
クラウドサービス利用における「責任共有モデル」に関する記述のうち、最も適切なものはどれか。
- アアクセス権限設定やデータの管理は、サービス形態に応じて利用者側の責任となる場合がある
- イIaaS、PaaS、SaaSのいずれにおいても、物理的なセキュリティ対策はすべて利用者側の責任である
- ウクラウド事業者と契約を結べば、データの管理責任はすべてクラウド事業者に移転する
- エSaaSを利用する場合、利用者はOSやミドルウェアのパッチ適用について責任を負う
責任共有モデル（Shared Responsibility Model）では、クラウド事業者が物理インフラの安全性を担う一方、データやアクセス権限の設定など利用者側が担うべき範囲がサービス形態（IaaS/PaaS/SaaS）によって変わります。
イのように物理セキュリティを利用者側の責任とする記述や、ウのように「契約すれば全部事業者の責任になる」とする記述に注意。エもSaaSではOS・ミドルウェアの管理は事業者側の責任である点が逆になっています。
IaaS→PaaS→SaaSの順に、利用者の責任範囲は狭くなり事業者の責任範囲が広くなる、というグラデーションのイメージを持っておきましょう。
📄 ケース
某社は、クラウドサービス上のオブジェクトストレージを利用して顧客の見積書PDFを保管していた。ある日、検索エンジン経由で当該ストレージ上のファイルに誰でもアクセスできる状態になっていたことが判明した。調査の結果、ストレージのアクセス権限設定が、初期設定のまま「全世界に公開（Public）」になっていたことが原因であった。
設問：このインシデントの直接的な原因と、再発防止のために整備すべき仕組みをそれぞれ30字以内で述べよ。
原因：「ストレージのアクセス権限が公開設定のまま放置されていた」
対策：「クラウドの設定を定期的に点検する仕組み（CSPM等）を導入し、公開設定を検知・是正する」
責任共有モデルのもと、アクセス権限などの「設定」は利用者側の責任範囲です。公開バケットの放置は、クラウド環境で最も多発するインシデントパターンの一つです。
「クラウド事業者に責任がある」と書くと誤りです。CSPM（Cloud Security Posture Management）のような設定監視の仕組みや、デプロイ時のチェックリスト化など、利用者側の対策をキーワードとして含めることが重要です。
クラウド利用における設定不備（特にストレージの公開設定）は、世界的に最も多いインシデント原因の一つです。責任共有モデルのもと、利用者側が担うべき設定管理の範囲を正しく理解しておきましょう。
🔗 サプライチェーン・新型Web攻撃編
「サーバ自身に攻撃させる」SSRFと、「何を使っているか分からない」サプライチェーンリスクを押さえます。
「自分は安全」ではなく「依存先が危険」という視点
SSRFもサプライチェーン攻撃も、自社のコードが直接悪いわけではなく、信頼している先（内部API・OSSライブラリ）が悪用されるという構造が共通しています。
SSRF（サーバサイドリクエストフォージェリ）の説明として、最も適切なものはどれか。
- アサーバ自身に、攻撃者が指定した任意の宛先へリクエストを送信させる攻撃である
- イ利用者のブラウザ上で、攻撃者のスクリプトを実行させる攻撃である
- ウデータベースへの問い合わせ文に不正な文字列を注入する攻撃である
- エCookieの値を推測して他の利用者になりすます攻撃である
SSRF（Server-Side Request Forgery）は、サーバ側のアプリケーションが外部URLを取得する機能などを持つ際、利用者が指定した宛先を検証せずにリクエストを送信してしまうことで、本来アクセスできない宛先（社内の非公開サーバや、クラウドのメタデータAPI等）へサーバ自身からリクエストを送らせる攻撃です。
イはXSS、ウはSQLインジェクション、エはセッションハイジャックの説明です。「サーバ自身が攻撃者の代わりにリクエストを送る」という点が、クライアント側で実行される攻撃と混同されやすいポイントです。
SSRFはクラウド環境のメタデータAPI（インスタンスの認証情報を取得できるエンドポイント）への攻撃と組み合わされることが多く、近年重要度が増しています。対策はURLの許可リスト化や、内部アドレスへのリクエストの遮断です。
📄 ケース
某社のWebサービスは、オープンソースのJavaScriptライブラリを複数利用して開発されている。ある日、利用していたライブラリの開発者アカウントが乗っ取られ、悪意のあるコードが公式パッケージに混入して配布されるという事案（サプライチェーン攻撃）が発生した。某社では当該ライブラリの利用状況やバージョンを正確に把握できておらず、影響範囲の特定に時間を要した。
設問：このインシデントを踏まえ、今後整備すべき仕組みを、その理由も含めて40字以内で述べよ。
「利用しているソフトウェア構成要素を一覧化するSBOM（ソフトウェア部品表）を整備し、脆弱性発覚時に迅速に影響範囲を特定できるようにする」
自社が利用しているOSSライブラリやその依存関係を正確に把握していなければ、サプライチェーン攻撃が発覚した際に「自社のどのサービスが影響を受けるか」を即座に判断できません。
「ライブラリを使わないようにする」は現実的でなく不適切です。「ウイルス対策ソフトを導入する」もこの種の攻撃には直接的な効果がなく不十分。SBOMやバージョン管理・依存関係の可視化というキーワードが解答の核心です。
サプライチェーン攻撃（OSSの乗っ取り、ビルドパイプラインの侵害など）は近年急増している攻撃形態です。対策の第一歩は「何を使っているかを正確に把握すること（SBOM）」であり、これがなければ脆弱性公表時の対応スピードが大きく落ちます。
📊 ログ管理・内部不正対策編
「ログを取得しているか」と「異常を検知できるか」は別物、という点が頻出のポイントです。
ログは「取る」だけでは意味がない
ログの完全性確保（改ざん防止）と、異常検知の仕組み（SIEM等）は別の論点です。「取得している＝安心」という思い込みが午後問題で崩されます。
ログ管理に関する記述のうち、最も適切なものはどれか。
- アログの改ざんを防止するため、WORM（Write Once Read Many）media等に保管したり、ハッシュ値を別途記録して完全性を検証できるようにする
- イログは記憶領域を圧迫するため、収集後すぐに削除する運用が望ましい
- ウシステム管理者は、自身の操作ログを自由に削除できる権限を持つべきである
- エログの保存形式や保存期間は、各サーバの管理者が個別に自由に決定してよい
ログはインシデント発生時の調査や不正の検知に不可欠な情報であり、攻撃者やインサイダーによる改ざん・削除を防ぐ仕組み（WORM媒体への保管、ハッシュ値による完全性検証、外部のログ収集サーバへの即時転送等）が重要です。
ウのように「管理者には強い権限を持たせるべき」という発想から飛びつきやすいですが、操作した本人がログを削除できる状態こそが、不正の隠蔽を可能にする最大のリスクです（職務分離の原則に反します）。
ログ管理の3要素「完全性の確保（改ざん防止）」「適切な保存期間」「アクセス権限の分離（操作者自身が消せない）」は頻出です。
📄 ケース
某社の従業員Cは、退職を決意した後、在職中に営業部門の顧客リストおよび見積データを、私用のクラウドストレージへ大量にアップロードしていた。情報システム部門が事後にログを確認したところ、退職前の2週間に、通常の業務時間外に大量のファイルアクセス・外部アップロードが発生していたことが記録されていたが、当時は誰も気付かなかった。
設問：今後同様の内部不正を早期に検知するために整備すべき仕組みを、35字以内で述べよ。
「通常と異なるアクセスパターンを検知し、アラートを発するログ監視（SIEM等）の仕組みを整備する」
内部不正は正当な権限を持つ利用者による行為であるため検知が難しく、業務時間外の大量アクセスや通常と異なるデータ持ち出しといった「振る舞いの異常」を自動検知する仕組み（SIEM、UEBA等）が有効です。
「ログを取得する」だけでは「事後に確認できる」状態にすぎず、設問が求める「早期に検知する」というリアルタイム性を満たしません。「全従業員のアクセスを禁止する」のような極端な対策も業務に支障が出るため不適切です。
内部不正対策では「ログを取得しているか」だけでなく「異常を検知してアラートを発する仕組みがあるか」が重要です。ログがあっても誰も見ていなければ意味がない、という点が午後試験で問われます。
🧭 ゼロトラスト・テレワーク編
「社内だから信頼する」を捨てる考え方と、デバイスの状態検証の重要性を押さえます。
「誰が」だけでなく「どのデバイスで、どんな状態か」
ID・パスワードによる認証だけでは、侵害されたデバイスからの正規利用者によるアクセスを防げません。ゼロトラストでは、デバイス側の健全性も継続的に検証します。
ゼロトラストの考え方に関する記述のうち、最も適切なものはどれか。
- ア社内ネットワークの内部からのアクセスであっても、利用者やデバイスの状態を都度検証し、暗黙的な信頼を与えない
- イ社内ネットワークの境界に強固なファイアウォールを設置し、内部は無条件に信頼するという考え方である
- ウ一度認証に成功した利用者は、その後のすべてのリソースへのアクセスが無条件に許可される
- エゼロトラストの導入には、VPNによる境界防御の強化のみで対応できる
ゼロトラストは「社内・社外を問わず、いかなる通信も信頼せず、アクセスごとに利用者・デバイス・コンテキストを検証する」という考え方で、従来の「境界の内側は信頼する」境界型防御モデルからの転換を意味します。
イはまさに従来の境界型防御の考え方であり、ゼロトラストとは正反対です。ウも認証成功後にアクセスごとの継続的な検証が行われない点が誤り、エもVPN強化のみでは実現できない点が誤りです。
ゼロトラストの原則は「Never Trust, Always Verify（決して信頼せず、常に検証する）」。社内ネットワークだからといって無条件に信頼しない、という点が繰り返し問われます。
📄 ケース
某社はテレワークを推進しており、従業員は社外から自宅のPCやスマートフォンを使って社内システム（クラウド上の業務システム）にVPNなしで直接アクセスできる環境を構築した。アクセス時にはID・パスワードによる認証のみが行われており、利用するデバイスのセキュリティパッチの適用状況やウイルス対策ソフトの稼働状況は確認されていなかった。ある日、私物PCがマルウェアに感染した状態のまま業務システムにアクセスされ、認証情報が窃取される事案が発生した。
設問：ゼロトラストの考え方に基づき、このシステムに追加で実装すべき仕組みを、その理由も含めて40字以内で述べよ。
「ID・パスワードに加えて、デバイスのセキュリティ状態を検証し、満たさない場合はアクセスを拒否する仕組みを導入する」
ゼロトラストでは「誰が」だけでなく「どのデバイスから、どのような状態で」アクセスしているかを継続的に検証することが求められます。ID・パスワードのみの認証では、デバイス自体が侵害されている場合のリスクを防げません。
「多要素認証を導入する」も有効な対策ですが、この設問は「私物PCがマルウェアに感染していた」ことが直接の原因であるため、デバイスの状態検証（コンプライアンスチェック）に言及することが解答の核心です。MFAだけでは「侵害されたデバイスからの正規利用者によるアクセス」というリスクには対応できません。
ゼロトラストの実装は「利用者の認証（だれか）」と「デバイスの状態検証（何で、どんな状態か）」の両方をセットで継続的に検証することが基本です。VPNの有無に関わらず、この検証プロセスがなければゼロトラストとは言えません。
コメント