From 10071901e12790436f89f6f8bca55fe98397e635 Mon Sep 17 00:00:00 2001 From: posimai Date: Mon, 20 Apr 2026 13:08:49 +0900 Subject: [PATCH] feat(posimai-sc): S31 compliance intro, beginner glossaries, S16 Q4, SW v2; dashboard timeline and projects Made-with: Cursor --- posimai-sc/index.html | 2 +- posimai-sc/js/data/categories.js | 38 +++++++++++++++++++++++++------- posimai-sc/js/data/drills.js | 6 +++++ posimai-sc/sw.js | 2 +- 4 files changed, 38 insertions(+), 10 deletions(-) diff --git a/posimai-sc/index.html b/posimai-sc/index.html index e7f90451..cb6f43f4 100644 --- a/posimai-sc/index.html +++ b/posimai-sc/index.html @@ -412,7 +412,7 @@ header{display:flex;align-items:center;justify-content:space-between;padding:0 1

情報処理安全確保支援士

-

セキュリティの基礎から攻撃手法・法規まで、AM2試験に対応した30単元を体系的に学習します。開発者の視点から「なぜそうなのか」を理解しましょう。

+

セキュリティの基礎から攻撃手法・法規まで、AM2試験に対応した31単元を体系的に学習します。開発者の視点から「なぜそうなのか」を理解しましょう。

diff --git a/posimai-sc/js/data/categories.js b/posimai-sc/js/data/categories.js index f0384112..e71206c2 100644 --- a/posimai-sc/js/data/categories.js +++ b/posimai-sc/js/data/categories.js @@ -1,7 +1,7 @@ export const CATEGORIES = [ { id:'basics', label:'セキュリティ基礎', icon:'shield', units:[ { id:'s01', num:'S01', title:'CIA三要素', freq:'high', diff:1, - concept:`

情報セキュリティの根幹はCIA三要素です。すべてのセキュリティ対策はこのどれかを守るために存在します。

機密性
Confidentiality
許可された人だけが情報にアクセスできる。暗号化・アクセス制御で実現。
完全性
Integrity
情報が正確で改ざんされていない。ハッシュ・デジタル署名で検証。
可用性
Availability
必要なときに情報を使える。冗長化・バックアップで確保。

開発者視点で言い換えると：機密性は「見せない」、完全性は「改ざんさせない」、可用性は「止めない」です。DoS攻撃は可用性を、SQLインジェクションは機密性・完全性を脅かします。

`, + concept:`

情報セキュリティの根幹はCIA三要素です。すべてのセキュリティ対策はこのどれかを守るために存在します。

初学者向け：用語のイメージ
機密性：秘密にしたい内容を、許可のない人に見られないようにすること。
完全性：データが途中で改ざんされていないかを確認できること。
可用性：サービスやファイルを、必要なときにいつでも使える状態に保つこと。
機密性
Confidentiality
許可された人だけが情報にアクセスできる。暗号化・アクセス制御で実現。
完全性
Integrity
情報が正確で改ざんされていない。ハッシュ・デジタル署名で検証。
可用性
Availability
必要なときに情報を使える。冗長化・バックアップで確保。

開発者視点で言い換えると：機密性は「見せない」、完全性は「改ざんさせない」、可用性は「止めない」です。DoS攻撃は可用性を、SQLインジェクションは機密性・完全性を脅かします。

`, examtips:[ '三要素のどれが損なわれているかを問う問題が頻出。攻撃とCIA要素のマッピングを整理すること。', '真正性（Authenticity）・信頼性（Reliability）・否認防止（Non-repudiation）など追加要素も出題される。CIAだけが全てではない。', @@ -22,7 +22,7 @@ export const CATEGORIES = [ ] }, { id:'s02', num:'S02', title:'脅威・脆弱性・リスク', freq:'high', diff:1, - concept:`

リスク管理の基礎概念を整理します。脅威は攻撃者や災害など「悪いことが起きる原因」、脆弱性はシステムや運用の「穴」、リスクはそれらが組み合わさって「実際に被害が発生する可能性と影響度」です。

リスクの計算（概念式）
リスク = 脅威 × 脆弱性 × 資産価値

リスク対応の4戦略：
・回避（リスクが生じる活動をやめる）
・低減（対策を実施して確率・影響を下げる）
・移転（保険・外部委託でリスクを移す）
・受容（コスト対効果で許容する）

開発者にとって「脆弱性」とはバグや設定ミスのこと。CVEデータベースに登録される脆弱性情報は、脅威アクターが攻撃に利用する前にパッチを当てるために使います。

`, + concept:`

リスク管理の基礎概念を整理します。脅威は攻撃者や災害など「悪いことが起きる原因」、脆弱性はシステムや運用の「穴」、リスクはそれらが組み合わさって「実際に被害が発生する可能性と影響度」です。

初学者向け：3語の違い
脅威：被害をもたらし得る「原因側」（マルウェア、災害、内部不正など）。
脆弱性：攻撃や事故に利用されやすい「弱点」（未パッチ、弱いパスワード設定など）。
リスク：脅威が脆弱性を突いたときに、どれだけ損失が起きうるかという見込み。
リスクの計算（概念式）
リスク = 脅威 × 脆弱性 × 資産価値

リスク対応の4戦略：
・回避（リスクが生じる活動をやめる）
・低減（対策を実施して確率・影響を下げる）
・移転（保険・外部委託でリスクを移す）
・受容（コスト対効果で許容する）

開発者にとって「脆弱性」とはバグや設定ミスのこと。CVEデータベースに登録される脆弱性情報は、脅威アクターが攻撃に利用する前にパッチを当てるために使います。

`, examtips:[ '脅威・脆弱性・リスクの定義の違いを問う問題は毎回出る。「脆弱性」は弱点であり攻撃そのものではない。', 'リスク対応4戦略（回避・低減・移転・受容）の具体例を各1つ言えるようにする。', @@ -43,7 +43,7 @@ export const CATEGORIES = [ ] }, { id:'s03', num:'S03', title:'認証技術', freq:'high', diff:2, - concept:`

認証は「あなたが本当にあなたか」を確認するプロセスです。認証要素は3種類あり、複数組み合わせることで強度が上がります。

認証の3要素
知識要素（Something you know）：パスワード・PIN・秘密の質問
所持要素（Something you have）：ICカード・スマートフォン・ハードウェアトークン
生体要素（Something you are）：指紋・顔認証・虹彩

2要素以上を組み合わせるのが多要素認証（MFA）。SSOはIDPが認証を一元管理し、アプリはそのトークンを信頼するモデルです。開発者にとってJWT（JSON Web Token）はSSO文脈でよく使うものです。

ユーザー
ID/PW入力
→
IdP
認証・発行
→
トークン
JWT/SAML
→
サービス
検証・許可
`, + concept:`

認証は「あなたが本当にあなたか」を確認するプロセスです。認証要素は3種類あり、複数組み合わせることで強度が上がります。

初学者向け：よく出る言葉
認証（Authentication）：利用者が本人かどうかを確認すること（ログイン）。
認可（Authorization）：本人でも「どのデータや操作を許すか」を決めること（権限）。
多要素認証（MFA）：知識・所持・生体など種類の異なる要素を2つ以上使うこと（同じ種類を2回は多要素にならない場合がある）。
認証の3要素
知識要素（Something you know）：パスワード・PIN・秘密の質問
所持要素（Something you have）：ICカード・スマートフォン・ハードウェアトークン
生体要素（Something you are）：指紋・顔認証・虹彩

2要素以上を組み合わせるのが多要素認証（MFA）。SSOはIDPが認証を一元管理し、アプリはそのトークンを信頼するモデルです。開発者にとってJWT（JSON Web Token）はSSO文脈でよく使うものです。

ユーザー
ID/PW入力
→
IdP
認証・発行
→
トークン
JWT/SAML
→
サービス
検証・許可
`, examtips:[ '「2段階認証」は同一要素を2回使う場合もある（PW+秘密の質問→どちらも知識要素）。多要素認証は異なる要素を組み合わせる点が重要。', 'チャレンジレスポンス認証：サーバがランダム値（チャレンジ）を送り、クライアントがハッシュ等で応答（レスポンス）する。パスワードを平文で送らない。', @@ -64,7 +64,7 @@ export const CATEGORIES = [ ] }, { id:'s04', num:'S04', title:'アクセス制御', freq:'high', diff:2, - concept:`

アクセス制御は「誰が何にどう操作できるか」を管理する仕組みです。3つのモデルが試験に頻出です。

主なアクセス制御モデル
DAC（任意アクセス制御）：所有者が権限を設定（Linuxのchmod等）
MAC（強制アクセス制御）：システムがラベルで強制（機密文書管理）
RBAC（役割ベース制御）：役割に権限を付与（多くのWebアプリで採用）

最小権限の原則（Least Privilege）：業務に必要な最小限の権限のみ与える。開発者でいえばEC2に付けるIAM RoleはReadOnlyで十分な場合にAdminを付けないことです。

Need-to-know：業務上知る必要がある情報だけに絞るデータ分離の原則。MACと組み合わせることが多い。

`, + concept:`

アクセス制御は「誰が何にどう操作できるか」を管理する仕組みです。3つのモデルが試験に頻出です。

初学者向け：この単元の入口
アクセス制御：ユーザーやプロセスが、どのリソース（ファイル・DB・機能）をどこまで使えるかを決める仕組み。
最小権限：業務に必要な範囲だけ権限を付け、余計な操作や閲覧をさせない原則。
職務分離：申請・承認・実行などを別の人に分け、一人で不正を完結できないようにすること。
主なアクセス制御モデル
DAC（任意アクセス制御）：所有者が権限を設定（Linuxのchmod等）
MAC（強制アクセス制御）：システムがラベルで強制（機密文書管理）
RBAC（役割ベース制御）：役割に権限を付与（多くのWebアプリで採用）

最小権限の原則（Least Privilege）：業務に必要な最小限の権限のみ与える。開発者でいえばEC2に付けるIAM RoleはReadOnlyで十分な場合にAdminを付けないことです。

Need-to-know：業務上知る必要がある情報だけに絞るデータ分離の原則。MACと組み合わせることが多い。

`, examtips:[ 'DAC・MAC・RBACの違いを具体例で説明できること。試験では「誰が権限を設定するか」がポイント。', '最小権限の原則は選択問題の正答選択肢になることが多い。「できるだけ多くの権限を与える」は誤答。', @@ -85,7 +85,7 @@ export const CATEGORIES = [ ] }, { id:'s05', num:'S05', title:'ISMS・セキュリティマネジメント', freq:'mid', diff:2, - concept:`

ISMS（Information Security Management System）はJIS Q 27001をベースにした、組織全体で情報セキュリティを継続的に改善する仕組みです。

PDCAサイクル（ISMS）
P（計画）：リスクアセスメント→セキュリティポリシー策定
D（実行）：管理策の実施・社員教育
C（確認）：内部監査・マネジメントレビュー
A（改善）：不適合の是正・継続的改善

ISMSの認証取得はISO/IEC 27001に基づきます。プライバシーマーク（PMS）は個人情報保護に特化した日本独自の認証制度です。ゼロトラストアーキテクチャは「境界の内側も信頼しない」という現代的なセキュリティ思想で、ISMSの文脈でも登場します。

`, + concept:`

ISMS（Information Security Management System）はJIS Q 27001をベースにした、組織全体で情報セキュリティを継続的に改善する仕組みです。

初学者向け：ISMS とゼロトラスト
ISMS：方針を決め、リスクを評価し、規程・教育・点検・改善を続ける「組織のセキュリティの仕組み」そのもの。
PDCA：Plan（計画）→Do（実行）→Check（評価）→Act（改善）の繰り返しでレベルを上げる考え方。
ゼロトラスト：社内ネットワークにいるから安全、とはせず、内外を問わず毎回アクセスを検証する設計思想。
PDCAサイクル（ISMS）
P（計画）：リスクアセスメント→セキュリティポリシー策定
D（実行）：管理策の実施・社員教育
C（確認）：内部監査・マネジメントレビュー
A（改善）：不適合の是正・継続的改善

ISMSの認証取得はISO/IEC 27001に基づきます。プライバシーマーク（PMS）は個人情報保護に特化した日本独自の認証制度です。ゼロトラストアーキテクチャは「境界の内側も信頼しない」という現代的なセキュリティ思想で、ISMSの文脈でも登場します。

`, examtips:[ 'ISMSはJIS Q 27001・ISO/IEC 27001が根拠。プライバシーマークとの違い（対象範囲・認定機関）を整理。', 'PDCAのどのフェーズの話かを問う問題が多い。「内部監査」はC（確認）、「リスクアセスメント」はP（計画）。', @@ -107,7 +107,7 @@ export const CATEGORIES = [ ]}, { id:'crypto', label:'暗号・PKI', icon:'key', units:[ { id:'s06', num:'S06', title:'共通鍵暗号', freq:'high', diff:2, - concept:`

共通鍵暗号（対称暗号）は送受信者が同じ鍵を使って暗号化・復号する方式です。速度が速く大量データの暗号化に向いています。

主要アルゴリズム
AES（Advanced Encryption Standard）：現在の標準。128/192/256ビット鍵。ブロック暗号
DES：56ビット鍵。現在は脆弱で使用禁止
3DES：DESを3回適用。AESへ移行中
ChaCha20：ストリーム暗号。モバイル・TLS1.3で採用

鍵配送問題：共通鍵を安全に相手に渡す手段が必要。これを解決したのが公開鍵暗号とDiffie-Hellman鍵交換です。TLSハンドシェイクではDH（ECDH）で共通鍵を合意し、AESで通信を暗号化するという組み合わせが標準です。

`, + concept:`

共通鍵暗号（対称暗号）は送受信者が同じ鍵を使って暗号化・復号する方式です。速度が速く大量データの暗号化に向いています。

初学者向け：暗号の役割（あとで詳しく）
この単元の共通鍵は「同じ秘密の鍵で暗号化・復号する」方式です。次の単元の公開鍵とセットで「誰でも送れるが本人だけ読める」「本人だけが署名できる」など別の役割を担います。ハッシュ（別単元）は「要約フィンガープリント」で改ざん検知に使います。
主要アルゴリズム
AES（Advanced Encryption Standard）：現在の標準。128/192/256ビット鍵。ブロック暗号
DES：56ビット鍵。現在は脆弱で使用禁止
3DES：DESを3回適用。AESへ移行中
ChaCha20：ストリーム暗号。モバイル・TLS1.3で採用

鍵配送問題：共通鍵を安全に相手に渡す手段が必要。これを解決したのが公開鍵暗号とDiffie-Hellman鍵交換です。TLSハンドシェイクではDH（ECDH）で共通鍵を合意し、AESで通信を暗号化するという組み合わせが標準です。

`, examtips:[ 'AES・DES・3DESのビット長と現在の安全性を整理する。DESは2024年現在使用禁止。', 'n人で共通鍵を持ち合う場合の鍵の数：n(n-1)/2本。公開鍵暗号ならn本で済む。この違いが問われる。', @@ -357,7 +357,8 @@ export const CATEGORIES = [ quiz:[ {q:'他のサービスで漏洩したID・パスワードのリストを使って別サービスにログインを試みる攻撃はどれか。',choices:['パスワードスプレー攻撃','ブルートフォース攻撃','クレデンシャルスタッフィング','辞書攻撃'],answer:2,exp:'クレデンシャルスタッフィングはパスワードの使い回しを悪用して漏洩リストを他サービスに転用する攻撃です。'}, {q:'アカウントロックアウト機能を回避しながらパスワードを試みる攻撃手法はどれか。',choices:['ブルートフォース攻撃','パスワードスプレー攻撃','レインボーテーブル攻撃','クレデンシャルスタッフィング'],answer:1,exp:'パスワードスプレーは少数の一般的なパスワードを多数のアカウントに分散して試すため、ロックアウト閾値を超えません。'}, - {q:'スピアフィッシングの説明として正しいものはどれか。',choices:['不特定多数に大量配信するフィッシング','特定の個人・組織を調査した標的型フィッシング','電話を使ったソーシャルエンジニアリング','SMSを使ったフィッシング'],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, @@ -510,7 +511,7 @@ 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 CSF 2.0（2024年2月）：Govern（統治）を追加した6機能（G-IPDRR）
　Govern→Identify→Protect→Detect→Respond→Recover
NIST SP 800シリーズ：米国のセキュリティガイドライン群
PCI DSS：クレジットカード業界のセキュリティ基準。12要件で構成
`, + concept:`

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

主な法律・制度
不正アクセス禁止法：不正アクセス行為そのものを禁止（クラッキング・フィッシング等）
個人情報保護法：個人情報の取得・利用・保管・第三者提供の規制。漏洩時の報告義務
サイバーセキュリティ基本法：国のサイバーセキュリティ戦略の基盤。NISC設置の根拠法
不正競争防止法：営業秘密の保護。漏洩・横領に刑事罰
電子署名法：電子署名の法的効力を定める
評価基準・フレームワーク
ISO/IEC 15408（CC：Common Criteria）：製品のセキュリティ評価基準。EALレベルで評価
PCI DSS：クレジットカード業界のセキュリティ基準（加盟店・決済事業者向け、12要件で構成）
NIST SP 800シリーズ：米国のセキュリティガイドライン群
NIST CSF 2.0（2024年2月）：Govern（統治）を追加した6機能（G-IPDRR）
　Govern→Identify→Protect→Detect→Respond→Recover
ISO/IEC 27001：ISMS の国際規格（Annex A に管理策を列挙）
`, examtips:[ '不正アクセス禁止法：権限なしのコンピュータへの不正ログインを禁止。ポートスキャンだけでは違反にならないが、脆弱性を突いた侵入は違反。', '個人情報保護法：令和4年（2022年）施行で漏洩報告義務化・個人関連情報追加。令和8年（2026年）4月改正法案で課徴金制度が新設予定（違法利得への制裁強化）。', @@ -637,6 +638,27 @@ export const CATEGORIES = [ {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:`

コンプライアンスは、法令・業界ガイドライン・社内規程に沿って業務を運営することです。情報セキュリティ分野では、個人情報保護やISMSの文脈で「記録」「監査」「証跡」がセットで問われます。

初学者向け：証跡とログ
証跡：いつ・誰が・何をしたかを後から追跡できる記録。インシデント調査や監査で事実関係を説明する根拠になる。
システムログ：ログイン成否、設定変更、特権操作などを機械的に残したもの。
ログの保護：攻撃者に消されたら意味がないため、権限分離・改ざん検知・外部SIEMへの転送などで改ざん耐性を高める。
内部統制との関係
重要な処理は職務分離や承認フローと組み合わせ、ログはその実行事実を残す。保存期間・閲覧権限・マスキングは個人情報保護と両立して設計する。

クラウドではログの有効化や保管先の設計も利用者責任に含まれる場合がある（責任共有モデル）。

`, + 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:'責任共有モデルでは、設定可能な監査ログの有効化や保管設計が利用者側の責任になる場合があります。'} + ] } ]} ]; diff --git a/posimai-sc/js/data/drills.js b/posimai-sc/js/data/drills.js index c5ffa731..1a598e2f 100644 --- a/posimai-sc/js/data/drills.js +++ b/posimai-sc/js/data/drills.js @@ -183,5 +183,11 @@ export const DRILLS = { { 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: 'ハニーポットは重要システムを守る囮。攻撃者の TTP を安全に観察でき、早期警告システムとしても機能します。' } + ], + s31: [ + { q: 'コンプライアンスの意味に最も近いのはどれか。', choices: ['法令・規程に適合した運用をすること', '脆弱性スキャンを週1回だけ行うこと'], answer: 0, exp: 'コンプライアンスは法令・業界ルール・社内規程・契約など、従うべき要件への適合を指します。' }, + { q: '監査証跡（ログ）の主な目的はどれか。', choices: ['ストレージコストを下げること', 'いつ誰が何をしたかを後から検証できるようにすること'], answer: 1, exp: '証跡は説明責任・調査・監査のために、操作の事実を追える記録を残すことが目的です。' }, + { q: 'ログの保護で重視すべきことはどれか。', choices: ['全員が同じ管理者で削除できること', '権限分離と改ざん検知・外部集約などで改ざん耐性を高めること'], answer: 1, exp: 'ログが改ざん・削除されると証跡として機能しません。権限分離と外部SIEM等が有効です。' }, + { q: 'クラウド利用時の監査ログの考え方として適切なのはどれか。', choices: ['必要なイベントの有効化や保管設計は利用者責任になり得る', 'すべてクラウド事業者が自動で完備する'], answer: 0, exp: '責任共有モデルでは、監査ログの有効化や保持ポリシーが利用者側の作業になる場合があります。' } ] }; \ No newline at end of file diff --git a/posimai-sc/sw.js b/posimai-sc/sw.js index 632728b0..09543f60 100644 --- a/posimai-sc/sw.js +++ b/posimai-sc/sw.js @@ -1,5 +1,5 @@ // posimai-sc SW — same-origin の静的資産のみキャッシュ（CDN は対象外） -const CACHE = 'posimai-sc-v1'; +const CACHE = 'posimai-sc-v2'; const STATIC = [ '/', '/index.html',