665 lines
126 KiB
JavaScript
665 lines
126 KiB
JavaScript
export const CATEGORIES = [
|
||
{ id:'basics', label:'セキュリティ基礎', icon:'shield', units:[
|
||
{ id:'s01', num:'S01', title:'CIA三要素', freq:'high', diff:1,
|
||
concept:`<p>情報セキュリティの根幹は<strong>CIA三要素</strong>です。すべてのセキュリティ対策はこのどれかを守るために存在します。</p><div class="formula-box"><div class="formula-label">初学者向け：用語のイメージ</div><strong>機密性</strong>：秘密にしたい内容を、許可のない人に見られないようにすること。<br><strong>完全性</strong>：データが途中で改ざんされていないかを確認できること。<br><strong>可用性</strong>：サービスやファイルを、必要なときにいつでも使える状態に保つこと。</div><div class="viz-cia"><div class="cia-card cia-c"><div class="cia-name">機密性</div><div class="cia-en">Confidentiality</div><div class="cia-desc">許可された人だけが情報にアクセスできる。暗号化・アクセス制御で実現。</div></div><div class="cia-card cia-i"><div class="cia-name">完全性</div><div class="cia-en">Integrity</div><div class="cia-desc">情報が正確で改ざんされていない。ハッシュ・デジタル署名で検証。</div></div><div class="cia-card cia-a"><div class="cia-name">可用性</div><div class="cia-en">Availability</div><div class="cia-desc">必要なときに情報を使える。冗長化・バックアップで確保。</div></div></div><p>開発者視点で言い換えると：機密性は「見せない」、完全性は「改ざんさせない」、可用性は「止めない」です。DoS攻撃は可用性を、SQLインジェクションは機密性・完全性を脅かします。</p>`,
|
||
examtips:[
|
||
'三要素のどれが損なわれているかを問う問題が頻出。攻撃とCIA要素のマッピングを整理すること。',
|
||
'<strong>真正性（Authenticity）・信頼性（Reliability）・否認防止（Non-repudiation）</strong>など追加要素も出題される。CIAだけが全てではない。',
|
||
'DoS攻撃→可用性、盗聴→機密性、改ざん→完全性。この対応を即答できるようにする。'
|
||
],
|
||
keypoints:[
|
||
'機密性（C）：許可された者だけがアクセスできる。暗号化・認証で守る',
|
||
'完全性（I）：データが正確で改ざんされていない。ハッシュ・署名で検証',
|
||
'可用性（A）：必要なときに使える。冗長化・DDoS対策で守る',
|
||
'真正性：通信相手が本当に本人かを確認できること（認証で実現）',
|
||
'否認防止：後から「やっていない」と言えないようにする（ログ・署名）'
|
||
],
|
||
quiz:[
|
||
{q:'DoS攻撃が損なう主なCIA要素はどれか。',choices:['機密性','完全性','可用性','真正性'],answer:2,exp:'DoS攻撃はサービスを停止させ、利用できなくするため可用性を損ないます。'},
|
||
{q:'盗聴によって主に損なわれるCIA要素はどれか。',choices:['可用性','完全性','機密性','信頼性'],answer:2,exp:'盗聴は許可なく情報を取得するため、機密性が損なわれます。'},
|
||
{q:'ハッシュ値を用いてデータが改ざんされていないことを確認する行為は、主にどのCIA要素を守るものか。',choices:['機密性','完全性','可用性','否認防止'],answer:1,exp:'ハッシュによる改ざん検知は完全性（Integrity）を守る手段です。'},
|
||
{q:'情報セキュリティの3要素（CIA）に含まれないものはどれか。',choices:['機密性','可用性','拡張性','完全性'],answer:2,exp:'拡張性（Scalability）はCIA三要素に含まれません。機密性・完全性・可用性が三要素です。'}
|
||
]
|
||
},
|
||
{ id:'s02', num:'S02', title:'脅威・脆弱性・リスク', freq:'high', diff:1,
|
||
concept:`<p>リスク管理の基礎概念を整理します。<strong>脅威</strong>は攻撃者や災害など「悪いことが起きる原因」、<strong>脆弱性</strong>はシステムや運用の「穴」、<strong>リスク</strong>はそれらが組み合わさって「実際に被害が発生する可能性と影響度」です。</p><div class="formula-box"><div class="formula-label">初学者向け：3語の違い</div><strong>脅威</strong>：被害をもたらし得る「原因側」（マルウェア、災害、内部不正など）。<br><strong>脆弱性</strong>：攻撃や事故に利用されやすい「弱点」（未パッチ、弱いパスワード設定など）。<br><strong>リスク</strong>：脅威が脆弱性を突いたときに、どれだけ損失が起きうるかという見込み。</div><div class="formula-box"><div class="formula-label">リスクの計算（概念式）</div>リスク = 脅威 × 脆弱性 × 資産価値<br><br>リスク対応の4戦略：<br>・回避（リスクが生じる活動をやめる）<br>・低減（対策を実施して確率・影響を下げる）<br>・移転（保険・外部委託でリスクを移す）<br>・受容（コスト対効果で許容する）</div><p>開発者にとって「脆弱性」とはバグや設定ミスのこと。CVEデータベースに登録される脆弱性情報は、脅威アクターが攻撃に利用する前にパッチを当てるために使います。</p>`,
|
||
examtips:[
|
||
'脅威・脆弱性・リスクの定義の違いを問う問題は毎回出る。「脆弱性」は弱点であり攻撃そのものではない。',
|
||
'リスク対応4戦略（回避・低減・移転・受容）の具体例を各1つ言えるようにする。',
|
||
'残留リスク：対策後にも残るリスクのこと。ゼロにはできないことを前提に許容・監視する。'
|
||
],
|
||
keypoints:[
|
||
'脅威：資産に損害を与える原因となり得るもの（マルウェア・内部不正・災害）',
|
||
'脆弱性：脅威が利用できるシステムや運用の弱点（パッチ未適用・設定ミス）',
|
||
'リスク：脅威が脆弱性を突くことで損害が発生する可能性と影響の組み合わせ',
|
||
'リスク対応：回避・低減・移転・受容の4戦略',
|
||
'残留リスク：対策後も残るリスク。経営判断で受容・監視する'
|
||
],
|
||
quiz:[
|
||
{q:'「パッチが未適用のため既知の脆弱性が存在するシステム」はリスク管理上、何に該当するか。',choices:['脅威','脆弱性','リスク','インシデント'],answer:1,exp:'未パッチのシステムは攻撃者に利用される「穴」であり、脆弱性に該当します。'},
|
||
{q:'サイバー保険を契約することで損害発生時の費用リスクを保険会社に負わせる対応は、リスク対応の4戦略のうちどれか。',choices:['回避','低減','移転','受容'],answer:2,exp:'保険やアウトソースでリスクを第三者に転嫁することをリスク移転と呼びます。'},
|
||
{q:'リスクアセスメントの手順として正しい順序はどれか。',choices:['リスク特定→リスク評価→リスク分析','リスク特定→リスク分析→リスク評価','リスク評価→リスク特定→リスク分析','リスク分析→リスク評価→リスク特定'],answer:1,exp:'JIS Q 27005に基づくリスクアセスメントは「特定→分析→評価」の順です。'},
|
||
{q:'脅威と脆弱性の説明として正しい組み合わせはどれか。',choices:['脅威：パッチ未適用／脆弱性：マルウェア','脅威：マルウェア／脆弱性：パッチ未適用','脅威：暗号化／脆弱性：認証','脅威：ファイアウォール／脆弱性：DoS'],answer:1,exp:'マルウェアは脅威（攻撃原因）、パッチ未適用は脆弱性（システムの弱点）です。'}
|
||
]
|
||
},
|
||
{ id:'s03', num:'S03', title:'認証技術', freq:'high', diff:2,
|
||
concept:`<p>認証は「あなたが本当にあなたか」を確認するプロセスです。認証要素は3種類あり、複数組み合わせることで強度が上がります。</p><div class="formula-box"><div class="formula-label">初学者向け：よく出る言葉</div><strong>認証（Authentication）</strong>：利用者が本人かどうかを確認すること（ログイン）。<br><strong>認可（Authorization）</strong>：本人でも「どのデータや操作を許すか」を決めること（権限）。<br><strong>多要素認証（MFA）</strong>：知識・所持・生体など<strong>種類の異なる</strong>要素を2つ以上使うこと（同じ種類を2回は多要素にならない場合がある）。</div><div class="formula-box"><div class="formula-label">認証の3要素</div>知識要素（Something you know）：パスワード・PIN・秘密の質問<br>所持要素（Something you have）：ICカード・スマートフォン・ハードウェアトークン<br>生体要素（Something you are）：指紋・顔認証・虹彩</div><p>2要素以上を組み合わせるのが<strong>多要素認証（MFA）</strong>。SSOはIDPが認証を一元管理し、アプリはそのトークンを信頼するモデルです。開発者にとってJWT（JSON Web Token）はSSO文脈でよく使うものです。</p><div class="viz-flow"><div class="vf-node">ユーザー<div class="vf-sub">ID/PW入力</div></div><div class="vf-arrow">→</div><div class="vf-node vf-hl">IdP<div class="vf-sub">認証・発行</div></div><div class="vf-arrow">→</div><div class="vf-node">トークン<div class="vf-sub">JWT/SAML</div></div><div class="vf-arrow">→</div><div class="vf-node">サービス<div class="vf-sub">検証・許可</div></div></div>`,
|
||
examtips:[
|
||
'「2段階認証」は同一要素を2回使う場合もある（PW+秘密の質問→どちらも知識要素）。<strong>多要素認証は異なる要素を組み合わせる</strong>点が重要。',
|
||
'チャレンジレスポンス認証：サーバがランダム値（チャレンジ）を送り、クライアントがハッシュ等で応答（レスポンス）する。パスワードを平文で送らない。',
|
||
'FIDO2 / パスキー：最新の試験でも出始めている。秘密鍵をデバイスに保管し、公開鍵で検証するフィッシング耐性の高い認証方式。'
|
||
],
|
||
keypoints:[
|
||
'知識・所持・生体の3要素。異なる要素を2つ以上組み合わせると多要素認証（MFA）',
|
||
'チャレンジレスポンス認証：パスワードを平文で送らずに認証する',
|
||
'SSO（シングルサインオン）：一度の認証で複数サービスを利用（SAML/OIDCで実現）',
|
||
'リスクベース認証：ログイン状況（場所・デバイス）が異常なら追加認証',
|
||
'FIDO2/パスキー：公開鍵暗号ベースのフィッシング耐性が高い認証'
|
||
],
|
||
quiz:[
|
||
{q:'多要素認証の説明として正しいものはどれか。',choices:['同じ知識要素を2回入力させる','異なる種類の認証要素を2つ以上組み合わせる','生体認証のみを使用する','毎回異なるパスワードを使用する'],answer:1,exp:'多要素認証は知識・所持・生体など異なる種類の認証要素を2つ以上組み合わせます。'},
|
||
{q:'チャレンジレスポンス認証の目的はどれか。',choices:['生体情報の保護','パスワードの平文送信を回避する','SSO実現','セッション固定攻撃の防止'],answer:1,exp:'チャレンジレスポンス認証はパスワード自体を送らず、ハッシュ等の応答で認証します。盗聴対策。'},
|
||
{q:'SSOにおいてIdP（アイデンティティプロバイダ）の役割はどれか。',choices:['各サービスのDBを管理する','ユーザー認証を一元管理しトークンを発行する','ファイアウォールとして機能する','セッションIDを生成する'],answer:1,exp:'IdPはユーザーを認証し、各サービス（SP）が信頼できるトークンを発行する中央認証機関です。'},
|
||
{q:'パスキー（FIDO2）の特徴として正しいものはどれか。',choices:['パスワードをサーバに保存する','秘密鍵をデバイスに保管し公開鍵で検証するためフィッシング耐性が高い','知識要素だけで認証する','SMSによるワンタイムパスワードを使う'],answer:1,exp:'FIDO2/パスキーは公開鍵暗号ベース。秘密鍵はデバイスから外に出ないのでフィッシングが効きません。'}
|
||
]
|
||
},
|
||
{ id:'s04', num:'S04', title:'アクセス制御', freq:'high', diff:2,
|
||
concept:`<p>アクセス制御は「誰が何にどう操作できるか」を管理する仕組みです。3つのモデルが試験に頻出です。</p><div class="formula-box"><div class="formula-label">初学者向け：この単元の入口</div><strong>アクセス制御</strong>：ユーザーやプロセスが、どのリソース（ファイル・DB・機能）をどこまで使えるかを決める仕組み。<br><strong>最小権限</strong>：業務に必要な範囲だけ権限を付け、余計な操作や閲覧をさせない原則。<br><strong>職務分離</strong>：申請・承認・実行などを別の人に分け、一人で不正を完結できないようにすること。</div><div class="formula-box"><div class="formula-label">主なアクセス制御モデル</div>DAC（任意アクセス制御）：所有者が権限を設定（Linuxのchmod等）<br>MAC（強制アクセス制御）：システムがラベルで強制（機密文書管理）<br>RBAC（役割ベース制御）：役割に権限を付与（多くのWebアプリで採用）</div><p>最小権限の原則（Least Privilege）：業務に必要な最小限の権限のみ与える。開発者でいえばEC2に付けるIAM RoleはReadOnlyで十分な場合にAdminを付けないことです。</p><p>Need-to-know：業務上知る必要がある情報だけに絞るデータ分離の原則。MACと組み合わせることが多い。</p>`,
|
||
examtips:[
|
||
'DAC・MAC・RBACの違いを具体例で説明できること。試験では「誰が権限を設定するか」がポイント。',
|
||
'最小権限の原則は選択問題の正答選択肢になることが多い。「できるだけ多くの権限を与える」は誤答。',
|
||
'職務分離（Separation of Duties）：一人の担当者がすべてを担当しない。承認者と執行者を分ける。よく問われる。'
|
||
],
|
||
keypoints:[
|
||
'DAC：所有者が自分で権限を決める（UNIX パーミッション等）',
|
||
'MAC：ラベルに基づいてシステムが強制（軍・政府系情報管理）',
|
||
'RBAC：役割に権限を紐付け（Webアプリのユーザー・管理者ロール）',
|
||
'最小権限の原則：必要最低限の権限だけ付与する',
|
||
'職務分離：不正防止のため1人に全権限を集中させない'
|
||
],
|
||
quiz:[
|
||
{q:'Linuxのファイルオーナーが chmod でパーミッションを設定するのはどのアクセス制御モデルか。',choices:['MAC','RBAC','DAC','ABAC'],answer:2,exp:'DACは所有者が自分で権限を設定できる任意アクセス制御モデルです。'},
|
||
{q:'「社員の役職（マネージャー・一般社員等）に権限セットを割り当てる」手法はどれか。',choices:['DAC','MAC','RBAC','NAC'],answer:2,exp:'役割（Role）に権限を紐付けるRBACです。Webアプリでは最も広く使われます。'},
|
||
{q:'最小権限の原則の説明として正しいものはどれか。',choices:['管理者には全権限を与える','業務に必要な最小限の権限だけ付与する','権限はデフォルトで全員に開放する','上位職者ほど権限が多くなる'],answer:1,exp:'最小権限（Least Privilege）は必要最小限の権限のみ与え、不正・ミスの影響範囲を最小化します。'},
|
||
{q:'資金送金の「申請」と「承認」を別々の担当者が行うようにするセキュリティ原則はどれか。',choices:['最小権限','職務分離','Need-to-know','MAC'],answer:1,exp:'職務分離（Separation of Duties）は一人が全工程を担わないようにして不正を防ぐ原則です。'}
|
||
]
|
||
},
|
||
{ id:'s05', num:'S05', title:'ISMS・セキュリティマネジメント', freq:'mid', diff:2,
|
||
concept:`<p><strong>ISMS</strong>（Information Security Management System）はJIS Q 27001をベースにした、組織全体で情報セキュリティを継続的に改善する仕組みです。</p><div class="formula-box"><div class="formula-label">初学者向け：ISMS とゼロトラスト</div><strong>ISMS</strong>：方針を決め、リスクを評価し、規程・教育・点検・改善を続ける「組織のセキュリティの仕組み」そのもの。<br><strong>PDCA</strong>：Plan（計画）→Do（実行）→Check（評価）→Act（改善）の繰り返しでレベルを上げる考え方。<br><strong>ゼロトラスト</strong>：社内ネットワークにいるから安全、とはせず、内外を問わず毎回アクセスを検証する設計思想。</div><div class="formula-box"><div class="formula-label">PDCAサイクル（ISMS）</div>P（計画）：リスクアセスメント→セキュリティポリシー策定<br>D（実行）：管理策の実施・社員教育<br>C（確認）：内部監査・マネジメントレビュー<br>A（改善）：不適合の是正・継続的改善</div><p>ISMSの認証取得はISO/IEC 27001に基づきます。プライバシーマーク（PMS）は個人情報保護に特化した日本独自の認証制度です。ゼロトラストアーキテクチャは「境界の内側も信頼しない」という現代的なセキュリティ思想で、ISMSの文脈でも登場します。</p>`,
|
||
examtips:[
|
||
'ISMSはJIS Q 27001・ISO/IEC 27001が根拠。プライバシーマークとの違い（対象範囲・認定機関）を整理。',
|
||
'PDCAのどのフェーズの話かを問う問題が多い。「内部監査」はC（確認）、「リスクアセスメント」はP（計画）。',
|
||
'ゼロトラスト：「常に検証、決して信頼しない（Never trust, always verify）」が合言葉。境界型セキュリティとの対比で問われる。'
|
||
],
|
||
keypoints:[
|
||
'ISMS：JIS Q 27001に基づく情報セキュリティマネジメントシステム。PDCAで継続改善',
|
||
'リスクアセスメント：リスクの特定→分析→評価。ISMS計画フェーズの中核',
|
||
'プライバシーマーク：個人情報保護専用。日本国内の制度（JIS Q 15001）',
|
||
'ゼロトラスト：内部ネットワークも信頼しない。常に認証・認可を確認',
|
||
'CSIRT：インシデント対応チーム（S06以降で詳述）'
|
||
],
|
||
quiz:[
|
||
{q:'ISMSの根拠となる国際規格はどれか。',choices:['ISO/IEC 15408','ISO/IEC 27001','JIS Q 15001','PCI DSS'],answer:1,exp:'ISMSはISO/IEC 27001（日本ではJIS Q 27001）が根拠規格です。'},
|
||
{q:'ISMS認証のPDCAサイクルにおいて「内部監査」はどのフェーズに位置するか。',choices:['Plan','Do','Check','Act'],answer:2,exp:'内部監査は実施内容を確認する「Check」フェーズに位置します。'},
|
||
{q:'ゼロトラストアーキテクチャの考え方として正しいものはどれか。',choices:['内部ネットワークは安全として信頼する','社外からのアクセスだけを検証する','内部・外部を問わずすべてのアクセスを常に検証する','一度認証すれば内部では再認証不要'],answer:2,exp:'ゼロトラストは「Never trust, always verify」として内部も含め常に検証します。'}
|
||
]
|
||
}
|
||
]},
|
||
{ id:'crypto', label:'暗号・PKI', icon:'key', units:[
|
||
{ id:'s06', num:'S06', title:'共通鍵暗号', freq:'high', diff:2,
|
||
concept:`<p><strong>共通鍵暗号（対称暗号）</strong>は送受信者が同じ鍵を使って暗号化・復号する方式です。速度が速く大量データの暗号化に向いています。</p><div class="formula-box"><div class="formula-label">初学者向け：暗号の役割（あとで詳しく）</div>この単元の<strong>共通鍵</strong>は「同じ秘密の鍵で暗号化・復号する」方式です。次の単元の<strong>公開鍵</strong>とセットで「誰でも送れるが本人だけ読める」「本人だけが署名できる」など別の役割を担います。<strong>ハッシュ</strong>（別単元）は「要約フィンガープリント」で改ざん検知に使います。</div><div class="formula-box"><div class="formula-label">主要アルゴリズム</div>AES（Advanced Encryption Standard）：現在の標準。128/192/256ビット鍵。ブロック暗号<br>DES：56ビット鍵。現在は脆弱で使用禁止<br>3DES：DESを3回適用。AESへ移行中<br>ChaCha20：ストリーム暗号。モバイル・TLS1.3で採用</div><p>鍵配送問題：共通鍵を安全に相手に渡す手段が必要。これを解決したのが公開鍵暗号とDiffie-Hellman鍵交換です。TLSハンドシェイクではDH（ECDH）で共通鍵を合意し、AESで通信を暗号化するという組み合わせが標準です。</p>`,
|
||
examtips:[
|
||
'AES・DES・3DESのビット長と現在の安全性を整理する。DESは2024年現在使用禁止。',
|
||
'n人で共通鍵を持ち合う場合の鍵の数：n(n-1)/2本。公開鍵暗号ならn本で済む。この違いが問われる。',
|
||
'ブロック暗号のモード（ECB・CBC・GCM等）が出題されることも。ECBは同じ平文→同じ暗号文になる弱点がある。'
|
||
],
|
||
keypoints:[
|
||
'共通鍵暗号：暗号化と復号に同じ鍵を使う。高速・大量データ向き',
|
||
'AES：現在の標準暗号。鍵長128/192/256ビット',
|
||
'DES：56ビット鍵で現在は脆弱。使用禁止',
|
||
'n人の鍵数：公開鍵ならn本、共通鍵ならn(n-1)/2本',
|
||
'鍵配送問題：共通鍵を安全に渡す手段が課題→DHや公開鍵暗号で解決'
|
||
],
|
||
quiz:[
|
||
{q:'現在の標準的な共通鍵暗号アルゴリズムはどれか。',choices:['DES','3DES','AES','RC4'],answer:2,exp:'AESは2001年に米国標準となり、現在最も広く使われる共通鍵暗号です。'},
|
||
{q:'10人のユーザーが互いに安全に通信するために必要な共通鍵の総数はいくつか（1対1通信）。',choices:['10本','20本','45本','100本'],answer:2,exp:'n(n-1)/2 = 10×9/2 = 45本の共通鍵が必要です。'},
|
||
{q:'共通鍵暗号の「鍵配送問題」とは何か。',choices:['鍵が長すぎる問題','暗号化に時間がかかる問題','共通鍵を安全に相手に渡す手段がない問題','鍵の保管場所がない問題'],answer:2,exp:'共通鍵を事前に安全に渡す方法がないことを鍵配送問題と言います。公開鍵暗号やDHで解決します。'},
|
||
{q:'ブロック暗号モードのうち同一ブロックの平文が常に同一の暗号文になるため脆弱とされるものはどれか。',choices:['CBC','GCM','CTR','ECB'],answer:3,exp:'ECB（Electronic Codebook）モードはブロックを独立に暗号化するため、同一平文→同一暗号文になり、パターン漏洩の危険があります。'}
|
||
]
|
||
},
|
||
{ id:'s07', num:'S07', title:'公開鍵暗号・デジタル署名', freq:'high', diff:2,
|
||
concept:`<p><strong>公開鍵暗号（非対称暗号）</strong>は公開鍵と秘密鍵のペアを使います。公開鍵で暗号化→秘密鍵で復号（機密性）、秘密鍵で署名→公開鍵で検証（完全性・否認防止）。</p><div class="viz-flow"><div class="vf-node">送信者<div class="vf-sub">秘密鍵で署名</div></div><div class="vf-arrow">→</div><div class="vf-node vf-hl">署名付き<div class="vf-sub">メッセージ</div></div><div class="vf-arrow">→</div><div class="vf-node">受信者<div class="vf-sub">公開鍵で検証</div></div></div><div class="formula-box"><div class="formula-label">主要アルゴリズム</div>RSA：素因数分解の困難性に基づく。2048ビット以上が現在の最低基準<br>ECDSA/EdDSA：楕円曲線暗号。RSAより短い鍵で同等の安全性<br>DH/ECDH：鍵交換アルゴリズム（暗号化ではなく鍵合意）</div><p>デジタル署名の手順：①メッセージのハッシュ値を計算②秘密鍵でハッシュを暗号化（=署名）③受信側は公開鍵で署名を復号しハッシュと照合。改ざんと否認を同時に防ぎます。</p>`,
|
||
examtips:[
|
||
'暗号化と署名で使う鍵の向きが逆なことを確実に理解する。暗号化は「受信者の公開鍵」、署名は「送信者の秘密鍵」。',
|
||
'RSAの最低鍵長は2048ビット（2024年現在）。1024ビットは脆弱で不推奨。',
|
||
'デジタル署名≠暗号化。署名は「本人確認・改ざん検知」が目的。機密性（内容を隠す）は公開鍵暗号化が担う。',
|
||
'<strong>耐量子暗号（PQC）</strong>：量子コンピュータはRSA・ECDSAの数学的基盤を破るとされる。NIST は2024年8月に ML-KEM（FIPS 203）・ML-DSA（FIPS 204）・SLH-DSA（FIPS 205）を正式標準化。試験最新動向として押さえておく。'
|
||
],
|
||
keypoints:[
|
||
'暗号化：受信者の公開鍵で暗号化→受信者の秘密鍵で復号（機密性）',
|
||
'署名：送信者の秘密鍵で署名→送信者の公開鍵で検証（完全性・否認防止）',
|
||
'RSA：素因数分解の困難性。最低2048ビット',
|
||
'ECDSA：楕円曲線暗号。短い鍵で高い安全性',
|
||
'DH/ECDH：鍵を共有するプロトコル。TLSのforward secrecyに使う',
|
||
'耐量子暗号（PQC）：ML-KEM・ML-DSA・SLH-DSA がNIST標準（2024年8月）。RSA/ECCの後継候補'
|
||
],
|
||
quiz:[
|
||
{q:'デジタル署名を生成する際に使用する鍵はどれか。',choices:['受信者の公開鍵','送信者の公開鍵','受信者の秘密鍵','送信者の秘密鍵'],answer:3,exp:'署名は「送信者の秘密鍵」で生成し、受信者は「送信者の公開鍵」で検証します。'},
|
||
{q:'公開鍵暗号で暗号化する際に使用する鍵はどれか。',choices:['送信者の秘密鍵','送信者の公開鍵','受信者の秘密鍵','受信者の公開鍵'],answer:3,exp:'「受信者の公開鍵」で暗号化し、受信者だけが持つ「秘密鍵」で復号します。'},
|
||
{q:'デジタル署名が提供するセキュリティ機能として正しいものの組み合わせはどれか。',choices:['機密性・可用性','完全性・否認防止','機密性・完全性','可用性・否認防止'],answer:1,exp:'デジタル署名は改ざん検知（完全性）と「やっていない」と言わせない（否認防止）を提供します。'},
|
||
{q:'RSA暗号の安全性の根拠となる数学的困難性はどれか。',choices:['離散対数問題','素因数分解の困難性','楕円曲線の困難性','ナップサック問題'],answer:1,exp:'RSAは大きな整数の素因数分解が困難であることを安全性の根拠としています。'}
|
||
]
|
||
},
|
||
{ id:'s08', num:'S08', title:'ハッシュ関数', freq:'high', diff:1,
|
||
concept:`<p><strong>ハッシュ関数</strong>は任意のデータから固定長のダイジェスト（ハッシュ値）を生成する一方向関数です。同じ入力から常に同じ出力が得られ、逆算は（計算量的に）不可能です。</p><div class="formula-box"><div class="formula-label">主要アルゴリズムと出力長</div>MD5：128ビット。衝突脆弱性あり。使用禁止（整合性確認のみ残存）<br>SHA-1：160ビット。衝突脆弱性あり。証明書用途では使用禁止<br>SHA-256：256ビット。現在の標準。Bitcoinでも使用<br>SHA-3：Keccakアルゴリズム。SHA-2と並行して使える代替</div><p>ハッシュの3性質：①衝突耐性（同じハッシュを持つ別データを作れない）②第二原像耐性（ハッシュ値から元データを求められない）③雪崩効果（入力が1ビット変わると出力が大きく変わる）</p><p>パスワード保存にはハッシュにソルト（ランダム値）を加えることでレインボーテーブル攻撃を防ぎます。bcrypt・Argon2が推奨。</p>`,
|
||
examtips:[
|
||
'MD5・SHA-1は衝突脆弱性が実証されており現在は安全でない。SHA-256以上を使う。',
|
||
'ハッシュは一方向（復号不可）。「ハッシュ値からパスワードを復元」はできない→レインボーテーブルは元の値のハッシュを事前計算して照合するもの。',
|
||
'ソルト：パスワードに加えるランダム値。ユーザーごとに異なるため、同じPWでもハッシュ値が変わりレインボーテーブルを無効化する。'
|
||
],
|
||
keypoints:[
|
||
'ハッシュ関数：一方向変換。固定長ダイジェストを生成',
|
||
'SHA-256：現在の標準。MD5・SHA-1は使用禁止（衝突脆弱性）',
|
||
'衝突耐性・第二原像耐性・雪崩効果がセキュアなハッシュの条件',
|
||
'パスワード保存：bcrypt/Argon2＋ソルトが推奨。単純SHA-256は不十分',
|
||
'レインボーテーブル攻撃：事前計算ハッシュとの照合。ソルトで無効化'
|
||
],
|
||
quiz:[
|
||
{q:'現在セキュリティ用途として推奨されないハッシュアルゴリズムはどれか。',choices:['SHA-256','SHA-3','SHA-512','MD5'],answer:3,exp:'MD5は衝突脆弱性が実証されており、セキュリティ用途での使用は禁止されています。'},
|
||
{q:'ハッシュ関数の性質として正しいものはどれか。',choices:['出力から入力が復元できる','同じ入力から毎回異なる出力が得られる','任意のデータから固定長のダイジェストを生成する','暗号化と復号に使用できる'],answer:2,exp:'ハッシュ関数は任意の入力から固定長ダイジェストを生成する一方向関数です。'},
|
||
{q:'パスワードのハッシュ保存においてソルトを使用する目的はどれか。',choices:['ハッシュ計算を高速化する','レインボーテーブル攻撃を無効化する','パスワードを復元できるようにする','認証速度を向上する'],answer:1,exp:'ソルト（ユーザーごとのランダム値）を加えることで、事前計算済みのレインボーテーブルを無効化します。'},
|
||
{q:'デジタル署名においてハッシュ関数を使う主な理由はどれか。',choices:['メッセージを暗号化するため','メッセージ全体を秘密鍵で処理するコストを削減するため','認証局の検証を省略するため','公開鍵を生成するため'],answer:1,exp:'メッセージ全体を秘密鍵で暗号化すると非常に遅いため、ハッシュ値のみ署名します。'}
|
||
]
|
||
},
|
||
{ id:'s09', num:'S09', title:'PKI・TLS', freq:'high', diff:2,
|
||
concept:`<p><strong>PKI</strong>（Public Key Infrastructure）は公開鍵の正当性を証明する仕組みです。中核となるのが<strong>認証局（CA）</strong>が発行する<strong>デジタル証明書（X.509）</strong>です。</p><div class="viz-flow"><div class="vf-node">CA<div class="vf-sub">認証局</div></div><div class="vf-arrow">→</div><div class="vf-node vf-hl">証明書<div class="vf-sub">公開鍵+CAの署名</div></div><div class="vf-arrow">→</div><div class="vf-node">ブラウザ<div class="vf-sub">CAの公開鍵で検証</div></div></div><p>TLS 1.3のハンドシェイク：①サーバ証明書を送る②クライアントがCAチェーンを検証③ECDHで共通鍵を合意④AES-GCMで通信開始。開発者にとってHTTPS=TLSは日常的な技術です。</p><div class="formula-box"><div class="formula-label">証明書の失効確認</div>CRL（証明書失効リスト）：失効した証明書のリスト。定期更新<br>OCSP（Online Certificate Status Protocol）：リアルタイムで1証明書の状態を確認<br>OCSP Stapling：サーバ自身が失効情報をキャッシュしてクライアントに渡す</div>`,
|
||
examtips:[
|
||
'ルートCA→中間CA→サーバ証明書のチェーン（信頼の連鎖）を理解する。ブラウザはルートCAを信頼リストで持つ。',
|
||
'TLS1.2と1.3の違い：TLS1.3はハンドシェイクが1-RTTに短縮、前方秘匿性（PFS）がデフォルト。',
|
||
'CRLとOCSPの違い：CRLは定期ダウンロード式・大きい。OCSPはリアルタイム・1件ずつ。試験でよく比較される。'
|
||
],
|
||
keypoints:[
|
||
'CA（認証局）：公開鍵の正当性を証明するデジタル証明書を発行',
|
||
'X.509証明書：公開鍵・所有者情報・CAの署名を含む',
|
||
'TLS 1.3：ECDH鍵交換＋AES-GCM暗号。1-RTTハンドシェイク',
|
||
'CRL：失効証明書リスト（定期更新）。OCSP：リアルタイム失効確認',
|
||
'信頼の連鎖：ルートCA→中間CA→エンドエンティティ証明書'
|
||
],
|
||
quiz:[
|
||
{q:'デジタル証明書においてCAが担う役割はどれか。',choices:['通信を暗号化する','公開鍵の正当性を証明する','秘密鍵を生成する','ファイアウォールとして機能する'],answer:1,exp:'CAは公開鍵が本当にその所有者のものであることをデジタル署名で証明します。'},
|
||
{q:'TLS通信でサーバ証明書の失効をリアルタイムに1件確認するプロトコルはどれか。',choices:['CRL','OCSP','LDAP','PKI'],answer:1,exp:'OCSPは1枚の証明書の失効状態をリアルタイムに確認するプロトコルです。'},
|
||
{q:'TLS 1.3の特徴として正しいものはどれか。',choices:['RC4で通信を暗号化する','1-RTTハンドシェイクで接続が速い','DES鍵交換を使う','前方秘匿性（PFS）はオプション'],answer:1,exp:'TLS1.3は1-RTTハンドシェイクで高速化し、ECDHによる前方秘匿性がデフォルトです。'},
|
||
{q:'証明書の信頼チェーンで「ルートCAの証明書を格納しているのは主にどこか。',choices:['Webサーバ','DNS','OSやブラウザの信頼リスト','OCSP Responder'],answer:2,exp:'ブラウザやOSはルートCAの証明書を信頼リスト（トラストストア）として事前に搭載しています。'}
|
||
]
|
||
}
|
||
]},
|
||
{ id:'network', label:'ネットワーク防御', icon:'network', units:[
|
||
{ id:'s10', num:'S10', title:'ファイアウォール・DMZ', freq:'high', diff:2,
|
||
concept:`<p><strong>ファイアウォール</strong>はネットワーク境界でトラフィックをフィルタリングします。<strong>DMZ</strong>（非武装地帯）はインターネットと内部ネットワークの間に置く中間ゾーンで、Webサーバ等の公開サービスを置きます。</p><div class="viz-layers"><div class="layer-item layer-1">インターネット（外部）<span class="layer-sub">不特定多数のアクセス</span></div><div class="layer-item layer-2">DMZ（非武装地帯）<span class="layer-sub">Webサーバ・DNSサーバ・メールサーバ</span></div><div class="layer-item layer-3">内部ネットワーク<span class="layer-sub">社内PC・DBサーバ・ファイルサーバ</span></div></div><div class="formula-box"><div class="formula-label">ファイアウォールの種類</div>パケットフィルタリング：IPアドレス・ポートで許可/拒否。高速だがアプリ層の攻撃に弱い<br>SPI（ステートフルパケットインスペクション）：コネクション状態を追跡。戻りパケットを自動許可<br>アプリケーションゲートウェイ：プロキシとして動作。アプリ層まで検査</div>`,
|
||
examtips:[
|
||
'DMZにはWebサーバ・メールサーバを置く。DBサーバはDMZではなく内部ネットワークに置く（頻出引っかけ）。',
|
||
'デフォルト拒否（ホワイトリスト型）が原則。「明示的に許可されていないものは拒否」。',
|
||
'ステートフルとステートレスの違い：ステートフルはセッション状態を管理するためSYN/ACKなどの戻り方向を自動許可できる。'
|
||
],
|
||
keypoints:[
|
||
'ファイアウォール：パケットをルールに基づき許可/拒否',
|
||
'DMZ：外部と内部の中間ゾーン。公開サービスのみ配置',
|
||
'パケットフィルタリング：IP/ポートベース。高速だがL7攻撃に弱い',
|
||
'SPI：接続状態を追跡。戻りパケットを動的に許可',
|
||
'デフォルト拒否原則：明示的に許可されていないものはすべて遮断'
|
||
],
|
||
quiz:[
|
||
{q:'DMZに設置すべきサーバとして適切なものはどれか。',choices:['データベースサーバ','人事管理システム','Webサーバ（公開用）','ファイルサーバ（社内用）'],answer:2,exp:'DMZには外部からアクセスされる公開Webサーバ等を置きます。DBや社内システムは内部ネットワークに置きます。'},
|
||
{q:'ステートフルパケットインスペクション（SPI）の特徴はどれか。',choices:['IPアドレスのみでフィルタリングする','コネクションの状態を追跡し戻りパケットを自動許可する','アプリケーション層のデータを復号して検査する','UDPのみに対応している'],answer:1,exp:'SPIはTCPセッション状態を管理し、正規の戻りパケット（ACK）を動的に許可します。'},
|
||
{q:'ファイアウォールの基本原則「デフォルト拒否」の意味はどれか。',choices:['すべての通信を拒否する','許可ルールに一致しない通信はすべて拒否する','認証なしの通信を拒否する','外部からの通信のみ拒否する'],answer:1,exp:'デフォルト拒否（deny all）は、明示的に許可されていないすべての通信を遮断する原則です。'}
|
||
]
|
||
},
|
||
{ id:'s11', num:'S11', title:'IDS・IPS・WAF', freq:'high', diff:2,
|
||
concept:`<p>ファイアウォールを補完するセキュリティデバイスです。<strong>IDS</strong>は検知のみ、<strong>IPS</strong>は検知して遮断します。<strong>WAF</strong>はWebアプリケーション専用でHTTPレベルの攻撃を防ぎます。</p><div class="formula-box"><div class="formula-label">検知方式</div>シグネチャ型（不正検知）：既知の攻撃パターンと照合。既知攻撃に強い・ゼロデイに弱い<br>アノマリ型（異常検知）：正常な行動からの逸脱を検知。未知攻撃も検知可能・誤検知が多い</div><p>WAFの導入パターン：リバースプロキシ型が最も一般的。クラウドWAFはCDNと統合されることも多い。SQLインジェクション・XSS・CSRFを主に防ぎます。誤検知（FP）のチューニングが運用上の課題です。</p>`,
|
||
examtips:[
|
||
'IDS（検知のみ）とIPS（検知＋遮断）の違いは必須。「遮断」のワードがあればIPS。',
|
||
'シグネチャ型はゼロデイ脆弱性の攻撃を検知できない。アノマリ型は未知攻撃を検知できるが誤検知率が高い。',
|
||
'WAFとファイアウォールの違い：FWはL3/4（IP/ポート）、WAFはL7（HTTPのパラメータ・ヘッダ）を検査。'
|
||
],
|
||
keypoints:[
|
||
'IDS：不正侵入の検知のみ（通知・ログ）',
|
||
'IPS：不正侵入の検知と遮断（インライン配置が必要）',
|
||
'WAF：Webアプリケーション専用。SQL・XSS等L7攻撃を防ぐ',
|
||
'シグネチャ型：既知攻撃に強い・ゼロデイに弱い',
|
||
'アノマリ型：未知攻撃も検知可・誤検知率が高い'
|
||
],
|
||
quiz:[
|
||
{q:'IPSとIDSの違いとして正しいものはどれか。',choices:['IDSは遮断できるがIPSは検知のみ','IPSは検知と遮断ができるがIDSは検知のみ','IPSはWAFの別名','IDSはファイアウォールの別名'],answer:1,exp:'IDSは検知・通知のみ。IPSはインラインに設置し不正トラフィックを遮断します。'},
|
||
{q:'未知のゼロデイ攻撃の検知に適したIDSの検知方式はどれか。',choices:['シグネチャ型','アノマリ型（異常検知型）','プロトコル解析型','パターンマッチ型'],answer:1,exp:'アノマリ型は正常行動の基準から逸脱を検知するため、シグネチャにない未知の攻撃にも対応できます。'},
|
||
{q:'WAFが主に防ぐ攻撃として正しいものの組み合わせはどれか。',choices:['DoS攻撃・ARP Spoofing','SQLインジェクション・XSS','DDoS攻撃・DNSハイジャック','フィッシング・スミッシング'],answer:1,exp:'WAFはWebアプリケーションへのSQLインジェクション・XSS・CSRFなどL7攻撃を防ぎます。'}
|
||
]
|
||
},
|
||
{ id:'s12', num:'S12', title:'VPN', freq:'mid', diff:2,
|
||
concept:`<p><strong>VPN</strong>（Virtual Private Network）はパブリックネットワーク上に暗号化された仮想トンネルを作り、安全な通信路を提供します。</p><div class="formula-box"><div class="formula-label">主なVPN方式</div>IPsec-VPN：L3でパケット全体を暗号化。ESP/AHプロトコル。拠点間接続に多い<br>SSL/TLS-VPN：L5/7でHTTPS上にトンネル。ブラウザから利用可能。リモートアクセスに多い<br>WireGuard：最新の軽量プロトコル。ChaCha20/Poly1305を使用</div><p>IPsecの2モード：トランスポートモード（ペイロードのみ暗号化）とトンネルモード（パケット全体を暗号化して新しいIPヘッダを付与）。拠点間VPNではトンネルモードが一般的です。</p>`,
|
||
examtips:[
|
||
'IPsec-VPNはL3（ネットワーク層）、SSL-VPNはL5以上（セッション/アプリ層）での動作という層の違いが問われる。',
|
||
'IPsecのESP（Encapsulating Security Payload）は暗号化と認証の両方を提供。AH（Authentication Header）は認証のみ（暗号化なし）。',
|
||
'スプリットトンネリング：VPN接続中に社内宛て通信のみVPNを通し、一般ネット通信は直接出る設定。セキュリティリスクとして問われることがある。'
|
||
],
|
||
keypoints:[
|
||
'IPsec-VPN：L3暗号化。拠点間接続向き。ESPは暗号化＋認証',
|
||
'SSL/TLS-VPN：HTTPS上のトンネル。リモートアクセス向き。ブラウザ対応',
|
||
'トンネルモード：元パケット全体を暗号化＋新IPヘッダ。拠点間に使用',
|
||
'トランスポートモード：ペイロードのみ暗号化。ホスト間通信に使用',
|
||
'WireGuard：現代的な軽量VPN。ChaCha20/Poly1305で高速'
|
||
],
|
||
quiz:[
|
||
{q:'IPsecのESPが提供する機能として正しいものはどれか。',choices:['認証のみ','暗号化のみ','暗号化と認証の両方','鍵交換のみ'],answer:2,exp:'ESP（Encapsulating Security Payload）はデータの暗号化と送信元認証の両方を提供します。'},
|
||
{q:'SSL-VPNの説明として正しいものはどれか。',choices:['IPレベルで全パケットを暗号化する','TLS上にトンネルを構築しリモートアクセスに使われる','AHとESPプロトコルを使用する','ネットワーク層で動作する'],answer:1,exp:'SSL/TLS-VPNはHTTPS（TLS）を利用したトンネリングで、ブラウザからアクセスできるリモートアクセスVPNです。'},
|
||
{q:'IPsecのトンネルモードとトランスポートモードの違いはどれか。',choices:['トンネルモードはUDPのみ対応','トンネルモードは元パケット全体を暗号化し新IPヘッダを付与する','トランスポートモードは拠点間接続に使われる','両モードに機能差はない'],answer:1,exp:'トンネルモードは元のIPパケット全体を暗号化し新IPヘッダを付けます。拠点間VPNで使われます。'}
|
||
]
|
||
},
|
||
{ id:'s13', num:'S13', title:'DNSセキュリティ・メールセキュリティ', freq:'high', diff:2,
|
||
concept:`<p>DNSとメールはインターネットの基盤であり、攻撃の標的になりやすいプロトコルです。</p><div class="formula-box"><div class="formula-label">DNS攻撃と対策</div>DNSキャッシュポイズニング：偽のDNS応答をキャッシュに送り込む→DNSSEC・ランダムポートで対策<br>DNSハイジャック：DNSサーバ自体を乗っ取る→DNSSEC・監視<br>DNSSEC：DNSレスポンスにデジタル署名を付与し改ざんを検知</div><div class="formula-box"><div class="formula-label">メール認証技術</div>SPF（Sender Policy Framework）：送信元IPをDNSで検証。なりすましドメイン対策<br>DKIM（DomainKeys Identified Mail）：メールヘッダにデジタル署名。改ざん検知<br>DMARC：SPF/DKIMの結果に基づいて受信側の処理ポリシーを指定（拒否・隔離）</div>`,
|
||
examtips:[
|
||
'SPF・DKIM・DMARCはセットで覚える。SPFはIP検証、DKIMは署名、DMARCはポリシー（どう処理するか）。',
|
||
'DNSキャッシュポイズニングはカミンスキー攻撃が有名。ランダムポート番号とTXID乱数化が対策。',
|
||
'メールの暗号化（S/MIMEやPGP）とDKIMの違い：DKIMは送信元の正当性確認。S/MIMEは内容の暗号化。目的が違う。'
|
||
],
|
||
keypoints:[
|
||
'DNSキャッシュポイズニング：偽応答でキャッシュを汚染。DNSSEC・ランダムポートで対策',
|
||
'DNSSEC：DNS応答にデジタル署名を付けて改ざんを検知',
|
||
'SPF：送信ドメインのIPアドレスをDNSで公開しなりすましを検証',
|
||
'DKIM：メールヘッダの署名で改ざん・なりすましを検知',
|
||
'DMARC：SPF/DKIMに基づくポリシーを定義（none/quarantine/reject）'
|
||
],
|
||
quiz:[
|
||
{q:'DNSキャッシュポイズニング攻撃の目的はどれか。',choices:['DNSサーバを過負荷にする','偽のDNS応答をキャッシュに記録させ利用者を偽サイトに誘導する','メールサーバを乗っ取る','TLS証明書を偽造する'],answer:1,exp:'DNSキャッシュポイズニングは偽の名前解決情報をキャッシュさせ、フィッシングサイト等に誘導します。'},
|
||
{q:'メール送信ドメインの正当性をIPアドレスで検証する仕組みはどれか。',choices:['DKIM','DMARC','SPF','DNSSEC'],answer:2,exp:'SPF（Sender Policy Framework）は送信元IPをDNSのTXTレコードで検証しなりすましを防ぎます。'},
|
||
{q:'DMARCが提供する主な機能はどれか。',choices:['メール本文を暗号化する','送信元IPを検証する','SPF/DKIMの結果に基づく受信ポリシーを定義する','メールのデジタル署名を行う'],answer:2,exp:'DMARCはSPF/DKIM両方の検証結果に基づいて、受信側が「none/quarantine/reject」などのポリシーを適用します。'},
|
||
{q:'DKIMが提供する機能はどれか。',choices:['送信元IPアドレスの検証','メールヘッダへのデジタル署名による改ざん・なりすましの検知','メール本文の暗号化','SPFポリシーの実施'],answer:1,exp:'DKIMはメールヘッダに秘密鍵で署名し、受信側が公開鍵で署名を検証することで改ざんを検知します。'}
|
||
]
|
||
},
|
||
{ id:'s25', num:'S25', title:'無線LAN セキュリティ', freq:'high', diff:2,
|
||
concept:`<p>無線LANは電波を使うため盗聴・なりすましへの対策が必須です。暗号化方式は世代を経るごとに強化されてきました。</p><div class="formula-box"><div class="formula-label">無線LAN暗号化方式の変遷</div>WEP（1997）：RC4暗号・IV再利用の脆弱性あり。現在は使用禁止<br>WPA（2003）：TKIP採用。WEPの緊急改善版<br>WPA2（2004）：CCMP/AES採用。現在の最低基準<br>WPA3（2018）：SAE（Simultaneous Authentication of Equals）で辞書攻撃対策・前方秘匿性</div><div class="formula-box"><div class="formula-label">企業向け認証（802.1X）</div>個人モード（PSK）：事前共有鍵。家庭・小規模向け<br>企業モード（802.1X）：RADIUS サーバが各ユーザーを認証<br> EAP-TLS：証明書ベース認証。最も安全<br> PEAP：トンネル内でパスワード認証<br> EAP-TTLS：PEAPの互換版</div><div class="viz-flow"><div class="vf-node">端末<div class="vf-sub">Supplicant</div></div><div class="vf-arrow">→</div><div class="vf-node vf-hl">AP<div class="vf-sub">Authenticator</div></div><div class="vf-arrow">→</div><div class="vf-node">RADIUS<div class="vf-sub">Auth Server</div></div></div><p>主な攻撃：悪意あるAP（Evil Twin・偽AP）で中間者攻撃、WPS PINブルートフォース、PMKIDを使ったオフライン辞書攻撃。対策はWPA3・証明書認証・管理フレーム保護（PMF/802.11w）。</p>`,
|
||
examtips:[
|
||
'WEP は IV（初期化ベクタ）の再利用で解読される。試験では「使用禁止」の選択肢として正答になりやすい。',
|
||
'WPA3 の SAE（ドラゴンフライ鍵交換）は辞書攻撃耐性と前方秘匿性を提供。PSK より安全な認証フロー。',
|
||
'企業の802.1X では RADIUS サーバが必要。EAP-TLS は証明書ベースで最も安全だが証明書管理が必要。PEAP はサーバ証明書のみで端末はパスワード認証。'
|
||
],
|
||
keypoints:[
|
||
'WEP：RC4・IV再利用で脆弱。使用禁止',
|
||
'WPA2：CCMP/AES で現在の最低基準',
|
||
'WPA3：SAE で辞書攻撃耐性・前方秘匿性を提供',
|
||
'802.1X 企業モード：RADIUS サーバで個人認証。EAP-TLS が最も安全',
|
||
'悪意ある AP（Evil Twin）：正規 AP を偽装して中間者攻撃。証明書検証で対策'
|
||
],
|
||
quiz:[
|
||
{q:'無線LAN の暗号化方式のうち現在使用が禁止されているのはどれか。',choices:['WPA2（CCMP/AES）','WEP（RC4/IV）','WPA3（SAE）','TKIP'],answer:1,exp:'WEP は IV（初期化ベクタ）の再利用により短時間で解読可能であり、現在のセキュリティ基準では使用が禁止されています。'},
|
||
{q:'WPA3 で WPA2 から改善された主なセキュリティ機能はどれか。',choices:['暗号アルゴリズムが DES から AES に変更','SAE 鍵交換により辞書攻撃耐性と前方秘匿性を実現','RC4 暗号を採用','WPS を廃止'],answer:1,exp:'WPA3 は SAE（ドラゴンフライ鍵交換）を採用。事前計算済み辞書による攻撃を困難にし、セッション鍵ごとの前方秘匿性も提供します。'},
|
||
{q:'企業向け無線 LAN 認証（WPA2/WPA3-Enterprise）で使われる認証プロトコルはどれか。',choices:['PSK（事前共有鍵）のみ','802.1X と RADIUS サーバによる個人認証'],answer:1,exp:'Enterprise モードは 802.1X を使い RADIUS サーバで各ユーザーを認証します。EAP-TLS（証明書）や PEAP（パスワード）が使われます。'},
|
||
{q:'正規のアクセスポイントに見せかけて端末を接続させる攻撃を何と呼ぶか。',choices:['DNSポイズニング','Evil Twin（悪意あるAP / 偽AP）'],answer:1,exp:'Evil Twin は合法的な AP と同名の SSID で偽 AP を立て、接続した端末の通信を傍受する中間者攻撃です。SSID だけでは本物か判断できません。'}
|
||
]
|
||
}
|
||
]},
|
||
{ id:'attacks', label:'攻撃手法と対策', icon:'sword', units:[
|
||
{ id:'s14', num:'S14', title:'マルウェア', freq:'high', diff:1,
|
||
concept:`<p>マルウェアはMalicious Softwareの略で、悪意のあるプログラムの総称です。種類と感染経路・対策を整理します。</p><div class="formula-box"><div class="formula-label">主なマルウェアの種類</div>ウイルス：他のプログラムに寄生して感染拡大<br>ワーム：ネットワークを自力で伝播（ホスト不要）<br>トロイの木馬：正常なソフトに見せかけて侵入<br>ランサムウェア：ファイルを暗号化し身代金を要求<br>スパイウェア：情報を窃取して送信<br>ルートキット：管理者権限を奪い存在を隠蔽<br>ボット：C&Cサーバの指令でDDoS等に悪用</div><p>検知方式：シグネチャ型（パターン照合）・ビヘイビア型（振る舞い検知）・サンドボックス（隔離環境で動作確認）。ゼロデイマルウェアにはシグネチャが効かないためビヘイビア型が重要です。</p>`,
|
||
examtips:[
|
||
'ランサムウェア対策の3-2-1ルール：3つのバックアップ・2種類のメディア・1つはオフライン。試験でも対策として正答になりやすい。',
|
||
'ルートキットは感染後にOS自体を改ざんして自分を隠す。通常のアンチウイルスで検知しにくい。',
|
||
'C&Cサーバ（Command and Control）：ボットを制御するサーバ。通信を遮断することが対策の一つ。'
|
||
],
|
||
keypoints:[
|
||
'ウイルス：宿主ファイルに寄生。ワーム：自力でネット感染',
|
||
'ランサムウェア：暗号化→身代金。対策はオフラインバックアップ',
|
||
'トロイの木馬：正規ソフトに偽装。ルートキット：自身を隠蔽',
|
||
'ビヘイビア検知：振る舞いから未知マルウェアを検出',
|
||
'サンドボックス：隔離環境でマルウェアを動作させ分析'
|
||
],
|
||
quiz:[
|
||
{q:'ネットワークを通じて自己複製しホストプログラムなしに拡散するマルウェアはどれか。',choices:['ウイルス','ワーム','スパイウェア','ルートキット'],answer:1,exp:'ワームは宿主プログラムを必要とせず、ネットワーク経由で自力に拡散します。'},
|
||
{q:'ランサムウェア対策として最も有効なものはどれか。',choices:['パスワードを強化する','定期的なオフラインバックアップを取得する','ファイアウォールを設置する','アカウントの2段階認証を導入する'],answer:1,exp:'ランサムウェアでファイルが暗号化されても、オフラインバックアップから復元できます。オンラインバックアップは暗号化される場合があります。'},
|
||
{q:'シグネチャ型の検知が無効な攻撃手法はどれか。',choices:['既知マルウェアの変種','ゼロデイマルウェア（未知の攻撃）','添付ファイルウイルス','既知の脆弱性を狙った攻撃'],answer:1,exp:'シグネチャ型はパターン照合のため、まだシグネチャがないゼロデイマルウェアを検知できません。'},
|
||
{q:'C&Cサーバ（Command and Control）の役割はどれか。',choices:['バックアップデータを保管する','感染したボットに指令を出し統制する','ファイアウォールのルールを管理する','証明書を発行する'],answer:1,exp:'C&Cサーバはボットネットの司令塔で、感染端末（ボット）に攻撃命令を送ります。'}
|
||
]
|
||
},
|
||
{ id:'s15', num:'S15', title:'Webアプリケーション攻撃', freq:'high', diff:2,
|
||
concept:`<p>Webアプリ開発者が必ず知るべき攻撃パターンです。OWASP Top 10の常連が試験でも頻出です。</p><div class="formula-box"><div class="formula-label">主要な攻撃と対策</div>SQLインジェクション：DB操作を注入。→プリペアドステートメント・入力検証<br>XSS（クロスサイトスクリプティング）：悪意のあるスクリプトを挿入→エスケープ・CSP<br>CSRF（クロスサイトリクエストフォージェリ）：ログイン中ユーザーに意図しないリクエスト→CSRFトークン・Same-Site Cookie<br>パストラバーサル：../でディレクトリを遡り任意ファイルを読む→パス正規化・バリデーション<br>コマンドインジェクション：OSコマンドを注入→外部コマンド使用禁止</div><p>XSSの種類：反射型（URLパラメータ経由）・格納型（DBに保存されたスクリプト）・DOMベース型（クライアントサイドJS処理）。試験では格納型が最も危険とされる。</p>`,
|
||
examtips:[
|
||
'SQLインジェクションの対策は「プリペアドステートメント（バインド変数）」が正答になる。エスケープだけでは不十分な場合がある。',
|
||
'XSS対策：出力時のHTMLエスケープ（< > 等）＋Content Security Policy（CSP）ヘッダ。',
|
||
'CSRF対策：CSRFトークン（セッションに紐づくランダム値をフォームに埋める）＋Same-Site Cookie属性。'
|
||
],
|
||
keypoints:[
|
||
'SQLインジェクション：プリペアドステートメントで対策',
|
||
'XSS：HTMLエスケープ＋CSPヘッダで対策。Cookieには HttpOnly 属性',
|
||
'CSRF：CSRFトークン＋Same-Site Cookie（Strict/Lax）で対策',
|
||
'パストラバーサル：../によるファイルパス操作。正規化・ホワイトリストで対策',
|
||
'セキュリティヘッダ：CSP・X-Frame-Options・HSTS等を必ず設定'
|
||
],
|
||
quiz:[
|
||
{q:'SQLインジェクションの最も効果的な対策はどれか。',choices:['入力文字数を制限する','プリペアドステートメント（バインド変数）を使用する','WAFを設置する','ファイアウォールでDBポートを塞ぐ'],answer:1,exp:'プリペアドステートメントはSQLとデータを分離するため、SQLインジェクションを根本的に防ぎます。'},
|
||
{q:'XSS（クロスサイトスクリプティング）攻撃の目的として最も適切なものはどれか。',choices:['DBのデータを削除する','サービスを停止させる','セッションCookieを盗みセッションハイジャックを行う','管理者権限を奪取する'],answer:2,exp:'XSS攻撃の典型的な目的はCookieからセッションIDを盗み、被害者として操作することです。'},
|
||
{q:'CSRF攻撃への対策として有効なものはどれか。',choices:['パラメータのSQLエスケープ','CSRFトークンをフォームに埋め込む','パスワードを強化する','HTTPSを使用する'],answer:1,exp:'CSRFトークンはセッションに紐づくランダム値で、正規フォームからのリクエストであることを検証します。'},
|
||
{q:'格納型（persistent）XSSとはどのような攻撃か。',choices:['URLパラメータに悪意のあるスクリプトを含める','悪意のあるスクリプトをDBに保存しアクセスした全ユーザーに実行させる','クライアントサイドのJS処理でスクリプトを注入する','セッションクッキーを改ざんする'],answer:1,exp:'格納型XSSはDBに保存したスクリプトがページ表示のたびに全ユーザーで実行されるため最も危険です。'}
|
||
]
|
||
},
|
||
{ id:'s16', num:'S16', title:'パスワード攻撃・フィッシング', freq:'high', diff:1,
|
||
concept:`<p>パスワードとフィッシングはエンドユーザーを標的にした攻撃であり、技術的対策と人的対策の両方が必要です。</p><div class="formula-box"><div class="formula-label">パスワード攻撃の種類</div>ブルートフォース：全パターンを試す。アカウントロックで緩和<br>辞書攻撃：よく使われる単語リストを試す<br>パスワードスプレー：多アカウントに対し少数のPWを試す（ロック回避）<br>クレデンシャルスタッフィング：他サービスの漏洩リストを転用<br>レインボーテーブル：事前計算ハッシュとの照合。ソルトで無効化</div><p>フィッシング：正規サービスを偽った詐欺メールやサイトで認証情報を奪う。スピアフィッシング（特定の個人・組織を狙う）はターゲットを調査して巧妙な文面を作成します。ビジネスメール詐欺（BEC）はCEOや取引先を名乗り送金指示をするものです。</p>`,
|
||
examtips:[
|
||
'クレデンシャルスタッフィングは「他サービスで漏洩したIDとPWをそのまま別サービスに使う」。パスワードの使い回しが被害を広げる。',
|
||
'パスワードスプレー攻撃：少数のPW（"Spring2024!"等）を多数のアカウントに試す。アカウントロックを回避するための手法。',
|
||
'スピアフィッシング対策：多要素認証・送信元確認（DMARC）・セキュリティ教育。技術だけでは防げない。'
|
||
],
|
||
keypoints:[
|
||
'ブルートフォース：全試行。アカウントロックとレート制限で対策',
|
||
'クレデンシャルスタッフィング：流出リストの転用。パスワード使い回しが最大の原因',
|
||
'パスワードスプレー：少数PWを多数アカウントに試す。ロック閾値をずらす攻撃',
|
||
'フィッシング：偽メール・偽サイトで認証情報を奪う',
|
||
'スピアフィッシング：特定個人を調査した標的型。BECはその一種'
|
||
],
|
||
quiz:[
|
||
{q:'他のサービスで漏洩したID・パスワードのリストを使って別サービスにログインを試みる攻撃はどれか。',choices:['パスワードスプレー攻撃','ブルートフォース攻撃','クレデンシャルスタッフィング','辞書攻撃'],answer:2,exp:'クレデンシャルスタッフィングはパスワードの使い回しを悪用して漏洩リストを他サービスに転用する攻撃です。'},
|
||
{q:'アカウントロックアウト機能を回避しながらパスワードを試みる攻撃手法はどれか。',choices:['ブルートフォース攻撃','パスワードスプレー攻撃','レインボーテーブル攻撃','クレデンシャルスタッフィング'],answer:1,exp:'パスワードスプレーは少数の一般的なパスワードを多数のアカウントに分散して試すため、ロックアウト閾値を超えません。'},
|
||
{q:'スピアフィッシングの説明として正しいものはどれか。',choices:['不特定多数に大量配信するフィッシング','特定の個人・組織を調査した標的型フィッシング','電話を使ったソーシャルエンジニアリング','SMSを使ったフィッシング'],answer:1,exp:'スピアフィッシングは標的を事前に調査し、信頼性の高い偽メール・偽サイトで情報を盗む標的型攻撃です。'},
|
||
{q:'パスワードをハッシュで保存する際にソルト（salt）を加える主な目的はどれか。',choices:['ハッシュ計算を高速化する','レインボーテーブル攻撃を困難にする','パスワードを平文のまま保存する','ブルートフォース攻撃を速くする'],answer:1,exp:'ソルトはユーザーごとに異なるランダム値をパスワードに付加してからハッシュ化するため、同一パスワードでもハッシュ値が変わり、事前計算したレインボーテーブルがそのまま使えなくなります。'}
|
||
]
|
||
},
|
||
{ id:'s17', num:'S17', title:'DoS/DDoS・APT', freq:'high', diff:2,
|
||
concept:`<p><strong>DoS/DDoS</strong>はサービスを停止させる攻撃（可用性の侵害）、<strong>APT</strong>（Advanced Persistent Threat）は国家レベルの高度な標的型持続攻撃です。</p><div class="formula-box"><div class="formula-label">DDoS攻撃の種類</div>Volumetric（帯域消費型）：大量トラフィックで帯域を埋める（UDP flood・ICMP flood）<br>Protocol（プロトコル型）：SYN floodでサーバリソースを枯渇させる<br>Application（アプリ型）：HTTP floodでWebサーバのCPUを使い切る<br>Amplification（増幅型）：DNSやNTPを踏み台にして大量レスポンスを標的に向ける</div><p>APTはKill Chain（偵察→侵入→水平移動→持続化→情報窃取）で進む多段階攻撃です。MITRE ATT&CK フレームワークはATTのTTPを体系化したもので、防御側が攻撃者の行動を予測するために使います。</p>`,
|
||
examtips:[
|
||
'SYN flood：TCPのSYNパケットだけ大量送信しACKを返さない。サーバはhalf-open接続を大量保持しリソース枯渇。SYN Cookie/Proxyで対策。',
|
||
'DNSアンプ攻撃：小さいDNSクエリに大きいレスポンスが返ることを悪用。送信元IPを詐称して標的に大量レスポンスを向ける。',
|
||
'APT対策：多層防御（Defense in Depth）・SIEM・EDR・ゼロトラスト。侵入を前提にした「検知・対応」が重要。'
|
||
],
|
||
keypoints:[
|
||
'DoS：単一ホストからの攻撃。DDoS：多数のボットからの分散型攻撃',
|
||
'SYN flood：half-open接続でサーバリソースを枯渇させる',
|
||
'DNSアンプ：小クエリ→大レスポンス増幅。送信元偽装で標的に向ける',
|
||
'APT：偵察→侵入→永続化→情報窃取の多段階攻撃',
|
||
'MITRE ATT&CK：攻撃者のTTPを体系化したフレームワーク'
|
||
],
|
||
quiz:[
|
||
{q:'SYN flood攻撃の仕組みはどれか。',choices:['大量のICMPパケットを送りつける','TCPのSYNパケットを大量送信しハンドシェイクを完了させずサーバリソースを枯渇させる','DNSの大量レスポンスを標的に向ける','HTTPリクエストを大量送信する'],answer:1,exp:'SYN floodはTCPの3ウェイハンドシェイクを悪用し、half-open接続を大量に作成してサーバのリソース（メモリ・接続テーブル）を枯渇させます。'},
|
||
{q:'DNSアンプ攻撃で攻撃者が悪用する特性はどれか。',choices:['DNSサーバの脆弱性を直接攻撃する','小さいクエリに対して大きいレスポンスが返るDNSの増幅特性','DNSキャッシュに偽情報を注入する','DNSサーバ自体をダウンさせる'],answer:1,exp:'DNSアンプ攻撃は小さいDNSクエリ（数十バイト）に対して何倍もの大きいDNSレスポンス（数千バイト）が返る増幅特性を利用します。'},
|
||
{q:'APT（高度標的型攻撃）の特徴として正しいものはどれか。',choices:['不特定多数を短時間で攻撃する','標的を定め長期にわたって持続的に侵入・情報窃取を行う','パスワードを総当たりで試す','ランサムウェアを展開して即座に金銭を要求する'],answer:1,exp:'APTは特定の標的（政府・重要インフラ等）に対して長期間潜伏しながら情報を収集・窃取する国家レベルの攻撃です。'}
|
||
]
|
||
},
|
||
{ id:'s18', num:'S18', title:'脆弱性管理', freq:'mid', diff:2,
|
||
concept:`<p>脆弱性管理はソフトウェアの欠陥を発見・評価・修正するサイクルです。ゼロデイ脆弱性は特に対応が難しく、多層防御が重要です。</p><div class="formula-box"><div class="formula-label">脆弱性評価・管理の仕組み</div>CVE（Common Vulnerabilities and Exposures）：脆弱性の識別番号（例：CVE-2021-44228）<br>CVSS（Common Vulnerability Scoring System）：脆弱性の深刻度スコア（0.0〜10.0）<br>NVD（National Vulnerability Database）：米NISTが管理するCVEデータベース<br>JVN（Japan Vulnerability Notes）：日本のIPAが運用する脆弱性情報データベース</div><p>脆弱性の種類：設計上の欠陥（CSRF等の仕様設計）・実装上のバグ（バッファオーバーフロー等）・設定ミス（デフォルトパスワード・不要サービスの放置）。設定ミスは最もよくある脆弱性の源です。</p>`,
|
||
examtips:[
|
||
'CVSS v3の基本スコアは0.0〜10.0。Critical（9.0〜10.0）・High（7.0〜8.9）・Medium・Low・None。',
|
||
'ゼロデイ脆弱性：パッチが存在しない状態での攻撃。ワークアラウンド（回避策）で暫定対応するしかない。',
|
||
'ペネトレーションテスト：攻撃者視点でシステムを試験的に攻撃し脆弱性を発見する手法。バグバウンティプログラムも関連。'
|
||
],
|
||
keypoints:[
|
||
'CVE：脆弱性の共通識別番号。CVSSでスコアリング（0.0〜10.0）',
|
||
'ゼロデイ：パッチ未存在の脆弱性。WAF・IPS・行動監視で暫定対応',
|
||
'ペネトレーションテスト：倫理的ハッカーが攻撃してセキュリティを評価',
|
||
'脆弱性の3種類：設計欠陥・実装バグ・設定ミス',
|
||
'JVN：日本の脆弱性情報データベース。IPAが運用'
|
||
],
|
||
quiz:[
|
||
{q:'CVSSの説明として正しいものはどれか。',choices:['脆弱性の識別番号（ID）を付与する仕組み','脆弱性の深刻度を0.0〜10.0でスコアリングする共通評価システム','脆弱性情報を公開するデータベース','侵入テストの手法の標準'],answer:1,exp:'CVSS（Common Vulnerability Scoring System）は脆弱性の深刻度を標準化されたスコアで評価するフレームワークです。'},
|
||
{q:'ゼロデイ脆弱性の説明として正しいものはどれか。',choices:['脆弱性が発見されてから0日以内にパッチが提供されたもの','パッチや修正が存在しない状態で悪用されている脆弱性','CVSSスコアが0点の軽微な脆弱性','すでに修正済みの脆弱性'],answer:1,exp:'ゼロデイは発見（または公開）からパッチが出るまでの間に悪用されるか、パッチが存在しない状態の脆弱性です。'},
|
||
{q:'ペネトレーションテストの目的はどれか。',choices:['マルウェアを駆除する','攻撃者の視点でシステムを試験し脆弱性を発見する','ログを分析して不正アクセスを検知する','従業員にセキュリティ教育を行う'],answer:1,exp:'ペネトレーションテストは倫理的ハッカー（ペネトレーター）が実際の攻撃手法でシステムを試験し、悪用可能な脆弱性を特定します。'}
|
||
]
|
||
},
|
||
{ id:'s23', num:'S23', title:'サプライチェーン・DevSecOps', freq:'high', diff:2,
|
||
concept:`<p>ソフトウェア開発はOSSコンポーネントや外部ベンダーに依存しており、その供給経路（サプライチェーン）への攻撃が2020年代の重大な脅威となっています。<strong>DevSecOps</strong>は開発（Dev）・セキュリティ（Sec）・運用（Ops）を統合するアプローチです。</p><div class="formula-box"><div class="formula-label">サプライチェーン攻撃の代表例</div>SolarWinds 事件（2020）：正規のソフトウェア更新に悪意あるコードを混入<br>Log4Shell（CVE-2021-44228）：広く使われるOSSライブラリの脆弱性が多数の製品に波及<br>XZ Utils バックドア（2024）：メンテナーへのソーシャルエンジニアリングでOSSにバックドアを挿入</div><div class="formula-box"><div class="formula-label">主な対策技術・フレームワーク</div>SBOM（Software Bill of Materials）：ソフトウェアの部品表。依存コンポーネントを機械可読形式で管理<br>SLSA（Supply chain Levels for Software Artifacts）：Googleが提唱するサプライチェーン完全性フレームワーク<br>Shift Left：セキュリティテストを開発の初期フェーズに前倒し<br>SAST/DAST：静的解析（コード）・動的解析（実行時）の自動セキュリティテスト<br>シークレット管理：認証情報をコードに書かずVault等で管理</div><p>CI/CDパイプラインはコードから本番環境への自動経路のため、悪意ある変更の大量配布リスクがあります。パイプライン自体のアクセス制御とシークレット管理が重要です。</p>`,
|
||
examtips:[
|
||
'SBOM は脆弱性が発覚した際に「自社製品のどのバージョンが影響を受けるか」を即座に特定できる。Log4Shell のような波及的脆弱性への対応で重要性が認識された。',
|
||
'Shift Left：開発の後期でなく設計・コーディング段階からセキュリティを組み込む。発見コストが最も低いフェーズで問題を潰す考え方。',
|
||
'CI/CD パイプラインへの攻撃：ソースコードへの不正コミット・パイプラインへの不正アクセス・シークレットの漏洩が主な攻撃ベクター。コードレビュー・SAST・シークレットスキャンで対策。'
|
||
],
|
||
keypoints:[
|
||
'SBOM：ソフトウェアの部品表。OSS依存関係を管理し脆弱性の影響範囲を即座に把握',
|
||
'サプライチェーン攻撃：正規の更新・OSS・外部ベンダーを経由して悪意あるコードを配布',
|
||
'Shift Left：セキュリティテストを開発の初期フェーズに前倒す DevSecOps の原則',
|
||
'SAST：静的解析（コードを実行せず解析）。DAST：動的解析（実行して脆弱性を発見）',
|
||
'シークレット管理：認証情報・APIキーをコードにハードコードせず Vault・シークレットマネージャーで管理'
|
||
],
|
||
quiz:[
|
||
{q:'SBOM（Software Bill of Materials）の主な用途はどれか。',choices:['ソフトウェアのパフォーマンスを計測する','ソフトウェアに含まれる依存コンポーネントを管理し脆弱性発覚時の影響範囲を特定する'],answer:1,exp:'SBOMはOSSなど依存コンポーネントの一覧を機械可読で管理。Log4Shellのような波及的脆弱性で「自社製品への影響あるか」を即座に判定できます。'},
|
||
{q:'DevSecOps の Shift Left が意味するのはどれか。',choices:['開発リリース直前にまとめてセキュリティテストを行う','設計・コーディング段階からセキュリティチェックを組み込む'],answer:1,exp:'Shift Left は問題を早期発見するほどコストが低いという考えに基づき、セキュリティを開発の上流フェーズに前倒しします。'},
|
||
{q:'SolarWinds 攻撃（2020年）の手口として正しいのはどれか。',choices:['フィッシングメールで多数の社員を騙した','正規のソフトウェアアップデートに悪意あるコードを混入して配布した'],answer:1,exp:'攻撃者は SolarWinds のビルドシステムに侵入し、正規の Orion 製品アップデートにバックドアを仕込みました。多数の政府機関・企業が被害を受けました。'},
|
||
{q:'CI/CD パイプラインにおけるシークレット管理のベストプラクティスはどれか。',choices:['API キーをソースコードのコメントに記載する','Vault やクラウドのシークレットマネージャーで管理し実行時に環境変数として注入する'],answer:1,exp:'認証情報をコードにハードコードするとリポジトリ履歴に残り漏洩します。シークレットマネージャーで一元管理し、パイプライン実行時のみ注入する方式が安全です。'}
|
||
]
|
||
},
|
||
{ id:'s24', num:'S24', title:'AI セキュリティ', freq:'mid', diff:2,
|
||
concept:`<p>生成AI・LLM（大規模言語モデル）の急速な普及に伴い、AI固有のセキュリティリスクが新たに生まれています。2026年現在、情報処理試験でも出題が始まっています。</p><div class="formula-box"><div class="formula-label">AI に対する主な攻撃手法</div>プロンプトインジェクション：悪意ある指示を入力に混入させ意図しない動作を誘発<br> → 直接型：ユーザーが直接モデルに悪意ある指示を入力<br> → 間接型：外部コンテンツ（Webページ・ドキュメント）経由で注入<br>データポイズニング：学習データに汚染データを混入しモデルの動作を操作<br>モデル反転攻撃：モデルの出力から学習データの情報を推測・復元<br>モデル抽出攻撃：大量のクエリを通じてモデルのロジックを盗み取る</div><div class="formula-box"><div class="formula-label">AI 利用時の情報セキュリティリスク</div>機密情報漏洩：プロンプトに機密情報・個人情報を入力すると外部に送信される<br>幻覚（Hallucination）：誤情報の生成と信頼。セキュリティアドバイスの誤り<br>AIエージェントの過剰権限：自律的に行動するエージェントが不要なアクセスを取得</div><p>OWASP は LLM アプリケーション向けの「Top 10 for LLM Applications」を公開。プロンプトインジェクション・安全でないプラグイン設計・過度のエージェント自律性などがトップリスクに挙がっています。</p>`,
|
||
examtips:[
|
||
'プロンプトインジェクションは OWASP Top 10 for LLM（2025年版）の第1位。システムプロンプトの漏洩・安全フィルタのバイパスが典型的な攻撃結果。対策は入力検証・モデルの権限最小化。',
|
||
'社員が業務で生成 AI を使う際の情報漏洩：入力したプロンプトが学習データになる可能性・外部サービスへの送信リスク。組織は利用ガイドラインを整備し、機密情報の入力を禁止する必要がある。',
|
||
'AI のセキュリティは従来のセキュリティと異なる点がある：モデルはブラックボックスで動作が不透明・出力の検証が困難・学習データへの攻撃（ポイズニング）という新しいベクターがある。'
|
||
],
|
||
keypoints:[
|
||
'プロンプトインジェクション：悪意ある指示を入力に混入。直接型・間接型がある',
|
||
'データポイズニング：学習データの汚染でモデルの動作を操作',
|
||
'モデル反転攻撃：モデル出力から学習データの機密情報を推測',
|
||
'機密情報漏洩リスク：生成AIサービスへの機密データ入力は外部送信・学習リスクあり',
|
||
'OWASP Top 10 for LLM：プロンプトインジェクション・安全でないプラグイン・過剰権限エージェントなど'
|
||
],
|
||
quiz:[
|
||
{q:'LLM への入力に悪意ある指示を埋め込み意図しない動作を起こさせる攻撃はどれか。',choices:['データポイズニング','プロンプトインジェクション'],answer:1,exp:'プロンプトインジェクションはモデルへの入力に隠れた指示を含め、システムプロンプトの上書き・安全フィルタのバイパス・機密情報の漏洩を狙います。'},
|
||
{q:'AI モデルの学習データに意図的に汚染データを混入する攻撃はどれか。',choices:['プロンプトインジェクション','データポイズニング（汚染攻撃）'],answer:1,exp:'データポイズニングは学習フェーズを攻撃します。汚染されたモデルは特定の入力に対して攻撃者が望む誤った出力を返すようになります。'},
|
||
{q:'社員が業務で生成 AI サービスを使う際の主なセキュリティリスクはどれか。',choices:['AIが返した答えが長くなること','機密情報・個人情報をプロンプトに入力し外部サービスに送信してしまうこと'],answer:1,exp:'生成AIサービスに送ったプロンプトは外部に送信されます。機密情報・顧客データの入力は情報漏洩につながるため、組織のガイドラインで明示的に禁止する必要があります。'},
|
||
{q:'OWASP Top 10 for LLM Applications に含まれるリスクはどれか。',choices:['ネットワーク帯域の不足','プロンプトインジェクション・安全でないプラグイン設計・過剰権限エージェント'],answer:1,exp:'OWASP は LLM 特有のリスクとして、プロンプトインジェクション・機密情報漏洩・不適切な出力処理・過剰なエージェント自律性などを挙げています。'}
|
||
]
|
||
},
|
||
{ id:'s26', num:'S26', title:'ソーシャルエンジニアリング', freq:'high', diff:1,
|
||
concept:`<p><strong>ソーシャルエンジニアリング</strong>は技術的な脆弱性ではなく、人間の心理・行動を操作して情報を騙し取る攻撃です。技術対策だけでは防げず、教育と手続きが重要です。</p><div class="formula-box"><div class="formula-label">主な攻撃手法</div>フィッシング（Phishing）：偽のメール・Webサイトで認証情報を詐取<br>スピアフィッシング（Spear Phishing）：特定の個人・組織を狙ったフィッシング<br>ホエーリング（Whaling）：経営幹部（クジラ）を狙ったスピアフィッシング<br>ヴィッシング（Vishing）：音声通話（Voice+Phishing）で情報詐取<br>スミッシング（Smishing）：SMS（SMS+Phishing）で偽URLに誘導<br>BEC（Business Email Compromise）：幹部・取引先を騙り振込詐欺や情報窃取<br>プリテキスティング（Pretexting）：架空のシナリオを作り信頼を得る手口<br>ベイティング（Baiting）：マルウェア入りUSBを置き去りにして拾わせる</div><p>テールゲーティング（ピギーバッキング）：正規の入室者の後ろについて無断入場する物理的ソーシャルエンジニアリング。</p><p>対策：多層防御（MFA・DMARC）＋訓練（標的型メール訓練）＋手続き（電話確認・上長承認）。技術だけでは防げないため<strong>セキュリティ意識教育（Security Awareness Training）</strong>が不可欠です。</p>`,
|
||
examtips:[
|
||
'フィッシング系は名前と説明の組み合わせが出題される。特に「スピアフィッシング≠一般的なフィッシング」「ホエーリング=経営幹部狙い」「BEC=振込詐欺・情報漏洩」の3つを確実に区別すること。',
|
||
'BEC（ビジネスメール詐欺）：CEO や取引先に成りすまして送金指示を出す。メールの正当性確認が対策（電話で二重確認）。近年の試験で増加中。',
|
||
'プリテキスティングはソーシャルエンジニアリングの基盤となる手法。「自分は IT 部門の者ですが…」といった架空の状況を設定して情報を引き出す。'
|
||
],
|
||
keypoints:[
|
||
'フィッシング：偽サイト・偽メールで認証情報を詐取',
|
||
'スピアフィッシング：特定個人を事前調査して狙う高度なフィッシング',
|
||
'BEC：幹部・取引先を騙る振込詐欺。電話による二重確認が対策',
|
||
'ヴィッシング/スミッシング：電話/SMSを使ったフィッシング変種',
|
||
'テールゲーティング：物理的な不正入館。二重扉（マンとラップ）で防止',
|
||
'セキュリティ意識教育（SAT）：技術対策だけでは防げないため人への教育が必須'
|
||
],
|
||
quiz:[
|
||
{q:'特定の個人・組織を事前調査して狙うフィッシングを何と呼ぶか。',choices:['ホエーリング','スピアフィッシング'],answer:1,exp:'スピアフィッシングは標的に関する情報を事前収集し、信憑性の高い偽メール・偽サイトを使います。一般的なフィッシングより検出が困難です。'},
|
||
{q:'経営幹部（CEO・CFO等）を狙って多額の送金を指示するメール詐欺はどれか。',choices:['スミッシング','BEC（ビジネスメール詐欺）'],answer:1,exp:'BEC は CEO や取引先に成りすました偽メールで送金指示を出す詐欺。電話等での二重確認が有効な対策です。'},
|
||
{q:'マルウェアを仕込んだ USB メモリを駐車場等に放置して拾わせる攻撃はどれか。',choices:['プリテキスティング','ベイティング（Baiting）'],answer:1,exp:'ベイティングは物理的な囮デバイスを使う手法。「会社名のラベルが貼られた USB」などを好奇心から挿してしまうことを狙います。'},
|
||
{q:'ソーシャルエンジニアリング対策として根本的に有効なのはどれか。',choices:['ファイアウォールの強化','セキュリティ意識教育（SAT）と手続き上の二重確認'],answer:1,exp:'ソーシャルエンジニアリングは人を騙す攻撃のため、技術対策だけでは防げません。従業員教育と標的型メール訓練、電話確認などの手続きが根本的な対策です。'}
|
||
]
|
||
},
|
||
{ id:'s27', num:'S27', title:'セキュアプログラミング', freq:'high', diff:2,
|
||
concept:`<p>安全なソフトウェアを開発するために、コード実装レベルの脆弱性を理解し回避する技法です。支援士試験ではコードの脆弱性と対策の組み合わせが問われます。</p><div class="formula-box"><div class="formula-label">主な脆弱性とコード上の原因</div>バッファオーバーフロー：確保したメモリ領域を超えて書き込む。C言語の gets/strcpy 等で発生<br> → 対策：境界チェック関数（fgets, strncpy）・ASLR・スタックカナリア<br>整数オーバーフロー：型の最大値を超えた演算。負数化・ゼロ除算につながる<br>フォーマット文字列攻撃：printf(user_input) のように書式文字列にユーザー入力を渡す<br> → 対策：printf("%s", user_input) と固定書式を使う<br>Use-After-Free：解放済みメモリへのアクセス。ヒープ破壊・任意コード実行につながる<br>競合状態（Race Condition）：TOCTOU（Time-of-Check-Time-of-Use）問題</div><div class="formula-box"><div class="formula-label">セキュアコーディングの原則</div>入力検証：信頼できない入力は全て検証（ホワイトリスト方式が原則）<br>出力エスケープ：HTML/SQL/コマンドへの出力時は適切にエスケープ<br>最小権限：プロセス・ファイル・DBアカウントは必要最小限の権限<br>エラー処理：内部情報を漏洩しないエラーメッセージ</div><p>OWASP ASVS（Application Security Verification Standard）は Webアプリのセキュリティ要件を体系化したフレームワーク。CERT Coding Standards はコードレベルのセキュアプログラミング規約です。</p>`,
|
||
examtips:[
|
||
'バッファオーバーフローは「確保した領域を超えて書き込む」ことで戻りアドレスを書き換え任意コードを実行できる。対策は境界チェック・コンパイラ保護（スタックカナリア・ASLR）。',
|
||
'フォーマット文字列攻撃：`printf(str)` のような実装でユーザーが `%x %x` などを入力するとメモリダンプができてしまう。`printf("%s", str)` と書式文字列を固定するだけで防げる。',
|
||
'TOCTOU：「チェック時点」と「使用時点」の間に状態が変わる競合状態。ファイルアクセスやトランザクションで発生しやすい。'
|
||
],
|
||
keypoints:[
|
||
'バッファオーバーフロー：境界チェック不足。ASLR・スタックカナリアで緩和',
|
||
'フォーマット文字列攻撃：printf(input) の誤実装。書式を固定して防ぐ',
|
||
'整数オーバーフロー：型の範囲超え。符号付き負数化が危険',
|
||
'Use-After-Free：解放済みメモリ参照。任意コード実行につながる',
|
||
'入力バリデーション：ホワイトリスト方式（許可リスト）が原則',
|
||
'OWASP ASVS：Webアプリのセキュリティ要件標準'
|
||
],
|
||
quiz:[
|
||
{q:'バッファオーバーフローが発生する根本的な原因はどれか。',choices:['暗号化されていないメモリを使っている','プログラムが確保したバッファの境界チェックをせずに書き込む'],answer:1,exp:'バッファオーバーフローは確保した領域を超えた書き込みでスタック上の戻りアドレスを書き換え、任意コードの実行につながります。'},
|
||
{q:'`printf(user_input)` という実装に存在する脆弱性はどれか。',choices:['バッファオーバーフロー','フォーマット文字列攻撃'],answer:1,exp:'書式文字列にユーザー入力を直接渡すと `%x` などで任意のメモリが読めてしまいます。`printf("%s", user_input)` と書式を固定することで防げます。'},
|
||
{q:'入力バリデーションにおいてセキュリティ的に推奨されるアプローチはどれか。',choices:['危険な文字のみ禁止するブラックリスト方式','許可する文字・値のみを定義するホワイトリスト方式'],answer:1,exp:'ブラックリスト方式は危険なパターンの定義漏れが発生しやすい。ホワイトリスト（許可リスト）方式は定義外を全て拒否するため堅牢です。'},
|
||
{q:'TOCTOU（Time-of-Check Time-of-Use）が引き起こす脆弱性はどれか。',choices:['メモリリーク','チェック時点と使用時点の間に状態が変わる競合状態'],answer:1,exp:'TOCTOU は権限チェック後・実際の操作前に状態が変わることで権限昇格・意図しない操作が発生する脆弱性です。アトミック操作で防ぎます。'}
|
||
]
|
||
}
|
||
]},
|
||
{ id:'management', label:'管理・法規', icon:'scale', units:[
|
||
{ id:'s19', num:'S19', title:'インシデント対応・CSIRT', freq:'high', diff:2,
|
||
concept:`<p>インシデント対応は<strong>PDCA</strong>ではなく<strong>PICERF</strong>サイクル（準備→識別→封じ込め→根絶→復旧→事後レビュー）で考えます。<strong>CSIRT</strong>（Computer Security Incident Response Team）は組織内外のインシデントを専門に扱うチームです。</p><div class="formula-box"><div class="formula-label">インシデント対応フェーズ（NIST SP 800-61）</div>1. 準備（Preparation）：体制・ツール・手順書の整備<br>2. 検知・分析（Detection & Analysis）：インシデントの識別と影響範囲確認<br>3. 封じ込め（Containment）：被害の拡大防止（ネットワーク切断等）<br>4. 根絶（Eradication）：マルウェア除去・脆弱性修正<br>5. 復旧（Recovery）：サービス再開・モニタリング<br>6. 事後レビュー（Post-incident Activity）：再発防止策の策定</div><p>SIEM（Security Information and Event Management）：複数のログを統合して異常を検知するプラットフォーム。SOC（Security Operations Center）はSIEMを監視する専門チームです。</p>`,
|
||
examtips:[
|
||
'封じ込め（Containment）は根絶より先に行う。まず被害を止め、その後マルウェアを除去する。',
|
||
'フォレンジックス：デジタル証拠の収集・保全・分析。証拠の連鎖（Chain of Custody）を保つことが重要。',
|
||
'JPCERT/CC：日本のCSIRTの調整機関。脆弱性情報・インシデント情報を収集・共有する。'
|
||
],
|
||
keypoints:[
|
||
'インシデント対応6フェーズ：準備→検知→封じ込め→根絶→復旧→事後レビュー',
|
||
'封じ込めが根絶の前：まず被害拡大を止めてからマルウェアを除去',
|
||
'CSIRT：インシデント対応の専門チーム。JPCERT/CCが日本の調整機関',
|
||
'SIEM：ログを統合して異常検知。SOCが監視を担う',
|
||
'デジタルフォレンジック：証拠保全・Chain of Custodyが重要'
|
||
],
|
||
quiz:[
|
||
{q:'インシデント対応において「封じ込め」フェーズの目的はどれか。',choices:['マルウェアを完全に除去する','インシデントの被害拡大を防ぐ','サービスを復旧させる','事後レビューを実施する'],answer:1,exp:'封じ込めはまず被害の拡大を止めることが目的。ネットワーク隔離などを行います。マルウェア除去は「根絶」フェーズです。'},
|
||
{q:'CSIRTの役割として正しいものはどれか。',choices:['ソフトウェアの開発','セキュリティインシデントの検知・対応・調整','ネットワーク機器の保守','社員の人事管理'],answer:1,exp:'CSIRTはセキュリティインシデントを専門に検知・分析・対応し、関係機関との情報共有・調整を行うチームです。'},
|
||
{q:'SIEMの機能として正しいものはどれか。',choices:['ファイアウォールとして通信を遮断する','複数システムのログを集約して脅威を相関分析する','マルウェアをサンドボックスで実行する','脆弱性スキャンを行う'],answer:1,exp:'SIEMは複数のログソースを統合し、相関分析によって個別ログでは見えない攻撃パターンを検知します。'},
|
||
{q:'デジタルフォレンジックにおける「Chain of Custody（証拠の連鎖）」の目的はどれか。',choices:['マルウェアを削除する','証拠が収集から法廷提出まで改ざんされていないことを証明する','バックアップを取得する','インシデントを封じ込める'],answer:1,exp:'Chain of Custodyは証拠の取り扱い履歴を記録し、証拠の完全性と法的証拠能力を維持するための手続きです。'}
|
||
]
|
||
},
|
||
{ id:'s20', num:'S20', title:'法規・評価基準', freq:'high', diff:2,
|
||
concept:`<p>情報セキュリティに関わる法律・制度・評価基準を整理します。試験では法律の名前と対象・罰則の組み合わせが問われます。</p><div class="formula-box"><div class="formula-label">主な法律・制度</div>不正アクセス禁止法：不正アクセス行為そのものを禁止（クラッキング・フィッシング等）<br>個人情報保護法：個人情報の取得・利用・保管・第三者提供の規制。漏洩時の報告義務<br>サイバーセキュリティ基本法：国のサイバーセキュリティ戦略の基盤。NISC設置の根拠法<br>不正競争防止法：営業秘密の保護。漏洩・横領に刑事罰<br>電子署名法：電子署名の法的効力を定める</div><div class="formula-box"><div class="formula-label">評価基準・フレームワーク</div>ISO/IEC 15408（CC：Common Criteria）：製品のセキュリティ評価基準。EALレベルで評価<br>PCI DSS：クレジットカード業界のセキュリティ基準（加盟店・決済事業者向け、12要件で構成）<br>NIST SP 800シリーズ：米国のセキュリティガイドライン群<br>NIST CSF 2.0（2024年2月）：Govern（統治）を追加した6機能（G-IPDRR）<br> Govern→Identify→Protect→Detect→Respond→Recover<br>ISO/IEC 27001：ISMS の国際規格（Annex A に管理策を列挙）</div>`,
|
||
examtips:[
|
||
'不正アクセス禁止法：権限なしのコンピュータへの不正ログインを禁止。ポートスキャンだけでは違反にならないが、脆弱性を突いた侵入は違反。',
|
||
'個人情報保護法：令和4年（2022年）施行で漏洩報告義務化・個人関連情報追加。令和8年（2026年）4月改正法案で<strong>課徴金制度</strong>が新設予定（違法利得への制裁強化）。',
|
||
'<strong>NIST CSF 2.0（2024年2月）は6機能</strong>：旧CSF 1.1の5機能にGovern（統治）が追加。G-IPDRRの頭文字で覚える。試験では「5機能」と「6機能」の区別が問われる。'
|
||
],
|
||
keypoints:[
|
||
'不正アクセス禁止法：権限なしのアクセス行為を禁止。IDのなりすましも対象',
|
||
'個人情報保護法（2022年改正）：漏洩報告義務化。2026年改正法案で課徴金制度導入予定',
|
||
'ISO/IEC 27001:2022：ISMSの国際規格。管理策が114→93に再整理（2022年改訂）',
|
||
'ISO/IEC 15408（CC）：製品セキュリティの国際評価基準。EAL1〜7のレベル',
|
||
'NIST CSF 2.0（2024年）：Govern追加で6機能（G-IPDRR）。旧1.1は5機能（IPDRR）'
|
||
],
|
||
quiz:[
|
||
{q:'不正アクセス禁止法で禁じられる行為として正しいものはどれか。',choices:['セキュリティ調査のための公開Webサーバのポートスキャン','他人のIDとパスワードを使って無断でログインすること','脆弱性情報をセキュリティ機関に報告すること','自社システムへのペネトレーションテスト'],answer:1,exp:'不正アクセス禁止法は権限なしに他人のIDなどを使ってコンピュータにアクセスする行為を禁じます。'},
|
||
{q:'2022年施行の個人情報保護法改正で新たに義務化された主な事項はどれか。',choices:['全企業のISMS認証取得','個人情報漏洩時の本人および個人情報保護委員会への報告義務','生体情報の収集禁止','クッキーの使用禁止'],answer:1,exp:'2022年改正で個人情報の漏洩・侵害が発生した場合、本人と個人情報保護委員会への報告が義務化されました。'},
|
||
{q:'2024年2月に公開されたNIST CSF 2.0でCSF 1.1から新たに追加された機能はどれか。',choices:['Respond（対応）','Recover（回復）','Govern（統治）','Audit（監査）'],answer:2,exp:'NIST CSF 2.0ではGovern（統治）が新設され6機能（G-IPDRR）になりました。組織のサイバーセキュリティ戦略・ガバナンス・サプライチェーンリスク管理を担います。'},
|
||
{q:'ISO/IEC 15408（CC：Common Criteria）の用途はどれか。',choices:['組織のISMS認証','IT製品・システムのセキュリティ機能の評価・認証','個人情報の保護規制','クレジットカードの安全基準'],answer:1,exp:'Common Criteriaは情報技術製品のセキュリティ機能をEAL（Evaluation Assurance Level）1〜7で評価・認証する国際規格です。'},
|
||
{q:'ISO/IEC 27001の2022年改訂での主な変更点はどれか。',choices:['Annex Aの管理策が114から93に再整理された','認証の有効期限が3年から5年になった','PDCAサイクルが廃止された','リスクアセスメントが任意になった'],answer:0,exp:'ISO/IEC 27001:2022改訂ではAnnex Aの管理策が114→93に整理され、組織的・人的・物理的・技術的の4テーマに再分類されました。'}
|
||
]
|
||
},
|
||
{ id:'s21', num:'S21', title:'クラウドセキュリティ', freq:'high', diff:2,
|
||
concept:`<p>クラウドサービスは利用形態（IaaS/PaaS/SaaS）によって、提供者とユーザーのセキュリティ責任範囲が異なります。これを<strong>責任共有モデル</strong>（Shared Responsibility Model）と呼びます。</p><div class="formula-box"><div class="formula-label">責任共有モデルの例（IaaS）</div>クラウド事業者の責任：物理インフラ・ハイパーバイザ・ネットワーク<br>ユーザーの責任：OS・ミドルウェア・アプリ・データ・IAM・暗号化設定<br><br>SaaS に近づくほどユーザーの責任は減るが、<strong>IAMとデータの責任は常にユーザー側</strong></div><p>クラウド特有のセキュリティリスクとして設定ミスが最多。S3バケット公開設定やルートアカウントのMFA無効化などが典型例です。</p><div class="formula-box"><div class="formula-label">主なクラウドセキュリティ技術</div>CASB（Cloud Access Security Broker）：クラウドサービスへのアクセスを可視化・制御する中間プロキシ<br>CSPM（Cloud Security Posture Management）：クラウド設定のセキュリティポリシー準拠を継続的に検証<br>SWG（Secure Web Gateway）：Webアクセスをフィルタリング。ゼロトラストで境界の代替<br>CWPP（Cloud Workload Protection Platform）：クラウド上のワークロードを保護</div>`,
|
||
examtips:[
|
||
'責任共有モデルは頻出。「物理層はクラウド事業者、IAMとデータはユーザー責任」を軸に理解する。SaaSでも「誰がアクセスできるか（IAM）」はユーザー責任。',
|
||
'CASB：シャドーIT（未承認クラウド利用）の可視化にも使われる。「クラウドへのアクセスを制御する中間ブローカー」という説明で選択肢に出やすい。',
|
||
'CSPM：クラウドの設定ミスを検出する。IaaS/PaaSのセキュリティポリシー違反を継続的に監視する仕組みで近年の試験で増加中。'
|
||
],
|
||
keypoints:[
|
||
'責任共有モデル：物理〜ハイパーバイザはCS事業者、OS以上はユーザー（IaaS）。IAMとデータは常にユーザー',
|
||
'CASB：クラウドアクセスの可視化・制御・シャドーIT検出',
|
||
'CSPM：クラウドの設定ミス（S3公開・IAM過剰権限等）を継続監視',
|
||
'SWG：Webトラフィックフィルタリング。ゼロトラスト構成での境界代替',
|
||
'クラウドのIAM：最小権限の原則。ルートアカウントのMFA必須・サービスアカウントには必要最小限のロール'
|
||
],
|
||
quiz:[
|
||
{q:'クラウド（IaaS）の責任共有モデルにおいて、常にユーザー側の責任となるものはどれか。',choices:['物理サーバのハードウェア管理','ハイパーバイザのセキュリティパッチ','IAM（アクセス権限）の管理とデータの保護','データセンターの物理セキュリティ'],answer:2,exp:'IaaS責任共有モデルでは、物理インフラはCSP責任ですが、IAMとデータはサービス形態に関わらず常にユーザーの責任です。'},
|
||
{q:'CASBが主に解決する課題はどれか。',choices:['クラウドサービスの可用性保証','承認されていないクラウドサービスの利用（シャドーIT）の可視化と制御','クラウドサーバの脆弱性スキャン','クラウドのバックアップ管理'],answer:1,exp:'CASBはユーザーとクラウドサービスの間に立つブローカーで、シャドーITの可視化、データ漏洩防止、アクセス制御などを提供します。'},
|
||
{q:'クラウド設定のセキュリティポリシー準拠を継続的に検証するツールはどれか。',choices:['CASB','SIEM','CSPM','WAF'],answer:2,exp:'CSPM（Cloud Security Posture Management）はクラウドインフラの設定が組織のセキュリティポリシーや規制要件に準拠しているか継続的に監視します。'},
|
||
{q:'クラウドのIAM設定で最初に実施すべきセキュリティ対策はどれか。',choices:['全ユーザーへの管理者権限付与','ルートアカウントへのMFA有効化と日常業務での不使用','すべてのAPIアクセスを無効化','クラウドの外部公開を禁止する'],answer:1,exp:'ルートアカウントは全権限を持つため、MFAを有効化し日常業務に使わないことが最重要の初期設定です。'}
|
||
]
|
||
},
|
||
{ id:'s22', num:'S22', title:'OAuth 2.0/OIDC/SAML', freq:'high', diff:2,
|
||
concept:`<p>現代のWebサービスでIDを連携させる3つのプロトコルを整理します。<strong>OAuth 2.0</strong>は「認可（Authorization）」、<strong>OIDC</strong>は「認証（Authentication）」、<strong>SAML</strong>はエンタープライズの「フェデレーション認証」です。</p><div class="formula-box"><div class="formula-label">3プロトコルの役割</div>OAuth 2.0：リソースへのアクセス権を第三者に委譲する認可フレームワーク<br> →「Googleドライブに○○アプリのアクセスを許可する」はOAuth 2.0<br>OIDC（OpenID Connect）：OAuth 2.0の上に認証レイヤーを追加<br> →「Googleアカウントで△△にログイン」はOIDC<br>SAML 2.0：XMLベースのSSO標準。企業向け（IdP/SPの概念の基盤）</div><div class="viz-flow"><div class="vf-node">ユーザー<div class="vf-sub">ブラウザ</div></div><div class="vf-arrow">→</div><div class="vf-node vf-hl">IdP<div class="vf-sub">認可/認証</div></div><div class="vf-arrow">→</div><div class="vf-node">トークン<div class="vf-sub">JWT/SAML</div></div><div class="vf-arrow">→</div><div class="vf-node">SP/RP<div class="vf-sub">検証・許可</div></div></div><p>JWTはHeader.Payload.Signatureの3部構成。Payloadにsub（ユーザーID）やexp（有効期限）などのクレームを格納します。IDaaSはこれらを統合したSaaS型のID管理サービスです（Azure AD/Okta等）。</p>`,
|
||
examtips:[
|
||
'OAuth 2.0は「認可」フレームワーク（誰が何をできるか）。OIDC は OAuth 2.0 の上に「認証（誰か）」を追加。この2層構造を混同しないこと。',
|
||
'SAMLとOIDCの使い分け：SAMLはエンタープライズSSO（人事システム・社内ポータル）、OIDCはモバイル・Web API向け（軽量・JSONベース）。',
|
||
'JWTの検証：署名アルゴリズムはRS256（RSA）またはHS256（HMAC）。noneアルゴリズムを許可する実装はJWT署名バイパス脆弱性になる。'
|
||
],
|
||
keypoints:[
|
||
'OAuth 2.0：認可委譲フレームワーク。アクセストークンでAPIアクセスを許可',
|
||
'OIDC：OAuth 2.0に認証を追加。IDトークン（JWT）でユーザー情報を含む',
|
||
'SAML 2.0：XMLベースのエンタープライズSSO。IdPがSPにアサーションを渡す',
|
||
'JWT：Header.Payload.Signatureの3部構成。クレームにsub/iss/exp等',
|
||
'IDaaS：ID管理をSaaSで提供（Okta・Azure AD・Cognito等）。MFA・SSO・プロビジョニングを統合'
|
||
],
|
||
quiz:[
|
||
{q:'「Googleアカウントで外部サービスにログインする」ときに使われるプロトコルはどれか。',choices:['OAuth 2.0のみ','SAML 2.0','OIDC（OpenID Connect）','Kerberos'],answer:2,exp:'「Googleでログイン」はOIDCによる認証です。OIDCはOAuth 2.0の上に認証レイヤー（IDトークン）を追加したプロトコルです。'},
|
||
{q:'OAuth 2.0が主に提供するのはどれか。',choices:['ユーザー認証（誰であるかの確認）','リソースへのアクセス権委譲（認可）','パスワードの暗号化','セッション管理'],answer:1,exp:'OAuth 2.0は「認可（Authorization）」フレームワークで、リソースオーナーの代わりにサードパーティへアクセストークンを発行します。認証はOIDCが担います。'},
|
||
{q:'JWTの構造として正しいものはどれか。',choices:['Header.Payload（BASE64）のみ','Header.Payload.Signatureの3部構成','暗号化された単一のBlobデータ','XMLベースのアサーション'],answer:1,exp:'JWTはBase64URLエンコードされたHeader.Payload.Signatureの3部をドット区切りで繋いだ構造です。SignatureでHeader+Payloadの完全性を保証します。'},
|
||
{q:'SAMLとOIDCの使い分けとして適切な説明はどれか。',choices:['SAMLはモバイルアプリ向け、OIDCはレガシー企業システム向け','SAMLはエンタープライズSSO向け、OIDCはWeb/モバイルAPI向けで軽量','SAMLはOIDCの上位互換','OIDCはXMLベースでSAMLはJSONベース'],answer:1,exp:'SAMLはXMLベースで企業向け（HR・社内ポータル等）のSSO。OIDCはJSONベースで軽量・Web API・モバイルアプリ向けです。'}
|
||
]
|
||
},
|
||
{ id:'s28', num:'S28', title:'事業継続・BCP/BCM', freq:'high', diff:2,
|
||
concept:`<p><strong>BCP（Business Continuity Plan）</strong>は災害・インシデント発生時でも事業を継続または迅速に復旧するための計画です。<strong>BCM（Business Continuity Management）</strong>はその計画を策定・維持・改善する継続的なマネジメント体制です。</p><div class="formula-box"><div class="formula-label">主要な指標</div>RTO（Recovery Time Objective）：目標復旧時間。何時間以内に復旧するか<br>RPO（Recovery Point Objective）：目標復旧時点。何時点のデータまで失って許容できるか<br>RLO（Recovery Level Objective）：目標復旧レベル。どの程度の業務水準まで回復するか</div><div class="formula-box"><div class="formula-label">バックアップ戦略</div>3-2-1 ルール：3コピー・2種類のメディア・1つはオフサイト（遠隔地）保管<br>フルバックアップ：全データ。リストアが最速だが時間・容量が大きい<br>差分バックアップ：前回フルからの差分。リストアはフル+差分<br>増分バックアップ：前回バックアップからの増分。容量小だがリストアに複数必要<br>ホットサイト：即時切替可能な待機系。コスト大<br>ウォームサイト：数時間で切替可能。中程度のコスト<br>コールドサイト：設備のみ提供。立上げに時間がかかる</div><p>DRP（Disaster Recovery Plan）は IT システムの復旧に焦点を当てた計画で、BCPの一部です。ISO 22301 が BCM の国際規格です。</p>`,
|
||
examtips:[
|
||
'RTO と RPO は混同しやすい。RTO は「時間軸（復旧まで何時間）」、RPO は「データ軸（何時点のデータまで許容するか）」。RPO が短いほど頻繁なバックアップが必要。',
|
||
'3-2-1 ルールはランサムウェア対策でも頻出。「3つのコピー・2種類の媒体・1つはオフライン/オフサイト」の「1つはオフライン」が特に重要。',
|
||
'BCP と DRP の違い：BCP は事業全体の継続（人・業務プロセスも含む）、DRP は IT システム復旧計画。DRP は BCP の下位計画。'
|
||
],
|
||
keypoints:[
|
||
'RTO：目標復旧時間（何時間以内に復旧）',
|
||
'RPO：目標復旧時点（何時点のデータまで失って許容できるか）',
|
||
'3-2-1 ルール：3コピー・2メディア・1オフサイト。ランサムウェア対策にも有効',
|
||
'ホットサイト：即時切替・コスト大。コールドサイト：立上げに時間がかかる',
|
||
'BCP：事業継続計画全体。DRP は IT 復旧計画（BCP の一部）',
|
||
'ISO 22301：BCM の国際規格'
|
||
],
|
||
quiz:[
|
||
{q:'RPO（Recovery Point Objective）の説明として正しいのはどれか。',choices:['システムの復旧完了までの目標時間','障害発生時に許容できるデータ損失の時点（どこまで遡れるか）'],answer:1,exp:'RPO はデータの「どこまで失ってよいか」という目標値。RPO=1時間なら最大1時間分のデータ損失を許容し、1時間おきのバックアップが必要です。'},
|
||
{q:'ランサムウェア対策として 3-2-1 ルールで最も重要な要素はどれか。',choices:['クラウドに2つ以上の同期バックアップを持つこと','1つはネットワークから切り離されたオフライン/オフサイト保管をすること'],answer:1,exp:'クラウド同期バックアップはランサムウェアに一緒に暗号化されるリスクがあります。オフライン保管なら感染拡大が届かず、確実に復旧できます。'},
|
||
{q:'ホットサイト・ウォームサイト・コールドサイトのうち最も復旧時間が短いのはどれか。',choices:['コールドサイト','ホットサイト'],answer:1,exp:'ホットサイトは本番と同等の環境が常時稼働しており即時切替が可能。コスト最大ですが RTO は最短です。'},
|
||
{q:'BCPとDRPの関係として正しいものはどれか。',choices:['DRP は BCP よりも広い概念で事業全体を対象にする','BCP は事業継続計画全体で、DRP はその中の IT システム復旧計画'],answer:1,exp:'BCP は事業全体（人・プロセス・設備・IT）を対象にします。DRP は IT システムの復旧に特化した下位計画です。'}
|
||
]
|
||
},
|
||
{ id:'s29', num:'S29', title:'物理・環境セキュリティ', freq:'mid', diff:1,
|
||
concept:`<p>情報セキュリティはデジタルだけの問題ではありません。物理的なアクセスが許可されると技術的対策の多くが無意味になります。</p><div class="formula-box"><div class="formula-label">施設・入退室管理</div>多層防護（Defense in Depth）：外周フェンス→ゲート→受付→セキュリティゾーン→サーバ室<br>マンとラップ（Man Trap）：二重扉で1人ずつ認証する仕組み。テールゲーティング防止<br>ICカード・生体認証：入退室を個人単位で記録・制御<br>CCTV（監視カメラ）：抑止効果と証拠収集<br>テールゲーティング（ピギーバッキング）：正規入室者の後ろについて無断入場</div><div class="formula-box"><div class="formula-label">情報機器・媒体の管理</div>クリーンデスクポリシー：離席時に書類・資料・PC を施錠・片付ける<br>スクリーンロック：一定時間無操作でロック<br>クリアスクリーンポリシー：画面を離れるときにロックする習慣<br>メディア廃棄<br> 上書き：NIST SP 800-88 に基づく複数回上書き<br> 消磁（デガウサー）：磁気を消去。SSD には無効<br> 物理破壊：シュレッダー・溶解。確実だが復元不可</div>`,
|
||
examtips:[
|
||
'テールゲーティング対策はマンとラップ（二重扉+一人ずつ認証）。物理的なソーシャルエンジニアリングの代表例として問われる。',
|
||
'メディア廃棄方法の違い：消磁は SSD に無効（フラッシュメモリは磁気と関係ない）。確実な廃棄には物理破壊が必要。',
|
||
'クリーンデスクポリシーは内部不正・のぞき見・物理盗難の対策。試験では「離席時の対策」として選択肢に登場する。'
|
||
],
|
||
keypoints:[
|
||
'マンとラップ：二重扉で1人ずつ認証。テールゲーティング対策',
|
||
'クリーンデスクポリシー：離席時に書類・PC を施錠・片付け',
|
||
'テールゲーティング：正規者に続いて無断入場する物理的な不正',
|
||
'メディア廃棄：消磁（HDD向け）・物理破壊（SSD含む確実な方法）・上書き（NIST SP 800-88）',
|
||
'多層防護：外周→建物→フロア→サーバ室と段階的にセキュリティを強化'
|
||
],
|
||
quiz:[
|
||
{q:'テールゲーティング（ピギーバッキング）を防ぐための物理的対策はどれか。',choices:['ICカードの発行','マンとラップ（二重扉で1人ずつ認証）'],answer:1,exp:'マンとラップは認証された1人だけが入室できる二重扉の仕組みです。ICカードだけでは後ろからついてくる人物を止められません。'},
|
||
{q:'SSD（フラッシュメモリ）の確実な廃棄方法として適切なのはどれか。',choices:['消磁（デガウサー）処理','物理的な破壊（粉砕・溶解）'],answer:1,exp:'消磁は磁気記録を消去する手法のため、磁気を使わない SSD には効果がありません。フラッシュメモリの確実な廃棄には物理破壊が必要です。'},
|
||
{q:'クリーンデスクポリシーの主な目的はどれか。',choices:['デスクの整理整頓を義務づけること','離席時に書類・PC を片付け・施錠して情報漏洩・盗難を防ぐこと'],answer:1,exp:'クリーンデスクポリシーは内部不正・のぞき見・盗難からの情報保護が目的です。単なる整理整頓ではなく情報セキュリティ対策です。'},
|
||
{q:'多層防護（Defense in Depth）を物理セキュリティに適用した場合の正しい例はどれか。',choices:['サーバ室だけを高度に保護する','外周フェンス→建物ゲート→受付認証→サーバ室の段階的な防護'],answer:1,exp:'多層防護は単一の防護が破られても次の層で食い止める考え方。物理セキュリティでも複数の防護層を設けることが原則です。'}
|
||
]
|
||
},
|
||
{ id:'s30', num:'S30', title:'脅威インテリジェンス・MITRE ATT&CK', freq:'mid', diff:3,
|
||
concept:`<p><strong>脅威インテリジェンス（CTI: Cyber Threat Intelligence）</strong>は攻撃者・攻撃手法・悪意ある活動に関する情報を収集・分析して防御に活かす実践です。</p><div class="formula-box"><div class="formula-label">情報の種類</div>IoC（Indicators of Compromise）：侵害の痕跡。攻撃後に確認される具体的な証拠<br> → 悪意あるIPアドレス・ドメイン・マルウェアのハッシュ値・レジストリキー<br>IoA（Indicators of Attack）：攻撃中の兆候。攻撃の予兆・進行中のパターン<br>TTP（Tactics, Techniques, Procedures）：攻撃者の戦術・技法・手順の体系</div><div class="formula-box"><div class="formula-label">主なフレームワーク・標準</div>MITRE ATT&CK：実際の攻撃事例に基づくTTPsのナレッジベース。初期侵入→永続化→権限昇格→探索→横断→情報収集→流出の各フェーズをマトリクスで整理<br>STIX（Structured Threat Information eXpression）：脅威情報の記述形式（XML/JSON）<br>TAXII（Trusted Automated eXchange of Indicator Information）：脅威情報の自動共有プロトコル<br>ISAC（Information Sharing and Analysis Center）：業界別の脅威情報共有組織</div><p>ハニーポット：攻撃者を引き付ける囮システム。実際の重要システムではなく観察・情報収集が目的です。ハニーネットは複数のハニーポットで構成されたネットワークです。</p>`,
|
||
examtips:[
|
||
'MITRE ATT&CK はフェーズ（タクティクス）→手法（テクニック）→手順（サブテクニック）の3層構造。「攻撃者がどのフェーズで何をしたか」をマッピングするツールとして使われる。',
|
||
'IoC と IoA の違い：IoC は「侵害された証拠（事後）」、IoA は「攻撃中の兆候（予防）」。SIEM で IoC/IoA を検出することで対応を高速化する。',
|
||
'STIX/TAXII：脅威インテリジェンスを機械可読形式で記述し（STIX）、自動的に共有する（TAXII）仕組み。ISAC などの組織間での情報共有で使われる。'
|
||
],
|
||
keypoints:[
|
||
'CTI：脅威インテリジェンス。攻撃者・手法・IOCに関する情報収集・分析・活用',
|
||
'IoC：侵害の痕跡（マルウェアのハッシュ・悪意ある IP/ドメイン）',
|
||
'TTP：攻撃者の戦術・技法・手順。MITRE ATT&CK で体系化',
|
||
'MITRE ATT&CK：実際の攻撃TTPs を初期侵入から流出まで整理したナレッジベース',
|
||
'STIX/TAXII：脅威情報の記述（STIX）と自動共有（TAXII）の標準規格',
|
||
'ハニーポット：攻撃者を引き付ける囮システム。観察・インテリジェンス収集が目的'
|
||
],
|
||
quiz:[
|
||
{q:'MITRE ATT&CK が提供するのはどれか。',choices:['脆弱性のスコアリング基準','実際の攻撃事例に基づく攻撃者のTTPs（戦術・技法・手順）のナレッジベース'],answer:1,exp:'MITRE ATT&CK は実際のインシデントから収集した攻撃者の行動を体系化したフレームワークです。セキュリティチームが攻撃手法を理解し検知・対策を設計するために使います。'},
|
||
{q:'IoC（Indicators of Compromise）の具体例として正しいのはどれか。',choices:['攻撃者グループの動機と目的','マルウェアのハッシュ値・悪意ある通信先の IP アドレス'],answer:1,exp:'IoC は侵害が発生した「証拠」となる具体的な技術的指標です。SIEM にフィードすることでインシデントの検知・調査に活用されます。'},
|
||
{q:'脅威情報を機械可読形式で記述するための標準仕様はどれか。',choices:['CVSS','STIX（Structured Threat Information eXpression）'],answer:1,exp:'STIX は脅威アクター・攻撃キャンペーン・IoC などを構造化して記述するための標準形式です。TAXII プロトコルと組み合わせて組織間で自動共有されます。'},
|
||
{q:'ハニーポットを設置する主な目的はどれか。',choices:['本番システムの負荷を分散する','攻撃者を引き付けて行動を観察し脅威インテリジェンスを収集する'],answer:1,exp:'ハニーポットは重要システムを守る囮。攻撃者がどのような手法を使うかを安全に観察でき、TTPsの把握や早期警告システムとして機能します。'}
|
||
]
|
||
},
|
||
{ id:'s31', num:'S31', title:'コンプライアンス・証跡（ログ）入門', freq:'mid', diff:1,
|
||
concept:`<p><strong>コンプライアンス</strong>は、法令・業界ガイドライン・社内規程に沿って業務を運営することです。情報セキュリティ分野では、個人情報保護やISMSの文脈で「記録」「監査」「証跡」がセットで問われます。</p><div class="formula-box"><div class="formula-label">初学者向け：証跡とログ</div><strong>証跡</strong>：いつ・誰が・何をしたかを後から追跡できる記録。インシデント調査や監査で事実関係を説明する根拠になる。<br><strong>システムログ</strong>：ログイン成否、設定変更、特権操作などを機械的に残したもの。<br><strong>ログの保護</strong>：攻撃者に消されたら意味がないため、権限分離・改ざん検知・外部SIEMへの転送などで<strong>改ざん耐性</strong>を高める。</div><div class="formula-box"><div class="formula-label">内部統制との関係</div>重要な処理は<strong>職務分離</strong>や承認フローと組み合わせ、ログはその実行事実を残す。保存期間・閲覧権限・マスキングは個人情報保護と両立して設計する。</div><p>クラウドではログの有効化や保管先の設計も利用者責任に含まれる場合がある（責任共有モデル）。</p>`,
|
||
examtips:[
|
||
'「コンプライアンス＝法令遵守だけ」と捉えない。社内規程・契約・業界基準も含む。',
|
||
'監査証跡は「後から説明できること」が目的。ログを取らないより、取り方と保護が問われる。',
|
||
'クラウドの監査ログはデフォルトで無効のサービスもある。必要なイベントを有効化し、長期保管は別ストレージやSIEM連携を検討。'
|
||
],
|
||
keypoints:[
|
||
'コンプライアンス：法令・規程・契約に適合した運用',
|
||
'証跡・ログ：操作の事実を記録し調査・説明責任を果たす',
|
||
'ログ保護：権限分離と改ざん耐性（外部集約・WORM等）',
|
||
'内部統制：職務分離・承認とログを組み合わせて不正を抑止',
|
||
'クラウド：ログ設計・保管も利用者側の責任になり得る'
|
||
],
|
||
quiz:[
|
||
{q:'コンプライアンスの説明として最も適切なものはどれか。',choices:['利益だけを最大化すること','法令・規程・契約等に適合するよう業務を運営すること','セキュリティ対策を一切行わないこと','技術的脆弱性をゼロにすること'],answer:1,exp:'コンプライアンスは法令だけでなく、業界ガイドライン・社内規程・取引先契約など、組織が従うべきルール全体への適合を指します。'},
|
||
{q:'監査証跡（ログ）の主な目的として適切なものはどれか。',choices:['ディスク使用量を減らすこと','いつ誰が何をしたかを後から検証できるようにすること','パスワードを平文で保存すること','通信を暗号化しないこと'],answer:1,exp:'証跡はインシデント調査・監査・説明責任のために、操作の事実を追える状態にすることを目的とします。'},
|
||
{q:'ログの改ざん耐性を高める取り組みとして適切なものはどれか。',choices:['管理者が自由に削除できる1台のサーバのみに保存','権限分離し、改ざん検知や外部SIEMへの集約を行う','ログを取らない','全員に同一の管理者権限を付与'],answer:1,exp:'ログが攻撃者や内部不正で改ざん・削除されると証跡として機能しません。権限分離と外部集約が有効です。'},
|
||
{q:'クラウド利用におけるログ・監査の考え方として適切なものはどれか。',choices:['すべてのログはクラウド事業者が自動で完全に代替する','必要な監査ログを有効化し、保管期間とアクセス権を設計するのは利用者責任になり得る','ログは個人情報ではないので無制限に公開してよい','ログは開発環境のみでよい'],answer:1,exp:'責任共有モデルでは、設定可能な監査ログの有効化や保管設計が利用者側の責任になる場合があります。'}
|
||
]
|
||
}
|
||
]}
|
||
];
|