情報セキュリティマネジメント ― マネジメント系 問題一覧・解説

📝 解説

ISMSの認証規格はISO/IEC 27001です。ISMS（Information Security Management System：情報セキュリティマネジメントシステム）とは、組織が情報セキュリティを継続的に管理・改善するための仕組み（Plan-Do-Check-Act）であり、ISO/IEC 27001はその仕組みが適切に整備・運用されているかを審査する国際規格です。企業の品質管理システムに例えると、ISO 9001が「品質管理の仕組みが整っているか」を第三者が審査・認証するように、ISO/IEC 27001は「情報セキュリティの管理体制が整っているか」を第三者が審査・認証します。認証を取得することで、取引先・顧客に対して「自社の情報セキュリティ管理が国際水準で認められている」ことを客観的に示せます。政府の調達要件やクラウドサービスの選定基準にもなっており、日本では2万件以上の組織が認証取得しています。誤答の「ISO 9001」は品質マネジメントシステムの規格、「ISO 14001」は環境マネジメントシステムの規格、「ISO/IEC 20000」はITサービスマネジメントの規格です。「ISMS認証規格＝ISO/IEC 27001・情報セキュリティ管理体制の国際規格」と確実に覚えましょう！

📝 解説

情報セキュリティリスクアセスメントの流れは「リスク特定→リスク分析→リスク評価→リスク対応」の4ステップです。健康診断に例えると、①リスク特定＝「全身の各部位を検査し問題候補を洗い出す（資産・脅威・脆弱性の特定）」②リスク分析＝「各所見の深刻さを評価する（発生可能性×影響度でリスク値を算出）」③リスク評価＝「治療が必要か様子見でいいか判断する（リスク許容度と比較して優先度付け）」④リスク対応＝「具体的な治療方針を決める（回避・低減・移転・受容の選択）」です。ISO/IEC 27005に基づくリスクアセスメントでは、情報資産（顧客データ・システム等）ごとに想定される脅威（不正アクセス・災害等）と脆弱性（未パッチ・弱いパスワード等）を組み合わせてリスクを特定し、定量的・定性的に分析します。誤答の「対策実施→リスク特定」はリスクを特定する前に対策を実施してしまっており正しくありません。「リスクアセスメントの流れ＝特定→分析→評価→対応のこの順序」と確実に覚えましょう！

📝 解説

リスク対応策の「リスク移転（転嫁）」は「リスクが現実化した場合の損失を、契約・保険などを通じて第三者に負担させる」対応策です。自動車保険に例えると、事故（リスク発生）の際の修理費・対人賠償（損失）を保険会社に支払ってもらう仕組みが、まさにリスクの移転（転嫁）です。サイバー保険への加入もこれと全く同じ発想で、「ランサムウェア感染・情報漏洩による損害賠償・復旧費用・事業中断損失」を保険会社に転嫁します。ただし保険に入ってもリスク自体がなくなるわけではなく、あくまで金銭的損失を分散させるだけである点が重要です。リスク対応4種の整理：①リスク回避（リスクのある活動をやめる）②リスク低減（対策を実施してリスクの発生確率・影響を減らす）③リスク移転（保険・アウトソーシング等で損失を第三者に転嫁）④リスク受容（許容範囲内として特別な対処をしない）。誤答の「リスクの高いサービスを中止する」はリスク回避、「セキュリティ対策を実施してリスクの影響を軽減する」はリスク低減の説明です。「リスク移転＝損失を保険・契約で第三者に負担させる・サイバー保険が典型例」と覚えましょう！

📝 解説

リスク対応策の「リスク受容（保有）」は「リスクを明確に認識した上で、対策コストがリスクによる損失を上回る・または影響が許容範囲内と経営的に判断して、あえて特別な対策を取らない」選択肢です。旅行の保険に例えると、「国内旅行の1泊2日程度なら万が一のリスクは限られているし、旅行保険料の方が見込み損失より高くつく」と判断して保険に入らないのがリスク受容の発想です。これは「無知・無対策」とは全く異なり、リスクを認識した上での意図的な経営判断である点が重要です。リスク受容が適切なケース：①発生可能性が非常に低い②発生しても損失額が小さい③対策コストの方が損失より大きい、という条件が揃う場合です。ISO/IEC 27001ではリスク許容度（Risk Appetite）を経営層が明確に定め、その範囲内に収まるリスクを受容するプロセスを求めています。誤答の「リスクを完全に取り除く」はリスク回避、「リスクを保険で転嫁する」はリスク移転、「リスクを低減する対策を実施する」はリスク低減の説明です。「リスク受容＝リスクを認識した上で許容範囲内と判断して特別な対策を取らない経営的意思決定」と覚えましょう！

