diff --git a/posimai-sc/js/data/categories.js b/posimai-sc/js/data/categories.js old mode 100644 new mode 100755 index a0f92442..6de4624d --- a/posimai-sc/js/data/categories.js +++ b/posimai-sc/js/data/categories.js @@ -132,14 +132,16 @@ export const CATEGORIES = [ examtips:[ '暗号化と署名で使う鍵の向きが逆なことを確実に理解する。暗号化は「受信者の公開鍵」、署名は「送信者の秘密鍵」。', 'RSAの最低鍵長は2048ビット（2024年現在）。1024ビットは脆弱で不推奨。', - 'デジタル署名≠暗号化。署名は「本人確認・改ざん検知」が目的。機密性（内容を隠す）は公開鍵暗号化が担う。' + 'デジタル署名≠暗号化。署名は「本人確認・改ざん検知」が目的。機密性（内容を隠す）は公開鍵暗号化が担う。', + '耐量子暗号（PQC）：量子コンピュータは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に使う' + 'DH/ECDH：鍵を共有するプロトコル。TLSのforward secrecyに使う', + '耐量子暗号（PQC）：ML-KEM・ML-DSA・SLH-DSA がNIST標準（2024年8月）。RSA/ECCの後継候補' ], quiz:[ {q:'デジタル署名を生成する際に使用する鍵はどれか。',choices:['受信者の公開鍵','送信者の公開鍵','受信者の秘密鍵','送信者の秘密鍵'],answer:3,exp:'署名は「送信者の秘密鍵」で生成し、受信者は「送信者の公開鍵」で検証します。'}, @@ -401,24 +403,67 @@ export const CATEGORIES = [ ] }, { id:'s20', num:'S20', title:'法規・評価基準', freq:'high', diff:2, - concept:`

情報セキュリティに関わる法律・制度・評価基準を整理します。試験では法律の名前と対象・罰則の組み合わせが問われます。

主な法律・制度
不正アクセス禁止法：不正アクセス行為そのものを禁止（クラッキング・フィッシング等）
個人情報保護法：個人情報の取得・利用・保管・第三者提供の規制。漏洩時の報告義務
サイバーセキュリティ基本法：国のサイバーセキュリティ戦略の基盤。NISC設置の根拠法
不正競争防止法：営業秘密の保護。漏洩・横領に刑事罰
電子署名法：電子署名の法的効力を定める
評価基準・フレームワーク
ISO/IEC 15408（CC：Common Criteria）：製品のセキュリティ評価基準。EALレベルで評価
PCI DSS：クレジットカード業界のセキュリティ基準（加盟店・決済事業者向け）
NIST SP 800シリーズ：米国のセキュリティガイドライン群
NIST Cybersecurity Framework（CSF）：識別・防御・検知・対応・回復の5機能
`, + concept:`

情報セキュリティに関わる法律・制度・評価基準を整理します。試験では法律の名前と対象・罰則の組み合わせが問われます。

主な法律・制度
不正アクセス禁止法：不正アクセス行為そのものを禁止（クラッキング・フィッシング等）
個人情報保護法：個人情報の取得・利用・保管・第三者提供の規制。漏洩時の報告義務
サイバーセキュリティ基本法：国のサイバーセキュリティ戦略の基盤。NISC設置の根拠法
不正競争防止法：営業秘密の保護。漏洩・横領に刑事罰
電子署名法：電子署名の法的効力を定める
評価基準・フレームワーク
ISO/IEC 15408（CC：Common Criteria）：製品のセキュリティ評価基準。EALレベルで評価
PCI DSS：クレジットカード業界のセキュリティ基準（加盟店・決済事業者向け）
NIST SP 800シリーズ：米国のセキュリティガイドライン群
NIST CSF 2.0（2024年2月）：Govern（統治）を追加した6機能（G-IPDRR）
　Govern→Identify→Protect→Detect→Respond→Recover
NIST SP 800シリーズ：米国のセキュリティガイドライン群
PCI DSS：クレジットカード業界のセキュリティ基準。12要件で構成
`, examtips:[ - '不正アクセス禁止法：アクセス権限のないコンピュータへの不正ログインを禁止。ポートスキャンだけでは違反にならないが、脆弱性を突いた侵入は違反。', - '個人情報保護法改正（2022年〜）：漏洩報告の義務化（個人に報告義務あり）・越境移転の規制強化・クッキー等の「個人関連情報」が追加。', - 'NIST CSFの5機能：Identify（識別）→Protect（防護）→Detect（検知）→Respond（対応）→Recover（回復）。頭文字IPDRRで覚える。' + '不正アクセス禁止法：権限なしのコンピュータへの不正ログインを禁止。ポートスキャンだけでは違反にならないが、脆弱性を突いた侵入は違反。', + '個人情報保護法：令和4年（2022年）施行で漏洩報告義務化・個人関連情報追加。令和8年（2026年）4月改正法案で課徴金制度が新設予定（違法利得への制裁強化）。', + 'NIST CSF 2.0（2024年2月）は6機能：旧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のレベル', - 'PCI DSS：カード決済のセキュリティ基準。12要件で構成', - 'NIST CSF：識別・防護・検知・対応・回復（IPDRR）の5機能フレームワーク' + '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:'NIST Cybersecurity Framework（CSF）の5機能として正しい組み合わせはどれか。',choices:['計画・実行・確認・改善・廃棄','識別・防護・検知・対応・回復','認証・暗号・監視・対応・復旧','設計・構築・テスト・展開・監視'],answer:1,exp:'NIST CSFはIdentify・Protect・Detect・Respond・Recover（IPDRR）の5機能で構成されます。'}, - {q:'ISO/IEC 15408（CC：Common Criteria）の用途はどれか。',choices:['組織のISMS認証','IT製品・システムのセキュリティ機能の評価・認証','個人情報の保護規制','クレジットカードの安全基準'],answer:1,exp:'Common Criteriaは情報技術製品のセキュリティ機能をEAL（Evaluation Assurance Level）1〜7で評価・認証する国際規格です。'} + {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:`

クラウドサービスは利用形態（IaaS/PaaS/SaaS）によって、提供者とユーザーのセキュリティ責任範囲が異なります。これを責任共有モデル（Shared Responsibility Model）と呼びます。

責任共有モデルの例（IaaS）
クラウド事業者の責任：物理インフラ・ハイパーバイザ・ネットワーク
ユーザーの責任：OS・ミドルウェア・アプリ・データ・IAM・暗号化設定

SaaS に近づくほどユーザーの責任は減るが、IAMとデータの責任は常にユーザー側

クラウド特有のセキュリティリスクとして設定ミスが最多。S3バケット公開設定やルートアカウントのMFA無効化などが典型例です。

主なクラウドセキュリティ技術
CASB（Cloud Access Security Broker）：クラウドサービスへのアクセスを可視化・制御する中間プロキシ
CSPM（Cloud Security Posture Management）：クラウド設定のセキュリティポリシー準拠を継続的に検証
SWG（Secure Web Gateway）：Webアクセスをフィルタリング。ゼロトラストで境界の代替
CWPP（Cloud Workload Protection Platform）：クラウド上のワークロードを保護
`, + 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:`

現代のWebサービスでIDを連携させる3つのプロトコルを整理します。OAuth 2.0は「認可（Authorization）」、OIDCは「認証（Authentication）」、SAMLはエンタープライズの「フェデレーション認証」です。

3プロトコルの役割
OAuth 2.0：リソースへのアクセス権を第三者に委譲する認可フレームワーク
　→「Googleドライブに○○アプリのアクセスを許可する」はOAuth 2.0
OIDC（OpenID Connect）：OAuth 2.0の上に認証レイヤーを追加
　→「Googleアカウントで△△にログイン」はOIDC
SAML 2.0：XMLベースのSSO標準。企業向け（IdP/SPの概念の基盤）
ユーザー
ブラウザ
→
IdP
認可/認証
→
トークン
JWT/SAML
→
SP/RP
検証・許可

JWTはHeader.Payload.Signatureの3部構成。Payloadにsub（ユーザーID）やexp（有効期限）などのクレームを格納します。IDaaSはこれらを統合したSaaS型のID管理サービスです（Azure AD/Okta等）。

`, + 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・モバイルアプリ向けです。'} ] } ]} diff --git a/posimai-sc/js/data/drills.js b/posimai-sc/js/data/drills.js old mode 100644 new mode 100755 index 80794bdd..879f7033 --- a/posimai-sc/js/data/drills.js +++ b/posimai-sc/js/data/drills.js @@ -80,6 +80,14 @@ export const DRILLS = { ], s20: [ { q: '権限なく他人の ID でコンピュータにアクセスすることを禁止する法律は。', choices: ['個人情報保護法', '不正アクセス禁止法'], answer: 1, exp: '不正アクセス行為の禁止が中心です。' }, - { q: 'NIST CSF の 5 機能に「防護」に相当する英語は。', choices: ['Detect', 'Protect'], answer: 1, exp: 'Identify / Protect / Detect / Respond / Recover が 5 機能です。' } + { q: '2024年公開の NIST CSF 2.0 で新設された機能は。', choices: ['Recover（回復）', 'Govern（統治）'], answer: 1, exp: 'CSF 2.0 では Govern が追加され、5 機能から 6 機能（G-IPDRR）になりました。' } + ], + s21: [ + { q: 'クラウドの責任共有モデルでサービス形態に関わらず常にユーザー責任となるのは。', choices: ['物理インフラ', 'IAM とデータの保護'], answer: 1, exp: 'IAM とデータは IaaS/PaaS/SaaS いずれでもユーザーが責任を持ちます。' }, + { q: 'シャドー IT（未承認クラウド利用）の可視化と制御を担うのは。', choices: ['CSPM', 'CASB'], answer: 1, exp: 'CASB はユーザーとクラウドの間に立ちアクセスを監視・制御します。' } + ], + s22: [ + { q: '「Google アカウントでログイン」を実現するプロトコルは。', choices: ['OAuth 2.0 のみ', 'OIDC（OpenID Connect）'], answer: 1, exp: 'OIDC は OAuth 2.0 に認証（誰か）レイヤーを追加したプロトコルです。' }, + { q: 'JWT の構造として正しいものは。', choices: ['暗号化された単一 Blob', 'Header.Payload.Signature の 3 部構成'], answer: 1, exp: 'JWT は 3 部をドット区切りで連結。Signature で完全性を保証します。' } ] };