📝 解説

CSIRT（Computer Security Incident Response Team：シーサート）は「組織内でセキュリティインシデント（不正アクセス・情報漏洩・マルウェア感染・DDoS攻撃等）が発生した際に、組織的・体系的に対応する専門チーム」です。病院の救急チームに例えると、救急患者（セキュリティインシデント）が搬送されたとき、担当ごとに役割分担された救急チーム（CSIRT）が素早く組織的に診断・治療（インシデント対応）にあたるように、CSIRTも役割分担と連携のもとでインシデントに対応します。CSIRTの役割は「有事だけでなく平時も重要」で、①平時：セキュリティ情報の収集・分析・教育・手順書整備②有事：検知・封じ込め・根絶・復旧・報告対応・法執行機関との連携を担います。国内外のCSIRT間での脅威情報共有を行うのが「NCA（日本CSIRT協議会）」「JPCERT/CC」などです。企業規模によっては専任チームではなく兼任チームとして整備されることもあります。誤答の「セキュリティ製品を開発するチーム」はベンダーの開発部門、「社内のITインフラを管理するチーム」はIT運用チーム（別部門）の説明です。「CSIRT＝セキュリティインシデントに組織的に対応する専門チーム・平時の準備も重要」と覚えましょう！

📝 解説

セキュリティインシデント対応の手順は「検知→封じ込め→根絶→復旧→事後対応」の順番が正解です。火事への対応に例えると、まず「火事だ！」と気づく（検知）→「燃え広がらないよう周囲をふさぐ（封じ込め）」→「火種を完全に消す（根絶）」→「部屋を元通りにする（復旧）」→「なぜ火事が起きたか原因を調べて次に備える（事後対応）」という流れと全く同じです。封じ込めをせずに根絶しようとすると被害が拡大しますし、根絶せずに復旧すると再発してしまいます。順番に意味があるので丸暗記ではなく、この流れの「なぜ」を理解して覚えましょう！誤答の選択肢はこの順番を入れ替えたものばかりです。

📝 解説

セキュリティ教育・訓練の目的は「従業員のセキュリティ意識を高め、人的ミスや内部不正を防ぐこと」です。電気設備の保安管理で例えると、どれだけ最新の遮断器（技術的対策）を設置しても、作業員が安全手順を知らずに誤操作したら事故は起きます。情報セキュリティも同じで、最先端のファイアウォールやウイルス対策ソフトを導入していても、従業員が怪しいメールの添付ファイルを開く・パスワードを付箋に書くといった行動をとれば守れません。技術的対策だけでは補えない「人」という最大の脆弱点を補うのが教育・訓練の本質的な目的です。「ITの知識習得」や「システムの強化」は副次的効果に過ぎません。

📝 解説

標的型メール訓練の目的は「実際の攻撃メールに見立てたメールを送り、従業員の対応能力と意識レベルを確認・向上させること」です。消防訓練で例えると、本当の火災が起きてから初めて消火器を練習するのでは遅い。定期的に「訓練です！」と火災警報を鳴らして実際に避難させることで、いざ本番になっても慌てず動けるようになります。標的型メール訓練も同じで、訓練メールを開封・クリックしてしまった従業員を「責める」のではなく、その人たちを特定して追加教育を行う「気づきの機会」として活用します。メールシステムのテストや配信テストが目的ではありません。「人を育てる」のが正しい訓練の目的です！

📝 解説

情報セキュリティポリシーは「基本方針→対策基準→実施手順」の3階層で構成されます。鉄道会社の安全管理で例えると、①「安全を最優先に列車を運行する」（基本方針＝経営トップの宣言）→②「制限速度を超えた場合は自動停止装置を作動させる」（対策基準＝具体的ルール）→③「出発前にブレーキの動作確認手順は○○の順に行う」（実施手順＝現場の作業手順書）という階層構造と同じです。基本方針は変わらない大方針、対策基準はそれを実現するルール、実施手順は日常の具体的操作手順と役割が異なります。「基本方針のみ」や「技術的対策のみ」では不完全。3階層セットで機能する点が重要です！

📝 解説

セキュリティ監査の目的は「情報セキュリティ対策が適切に実施されているかを、独立した立場で確認・評価すること」です。電車の安全検査で例えると、電車を運行している会社の整備士が自分で「問題なし」と判断するだけでなく、国土交通省の検査官（第三者）が独立した立場で車両を点検します。「独立した立場」がポイントで、自社の担当者が自分の仕事を自分で評価しても客観性が担保できません。内部監査（社内の監査部門）と外部監査（第三者機関）があり、どちらも「ポリシーや法令・規格への準拠状況を客観的に確認する」目的は同じです。「セキュリティ製品の選定」「事故の修復」は監査の目的ではありません。

📝 解説

内部不正対策の基本は「職務の分離・最小権限の付与・ログの監視・定期的な権限見直しを組み合わせる」ことです。銀行の窓口業務で例えると、1人の行員が「お金の受け取り」「帳簿への記録」「金庫への入金」を全部1人でできてしまうと横領のリスクが高まります。そこで役割を分けて「防止」「抑止」「検知」を組み合わせることが内部不正対策の鉄則です。最小権限とは「業務に必要な最低限のアクセス権しか与えない」こと、ログ監視は「不正の証拠を残し抑止力にする」こと。「全従業員に全権限」は論外です。単一の対策ではなく複数の対策の組み合わせが正解の理由で、試験でもここが問われます！

📝 解説

情報資産の分類・管理の目的は「情報の重要度に応じた適切な保護レベルを設定すること」です。郵便物の管理で例えると、ハガキ（誰でも見られる）・普通郵便（封筒で中身は見えない）・書留（受け取り確認が必要）・機密書類便（担当者のみ受け取り可能）のように、重要度に応じて扱い方を変えますよね。情報資産も「公開」「社外秘」「機密」「極秘」などに分類し、それぞれに異なるアクセス制限・保管方法・廃棄方法を定めます。重要でない情報に過剰な保護をかけるのも非効率で、重要な情報を無保護にするのも危険です。「情報の量」「保存期間」「フォーマット」の管理は別の目的です！

📝 解説

サプライチェーンリスクとは「自社だけでなく、取引先・委託先・ベンダーなどの供給連鎖の弱いリンクを突いて攻撃者が侵入するリスク」です。水道のインフラで例えると、浄水場（自社）の設備がどれだけ堅牢でも、そこへ原水を供給する上流のポンプ設備（取引先）を攻撃者が汚染したら、自社の対策だけでは防げません。2020年のSolarWinds事件では、広く使われるITツールのアップデートにマルウェアが混入し、数千もの組織が被害を受けました。「直接自社を攻撃する」より「信頼された取引先経由」で侵入する手口は近年急増しています。「在庫不足」「物流の遅延」はセキュリティとは別のサプライチェーンリスクです！

📝 解説

クラウドのセキュリティ責任共有モデルは「IaaS・PaaS・SaaSのサービスモデルごとに、ベンダーと利用者の責任範囲を分担する」考え方です。マンション管理で例えると、建物の構造・共用設備（インフラ）は管理会社の責任ですが、部屋の中の家具や鍵の管理（アプリとデータ）は入居者の責任ですよね。IaaSでは「物理サーバまで」がベンダー責任で、OSから上は利用者。PaaSではミドルウェアまでベンダー、アプリ以上は利用者。SaaSはほぼベンダー責任ですが、アクセス管理や設定は利用者責任です。「すべてベンダーが責任を負う」は誤りで、特にアクセス管理・データ設定の責任を利用者が怠るとセキュリティ事故につながります！

📝 解説

BYOD（Bring Your Own Device）のセキュリティリスクとして最も重要なのは「個人端末は会社のセキュリティポリシーの適用・管理が難しく情報漏洩リスクが高い」ことです。社員証の管理で例えると、会社が発行した社員証なら紛失時に即時無効化できますが、個人のスマホに入った会社データは紛失しても即座に対処できません。個人端末はセキュリティパッチの適用が個人任せになりがちで、私用アプリからのマルウェア感染・業務データの端末への残留・紛失時の情報漏洩リスクが伴います。「会社支給端末より管理コストが高い」は逆で、BYOD導入でコストを抑えることが多いです。管理できないからこそリスクが高まるのが本質です！

📝 解説

テレワーク環境で「適切でない」のは「公共のフリーWi-Fiで機密情報を扱う」ことです。道路のインフラで例えると、一般道路（フリーWi-Fi）は誰でも通行できますが、管理されたトンネル（VPN）は許可された車両だけが走れます。カフェや空港のフリーWi-Fiは多くの場合、通信が暗号化されておらず、同じネットワーク上の悪意ある第三者が通信内容を盗み見る中間者攻撃のリスクがあります。機密情報を扱う場合は必ずVPNを使って暗号化した専用トンネルを確立するのが基本です。VPN接続・画面ののぞき見防止・セキュリティソフトの導入は正しいテレワーク対策です。この問題は「適切でないもの」を選ぶ逆問いなので注意しましょう！

📝 解説

情報セキュリティの組織的管理策「職務の分離（Segregation of Duties）」の目的は「1人の人間が不正行為を完結させること・誤りが見逃されることを防ぐこと」です。会計インフラで例えると、1人の経理担当者が「伝票の作成」「上司の承認」「振込の実行」をすべて1人でできるようになっていると、横領を行っても発覚しにくくなります。そこで役割を分けて「作成する人・承認する人・実行する人」を別々にすることで、不正の機会を排除します。ITでも「プログラム開発者が本番環境に直接リリースできない」「バックアップの実施者とバックアップの検証者を分ける」などが職務の分離の実例です。「業務効率の向上」や「コスト削減」は逆に効率が下がる面もありますが、それでも内部不正防止のために実施する対策です！

📝 解説

情報セキュリティにおけるログ管理の目的は「不正アクセスや異常な操作の検知・証拠保全・原因調査に活用すること」です。鉄道の運行記録で例えると、列車の速度・位置・ドア開閉のログが残っていることで、事故発生時に「どこで何が起きたか」の正確な原因調査ができます。サイバーセキュリティのログも同様に、「誰がいつ・どのシステムに・どのような操作をしたか」を記録することで、インシデントの早期検知・不正の証拠保全・コンプライアンス要件（監査ログの保存義務）を満たします。重要なのはログを「ただ保存するだけ」でなく、改ざん防止・集中管理（SIEM）・定期的な監視・レビューを組み合わせることです。「システムの性能向上」「ストレージ容量管理」は別の目的です！

📝 解説

セキュリティパッチを定期的に適用する理由は「CVE等で公開された既知の脆弱性を修正して、その脆弱性を悪用した攻撃のリスクを低減するため」です。道路インフラで例えると、橋の亀裂（脆弱性）が発見されて報告書（CVE）が公開されたら、すぐに補修工事（パッチ適用）をしないと、その亀裂を知った悪意ある人物がその橋を破壊しようとするリスクが高まります。ソフトウェアの脆弱性も、CVEで公開された瞬間から攻撃者がその脆弱性を利用するツール（エクスプロイト）を作り始めます。パッチ未適用のシステムは既知の攻撃手法が確立されているため、攻撃者にとって格好のターゲットです。「機能追加」はアップデートの目的の一部ですがセキュリティパッチの主目的ではなく、「ライセンス要件」「パフォーマンス向上」は別の話です！

📝 解説

情報セキュリティインシデント報告の目的は「迅速な対応による被害拡大の防止・関係者への通知・再発防止策の策定に活かすこと」です。ガス漏れ事故の対応で例えると、ガス漏れを発見した人が「自分の責任問題になるかもしれない」と隠してしまうと、爆発事故に発展する可能性があります。すぐに報告することで、被害が広がる前に対処できます。情報セキュリティインシデントも同様で、個人情報保護法では漏洩が発生した場合の個人情報保護委員会への報告・本人への通知義務が定められており、報告を怠ることは法的義務違反になります。「担当者の責任追及」が目的でないことが特に重要で、責任追及を恐れた隠蔽は二次被害の拡大につながる最悪の対応です！

📝 解説

クリアスクリーン・クリアデスクポリシーの目的は「離席時に画面をロックし机上に情報資産を放置しないことで情報漏洩を防ぐこと」です。電車内の荷物管理で例えると、席を立つときに財布・スマホ・書類を席に放置したまま離れると、第三者に見られたり持ち去られたりするリスクがあります。オフィスも同じで、離席時にPCをロックせずに放置すると第三者が画面を見たり操作したりできます。机に機密書類・USBメモリ・パスワードのメモを放置するのも同様のリスクです。この対策は特別な技術投資なしに「習慣とルール」だけで実施できる手軽なセキュリティ対策ですが、継続的な意識啓発と定着化が課題です。「整理整頓」はあくまで副次的効果であり、情報漏洩防止が本来の目的です！

📝 解説

委託先のセキュリティ管理として適切なのは「契約でセキュリティ要件を明示し定期的に監査・確認すること」です。工事の外部委託で例えると、建設会社が工事を下請け業者に任せる際、「安全基準を守ること」を契約書に明記し、定期的に現場監督が確認に来なければ、下請けが手抜き工事をしていても気づけません。情報セキュリティも同様で、委託先に情報を渡した後は「委託先が勝手に守ってくれる」という前提は危険です。契約にNDA・情報取り扱い基準・サブ委託の承認・監査権を明記し、定期的にセキュリティ状況を確認・評価することが自社情報の保護につながります。近年のサプライチェーン攻撃を踏まえ、委託先管理は非常に重要なセキュリティ課題として位置づけられています！

📝 解説

MDMは、会社から支給されたスマホやタブレットを、本部のパソコンから魔法のように一括操作する仕組みのことです。身近な例でいうと「学校の図書管理システム」をイメージしてみてください。どの本が誰の手元にあるか、返却期限はいつか、勝手に持ち出されていないかを先生がカウンターで一元管理していますよね。これのスマホ版がMDMです。社員が勝手に怪しいアプリを入れないように制限したり、紛失した時に遠隔でロックをかけたりできます。正解の選択肢にある通り、「一元的に管理する」という点が最大のポイントです。これが無いと、社員一人ひとりのスマホ設定を情シス担当者が手作業で見回らなければならず、管理がパンクしてしまいます。セキュリティレベルを組織全体で一定に保つための、現代の必須ツールといえますね。

📝 解説

リモートワイプは、まさに「デジタルな自爆装置」です！例えば、大事な機密書類が入ったカバンを電車に忘れてしまったとしましょう。普通なら誰かに拾われないかビクビクするしかありませんが、もしそのカバンに「ボタン一つで中身をシュレッダーにかけて白紙にする機能」がついていたら安心ですよね？それがリモートワイプの正体です。万が一スマホを紛失したり盗まれたりしても、管理者がネットワーク越しに「消去命令」を送ることで、端末内のデータを瞬時に消し去ることができます。選択肢にある「遠隔消去」という言葉がキーワードです。犯人の手に渡って中身を見られる前に、データを空っぽにしてしまえば、物理的な端末は失っても「情報の漏洩」という最悪の事態だけは防げる、という論理的な守り方なんです。

📝 解説

「残留リスク」とは、どんなに頑張って対策しても、どうしてもゼロにできずに残ってしまうリスクのことです。例えば、家の防犯を考えてみましょう。頑丈な鍵を付け、防犯カメラを設置し、警備会社と契約したとします。これでかなり安全になりますが、「隕石が落ちてきて家が壊れる」とか「プロの泥棒が壁を爆破して入ってくる」といった極めて低い可能性のリスクは、完全には消せませんよね。この「色々やったけど、まだ残っている不安要素」が残留リスクです。セキュリティの世界では、お金や手間を無限にかけることはできないので、「ここまでのリスクは対策した。残った分は、もし起きたらその時に対応しよう（あるいは諦めよう）」と経営者が納得して受け入れる必要があります。選択肢にある「対策を実施した後もなお残る」という表現が、この概念を完璧に表しています。

📝 解説

この問題は「絶対にやってはいけないこと」を選ぶ問題ですね！正解は「ログを削除する」です。これは火事で例えると、火元を調べるための手がかりを、パニックになって燃やして消してしまうようなものです。個人情報が漏洩したとき、最も大切なのは「どこから、何が、なぜ漏れたのか」を突き止めて再発を防ぐことです。そのための貴重な証拠が「ログ（通信の記録）」なんです。ログを消してしまうと、原因究明ができなくなるばかりか、世間からは「何かやましいことを隠しているんじゃないか？」と疑われ、企業の信頼は地に落ちてしまいます。適切な対応は、まず被害を広げないためにシステムを切り離し、次に証拠であるログをしっかり保存して調査することです。証拠隠滅は、セキュリティ管理における最大の「禁じ手」だと覚えておきましょう。