SG NotebookLM Export

⭐ まず読む3記事

ポート番号とは？通信先サービスの識別を理解する【情報セキュリティマネジメント】

Source: pages\sg\port-number.md
Permalink: /sg/port-number/

まず結論

ポート番号とは、同じ機器内でどのサービス（アプリケーション）に通信を届けるかを識別する番号であり、SG試験では「通信の宛先の中身をどう区別するか」を問われる。

直感的な説明

IPアドレスが「建物の住所」だとすると、ポート番号は「部屋番号」です。

IPアドレス → どの機器か
ポート番号 → その機器のどのサービスか

例えば同じサーバでも、

Webサイトを見る → 80番（HTTP）
安全なWeb通信 → 443番（HTTPS）
メール送信 → 25番

のように、同じ住所でも行き先の部屋が違うイメージです。

定義・仕組み

ポート番号は、TCP/IP通信において、通信を受け取るプログラム（サービス）を識別するための番号です。

基本の仕組みは以下の通りです。

送信元が「IPアドレス＋ポート番号」を指定して通信を送る
受信側の機器に届く（IPアドレスで到達）
その機器の中で、ポート番号を見て該当サービスに渡す

主なポート番号の例：

80：HTTP（Web）
443：HTTPS（安全なWeb）
22：SSH（リモート操作）

SG試験では、「ポート番号＝通信内容ではなく通信先のサービス識別」と理解しておくことが重要です。

どんな場面で使う？

① 通信の制御（ファイアウォール）

「80番だけ許可」「22番は禁止」など
→ ポート番号単位で通信を制御する

② 不正アクセス対策

不要なポートを閉じる（ポート閉塞）
→ 攻撃対象を減らす

③ サーバ運用

Webサーバやメールサーバを適切なポートで公開する

SG試験では、
「どのポートを開けるべきか／閉じるべきか」という運用判断でよく出ます。

よくある誤解・混同

❌ 物理的な接続口（LANポートなど）

→ ⭕ ポート番号は論理的な番号（ソフトウェア上）

❌ プロトコルそのものを識別する番号

→ ⭕ 正しくは「そのプロトコルを使うサービス（アプリ）」を識別

❌ データごとに自動で付く番号

→ ⭕ あらかじめ決められた番号（例：80, 443）を使う

SG試験では
「ポート番号＝サービスの識別」か「物理ポート」かを混同させてくる問題が頻出です。

選択肢では
「ケーブル」「接続端子」と書かれていたら誤りと判断できます。

まとめ（試験直前用）

ポート番号＝同一機器内のサービス識別番号
IPアドレス＝機器、ポート番号＝サービス
ファイアウォールはポート単位で制御する
「物理ポート」との混同が典型的なひっかけ
「どの通信を許可・遮断するか」の判断問題でよく出る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

DHCPとは？IPアドレスを自動で割り当てる仕組み【情報セキュリティマネジメント】

Source: pages\sg\dhcp.md
Permalink: /sg/dhcp/

まず結論

DHCPは、ネットワークに接続した機器に対してIPアドレスを自動的に割り当てる仕組みであり、SG試験では「どの役割の仕組みか」を見極める問題としてよく出ます。

直感的な説明

Wi-Fiにつなぐと、スマホやPCがすぐにインターネットを使えるようになりますよね。

これは裏で
👉「あなたはこのIPアドレスを使ってください」
と自動で割り当てられているからです。

もしDHCPがなければ、

IPアドレス
サブネットマスク
デフォルトゲートウェイ

を全部手入力する必要があります。

つまりDHCPは
👉「ネットワーク接続の初期設定を自動化してくれる仕組み」
です。

定義・仕組み

DHCP（Dynamic Host Configuration Protocol）は、ネットワークに接続する端末に対して、IPアドレスなどの設定情報を自動配布するプロトコルです。

基本の流れはシンプルです。

端末が「IPください」と要求（DHCP Discover）
サーバが「このIP使っていいよ」と提案（Offer）
端末が「それ使います」と返答（Request）
サーバが「OK」と確定（ACK）

この仕組みによって、

IPアドレスの重複防止
設定ミスの削減
管理の効率化

が実現されます。

SG試験では「自動設定」「IP配布」というキーワードが重要です。

どんな場面で使う？

使う場面

社内ネットワークで多数のPCを管理するとき
Wi-Fi環境（家庭・オフィス・カフェなど）
一時的に接続される端末が多い環境

👉「手動設定が現実的でない環境」で使われる

使わない（または注意する）場面

サーバやネットワーク機器（固定IPが必要）
セキュリティ上、IPを固定管理したい場合

👉「重要機器は固定IP」が基本

よくある誤解・混同

SG試験ではここがよく狙われます。

❌ ドメイン名とIPの対応を管理する仕組み

→ これは DNS

❌ 異なるネットワーク間でIPアドレスを変換する仕組み

→ これは NAT

❌ IPアドレスとMACアドレスを対応付ける仕組み

→ これは ARP

ひっかけポイント

DHCP = 「IPを配る」
DNS = 「名前を解決する」
NAT = 「アドレスを変換する」
ARP = 「IPとMACを結びつける」

👉 SG試験では「役割の違い」で切ることが重要

まとめ（試験直前用）

DHCPは「IPアドレスを自動で割り当てる仕組み」
手動設定を不要にし、管理を効率化する
サーバや重要機器は固定IPにするのが基本
DHCPとDNS・NAT・ARPの違いは頻出
選択肢では「自動付与」かどうかで判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

クライアントサーバーシステムとは？役割分担の考え方を理解する【情報セキュリティマネジメント】

Source: pages\sg\client-server-system.md
Permalink: /sg/client-server-system/

まず結論

クライアントサーバーシステムとは、クライアントとサーバーが役割分担して処理を行う仕組みであり、SG試験では「どこで何を処理するか」を判断させる問題として出題されます。

直感的な説明

イメージとしては「レストラン」です。

クライアント：お客さん（注文する）
サーバー：厨房（料理を作る）

お客さんは全部の料理を自分で作るわけではなく、
厨房に依頼して結果（料理）を受け取りますよね。

ただし最近は、セルフサービスやタブレット注文のように
一部の処理はお客さん側でも行うことがあります。

👉 つまり
「全部サーバー」でも「全部クライアント」でもなく、分担するのがポイントです。

定義・仕組み

クライアントサーバーシステムは以下のような構成です。

クライアント（利用者側）
- 画面表示
- 入力処理
- 一部の計算処理
サーバー（提供側）
- データ管理
- 認証・アクセス制御
- 重要な処理

なぜ分けるのか？

目的は主にこの3つです。

処理の効率化（負荷分散）
セキュリティ確保（重要データはサーバーで管理）
管理の一元化

SG試験では
👉「重要な処理やデータはサーバーに置く」
という考え方がよく問われます。

どんな場面で使う？

使うべき場面

社内システム（勤怠管理・会計システム）
Webサービス（ログイン・データ保存）
業務アプリ全般

👉 特に
「データを安全に管理したいとき」に必須です。

使うと誤解しやすい場面

すべてサーバーで処理する（＝シンクライアント）
すべてクライアントで処理する（＝スタンドアロン）

これらはクライアントサーバーとは別の考え方です。

よくある誤解・混同

① シンクライアントとの違い

シンクライアント
→ クライアントはほぼ処理しない
クライアントサーバー
→ 両方が処理する（ここが正解ポイント）

👉 SG試験では
「クライアントは処理を行わない」と書かれていたら誤りです。

② 冗長化システムとの混同

「複数のシステムで信頼性向上」
→ これは冗長化（可用性の話）

👉 クライアントサーバーは
役割分担の話であり、信頼性の話ではない

③ スタンドアロンとの違い

スタンドアロン
→ 1台で完結
クライアントサーバー
→ 複数で役割分担

SG試験のひっかけポイント

「すべてサーバーで処理」→ ×（シンクライアント）
「すべてクライアントで処理」→ ×（スタンドアロン）
「両方で処理を分担」→ ○（正解）

👉 この3択を切れるようにするのが重要です。

まとめ（試験直前用）

クライアントとサーバーが役割分担して処理する仕組み
重要なデータ・処理はサーバー側で管理
SG試験では「どこで処理するか」を問われる
「全部サーバー」「全部クライアント」は誤り
正解は「両方が処理能力を持ち、使い分ける」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

📝 試験概要

情報セキュリティマネジメント試験とは？役割・対象者・試験の位置づけを整理

Source: pages\sg\information-security-management-exam.md
Permalink: /sg/information-security-management-exam/

まず結論

情報セキュリティマネジメント試験は、組織の情報セキュリティを守るために必要な、基本的な管理スキルを確認する国家試験です。

技術だけでなく、ルールの運用、業務フローの見直し、従業員の意識向上なども含めて、継続的に情報を守る力が求められます。

なぜ必要とされているのか

ITの活用が広がる一方で、サイバー攻撃や情報漏えいのリスクも大きくなっています。

情報セキュリティの問題は、単にシステムを導入すれば解決するものではありません。組織の中で適切に情報を管理し、ルールを守り、事故が起きたときに適切に対応できる体制づくりが重要です。

そのため、情報セキュリティを「技術面」だけでなく「管理面」から支える人材が必要とされています。

情報セキュリティマネジメント試験とは

IPAによると、この試験は情報セキュリティマネジメントの

計画
運用
評価
改善

を通じて、組織の情報セキュリティ確保に貢献するための基本的なスキルを認定する試験です。

位置づけとしては、共通キャリア・スキルフレームワーク（CCSF）レベル2相当とされています。

この試験で期待される役割

情報セキュリティマネジメント人材には、たとえば次のような役割が期待されます。

部門全体の情報セキュリティ意識を高める
情報漏えいのリスクを低減する
トラブル発生時に適切に対応して被害を最小限に抑える
安全なIT利活用を支える

つまり、現場で情報を扱う人が、日常業務の中でセキュリティを維持するための土台になる試験だと考えると分かりやすいです。

どんな人に向いているか

IPAでは、特に次のような人に受験を勧めています。

業務で個人情報を扱う人
業務部門や管理部門で情報管理を担当する人
外部委託先の情報セキュリティ評価や確認を行う人
情報セキュリティ管理の知識とスキルを身につけたい人
ITパスポート試験合格後に次のステップへ進みたい人

エンジニアだけでなく、総務、人事、経理、営業、企画など幅広い職種で役立つ点が特徴です。

試験実施の概要

IPAの案内では、情報セキュリティマネジメント試験は CBT（Computer Based Testing）方式で年間を通じて随時実施されています。

また、身体の不自由などによりCBT方式での受験が難しい場合には、筆記による特別措置試験も用意されています。

受験手数料は、2026年2月5日更新のIPAページでは 7,500円（税込） です。

まず最初に確認したい公式ページ

公式情報を最初に見てから学習を始めると、出題範囲と試験の目的をつかみやすくなります。

まとめ

情報セキュリティマネジメント試験は、情報セキュリティを現場で適切に運用し、継続的に守るための基本力を確認する試験です。

技術職だけでなく、情報を扱う多くの社会人に関係する内容なので、情報管理やセキュリティの基礎を体系的に学びたい人に向いています。

情報セキュリティマネジメント試験の出題内容とは？科目A・科目Bと勉強方法を整理

Source: pages\sg\sg-exam-outline-study.md
Permalink: /sg/sg-exam-outline-study/

まず結論

情報セキュリティマネジメント試験は、科目Aで基礎知識、科目Bで実務的な判断力を問う試験です。

勉強するときは、

まず科目Aの頻出知識を整理する
次に科目Bのケース問題に慣れる
最後に公開問題で時間配分を確認する

という流れにすると進めやすいです。

出題内容の全体像

IPAの「情報セキュリティマネジメント試験出題内容」では、科目Aと科目Bの内容が分けて示されています。

科目Aで問われること

科目Aでは、情報セキュリティの基礎知識に加えて、管理・対策・法規、さらに周辺のIT知識まで問われます。

重点分野

情報セキュリティ全般
- 機密性・完全性・可用性
- 脅威、脆弱性、サイバー攻撃手法
- 暗号、認証
情報セキュリティ管理
- 情報資産
- リスク
- ISMS
- インシデント管理
- CSIRT
情報セキュリティ対策
- マルウェア対策
- 不正アクセス対策
- 情報漏えい対策
- アクセス管理
- 情報セキュリティ啓発
情報セキュリティ関連法規
- サイバーセキュリティ基本法
- 個人情報保護法
- 不正アクセス禁止法

科目Bで問われること

科目Bでは、実際の業務現場を想定したケーススタディを通して、情報セキュリティ管理の実践力が問われます。

IPAでは、たとえば次のようなテーマが挙げられています。

情報資産管理
リスクアセスメント
IT利用における情報セキュリティ確保
委託先管理
情報セキュリティ教育・訓練

科目Aのように単語だけを覚えるのではなく、状況を読んで「何が適切か」を判断する力が必要です。

出題の特色

IPAの説明では、出題には次の特色があります。

1. 身近な事例をベースにした実践的な出題

内部不正の防止、標的型攻撃対策、クラウドサービスの安全利用、法改正への対応など、現場で起こりうるテーマが扱われます。

2. 国際・国内標準や公的ガイドラインに基づく出題

ISO/IEC 27000 規格群、JIS Q 27000 規格群、「組織における内部不正防止ガイドライン」などに基づく考え方が重視されます。

このため、用語の暗記だけではなく、「なぜその対策が必要なのか」を理解しておくことが重要です。

試験時間と形式

IPAの2023年3月31日公開の出題内容ページでは、次のように案内されています。

試験時間: 120分
出題形式: 科目Aは多肢選択式（四肢択一）、科目Bも多肢選択式
出題数/解答数: 60問/60問
合格基準: 総合評価点 1,000点満点中 600点以上

採点は IRT（項目応答理論）に基づいて行われます。

勉強方法

ここからは、IPAの出題内容、公開問題、通年試験案内をもとにした勉強の進め方です。

1. 最初に科目Aの重点分野を固める

最初は、次の分野を優先して整理すると進めやすいです。

CIA（機密性・完全性・可用性）
脅威、脆弱性、攻撃手法
暗号、認証、アクセス制御
ISMS、リスク管理、インシデント対応
個人情報保護法、不正アクセス禁止法などの法規

科目Bでも基礎知識が前提になるので、最初に土台を作っておくと後が楽になります。

2. 科目Bはケース問題として読む練習をする

科目Bは、知識問題というより「場面に応じた適切な判断」を問う問題です。

そのため、

誰が困っているのか
何がリスクなのか
どの管理策が妥当か
どこに改善余地があるか

を読み取る練習が重要です。

単語だけを覚えるより、業務シーンとセットで理解する方が得点につながりやすいです。

3. 公開問題で形式に慣れる

IPAは、CBT方式の情報セキュリティマネジメント試験について、令和5年度以降の公開問題（問題冊子・解答例）を掲載しています。

これを使うと、

実際の設問の聞かれ方
科目Aと科目Bの比重
読む量の感覚
時間配分

を確認できます。

特に本番が CBT 方式なので、知識の確認だけでなく、短時間で判断する感覚を身につけることが大切です。

4. 試験直前は「頻出論点の再確認」に絞る

直前期は新しい範囲を広げすぎず、次を見直すのが効率的です。

重要用語の定義
法規の違い
典型的なリスクと対策
ケース問題で迷いやすい論点

情報セキュリティの試験は、似た言葉の違いで迷いやすいので、「違い」で覚えると整理しやすくなります。

参考にした公式ページ

勉強方法の部分は、上記の公式情報から組み立てた学習方針です。

まとめ

情報セキュリティマネジメント試験は、科目Aで基礎知識を、科目Bで実務的な判断力を問う試験です。

勉強するときは、まず重点分野を押さえ、その後にケース問題と公開問題で仕上げる流れが進めやすいです。

情報セキュリティ全般

攻撃者の種類とは？目的と特徴で整理する【情報セキュリティマネジメント】

Source: pages\sg\attacker-types.md
Permalink: /sg/attacker-types/

まず結論

攻撃者の種類とは、「どんな目的・動機で攻撃するか」によって分類したものであり、SG試験では攻撃者の意図を見抜いて適切な対策を選べるかが問われます。

直感的な説明

攻撃者といっても、全員が同じ目的ではありません。

お金目的の人
技術力を試したい人
楽しみでやる人
思想的な主張をしたい人

👉 「誰が何のために攻撃しているか」で対策は変わる
これが理解できると、問題が一気に解きやすくなります。

定義・仕組み

代表的な攻撃者の種類を整理します。

スクリプトキディ（Script Kiddie）

他人が作ったツールを使うだけ
技術力は低いが数は多い
👉 無差別攻撃が多い

ハッカー（Hacker）

本来は「高い技術力を持つ人」という中立的な意味
善悪どちらにも使われる
👉 セキュリティ向上に貢献する場合もある

クラッカー（Cracker）

悪意を持って攻撃する人
不正侵入・情報窃取などを行う
👉 SG試験では「悪意の攻撃者」は基本これ

詐欺犯・故意犯

明確な目的（主に金銭）を持つ
フィッシングや不正送金など
👉 ビジネス被害に直結

愉快犯

目的は楽しみ・自己満足
Webサイト改ざんなど
👉 直接の金銭被害がなくても影響大

どんな場面で使う？

リスク分析・対策選定

SG試験では、次のように問われます。

「この攻撃はどのタイプか？」
「どの対策が有効か？」

例：

無差別攻撃 → スクリプトキディ → 基本的なセキュリティ対策
標的型攻撃 → 詐欺犯・クラッカー → 教育＋監視＋多層防御

👉 攻撃者の種類から対策を逆算するのがポイント

セキュリティ教育（現場運用）

フィッシング対策 → 詐欺犯を想定
内部不正対策 → 故意犯・不満社員を想定

👉 誰を想定しているかで教育内容が変わる

よくある誤解・混同

❌ ハッカー＝悪い人

→ ⭕ 本来は中立（技術者）

👉 SG試験では
「ハッカー＝悪意」と書かれていたら誤りの可能性が高い

❌ 技術力が高い＝危険

→ ⭕ 危険かどうかは「目的」で決まる

👉 クラッカーは悪意あり
👉 ハッカーは善悪どちらもあり

❌ 攻撃者は外部だけ

→ ⭕ 内部の人も攻撃者になる

👉 不正のトライアングルとセットで出題されやすい

まとめ（試験直前用）

攻撃者は「目的・動機」で分類する
スクリプトキディ＝低技術・無差別攻撃
クラッカー＝悪意ある攻撃者（試験で重要）
ハッカーは中立なので混同注意
SG試験では「誰が・何の目的で」を見て対策を判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ボットネットとは？踏み台化とDDoSの関係を理解する【情報セキュリティマネジメント】

Source: pages\sg\botnet.md
Permalink: /sg/botnet/

まず結論

ボットネットとは、マルウェアに感染した多数の端末を遠隔操作し、攻撃に利用する仕組みです。
SG試験では「DDoSの攻撃元になる仕組み」として理解できているかが問われます。

直感的な説明

知らないうちに、自分のPCが「操られる兵隊」になるイメージです。

利用者のPCがマルウェアに感染
攻撃者が遠隔操作できる状態になる
多数のPCをまとめて操作
一斉に攻撃を実行

👉 自分が被害者であり加害者にもなるのがポイントです。

定義・仕組み

ボットネットの構成

ボット（Bot）：感染した端末
攻撃者：ボットを操作する
C&Cサーバ（指令サーバ）：命令を配信

基本の流れ

マルウェア感染
ボット化（遠隔操作可能）
指令サーバから命令受信
一斉攻撃（DDoSなど）

👉 複数端末をまとめて動かす仕組み

どんな場面で使う？

主な用途

DDoS攻撃
スパムメール送信
不正アクセスの踏み台

実務での重要ポイント

自社端末がボット化すると → 知らないうちに攻撃に加担
社会的信用の低下につながる

👉 「防御」だけでなく「加害防止」も重要

よくある誤解・混同

❌ ボットネット＝マルウェアそのもの

→ ⭕ マルウェアによって構成される「ネットワーク」

❌ DDoS攻撃と同じもの

→ ⭕ ボットネットは「攻撃の手段（仕組み）」

❌ 感染するとすぐ被害が出る

→ ⭕ 気づかないまま利用されることが多い

SG試験のひっかけ

「複数端末」「遠隔操作」 → ボットネット
「一斉攻撃」 → DDoS（結果）

👉 手段と結果を切り分ける

まとめ（試験直前用）

ボットネット＝感染端末を遠隔操作する仕組み
DDoSの攻撃元として使われる
自分が「踏み台」になるリスクあり
マルウェアとは別概念（構造）
SG試験では「攻撃の構成」で判断

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

クリックジャッキングとは？見えない操作誘導の仕組み【情報セキュリティマネジメント】

Source: pages\sg\clickjacking.md
Permalink: /sg/clickjacking/

まず結論

クリックジャッキングとは、見えない（透明な）画面を重ねて、利用者に意図しないクリック操作をさせる攻撃です
SG試験では「ユーザの操作をだまして実行させる攻撃か」を見抜けるかがポイントになります

直感的な説明

たとえば、普通のボタンを押したつもりなのに、
実はその裏に「別の危険なボタン」が隠れていたらどうでしょうか。

見えている → 安全そうなボタン
実際に押している → 不正な操作（設定変更・送金など）

このように、見た目と実際の操作をズラす攻撃がクリックジャッキングです。

定義・仕組み

クリックジャッキングは、Webページの表示の仕組み（特に iframe）を悪用します。

基本の流れ

攻撃者が正規サイトの上に透明なページを重ねる
利用者は正規ページを操作しているつもりでクリック
実際には透明ページのボタンが押される
意図しない操作（設定変更・情報送信など）が実行される

ポイント

「ユーザが自分で操作してしまう」点が特徴
マルウェア感染とは違い、利用者の操作を利用する攻撃

どんな場面で使う？

よくある場面

SNSの「いいね」や「フォロー」を勝手に押させる
管理画面の設定変更（例：権限付与）
Webサービスの操作（送信・承認など）

業務での注意点（SG視点）

Web管理画面（クラウド・社内システム）
ブラウザで操作する設定変更系の画面
→ クリックだけで重要操作ができる設計はリスク

よくある誤解・混同

❌ フィッシングと同じ

→ ⭕ フィッシングは「偽サイトに誘導」、クリックジャッキングは「正規画面上で操作をだます」

❌ マルウェアが必要

→ ⭕ 不要。ブラウザ上の表示だけで成立する攻撃

❌ ユーザが操作していない

→ ⭕ ユーザ自身がクリックしてしまうのが特徴

SG試験でのひっかけポイント

「利用者が気づかず操作させられる」→クリックジャッキング
「偽サイトに誘導される」→フィッシング
「DNSを書き換える」→DNSキャッシュポイズニング

👉 “どこでだまされているか”で切り分けるのがコツ

まとめ（試験直前用）

クリックジャッキング＝透明画面でクリック操作をだます攻撃
利用者の操作を利用する（マルウェア不要）
フィッシングとの違いは「サイト誘導か／操作誘導か」
「正規画面上で意図しない操作」ならこれを疑う

👉 判断基準：
見えている画面と、実際の操作がズレているか？

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

C&Cサーバとは？ボットネットを操る指令の仕組み【情報セキュリティマネジメント】

Source: pages\sg\command-and-control.md
Permalink: /sg/command-and-control/

まず結論

C&Cサーバ（Command and Controlサーバ）とは、ボットネットに対して攻撃命令を送る指令サーバです。
SG試験では「ボットを動かす中心の存在」として理解できているかが問われます。

直感的な説明

ボットネットは「軍隊」、C&Cサーバは「司令塔」です。

ボット：命令を受けて動く兵隊
C&Cサーバ：命令を出す司令塔

👉 司令塔があるから一斉攻撃できる

定義・仕組み

基本構成

ボット（感染端末）
C&Cサーバ（指令サーバ）
攻撃者（操作する人）

動作の流れ

端末がマルウェアに感染
ボットがC&Cサーバに接続
C&Cサーバから命令を受信
ボットが攻撃を実行

ポイント

攻撃者は直接ボットを操作しない
→ C&Cサーバ経由で一括制御

👉 効率的に大規模攻撃が可能になる

どんな場面で使う？

主な用途

DDoS攻撃の指令
スパム送信
情報収集（キーログなど）

実務での重要ポイント

感染端末がC&Cサーバと通信していると
→ 外部から操作されている可能性

👉 不審な通信の検知が重要

よくある誤解・混同

❌ C&Cサーバ＝攻撃対象

→ ⭕ 攻撃を指示する側（攻撃インフラ）

❌ ボットネットと同じもの

→ ⭕ ボットネットの一部（役割が違う）

❌ マルウェアと同じ意味

→ ⭕ マルウェアは感染手段、C&Cは制御機構

SG試験のひっかけ

「遠隔操作」「命令を送る」 → C&Cサーバ
「感染端末」 → ボット

👉 役割で切り分ける

まとめ（試験直前用）

C&Cサーバ＝ボットへの指令役
ボットネットの中心的存在
攻撃はC&C経由で制御される
ボット＝実行、C&C＝指示
SG試験では「役割」で判断

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

クラッカーとは？悪意ある攻撃者の特徴と見分け方【情報セキュリティマネジメント】

Source: pages\sg\cracker.md
Permalink: /sg/cracker/

まず結論

クラッカーとは、悪意を持って不正侵入や情報窃取などを行う攻撃者であり、SG試験では「目的が悪意かどうか」「どのレベルの対策が必要か」を判断させる問題として出題されます。

直感的な説明

イメージとしては、

技術を「悪いこと」に使う人
システムに侵入して情報を盗む・壊す人

です。

👉 同じ技術を持っていても、
目的が悪意ならクラッカーになるのがポイントです。

定義・仕組み

クラッカーの特徴を整理します。

悪意を持って攻撃する

情報の盗取（個人情報・機密情報）
システム破壊・改ざん
不正送金や詐欺

技術力はさまざま

高度な攻撃（ゼロデイ、標的型攻撃）
既知の脆弱性攻撃

👉 スクリプトキディとの違いは「目的と理解度」

目的が明確

金銭目的（最も多い）
ハクティビズム（思想的攻撃）
サイバーテロ

👉 動機とセットで出題されやすい

どんな場面で使う？

SG試験での典型パターン

パターン①：攻撃者の分類

悪意あり → クラッカー
技術者（中立） → ハッカー

👉 「悪意があるか」が最重要ポイント

パターン②：対策のレベル判断

スクリプトキディ → 基本対策で防げる
クラッカー → 多層防御・監視が必要

👉 対策の強さを判断させる問題が出やすい

現場での意味

企業の情報漏えい事件の多くはクラッカーによるもの
標的型攻撃やランサムウェアも該当

👉 「被害を出す主体」＝クラッカーと考えると理解しやすい

よくある誤解・混同

❌ ハッカー＝クラッカー

→ ⭕ ハッカーは中立、クラッカーは悪意あり

👉 SG試験ではこの違いがよく問われる

❌ 技術力が高い人＝クラッカー

→ ⭕ 判断基準は「悪意」

👉 技術ではなく目的で分類する

❌ 外部の人だけがクラッカー

→ ⭕ 内部不正でも「悪意」があれば該当

👉 不正のトライアングルと関連づけて出題されることあり

まとめ（試験直前用）

クラッカー＝悪意を持つ攻撃者
判断基準は「技術力」ではなく「目的」
ハッカー（中立）との違いが頻出
スクリプトキディより対策レベルは高く必要
SG試験では「悪意かどうか」で切り分ける

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

CRLとは？失効証明書リストの役割【情報セキュリティマネジメント】

Source: pages\sg\crl.md
Permalink: /sg/crl/

まず結論

CRL（証明書失効リスト）は「有効期限内でも使ってはいけない証明書」を一覧にしたもの
SG試験では「有効期限」と「失効」の違いを理解できているかが問われる

直感的な説明

CRLは「ブラックリスト」です。

たとえば社員証を考えてみてください。
有効期限がまだ残っていても、退職した人のカードは使えませんよね。

同じように、デジタル証明書も
まだ期限内でも“使ってはいけない状態”になることがある
→ その情報をまとめたのがCRLです。

定義・仕組み

CRL（Certificate Revocation List）は、認証局（CA）が発行する
失効した証明書の一覧です。

ポイント

対象：失効した証明書のみ
有効期限とは別管理
定期的に更新される

なぜ必要か

証明書は通常、有効期限内であれば使えますが、次のような場合は危険です。

秘密鍵が漏えいした
所有者情報に誤りがあった
利用者が退職・異動した

このような場合、有効期限内でも強制的に無効（失効）にする必要があります。

→ その結果がCRLに掲載されます

SG試験では
「有効期限が残っている＝安全」ではない
と理解しているかが重要です。

どんな場面で使う？

使う場面

Webサイトの証明書確認（HTTPS通信）
社内システムの証明書認証
電子署名の検証

→ 「この証明書はまだ使っていいのか？」を確認するために使う

業務での判断ポイント

証明書は期限だけでなく「失効確認」が必要
CRLやOCSPを使ってチェックする運用が重要

使うと誤解しやすい場面

有効期限内だから安全と判断してしまう
CRLを見ずに証明書を信用してしまう

よくある誤解・混同

① 有効期限と失効の混同

有効期限：時間による期限切れ
失効：途中で使えなくする措置

→ SG試験ではここをよくひっかけてきます

② CRLはすべての証明書を載せる

→ 誤り

CRLは
失効した証明書だけを載せる

③ 公開鍵があればCRLは不要

→ 誤り

公開鍵があっても
その証明書が失効している可能性があるため確認が必要

④ 失効後は一定期間必ず登録される

→ 誤り

登録期間は固定ではなく、
認証局のポリシーに依存する

SG試験での典型ひっかけ

「有効期限内だからCRL不要」→誤り
「すべての証明書を登録」→誤り
「失効＝期限切れ」→誤り

まとめ（試験直前用）

CRLは「失効した証明書の一覧」
有効期限内でも失効は起こる
「期限内＝安全」は誤り
CRLは“ブラックリスト”と覚える
SG試験では「期限」と「失効の違い」を見抜く

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

クロスサイトリクエストフォージェリとは？なりすまし操作の仕組み【情報セキュリティマネジメント】

Source: pages\sg\csrf.md
Permalink: /sg/csrf/

まず結論

クロスサイトリクエストフォージェリ（CSRF）は、ログイン済みの利用者になりすまして、意図しないリクエストを送らせる攻撃です。
SG試験では「本人の操作に見せかける攻撃かどうか」を見抜けるかがポイントになります。

直感的な説明

イメージとしては、

銀行にログインしたまま別のサイトを見る
そのサイトに「見えない送金ボタン」が仕込まれている
気づかないうちに送金リクエストが実行される

という状態です。

ポイントは
👉 自分は何もしていないのに、勝手に操作が行われること

です。

定義・仕組み

クロスサイトリクエストフォージェリ（CSRF）は、

利用者がログイン済みの状態を利用して
攻撃者が用意したページやリンクを踏ませ
正規のWebサイトに対して不正なリクエストを送らせる

攻撃です。

仕組みの流れ

利用者が正規サイトにログイン（Cookie保持）
攻撃者のページを閲覧
見えない形でリクエスト送信（例：送金・設定変更）
サーバは「ログイン済みユーザの操作」と誤認

重要ポイント

サーバ側は「正規ユーザの通信」と区別できない
攻撃の成立条件は「ログイン状態」

どんな場面で使う？

起きやすい場面

ログイン状態を保持するWebサービス
- 銀行
- ECサイト
- SNS
ワンクリックで実行される処理
- 送金
- パスワード変更
- メール変更

現場での対策の考え方

トークン（CSRFトークン）の付与
再認証（重要操作時）
Refererチェック

👉 「その操作、本当にユーザ本人が意図した？」を確認する仕組みが重要

よくある誤解・混同

❌ XSSと混同する

XSS：スクリプトを実行させる攻撃
CSRF：ユーザの操作を悪用する攻撃

👉 SG試験ではここをよく狙われます

❌ 「不正アクセス」だと考える

CSRFはログイン済みユーザを利用する
ID・パスワードを破るわけではない

👉 「なりすまし操作」がキーワード

❌ 「ユーザが怪しい操作をした」と思う

実際はユーザは気づいていない

👉 「本人の意思ではない」が重要

まとめ（試験直前用）

CSRF＝ログイン状態を悪用したなりすまし操作
サーバは正規ユーザの操作と区別できない
XSSは「スクリプト実行」、CSRFは「リクエスト悪用」
選択肢で「本人の意思でない操作」があればCSRFを疑う

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

CVSSとは？脆弱性の深刻度を共通スコアで判断する【情報セキュリティマネジメント】

Source: pages\sg\cvss.md
Permalink: /sg/cvss/

まず結論

CVSS（共通脆弱性評価システム）は、脆弱性の危険度を0.0〜10.0のスコアで評価する指標
SG試験では「どの基準で評価するか」「スコアの意味」を判断させる問題がよく出ます

直感的な説明

脆弱性は「危ない」と言っても、人によって感じ方が違います。

そこでCVSSは、
👉 全員が同じ基準で危険度を判断できるようにした“点数表” です

たとえば：

誰でも攻撃できる → 点数が高い
条件が厳しい → 点数が低い

こうすることで、
👉 「どれを優先して対策するか」を決めやすくする のが目的です

定義・仕組み

CVSSは、脆弱性の深刻度を 3つの観点（評価基準） で評価します。

① 基本評価基準（Base Metrics）

脆弱性そのものの危険度
時間や環境に関係なく固定

例：

攻撃のしやすさ
認証の必要性
機密性・完全性・可用性への影響

👉 「本質的にどれくらい危険か」

② 現状評価基準（Temporal Metrics）

現時点での危険度

例：

攻撃コードが公開されているか
対策（パッチ）があるか

👉 「今どれくらい危ないか」

③ 環境評価基準（Environmental Metrics）

利用環境を考慮した危険度

例：

重要システムかどうか
影響範囲の大きさ

👉 「自分の環境ではどれくらい影響があるか」

最終的に、
👉 0.0〜10.0のスコアで表現される（高いほど危険）

どんな場面で使う？

✔ 使う場面

脆弱性情報（CVE）を評価するとき
パッチ適用の優先順位を決めるとき
リスクアセスメントの判断材料

👉 「どれから対応すべきか」を決めるために使う

✔ 注意すべき場面

スコアだけで判断してしまう場合

👉 同じCVSSでも

社内システム → 影響大
テスト環境 → 影響小

になることがある

よくある誤解・混同

❌ 「CVSSは0〜100で評価する」

→ ⭕ 0.0〜10.0で評価する

❌ 「評価基準は2つ（現状と環境）」

→ ⭕ 3つ（基本・現状・環境）

❌ 「CVSSは環境に依存しない」

→ ⭕ 環境評価で結果は変わる

❌ 「CVSSv2とv3は同じスコアになる」

→ ⭕ 評価方法が違うのでスコアが変わることがある

SG試験では
👉 「評価基準の数」「スコア範囲」「環境で変わるか」
を狙ってきます

まとめ（試験直前用）

CVSS＝脆弱性を 0.0〜10.0で数値化する指標
評価基準は 基本・現状・環境の3つ
スコアが高いほど危険（優先対応）
環境によって最終評価は変わる
「共通指標だが最終判断は現場依存」 が重要ポイント

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

攻撃の目的をCIAで整理！試験で迷わない判断軸【情報セキュリティマネジメント】

Source: pages\sg\cyber-attack-cia.md
Permalink: /sg/cyber-attack-cia/

まず結論

攻撃は「機密性・完全性・可用性（CIA）のどれを壊すか」で整理できます。
SG試験では「何が壊されているか」で攻撃を切り分けます。

直感的な説明

攻撃の目的は大きく3つしかありません。

情報を盗む
情報を書き換える
システムを止める

👉 この3つがCIAです。

定義・仕組み

機密性（Confidentiality）

情報が漏れないこと

主な攻撃

フィッシング
スパイウェア
キーロガー

👉 情報を盗む攻撃

完全性（Integrity）

情報が正しいこと

主な攻撃

DNSキャッシュポイズニング
改ざん攻撃

👉 情報を書き換える攻撃

可用性（Availability）

使い続けられること

主な攻撃

DoS / DDoS攻撃
DNSリフレクター攻撃

👉 サービスを止める攻撃

どんな場面で使う？

SG試験での使い方

問題文にこう書かれていたら👇

「情報が漏えい」 → 機密性
「誤った情報に誘導」 → 完全性
「サービス停止」 → 可用性

👉 まずCIAに当てはめる

科目Bでの重要ポイント

対策もCIAで変わる

例：

機密性 → アクセス制御
完全性 → 改ざん検知
可用性 → 冗長化

👉 「目的→対策」がつながる

よくある誤解・混同

❌ 攻撃名で覚える

→ ⭕ 攻撃の目的で整理する

❌ DNS攻撃は全部同じ

→ ⭕

ポイズニング → 完全性
リフレクター → 可用性

❌ DDoSは情報漏えいにつながる

→ ⭕ 可用性の問題

SG試験のひっかけ

「盗む」「漏えい」 → 機密性
「改ざん」「偽情報」 → 完全性
「停止」「過負荷」 → 可用性

👉 キーワードで即判断

まとめ（試験直前用）

攻撃はCIAで分類する
機密性＝盗む
完全性＝書き換える
可用性＝止める
SG試験では「何が壊れたか」で切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

DDoS攻撃の種類を整理！試験での見分け方まとめ【情報セキュリティマネジメント】

Source: pages\sg\ddos-attack-summary.md
Permalink: /sg/ddos-attack-summary/

まず結論

DDoS攻撃は「通信量で圧迫するか／接続を詰まらせるか／増幅するか」で分類できます。
SG試験では「攻撃の仕組み（どう止めているか）」で切り分けます。

直感的な説明

DDoS攻撃は「相手を使えなくする」攻撃ですが、やり方が違います。

とにかく大量に送る → 通信でパンク
サーバに仕事だけさせて放置 → 処理が詰まる
他のサーバを使う → 攻撃を増幅

👉 止め方の違い＝分類のポイント

定義・仕組み

① 通信量型（フラッド型）

大量のパケットを送りつける
回線やサーバの処理能力を超えさせる

例：

UDPフラッド
ICMPフラッド

👉 力技で押しつぶす

② 接続枯渇型

接続処理を占有して、新しい接続を受けられなくする

例：

SYNフラッド攻撃

👉 サーバの受付を詰まらせる

③ 増幅型（リフレクション型）

他のサーバを利用して攻撃トラフィックを増やす

例：

DNSリフレクター攻撃
NTPリフレクション攻撃

👉 少ない力で大きな攻撃

どんな場面で使う？

実務での視点

Webサービス停止を狙う攻撃
企業・公共機関への妨害

重要ポイント

自社が攻撃対象になるだけでなく
踏み台になるリスクもある

👉 DNSやNTPの設定不備が原因になることがある

よくある誤解・混同

❌ DDoSは全部同じ攻撃

→ ⭕ 仕組みごとに分類できる

❌ 通信量が多ければすべてフラッド攻撃

→ ⭕ 増幅型の可能性もある

❌ SYNフラッドは通信量攻撃

→ ⭕ 接続処理を詰まらせる攻撃

SG試験のひっかけ

「DNS」「応答」「増幅」 → 増幅型（リフレクター）
「SYN」「接続待ち」 → 接続枯渇型
「大量パケット」 → 通信量型

👉 キーワードで分類する

まとめ（試験直前用）

DDoSは3分類で考える
→ 通信量型／接続枯渇型／増幅型
DNSが出たら増幅型を疑う
SYNが出たら接続枯渇型
「通信か接続か増幅か」で判断
SG試験では仕組みベースで切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ディレクトリトラバーサルとは？不正ファイルアクセスの仕組みと対策【情報セキュリティマネジメント】

Source: pages\sg\directory-traversal.md
Permalink: /sg/directory-traversal/

まず結論

ディレクトリトラバーサルとは、パス指定を悪用して本来アクセスできないファイルにアクセスする攻撃です。SG試験では「不正なファイル参照かどうか」を見抜く問題として出題されます。

直感的な説明

フォルダの中にある資料を取り出すとき、普通は決められた場所しか見られません。

しかし攻撃者は
「1つ上のフォルダに戻る（../）」という指定を使って
本来見えない場所までたどり着きます。

イメージとしては👇

許可されたフォルダ：公開資料
攻撃者の操作：裏の倉庫まで勝手に入り込む

つまり「道（パス）をズルして、立ち入り禁止エリアに入る攻撃」です。

定義・仕組み

ディレクトリトラバーサルは、Webアプリのファイル参照処理の不備を突く攻撃です。

基本の仕組み

アプリがファイルパスをユーザー入力から受け取る
入力チェックが不十分
攻撃者が「../」などを混ぜる
上位ディレクトリに移動して機密ファイルにアクセス

典型例

/download?file=../../etc/passwd

本来は「公開フォルダ内のファイル」だけを取得する想定でも、
上の階層へ移動できてしまうと、システム内部のファイルが読めてしまいます。

なぜ問題か

設定ファイルやパスワード情報が漏えいする
サーバ内部構造が知られる
他の攻撃（不正アクセス）につながる

どんな場面で使う？

使われる場面

ファイルダウンロード機能
画像表示機能
ログ閲覧機能

👉「ユーザー入力でファイルを指定できる」仕組みは要注意

誤解しやすい場面

単なるURL操作ではなく「パスの解釈の問題」
認証を突破する攻撃ではない（アクセス制御の不備とは別）

よくある誤解・混同

❌ SQLインジェクションと同じ？

→ ⭕ 全く別物

SQLインジェクション：データベース操作を改ざん
ディレクトリトラバーサル：ファイルパスを悪用

👉 SG試験ではこの違いをよく問われます

❌ OSの脆弱性の問題？

→ ⭕ 多くはアプリの入力チェック不備

原因は「設計・実装のミス」
対策は「入力値の制御」

❌ 認証があれば防げる？

→ ⭕ 認証とは別問題

ログイン済でも発生する可能性あり
アクセス制御だけでは不十分

SG試験でのひっかけ

「SQLを実行する攻撃」と書いてあれば誤り（それはSQLインジェクション）
「パス指定でファイルにアクセス」とあればディレクトリトラバーサル

まとめ（試験直前用）

「../」などで上位ディレクトリへ移動 → ファイル不正取得
DB操作ならSQLインジェクション、ファイル参照なら本攻撃
原因は入力値チェック不足（設計ミス）
認証や権限管理とは別の問題
選択肢では「ファイルパス操作かどうか」で判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

DNSリフレクター攻撃とDNSキャッシュポイズニングの違いを整理【SG試験】

Source: pages\sg\dns-attack-difference.md
Permalink: /sg/dns-attack-difference/

まず結論

DNSリフレクター攻撃は「通信を集中させて止める攻撃（可用性の破壊）」、DNSキャッシュポイズニングは「名前解決を改ざんする攻撃（完全性の破壊）」です。
SG試験では「止めるのか／だますのか」で切り分けます。

直感的な説明

この2つは目的がまったく違います。

DNSリフレクター攻撃
→ 荷物を大量に送りつけて「相手をパンクさせる」
DNSキャッシュポイズニング
→ 住所録を書き換えて「間違った場所に誘導する」

👉 攻撃の目的が違うと覚えるのが一番シンプルです。

定義・仕組み

DNSリフレクター攻撃

IPアドレスを偽装
DNSサーバに問い合わせを送る
応答をターゲットに送りつける
結果：通信量でサービス停止（DoS/DDoS）

👉 特徴：なりすまし＋増幅

DNSキャッシュポイズニング

DNSサーバのキャッシュ情報を改ざん
正しいドメイン名 → 偽のIPに変える
利用者を偽サイトへ誘導
結果：フィッシングや情報漏えい

👉 特徴：名前解決の改ざん

どんな場面で使う？

DNSリフレクター攻撃

サービス停止を狙う攻撃
DDoSの一種として使われる

👉 可用性（Availability）を狙う

DNSキャッシュポイズニング

偽サイトへ誘導
認証情報の盗み取り

👉 完全性（Integrity）を狙う

よくある誤解・混同

❌ DNSに関係する攻撃は全部同じ

→ ⭕ 目的が違う（止める vs だます）

❌ どちらも通信量を増やす攻撃

→ ⭕ 増やすのはリフレクター攻撃だけ

❌ キャッシュポイズニングはDoS攻撃

→ ⭕ 情報改ざん攻撃（フィッシングにつながる）

SG試験のひっかけ

「大量通信」「トラフィック増大」 → リフレクター攻撃
「誤ったIPアドレスを返す」 → キャッシュポイズニング

👉 このキーワードで即判断できるようにする

まとめ（試験直前用）

リフレクター攻撃＝通信を集中させて止める（可用性）
キャッシュポイズニング＝名前解決を改ざん（完全性）
「なりすまし＋増幅」ならリフレクター攻撃
「偽のIPを返す」ならキャッシュポイズニング
SG試験では「攻撃の目的」で切り分ける

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

DNSキャッシュポイズニングとファーミングの違いを整理【SG試験】

Source: pages\sg\dns-poisoning-vs-pharming.md
Permalink: /sg/dns-poisoning-vs-pharming/

まず結論

DNSキャッシュポイズニングは「DNSサーバを改ざんする攻撃」、ファーミングは「利用者を偽サイトに誘導する攻撃（手段は複数）」です。
SG試験では「どこが改ざんされているか」で切り分けます。

直感的な説明

同じ「偽サイトに誘導」でも原因が違います。

DNSキャッシュポイズニング
→ 住所録（DNSサーバ）を書き換える
ファーミング
→ どこかを細工して、とにかく偽サイトに連れていく

👉 ファーミングは“結果”、キャッシュポイズニングは“手段”です。

定義・仕組み

DNSキャッシュポイズニング

DNSサーバのキャッシュを改ざん
正しいドメイン → 偽のIPへ変更
利用者は気づかず偽サイトへ

👉 DNSサーバが原因

ファーミング（Pharming）

利用者を偽サイトへ誘導する攻撃全体
手段は複数
- DNS改ざん（←キャッシュポイズニング）
- hostsファイル改ざん
- マルウェア

👉 原因は複数あり得る

どんな場面で使う？

DNSキャッシュポイズニング

DNSサーバが攻撃対象
組織単位で影響が広がる

ファーミング

個人PC・ネットワーク・DNSなど幅広い
フィッシングより気づきにくい

👉 URLが正しくても偽サイトになるのが特徴

よくある誤解・混同

❌ ファーミング＝DNS攻撃

→ ⭕ DNSは手段の1つにすぎない

❌ DNSキャッシュポイズニング＝ファーミング

→ ⭕ ファーミングの一種（手段の一つ）

SG試験のひっかけ

「DNSサーバのキャッシュ改ざん」 → DNSキャッシュポイズニング
「利用者を偽サイトへ誘導」 → ファーミング

👉 手段か結果かで切る

まとめ（試験直前用）

キャッシュポイズニング＝DNSサーバ改ざん
ファーミング＝偽サイト誘導（広い概念）
ファーミングは複数手段あり
DNSと明記されていればキャッシュポイズニング
「どこが改ざんされたか」で判断

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

DNSリフレクター攻撃とは？仕組みと対策の考え方【情報セキュリティマネジメント】

Source: pages\sg\dns-reflector-attack.md
Permalink: /sg/dns-reflector-attack/

まず結論

DNSリフレクター攻撃とは、送信元IPアドレスを偽装してDNSサーバにリクエストを送り、その応答を標的に集中させることで通信を圧迫する攻撃（DoS/DDoS）です。
SG試験では「なりすまし＋応答を利用した増幅攻撃」と理解できているかが問われます。

直感的な説明

「他人の住所を書いた注文を大量に出して、商品を全部その人に送りつける」イメージです。

攻撃者：DNSサーバに大量の問い合わせを送る
ただし送信元は「標的のIP」に偽装
DNSサーバ：問い合わせに対して応答を返す
結果：標的に大量の応答が押し寄せる

攻撃者は直接攻撃せず、サーバを“踏み台”にするのがポイントです。

定義・仕組み

DNSリフレクター攻撃は、次の2つの特徴で成り立ちます。

① IPアドレスの偽装（IPスプーフィング）

攻撃者は送信元IPを「標的」に偽装
DNSサーバはそれを本物と信じて応答を返す

② 応答の増幅（Amplification）

小さなリクエスト → 大きなレスポンスになる
そのため、攻撃トラフィックが何倍にも増える

この結果、

攻撃者の負荷は小さい
標的には非常に大きな負荷がかかる

という非対称な攻撃になります。

SG試験では「増幅型DDoS攻撃の代表例」として理解しておくと整理しやすいです。

どんな場面で使う？

使われる場面

Webサービスや企業サイトへのDDoS攻撃
サービス停止を狙う妨害行為
ボットネットと組み合わせた大規模攻撃

業務での重要ポイント

外部公開DNSサーバが踏み台にされる可能性がある
自社が「加害側」にもなり得る

そのため、

不要なDNS応答の制限
オープンリゾルバの無効化などの対策が重要になります。

よくある誤解・混同

❌ DNSサーバ自体が攻撃対象

→ ⭕ DNSサーバは「踏み台（リフレクター）」として使われる

❌ 攻撃者が直接大量通信を送る

→ ⭕ サーバの応答を利用して間接的に攻撃する

❌ 単なるDoS攻撃の一種

→ ⭕ なりすまし＋増幅が特徴のDDoS攻撃

SG試験のひっかけ

「送信元IPを偽装しているか？」が重要
「応答を利用しているか？」が判断ポイント

👉 この2つがなければ、DNSリフレクター攻撃ではないと切れます。

まとめ（試験直前用）

DNSリフレクター攻撃＝偽装したIPにDNS応答を送りつける攻撃
ポイントは「IPスプーフィング＋増幅」
DNSサーバは攻撃対象ではなく踏み台
「直接攻撃か／間接攻撃か」で切り分ける
選択肢では「応答を利用しているか」に注目

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

DNSリフレクター攻撃とSYNフラッド攻撃の違いを整理【SG試験】

Source: pages\sg\dos-attack-difference.md
Permalink: /sg/dos-attack-difference/

まず結論

DNSリフレクター攻撃は「他サーバを使って通信を増幅する攻撃」、SYNフラッド攻撃は「接続処理を詰まらせる攻撃」です。
SG試験では「増幅か／接続枯渇か」で切り分けます。

直感的な説明

DNSリフレクター攻撃
→ 他人に頼んで荷物を大量に送りつける
SYNフラッド攻撃
→ 受付に来て「ちょっと待って」と言ったまま居座る人が大量発生

👉 どちらも止まるが、止まり方が違う

定義・仕組み

DNSリフレクター攻撃

IP偽装＋DNSサーバ利用
応答でトラフィック増幅
通信量で圧迫

SYNフラッド攻撃

TCPの3ウェイハンドシェイクを悪用
SYN送信後、ACKを返さない
サーバの接続待ちが溜まる

👉 接続リソース枯渇

どんな場面で使う？

DNSリフレクター攻撃

大規模DDoS
ボットネットと組み合わせ

SYNフラッド攻撃

サーバ単体を狙う
比較的シンプルな攻撃

よくある誤解・混同

❌ どちらも同じDoS攻撃

→ ⭕ 攻撃の仕組みが違う

❌ SYNフラッドは通信量攻撃

→ ⭕ 接続処理を詰まらせる攻撃

SG試験のひっかけ

「DNS」「応答」「増幅」 → リフレクター攻撃
「SYN」「接続待ち」 → SYNフラッド

👉 キーワードで即切る

まとめ（試験直前用）

リフレクター攻撃＝増幅型DDoS
SYNフラッド＝接続枯渇型DoS
DNSが出たらリフレクターを疑う
SYNが出たら即SYNフラッド
「通信量か接続か」で判断

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

DoS攻撃とDDoS攻撃の違いを整理【SG試験】

Source: pages\sg\dos-vs-ddos.md
Permalink: /sg/dos-vs-ddos/

まず結論

DoS攻撃は「1つの攻撃元からのサービス妨害」、DDoS攻撃は「複数の攻撃元からの分散攻撃」です。
SG試験では「攻撃元が1つか複数か」で切り分けます。

直感的な説明

同じ「サービスを止める攻撃」でも、やり方が違います。

DoS攻撃
→ 1人が大量にアクセスしてサーバを止める
DDoS攻撃
→ 大人数で一斉にアクセスしてサーバを止める

👉 人数の違い＝攻撃の違い

定義・仕組み

DoS攻撃（Denial of Service）

単一の攻撃元から攻撃
通信や処理を集中させる
規模は比較的小さい

DDoS攻撃（Distributed Denial of Service）

複数の攻撃元から同時攻撃
ボットネットなどを利用
大規模で防御が難しい

👉 インターネット上の多数の端末が使われる

どんな場面で使う？

DoS攻撃

小規模な攻撃
単純な負荷試験の延長のようなケース

DDoS攻撃

大規模サービス停止
社会的影響を狙う攻撃

👉 実務ではほぼDDoSが問題になる

よくある誤解・混同

❌ DoSとDDoSは同じ意味

→ ⭕ D（Distributed）がつくと「分散攻撃」

❌ 通信量が多ければDDoS

→ ⭕ 攻撃元が複数かどうかが本質

❌ SYNフラッド＝DDoS

→ ⭕ 手法の話であり、DoSにもDDoSにもなり得る

SG試験のひっかけ

「複数の端末」「ボットネット」 → DDoS
「単一の攻撃元」 → DoS

👉 攻撃手法ではなく“構成”で判断

まとめ（試験直前用）

DoS＝単一攻撃元
DDoS＝複数攻撃元（分散）
「ボットネット」が出たらDDoS
手法（SYNなど）ではなく構成で判断
SG試験では「誰が攻撃しているか」で切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ハッカーとは？本来の意味とホワイトハッカーとの違い【情報セキュリティマネジメント】

Source: pages\sg\hacker.md
Permalink: /sg/hacker/

まず結論

ハッカーとは、本来は高い技術力を持つ技術者を指す中立的な言葉であり、SG試験では「ハッカー＝悪意ではない」と正しく切り分けられるかが問われます。

直感的な説明

ニュースなどでは「ハッカー＝悪い人」と言われがちですが、本来は違います。

技術を「良いこと」に使う → ホワイトハッカー
技術を「悪いこと」に使う → クラッカー

👉 ハッカーは“技術者”、クラッカーは“犯罪者”
この違いが一番大事です。

定義・仕組み

ハッカーは本来、以下のような人を指します。

高い技術力を持つ人

システムやネットワークの仕組みを深く理解
脆弱性を見つける能力がある

善悪は含まない（中立）

セキュリティ強化に貢献する人もいる
不正に使えばクラッカーになる

👉 「技術者」という意味の言葉

ホワイトハッカー（White Hacker）

セキュリティ向上のために活動
脆弱性診断やペネトレーションテストを行う

👉 企業や組織にとって「守る側の専門家」

どんな場面で使う？

SG試験での典型パターン

パターン①：用語の正しい理解

ハッカー＝悪意 → ❌ 誤り
ハッカー＝技術者 → ⭕ 正解

👉 ここはひっかけとして頻出

パターン②：攻撃者の分類

悪意あり → クラッカー
技術力あり（中立） → ハッカー

👉 「目的」で判断するのがポイント

現場での意味

ホワイトハッカーが企業の脆弱性を診断
セキュリティ対策の強化に活用される

👉 攻撃者だけでなく、防御側にも存在する

よくある誤解・混同

❌ ハッカー＝犯罪者

→ ⭕ 本来は中立（技術者）

👉 SG試験ではこの誤解を突く問題が多い

❌ ハッカーとクラッカーは同じ

→ ⭕ 明確に違う

ハッカー：技術者（中立）
クラッカー：悪意ある攻撃者

❌ 技術力が高い＝危険人物

→ ⭕ 技術ではなく「使い方」で決まる

👉 ホワイトハッカーはむしろ必要な存在

まとめ（試験直前用）

ハッカー＝高い技術力を持つ人（中立）
悪意がある場合はクラッカーと呼ぶ
ホワイトハッカーは防御側の専門家
SG試験では「ハッカー＝悪意」は誤り
判断基準は「技術」ではなく「目的」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

メールヘッダーインジェクションとは？改行を悪用する攻撃【情報セキュリティマネジメント】

Source: pages\sg\mail-header-injection.md
Permalink: /sg/mail-header-injection/

まず結論

メールヘッダーインジェクションとは、入力フォームに改行文字などを埋め込み、メールのヘッダーや本文を不正に改ざんする攻撃です。
SG試験では「入力値をそのまま使う設計の弱さ（脆弱性）」を突く攻撃として問われます。

直感的な説明

お問い合わせフォームに名前やメールアドレスを入力すると、その内容がメールとして送信されますよね。

もしその入力欄に
「改行＋別の宛先」
を仕込めたらどうなるでしょうか？

👉 本来送るはずのメールに、勝手に別の宛先や内容が追加されてしまいます。

定義・仕組み

メールヘッダーインジェクションは、Webフォームなどの入力値に改行コード（CRLF）を含めることで、メールのヘッダー情報を不正に追加・変更する攻撃です。

典型的な仕組み

入力フォームに悪意ある文字列を入力
改行コードを使ってヘッダーを分断
新しいヘッダー（To、Cc、Bccなど）を追加
不正なメール送信や情報漏えいが発生

👉 「入力値がそのままメールに使われる」ことが原因

どんな場面で使う？

よくある対象

お問い合わせフォーム
会員登録フォーム
メール送信機能を持つWebアプリ

業務でのポイント

入力値の検証（バリデーション）が重要
改行コードの除去・無効化
フレームワークの安全な関数を使う

👉 開発・設計ミスを突く攻撃（脆弱性利用）

よくある誤解・混同

❌ フィッシングとの違い

フィッシング：人をだまして入力させる
ヘッダーインジェクション：システムの不備を突く

👉 人を狙う vs システムを狙う

❌ SQLインジェクションとの違い

SQLインジェクション：データベース操作を改ざん
ヘッダーインジェクション：メールの構造を改ざん

👉 対象が違う（DBかメールか）

❌ 迷いやすいポイント（SG試験）

「改行コード」「入力フォーム」「ヘッダー追加」
→ このキーワードが出たらメールヘッダーインジェクション
「だまして入力させる」ならフィッシング系

まとめ（試験直前用）

メールヘッダーインジェクション＝改行でメール構造を改ざん
入力値をそのまま使う設計ミスが原因
フィッシングは人、インジェクションはシステムを狙う
「改行コード」「ヘッダー追加」が出たら即判断

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

メッセージ認証とは？改ざん検知と送信者確認の仕組み【情報セキュリティマネジメント】

Source: pages\sg\message-authentication.md
Permalink: /sg/message-authentication/

まず結論

メッセージ認証とは、「データが改ざんされていないこと」と「送信者が正しいこと」を確認する仕組みであり、SG試験では「電子署名との関係」で問われることが多い。

直感的な説明

たとえば、契約書を紙でやり取りするとき、

内容が途中で書き換えられていないか（改ざん防止）
本人が書いたものか（なりすまし防止）

を確認したいですよね。

これをデジタルで実現したのがメッセージ認証です。

「封筒の中身が変わっていない＋送り主が本物」
この2つを同時にチェックするイメージです。

定義・仕組み

メッセージ認証は、主に次の2つの技術を組み合わせて実現します。

ハッシュ関数
公開鍵暗号（電子署名）

基本の流れはシンプルです。

送信側

メッセージからハッシュ値を作る
そのハッシュ値を秘密鍵で暗号化（署名）する
メッセージと署名を送る

受信側

メッセージからハッシュ値を再計算する
署名を公開鍵で復号してハッシュ値を取り出す
2つのハッシュ値を比較する

→ 一致すればOK

改ざんされていない（完全性）
送信者が正しい（認証）

SG試験ではこの流れを丸暗記するのではなく、

👉 「送信者は秘密鍵」「受信者は公開鍵」

この対応関係を押さえることが重要です。

どんな場面で使う？

よく使われる場面

電子メールの送信（なりすまし防止）
ソフトウェア配布（改ざん検知）
電子契約（本人確認）

SG試験での出題ポイント

SG試験では、

「改ざん検知なのか？」
「送信者確認なのか？」
「両方なのか？」

を判断させる問題が多いです。

👉 メッセージ認証は 両方を満たす仕組み

よくある誤解・混同

❌ ハッシュで元のメッセージに戻せる

→ できない（不可逆）

SG試験では
「ハッシュ値を復号して元のメッセージを得る」
と書かれていたら即NGです。

❌ 送信者は公開鍵で署名する

→ 逆です

正：秘密鍵で署名
誤：公開鍵で署名

👉 ここは超頻出のひっかけです

❌ 暗号化＝メッセージ認証

→ 役割が違う

暗号化：盗み見防止（機密性）
メッセージ認証：改ざん検知＋送信者確認

👉 SG試験では「機密性」と「完全性」を混同させてくる

❌ 秘密鍵のハッシュ値を送る

→ 意味がない

送るのは
👉 メッセージのハッシュ値に対する署名

まとめ（試験直前用）

メッセージ認証＝改ざん検知＋送信者確認
送信者：ハッシュ作成 → 秘密鍵で署名
受信者：ハッシュ再計算＋公開鍵で検証
「秘密鍵で署名・公開鍵で確認」が判断基準
ハッシュは元に戻せない（ここを狙った誤りに注意）

SQLインジェクションとは？仕組みと対策をやさしく理解【情報セキュリティマネジメント】

Source: pages\sg\sql-injection.md
Permalink: /sg/sql-injection/

まず結論

SQLインジェクションとは、入力値にSQL文を混入させてデータベースを不正操作する攻撃です。
SG試験では「入力値をそのまま使っているかどうか」を見抜けるかがポイントです。

直感的な説明

SQLインジェクションは「注文にこっそり命令を混ぜる」イメージです。

たとえば、ログイン画面で
「ユーザー名」を入力するはずなのに、

’’’ ‘OR ‘1’=’1 ‘’’

のような不正な文字列を入れると、
システムがそれをSQL文として解釈してしまい、
本来ありえない動き（認証突破など）が起きます。

👉 本来は「値」なのに「命令」として扱われてしまうのが問題です。

定義・仕組み

SQLインジェクションとは、

入力フォームなどにSQL文の一部を埋め込み、
データベースに対して意図しない操作を実行させる攻撃

です。

典型的な原因：

入力値をそのままSQLに連結している
入力チェック（バリデーション）が不十分

基本的な流れ：

ユーザーが入力欄に悪意ある文字列を入力
そのままSQL文に組み込まれる
データベースがそれを実行してしまう

結果として：

認証回避
データの漏えい
データの改ざん

などが発生します。

どんな場面で使う？

攻撃されやすい場面

ログイン画面
検索フォーム
問い合わせフォーム

👉 「ユーザー入力をDBに渡す処理」はすべて対象です。

対策が必要な場面

Webアプリケーション全般
外部入力を扱うシステム

👉 SG試験では
「入力値の扱い」が問われることが多いです。

よくある誤解・混同

❌ よくある誤解

「通信を盗み見る攻撃」
「プログラムを制限する仕組み」

⭕ 正しい理解

入力値を悪用してデータベースを操作する攻撃

SG試験でのひっかけ

SG試験では次のように混同させてきます。

「通信内容を検知して遮断」
　→ WAF
「実行環境を制限する」
　→ サンドボックス
「入力値を悪用してDB操作」
　→ SQLインジェクション（これが正解）

👉 選択肢では
「SQL文の中に不正な入力を埋め込む」と書かれていたらSQLインジェクションです。

まとめ（試験直前用）

SQLインジェクション＝入力値を使ったDB不正操作攻撃
原因は「入力値をそのままSQLに使うこと」
対策は
→ プレースホルダ（バインド変数）
→ 入力チェック
SG試験では
→ 「入力値の扱い」に注目して判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

SSL/TLSとは？通信を守る暗号化の仕組み【情報セキュリティマネジメント】

Source: pages\sg\ssl-tls.md
Permalink: /sg/ssl-tls/

まず結論

SSL/TLSとは、インターネット通信を暗号化し、盗聴や改ざんを防ぐための仕組みであり、HTTPSなどの安全な通信の基盤となる技術である。

SG試験では「なぜ安全なのか（暗号化＋認証）」を判断させる問題として出題されます。

直感的な説明

SSL/TLSは「通信に鍵をかける仕組み」です。

イメージとしては、

HTTP：はがき（誰でも読める）
HTTPS：鍵付きの箱（中身が見えない＋改ざんされない）

という違いです。

つまりSSL/TLSは、 通信の中身を守るための“カギと封印”の役割を持っています。

定義・仕組み

SSL/TLSは、通信を安全にするために次の3つを実現します。

① 暗号化（機密性）

通信内容を暗号化することで、第三者に内容を読まれないようにします。

② 改ざん防止（完全性）

通信途中で内容が書き換えられていないかを検知します。

③ サーバ認証（正当性の確認）

接続先が本物のサーバかどうかを確認します。

→ これに使われるのが「デジタル証明書」です。

SG試験での重要ポイント

SSL/TLS＝暗号化＋認証
HTTPSは「HTTP＋SSL/TLS」

この関係を理解しておくことが重要です。

どんな場面で使う？

使う場面

Webサイト（HTTPS）
オンライン決済
ログイン処理

SG試験でよくある出題

「通信を暗号化する仕組みはどれか」 → SSL/TLS
「HTTPSで使われている技術はどれか」 → SSL/TLS

現場運用での意味

SSL/TLSなし → 情報漏えいリスク
SSL/TLSあり → 基本的なセキュリティ確保

つまり、 SSL/TLSは最低限のセキュリティ対策です。

よくある誤解・混同

❌ SSLとTLSは別物

→ ⭕ TLSはSSLの後継（実質同じ用途）

SG試験ではまとめて「SSL/TLS」として扱われます。

❌ 暗号化だけの仕組み

→ ⭕ 認証と改ざん防止も含まれる

「暗号化だけ」と思っていると選択肢を誤ります。

❌ HTTPSが安全なのはURLの違い

→ ⭕ SSL/TLSが裏で動いているから安全

本質は「暗号化の仕組み」です。

まとめ（試験直前用）

SSL/TLS＝通信の暗号化＋認証＋改ざん防止
HTTPSの中身の技術
デジタル証明書で正当性を確認
SG試験では「なぜ安全か」で問われる
HTTPとの違いは「SSL/TLSの有無」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

踏み台攻撃とは？加害者にならないための重要ポイント【情報セキュリティマネジメント】

Source: pages\sg\stepping-stone-attack.md
Permalink: /sg/stepping-stone-attack/

まず結論

踏み台攻撃とは、第三者の機器を乗っ取って攻撃に利用する手法です。
SG試験では「攻撃元を隠す／他人を使う攻撃」として理解できているかが問われます。

直感的な説明

「自分では攻撃せず、他人のPCを使って攻撃する」イメージです。

攻撃者：直接攻撃しない
被害者のPC：知らないうちに攻撃に使われる
本来の標的：攻撃を受ける

👉 被害者が加害者になる構造

定義・仕組み

基本の流れ

機器がマルウェアなどで侵害される
攻撃者がその機器を遠隔操作
他のシステムへ攻撃を実行

主な具体例

ボットネットによるDDoS攻撃
DNSリフレクター攻撃（サーバを利用）
不正アクセスの中継

ポイント

攻撃元の特定が難しくなる
攻撃者の匿名性が高まる

👉 責任の所在が分かりにくい

どんな場面で使う？

攻撃者の目的

身元を隠す
攻撃の規模を拡大

実務での重要ポイント

自社の機器が踏み台になると → 加害者として扱われるリスク
例：
- 自社サーバから攻撃通信が発生
- 外部からの信用低下
- 法的・契約上の問題

👉 「守る」だけでなく「使われない」ことが重要

よくある誤解・混同

❌ 踏み台攻撃＝特定の攻撃手法

→ ⭕ 攻撃の“やり方（構造）”の概念

❌ DDoS攻撃と同じ

→ ⭕ DDoSは踏み台攻撃の一例

❌ 自分が攻撃対象にならなければ問題ない

→ ⭕ 踏み台になるリスクがある

SG試験のひっかけ

「他の端末を利用して攻撃」 → 踏み台攻撃
「ボットネット」 → 踏み台の仕組み
「攻撃元の偽装」 → 踏み台の目的

👉 「誰が攻撃しているように見えるか」で判断

まとめ（試験直前用）

踏み台攻撃＝他人の機器を使う攻撃
ボットネット・リフレクターは代表例
目的は「匿名化」と「拡大」
被害者が加害者になる構造
SG試験では「攻撃の構成」で切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

タイムスタンプとは？存在証明と否認防止の役割を理解する【情報セキュリティマネジメント】

Source: pages\sg\timestamp.md
Permalink: /sg/timestamp/

まず結論

タイムスタンプとは、「その時刻にその電子文書が存在していたこと」を証明する仕組み
SG試験では「改ざん防止」ではなく存在証明・否認防止であるかを見抜く問題として出題される

直感的な説明

タイムスタンプは「日付入りの証明書」のようなものです。

たとえば契約書に「この日付で存在していました」と公的に証明されると、あとから
「そんな文書は作っていない」と言い逃れできません。

ただし、

コピーはできる
改ざんもできる

👉 でも
「あとから変えたかどうか」はバレる

この「防ぐのではなく、証明する」という感覚がとても重要です。

定義・仕組み

タイムスタンプは、信頼できる第三者機関（TSA：時刻認証局）が発行します。

役割は大きく2つです。

① 存在証明

「この時刻までに、この電子文書は存在していた」

② 完全性の証明（非改ざん証明）

タイムスタンプ付与後に変更されていないことを確認できる

ここで重要なのは👇

👉 改ざんを防ぐのではなく、改ざんを検知できるだけ

どんな場面で使う？

使う場面

契約書・申請書などの電子文書の証拠性確保
電子帳簿保存法などの記録保存
「いつ作られたか」が重要な文書

👉 業務では
後からのトラブル（言った・言わない）を防ぐために使う

使わない（誤解しやすい）場面

コピーを防ぎたい → ❌
改ざんそのものを防ぎたい → ❌

👉 これらは別の対策（アクセス制御・暗号など）

よくある誤解・混同

❌ タイムスタンプ＝改ざん防止

👉 実際は
改ざんを防ぐのではなく、改ざんを検知する

❌ タイムスタンプ＝コピー防止

👉 コピーは普通にできる
（選択肢でよく出るひっかけ）

⚠ 電子署名との違い

| 用語 | 役割 | |——|——| | 電子署名 | 作成者の証明・改ざん検知 | | タイムスタンプ | 存在時刻の証明 |

👉 SG試験ではこの違いをよく問われる

SG試験の典型ひっかけ

「防止」という言葉が出たら要注意
正解はだいたい「証明」「検知」

まとめ（試験直前用）

タイムスタンプ＝存在証明（いつあったか）
コピー防止ではない
改ざん防止ではない（検知のみ）
キーワードは否認防止
選択肢で「防止」と書かれていたら疑う

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

脆弱性とは？攻撃される原因を理解する【情報セキュリティマネジメント】

Source: pages\sg\vulnerability.md
Permalink: /sg/vulnerability/

まず結論

脆弱性とは、脅威によって攻撃される可能性のある「弱点」のこと（JIS Q 27000:2014 3.77）
SG試験では「脅威・脆弱性・リスクの関係を正しく理解できているか」が問われる

直感的な説明

脆弱性は「カギのかかっていないドア」のようなものです。

家（＝システム）に
カギがかかっていないドア（＝脆弱性）があると
泥棒（＝脅威）が入り込める

つまり、

👉 弱点（脆弱性）があるから攻撃される

という関係です。

システムでも同じで、

バグがある
設定が甘い
パスワードが弱い

こういったものがすべて脆弱性になります。

定義・仕組み

脆弱性は、JISで次のように定義されます。

脅威によって付け込まれる可能性のある、資産または管理策の弱点
（JIS Q 27000:2014 用語番号 3.77）

ポイントは2つです。

① 「弱点」であること

プログラムのバグ
設定ミス
運用ルールの不備

👉 技術だけでなく「運用のミス」も脆弱性

② 「脅威とセットで意味を持つ」

脆弱性だけでは被害は発生しません。

脆弱性（弱点）
脅威（攻撃者・災害など）

この2つが組み合わさると、

👉 リスク（被害の可能性）になる

関係の整理（超重要）

脅威：攻撃する存在
脆弱性：攻撃される原因（弱点）
リスク：実際に被害が起こる可能性

SG試験ではこの関係が頻出です。

どんな場面で使う？

① セキュリティ対策の検討

「どこが弱いか？」を見つける
→ パッチ適用、設定変更などで対策

👉 脆弱性の発見がスタート地点

② リスクアセスメント

脅威 × 脆弱性 → リスク評価

👉 「脆弱性があるかどうか」でリスクの大きさが変わる

③ システム運用・監査

定期的な脆弱性診断
ソフトウェア更新（パッチ管理）

👉 運用での管理が重要

よくある誤解・混同

❌ 脆弱性＝攻撃そのもの

→ 間違い

脆弱性：弱点
攻撃：脅威による行動

👉 攻撃ではなく「攻撃される原因」

❌ 脆弱性＝リスク

→ 間違い

脆弱性だけでは被害は発生しない
脅威と組み合わさって初めてリスクになる

❌ バグだけが脆弱性

→ 間違い

設定ミス（例：誰でもアクセス可能）
運用ミス（例：パスワード使い回し）

👉 人的・運用的な問題も含まれる

SG試験のひっかけポイント

「脅威」「脆弱性」「リスク」を入れ替えてくる
「脆弱性＝攻撃」と書いてあれば誤り
「脆弱性単体で被害が発生する」と書いてあれば誤り

まとめ（試験直前用）

脆弱性＝攻撃される原因となる弱点（JIS Q 27000:2014 3.77）
バグだけでなく、設定・運用の不備も含む
脅威と組み合わさってリスクになる
判断基準：
- 攻撃する側 → 脅威
- 攻撃される原因 → 脆弱性
- 被害の可能性 → リスク

👉 この3つを切り分けられれば正解できる

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

クロスサイトスクリプティングとは？スクリプト実行の仕組み【情報セキュリティマネジメント】

Source: pages\sg\xss.md
Permalink: /sg/xss/

まず結論

クロスサイトスクリプティング（XSS）は、Webサイトに不正なスクリプトを埋め込み、利用者のブラウザで実行させる攻撃です。
SG試験では「スクリプトが実行されるかどうか」で見分けるのが重要です。

直感的な説明

イメージとしては、

普通のWebページに見える
しかし裏で「仕込まれたプログラム」が動く
利用者の情報が盗まれる

という状態です。

例：

コメント欄に悪意あるコードが書かれる
それを見た人のブラウザで自動実行
Cookieなどが盗まれる

👉 ページを開いただけで被害が起きるのが特徴です

定義・仕組み

クロスサイトスクリプティング（XSS）は、

Webアプリの入力チェック不備などを利用して
悪意あるスクリプトをページに埋め込み
他の利用者のブラウザで実行させる攻撃

です。

仕組みの流れ

攻撃者がスクリプトを仕込む（入力フォームなど）
サーバがそのまま表示してしまう
利用者がページを閲覧
ブラウザでスクリプトが実行
Cookieや入力情報が送信される

主な被害

Cookieの盗取（セッション乗っ取り）
偽画面の表示（フィッシング誘導）
不正な操作の実行

どんな場面で使う？

起きやすい場面

入力内容をそのまま表示する機能
- 掲示板
- コメント欄
- 検索結果表示
HTMLエスケープが不十分なWebアプリ

現場での対策の考え方

入力値の無害化（エスケープ処理）
出力時のサニタイズ
Content Security Policy（CSP）の導入

👉 「スクリプトを実行させない」ことが本質

よくある誤解・混同

❌ CSRFと混同する

XSS：スクリプトを実行させる
CSRF：リクエストを送らせる

👉 SG試験では
「不正なスクリプト実行」と書かれていたらXSS

❌ サーバが直接攻撃されると思う

実際は「利用者のブラウザ」が攻撃対象

👉 攻撃対象はクライアント側

❌ クリックしないと起きないと思う

ページ表示だけで実行される場合もある

👉 「閲覧だけで発動」が重要

まとめ（試験直前用）

XSS＝スクリプトを利用者のブラウザで実行させる攻撃
被害はCookie盗取やセッション乗っ取り
CSRFは「リクエスト悪用」、XSSは「スクリプト実行」
選択肢で「スクリプト」「ブラウザ実行」があればXSSを疑う

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

情報セキュリティ管理

SG試験ケース問題の解き方テンプレ【情報セキュリティマネジメント】

Source: pages\sg\case-solving-template.md
Permalink: /sg/case-solving-template/

まず結論

SGのケース問題は「原因 → 対策の種類 → 順番」で解く
迷ったら「人・ルール・技術・委託・インシデント」のどれかで切る

直感的な説明

SGの問題は一見むずかしく見えますが、やっていることはシンプルです👇

👉 「何が原因？」
👉 「どの対策が合う？」

この2つだけ

定義・仕組み

解き方テンプレ（これだけ覚える）

① 原因を特定する
👉 人？ルール？技術？外部？事故？

② 対策の種類を決める
👉 教育？安全管理？委託管理？インシデント対応？

③ 順番を確認する
👉 いまやるべきことか？

対策の分類（超重要）

問題を見たらまずこれ👇

人の問題 → 教育・訓練
ルール不足 → 組織的対策
システム問題 → 技術的対策
外部委託 → 委託先管理
事故発生後 → インシデント対応

👉 ここで8割決まる

どんな場面で使う？

ケース問題の典型パターン

パターン①：人的ミス

例👇

誤送信
フィッシング

👉 教育・訓練

パターン②：管理不足

例👇

ルール未整備
責任不明

👉 組織的対策

パターン③：技術不足

例👇

アクセス制御なし
ログなし

👉 技術的対策

パターン④：委託問題

例👇

外部業者のミス

👉 委託先管理

パターン⑤：事故発生後

例👇

ウイルス感染

👉 インシデント対応（拡大防止）

よくある誤解・混同

❌ よくある誤解

とりあえず技術対策を選ぶ
強そうな対策を選ぶ

⭕ 正しい理解

原因に合った対策を選ぶ
順番を守る

SG試験のひっかけ

典型パターン👇

人の問題なのに技術対策 → ❌
初動対応なのに原因調査 → ❌
委託なのに自社対策 → ❌

👉 原因とズレた選択肢を切る

まとめ（試験直前用）

「原因 → 対策 → 順番」で考える
人・ルール・技術・委託・事故で分類
強そうな対策ではなく適切な対策
インシデントはまず拡大防止
「ズレている選択肢」を消す

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ケース問題の解き方！CIAとリスク対応で考える実践手順【SG試験】

Source: pages\sg\case-study-approach.md
Permalink: /sg/case-study-approach/

まず結論

ケース問題は「CIA → 対策 → リスク対応」の順で考えると安定して解けます。
SG試験では「何が起きているか → どう対応するか」の判断力が問われます。

直感的な説明

問題文は長いですが、やることはシンプルです👇

何が起きているか見る
何が困るか考える
どうすればいいか選ぶ

👉 順番を守るだけで解ける

定義・仕組み

解く手順（最重要）

① 事象の把握

どんな攻撃・問題かを確認

例：

DDoS → サービス停止

② CIAで分類

何が壊れているか

例：

サービス停止 → 可用性

③ 対策を考える

どの対策が適切か

例：

冗長化・負荷分散

④ リスク対応を判断

実施するかどうか

例：

コストを考えて低減を選択

👉 この4ステップで解く

どんな場面で使う？

典型問題パターン

「最も適切な対応はどれか」
「優先すべき対策はどれか」

解き方のコツ

いきなり選択肢を見ない
まずCIAを決める

👉 これだけで正答率が上がる

よくある誤解・混同

❌ 知っている用語で選ぶ

→ ⭕ 問題に合っているかで選ぶ

❌ 強そうな対策を選ぶ

→ ⭕ 目的に合った対策を選ぶ

❌ 完璧な対策を選ぶ

→ ⭕ 現実的な対応を選ぶ

SG試験のひっかけ

「暗号化」など万能そうな選択肢に注意
「目的とズレている対策」は不正解

例：

DDoS対策 → 暗号化 ❌
改ざん対策 → バックアップ ❌（直接ではない）

👉 CIAと一致しているかで切る

まとめ（試験直前用）

手順は4ステップ
→ 事象 → CIA → 対策 → リスク対応
まずCIAを決める
対策は目的と一致させる
最後は現実的な判断
SG試験は「流れ」で解く

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

よくある誤答パターンまとめ！SG試験で選択肢を切るコツ【情報セキュリティマネジメント】

Source: pages\sg\common-mistakes.md
Permalink: /sg/common-mistakes/

まず結論

SG試験の誤答は「目的とズレた対策を選んでしまうこと」が原因です。
「CIAと一致しているか」で選択肢を切ることが最重要です。

直感的な説明

間違いはだいたい同じです。

強そうな対策を選ぶ
とりあえず安全そうなものを選ぶ
用語を知っているから選ぶ

👉 全部ダメです

正しくは👇
👉 「この問題で必要な対策か？」を見る

定義・仕組み

誤答の原因（3パターン）

① CIAのズレ

問題：可用性
選択：機密性対策 → ❌

例：

DDoS対策 → 暗号化 ❌

② 手段と目的の混同

手段だけ見て選ぶ

例：

ボットネット＝攻撃そのもの ❌
→ 実際は攻撃の仕組み

③ 現実性の無視

完璧すぎる対策を選ぶ

例：

サービス停止（回避）を選ぶ ❌
→ 業務が成り立たない

どんな場面で使う？

SG試験の典型ミス

問題文👇

「サービス停止を防ぐ」
「情報漏えいを防止」

なのに👇

違う目的の対策を選ぶ

👉 ここで落とす人が多い

正しい判断の流れ

何が問題か
CIAで分類
対策が一致しているか

👉 この3つで切る

よくある誤解・混同

❌ 暗号化は万能

→ ⭕ 機密性だけ

❌ バックアップは最強

→ ⭕ 可用性中心

❌ 強い対策＝正解

→ ⭕ 目的に合っているかが重要

SG試験のひっかけ（超重要）

パターン①

DDoS問題
→ 暗号化・認証を選ばせる

👉 ❌（可用性とズレ）

パターン②

改ざん問題
→ バックアップを選ばせる

👉 ❌（直接対策ではない）

パターン③

現実的判断
→ 回避（サービス停止）を選ばせる

👉 ❌（過剰対応）

まとめ（試験直前用）

誤答の原因＝CIAのズレ
まずCIAを判断する
対策が一致しているか確認
強そうな選択肢に注意
SG試験は「目的一致」で切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

CSIRTとは？組織内インシデント対応の基本【情報セキュリティマネジメント】

Source: pages\sg\csirt.md
Permalink: /sg/csirt/

まず結論

CSIRTは、組織内で発生したセキュリティインシデントに対応する専門チームである。
SG試験では「社内対応か、外部支援か（JPCERT/CC）」を見分ける問題が多い。

直感的な説明

会社でトラブルが起きたとき、
現場で対応する「社内の専門チーム」が必要ですよね。

CSIRTはまさにそれで、
会社の中でセキュリティ事故に対応する“専任チーム”です。

例えば：

ウイルス感染したPCの対応
不正アクセスの調査
情報漏えいの原因分析

などを担当します。

👉 イメージ：
CSIRT＝社内の消防隊（火事が起きたらすぐ出動）

定義・仕組み

CSIRT（Computer Security Incident Response Team）は、

セキュリティインシデントの
- 検知
- 分析
- 対応
- 復旧
  を行う組織内のチームです。

基本の役割

インシデントの検知（異常の発見）
影響範囲の調査
被害拡大の防止
原因分析と再発防止

ポイント

組織内に設置される
実際に手を動かして対応する
必要に応じて外部（JPCERT/CCなど）と連携する

SG試験では
「インシデントに対処する実働部隊」として理解すればOKです。

どんな場面で使う？

使う場面（正しい理解）

自社でセキュリティ事故が発生したとき
社内ネットワークで異常が検知されたとき
被害の拡大を防ぐための初動対応

使うと誤解しやすい場面

❌ 外部の相談窓口（それはJPCERT/CC）
❌ 経営判断を行う組織（それは経営層やISMS）

よくある誤解・混同

① JPCERT/CCとの違い

CSIRT：組織内の対応チーム（自社で動く）
JPCERT/CC：外部から支援する組織

👉 SG試験ではここをよく入れ替えてくる

② SOCとの違い

SOC：監視・検知が中心
CSIRT：実際の対応・復旧まで行う

👉 「対応までやるか？」で切る

③ ISMSとの違い

ISMS：管理の仕組み（ルール・体制）
CSIRT：実務の対応チーム

👉 「仕組み」か「実働」かで判断

まとめ（試験直前用）

CSIRT＝組織内のインシデント対応チーム
実際に対応・復旧まで行う「現場部隊」
選択肢では
- 「外部機関」→×
- 「監視だけ」→×
- 「対応・復旧を行う」→○

👉 「社内で実際に動くかどうか」で切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

不正のトライアングルとは？内部不正が起こる3要素【情報セキュリティマネジメント】

Source: pages\sg\fraud-triangle.md
Permalink: /sg/fraud-triangle/

まず結論

不正のトライアングルとは、「動機・機会・正当化」の3つがそろうと不正が発生しやすくなるという考え方であり、SG試験では不正を防ぐためにどの要素を断つべきかを判断させる問題として出題されます。

直感的な説明

たとえば、社内で不正が起きる場面を考えてみます。

お金に困っている（動機）
一人で処理できてチェックがない（機会）
「これくらい大丈夫」と思ってしまう（正当化）

この3つがそろうと、不正が起きやすくなります。

逆に言うと、どれか1つでも崩せば不正は起きにくくなるというのがポイントです。

定義・仕組み

不正のトライアングルは、内部不正や不祥事の原因分析に使われる基本概念です。

3つの要素は以下のとおりです。

① 動機（Motivation）

不正をしたくなる理由
例：

金銭的な問題
ノルマ・プレッシャー
不満（待遇・評価）

② 機会（Opportunity）

不正ができてしまう状況
例：

チェック体制がない
権限が集中している
ログ監視が不十分

👉 業務設計やアクセス管理の問題がここに該当

③ 正当化（Rationalization）

「やっても仕方ない」と思う心理
例：

「会社も不正している」
「自分は正当に評価されていない」
「一度だけなら問題ない」

👉 教育や組織文化の問題がここに該当

どんな場面で使う？

不正対策を考えるとき

SG試験では、「どう防ぐか」が問われます。

機会を減らす
→ 職務分掌、アクセス制御、監査ログ
動機を減らす
→ 適切な評価制度、労務管理
正当化を防ぐ
→ セキュリティ教育、倫理意識の向上

ケース問題（科目B）

「なぜ不正が起きたか」
「どの対策が有効か」

👉 3要素のどこに問題があったかを見抜くのがポイント

よくある誤解・混同

❌ 技術対策だけで防げる

→ ⭕ 正当化や動機も関係する

SG試験では
「アクセス制御を強化すれば十分」といった選択肢が出ますが不正解になりやすいです。

❌ 不正は悪い人がやるもの

→ ⭕ 誰でも条件がそろえば起こり得る

👉 人ではなく「環境」に注目するのが重要

❌ 動機がなければ安全

→ ⭕ 機会があるだけでもリスク

👉 権限集中・チェック不足は要注意

まとめ（試験直前用）

不正は「動機・機会・正当化」の3つがそろうと起きる
対策は「どれか1つを断つ」視点で考える
SG試験では「機会（統制の不備）」がよく問われる
技術対策だけでなく、教育・組織も含めて判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

インシデント対応とは？初動対応の判断基準を整理【情報セキュリティマネジメント】

Source: pages\sg\incident-response.md
Permalink: /sg/incident-response/

まず結論

インシデント対応とは「事故発生時に被害を最小化するための対応」
SG試験では「最初にやるべき行動（初動対応）」を判断させる問題がよく出る

直感的な説明

情報漏えいや不正アクセスが起きたとき👇

すぐ復旧する？
原因を調べる？

👉 実はどっちも違う

まずやるべきは👇
👉 被害の拡大を止める

定義・仕組み

インシデントとは

情報セキュリティ上の事故
例👇
情報漏えい
不正アクセス
マルウェア感染

インシデント対応の基本流れ

① 検知・把握
→ 何が起きたか確認

② 初動対応（最重要）
→ 拡大防止

③ 原因調査
→ なぜ起きたか

④ 復旧
→ 元の状態に戻す

⑤ 再発防止
→ 同じ事故を防ぐ

👉 SG試験は「②初動対応」をよく聞く

どんな場面で使う？

科目Bの典型パターン

ウイルス感染
不正アクセス検知
誤送信発覚

正しい初動対応（超重要）

例👇

ネットワークから切り離す
アカウント停止
システム隔離

👉 共通点👇
👉 拡大防止

NG対応（よく出る）

いきなり復旧
原因調査を優先
報告せず自己判断

👉 順番ミスが狙われる

よくある誤解・混同

❌ よくある誤解

まず原因調査
すぐ復旧が最優先

⭕ 正しい理解

最優先は拡大防止
その後に調査・復旧

SG試験のひっかけ

典型パターン👇

「原因調査」→ ❌（まだ早い）
「復旧作業」→ ❌（まだ早い）
「隔離・停止」→ ⭕

👉 「順番」で判断する

まとめ（試験直前用）

インシデント対応＝事故時の対応
最優先は拡大防止
流れは「検知→拡大防止→調査→復旧→再発防止」
原因調査や復旧は後
「最初に何をするか」で選択肢を切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

JPCERT/CCとは？役割とCSIRTとの違いを整理【情報セキュリティマネジメント】

Source: pages\sg\jpcert-cc.md
Permalink: /sg/jpcert-cc/

まず結論

JPCERT/CCは、日本国内のセキュリティインシデント対応を支援する中立的な組織（CSIRT）である。
SG試験では「政府機関ではない独立組織」という点を判断させる問題が多い。

直感的な説明

会社でトラブルが起きたときに、
「専門家に相談して対処を手伝ってもらう」ことがありますよね。

JPCERT/CCは、
日本全体のセキュリティ相談窓口＋専門支援チームのような存在です。

不正アクセスがあった
マルウェアに感染した
情報漏えいの可能性がある

こういったときに、
企業や組織をまたいで対応をサポートする役割を担っています。

定義・仕組み

JPCERT/CC（JPCERT Coordination Center）は、

コンピュータセキュリティインシデントに関する
- 報告の受付
- 対応支援
- 情報共有
- 再発防止の助言
  を行う組織です。

ポイントは次の3つです。

① 中立・独立の組織

特定の政府機関や企業に属さない
公平な立場で対応できる

② 日本版CSIRT

CSIRT（Computer Security Incident Response Team）の一種
国内全体を対象にした「調整役」

③ 情報共有のハブ

攻撃手法や脆弱性情報を収集・共有
被害の拡大を防ぐ役割

SG試験では
「インシデント対応を支援する組織」＝JPCERT/CC
と押さえておけばOKです。

どんな場面で使う？

使う場面（正しい理解）

インシデントが発生したときの相談・支援
複数組織にまたがる攻撃への対応
攻撃情報の共有・注意喚起

使うと誤解しやすい場面

❌ 社内対応チーム（それはCSIRT）
❌ 政府の司令塔（それはNCOなど）

よくある誤解・混同

① CSIRTとの違い

CSIRT：組織内の対応チーム
JPCERT/CC：外部の支援・調整機関

👉 SG試験ではここを混同させてきます

② NCO（国家サイバー統括室）との違い

NCO：政府の司令塔（内閣官房）
JPCERT/CC：独立した民間組織

👉 「政府かどうか」で切るのがポイント

③ CRYPTRECとの違い

CRYPTREC：暗号の評価・推奨
JPCERT/CC：インシデント対応

👉 「暗号か？インシデントか？」で判断

④ JISCとの違い

JISC：標準化（JIS）
JPCERT/CC：セキュリティ対応支援

👉 分野が全く違う

まとめ（試験直前用）

JPCERT/CC＝日本のインシデント対応支援組織（CSIRT）
政府ではなく中立・独立の組織
役割は「報告受付・対応支援・情報共有」
選択肢では
- 「政府機関」→×
- 「暗号評価」→×
- 「インシデント対応支援」→○

👉 「誰の組織か」ではなく「何をするか」で切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

NCOとは？政府のサイバー司令塔を理解する【情報セキュリティマネジメント】

Source: pages\sg\nco.md
Permalink: /sg/nco/

まず結論

NCOは、内閣官房に設置された日本のサイバーセキュリティ対策の司令塔となる組織である。
SG試験では「政府の司令塔」か「現場対応組織（CSIRTやJPCERT/CC）」かを見分ける問題が多い。

直感的な説明

会社でいうと、

現場で対応するチーム（CSIRT）
外部から支援する専門家（JPCERT/CC）
全体方針を決める経営層

がありますよね。

NCOはこの中で、
国レベルの“経営層・司令塔”の役割です。

👉 イメージ

CSIRT：現場
JPCERT/CC：外部支援
NCO：全体を指揮するトップ

定義・仕組み

NCO（国家サイバー統括室）は、

内閣官房に設置された組織で
日本全体のサイバーセキュリティ対策を統括する

役割を持ちます。

主な役割

政府全体のセキュリティ方針の策定
サイバー攻撃への対応方針の決定
関係省庁・機関の連携・調整
重要インフラの保護に関する指示

ポイント

政府の組織である（内閣官房）
現場で対応するのではなく、方針を決める
全体の統括・指揮が役割

SG試験では
「司令塔」＝NCO
と押さえると判断しやすくなります。

どんな場面で使う？

使う場面（正しい理解）

国家レベルのサイバー攻撃対応
政府全体のセキュリティ方針の決定
重要インフラ防護の指揮

使うと誤解しやすい場面

❌ 個別企業のインシデント対応（それはCSIRT）
❌ 技術的な支援・助言（それはJPCERT/CC）

よくある誤解・混同

① CSIRTとの違い

CSIRT：組織内の実務対応
NCO：全体方針を決める司令塔

👉 「実際に対応するか？」で切る

② JPCERT/CCとの違い

JPCERT/CC：中立な外部支援機関
NCO：政府の組織（内閣官房）

👉 「政府かどうか」で判断

③ SG試験のひっかけ

SG試験では次のように混同させてきます：

「インシデント対応を行う」→CSIRTやJPCERT/CC
「統括・指揮する」→NCO

👉 選択肢では
“対応する”か“指揮する”かに注目

まとめ（試験直前用）

NCO＝政府のサイバーセキュリティ司令塔（内閣官房）
現場対応ではなく方針決定・統括が役割
選択肢では
- 「インシデント対応を行う」→×
- 「中立組織」→×
- 「政府の司令塔」→○

👉 「政府か？現場か？」で切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

SG試験よく出るNG選択肢まとめ【情報セキュリティマネジメント】

Source: pages\sg\ng-patterns.md
Permalink: /sg/ng-patterns/

まず結論

SG試験は「ズレた対策」を選ばせる問題が多い
「原因と対策が合っているか」「順番が正しいか」で切る

直感的な説明

SGの問題はこうなっています👇

👉 正しそうな選択肢が並ぶ
👉 でも1つだけ「ズレている」

つまり👇
👉 完璧を選ぶのではなく「ズレ」を見抜く試験

定義・仕組み

NG選択肢の作られ方（超重要）

SG試験のひっかけはパターン化されています👇

パターン①：対策の種類ズレ

例👇

人のミス → 技術対策を選ばせる
ルール問題 → 教育を選ばせる

👉 原因と対策がズレている

パターン②：順番ミス

例👇

インシデントで原因調査を先にやる
復旧を優先する

👉 本来は拡大防止が先

パターン③：やりすぎ（過剰対策）

例👇

軽微な違反で重い処分
全面禁止など極端な対策

👉 合理性がない

パターン④：丸投げ

例👇

委託したので責任なし
契約したから管理不要

👉 委託元の責任は残る

パターン⑤：手続き無視

例👇

就業規則を勝手に変更
意見聴取なし

👉 プロセス違反

どんな場面で使う？

問題の見方テンプレ

① 原因を見る
👉 人・ルール・技術・委託・事故

② 選択肢を見る
👉 合っているか？ズレているか？

③ NGパターンに当てはめる

実戦イメージ

問題👇
「誤送信が多い」

選択肢👇

A：教育強化
B：システム変更

👉 正解：A
👉 Bは「ズレ」

よくある誤解・混同

❌ よくある誤解

強そうな対策を選ぶ
完璧な対策を選ぶ

⭕ 正しい理解

原因に合った対策を選ぶ
ズレているものを消す

SG試験のひっかけ（まとめ）

対策の種類ズレ
順番ミス
過剰対策
丸投げ
手続き違反

👉 この5つでほぼ全て説明できる

まとめ（試験直前用）

SGは「ズレ」を見抜く試験
原因と対策が一致しているかを見る
インシデントは順番に注意
委託は丸投げNG
手続き違反は即NG

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

残留リスクとは？対応後にも残るリスクを理解する【情報セキュリティマネジメント】

Source: pages\sg\residual-risk.md
Permalink: /sg/residual-risk/

まず結論

残留リスクとは「リスク対応を行った後でも残るリスク」
SG試験では「対応してもゼロにならない」という前提を理解できているかが問われる

直感的な説明

例えば「鍵をかける」対策をしても、泥棒が絶対に入れないわけではありません。

鍵をかける → リスクは下がる
でも「ゼロにはならない」

この「対策してもまだ残っているリスク」が残留リスクです。

👉 対策＝リスク消滅ではない、というのがポイント

定義・仕組み

残留リスクは、リスクマネジメントの流れの中で次のように位置づけられます。

リスクを特定する
リスクを評価する
リスク対応（回避・低減・移転・受容）を行う
それでも残るリスクが「残留リスク」

つまり、

対策後の状態で
「まだ許容するか？」を判断する対象

になります。

ISMSでも、最終的に「残留リスクを受容できるか」が重要な判断になります。

どんな場面で使う？

よく使う場面

セキュリティ対策を実施した後の最終判断
管理者が「これ以上対策するか？」を決める場面
コストとリスクのバランスを取る場面

👉 実務では
「コストをかけすぎず、どこまで許容するか」が重要

誤解しやすい場面

「対策したから安全」と考える
「リスクはゼロにできる」と思う

👉 SG試験ではこの考えは明確に誤り

よくある誤解・混同

❌ よくある誤解

残留リスク＝対策が不十分な状態
残留リスク＝対応前のリスク

⭕ 正しい理解

残留リスク＝対応後でも残るリスク（正常な状態）

混同しやすい用語

固有リスク（Inherent Risk）
- 対策前のリスク
- まだ何もしていない状態
残留リスク（Residual Risk）
- 対策後のリスク
- それでも残るもの

👉 SG試験では
「対策前か、対策後か」で切り分ける

典型的なひっかけ

「対策したらリスクはなくなる」→ ❌
「残留リスクはゼロにするべき」→ ❌
「残留リスクは受容するか判断する対象」→ ⭕

👉 選択肢では
「残る」「許容」「判断」などのキーワードが出たら正解に近い

まとめ（試験直前用）

残留リスク＝対策後にも残るリスク
リスクはゼロにならないのが前提
最終的に「受容するか」を判断する対象
固有リスク（対策前）との違いが頻出
SG試験では「ゼロになる」と書いてあれば誤りと判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

リスク対応とCIAの関係を整理！試験で迷わない判断フロー【SG試験】

Source: pages\sg\risk-response-cia.md
Permalink: /sg/risk-response-cia/

まず結論

リスク対応は「CIAで特定したリスクに対してどう対処するかの意思決定」です。
SG試験では「この状況でどの対応を選ぶべきか」が問われます。

直感的な説明

これまでの流れを1本にするとこうなります👇

攻撃を受ける
何が壊れるか（CIA）を判断
対策を考える
最後に「どう対応するか」を決める

👉 リスク対応＝最終判断

定義・仕組み

リスク対応は4つに分類されます。

① 回避（Risk Avoidance）

危険なことをやらない

例：

危険なサービスを停止する

👉 リスクをゼロにするが、機能も失う

② 低減（Risk Mitigation）

リスクを減らす

例：

DDoS対策導入
アクセス制御強化

👉 最も一般的な対応

③ 移転（Risk Transfer）

リスクを他者に移す

例：

保険加入
クラウド利用

👉 自社で抱えない

④ 受容（Risk Acceptance）

リスクを受け入れる

例：

影響が小さいので対策しない

👉 コストとのバランスで判断

どんな場面で使う？

SG試験での典型パターン

問題はこう聞いてきます👇

「最も適切な対応はどれか？」
「現実的な対応はどれか？」

👉 完璧ではなく“現実的な判断”を選ぶ

判断の流れ（超重要）

どのCIAが影響を受けるか
適切な対策は何か
その対策を実施するか判断

👉 最後がリスク対応

よくある誤解・混同

❌ とにかく対策すればよい

→ ⭕ コストと効果で判断する

❌ すべて回避が正しい

→ ⭕ 現実的ではない（業務が止まる）

❌ 受容は何もしない＝悪い

→ ⭕ 合理的な判断の一つ

SG試験のひっかけ

「サービス停止」 → 回避
「対策導入」 → 低減
「保険・外部委託」 → 移転
「影響軽微」 → 受容

👉 キーワードで判断

まとめ（試験直前用）

リスク対応＝最終意思決定
回避＝やめる
低減＝減らす
移転＝任せる
受容＝そのまま
SG試験では「現実的か」で切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

リスク対応とは？4つの対処方法を整理【情報セキュリティマネジメント】

Source: pages\sg\risk-treatment.md
Permalink: /sg/risk-treatment/

まず結論

リスク対応とは、リスク評価の結果をもとに「そのリスクをどう扱うか（減らす・避ける・共有する・受け入れる）」を決めて実行することです。
SG試験では「その対策がどの種類のリスク対応か」を判断させる問題がよく出ます。

直感的な説明

リスク対応は「事故にどう備えるかの選択」です。

たとえば地震リスクなら：

家を建てない → 回避
耐震補強する → 低減
保険に入る → 共有
何もしない → 受容

同じリスクでも「どう向き合うか」は複数の選択肢があります。
SG試験は、この選択の違いを見抜けるかがポイントです。

定義・仕組み

■ リスク対応とは

JIS Q 31000:2010（リスクマネジメントの指針）では、
リスク対応は「リスクを修正するためのプロセス」と定義されています。

■ 主な4つの対応方法（試験重要）

実務・試験では次の4つで整理すると理解しやすいです。

リスク回避
→ リスクを生む活動をやめる（例：危険なシステムを使わない）
リスク低減（軽減）
→ 発生確率や影響を下げる（例：ウイルス対策ソフト導入）
リスク共有（移転）
→ 他者と分担する（例：保険加入、外部委託）
※金銭的リスクを移すものは「リスクファイナンシング」
リスク受容（保有）
→ あえて対策せず受け入れる（例：軽微なリスクは放置）

どんな場面で使う？

■ よくある業務判断

システム障害リスク → 冗長化（低減）
情報漏えいリスク → 委託契約で責任分担（共有）
高コストすぎる対策 → 受容

■ SG試験での出題パターン

「この対策はどのリスク対応か？」
「適切なリスク対応を選べ」

選択肢では「行動内容」から分類させる問題が多いです。

よくある誤解・混同

❌ 保険はリスクをなくす → 間違い

→ ⭕ 保険は「リスク共有（移転）」
（損失の負担を他者に移すだけ）

❌ セキュリティ対策＝すべて低減

→ ⭕ 対策の種類で変わる

利用停止 → 回避
保険 → 共有
何もしない → 受容

❌ リスク対応は1つだけ選ぶ

→ ⭕ 複数を組み合わせることもある

■ SG試験のひっかけポイント

「保険」「契約」→ 共有
「やめる」「中止」→ 回避
「対策導入」→ 低減

この対応関係を覚えておくと、選択肢をかなり切れます。

まとめ（試験直前用）

リスク対応＝「どう扱うか」の意思決定
4分類：回避・低減・共有・受容
保険・委託 → 共有（超頻出）
SG試験は「行動から分類」を問う問題が多い
キーワードで即判定できるようにするのがコツ

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

情報セキュリティ基本方針とは？経営者の宣言を理解する【情報セキュリティマネジメント】

Source: pages\sg\security-policy-basic.md
Permalink: /sg/security-policy-basic/

まず結論

情報セキュリティ基本方針とは、経営者が示す「情報をどう守るか」という方向性と意思を表した文書
SG試験では「具体的な対策ではなく、方針レベルかどうか」を判断させる問題が多い

直感的な説明

会社のトップが
「うちは情報セキュリティをこういう考えで守ります」と宣言するのが基本方針です。

たとえば：

情報を守ることを重要視する
法令を守る
継続的に改善する

👉 現場の細かいルールではなく
“会社としての考え方”を示すものです

定義・仕組み

情報セキュリティ基本方針は、情報セキュリティポリシーの最上位に位置します。

主な内容は以下のようなものです：

情報セキュリティの目的（なぜ守るのか）
適用範囲（どこまで守るのか）
経営者の責任と関与
法令・規格の遵守
継続的改善の方針

👉 ポイントは
「具体的な対策は書かない」こと

また、基本方針は

社内に周知される
必要に応じて社外にも公開される

という特徴があります

どんな場面で使う？

使う場面

ISMSの構築・運用
社内のセキュリティ教育
外部への信頼性アピール（Web公開など）

👉 「この会社はちゃんとセキュリティを考えているか」を示す土台になります

注意が必要な場面

手順書のような細かい内容を書く
システム単位の対策を書く

👉 それは
対策基準や実施手順の役割です

よくある誤解・混同

❌ 誤解1

基本方針は機密文書なので外部に出さない

👉 ⭕ 正しくは
外部公開されることもある（信頼性の証明）

❌ 誤解2

一度決めたら変更しない

👉 ⭕ 正しくは
環境変化（法改正・技術）に応じて見直す

❌ 誤解3

具体的な対策を書く文書

👉 ⭕ 正しくは
方向性だけを書く（具体策は下位文書）

SG試験では
👉「それは方針レベルか？具体策か？」
と問われることが多いです

まとめ（試験直前用）

基本方針＝経営者の宣言（方向性）
具体的対策は書かない（→対策基準・手順）
社外公開されることがある
環境に応じて見直す
「具体的すぎる内容」は誤りと判断

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

情報セキュリティ実施手順とは？現場でのやり方を理解する【情報セキュリティマネジメント】

Source: pages\sg\security-policy-procedures.md
Permalink: /sg/security-policy-procedures/

まず結論

情報セキュリティ実施手順とは、対策基準で決めたルールを「どうやって実行するか」を具体的な手順として示した文書
SG試験では「ルールではなく作業レベルかどうか」を見極める問題がよく出る

直感的な説明

対策基準が「何を守るか（ルール）」なら、
実施手順は
👉「どうやってやるの？」をまとめたものです

たとえば：

バックアップの取り方（どの時間に・どの手順で）
ログの確認方法（どこを見るか・どの順番で）
インシデント発生時の対応手順

👉 現場で使うマニュアル・作業手順書のイメージです

定義・仕組み

情報セキュリティ実施手順は、ポリシーの最下位レイヤーです。

役割：

対策基準を現場で実行できる形にする
作業のばらつきを防ぐ
誰でも同じ対応ができるようにする

主な内容：

作業手順（ステップごとの操作）
使用ツール・操作方法
異常時の対応フロー
記録・報告方法

👉 ポイント
「具体的な操作レベルまで書く」こと

どんな場面で使う？

使う場面

日常運用（バックアップ、ログ確認など）
インシデント対応
新人教育・引き継ぎ

👉 現場では
「人によってやり方が違う」問題を防ぐために重要です

注意が必要な場面

ルールだけを書いて具体性がない
経営方針のような抽象的な内容を書く

👉 それは

ルール → 対策基準
抽象 → 基本方針
の役割です

よくある誤解・混同

❌ 誤解1

実施手順＝ルール

👉 ⭕ 正しくは
ルールを実行するためのやり方

❌ 誤解2

抽象的な内容でもOK

👉 ⭕ 正しくは
誰でも同じように実行できる具体性が必要

❌ 誤解3

組織全体の方針を書く

👉 ⭕ 正しくは
現場の作業内容を書く

SG試験では
👉「これは作業レベルか？」
👉「具体的すぎる＝手順」
と判断できるかが重要です

まとめ（試験直前用）

実施手順＝どうやるか（作業レベル）
対策基準を実行するための具体手順
最も具体的な文書
マニュアル・手順書に相当
「抽象的な内容」→手順ではないので誤り

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

情報セキュリティ対策基準とは？ルールレベルの考え方【情報セキュリティマネジメント】

Source: pages\sg\security-policy-standards.md
Permalink: /sg/security-policy-standards/

まず結論

情報セキュリティ対策基準とは、基本方針を実現するために「何を守るか」を具体的なルールとして定めた文書
SG試験では「方針ではなくルールレベルかどうか」を見極める問題がよく出る

直感的な説明

基本方針が「こういう考えで守る！」という宣言だとすると、

対策基準は
👉「じゃあ何を守るの？」を決めるルールです

たとえば：

パスワードは〇文字以上にする
USBは許可されたものだけ使う
アクセス権は必要最小限にする

👉 現場で守るべき“約束ごと”のイメージです

定義・仕組み

情報セキュリティ対策基準は、ポリシーの中間レイヤーです。

役割は以下の通り：

基本方針を具体化する
組織全体で守るルールを統一する
セキュリティ対策の基準を示す

主な内容：

アクセス制御のルール
パスワード管理の基準
ログ管理・監視のルール
端末・ネットワーク利用ルール

👉 ポイント
「何を守るか」まで書くが、「どうやるか」は書かない

どんな場面で使う？

使う場面

社内ルールの整備
セキュリティ監査の基準
委託先への要求事項の提示

👉 現場では
「人によってやり方が違う」状態を防ぐために使います

注意が必要な場面

手順レベルまで細かく書く
経営方針のような抽象的な内容を書く

👉 それは

手順 → 実施手順
抽象 → 基本方針
の役割です

よくある誤解・混同

❌ 誤解1

対策基準＝作業手順

👉 ⭕ 正しくは
ルールであり、手順ではない

❌ 誤解2

対策基準＝経営方針

👉 ⭕ 正しくは
基本方針を具体化したもの

❌ 誤解3

システムごとの詳細設定を書く

👉 ⭕ 正しくは
組織全体のルールを書く

SG試験では
👉「これはルールか？手順か？」
👉「これは方針か？基準か？」
の切り分けが重要です

まとめ（試験直前用）

対策基準＝何を守るか（ルール）
基本方針より具体的、手順より抽象的
手順までは書かない
組織全体の共通ルール
「やり方が書いてある」→手順なので誤り

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

情報セキュリティポリシーとは？3階層で理解する基本ルール【情報セキュリティマネジメント】

Source: pages\sg\security-policy.md
Permalink: /sg/security-policy/

まず結論

情報セキュリティポリシーとは、組織が情報を守るためのルールを3階層（基本方針・対策基準・実施手順）で整理したもの
SG試験では「どのレベルの文書か」を判断させる問題がよく出る

直感的な説明

会社で「セキュリティちゃんとやろう！」と言っても、それだけでは何も動きません。

そこで次のように分けて考えます：

方針（どういう考えで守るか）
ルール（何を守るか）
手順（どうやってやるか）

👉 この3つをまとめたものが「情報セキュリティポリシー」です

現場でいうと
「社長の宣言 → 社内ルール → 作業マニュアル」のイメージです

定義・仕組み

情報セキュリティポリシーは、通常3階層で構成されます。

① 情報セキュリティ基本方針

経営者が示す「セキュリティの考え方」
例：情報を守る目的、取り組む姿勢
社外公開されることも多い

👉 ポイント：方向性・宣言レベル

② 情報セキュリティ対策基準

方針を実現するためのルール
例：パスワードの長さ、アクセス制御のルール

👉 ポイント：守るべきルール

③ 情報セキュリティ実施手順

実際の作業手順
例：バックアップの手順、ログ確認方法

👉 ポイント：現場のやり方

SG試験ではこの3つをまとめて
「情報セキュリティポリシー」と呼びます

どんな場面で使う？

使う場面

ISMS（情報セキュリティマネジメントシステム）の構築
社内ルール整備
委託先管理や監査対応

👉 現場では
「ルールが曖昧で属人化している」状態を防ぐために使います

注意が必要な場面

「基本方針に具体的な手順を書く」
「手順書に経営方針を書く」

👉 レベルが混ざるとNG（試験でもよく出る）

よくある誤解・混同

❌ よくある誤解1

基本方針は機密文書で外部に出さない

👉 ⭕ 正しくは
基本方針は社外にも公開されることがある

❌ よくある誤解2

基本方針は一度決めたら変えない

👉 ⭕ 正しくは
環境変化（法改正・技術）に応じて見直す

❌ よくある誤解3

基本方針に具体的な対策を書く

👉 ⭕ 正しくは
具体策は対策基準・手順に書く

SG試験では
👉「それはどの階層の話？」
と切り分けるのが最重要ポイントです

まとめ（試験直前用）

情報セキュリティポリシー＝基本方針＋対策基準＋実施手順
基本方針＝方向性（経営者の宣言）
対策基準＝ルール、実施手順＝やり方
「具体的すぎる」→基本方針ではない
「変更しない」→誤り（環境に応じて見直す）

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

情報セキュリティ教育・訓練とは？人的対策の基本を整理【情報セキュリティマネジメント】

Source: pages\sg\security-training.md
Permalink: /sg/security-training/

まず結論

情報セキュリティ教育・訓練とは「人によるミスや不正を防ぐための対策」
SG試験では「教育で対応すべきか」「技術対策と混同しないか」を判断させる問題がよく出る

直感的な説明

セキュリティ事故の多くは👇

メールの誤送信
パスワードの使い回し
不審メールを開く

👉 つまり「人のミス」

だから👇
👉 人を変える対策が必要

それが教育・訓練です

定義・仕組み

教育・訓練とは

従業員のセキュリティ意識・行動を改善する取り組み

主な内容

教育（知識）

ルールの理解
脅威の理解

訓練（実践）

標的型メール訓練
インシデント対応訓練

👉 「知る」＋「できる」がセット

なぜ重要か

👉 技術対策だけでは防げない

例👇

強いシステムでも
→ パスワードを教えたら終わり

どんな場面で使う？

科目Bの典型パターン

誤送信が多発
フィッシング被害
内部不正

正しい判断例

問題でこう聞かれます👇

「不審メールを開いてしまう」
→ 教育・訓練
「ルールが守られていない」
→ 教育
「操作ミスが多い」
→ 訓練

よくある誤解・混同

❌ よくある誤解

システムを強化すれば解決
マニュアル配布で十分

⭕ 正しい理解

人的対策は必須
教育＋訓練の両方が必要

SG試験のひっかけ

典型パターン👇

「教育すべき場面で技術対策を選ばせる」
「ルール違反なのにシステム対応を選ばせる」

👉 問題の原因を見ることが重要

まとめ（試験直前用）

教育・訓練＝人的リスク対策
教育（知識）＋訓練（実践）がセット
人のミスは技術だけでは防げない
問題は「原因が人か」で判断
「対策の種類ズレ」に注意

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

委託先管理とは？外部委託のリスク対策を整理【情報セキュリティマネジメント】

Source: pages\sg\vendor-management.md
Permalink: /sg/vendor-management/

まず結論

委託先管理とは「外部委託による情報漏えいリスクを管理すること」
SG試験では「委託前・委託中・委託後のどの対策か」を判断させる問題がよく出る

直感的な説明

会社が仕事を外部に任せるとき👇

👉 「自分の会社の情報」を外に出すことになる

つまり👇
👉 委託先が事故を起こしたら、自社の責任になる

だから👇
👉 「任せる前・任せている間・終わった後」すべて管理が必要

定義・仕組み

委託先管理は3段階で考えると理解しやすい👇

① 委託前（選定・契約）

信頼できる会社か確認

例👇

セキュリティ体制の確認
実績の確認
契約で義務を明確化

👉 ここでミスると全部アウト

② 委託中（監督・管理）

任せっぱなしにしない

例👇

定期的な監査
作業状況の確認
アクセス権の制御

👉 「丸投げ」が一番危険

③ 委託後（終了時）

情報を残させない

例👇

データの返却・削除
アカウントの停止

👉 ここ忘れる問題よく出る

どんな場面で使う？

科目Bの典型パターン

システム開発の外注
データ処理の委託
クラウドサービス利用

正しい判断の流れ

問題ではこう見ます👇

委託前の話？
委託中の話？
委託後の話？

👉 フェーズで切る

よくある誤解・混同

❌ よくある誤解

委託したら責任も移る
契約書があればOK

⭕ 正しい理解

責任は委託元に残る
契約＋監督が必要

SG試験のひっかけ

典型パターン👇

「委託したので責任なし」→ ❌
「契約しただけで監督なし」→ ❌
「終了時のデータ削除なし」→ ❌

👉 丸投げは全部NG

まとめ（試験直前用）

委託先管理＝外部委託のリスク管理
3段階（委託前・中・後）で考える
責任は委託元に残る
契約だけでなく監督が必要
「丸投げしていないか」で判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

情報セキュリティ対策

ブラックリストとホワイトリストの違いとは？判断基準を整理【情報セキュリティマネジメント】

Source: pages\sg\blacklist-whitelist.md
Permalink: /sg/blacklist-whitelist/

まず結論

ブラックリストとホワイトリストは「通信を許可・拒否するルールの考え方」であり、SG試験では「何を基準に許可・拒否しているか」を見抜く問題として出題される。

直感的な説明

イメージで考えるとシンプルです。

ブラックリスト
→ ダメな人だけ入れない（基本OK）
ホワイトリスト
→ 許可された人だけ入れる（基本NG）

例えば会社の入館管理で考えると、

ブラックリスト：問題を起こした人だけ入館禁止
ホワイトリスト：社員証を持っている人だけ入館OK

この「どちらを基準にするか」がポイントです。

定義・仕組み

ブラックリストとホワイトリストは、ファイアウォールやWAFなどで使われるアクセス制御の方式です。

ブラックリスト方式

初期状態：すべて許可
「禁止したい対象」を登録
該当するものを遮断

👉 例：

特定のIPアドレス
攻撃パターン（WAFの場合）

ホワイトリスト方式

初期状態：すべて拒否
「許可する対象」を登録
登録されたものだけ通す

👉 例：

特定のIPアドレスのみ許可
特定のURLのみアクセス可能

SG試験ではここが重要です👇

👉 ブラックリスト＝禁止ベース
👉 ホワイトリスト＝許可ベース

どんな場面で使う？

ブラックリストが使われる場面

既知の攻撃を防ぐ（WAF）
スパムメール対策
不正IPの遮断

👉 「とりあえず全部通すが、危険なものだけ止める」

ホワイトリストが使われる場面

社内システムへのアクセス制限
重要システムの通信制御
委託先アクセスの限定

👉 「安全が確認できたものだけ通す」

業務での判断ポイント

セキュリティ重視 → ホワイトリスト
利便性重視 → ブラックリスト

よくある誤解・混同

❌ 「ブラックリスト＝URLやIPのリスト」

→ ⭕ 状況によって対象は変わる

ファイアウォール → IPアドレス
WAF → 通信データ（攻撃パターン）

❌ 「WAFはURLをブロックするもの」

→ ⭕ 通信の中身を見て判断する

SG試験では、

👉 「IPやURLの話になっている選択肢」はミスリードの可能性あり

❌ 「ブラックリストとホワイトリストは同じようなもの」

→ ⭕ 初期状態が逆

ブラックリスト：基本OK → 一部NG
ホワイトリスト：基本NG → 一部OK

まとめ（試験直前用）

ブラックリスト＝禁止対象を登録して遮断（基本OK）
ホワイトリスト＝許可対象のみ通す（基本NG）
何を登録するかは機器によって異なる（IP・URL・パターンなど）
SG試験では「何を基準に制御しているか」を見抜くのが重要

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ボットとは？遠隔操作される仕組みを理解する【情報セキュリティマネジメント】

Source: pages\sg\bot.md
Permalink: /sg/bot/

まず結論

ボットとは、外部から遠隔操作されるマルウェアであり、感染端末を攻撃に利用する仕組みで、SG試験では「誰が操作しているか」「何に使われるか」を見抜くことが重要です。

直感的な説明

ボットは「知らないうちに操られるパソコン」です。

たとえば

自分のPCが勝手に大量の通信を送る
気づかないうちに攻撃の加害者になる

といった状態になります。

イメージとしては、
操作者（攻撃者）→指示を出すサーバ→乗っ取られたPC群→攻撃対象
という流れです。

定義・仕組み

ボットは、感染すると外部からの命令で動くようになります。

基本構成（試験でよく出る）

ボットハーダー（攻撃者）
- ボットを操作する人
C&Cサーバ（Command and Control）
- ボットに命令を送るサーバ
ボット（感染端末）
- 指示に従って動くコンピュータ
ボットネット
- 複数のボットが連携したネットワーク

何をするのか

DDoS攻撃（大量アクセス）
スパムメール送信
情報収集（個人情報など）
不正アクセスの踏み台

SG試験では、
「1台ではなく多数で攻撃する」点が重要な特徴です。

どんな場面で使う？

使うべき場面（試験・実務）

DDoS攻撃の原因を考えるとき
不審な大量通信の原因分析
セキュリティ対策（EDR・監視など）

間違えやすい場面

単体のウイルスと混同する
→ ボットは「遠隔操作＋ネットワーク連携」がポイント

よくある誤解・混同

① ボットとウイルスの混同

❌ ボット＝ウイルスの一種
⭕ ボットは遠隔操作される仕組みが本質

👉 増殖より「操作される」が重要

② ボットネットの誤解

❌ ボットネット＝サーバ
⭕ ボットネット＝感染した端末の集まり

👉 C&Cサーバとは別物

③ 攻撃者との関係

❌ ボットが自動で攻撃する
⭕ 攻撃者がC&Cサーバ経由で指示する

👉 「誰が操作しているか」を意識

SG試験での典型パターン

「遠隔操作される」かどうか
「複数端末で攻撃する」かどうか
「C&Cサーバの存在」

選択肢で
「自己増殖」や「ファイル感染」と書いてあれば
→ ボットではない可能性が高い

まとめ（試験直前用）

ボット＝遠隔操作されるマルウェア
C&Cサーバが命令を出す
ボットネット＝感染端末の集合
主な用途はDDoS・スパム・踏み台
判断基準は「遠隔操作・複数端末・指令サーバ」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ブルートフォース攻撃とは？総当たり攻撃の仕組みと対策【情報セキュリティマネジメント】

Source: pages\sg\brute-force-attack.md
Permalink: /sg/brute-force-attack/

まず結論

ブルートフォース攻撃とは、IDとパスワードの組み合わせを総当たりで試して認証を突破する攻撃であり、SG試験では「どの認証対策が有効か」を判断させる問題として出題される。

直感的な説明

ブルートフォース攻撃は、

👉「鍵を1つずつ試して開ける」

イメージです。

例えば、

0000 → 0001 → 0002 … と順番に試す
👉 いつか正解に当たる

👉 シンプルだけど確実な攻撃です。

定義・仕組み

ブルートフォース攻撃（総当たり攻撃）は、

👉 考えられるすべてのパスワードを試すことで
👉 正しい認証情報を見つける攻撃です。

攻撃の特徴

技術的に高度ではない
時間をかければ成功する可能性がある
パスワードが短い・単純だと危険

どんな場面で使う？

攻撃される場面

ログイン認証（ID・パスワード）
Webサービス
社内システム

防ぐ場面（対策）

アカウントロック（一定回数失敗で停止）
多要素認証（MFA）
パスワードの複雑化・長文化
ログイン試行の制限（レート制限）

SG試験での考え方

👉 「試行回数を制限できているか？」

無制限 → 危険
制限あり → 有効な対策

よくある誤解・混同

❌ 誤解①：特殊な技術攻撃

👉 ⭕ 実際は

単純な試行の繰り返し

❌ 誤解②：パスワードが漏れている攻撃

👉 ⭕ 違う

推測して当てる攻撃

（漏えいはリスト型攻撃）

❌ 誤解③：1回で成功する攻撃

👉 ⭕ 違う

何度も試すことが前提

SG試験のひっかけポイント

「パスワードの暗号化」で防げるとする選択肢
→ ❌ 不十分

👉 正しくは

試行回数の制限や多要素認証

まとめ（試験直前用）

ブルートフォース攻撃＝「総当たりでパスワードを試す」
シンプルだが確実な攻撃
対策は
👉 試行回数制限＋多要素認証
試験では
👉 「推測型か漏えい型か」で切り分ける

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

よく出るポート番号とは？試験での見分け方を整理【SG試験】

Source: pages\sg\common-port-numbers.md
Permalink: /sg/common-port-numbers/

まず結論

よく出るポート番号とは、ネットワーク通信でサービスごとに決まっている番号のうち、SG試験で頻出のもの（HTTPやSMTPなど）です。
SG試験では、単なる暗記ではなく、どのサービスの通信かを見抜いて選択肢を切れるかが問われます。

直感的な説明

ポート番号は、サーバの中にある「受付窓口」の番号のようなものです。
同じサーバでも、Webを見るのか、メールを送るのかで、入る場所が違います。

たとえば、

Webページを見る → HTTP（80番）
メールを送る → SMTP（25番）

というように、「何をしたいか」で入口が決まっています。

SG試験では、この入口を見て
「この通信は正しいか？」
「違うサービスと混ざっていないか？」
を判断させてきます。

定義・仕組み

ポート番号とは、TCPやUDP通信で、どのアプリケーションにデータを渡すかを識別する番号です。

代表的なポート番号は次のとおりです。

プロトコル	役割	ポート番号
HTTP	Web通信	80
HTTPS	暗号化されたWeb通信	443
SMTP	メール送信	25
POP3	メール受信	110
IMAP	メール受信	143
DNS	名前解決	53

SG試験ではすべてを覚える必要はありませんが、
HTTP・HTTPS・SMTP・POP3・DNSあたりは特に頻出です。

また、通信の基本ルールも重要です。

サーバ側：固定のポート番号（上の表）
クライアント側：1024以上の動的ポート

この仕組みを理解していると、選択肢の正誤を判断しやすくなります。

どんな場面で使う？

ファイアウォール設定の判断

業務では、必要な通信だけを通すために、ポート番号を指定して制御します。
たとえば、

Web閲覧を許可 → 80番・443番を許可
メール送信を許可 → 25番を許可

というように使います。

SG試験では、
「どのポートを許可すべきか」
という形で問われることが多いです。

通信の正誤判断

試験では、通信の表や図が出てきて、
「この通信は正しいか？」
と問われることがあります。

そのとき、ポート番号を見て、

HTTPなのに25番 → おかしい
SMTPなのに110番 → おかしい

と判断できることが重要です。

使うと誤解しやすい場面

ポート番号だけを暗記していると、
送信元とあて先の区別がつかなくなることがあります。

SG試験では、
送信元ポートとあて先ポートを入れ替えたひっかけ
がよく出るので注意が必要です。

よくある誤解・混同

SMTPとPOP3の混同

メール関連で最も多いひっかけです。

SMTP：送信（25）
POP3：受信（110）

選択肢では、SMTPなのに110番が書かれていたら誤りです。

HTTPとHTTPSの混同

HTTP：80
HTTPS：443

「暗号化されている」と書かれていたらHTTPS（443）です。
ここもSG試験ではよく問われます。

DNSの扱いの誤解

DNSは53番ですが、
TCPとUDPの両方で使われることがあります。

SG試験では細かいプロトコルよりも、
名前解決＝53番 と覚えておけば十分です。

クライアントも固定ポートを使うという誤解

初心者がよく混同するポイントです。

サーバ：固定ポート（80や25など）
クライアント：1024以上の動的ポート

この区別ができないと、選択肢を正しく切れません。

まとめ（試験直前用）

よく出るポート番号は、サービスごとに決まった通信の入口です。
SG試験では、HTTP（80）、HTTPS（443）、SMTP（25）、POP3（110）、DNS（53）を押さえることが重要です。
選択肢では、サービスとポート番号の不一致、送信元とあて先の入れ替え、SMTPとPOP3の混同に注意します。
迷ったら、サーバは固定ポート、PCは1024以上というルールで判断すると切りやすくなります。

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

クリプトジャッキングとは？不正マイニングの仕組みを理解する【情報セキュリティマネジメント】

Source: pages\sg\cryptojacking.md
Permalink: /sg/cryptojacking/

まず結論

クリプトジャッキングとは、利用者のPCやサーバの計算資源を無断で使い、仮想通貨のマイニングを行う不正行為（マルウェア）であり、SG試験では「資源の不正利用」と「気づきにくさ」を見抜くことが重要です。

直感的な説明

クリプトジャッキングは「勝手にパソコンを働かせてお金を稼ぐ攻撃」です。

たとえば

PCが急に重くなる
CPU使用率が高い状態が続く
ファンが回りっぱなし

といった状態になります。

👉 自分のPCが“こっそり働かされている”状態です

定義・仕組み

クリプトジャッキングは、マルウェアなどを使って端末の計算能力を奪います。

基本の流れ

マルウェア感染 or Webスクリプト実行
マイニングプログラムが起動
CPU・GPUを使って計算処理
仮想通貨が攻撃者に送られる

マイニングとは（試験用に簡潔）

仮想通貨の取引を成立させるための計算処理
計算の報酬として仮想通貨が得られる

👉 本来は自分の機器で行うもの

特徴

データ破壊はしない（気づきにくい）
長時間にわたり資源を消費
複数端末で行われることもある

SG試験では、
「情報を盗むわけでも壊すわけでもない」点が重要な特徴です。

どんな場面で使う？

使うべき場面（試験・実務）

PCが異常に重い原因の分析
サーバ負荷の異常検知
不審なプロセスの調査

間違えやすい場面

マルウェア＝情報漏えいと思い込む
→ クリプトジャッキングは「資源の悪用」

よくある誤解・混同

① ランサムウェアとの違い

❌ 仮想通貨＝身代金要求
⭕ クリプトジャッキングは勝手に稼ぐ、ランサムウェアは要求する

② スパイウェアとの違い

❌ 情報を盗む攻撃
⭕ 目的は情報ではなく計算資源

③ ボットとの関係

❌ 無関係
⭕ ボットネットを使って大規模に行われることがある

SG試験での典型パターン

「CPU使用率が異常に高い」
「端末の動作が遅くなる」
「仮想通貨のマイニング」

選択肢で
「データを暗号化」や「情報を送信」とあれば
→ 別のマルウェアであり誤り

まとめ（試験直前用）

クリプトジャッキング＝計算資源の不正利用
仮想通貨マイニングに使われる
データ破壊や情報漏えいは目的ではない
気づきにくく長期間続く
判断基準は「CPUなど資源を勝手に使うか」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

CRYPTRECとは？暗号の安全性評価の役割を理解する【情報セキュリティマネジメント】

Source: pages\sg\cryptrec.md
Permalink: /sg/cryptrec/

まず結論

CRYPTRECは、安全な暗号技術を評価・推奨する日本のプロジェクトである。
SG試験では「暗号の評価」か「インシデント対応（JPCERT/CC）」かを見分ける問題が多い。

直感的な説明

会社でシステムを作るとき、

どの暗号を使えば安全か？
古い暗号は危険じゃないか？

と迷いますよね。

CRYPTRECは、
「この暗号は安全に使えるよ」とお墨付きを出す専門チームです。

👉 イメージ

CRYPTREC：暗号の品質チェック担当
JPCERT/CC：事故対応担当

定義・仕組み

CRYPTREC（Cryptography Research and Evaluation Committees）は、

電子政府などで利用する暗号の
- 安全性評価
- 推奨リストの作成
  を行うプロジェクトです。

主な役割

暗号アルゴリズムの安全性評価
推奨暗号リストの作成・公開
暗号技術の運用指針の検討

運営

総務省・経済産業省が中心となって運営

ポイント

暗号の安全性を評価するのが役割
実際のインシデント対応はしない
電子政府で使う暗号の基準になる

SG試験では
「暗号の評価」＝CRYPTREC
と覚えると判断しやすくなります。

どんな場面で使う？

使う場面（正しい理解）

システムで使用する暗号方式を選定するとき
安全な暗号を採用する基準を決めるとき
電子政府や重要システムの設計

使うと誤解しやすい場面

❌ インシデント対応（それはJPCERT/CC）
❌ 社内のセキュリティ運用（それはCSIRTやISMS）

よくある誤解・混同

① JPCERT/CCとの違い

JPCERT/CC：インシデント対応支援
CRYPTREC：暗号の安全性評価

👉 SG試験ではここをよく混同させてくる

② CSIRTとの違い

CSIRT：組織内での対応チーム
CRYPTREC：技術評価（暗号）

👉 「対応するか？評価するか？」で切る

③ SG試験のひっかけ

SG試験では次のような表現に注意：

「インシデント対応」「報告受付」→×
「暗号技術の評価・推奨」→○

👉 選択肢では
“暗号”というキーワードがあるかをチェック

まとめ（試験直前用）

CRYPTREC＝暗号の安全性評価・推奨プロジェクト
総務省・経産省が中心
選択肢では
- 「インシデント対応」→×
- 「組織内対応」→×
- 「暗号の評価・推奨」→○

👉 「暗号か？インシデントか？」で切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

サイバーキルチェーンとは？攻撃の流れから対策を考える【情報セキュリティマネジメント】

Source: pages\sg\cyber-kill-chain.md
Permalink: /sg/cyber-kill-chain/

まず結論

サイバーキルチェーンとは、攻撃の流れを段階（フェーズ）に分けて整理し、どこで攻撃を止めるかを考えるフレームワークであり、SG試験では「各段階に対応する対策を選べるか」が問われる。

直感的な説明

サイバーキルチェーンは、

👉「攻撃は1回ではなく、段階的に進む」
👉「どこか1つでも止めれば被害を防げる」

という考え方です。

イメージとしては、

下見
準備
侵入
操作
目的達成

という流れを分解して見える化したものです。

定義・仕組み

サイバーキルチェーンは、標的型攻撃の流れを次の7段階で表します。

偵察（Reconnaissance）
- 標的の情報収集（組織・社員・システム）
武器化（Weaponization）
- 攻撃用マルウェアやファイルを作成
配送（Delivery）
- メールやWebで攻撃を送り込む
攻撃（Exploitation）
- 脆弱性を突いて侵入
インストール（Installation）
- マルウェアを定着させる
C&C（Command & Control）
- 外部から遠隔操作できる状態にする
目的の実行（Actions on Objectives）
- 情報窃取や破壊などを実行

重要なポイント

👉 どの段階でも止められれば攻撃は成立しない

どんな場面で使う？

使う場面

セキュリティ対策の設計
インシデント対応（どの段階かの特定）
ログ分析・監視

SG試験での考え方

各段階に対応する対策を結びつけることが重要です。

フェーズ	対策例
偵察	公開情報の管理
配送	メールフィルタ
攻撃	パッチ適用
インストール	ウイルス対策
C&C	通信監視
実行	権限制御・ログ監視

👉 「どの段階を防ぐ対策か」で判断する

よくある誤解・混同

❌ 誤解①：侵入防止だけが重要

👉 ⭕ 実際は

検知
被害抑止
も同じくらい重要

❌ 誤解②：1つの対策で防げる

👉 ⭕ サイバーキルチェーンは

複数の段階に対策を配置する前提

❌ 誤解③：攻撃は一瞬で起こる

👉 ⭕ 実際は

段階的に進行するため
👉 途中で気づいて止めることができる

SG試験のひっかけポイント

「どのフェーズの対策か」を問う問題
似た対策（例：認証 vs 通信監視）を混同させる

👉 フェーズと対策の対応を意識する

まとめ（試験直前用）

サイバーキルチェーン＝攻撃を7段階に分解した考え方
重要なのは
👉 「どこで止めるか」
対策は
👉 防止・検知・被害抑止を組み合わせる
試験では
👉 「この対策はどのフェーズか」で判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

DDoS攻撃とは？サービス停止を狙う攻撃の仕組み【情報セキュリティマネジメント】

Source: pages\sg\ddos.md
Permalink: /sg/ddos/

まず結論

DDoS攻撃とは、多数の端末から大量の通信を送りつけてサーバを過負荷にし、サービスを停止させる攻撃です。
SG試験では「情報を盗むのではなく、使えなくする攻撃かどうか」を見抜けるかが問われます。

直感的な説明

人気サイトに一気に何万人もアクセスしたら、サーバが重くなって落ちますよね。

それをわざと大量のアクセスで起こすのがDDoS攻撃です。

👉 「壊す」のではなく「使えなくする」攻撃

定義・仕組み

DDoS（Distributed Denial of Service）攻撃は、複数の端末（ボットなど）から標的サーバに大量の通信を送りつけ、サービス提供を妨害する攻撃です。

基本の流れ

攻撃者が多数の端末（ボット）を用意
一斉に標的サーバへリクエスト送信
サーバが処理しきれなくなる
正常ユーザーが利用できなくなる

👉 分散（Distributed）しているのがポイント

どんな場面で使う？

よくある目的

Webサイトの停止（ECサイト、企業サイトなど）
サービス妨害による信用低下
他の攻撃の目くらまし

業務でのポイント

可用性（Availability）への影響が大きい
負荷分散やWAFなどの対策が重要
監視と迅速な対応体制が必要

👉 CIAの「A（可用性）」を狙う攻撃

よくある誤解・混同

❌ フィッシングとの違い

フィッシング：情報を盗む
DDoS：サービスを止める

👉 盗取か停止かで判断

❌ DoS攻撃との違い

DoS：1つの端末から攻撃
DDoS：複数の端末から分散攻撃

👉 規模と分散性が違う

❌ マルウェアとの関係

マルウェア：端末を感染させる
DDoS：その端末を使って攻撃することがある

👉 ボットネットとして利用される点に注意

SG試験でのひっかけ

「大量アクセス」「サーバ過負荷」「サービス停止」
→ DDoS攻撃
「情報を盗む」なら別の攻撃（フィッシングなど）

まとめ（試験直前用）

DDoS＝大量通信でサービス停止
情報漏えいではなく可用性低下が目的
DoSとの違いは「分散」
「大量アクセス」「停止」がキーワードなら即判断

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

辞書攻撃とは？効率的なパスワード破解の仕組み【情報セキュリティマネジメント】

Source: pages\sg\dictionary-attack.md
Permalink: /sg/dictionary-attack/

まず結論

辞書攻撃とは、よく使われる単語やパスワードをまとめたリスト（辞書）を使って認証を突破する攻撃であり、SG試験では「ブルートフォースとの違い」と「なぜ効率が良いか」を判断させる問題として出題される。

直感的な説明

ブルートフォース攻撃は「全部試す」ですが、

辞書攻撃は 👉「当たりそうなものだけ試す」攻撃です。

例えば、

password
123456
qwerty

👉 よく使われるパスワードを優先的に試します。

定義・仕組み

辞書攻撃は、

👉 あらかじめ用意された「パスワードリスト（辞書）」を使って
👉 順番に試行することで認証突破を狙う攻撃です。

なぜ効率が良いか

多くのユーザが似たようなパスワードを使う
総当たりより試行回数が少ない

👉 短時間で成功する可能性が高い

ブルートフォースとの違い

攻撃	特徴
ブルートフォース	すべての組み合わせを試す
辞書攻撃	よく使われるものだけ試す

どんな場面で使う？

攻撃される場面

Webサービスのログイン
社内システム
パスワードが単純な環境

防ぐ場面（対策）

パスワードの複雑化（長さ・記号）
多要素認証（MFA）
パスワードの使い回し禁止
ログイン試行の制限

SG試験での考え方

👉 「なぜ効率が良いのか？」

人は単純なパスワードを使いがち
👉 そこを狙っている

よくある誤解・混同

❌ 誤解①：ブルートフォースと同じ

👉 ⭕ 違う

総当たりか
優先的試行か

❌ 誤解②：パスワードが漏えいしている

👉 ⭕ 違う

推測して試す攻撃

（漏えいはリスト型攻撃）

❌ 誤解③：時間がかかる攻撃

👉 ⭕ むしろ効率的

少ない試行で成功しやすい

SG試験のひっかけポイント

「辞書攻撃＝総当たり」とする選択肢
→ ❌ 誤り

👉 正しくは

優先順位をつけて試す攻撃

まとめ（試験直前用）

辞書攻撃＝「よく使われるパスワードを優先して試す」
総当たりより効率が良い
対策は
👉 複雑なパスワード＋MFA
試験では
👉 「総当たりか効率型か」で切り分ける

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

DNSキャッシュポイズニングとは？偽サイトへ誘導する攻撃【情報セキュリティマネジメント】

Source: pages\sg\dns-cache-poisoning.md
Permalink: /sg/dns-cache-poisoning/

まず結論

DNSキャッシュポイズニングは、DNSサーバの情報を書き換えて正規サイトの代わりに偽サイトへ誘導する攻撃
SG試験では「通信前の行き先を書き換える攻撃」として判断できるかが問われる

直感的な説明

普段は「銀行のURL」を入力すると、正しい銀行サイトに接続されます。

しかしこの攻撃では、

見た目は同じURLなのに
裏側の案内（住所）が書き換えられていて、偽サイトに連れていかれる

イメージとしては、
「正しい住所を書いたのに、案内板が勝手に書き換えられて別の場所に誘導される」感じです。

定義・仕組み

DNSキャッシュポイズニングは、DNSサーバのキャッシュ情報を不正に書き換える攻撃です。

流れはシンプルです。

DNSサーバに不正な情報を登録させる
正規サイトのドメインに対して
攻撃者のサーバのIPアドレスを返すようにする
利用者は気づかず偽サイトへ接続する

ポイントはここです：

ユーザのPCではなく
DNSサーバ側がだまされている

そのため、利用者は正しいURLを入力しても被害に遭います。

どんな場面で使う？

使われる場面

インターネットバンキング
ECサイト
ログインページ全般

→ ID・パスワードを入力させたい場面で使われる

注意すべき場面（誤解しやすい）

ブラウザ内で改ざんするわけではない
メールで誘導するわけでもない

SG試験では
「どこで操作が行われているか（DNSか、ブラウザか）」が重要

よくある誤解・混同

フィッシングとの違い

フィッシング：メールなどで偽サイトに誘導
DNSポイズニング：正しいURLでも偽サイトに行く

👉 「メール」「URLリンク」が出てきたらフィッシング

Man-in-the-Browserとの違い

MITB：ブラウザ内で改ざん
DNS：接続先そのものを変える

👉 「マルウェアがブラウザ内で改ざん」はMITB

Man-in-the-Middleとの違い

MITM：通信途中で盗聴・改ざん
DNS：接続前に行き先を変える

👉 「中継」「盗聴」があればMITM

まとめ（試験直前用）

DNSポイズニング＝行き先（IPアドレス）を書き換える攻撃
正しいURLでも偽サイトに誘導される
フィッシング：メール誘導
MITB：ブラウザ内改ざん
MITM：通信途中で改ざん
「DNSキャッシュを書き換える」とあれば正解

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ドメイン名ハイジャックとは？DNSを悪用したなりすましの仕組み【情報セキュリティマネジメント】

Source: pages\sg\domain-hijacking.md
Permalink: /sg/domain-hijacking/

まず結論

ドメイン名ハイジャックとは、DNS情報を書き換えて正規のWebサイトを偽サイトにすり替える攻撃であり、SG試験では「DNSの改ざんによるなりすまし」と「どの対策が有効か」を判断させる問題として出題される。

直感的な説明

ドメイン名ハイジャックは、

👉「住所録を書き換えて、別の場所に案内する」

攻撃です。

例えば、

「銀行のサイトにアクセスしたつもり」でも
👉 実際は攻撃者の偽サイトに接続される

👉 見た目が同じなので気づきにくいのが特徴です。

定義・仕組み

ドメイン名ハイジャックは、DNSの仕組みを悪用します。

通常：

google.com → 正しいIPアドレス

攻撃時：

google.com → 攻撃者のIPアドレス

攻撃の流れ

DNSサーバの情報を書き換える
ユーザが通常通りURLを入力
偽のIPアドレスが返る
偽サイトに誘導される

👉 ユーザは気づかず情報を入力してしまう

どんな場面で使う？

攻撃される場面

DNSサーバの設定が弱い場合
キャッシュの管理が不十分な場合
ドメイン管理が不適切な場合

防ぐ場面（対策）

DNSSEC（DNSの正当性確認）
ドメイン管理の厳格化
HTTPS証明書の確認

SG試験での考え方

👉 「どこが改ざんされているか」

通信内容 → 変わっていない
接続先 → 変わっている（ここがポイント）

よくある誤解・混同

❌ 誤解①：中間者攻撃と同じ

👉 ⭕ 似ているが違う

中間者攻撃：通信の途中に割り込む
ドメイン名ハイジャック：最初から偽サイトに誘導

❌ 誤解②：IPスプーフィングと同じ

👉 ⭕ 違う

IPスプーフィング：送信元を偽装
ドメイン名ハイジャック：行き先を偽装

❌ 誤解③：ウイルス感染が必要

👉 ⭕ 不要

DNSを書き換えるだけで成立

SG試験のひっかけポイント

「通信を盗聴する攻撃」とする選択肢
→ ❌ 不正確

👉 正しくは

接続先を偽装する攻撃

まとめ（試験直前用）

ドメイン名ハイジャック＝「DNSを書き換えて偽サイトへ誘導」
特徴は
👉 見た目では気づきにくい
対策は
👉 DNSの正当性確認＋証明書確認
試験では
👉 「通信途中か／接続先か」で切り分ける

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ハニーポットとは？攻撃者をおびき寄せる仕組み【情報セキュリティマネジメント】

Source: pages\sg\honeypot.md
Permalink: /sg/honeypot/

まず結論

ハニーポットとは、攻撃者をおびき寄せて行動を監視・分析するための仕組みです。
SG試験では「攻撃を防ぐのではなく観察する目的かどうか」を判断できるかがポイントです。

直感的な説明

ハニーポットは「おとり」です。

泥棒を捕まえるために、わざと魅力的な家を用意して監視するイメージです。
攻撃者にとって「入りやすそう」に見えるシステムを用意して、
そこでの行動を観察します。

👉 ポイントは
「守る」ではなく「誘う」です。

定義・仕組み

ハニーポットとは、

攻撃者を意図的に誘導し、その行動や手口を記録・分析する仕組み

です。

主な目的：

攻撃手法の把握
不正アクセスの検知
インシデント対応の強化

基本的な流れ：

本物そっくりのシステムを用意
攻撃者を誘導する
アクセスや操作を記録・分析する

👉 実際の業務では
「新しい攻撃手法の情報収集」や「早期検知」に役立ちます。

どんな場面で使う？

使うべき場面

不正アクセスの傾向を把握したいとき
攻撃手法を分析したいとき
セキュリティ監視の強化

誤解しやすい場面

攻撃を防ぐ仕組みとして使う
→ ハニーポットは防御ではなく観測・分析です

よくある誤解・混同

❌ よくある誤解

「攻撃を遮断する仕組み」
「プログラムの影響を制限する仕組み」

⭕ 正しい理解

攻撃者を誘導して行動を監視する仕組み

SG試験でのひっかけ

SG試験では次のように混同させてきます。

「通信の中身を見て遮断」
　→ WAF
「実行範囲を制限する」
　→ サンドボックス
「攻撃者を誘導して監視する」
　→ ハニーポット（これが正解）

👉 選択肢では
「おびき寄せる」「監視する」と書かれていたらハニーポットです。

まとめ（試験直前用）

ハニーポット＝攻撃者を誘導して監視する仕組み
目的は防御ではなく分析・検知
「おとり」「監視」「行動分析」がキーワード
SG試験では
→ WAF・サンドボックスとの違いで出題されやすい

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

IPスプーフィングとは？送信元偽装の仕組みと対策【情報セキュリティマネジメント】

Source: pages\sg\ip-spoofing.md
Permalink: /sg/ip-spoofing/

まず結論

IPスプーフィングとは、送信元のIPアドレスを偽装して通信する攻撃であり、SG試験では「なりすましの種類」と「防御できる仕組み」を判断させる問題として出題される。

直感的な説明

IPアドレスは「通信の送り主の住所」です。

IPスプーフィングは、 👉「差出人の住所を偽る」攻撃です。

例えば、

本当は攻撃者なのに
👉 正規サーバや信頼できる機器になりすます

👉 受け取る側は「信頼できる相手」と勘違いします。

定義・仕組み

IPスプーフィングは、IPパケットの送信元アドレスを書き換えることで成立します。

攻撃の流れ

攻撃者が送信元IPを偽装
サーバに通信を送る
サーバは正規の相手と誤認
不正な通信が成立する

主な利用目的

アクセス制御の回避（IP制限の突破）
DDoS攻撃の隠蔽（発信元の特定を困難にする）
他の攻撃（中間者攻撃など）の補助

どんな場面で使う？

攻撃される場面

IPアドレスだけで認証しているシステム
ネットワーク内部を信頼しすぎている環境

防ぐ場面（対策）

パケットフィルタリング（不正なIPの遮断）
認証の強化（IPだけに依存しない）
侵入検知システム（IDS/IPS）

SG試験での考え方

👉 「IPアドレス＝本人確認ではない」

IPは簡単に偽装できる
👉 認証としては不十分

よくある誤解・混同

❌ 誤解①：通信内容を盗む攻撃

👉 ⭕ 違う

IPスプーフィングは「なりすまし」

（盗聴は中間者攻撃）

❌ 誤解②：DNSの問題

👉 ⭕ 違う

DNS：名前→IP変換
IPスプーフィング：送信元の偽装

❌ 誤解③：これだけで侵入できる

👉 ⭕ 単独では難しい

他の攻撃と組み合わせて使われることが多い

SG試験のひっかけポイント

「IP制限をしていれば安全」とする選択肢
→ ❌ 不十分

👉 正しくは

IPだけに依存しない認証が必要

まとめ（試験直前用）

IPスプーフィング＝「送信元IPの偽装」
目的は
👉 なりすまし・追跡回避
IPは認証として弱い
試験では
👉 「なりすましか盗聴か」で切り分ける

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

キーロガーとは？入力情報を盗む仕組みを理解する【情報セキュリティマネジメント】

Source: pages\sg\keylogger.md
Permalink: /sg/keylogger/

まず結論

キーロガーとは、キーボード入力を記録し、IDやパスワードなどの情報を盗むマルウェア（または仕組み）であり、SG試験では「認証情報の漏えい原因」として判断できることが重要です。

直感的な説明

キーロガーは「入力内容を盗み見する装置」です。

たとえば

ログインID・パスワードを入力する
その内容がそのまま記録・送信される

というように、ユーザーが入力した情報がそのまま盗まれるのが特徴です。

見た目では気づきにくく、
「普通に使っているだけで情報が漏れる」のが怖いポイントです。

定義・仕組み

キーロガーは、キーボード入力を監視し、その情報を記録・送信します。

動作の流れ

端末にキーロガーが仕込まれる
ユーザーがキーボード入力を行う
入力内容が記録される
外部へ送信される

種類

ソフトウェア型
- マルウェアとして動作（スパイウェアの一種）
ハードウェア型
- キーボードとPCの間に装着される装置

特徴

認証情報（ID・パスワード）を狙う
気づかれにくい
不正ログインの原因になる

SG試験では、
「入力情報が漏えいする原因」＝キーロガーと判断できるかがポイントです。

どんな場面で使う？

使うべき場面（試験・実務）

不正ログインの原因分析
情報漏えいの調査
認証強化（多要素認証など）の検討

間違えやすい場面

通信盗聴と混同
→ キーロガーは「端末内で入力を記録」

よくある誤解・混同

① スパイウェアとの関係

❌ キーロガーは別の攻撃
⭕ キーロガーはスパイウェアの一種

② フィッシングとの違い

❌ ID・パスワードが盗まれる＝同じ
⭕ フィッシングはだまして入力させる、キーロガーは入力を盗む

③ 通信盗聴との違い

❌ ネットワークで盗まれる
⭕ 端末内で入力時に記録される

SG試験での典型パターン

「キーボード入力が記録される」
「ID・パスワードが漏えい」
「不正ログインの原因」

選択肢で
「偽サイトに誘導」とあれば
→ フィッシングであり誤り

まとめ（試験直前用）

キーロガー＝キーボード入力を記録する仕組み
ID・パスワード漏えいの原因になる
スパイウェアの一種
ハードウェア型もある
判断基準は「入力時に盗まれるかどうか」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

マクロウイルスとは？Officeファイル経由の感染を理解する【情報セキュリティマネジメント】

Source: pages\sg\macro-virus.md
Permalink: /sg/macro-virus/

まず結論

マクロウイルスとは、WordやExcelなどのマクロ機能を悪用して感染・拡散するウイルスであり、SG試験では「ファイルを開くことで感染する点」を見抜くことが重要です。

直感的な説明

マクロウイルスは「便利機能に見せかけた危険な仕組み」です。

たとえば

「このExcelを開いてください」とメールで送られる
開いた瞬間にマクロが動いて感染

というように、ユーザーの操作（開く）をきっかけに感染するのが特徴です。

業務でもよく使うOfficeファイルが入口になるため、
気づきにくく、広がりやすいのがポイントです。

定義・仕組み

マクロウイルスは、アプリケーションのマクロ機能を利用して動作します。

マクロとは

WordやExcelにある自動処理機能（VBAなど）
作業を効率化するための仕組み

👉 これを悪用したのがマクロウイルス

感染の流れ

メールやダウンロードでファイルを受け取る
ファイルを開く
マクロが実行される
ウイルスが動作・感染拡大

特徴

ファイルに埋め込まれる（宿主あり）
自己増殖する場合がある
Officeファイル経由で広がる

SG試験では、
「マクロを実行させること」が感染のトリガーになる点が重要です。

どんな場面で使う？

使うべき場面（試験・実務）

メールの添付ファイル対策
社内でのセキュリティ教育（マクロ無効化など）
Officeファイルの安全確認

間違えやすい場面

すべてのウイルスが自動感染すると思う
→ マクロウイルスは「開く＋実行」が必要

よくある誤解・混同

① 通常のウイルスとの違い

❌ すべてのウイルスは同じ感染方法
⭕ マクロウイルスは「ファイル＋マクロ実行」が条件

② ワームとの混同

❌ マクロウイルスもネットワークで勝手に広がる
⭕ ユーザー操作が必要（開く・許可する）

③ マクロ＝危険という誤解

❌ マクロは全部危険
⭕ マクロ自体は便利な機能で、悪用されると危険

SG試験での典型パターン

「メール添付のOfficeファイル」
「マクロを有効にする操作」
「開いたことで感染」

選択肢で
「ネットワーク経由で自動増殖」とあれば
→ ワームの可能性が高い

まとめ（試験直前用）

マクロウイルス＝マクロ機能を悪用したウイルス
Officeファイルに埋め込まれる
感染には「開く＋マクロ実行」が必要
ワームとの違いは「自動拡散しない」点
判断基準は「マクロ実行がトリガーかどうか」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

マルウェアとは？種類と見分け方を整理【情報セキュリティマネジメント】

Source: pages\sg\malware.md
Permalink: /sg/malware/

まず結論

マルウェアとは、利用者の意図しない不正な動作を行う悪意あるソフトウェアの総称であり、SG試験では「どの種類か」「どう広がるか」を見抜くことが問われます。

直感的な説明

マルウェアは「見た目は普通だけど、中身が危険なアプリ」です。

たとえば

添付ファイルを開いたら勝手に情報が送信される
無料ソフトだと思ったら裏で不正通信している

といったように、気づかないうちに被害が広がるのが特徴です。

業務でも、

メール添付
USBメモリ
Webダウンロード
など、日常的な操作が感染のきっかけになります。

定義・仕組み

マルウェアは、感染方法や動き方で分類されます。

代表的な種類（試験頻出）

コンピュータウイルス
- 自己増殖あり
- 他のファイルに寄生して広がる（宿主が必要）
ワーム
- 自己増殖あり
- 単体でネットワークを通じて広がる（宿主不要）
トロイの木馬
- 自己増殖なし
- 正常なソフトを装って侵入し、不正動作を行う

その他よく出るもの

ランサムウェア：データを暗号化して身代金要求
スパイウェア：情報をこっそり収集
キーロガー：キーボード入力を記録
ルートキット：侵入後の痕跡を隠す
ボット：遠隔操作される端末（ボットネットの一部）

感染経路

メール添付
Webサイト閲覧
外部メディア（USBなど）
不正なダウンロード

SG試験では、
「どうやって侵入し、どう広がるか」までセットで理解することが重要です。

どんな場面で使う？

使うべき場面（試験・実務）

セキュリティ対策の検討（ウイルス対策ソフト、教育など）
インシデント対応（感染の特定・拡大防止）
リスクアセスメント（どの脅威が現実的か）

間違えやすい場面

すべての不正アクセスを「マルウェア」と思う
→ 設定ミスや人的ミスもあるので区別が必要

よくある誤解・混同

① ウイルスとワームの混同

❌ ウイルスもワームも同じ
⭕ ウイルスは宿主が必要、ワームは単独で広がる

👉 SG試験ではここをよく問われます

② トロイの木馬の誤解

❌ 自己増殖する
⭕ 増殖しないが、だまして侵入する

👉 「増えない＝安全」ではないので注意

③ マルウェア＝ウイルスだけと思う

❌ マルウェア＝ウイルス
⭕ マルウェアは総称（ワーム・ランサムウェアなど含む）

👉 選択肢で「マルウェア＝ウイルス」と書いてあれば誤り

SG試験での典型パターン

「自己増殖するかどうか」
「宿主が必要かどうか」
「だまして侵入するか」

この3つで切り分けられるようにするのがポイントです。

まとめ（試験直前用）

マルウェア＝不正動作をするソフトの総称
ウイルス：宿主あり＋増殖する
ワーム：宿主なし＋増殖する
トロイの木馬：増殖しない＋だまして侵入
判断基準は「増えるか・宿主が必要か・侵入方法」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

Man-in-the-Browserとは？ブラウザ内改ざん攻撃の仕組み【情報セキュリティマネジメント】

Source: pages\sg\man-in-the-browser.md
Permalink: /sg/man-in-the-browser/

まず結論

Man-in-the-Browser（MITB）は、PC内のマルウェアがブラウザの通信内容を改ざんする攻撃
SG試験では「通信途中ではなく、ブラウザ内で改ざんしているか」を見抜く問題としてよく出る

直感的な説明

銀行サイトで振込をしたとき、

自分は「Aさんに1万円」と入力したつもりなのに
実際には「攻撃者の口座に50万円」に書き換えられて送信される

というようなイメージです。

しかも画面上は正常に見えるため、利用者は気づきにくいのがポイントです。

定義・仕組み

Man-in-the-Browser攻撃は、次の流れで行われます。

PCにマルウェアが感染する
Webブラウザに入り込む（拡張機能のように動く）
利用者がログインや振込操作を行う
送信直前のデータを改ざんする（振込先など）

重要なのはここです：

通信経路ではなく
ブラウザの中で書き換える

そのため、HTTPS通信であっても防げない場合があります。

どんな場面で使う？

使われる場面

インターネットバンキング
クレジットカード決済
個人情報の入力フォーム

→ 「入力→送信」する場面が狙われる

注意すべき場面（誤解しやすい）

偽サイトに誘導する攻撃ではない
通信途中で盗聴する攻撃でもない

SG試験では
「どこで攻撃しているか（ブラウザ内か通信途中か）」を問われることが多い

よくある誤解・混同

Man-in-the-Middleとの違い

MITM：通信の途中で盗聴・改ざん
MITB：ブラウザ内で改ざん

👉 選択肢では「中継サイト」「通信経路」などの表現があればMITM

フィッシングとの違い

フィッシング：偽サイトに入力させる
MITB：正規サイト上で改ざんする

👉 「偽サイトに誘導」はフィッシング

DNSキャッシュポイズニングとの違い

DNS：接続先そのものを偽サイトに変える
MITB：接続先は正しいが中身が改ざんされる

👉 「DNSを書き換える」は別物

まとめ（試験直前用）

MITB＝ブラウザ内で通信内容を改ざんする攻撃
ポイントは「通信途中ではなくPC内部」
フィッシング：偽サイトに誘導
MITM：通信途中で盗聴・改ざん
選択肢で「マルウェアがブラウザ内で改ざん」とあれば正解

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

中間者攻撃とは？通信を盗み見る仕組みと対策【情報セキュリティマネジメント】

Source: pages\sg\man-in-the-middle-attack.md
Permalink: /sg/man-in-the-middle-attack/

まず結論

中間者攻撃とは、通信を行う2者の間に割り込んで、内容を盗聴・改ざんする攻撃であり、SG試験では「暗号化・認証で防げるか」を判断させる問題として出題される。

直感的な説明

中間者攻撃は、

👉「2人の会話の間にこっそり入り込む盗み聞き」

のイメージです。

例えば、

AさんとBさんが通信しているつもりでも
実際は攻撃者を経由して通信している

👉 つまり
「気づかないまま盗まれる」のが特徴です。

定義・仕組み

中間者攻撃（MITM：Man In The Middle）は、

攻撃者が通信経路に入り込む
通信内容を盗聴する
必要に応じて改ざんする

という流れで行われます。

代表的な手口

Wi-Fiのなりすまし（偽アクセスポイント）
ARPスプーフィング
DNSスプーフィング

👉 共通点は
「正しい相手と通信していると錯覚させる」こと

どんな場面で使う？

使われる場面（攻撃）

公衆Wi-Fiでの通信
暗号化されていない通信（HTTPなど）
認証が不十分な通信

防ぐ場面（対策）

HTTPS（通信の暗号化）
証明書の検証（正しい相手か確認）
VPNの利用

SG試験での考え方

👉 「盗聴・改ざん」を防ぐには何か？

暗号化 → 内容を読めなくする
認証 → 相手が正しいか確認する

👉 この2つをセットで考える

よくある誤解・混同

❌ 誤解①：通信を止める攻撃

👉 ⭕ 違う

中間者攻撃は「盗む・改ざんする」攻撃

（通信停止はDoS攻撃）

❌ 誤解②：ウイルス感染の話

👉 ⭕ 違う

通信経路の攻撃

❌ 誤解③：暗号化だけで完全防御

👉 ⭕ 不十分な場合あり

偽物のサイトに誘導されると意味がない

👉 認証（証明書確認）も必要

SG試験のひっかけポイント

「暗号化だけで防げる」とする選択肢
→ ❌ 不十分

👉 正しくは

暗号化＋認証の組み合わせ

まとめ（試験直前用）

中間者攻撃＝「通信の間に割り込んで盗聴・改ざん」
特徴は
👉 気づかれにくい
対策は
👉 暗号化＋相手認証
試験では
👉 「盗聴か妨害か」をまず切り分ける

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

パスワードリスト攻撃とは？使い回しを狙う不正ログイン【情報セキュリティマネジメント】

Source: pages\sg\password-list-attack.md
Permalink: /sg/password-list-attack/

まず結論

パスワードリスト攻撃とは、他サービスから流出したIDとパスワードの組み合わせを使って不正ログインを試みる攻撃であり、SG試験では「推測型攻撃との違い」と「使い回しの危険性」を判断させる問題として出題される。

直感的な説明

パスワードリスト攻撃は、

👉「すでに正解が載っているリストを使う」攻撃です。

例えば、

どこかのサイトから流出した
IDとパスワードをそのまま使って
👉 他のサイトにログインを試す

👉 同じパスワードを使っていると簡単に突破されます。

定義・仕組み

パスワードリスト攻撃（リスト型攻撃）は、

👉 流出した認証情報（ID・パスワード）を入手し
👉 他のサービスに対してそのまま試す攻撃です。

攻撃の流れ

他サービスから認証情報が流出
攻撃者がリストを入手
別のサービスでログインを試行
同じ情報を使っているアカウントに侵入成功

なぜ成功するのか

多くの人がパスワードを使い回している
正しい組み合わせなので成功率が高い

👉 推測ではなく「再利用」がポイント

どんな場面で使う？

攻撃される場面

Webサービスのログイン
ECサイト、SNS、社内システム

防ぐ場面（対策）

パスワードの使い回し禁止
多要素認証（MFA）
異常ログイン検知（普段と違うIP・時間）
パスワード漏えいチェック機能

SG試験での考え方

👉 「推測か、流出か」

推測 → ブルートフォース・辞書攻撃
流出 → パスワードリスト攻撃

👉 この違いで判断する

よくある誤解・混同

❌ 誤解①：ブルートフォース攻撃と同じ

👉 ⭕ 違う

ブルートフォース：総当たり
リスト型：流出情報をそのまま使う

❌ 誤解②：時間がかかる攻撃

👉 ⭕ むしろ高速

正しい組み合わせなので試行回数が少ない

❌ 誤解③：複雑なパスワードなら安全

👉 ⭕ 不十分

他サイトで漏れていれば意味がない

SG試験のひっかけポイント

「パスワードの複雑化だけで防げる」とする選択肢
→ ❌ 不十分

👉 正しくは

使い回し禁止＋多要素認証

まとめ（試験直前用）

パスワードリスト攻撃＝「流出情報の使い回し攻撃」
特徴は
👉 成功率が高い・高速
対策は
👉 使い回し禁止＋MFA
試験では
👉 「推測か流出か」で切り分ける

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

フィッシングとは？だましの手口と見抜き方【情報セキュリティマネジメント】

Source: pages\sg\phishing.md
Permalink: /sg/phishing/

まず結論

フィッシングとは、偽のメールやWebサイトで利用者をだまし、認証情報などを入力させて盗み取る攻撃です。
SG試験では「だまして入力させる攻撃かどうか」を見抜けるかが問われます。

直感的な説明

銀行から「不正アクセスがありました。今すぐ確認してください」というメールが届き、リンクをクリックすると本物そっくりの画面が出てきてID・パスワードを入力してしまう…。

これがフィッシングです。

👉 「本物に見せかけて入力させる」のがポイントです。

定義・仕組み

フィッシング（phishing）は、実在する企業やサービスを装い、利用者を偽サイトに誘導して情報を盗む攻撃です。

基本の流れは次の通りです。

攻撃者が偽のWebサイトを用意
メールなどでURLを送りつける
利用者がリンクをクリック
偽サイトでID・パスワードなどを入力
情報が攻撃者に送られる

重要なのは
👉 「ユーザー自身に入力させる」点です。

どんな場面で使う？

よく使われる場面

銀行・クレジットカードのログイン情報の盗取
ECサイトのアカウント乗っ取り
社内システムの認証情報の奪取

業務でのポイント

社員教育（不審メールの見分け）
URL確認の習慣化
多要素認証の導入

👉 人の判断ミスを狙う攻撃なので、教育が重要

よくある誤解・混同

❌ DDoS攻撃との混同

DDoS：サーバを止める攻撃
フィッシング：情報をだまし取る攻撃

👉 目的が全く違う（停止 vs 盗取）

❌ マルウェア感染との混同

マルウェア：プログラムを感染させる
フィッシング：入力させて盗む

👉 「入力させるかどうか」で見分ける

❌ ボットとの混同

ボット：遠隔操作するためのプログラム
フィッシング：だまして情報を取得する手口

👉 ボットは手段、フィッシングは攻撃手法

SG試験でのひっかけ

「メールで誘導」＋「偽サイト」＋「入力させる」
→ この組み合わせならフィッシングと判断

まとめ（試験直前用）

フィッシング＝偽サイトに誘導して入力させる攻撃
「ユーザーが自分で入力する」が最大の特徴
DDoS（停止）・マルウェア（感染）と区別する
メール＋リンク＋入力フォーム → フィッシングと判断

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ポートスキャンとは？攻撃と対策の両面から理解する【情報セキュリティマネジメント】

Source: pages\sg\port-scan.md
Permalink: /sg/port-scan/

まず結論

ポートスキャンとは、サーバや機器のポートの状態を調べて、どのサービスが動いているかを確認する行為であり、SG試験では「攻撃にも防御にも使われる点」と「目的の違い」を判断させる問題として出題される。

直感的な説明

ポートは「サーバの入口」です。

イメージとしては、

どのドア（ポート）が開いているか調べる
どこから入れそうか探す

という「下見（偵察）」の行為です。

👉 空き巣が家のドアや窓をチェックするのと同じです。

ただし、 👉 管理者も「ちゃんと閉まっているか確認するため」に使います。

定義・仕組み

ポートスキャンは、対象サーバに対して通信を行い、

開いているポート（Open）
閉じているポート（Closed）
応答がないポート（Filtered）

を調べることで、

👉 どのサービス（HTTP、SSHなど）が動いているかを把握します。

なぜ重要か

不要なサービスが動いている
→ 攻撃の入口になる

攻撃者の目的

侵入できそうなサービスを探す
脆弱性のあるポートを特定する

防御側の目的（重要）

不要なポートが開いていないか確認
設定ミスの検出
セキュリティチェック（脆弱性診断の一部）

👉 同じ行為でも「目的が違う」ことがポイント

どんな場面で使う？

使う場面

サーバ構築後の設定確認
セキュリティ監査・脆弱性診断
インシデント対応（攻撃の痕跡調査）

SG試験での考え方

攻撃者：侵入口を探す
管理者：不要な入口を閉じる

👉 目的で判断する

よくある誤解・混同

❌ 誤解①：ポートスキャン＝攻撃そのもの

👉 ⭕ 実際は

攻撃の「前段階（偵察）」
防御でも使う

❌ 誤解②：ログ分析と同じ

👉 ⭕ 全く別

ポートスキャン：入口の調査
ログ分析：利用履歴の確認

❌ 誤解③：ID管理やアクセス制御の話

👉 ⭕ 違う

ポートスキャンは「ネットワークの入口」の話

SG試験のひっかけポイント

「ポートスキャン＝不正行為」と決めつける選択肢
→ ❌ 不正確

👉 正しくは

用途によってはセキュリティ対策として正しい

まとめ（試験直前用）

ポートスキャン＝「開いているポートを調べる行為」
攻撃では
👉 侵入口の発見（偵察）
防御では
👉 不要サービスの確認
試験では
👉 「目的が攻撃か対策か」で判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

プライバシーセパレータとは？無線LANで端末同士を隔離する仕組み【情報セキュリティマネジメント】

Source: pages\sg\privacy-separator.md
Permalink: /sg/privacy-separator/

まず結論

プライバシーセパレータは、同じ無線LANに接続している端末同士の通信を禁止する機能であり、SG試験では「接続そのものは防げない」という点が重要です。

直感的な説明

カフェのWi-Fiをイメージしてください。

AさんとBさんが同じWi-Fiに接続している
でも、お互いのスマホやPCにはアクセスできない

👉 これがプライバシーセパレータです。

つまり、

👉 同じネットワーク内でも「隣の人には見えない」状態にする機能

です。

定義・仕組み

プライバシーセパレータとは、

無線LANのアクセスポイントが
同じネットワークに接続している端末同士の通信を遮断する機能

です。

仕組みとしては、

端末Aと端末Bが同じWi-Fiに接続
通常なら直接通信できる（同一ネットワーク）
プライバシーセパレータONの場合
→ 端末A → 端末B の通信を遮断

👉 ただし重要なポイント：

インターネットへの通信はできる
アクセスポイントへの接続もできる

つまり、

👉 「横の通信だけ止める」機能

です。

どんな場面で使う？

■ 使うべき場面

カフェやホテルのフリーWi-Fi
セミナー会場の来場者Wi-Fi
ゲスト用ネットワーク

👉 不特定多数が接続する環境

■ 使うと誤解しやすい場面

不正接続の防止
アクセス制御（誰が接続できるか）

👉 これは別の仕組み（認証・PSKなど）が担当します。

よくある誤解・混同

❌ プライバシーセパレータで不正接続を防げる

→ 防げない

👉 接続はできてしまう

❌ URLフィルタと同じ

→ 違う

プライバシーセパレータ → 端末同士の通信を制限
URLフィルタ → Webサイトへのアクセス制限

❌ DHCPと関係がある

→ 関係ない

DHCPはIPアドレスの割り当てであり、通信制御ではない

SG試験のひっかけ

SG試験ではこう出ます：

「アクセスポイントへの接続を防止する」

このとき、

プライバシーセパレータ → ❌（接続は防げない）
PSK（事前共有鍵） → ⭕（接続を制御する）

👉 接続前か、接続後かで切り分ける

まとめ（試験直前用）

プライバシーセパレータは「端末同士の通信」を遮断する機能
アクセスポイントへの接続は防げない
フリーWi-Fiなどで横の攻撃を防ぐために使う
SG試験では「接続制御ではない」と判断できればOK

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

事前共有鍵（PSK）とは？無線LANの接続制御の基本【情報セキュリティマネジメント】

Source: pages\sg\psk-wireless-auth.md
Permalink: /sg/psk-wireless-auth/

まず結論

事前共有鍵（PSK）は、無線LANに接続できる端末を制限するための「共通パスワード」であり、SG試験では「接続そのものを制御する仕組みかどうか」を判断させる問題でよく問われます。

直感的な説明

セミナー会場のWi-Fiをイメージしてください。

参加者には「今日のパスワード」を配る
そのパスワードを知っている人だけ接続できる

これがPSKです。

もしパスワードを毎回変えなければ、過去の参加者もずっと使えてしまいます。

だから、 「イベントごとに鍵を変える」＝不正利用を防ぐ基本対策 になります。

定義・仕組み

事前共有鍵（PSK：Pre-Shared Key）とは、

無線LANのアクセスポイントと端末で
あらかじめ同じ鍵（パスワード）を共有して
認証を行う方式

です。

仕組みとしてはシンプルで、

端末がWi-Fiに接続しようとする
正しい鍵（パスワード）を入力
一致すれば接続許可

という流れになります。

SG試験ではここが重要です：

👉 PSKは「接続前の認証」を担当する

つまり、 接続できるかどうかを決める仕組みです。

どんな場面で使う？

使うべき場面

セミナーやイベントの来場者Wi-Fi
小規模オフィスの無線LAN
来客用ネットワーク（ゲストWi-Fi）

特に重要なのが、

👉 参加者が毎回変わる環境

この場合は、 PSKを定期的に変更することで不正接続を防ぐ という運用になります。

使うと誤解しやすい場面

接続後の通信制御（URL制限など）
IPアドレスの割当（DHCP）

これらはすべて 接続した後の話です。

よくある誤解・混同

❌ DHCPで制御できる

→ できない

DHCPはIPアドレスを配るだけです。
接続の可否は制御できません。

❌ URLフィルタで防げる

→ 防げない

URLフィルタは
接続後にどのサイトへ行けるかを制御する機能です。

❌ プライバシーセパレータで防げる

→ 防げない

これは
端末同士の通信を防ぐ機能です。
アクセスポイントへの接続自体は止められません。

SG試験のひっかけ

SG試験ではこう問われます：

「接続を防ぐ対策はどれか？」

このとき、

接続前 → 認証（PSKなど）
接続後 → フィルタ・制限

この切り分けができるかがポイントです。

まとめ（試験直前用）

PSKは「無線LANに接続できるか」を決める認証方式
セミナーなどでは「鍵を毎回変更」が基本対策
DHCPやURLフィルタは「接続後」の制御なので不正解
SG試験では「接続前か・接続後か」で選択肢を切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ランサムウェアとは？身代金要求型攻撃の仕組み【情報セキュリティマネジメント】

Source: pages\sg\ransomware.md
Permalink: /sg/ransomware/

まず結論

ランサムウェアとは、データを暗号化して利用できなくし、復旧と引き換えに身代金を要求するマルウェアであり、SG試験では「可用性の侵害」と「金銭要求」を見抜くことが重要です。

直感的な説明

ランサムウェアは「データを人質に取る攻撃」です。

たとえば

ファイルがすべて開けなくなる
「元に戻したければお金を払え」と表示される

といった状態になります。

業務では

業務停止
顧客対応不能
など、可用性（使える状態）が失われる被害が大きいのが特徴です。

定義・仕組み

ランサムウェアは、感染後にデータを暗号化し、復号と引き換えに金銭を要求します。

基本の流れ

メール添付や不正サイトから感染
端末内のファイルを暗号化
「復元したければ支払え」と表示
仮想通貨などで支払い要求

特徴

データの利用不可（可用性の侵害）
金銭要求（身代金）
組織全体に拡大することもある

近年の傾向（SG試験でも出やすい）

二重脅迫（ダブルエクストーション）
- 暗号化＋情報を盗んで公開を脅す

👉 可用性＋機密性の両方を脅かす

どんな場面で使う？

使うべき場面（試験・実務）

インシデント対応（感染時の初動判断）
バックアップ運用の重要性
社内教育（不審メール対策）

間違えやすい場面

単なるデータ削除と混同
→ ランサムウェアは「復元させる代わりに金銭要求」

よくある誤解・混同

① スパイウェアとの違い

❌ 情報を盗む＝ランサムウェア
⭕ ランサムウェアは「使えなくする＋要求する」

② ウイルスとの混同

❌ すべて自己増殖する
⭕ ランサムウェアは増殖が本質ではない

③ 対応方法の誤解

❌ 支払えば必ず復旧する
⭕ 復旧保証はなく、支払いは推奨されない

SG試験での典型パターン

「ファイルが暗号化される」
「業務が停止する」
「身代金を要求される」

選択肢で
「情報を収集する」とあれば
→ スパイウェアであり誤り

まとめ（試験直前用）

ランサムウェア＝データを暗号化して身代金要求
可用性の侵害が中心
二重脅迫で機密性も侵害
感染経路はメール・Webなど
判断基準は「使えなくする＋金銭要求」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

リバースブルートフォース攻撃とは？逆総当たりの仕組みと対策【情報セキュリティマネジメント】

Source: pages\sg\reverse-brute-force-attack.md
Permalink: /sg/reverse-brute-force-attack/

まず結論

リバースブルートフォース攻撃とは、特定のパスワードを固定して複数のIDに対して試す攻撃であり、SG試験では「通常のブルートフォースとの違い」と「アカウントロックを回避する仕組み」を判断させる問題として出題される。

直感的な説明

通常のブルートフォース攻撃は、

👉 1つのIDに対してパスワードを変えて試す

ですが、リバースブルートフォースは逆です。

👉 1つのパスワードで、たくさんのIDを試す

イメージ：

「password123」を固定
山田、田中、佐藤…とIDを変えて試す

👉 誰か1人でも同じパスワードを使っていれば突破できます。

定義・仕組み

リバースブルートフォース攻撃（逆総当たり攻撃）は、

👉 よく使われるパスワードを1つ選び
👉 多数のアカウントに対して試行する攻撃です。

なぜ有効か

多くのユーザが同じようなパスワードを使っている
1アカウントへの試行回数が少ない

👉 アカウントロックを回避しやすい

通常のブルートフォースとの違い

攻撃	特徴
ブルートフォース	1つのIDに対して総当たり
リバースブルートフォース	1つのパスワードで複数IDを試す

どんな場面で使う？

攻撃される場面

多数のユーザアカウントがあるサービス
パスワードの使い回しが多い環境

防ぐ場面（対策）

多要素認証（MFA）
パスワードの使い回し禁止
異常ログイン検知（IP・挙動分析）
パスワードポリシーの強化

SG試験での考え方

👉 「なぜロックされないか？」

1ユーザあたりの試行回数が少ない
👉 アカウントロックに引っかかりにくい

よくある誤解・混同

❌ 誤解①：ブルートフォースと同じ

👉 ⭕ 逆の考え方

ID固定か
パスワード固定か

❌ 誤解②：パスワード漏えい攻撃

👉 ⭕ 違う

推測して試す攻撃

（漏えいはリスト型攻撃）

❌ 誤解③：対策はアカウントロックだけ

👉 ⭕ 不十分

ロックを回避できる攻撃

SG試験のひっかけポイント

「アカウントロックで防げる」とする選択肢
→ ❌ 不十分

👉 正しくは

多要素認証や異常検知が必要

まとめ（試験直前用）

リバースブルートフォース＝「パスワード固定で複数IDを試す」
特徴は
👉 アカウントロックを回避しやすい
対策は
👉 MFA＋使い回し防止＋異常検知
試験では
👉 「ID固定かパスワード固定か」で切り分ける

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ルートキットとは？管理者権限で隠蔽する仕組み【情報セキュリティマネジメント】

Source: pages\sg\rootkit.md
Permalink: /sg/rootkit/

まず結論

ルートキットとは、管理者権限（root権限）を取得してシステムを支配し、その存在や不正活動を隠蔽するマルウェアであり、SG試験では「管理者権限を使って隠す」という点を見抜くことが重要です。

直感的な説明

ルートキットは「管理者になりすまして証拠を消す仕組み」です。

たとえば

攻撃者が管理者権限を取得する
ログを削除・改ざんする
不正プログラムを見えなくする

というように、“管理者だから何でもできる”状態を悪用して隠すのが特徴です。

👉 普通のユーザー権限ではできない操作ができる点が本質です

定義・仕組み

ルートキットは、管理者権限を利用してシステムの深い部分に介入します。

なぜ「ルート」なのか（重要）

root＝管理者権限（最も強い権限）
OSの内部まで操作できる
セキュリティ機能すら無効化できる

👉 この権限を取られると、検知が極めて困難になる

主な機能

プロセスの隠蔽（動いていても見えない）
ファイルの隠蔽
ログの改ざん・削除
セキュリティソフトの無効化

👉 これらはすべて「管理者権限があるから可能」

攻撃の流れでの位置づけ

脆弱性などで侵入
権限昇格（管理者権限を取得）
ルートキットで隠蔽

SG試験では、
「権限昇格のあとに使われる」という流れで理解するのが重要です。

どんな場面で使う？

使うべき場面（試験・実務）

不正アクセス後の調査
権限昇格が疑われるケース
ログが不自然に消えている場合

間違えやすい場面

初期侵入手段と混同
→ ルートキットは「侵入後＋権限取得後」に使われる

よくある誤解・混同

① ルートキットの役割の誤解

❌ 攻撃を実行するマルウェア
⭕ 管理者権限を使って痕跡を隠すマルウェア

② 権限の重要性の見落とし（最重要）

❌ 普通の権限でも同じことができる
⭕ 管理者権限があるから隠蔽が可能

👉 SG試験ではここが最重要ポイント

③ ボットとの違い

❌ どちらも乗っ取り系
⭕ ボット＝操作、ルートキット＝管理者権限で隠蔽

SG試験での典型パターン

「管理者権限を取得している」
「ログが消されている／改ざんされている」
「不正プログラムが検知されない」

選択肢で
「自己増殖」や「情報収集」と書かれていれば
→ ルートキットではない

まとめ（試験直前用）

ルートキット＝管理者権限で隠蔽するマルウェア
root権限を使ってシステムを操作
ログ改ざん・プロセス隠蔽が可能
権限昇格のあとに使われる
判断基準は「管理者権限で隠しているか」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

サンドボックスとは？安全にプログラムを実行する仕組み【情報セキュリティマネジメント】

Source: pages\sg\sandbox.md
Permalink: /sg/sandbox/

まず結論

サンドボックスとは、プログラムの動作範囲を制限して安全に実行する仕組みです。
SG試験では「影響範囲を限定する対策かどうか」を判断できるかがポイントです。

直感的な説明

サンドボックスは「砂場」のイメージです。

子どもが砂場の中で遊ぶ分には安全ですが、外に出ると危険がありますよね。
同じように、プログラムを決められた範囲の中だけで動かすことで、
もし悪い動きをしても外に影響が出ないようにします。

定義・仕組み

サンドボックスは、プログラムの実行時に次のような制限をかける仕組みです。

アクセスできるファイルを制限する
ネットワーク通信を制限する
システム全体への影響を遮断する

つまり、

「プログラムは動かすが、できることを最小限にする」

という考え方です。

特に、次のような場面で使われます。

不審なファイルの動作確認（マルウェア解析）
信頼できないプログラムの実行
ブラウザの安全な実行環境

どんな場面で使う？

使うべき場面

添付ファイルやダウンロードファイルの安全確認
未検証のソフトウェアを実行するとき
セキュリティ検査やマルウェア分析

誤解しやすい場面

攻撃を「防ぐ」仕組みと混同しやすい
→ サンドボックスは防御というより被害の限定です

よくある誤解・混同

❌ よくある誤解

「怪しい通信を検知して遮断する仕組み」
「攻撃を防ぐフィルタのようなもの」

⭕ 正しい理解

プログラムの行動範囲を制限する仕組み

SG試験でのひっかけ

SG試験では次のように混同させてきます。

「攻撃パターンを検知して遮断」
　→ WAF（Webアプリケーションファイアウォール）
「侵入者をおびき寄せて監視」
　→ ハニーポット
「実行環境を制限して影響を防ぐ」
　→ サンドボックス（これが正解）

👉 選択肢では
「実行できる機能やアクセスを制限する」と書かれていたらサンドボックスです。

まとめ（試験直前用）

サンドボックス＝安全な範囲内でプログラムを実行する仕組み
目的は「攻撃防止」ではなく被害の限定
「アクセス制限」「実行制限」がキーワード
SG試験では
→ WAF・ハニーポットとの違いで出題されやすい

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

スクリプトキディとは？初心者攻撃者の特徴と対策【情報セキュリティマネジメント】

Source: pages\sg\script-kiddie.md
Permalink: /sg/script-kiddie/

まず結論

スクリプトキディとは、自分で攻撃を作れず、他人が作ったツールを使って攻撃する未熟な攻撃者であり、SG試験では「無差別攻撃や基本対策で防げる相手か」を判断させる問題として出題されます。

直感的な説明

イメージとしては、

ゲームでいう「チートツールをそのまま使う人」
中身は理解していないが、ボタンを押せば攻撃できる

という感じです。

👉 技術力は高くないが、誰でも攻撃できる状態を作る存在なので数が多く、油断できません。

定義・仕組み

スクリプトキディの特徴は以下の通りです。

他人のツールを使う

自分でプログラムは作れない
公開されている攻撃ツールを使用

技術力は低い

仕組みを理解していないことが多い
既知の脆弱性をそのまま狙う

無差別攻撃が多い

特定の企業を狙うというより
「見つかったら攻撃する」スタイル

👉 そのため、古いソフトや未対策のシステムが狙われやすい

どんな場面で使う？

SG試験での典型パターン

パターン①：攻撃のレベル判定

高度な標的型攻撃 → スクリプトキディではない
単純な脆弱性攻撃 → スクリプトキディの可能性

👉 「高度かどうか」が判断基準

パターン②：対策の選択

パッチ未適用 → 攻撃される（スクリプトキディでも可能）
基本対策あり → 防げる

👉 基本対策で防げるかどうかがポイント

現場での意味

インターネット公開サーバは常にスキャンされている
スクリプトキディが自動ツールで攻撃している

👉 「特別に狙われていなくても攻撃される」理由になる

よくある誤解・混同

❌ スクリプトキディ＝危険ではない

→ ⭕ 数が多く、被害は普通に起きる

👉 技術力は低くても、放置すれば侵入される

❌ 高度な攻撃＝スクリプトキディ

→ ⭕ それはクラッカーや組織的攻撃

👉 スクリプトキディは「単純・既知攻撃」が基本

❌ 対策は特別なものが必要

→ ⭕ 基本対策で防げる

パッチ適用
不要ポート閉鎖
パスワード管理

👉 SG試験では「基本対策で十分」が正解になりやすい

まとめ（試験直前用）

スクリプトキディ＝ツール頼みの初心者攻撃者
技術力は低いが数が多く無差別攻撃をする
既知の脆弱性を狙うのが特徴
基本的なセキュリティ対策で防げる
SG試験では「高度攻撃との違い」で判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

情報セキュリティ対策をCIAで整理！実務と試験の判断軸【SG試験】

Source: pages\sg\security-measures-cia.md
Permalink: /sg/security-measures-cia/

まず結論

情報セキュリティ対策は「機密性・完全性・可用性（CIA）のどれを守るか」で整理できます。
SG試験では「その対策は何を守っているか」で正誤を判断します。

直感的な説明

対策は「攻撃の逆」です。

盗まれる → 盗まれないようにする
書き換えられる → 書き換えられないようにする
止められる → 止まらないようにする

👉 攻撃（CIA）⇔対策（CIA）で対応する

定義・仕組み

機密性（Confidentiality）を守る対策

アクセス制御（ID・パスワード）
認証（多要素認証など）
暗号化

👉 見られてはいけない情報を守る

完全性（Integrity）を守る対策

改ざん検知（ハッシュ値）
ログ管理
デジタル署名

👉 正しさを維持する

可用性（Availability）を守る対策

冗長化（サーバの二重化）
負荷分散
バックアップ

👉 止まらないようにする

どんな場面で使う？

SG試験での使い方

問題文で👇

「情報漏えいを防ぐ」 → 機密性対策
「改ざんを防止」 → 完全性対策
「サービス継続」 → 可用性対策

👉 対策の目的で判断

科目Bでの重要ポイント

対策は「目的に合っているか」が重要

例：

DDoS対策なのに暗号化 → ❌
改ざん対策なのにバックアップ → ❌（直接ではない）

👉 「守りたいもの」と一致しているかを見る

よくある誤解・混同

❌ セキュリティ対策は全部同じ

→ ⭕ 守る対象（CIA）が違う

❌ 暗号化は万能

→ ⭕ 機密性の対策であり、可用性には効かない

❌ バックアップはすべての対策になる

→ ⭕ 主に可用性の対策

SG試験のひっかけ

「暗号化」 → 機密性
「ハッシュ」「署名」 → 完全性
「冗長化」「バックアップ」 → 可用性

👉 用語→CIAに変換して判断

まとめ（試験直前用）

対策はCIAで分類する
機密性＝アクセス制御・暗号化
完全性＝改ざん検知・署名
可用性＝冗長化・バックアップ
SG試験では「何を守るか」で切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

セッションハイジャックとは？ログイン乗っ取りの仕組みと対策【情報セキュリティマネジメント】

Source: pages\sg\session-hijacking.md
Permalink: /sg/session-hijacking/

まず結論

セッションハイジャックとは、ユーザのセッション情報（ログイン状態）を盗んで、本人になりすまして不正アクセスする攻撃であり、SG試験では「認証後の対策ができているか」を判断させる問題として出題される。

直感的な説明

ログインすると、

👉「この人は本人です」という状態（セッション）が作られます。

セッションハイジャックは、 👉 この「ログイン済みの状態」を盗む攻撃です。

イメージとしては、

本人が入館証を持って入ったあと
その入館証を盗んで別人が使う

👉 パスワードを知らなくても侵入できるのがポイントです。

定義・仕組み

セッションハイジャックは、次の流れで行われます。

ユーザがWebサイトにログイン
サーバがセッションIDを発行
攻撃者がそのセッションIDを取得
そのIDを使って本人になりすます

セッションIDの取得方法（代表例）

スニッフィング（通信盗聴）
クロスサイトスクリプティング（XSS）
マルウェア感染

👉 共通点は
「セッションIDを盗むこと」

どんな場面で使う？

攻撃されやすい場面

公衆Wi-Fi利用時
暗号化されていない通信（HTTP）
セッション管理が弱いWebサイト

防ぐ場面（対策）

HTTPS（通信の暗号化）
セッションIDの定期変更
ログイン後の再認証（重要操作時）
Cookieの適切な設定（Secure属性など）

SG試験での考え方

👉 「認証後も安全か？」がポイント

認証（ID・パスワード）だけでは不十分
セッション管理まで含めて考える

よくある誤解・混同

❌ 誤解①：パスワードを盗む攻撃

👉 ⭕ 違う

セッションハイジャックは
👉 「ログイン後の状態」を盗む

❌ 誤解②：中間者攻撃と同じ

👉 ⭕ 関係はあるが別物

中間者攻撃：通信を盗聴
セッションハイジャック：セッションを乗っ取る

（中間者攻撃が原因になることはある）

❌ 誤解③：ログインすれば安全

👉 ⭕ SG試験ではここが重要

ログイン後の管理が不十分だと不正利用される

SG試験のひっかけポイント

「認証強化（パスワード）」だけで防げるとする選択肢
→ ❌ 不十分

👉 正しくは

セッション管理の対策が必要

まとめ（試験直前用）

セッションハイジャック＝「ログイン状態の乗っ取り」
パスワード不要で侵入できるのが特徴
対策は
👉 HTTPS＋セッション管理
試験では
👉 「認証前か認証後か」で切り分ける

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

スミッシングとは？SMSを使った詐欺手口【情報セキュリティマネジメント】

Source: pages\sg\smishing.md
Permalink: /sg/smishing/

まず結論

スミッシングとは、SMS（ショートメッセージ）を使って偽サイトへ誘導し、認証情報などを盗み取るフィッシングの一種です。
SG試験では「SMSで誘導しているか」でフィッシングとの違いを判断させる問題がよく出ます。

直感的な説明

「荷物のお届けに問題があります。こちらから確認してください」
というSMSが届き、リンクをタップすると偽サイトへ…。

スマホだとURLをよく確認せずに押してしまいがちです。

👉 メールではなく“SMSでだます”のがスミッシング

定義・仕組み

スミッシング（smishing）は、SMSを利用して利用者を偽サイトへ誘導し、情報を盗む攻撃です。
（SMS＋phishing の造語）

基本の流れはフィッシングと同じです。

攻撃者が偽サイトを用意
SMSでURL付きメッセージを送信
利用者がリンクをタップ
偽サイトで情報を入力
情報が盗まれる

👉 違いは「メールかSMSか」だけ

どんな場面で使う？

よく使われるケース

配送業者を装うSMS（不在通知など）
銀行・キャリアを装うSMS
「緊急」「重要」と焦らせる内容

業務でのポイント

社員のスマホも攻撃対象になる
BYOD（私物端末利用）環境では特に注意
SMSのリンクは原則クリックしない教育

👉 スマホ利用の増加とともに被害が増えている

よくある誤解・混同

❌ フィッシングとの違い

フィッシング：メールで誘導
スミッシング：SMSで誘導

👉 誘導手段で区別する

❌ ビッシングとの混同

スミッシング：SMS
ビッシング：電話

👉 SMSか音声かで判断

❌ 正規のSMSとの区別

正規：公式サイトに誘導 or URLなし
攻撃：不自然なURL・短縮URL

👉 URLの違和感が重要な判断ポイント

SG試験でのひっかけ

「SMSでURLを送る」
→ この時点でスミッシングを疑う
「メール」ならフィッシング
→ 手段で切り分ける

まとめ（試験直前用）

スミッシング＝SMS版フィッシング
SMS＋URL＋入力 → 典型パターン
フィッシング（メール）と手段で区別
ビッシング（電話）との違いも押さえる

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

SMTPのポート番号とは？パケットフィルタリングでの見方を整理【SG試験】

Source: pages\sg\smtp-port-packet-filtering.md
Permalink: /sg/smtp-port-packet-filtering/

まず結論

SMTPのポート番号とは、メール送信で使う通信先の番号で、通常は25番を指すものです。
SG試験では、SMTPそのものの暗記だけでなく、パケットフィルタリング型ファイアウォールでどの通信を通すべきかを判断できるかと問われることが多いです。

この種の問題では、SMTPサーバのあて先ポートは25番、PC側の送信元ポートは1024以上、応答では向きが逆になると整理できれば、選択肢を切りやすくなります。

直感的な説明

ポート番号は、ネットワークの世界でいう「部屋番号」のようなものです。
同じサーバでも、どのサービスに話しかけたいかで入口が違います。

たとえば、社内PCからインターネット上のSMTPサーバへメールを送るときは、
「SMTPというメール送信用の入口」に向かって通信します。
その入口が 25番ポート です。

一方で、PC側は毎回同じ番号を使うわけではありません。
PCは通信のたびに空いている番号を一時的に使うので、送信元ポートは1024以上の動的な番号になります。

つまり感覚としては、次のように考えるとわかりやすいです。

PCはその都度、空いている番号から出発する
サーバはサービスごとに決まった番号で待っている
返事は行きと逆向きに戻る

SG試験ではこの流れを理解しているかを、表や構成図で問われることが多いです。

定義・仕組み

SMTPは、電子メールを送信するためのプロトコルです。
正式には Simple Mail Transfer Protocol といいますが、SG試験では英語の正式名称よりも、メール送信で使うという役割を押さえることが大切です。

パケットフィルタリング型ファイアウォールは、通信を通すか止めるかを、主に次の情報で判断します。

送信元IPアドレス
あて先IPアドレス
プロトコル
送信元ポート番号
あて先ポート番号

ここで、社内PCからSMTPサーバへメール送信する通信を考えると、基本は次の形になります。

送信元：PC
あて先：SMTPサーバ
送信元ポート番号：1024以上
あて先ポート番号：25

そして、その応答は次のように逆になります。

送信元：SMTPサーバ
あて先：PC
送信元ポート番号：25
あて先ポート番号：1024以上

このため、選択肢では 「SMTPなのに110番になっていないか」、「PC側が25番になっていないか」、「応答の向きが逆になっているか」 を見ると判断しやすくなります。

なお、SG試験ではポート番号そのものを細かく暗記するより、サーバ側は固定の代表的なポート、クライアント側は動的なポートという考え方を押さえておく方が得点につながります。

どんな場面で使う？

SMTPのポート番号の考え方は、主に次のような場面で使います。

ファイアウォール設定を考える場面

社内ネットワークとインターネットの間にファイアウォールを置くとき、必要な通信だけを許可する必要があります。
そのとき、メール送信を許可したいなら、SMTPに対応した通信を正しく通す必要があります。

業務では、
「社内PCから外部のメールサーバへ送信できるようにする」
「不要な通信は遮断する」
という判断につながります。

ネットワーク構成図や通信表を読む場面

SG試験では、図や表を見て、どの通信が妥当かを判断させる問題がよく出ます。
このとき、SMTPの役割とポート番号がわかっていると、通信の正誤を見分けやすくなります。

使うと誤解しやすい場面

ただし、単に「25番を覚える」だけでは不十分です。
選択肢では 送信元ポート番号とあて先ポート番号を入れ替えてひっかける ことがあります。

また、SG試験では SMTP と POP3 を混同させてくることがあります。
メール送信は SMTP、メール受信は POP3 や IMAP という切り分けが大切です。

よくある誤解・混同

SMTPとPOP3の混同

よくあるのが、SMTPは送信、POP3は受信 という区別があいまいになることです。
選択肢では、SMTPの通信なのに110番ポートが書かれていたら注意です。

SMTP：メール送信、25番
POP3：メール受信、110番

この区別ができれば、かなり切りやすくなります。

PC側も固定ポートを使うという誤解

初心者が混同しやすいのが、
「SMTPならPC側も25番を使うのではないか」
という考え方です。

しかし実際には、通常の通信ではサーバ側がサービス用の固定ポートで待ち受け、PC側は一時的な動的ポートを使います。
したがって、PCの送信元ポートが25番になっている選択肢は不自然です。

応答でも同じ並びになるという誤解

行きの通信と返りの通信で、送信元とあて先がそのままだと思ってしまうことがあります。
しかし応答では、送信元とあて先が逆 になります。

選択肢ではこの点をずらしてくることがあり、
「SMTPサーバからPCへの応答なのに、あて先ポートが25番になっている」
などの形でひっかけてきます。

SG試験では、こうした表の見方を問われることが多いので、通信の流れで判断する ことが大切です。

まとめ（試験直前用）

SMTPのポート番号は、メール送信で使う25番です。
ただし試験では、番号の丸暗記だけでなく、PC側は1024以上の動的ポートを使うと理解しているかが問われます。
選択肢では SMTPとPOP3の混同、送信元ポートとあて先ポートの入れ替え、応答方向の逆転ミス に注意です。
迷ったら、サーバ側が固定ポート、PC側が動的ポート、応答は逆向き で判断すると切りやすくなります。

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

スパイウェアとは？情報を盗むマルウェアの特徴【情報セキュリティマネジメント】

Source: pages\sg\spyware.md
Permalink: /sg/spyware/

まず結論

スパイウェアとは、利用者に気づかれずに個人情報や操作情報を収集・外部へ送信するマルウェアであり、SG試験では「情報を盗む目的かどうか」を見抜くことが重要です。

直感的な説明

スパイウェアは「こっそり見張るソフト」です。

たとえば

入力したID・パスワードが盗まれる
閲覧履歴や操作履歴が送信される

といったように、気づかないうちに情報が抜き取られるのが特徴です。

業務でも

個人情報の漏えい
認証情報の流出
につながるため、被害が大きくなりやすいです。

定義・仕組み

スパイウェアは、ユーザーの行動や情報を収集し、外部に送信します。

主な収集対象

ID・パスワード
クレジットカード情報
キーボード入力（キーロガー）
閲覧履歴・操作履歴

感染経路

フリーソフトのインストール
不正なWebサイト
メールのリンク・添付ファイル

👉 「便利そうなソフト」に紛れて入ることが多い

特徴

表面上は目立たない（潜伏型）
ユーザーに気づかれにくい
情報を外部に送信する

SG試験では、
「破壊ではなく情報収集が目的」という点が重要です。

どんな場面で使う？

使うべき場面（試験・実務）

情報漏えいリスクの分析
個人情報保護対策の検討
不正ログインの原因調査

間違えやすい場面

ランサムウェアと混同する
→ スパイウェアは「盗む」、ランサムウェアは「身代金要求」

よくある誤解・混同

① ランサムウェアとの違い

❌ 情報を盗む＝ランサムウェア
⭕ スパイウェアは盗む、ランサムウェアは人質にする

② ウイルスとの混同

❌ すべてのマルウェアは増殖する
⭕ スパイウェアは増殖より情報収集が目的

③ キーロガーとの関係

❌ キーロガー＝別物
⭕ キーロガーはスパイウェアの一種

SG試験での典型パターン

「利用者に気づかれずに情報を収集」
「認証情報を外部送信」
「不正ログインの原因」

選択肢で
「データを暗号化して身代金要求」とあれば
→ ランサムウェアであり誤り

まとめ（試験直前用）

スパイウェア＝情報を盗むマルウェア
ID・パスワードなどを収集・送信
気づかれにくいのが特徴
キーロガーはその一種
判断基準は「目的が情報収集かどうか」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

標的型攻撃とは？狙われる組織の特徴と対策【情報セキュリティマネジメント】

Source: pages\sg\targeted-attack.md
Permalink: /sg/targeted-attack/

まず結論

標的型攻撃とは、特定の組織や個人を狙って、計画的・継続的に行われる不正アクセス攻撃であり、SG試験では「なぜ防ぎにくいか」と「どの対策が有効か」を判断させる問題として出題される。

直感的な説明

通常の攻撃は「とりあえず誰かに当たればいい」ですが、

標的型攻撃は 👉「この会社・この人を狙う」と決めてから攻撃します。

たとえば、

会社の社員を調べる
本物っぽいメールを送る
だまされるのを待つ

というように、相手に合わせて作られる攻撃です。

👉 だから「気づきにくく、防ぎにくい」のが特徴です。

定義・仕組み

標的型攻撃は、次のような流れで行われます。

情報収集
- SNSや公開情報から組織・社員の情報を集める
侵入手段の準備
- 標的に合わせたメールやサイトを作成
侵入（初期感染）
- 添付ファイルやURLを使ってマルウェア感染
内部活動
- 権限取得、情報収集、横展開
目的達成
- 情報窃取、不正送金など

代表的な関連攻撃

水飲み場型攻撃
→ 標的がよくアクセスするサイトを改ざんして感染させる
APT（Advanced Persistent Threat）
→ 長期間にわたって潜伏しながら攻撃を続ける
BEC（ビジネスメール詐欺）
→ 経営者や取引先を装って送金を指示する

👉 これらはすべて「標的型攻撃の一種」として整理できます。

どんな場面で使う？

使う場面（対策を考える場面）

社員へのセキュリティ教育
メール対策（添付・URLチェック）
権限管理（最小権限）
ログ監視・早期検知

特に重要な考え方（SG試験）

完全に防ぐのは難しい
👉 侵入を前提に被害を抑える設計が必要

（例）

多要素認証
権限分離
ログ監視

よくある誤解・混同

❌ 誤解①：特別な技術攻撃だけが標的型攻撃

👉 ⭕ 実際は

メール
人の心理
を使う「だまし」が中心

❌ 誤解②：ウイルス対策ソフトで防げる

👉 ⭕ 標的型は

新種の攻撃
個別に作られた手口
が多く、検知しにくい

❌ 誤解③：侵入されなければ問題ない

👉 ⭕ SG試験では

侵入後の対応（検知・封じ込め）が重要

SG試験のひっかけポイント

「防止策だけ」で解決しようとする選択肢
→ ❌ 不十分

👉 正解は

教育
検知
権限制御
を組み合わせた対策

まとめ（試験直前用）

標的型攻撃＝「特定の相手を狙った攻撃」
特徴は
👉 個別最適・長期・気づきにくい
水飲み場型・APT・BECは仲間
対策は
👉 防止＋検知＋被害抑止の組み合わせ
選択肢では
👉 「人・運用・技術のどれが不足しているか」で判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

不正アクセスの手法とは？攻撃パターンを整理して対策につなげる【情報セキュリティマネジメント】

Source: pages\sg\unauthorized-access-techniques.md
Permalink: /sg/unauthorized-access-techniques/

まず結論

不正アクセスの手法とは、システムの弱点や人のミスを利用して侵入する具体的な攻撃方法であり、SG試験では「どの手法か」ではなく「どの対策で防ぐべきか」を判断させる問題として出題される。

直感的な説明

不正アクセスの手法は、大きく分けると次の3つです。

入口を探す（スキャン・調査）
情報を盗む（盗聴・だまし）
中に入り込む（侵入・権限取得）

つまり、 👉「どうやって入るか」のパターンを知ることで
👉「どこを守ればいいか」が見えてきます。

定義・仕組み

代表的な不正アクセス手法を整理します。

① 調査・情報収集系

ポートスキャン
→ 開いているポート（入口）を探す
スニッフィング（盗聴）
→ ネットワーク上の通信を盗み見る

② 情報漏えい・解析系

テンペスト攻撃
→ 電磁波から画面情報を盗む
サイドチャネル攻撃
→ 消費電力や処理時間などから情報を推測

③ 認証突破・侵入系

ブルートフォース攻撃
→ パスワードを総当たりで試す
辞書攻撃
→ よく使われるパスワードを試す
パスワードリスト攻撃（リスト型攻撃）
→ 流出したID・パスワードを使い回す
フィッシング
→ 偽サイトで認証情報をだまし取る

④ システム脆弱性を突く攻撃

SQLインジェクション
→ 入力欄からデータベースを操作
クロスサイトスクリプティング（XSS）
→ 悪意あるスクリプトを実行させる
バッファオーバーフロー
→ メモリの不具合を利用して不正実行

⑤ 内部侵入後の攻撃

権限昇格（Privilege Escalation）
→ 一般ユーザから管理者権限へ
バックドア設置
→ 再侵入できるように裏口を作る

SG試験では、この中の名前を覚えることよりも
👉「どの段階の攻撃か」を理解することが重要です。

どんな場面で使う？

使う場面

リスクアセスメント（どんな攻撃があり得るか）
セキュリティ対策の設計
インシデント対応（どの手口かの特定）

判断のポイント（実務・試験共通）

「外から探す攻撃」か？
「情報を盗む攻撃」か？
「侵入後の行動」か？

👉 この切り分けができると選択肢を削れます。

よくある誤解・混同

❌ 誤解①：技術的な攻撃だけが不正アクセス

👉 ⭕ 実際は

フィッシング
パスワード使い回し
など人の弱点を突く攻撃も多い

❌ 誤解②：1つの手法で侵入する

👉 ⭕ 実際は

スキャン → 情報収集 → 侵入
と複数の手法を組み合わせる

❌ 誤解③：対策は1つで十分

👉 ⭕ SG試験では

認証（防止）
ログ監視（検知）
権限制御（被害抑止）
を組み合わせる前提で考える

SG試験のひっかけポイント

「パスワード対策」で防げない攻撃を選ばせる問題
（例：テンペストやサイドチャネル）

👉 「どの対策が効くか」で判断する

まとめ（試験直前用）

不正アクセス手法＝「侵入のための具体的なやり方」
攻撃は
👉 調査 → 情報取得 → 侵入 → 権限拡大の流れ
手法は
👉 スキャン系／盗聴系／認証突破系／脆弱性攻撃に分類できる
試験では
👉 「この攻撃に効く対策は何か」で切り分ける

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

不正アクセスとは？攻撃の流れと対策の考え方【情報セキュリティマネジメント】

Source: pages\sg\unauthorized-access.md
Permalink: /sg/unauthorized-access/

まず結論

不正アクセスとは、許可されていない者が情報システムやデータにアクセスする行為であり、SG試験では「攻撃の流れを理解して、どの段階で防ぐか」を判断させる問題として出題される。

直感的な説明

不正アクセスは「いきなり侵入される」わけではありません。

イメージとしては、

下見（どこが弱いか調べる）
鍵を見つける（脆弱性やパスワード）
中に入る（侵入）
さらに奥へ進む（権限拡大）
証拠を消す

という段階的な行動です。

つまり、 👉「どの段階で止めるか」が対策のポイントになります。

定義・仕組み

不正アクセスは、一般的に次のような手順で行われます（攻撃の流れ）：

調査（フットプリンティング）
- 公開情報やネットワーク情報を収集
- 例：ポートスキャン、SNS情報の収集
脆弱性の発見
- システムの弱点を見つける
- 例：未更新のソフト、弱いパスワード
侵入・権限取得
- 不正にログイン、または権限を奪う
- 例：ID・パスワードの不正取得
実行（目的の達成）
- 情報の窃取、改ざん、破壊など
後処理（痕跡隠し）
- ログ削除、バックドア設置

SG試験では、この流れを理解したうえで
👉「どの対策がどの段階に効くか」を問われます。

どんな場面で使う？

使う場面

アクセス制御の設計（認証・認可）
ログ監視・インシデント対応
脆弱性対策（パッチ適用）
社内教育（パスワード管理）

特に重要な考え方

「侵入されない」だけでなく
👉「侵入されても被害を広げない」設計

（例：最小権限、ログ監視）

よくある誤解・混同

❌ 誤解①：不正アクセス＝ハッキングだけ

👉 ⭕ 実際は

パスワード使い回し
内部不正
なども含まれる

❌ 誤解②：侵入されたら終わり

👉 ⭕ SG試験ではここが重要

侵入後の拡大を防ぐ対策が問われる
（例：アクセス権限の分離）

❌ 誤解③：技術対策だけで防げる

👉 ⭕ 実務では

教育（パスワード管理）
運用（ログ監視）
も同じくらい重要

SG試験のひっかけポイント

「侵入防止」だけの対策を選ばせる問題
→ 検知・対応・被害抑止が抜けていないか確認する

まとめ（試験直前用）

不正アクセス＝「許可されていないアクセス」
攻撃は 調査 → 脆弱性 → 侵入 → 実行 → 隠蔽 の流れ
対策は「侵入防止」だけでなく
👉 検知・被害抑止・対応まで含めて考える
選択肢では
👉「どの段階の対策か」を見極めるのがコツ

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ビッシングとは？電話でだます詐欺手口【情報セキュリティマネジメント】

Source: pages\sg\vishing.md
Permalink: /sg/vishing/

まず結論

ビッシングとは、電話を使って利用者をだまし、認証情報や個人情報を聞き出す攻撃です。
SG試験では「電話で聞き出しているかどうか」でフィッシング・スミッシングと区別させる問題がよく出ます。

直感的な説明

「銀行の者ですが、不正利用の可能性があります。本人確認のため暗証番号を教えてください」

こうした“それっぽい電話”で情報を聞き出されるのがビッシングです。

👉 リンクではなく“会話でだます”のがポイント

定義・仕組み

ビッシング（vishing）は、電話（音声）を利用して利用者から情報を不正に取得する攻撃です。
（voice＋phishing の造語）

基本の流れは次の通りです。

攻撃者が電話をかける（または自動音声）
公的機関・金融機関などを装う
利用者に不安や緊急性を与える
暗証番号や認証情報を聞き出す

👉 ユーザーに「口頭で答えさせる」点が特徴

どんな場面で使う？

よくあるケース

銀行・カード会社を装った本人確認
サポートセンターを装った問い合わせ対応
「不正アクセス」「料金未納」などの不安をあおる電話

業務でのポイント

電話でも情報を教えてはいけない教育が必要
折り返し確認（公式番号へ）が重要
コールセンターを狙った攻撃にも注意

👉 人の心理（焦り・信頼）を利用する攻撃

よくある誤解・混同

❌ フィッシングとの違い

フィッシング：メール＋Webサイト
ビッシング：電話

👉 通信手段で区別する

❌ スミッシングとの違い

スミッシング：SMS
ビッシング：電話

👉 テキストか音声かがポイント

❌ 正規の電話との区別

正規：重要情報（暗証番号など）は聞かない
攻撃：暗証番号・パスワードを聞く

👉 「電話で認証情報を聞かれたら疑う」が基本

SG試験でのひっかけ

「電話で本人確認」「口頭で番号を答えさせる」
→ ビッシングと判断
「メール」「SMS」が出てきたら別の攻撃

まとめ（試験直前用）

ビッシング＝電話でだまして情報を聞き出す
「口頭で答えさせる」が最大の特徴
フィッシング（メール）・スミッシング（SMS）と手段で区別
電話で暗証番号を聞く時点で不正と判断

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

WAFとは？Webアプリを守る仕組みを理解する【情報セキュリティマネジメント】

Source: pages\sg\waf.md
Permalink: /sg/waf/

まず結論

WAFとは、Webアプリケーションへの攻撃を検知・遮断する仕組みです。
SG試験では「通信内容を見て攻撃をブロックする対策かどうか」を判断できるかがポイントです。

直感的な説明

WAFは「Web専用の門番」です。

普通のファイアウォールが「通していい通信か」を見るのに対して、
WAFはその中身まで見て「危ないリクエストか」を判断します。

たとえば：

「変なSQL文が入っている」
「怪しいスクリプトが含まれている」

こういったリクエストを見つけて、アプリに届く前に止めるのがWAFです。

定義・仕組み

WAF（Web Application Firewall）は、

Webアプリケーションへの通信内容（HTTPリクエスト）を解析し、
攻撃と判断した場合に遮断する仕組み

です。

主な特徴：

SQLインジェクション対策
クロスサイトスクリプティング（XSS）対策
不正な入力データの検知

仕組みとしては：

リクエストの中身をチェック
ルール（シグネチャ）と照合
攻撃と判断したら遮断

👉 ポイントは
「通信内容（中身）を見て判断する」ことです。

どんな場面で使う？

使うべき場面

Webサービスを公開している場合
入力フォームやログイン機能があるシステム
SQLインジェクションやXSS対策を強化したいとき

誤解しやすい場面

OSやネットワーク全体の防御と混同しやすい
→ WAFはWebアプリ限定の対策です

よくある誤解・混同

❌ よくある誤解

「プログラムの動作範囲を制限する仕組み」
「侵入者をおびき寄せる仕組み」

⭕ 正しい理解

通信内容を解析して攻撃を遮断する仕組み

SG試験でのひっかけ

SG試験では次のように混同させてきます。

「実行範囲を制限する」
　→ サンドボックス
「侵入者を誘導して監視する」
　→ ハニーポット
「通信の中身を見て攻撃を遮断する」
　→ WAF（これが正解）

👉 選択肢では
「攻撃と判定した通信を遮断する」と書かれていたらWAFです。

まとめ（試験直前用）

WAF＝Webアプリへの攻撃を検知・遮断する仕組み
通信の「中身」を見て判断するのが特徴
SQLインジェクション・XSS対策に使う
SG試験では
→ サンドボックス・ハニーポットとの違いで出題されやすい

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

WPA2・WPA3・802.1Xとは？無線LAN認証の違いを整理【情報セキュリティマネジメント】

Source: pages\sg\wifi-auth-wpa2-wpa3-8021x.md
Permalink: /sg/wifi-auth-wpa2-wpa3-8021x/

まず結論

WPA2・WPA3・802.1Xは無線LANの認証方式であり、SG試験では「共通パスワード型（PSK）か、個人認証型（802.1X）か」を見分けることが重要です。

直感的な説明

Wi-Fiの使い方は大きく2パターンあります。

■ パターン①（PSK）

全員同じパスワードで入る
セミナー会場や家庭用Wi-Fi

👉 鍵を知っていれば誰でも入れる

■ パターン②（802.1X）

一人ひとりIDとパスワードでログイン
会社のWi-Fi

👉 個人ごとに管理できる

この違いがそのまま試験ポイントです。

定義・仕組み

■ WPA2 / WPA3（PSK方式）

事前共有鍵（PSK）を使う方式
全員同じパスワードで接続

特徴

設定が簡単
小規模環境向け
鍵が漏れると全員影響

👉 SG試験では
「接続のための共通パスワード」＝PSK

■ 802.1X（エンタープライズ方式）

認証サーバ（RADIUSなど）を使う
利用者ごとに認証

特徴

個人単位で管理できる
不正利用者だけ止められる
大規模・企業向け

👉 SG試験では
「利用者単位で認証する仕組み」

どんな場面で使う？

■ WPA2 / WPA3（PSK）

セミナー会場
カフェのWi-Fi
家庭用ネットワーク

👉 「一時利用・多数参加者」に向いている

■ 802.1X

社内ネットワーク
学校・企業Wi-Fi

👉 「利用者を管理したい環境」に向いている

よくある誤解・混同

❌ WPA2 = 安全ではない

→ 誤解

WPA2自体は広く使われている方式で、
問題は「運用（鍵の使い回し）」です。

❌ PSKでも利用者管理できる

→ できない

👉 全員同じ鍵なので、誰が使っているか分からない

❌ 802.1Xは暗号方式

→ 違う

👉 認証の仕組みです（ここ重要）

SG試験のひっかけ

SG試験ではこう出ます：

「セミナー会場」 → PSK
「利用者ごとに管理」 → 802.1X

👉 環境で判断するのがコツ

まとめ（試験直前用）

WPA2/WPA3（PSK）は共通パスワードで接続する方式
802.1Xは利用者ごとに認証する方式
セミナーや来客用 → PSK
社内ネットワーク → 802.1X
SG試験では「共通か個別か」で切り分ける

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

情報セキュリティ関連法規

著作権の帰属とは？委託開発との違いを理解する【情報セキュリティマネジメント】

Source: pages\sg\copyright-ownership.md
Permalink: /sg/copyright-ownership/

まず結論

外部委託した場合、著作権は原則「委託先」に帰属する
自社の社員などが業務として作成した場合は「会社（法人）」に帰属する
機密保持契約（NDA）は著作権の帰属とは無関係

👉 試験では
「契約がないなら外注＝相手、社内＝自社」
で判断する！

直感的な説明

イメージで考えるとわかりやすいです👇

外注 → 「作った人のもの」
社内 → 「会社の仕事で作ったから会社のもの」

例えば…

フリーランスに開発を頼んだ
　→ 作ったのはフリーランス → その人の著作権
社員が会社の業務として開発した
　→ 会社の仕事 → 会社の著作権

定義・仕組み

■ 原則（超重要）

著作権は
👉 「創作した人」に帰属する

■ 委託開発の場合

外部企業・個人に開発を依頼
作ったのは「委託先」

👉 著作権は委託先に帰属

※発注者に移すには
👉 著作権譲渡契約が必要

■ 社内開発（法人著作）

次の条件を満たすと会社に帰属👇

会社が企画
業務として作成
社員・従業者が作成

👉 会社（法人）が著作者になる

■ 機密保持契約（NDA）

情報を外に漏らさない契約
著作権の帰属とは無関係

👉 著作権は変わらない！

どんな場面で使う？

■ システム開発

外注開発 → 著作権トラブルになりやすい
再利用・改修ができないケースあり

👉 契約で明確にするのが実務

■ 社内開発

自社システム
社員が開発

👉 問題なく会社が利用できる

よくある誤解・混同

❌ 誤解①：お金を払えば著作権ももらえる

👉 間違い

→ お金は「作業の対価」であって
　著作権は別

❌ 誤解②：NDAを結べば著作権も自社になる

👉 間違い

→ NDAは「秘密保持」だけ

❌ 誤解③：外注でも当然自社のもの

👉 間違い（超頻出）

→ 契約がなければ相手のもの

まとめ（試験直前用）

外注 → 著作権は委託先
社内 → 著作権は会社
NDA → 著作権とは無関係

👉 判断基準はこれだけ：

「誰が作ったか？」

🔑 試験テクニック

「契約なし」→ 外注は全部NG
「社員が作成」→ 即正解候補
NDAが出てきたら → ひっかけを疑う

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

著作権譲渡契約とは？ライセンス契約との違いを整理【情報セキュリティマネジメント】

Source: pages\sg\copyright-transfer.md
Permalink: /sg/copyright-transfer/

まず結論

著作権譲渡契約とは「著作権そのものを相手に渡す契約」
SG試験では「譲渡」と「利用許諾（ライセンス）」の違いを判断させる

👉 自由に使いたいなら譲渡、使わせてもらうだけならライセンス

直感的な説明

イメージで整理👇

譲渡 → 「所有権を丸ごと渡す」
ライセンス → 「使っていいよと許可する」

例えば…

譲渡：ソフトを完全に自社のものにする
ライセンス：使う権利だけもらう（改変不可など制限あり）

👉 「持ち主になるか、借りるだけか」の違い

定義・仕組み

■ 著作権譲渡契約

著作権（財産権）を相手に移す契約
移転後は受け取った側が自由に使える

👉 著作権の持ち主が変わる

■ 利用許諾契約（ライセンス）

著作権は元のまま
使用する権利だけ与える

👉 持ち主は変わらない

■ なぜ重要か（実務）

外注開発では👇

契約なし → 委託先に著作権
ライセンスのみ → 制限付き利用
譲渡契約 → 自社で自由に利用可能

👉 要件によって契約を選ぶ必要がある

どんな場面で使う？

■ システム開発（科目Bで重要）

外注したシステムを改修したい
他システムへ流用したい

👉 譲渡契約が必要

■ ソフトウェア利用

パッケージソフト
SaaS

👉 ライセンス契約が一般的

よくある誤解・混同

❌ 委託すれば自社の著作権になる

→ 誤り

👉 契約がなければ委託先

❌ ライセンスがあれば自由に改変できる

→ 誤り

👉 利用範囲は契約で制限される

❌ 譲渡とライセンスは同じ

→ 誤り（超頻出）

👉 全く別物

SG試験のひっかけ

「利用できる」→ ライセンスの可能性あり
「自由に改変・再利用」→ 譲渡が必要

👉 “自由にできるか”を見る

まとめ（試験直前用）

譲渡 → 著作権ごと渡す
ライセンス → 使用許可だけ
外注 → 契約がすべて

👉 判断基準：

自由に使えるか？

→ YES：譲渡
→ NO：ライセンス

懲戒処分とは？有効となる条件とNG例を整理【情報セキュリティマネジメント】

Source: pages\sg\disciplinary-action.md
Permalink: /sg/disciplinary-action/

まず結論

懲戒処分は「就業規則に定めていること」が前提で、内容は合理的である必要がある
SG試験では「就業規則にない処分」「重すぎる処分」を見抜けるかがポイント

直感的な説明

会社は、情報漏えいなどの問題が起きたときに処分をしたくなります。

でも👇

👉 ルールに書いていない罰は与えられない

たとえば

「今回は特別に重い処分にする」
→ これはNG

定義・仕組み

懲戒処分とは

就業規則に基づいて行う制裁
例：戒告、減給、出勤停止、解雇など

有効となる条件（超重要）

SG試験ではここを見ます👇

就業規則に定めがある
内容が合理的である
社会的に相当である

👉 この3つが揃って初めて有効

なぜ必要か

従業員を守るため（会社の暴走防止）
公平なルールを維持するため

どんな場面で使う？

情報セキュリティでの典型例

USB持ち出し違反
パスワード管理違反
情報漏えい

正しい使い方

就業規則に処分内容を明記
違反内容に応じて適切に適用

NGな使い方（試験でよく出る）

就業規則にない処分をする
個別合意で重い処分を設定する
軽微な違反に過剰な処分

よくある誤解・混同

❌ よくある誤解

会社の判断で自由に処分できる
個別合意で重くできる

⭕ 正しい理解

就業規則がすべての基準
個別合意で不利にするのは無効

SG試験のひっかけ

よくある出題👇

「個別合意で重い処分」→ ❌
「就業規則にない処分」→ ❌
「合理的な範囲の処分」→ ⭕

👉 判断基準はこれだけ👇
👉 ルールにあるか＋重すぎないか

まとめ（試験直前用）

懲戒処分は就業規則が前提
就業規則にない処分はNG
重すぎる処分もNG（合理性必要）
個別合意で重くするのはNG
「ルール＋バランス」で判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

労働契約法（不利益変更）とは？就業規則との関係を整理【情報セキュリティマネジメント】

Source: pages\sg\labor-contract-disadvantageous-change.md
Permalink: /sg/labor-contract-disadvantageous-change/

まず結論

就業規則を変更しても、従業員に不利な変更は原則NG（合理性が必要）
SG試験では「勝手なルール変更」と「個別合意との関係」を見抜く問題がよく出る

直感的な説明

会社がルールを変えるとき、こんなケースを考えてみてください👇

罰則を重くする
セキュリティ違反の処分を強化する

これ、会社としてはやりたくなりますよね。

でも👇
👉 会社の都合だけでルールを厳しくするのはNG

なぜかというと
👉 従業員にとって「不利」だから

定義・仕組み

不利益変更とは

就業規則の変更によって
👉 従業員の条件が悪くなること

例👇

罰則が重くなる
制限が増える
給与が下がる

原則ルール（超重要）

👉 SG試験ここが本質

不利益変更 → 原則NG
ただし👇
👉 合理的であれば例外的にOK

「合理性」の判断ポイント（ざっくり）

変更の必要性（セキュリティ強化など）
内容の妥当性（過剰でないか）
従業員への説明・周知

👉 ここが揃って初めてOK

どんな場面で使う？

情報セキュリティでの典型例

情報漏えい時の処分強化
USB利用禁止などのルール追加
監視強化（ログ取得など）

正しい進め方

就業規則を変更
労働者代表の意見を聴く
合理性を確保
周知する

👉 この流れが大事

NGな進め方（試験で出る）

いきなり個別合意で重いルール
周知なしで適用
明らかに過剰な罰則

よくある誤解・混同

❌ よくある誤解

就業規則を変えれば何でも有効
個別合意でカバーできる

⭕ 正しい理解

不利益変更は合理性が必要
個別合意でも不利な内容は無効

SG試験のひっかけ

よくある出題パターン👇

「セキュリティ強化のため厳罰化」→ それだけでは不十分
「個別合意したからOK」→ ❌
「合理性＋手続きあり」→ ⭕

👉 「理由が正しい」だけではダメ
👉 「手続きとバランス」が必要

まとめ（試験直前用）

不利益変更は原則NG
例外は「合理性あり」の場合のみ
就業規則＋意見聴取＋周知がセット
個別合意で不利にするのはNG
「強化＝OK」ではなく「合理性」で判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

労働基準法と労働契約法の違いとは？試験での切り分け方【情報セキュリティマネジメント】

Source: pages\sg\labor-law-difference.md
Permalink: /sg/labor-law-difference/

まず結論

労働基準法＝最低限のルール（会社が守るべき基準）
労働契約法＝契約のルール（就業規則や個別合意の有効性）
SG試験では「どちらの観点の話か」を見抜くことが重要

直感的な説明

ざっくりイメージ👇

労働基準法 → 「これ以下はダメ」ライン
労働契約法 → 「その契約は有効か？」を判断

たとえば

給料を極端に低くする → 労働基準法でNG
就業規則を勝手に変える → 労働契約法でNG

👉 見ているポイントが違う

定義・仕組み

労働基準法（労基法）

最低限の労働条件を定める法律
会社が守る義務

主な内容👇

労働時間
賃金
休憩・休日
就業規則の作成義務

👉 「最低ラインを下回っていないか」を見る

労働契約法

労働契約のルールを定める法律

主な内容👇

就業規則と契約の関係
不利益変更の制限
個別合意の有効性

👉 「そのルールは有効か」を見る

どんな場面で使う？

情報セキュリティでの出題例

労働基準法が関係する場面

就業規則の作成・届出
意見聴取の手続き

労働契約法が関係する場面

個別合意の有効性
不利益変更
懲戒処分の妥当性

判断のコツ（超重要）

SG試験ではここ👇

👉 「最低基準の話？」
👉 「契約の有効性の話？」

これでほぼ切れる

よくある誤解・混同

❌ よくある誤解

労働基準法だけ覚えればOK
就業規則＝絶対有効

⭕ 正しい理解

労働基準法 → 最低ライン
労働契約法 → 有効性チェック

SG試験のひっかけ

典型パターン👇

「就業規則を変更したから有効」→ ❌（契約法でNG）
「最低基準を満たしているからOK」→ ❌（契約法でNGの場合あり）
「合理性あり＋手続きあり」→ ⭕

👉 2つの法律をまたいで判断させてくる

まとめ（試験直前用）

労基法＝最低ライン
契約法＝有効性チェック
就業規則変更は契約法がポイント
不利益変更・個別合意は契約法で判断
「どの法律の話か」で選択肢を切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

安全管理措置とは？個人情報保護法の基本と実務対応【情報セキュリティマネジメント】

Source: pages\sg\safety-control-measures.md
Permalink: /sg/safety-control-measures/

まず結論

安全管理措置とは「個人情報を漏えい・紛失から守るための対策」
SG試験では「どの対策が適切か」を判断させる問題がよく出る

直感的な説明

個人情報は会社にとって「重要な資産」です。

もし👇

USBで持ち出される
メール誤送信される
不正アクセスされる

👉 これ全部アウト

だから👇
👉 事故が起きないように事前にルールと仕組みを作る

これが安全管理措置です

定義・仕組み

安全管理措置は大きく4つに分かれます👇

① 組織的安全管理措置

ルール・体制づくり

例👇

管理責任者の設置
取扱ルールの策定
インシデント対応手順

② 人的安全管理措置

人に対する対策

例👇

従業員教育
秘密保持契約
権限の明確化

③ 物理的安全管理措置

モノの管理

例👇

入退室管理
紙資料の施錠保管
盗難防止

④ 技術的安全管理措置

ITで守る

例👇

アクセス制御
ログ管理
暗号化

👉 この4分類はSG試験でそのまま出ます

どんな場面で使う？

科目Bでの典型パターン

情報漏えい事故の対策検討
委託先の管理
従業員の不正防止

正しい判断例

問題でこう聞かれます👇

「誤送信防止には？」
→ 技術的（送信前チェック）
「従業員の意識向上は？」
→ 人的（教育）
「責任の所在を明確にする」
→ 組織的

よくある誤解・混同

❌ よくある誤解

技術対策だけやればOK
セキュリティ製品を入れれば十分

⭕ 正しい理解

4つ全部必要（バランスが重要）
人・ルール・物理・技術の組み合わせ

SG試験のひっかけ

よくあるパターン👇

「教育なのに技術対策を選ばせる」
「ルールなのにシステム対策を選ばせる」

👉 対策の種類をズラしてくる

まとめ（試験直前用）

安全管理措置＝個人情報を守る対策
4分類（組織・人的・物理・技術）を覚える
問題は「どの分類か」で判断
技術だけでなく人・ルールも重要
「対策の種類ズレ」に注意

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

就業規則と個別合意の関係とは？優先順位を理解する【情報セキュリティマネジメント】

Source: pages\sg\work-rules-vs-individual-agreement.md
Permalink: /sg/work-rules-vs-individual-agreement/

まず結論

就業規則が基準であり、個別合意でそれより不利な条件にはできない
SG試験では「就業規則を無視した個別合意」や「手続き無視」を見抜く問題がよく出る

直感的な説明

会社のルールには「全員に共通のルール（就業規則）」と「個別の約束（個別合意）」があります。

イメージはこんな感じです👇

就業規則 → 会社の“基本ルール”
個別合意 → 業務ごとの“追加ルール”

ただしポイントはここ👇

👉 個別合意は「上乗せ」はOKだが「悪化」はNG

たとえば

OK：秘密情報を具体的に指定する
NG：就業規則より重い罰則を勝手に追加する

定義・仕組み

就業規則とは

労働条件や職場ルールを定めたもの
常時10人以上の従業員がいる会社は作成義務あり
労働基準監督署へ届け出が必要

👉 情報セキュリティもここに書ける（むしろ書くべき）

個別合意とは

従業員ごとに結ぶ契約や取り決め
例：秘密保持契約（NDA）

優先順位（超重要）

👉 SG試験で一番大事なポイント

就業規則（基準）
個別合意（補足）

そして👇

👉 個別合意は就業規則より不利にできない（無効）

就業規則の変更ルール

労働者代表の意見聴取が必要
勝手に変更はNG

どんな場面で使う？

よく出るシチュエーション

情報漏えい対策（秘密保持）
懲戒処分の設定
セキュリティルールの整備

正しい使い方

就業規則で「包括ルール」を決める
個別合意で「具体的な対象」を決める

例👇

就業規則：秘密情報の漏えい禁止
個別合意：このプロジェクトのデータが対象

NGな使い方（試験に出る）

就業規則より重い罰則を個別合意で設定
従業員の意見を聞かずに就業規則を変更

よくある誤解・混同

❌ よくある誤解

個別合意があれば何でも自由に決められる
セキュリティ規定は就業規則に書けない

⭕ 正しい理解

個別合意は就業規則の範囲内で有効
セキュリティルールは就業規則に書いてOK

SG試験のひっかけ

SG試験ではこう聞かれます👇

「個別合意で重い処分」→ ❌
「意見聴取なしで就業規則変更」→ ❌
「個別合意で秘密の範囲を明確化」→ ⭕

👉 「強くする＝OK」ではなく
👉 「ルールの順番を守っているか」で判断する

まとめ（試験直前用）

就業規則が基準、個別合意は補足
個別合意で不利な条件はNG
就業規則変更は意見聴取が必要
セキュリティ規定は就業規則に書ける
「手続き」と「優先順位」で選択肢を切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

テクノロジ

クライアントサーバーシステムとは？役割分担の考え方を理解する【情報セキュリティマネジメント】

Source: pages\sg\client-server-system.md
Permalink: /sg/client-server-system/

まず結論

直感的な説明

イメージとしては「レストラン」です。

クライアント：お客さん（注文する）
サーバー：厨房（料理を作る）

お客さんは全部の料理を自分で作るわけではなく、
厨房に依頼して結果（料理）を受け取りますよね。

ただし最近は、セルフサービスやタブレット注文のように
一部の処理はお客さん側でも行うことがあります。

👉 つまり
「全部サーバー」でも「全部クライアント」でもなく、分担するのがポイントです。

定義・仕組み

クライアントサーバーシステムは以下のような構成です。

クライアント（利用者側）
- 画面表示
- 入力処理
- 一部の計算処理
サーバー（提供側）
- データ管理
- 認証・アクセス制御
- 重要な処理

なぜ分けるのか？

目的は主にこの3つです。

処理の効率化（負荷分散）
セキュリティ確保（重要データはサーバーで管理）
管理の一元化

SG試験では
👉「重要な処理やデータはサーバーに置く」
という考え方がよく問われます。

どんな場面で使う？

使うべき場面

社内システム（勤怠管理・会計システム）
Webサービス（ログイン・データ保存）
業務アプリ全般

👉 特に
「データを安全に管理したいとき」に必須です。

使うと誤解しやすい場面

すべてサーバーで処理する（＝シンクライアント）
すべてクライアントで処理する（＝スタンドアロン）

これらはクライアントサーバーとは別の考え方です。

よくある誤解・混同

① シンクライアントとの違い

シンクライアント
→ クライアントはほぼ処理しない
クライアントサーバー
→ 両方が処理する（ここが正解ポイント）

👉 SG試験では
「クライアントは処理を行わない」と書かれていたら誤りです。

② 冗長化システムとの混同

「複数のシステムで信頼性向上」
→ これは冗長化（可用性の話）

👉 クライアントサーバーは
役割分担の話であり、信頼性の話ではない

③ スタンドアロンとの違い

スタンドアロン
→ 1台で完結
クライアントサーバー
→ 複数で役割分担

SG試験のひっかけポイント

「すべてサーバーで処理」→ ×（シンクライアント）
「すべてクライアントで処理」→ ×（スタンドアロン）
「両方で処理を分担」→ ○（正解）

👉 この3択を切れるようにするのが重要です。

まとめ（試験直前用）

クライアントとサーバーが役割分担して処理する仕組み
重要なデータ・処理はサーバー側で管理
SG試験では「どこで処理するか」を問われる
「全部サーバー」「全部クライアント」は誤り
正解は「両方が処理能力を持ち、使い分ける」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

DHCPとは？IPアドレスを自動で割り当てる仕組み【情報セキュリティマネジメント】

Source: pages\sg\dhcp.md
Permalink: /sg/dhcp/

まず結論

直感的な説明

Wi-Fiにつなぐと、スマホやPCがすぐにインターネットを使えるようになりますよね。

これは裏で
👉「あなたはこのIPアドレスを使ってください」
と自動で割り当てられているからです。

もしDHCPがなければ、

IPアドレス
サブネットマスク
デフォルトゲートウェイ

を全部手入力する必要があります。

つまりDHCPは
👉「ネットワーク接続の初期設定を自動化してくれる仕組み」
です。

定義・仕組み

DHCP（Dynamic Host Configuration Protocol）は、ネットワークに接続する端末に対して、IPアドレスなどの設定情報を自動配布するプロトコルです。

基本の流れはシンプルです。

端末が「IPください」と要求（DHCP Discover）
サーバが「このIP使っていいよ」と提案（Offer）
端末が「それ使います」と返答（Request）
サーバが「OK」と確定（ACK）

この仕組みによって、

IPアドレスの重複防止
設定ミスの削減
管理の効率化

が実現されます。

SG試験では「自動設定」「IP配布」というキーワードが重要です。

どんな場面で使う？

使う場面

社内ネットワークで多数のPCを管理するとき
Wi-Fi環境（家庭・オフィス・カフェなど）
一時的に接続される端末が多い環境

👉「手動設定が現実的でない環境」で使われる

使わない（または注意する）場面

サーバやネットワーク機器（固定IPが必要）
セキュリティ上、IPを固定管理したい場合

👉「重要機器は固定IP」が基本

よくある誤解・混同

SG試験ではここがよく狙われます。

❌ ドメイン名とIPの対応を管理する仕組み

→ これは DNS

❌ 異なるネットワーク間でIPアドレスを変換する仕組み

→ これは NAT

❌ IPアドレスとMACアドレスを対応付ける仕組み

→ これは ARP

ひっかけポイント

DHCP = 「IPを配る」
DNS = 「名前を解決する」
NAT = 「アドレスを変換する」
ARP = 「IPとMACを結びつける」

👉 SG試験では「役割の違い」で切ることが重要

まとめ（試験直前用）

DHCPは「IPアドレスを自動で割り当てる仕組み」
手動設定を不要にし、管理を効率化する
サーバや重要機器は固定IPにするのが基本
DHCPとDNS・NAT・ARPの違いは頻出
選択肢では「自動付与」かどうかで判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

DNSとは？名前解決の仕組みとセキュリティのポイント【情報セキュリティマネジメント】

Source: pages\sg\dns.md
Permalink: /sg/dns/

まず結論

DNSとは、ドメイン名（例：google.com）をIPアドレスに変換する仕組みであり、SG試験では「通信の流れ」と「なりすまし攻撃との関係」を判断させる問題として出題される。

直感的な説明

DNSは「インターネットの住所録」です。

例えば、

「google.com」を入力すると
👉 DNSが「IPアドレス（例：111.202.22.22）」を教えてくれる

👉 その情報をもとにWebサーバにアクセスします。

定義・仕組み

DNS（Domain Name System）は、

👉 人が覚えやすい名前（ドメイン名）
👉 コンピュータが使う住所（IPアドレス）

を対応付ける仕組みです。

基本的な流れ

ユーザがURLを入力
DNSサーバに問い合わせ
IPアドレスを取得
Webサーバに接続
ページが表示される

👉 「DNS → Web通信」の順番が重要

どんな場面で使う？

使う場面

Webサイト閲覧（HTTP/HTTPS）
メール送受信
社内システムへのアクセス

👉 ほぼすべてのネットワーク通信で使われる

SG試験での考え方

DNSは「通信の前段階」
DNSが正しくないと
👉 間違ったサーバに接続してしまう

よくある誤解・混同

❌ 誤解①：DNSが通信している

👉 ⭕ 違う

DNSは「住所を調べるだけ」
実際の通信はHTTP/HTTPS

❌ 誤解②：DNS＝セキュリティ機能

👉 ⭕ 基本は違う

ただの名前解決の仕組み

❌ 誤解③：安全な仕組み

👉 ⭕ ここが重要

DNSは改ざんされると危険

SG試験のひっかけポイント

DNSの問題で「通信内容」について問う選択肢
→ ❌ DNSは通信内容には関与しない

👉 正しくは

「どこに接続するか」を決める仕組み

セキュリティ上の重要ポイント

DNSキャッシュポイズニング
→ 偽のIPアドレスを返して、偽サイトへ誘導

👉 フィッシングや中間者攻撃の入口になる

まとめ（試験直前用）

DNS＝「名前→IPアドレス」の変換
通信の前に必ず使われる仕組み
DNSが改ざんされると
👉 偽サイトに誘導される
試験では
👉 「名前解決か通信か」を切り分ける

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

五大装置とは？コンピュータの基本構成を理解する【情報セキュリティマネジメント】

Source: pages\sg\five-basic-components.md
Permalink: /sg/five-basic-components/

まず結論

五大装置とは、コンピュータを構成する「入力・出力・記憶・演算・制御」の5つの基本機能のこと
SG試験では「どの装置が何を担当しているか」を正しく切り分けられるかが問われる

直感的な説明

コンピュータは、人間の仕事に例えると分かりやすいです。

入力装置：情報を受け取る（目や耳）
記憶装置：覚える（記憶）
演算装置：考える（脳）
制御装置：指示を出す（司令塔）
出力装置：結果を伝える（口や手）

つまり、
「入力 → 記憶 → 演算・制御 → 出力」
という流れで動いています。

定義・仕組み

五大装置は以下の5つです。

① 入力装置

例：キーボード、マウス
役割：外部からデータを取り込む

② 出力装置

例：ディスプレイ、プリンタ
役割：処理結果を外部に出す

③ 記憶装置

主記憶装置（メモリ）：処理中のデータを一時保存
補助記憶装置（HDD/SSD）：長期保存
役割：データやプログラムを保持する

④ 演算装置

CPUの中にある機能
役割：計算やデータ処理を行う

⑤ 制御装置

CPUの中にある機能
役割：各装置に「次に何をするか」を指示する

👉 ポイント

演算装置と制御装置はまとめてCPU（中央処理装置）と呼ばれる

どんな場面で使う？

使う場面

システム構成の理解（科目A）
障害やトラブルの原因切り分け（科目B）

例：

「画面が映らない」→ 出力装置の問題？
「処理が遅い」→ 演算装置（CPU）や記憶装置の問題？

👉 SG試験では
「どの装置の役割か」を判断させる問題が多い

誤解しやすい場面

CPUと記憶装置の役割が混ざる
入力と出力を逆に考える

よくある誤解・混同

❌ よくある誤解①

CPUはデータを保存する装置である
👉 ⭕ 保存は記憶装置、CPUは処理担当

❌ よくある誤解②

マウスは出力装置
👉 ⭕ 入力装置（操作情報を送る）

❌ よくある誤解③

制御装置は計算を行う
👉 ⭕ 計算は演算装置、制御は指示役

SG試験のひっかけ

「処理する」→ 演算装置
「指示する」→ 制御装置
「保存する」→ 記憶装置

👉 この3つを混同させてくる問題が非常に多い

まとめ（試験直前用）

五大装置＝入力・出力・記憶・演算・制御
CPU＝演算装置＋制御装置
判断のコツ
- 取り込む → 入力
- 保存する → 記憶
- 計算する → 演算
- 指示する → 制御
- 表示する → 出力
SG試験では「役割の切り分け」が最重要

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

HTTPとHTTPSの違いとは？安全な通信の判断ポイント【情報セキュリティマネジメント】

Source: pages\sg\http-https.md
Permalink: /sg/http-https/

まず結論

HTTPは暗号化されない通信、HTTPSは暗号化された安全な通信であり、SG試験では「情報が保護されるかどうか」を判断する問題として出題される。

直感的な説明

HTTPとHTTPSの違いは「中身が見えるかどうか」です。

イメージとしては、

HTTP：はがき（誰でも読める）
HTTPS：封筒（中身が見えない）

という違いです。

つまり、

HTTP → 通信内容が見える
HTTPS → 通信内容が見えない

この差がそのまま「安全性の差」になります。

定義・仕組み

HTTPとは

Webページを見るための通信プロトコルで、
TCPの80番ポートを使用します。

特徴：

通信は暗号化されない（平文）
IDやパスワードが盗まれる可能性がある

HTTPSとは

HTTPに暗号化（SSL/TLS）を追加したものです。
TCPの443番ポートを使用します。

特徴：

通信が暗号化される
盗聴や改ざんを防ぐ

SG試験での重要ポイント

HTTP → 危険（情報がそのまま流れる）
HTTPS → 安全（暗号化される）

この「暗号化の有無」で判断します。

どんな場面で使う？

使うべき場面

ログイン画面
個人情報入力
決済処理

→ HTTPSが必須

SG試験でよくある出題

「安全な通信はどれか」 → HTTPSを選ぶ
「情報漏えいのリスクがあるのはどれか」 → HTTPを選ぶ

現場運用での意味

HTTPのまま運用 → 情報漏えいリスク
HTTPSへ移行 → 基本的なセキュリティ対策

つまり、 HTTPSを使うこと自体が情報漏えい対策です。

よくある誤解・混同

❌ HTTPSなら完全に安全

→ ⭕ 暗号化されるが、サイト自体が安全とは限らない

HTTPSは通信を守るだけで、

フィッシングサイト
偽サイト

は防げません。

❌ HTTPでも問題ない場合がある

→ ⭕ 基本的にはHTTPSを使うべき

SG試験では、 HTTPが選択肢にあれば「危険」と判断することが多いです。

❌ URLの違いだけの話

→ ⭕ セキュリティの本質的な違い

http:// → 平文
https:// → 暗号化

見た目だけでなく、仕組みが違うことが重要です。

まとめ（試験直前用）

HTTP＝平文通信（危険）
HTTPS＝暗号化通信（安全）
ポート：80（HTTP）／443（HTTPS）
SG試験では「暗号化されているか」で判断
HTTPSでもサイト自体の安全性は別問題

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

MACアドレスとは？機器を識別する番号の役割【情報セキュリティマネジメント】

Source: pages\sg\mac-address.md
Permalink: /sg/mac-address/

まず結論

MACアドレスとは、ネットワーク機器ごとに製造時に割り当てられる一意の識別番号であり、SG試験では「機器レベルでの識別」と「IPアドレスとの違い」を判断させる問題でよく問われます。

直感的な説明

MACアドレスは「機器の指紋」のようなものです。

IPアドレス：ネットワーク上の住所（変わることがある）
MACアドレス：機器そのものの番号（基本的に変わらない）

たとえば、会社のPCやスマホは
同じネットワークにいても、それぞれ違うMACアドレスを持っています。

👉 「人（IP）ではなく、機械そのもの（MAC）を見分ける」イメージです。

定義・仕組み

MACアドレス（Media Access Controlアドレス）は、
ネットワークインターフェース（NIC）に割り当てられる固有識別子です。

■ 特徴

48ビット（例：00-1A-2B-3C-4D-5E）
製造元ごとに割り当て範囲が決まっている
原則として変更されない（※ソフト的に変更できる場合もある）

■ 通信での役割

同じLAN内では、通信はIPアドレスではなく
最終的にMACアドレスを使って相手を特定します。

そのために使われるのが ARP（Address Resolution Protocol）です。

IPアドレス → MACアドレスに変換して通信する

👉 IPは論理的な住所、MACは物理的な宛先

どんな場面で使う？

■ 使う場面

LAN内通信（同一ネットワーク内）
機器単位でのアクセス制御（MACアドレスフィルタリング）
不正端末の検出

■ 現場での使いどころ（SG試験ポイント）

「特定の端末だけ接続を許可したい」 → MACアドレスで制御する

■ 注意が必要な場面

インターネット通信（WAN） → MACアドレスは使われない（IPが使われる）

よくある誤解・混同

❌ IPアドレスと同じもの

→ ⭕ IPは変わる／MACは基本固定

❌ インターネットでもMACアドレスで通信する

→ ⭕ MACアドレスはLAN内だけで使う

❌ MACアドレスは完全に偽装できない

→ ⭕ ソフト的に変更（なりすまし）できるため、過信はNG

👉 SG試験では
「MACアドレスで完全にセキュリティを確保できる」
という選択肢は誤りとして出やすいです。

まとめ（試験直前用）

MACアドレス＝機器ごとの固有番号（物理アドレス）
LAN内通信で相手を特定するために使う
IPアドレスとは役割が違う（住所 vs 機器）
MACアドレス制御はあるが、なりすまし可能で万能ではない

👉 「LAN内＝MAC」「ネットワーク全体＝IP」この切り分けが最重要

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ポート番号とは？通信先サービスの識別を理解する【情報セキュリティマネジメント】

Source: pages\sg\port-number.md
Permalink: /sg/port-number/

まず結論

直感的な説明

IPアドレスが「建物の住所」だとすると、ポート番号は「部屋番号」です。

IPアドレス → どの機器か
ポート番号 → その機器のどのサービスか

例えば同じサーバでも、

Webサイトを見る → 80番（HTTP）
安全なWeb通信 → 443番（HTTPS）
メール送信 → 25番

のように、同じ住所でも行き先の部屋が違うイメージです。

定義・仕組み

ポート番号は、TCP/IP通信において、通信を受け取るプログラム（サービス）を識別するための番号です。

基本の仕組みは以下の通りです。

送信元が「IPアドレス＋ポート番号」を指定して通信を送る
受信側の機器に届く（IPアドレスで到達）
その機器の中で、ポート番号を見て該当サービスに渡す

主なポート番号の例：

80：HTTP（Web）
443：HTTPS（安全なWeb）
22：SSH（リモート操作）

SG試験では、「ポート番号＝通信内容ではなく通信先のサービス識別」と理解しておくことが重要です。

どんな場面で使う？

① 通信の制御（ファイアウォール）

「80番だけ許可」「22番は禁止」など
→ ポート番号単位で通信を制御する

② 不正アクセス対策

不要なポートを閉じる（ポート閉塞）
→ 攻撃対象を減らす

③ サーバ運用

Webサーバやメールサーバを適切なポートで公開する

SG試験では、
「どのポートを開けるべきか／閉じるべきか」という運用判断でよく出ます。

よくある誤解・混同

❌ 物理的な接続口（LANポートなど）

→ ⭕ ポート番号は論理的な番号（ソフトウェア上）

❌ プロトコルそのものを識別する番号

→ ⭕ 正しくは「そのプロトコルを使うサービス（アプリ）」を識別

❌ データごとに自動で付く番号

→ ⭕ あらかじめ決められた番号（例：80, 443）を使う

SG試験では
「ポート番号＝サービスの識別」か「物理ポート」かを混同させてくる問題が頻出です。

選択肢では
「ケーブル」「接続端子」と書かれていたら誤りと判断できます。

まとめ（試験直前用）

ポート番号＝同一機器内のサービス識別番号
IPアドレス＝機器、ポート番号＝サービス
ファイアウォールはポート単位で制御する
「物理ポート」との混同が典型的なひっかけ
「どの通信を許可・遮断するか」の判断問題でよく出る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

SSHとは？安全な遠隔操作の仕組み【情報セキュリティマネジメント】

Source: pages\sg\ssh.md
Permalink: /sg/ssh/

まず結論

SSHとは、ネットワーク越しに機器を遠隔操作するためのプロトコルで、通信を暗号化することで安全にログイン・操作ができる技術である。

SG試験では「Telnetとの違い（暗号化の有無）」を判断させる問題としてよく出ます。

直感的な説明

SSHは「安全なリモコン操作」です。

Telnetと同じように、

離れた場所から機器を操作できる

という点は同じですが、

違いは、 通信内容が暗号化されていることです。

つまり、

パスワードを入力しても盗まれにくい
操作内容も第三者に見られない

という安全な仕組みになっています。

定義・仕組み

SSH（Secure Shell）は、遠隔操作のためのプロトコルで、 TCPの22番ポートを使用します。

基本の流れは、

クライアントが接続
認証（パスワード or 公開鍵）
暗号化された通信で操作

という形です。

重要なポイントは次の2つです。

通信が暗号化される
認証方法に公開鍵認証が使える

これにより、 盗聴やなりすましのリスクを大幅に低減できます。

どんな場面で使う？

使う場面

サーバやネットワーク機器の遠隔操作
クラウド環境の管理
セキュリティが求められる運用

SG試験で問われる重要ポイント

「安全に遠隔操作する方法はどれか」 → SSHを選ぶ
「平文通信で危険なのはどれか」 → Telnetを除外する

よくある誤解・混同

❌ Telnetと同じもの

→ ⭕ 役割は同じだが安全性が違う

Telnet：暗号化なし（危険）
SSH：暗号化あり（安全）

SG試験ではこの対比が頻出です。

❌ SSHなら完全に安全

→ ⭕ 設定や運用によってはリスクあり

例えば、

弱いパスワード
不適切な公開鍵管理

があると、不正アクセスされる可能性があります。

❌ ポート番号の暗記問題

→ ⭕ 「用途＋安全性」で判断

22番ポート → SSH（安全）
23番ポート → Telnet（危険）

とセットで覚えるのがポイントです。

まとめ（試験直前用）

SSH＝安全な遠隔操作（TCP22番ポート）
通信は暗号化される
Telnetの代替として使われる
SG試験では「安全な選択肢」として出る
Telnetとの違い（暗号化の有無）で判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

Telnetとは？安全でない遠隔操作の仕組み【情報セキュリティマネジメント】

Source: pages\sg\telnet.md
Permalink: /sg/telnet/

まず結論

Telnetとは、ネットワーク越しに機器を遠隔操作するためのプロトコルだが、通信内容が暗号化されないため不正アクセスの原因になりやすい技術である。

SG試験では「なぜ攻撃対象になるか（初期パスワード＋平文通信）」を判断させる問題としてよく出ます。

直感的な説明

Telnetは「離れた場所から機器を直接操作できる仕組み」です。

イメージとしては、

自分のキーボード操作が
そのままネットワーク越しに機器に届く

という感じです。

ただし問題は、 ID・パスワードや操作内容がそのまま見える状態で送られることです。

さらにIoT機器では、

初期パスワードのまま運用されている
外部からアクセスできる状態になっている

ことが多く、
簡単にログインされて乗っ取られる原因になります。

定義・仕組み

Telnetは、TCPの23番ポートを使って通信する遠隔操作用プロトコルです。

基本の流れは、

クライアントが接続
ID・パスワードでログイン
コマンド操作を実行

というシンプルな仕組みです。

重要なポイントは次の2つです。

通信が暗号化されない（平文通信）
認証情報（ID・パスワード）がそのまま流れる

このため、 盗聴や不正ログインに非常に弱いという特徴があります。

また、IoT機器では

メンテナンス用にTelnetが有効
初期ID（root / admin など）が残っている

ケースがあり、攻撃の入口になります。

どんな場面で使う？

使う場面

ネットワーク機器やサーバの遠隔操作（旧環境）
IoT機器のメンテナンス用アクセス

SG試験で問われる重要ポイント

「Telnetが開いている」＝攻撃されやすい状態
「初期パスワード」＝不正ログインされやすい状態

この2つがセットで出ることが多いです。

使うと危険な場面

インターネットに公開されたまま使用
初期パスワードのまま運用

この場合、 不正ログイン → 機器乗っ取り → ボット化 につながります。

実際に、IoT機器を狙うマルウェア（例：Mirai）は、この弱点を利用して大量感染を広げました。

よくある誤解・混同

❌ SSHと同じ安全な遠隔操作

→ ⭕ Telnetは暗号化なし、SSHは暗号化あり

SG試験では、「遠隔操作できる＝安全」と誤解させる選択肢に注意です。

❌ メールやWeb通信に使われる

→ ⭕ Telnetは遠隔操作専用

SMTP（メール送信）＝25番ポート
HTTP（Web）＝80番ポート

と混同させてきます。

❌ ポート番号の暗記問題

→ ⭕ 「用途＋リスク」で判断する

SG試験では、

23番ポート → Telnet（遠隔操作）
平文通信 → 危険
初期パスワード → 不正ログイン

という組み合わせで切ることが重要です。

まとめ（試験直前用）

Telnet＝遠隔操作（TCP23番ポート）
通信は暗号化されない（平文）
初期パスワードと組み合わさると危険
IoT機器の乗っ取り（ボット化）の原因になる
SSHとの違い（暗号化あり／なし）で判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

マネジメント

稼働率とは？可用性の考え方とSLAでの判断基準【情報セキュリティマネジメント】

Source: pages\sg\availability.md
Permalink: /sg/availability/

まず結論

稼働率とは「サービスが使える状態だった割合」であり、可用性（Availability）を数値で表したもの
SG試験では「どの時間を対象にするか」と「停止時間の扱い」を正しく判断できるかが問われる

直感的な説明

稼働率はシンプルに言うと、

👉 「どれくらい止まらずに動いていたか」

です。

例えば会社のシステムで、

50時間中1時間止まった → ほぼ動いている
50時間中10時間止まった → かなり止まっている

👉 この「ちゃんと使えた割合」が稼働率です。

定義・仕組み

稼働率は、基本的に次の考え方で求めます。

👉 稼働率＝（稼働時間）÷（サービス提供時間）

別の言い方をすると、

👉 稼働率＝（サービス提供時間 − 停止時間）÷ サービス提供時間

MTBF・MTTRとの関係

MTBF：平均故障間隔（どれくらい長く動くか）
MTTR：平均復旧時間（どれくらいで直るか）

👉 稼働率は次の関係でも表せます

稼働率＝ MTBF ÷（MTBF ＋ MTTR）

SG試験での重要ポイント

① 分母を間違えない

❌ 24時間 × 日数
⭕ サービス提供時間だけ

② 停止時間の扱い

障害停止 → 含める
計画停止 → 条件次第

👉 「サービス提供時間外なら含めない」

③ 条件文を読む

営業日
提供時間帯
停止の条件

👉 ここを読み取る問題

どんな場面で使う？

使う場面

SLA（サービスレベル合意）で品質を決めるとき
クラウドやシステム運用の評価
業務システムの安定性判断

👉 SG試験では
「この稼働率は妥当か？」と判断させる問題が出る

注意が必要な場面

可用性（概念）と稼働率（数値）を混同する
提供時間と全時間を混同する
回数制限と時間制限を混同する

よくある誤解・混同

❌ 誤解①

「稼働率は常に24時間基準」

👉 ⭕ サービス提供時間が基準

❌ 誤解②

「停止回数も計算に使う」

👉 ⭕ 稼働率は時間だけを見る

❌ 誤解③

「計画停止は全部含める」

👉 ⭕ 条件文で判断する

SG試験のひっかけ

「営業日」「時間帯」を無視させる
「MTBF・MTTR」を出して混乱させる
「回数制限」を計算に入れさせる

👉 選択肢では
分母がズレているものを切る

まとめ（試験直前用）

稼働率＝使えた時間 ÷ 提供時間
分母は「サービス提供時間」
停止時間は「条件文で判断」
回数ではなく「時間」で考える
SG試験は
👉 「何を分母にしたか」で正誤が決まる

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

契約不適合責任とは？瑕疵担保責任との違いも整理【情報セキュリティマネジメント】

Source: pages\sg\contract-nonconformity.md
Permalink: /sg/contract-nonconformity/

まず結論

契約不適合責任とは「契約どおりでない成果物に対する責任」
SG試験では「完成後の不具合の責任」を問う問題で出る

👉 契約どおりかどうかで判断する

直感的な説明

イメージで考えると👇

約束したものと違う → 責任あり
約束どおり → 問題なし

例えば…

「この機能を持つシステム」と契約
→ 実際は機能が足りない

👉 契約不適合 → 責任発生

定義・仕組み

■ 契約不適合責任

成果物が契約内容と一致しない場合に発生
修正・損害賠償などの責任を負う

👉 契約とのズレがポイント

■ 何が請求できる？

発注側は👇を要求できる

修補（修正）
代替品の提供
損害賠償
契約解除

👉 状況に応じて選択できる

■ 旧制度との違い（軽く）

旧：瑕疵担保責任（キズがあるか）
新：契約不適合責任（契約どおりか）

👉 「契約基準」に変わった

どんな場面で使う？

■ システム開発（請負契約とセット）

納品されたシステムに不具合
要件どおり動かない

👉 契約不適合責任が問題になる

■ 委託先管理（科目B）

ベンダーとのトラブル
納品後の対応

👉 契約内容が重要になる

よくある誤解・混同

❌ バグがあればすべて責任になる

→ 誤り

👉 契約に含まれていなければ対象外

❌ 完成していれば問題ない

→ 誤り

👉 完成していても契約と違えばNG

❌ 準委任契約でも同じ責任がある

→ 誤り（重要）

👉 原則は請負契約で問題になる

SG試験のひっかけ

「契約どおり」→ OK
「期待どおり」→ NGの可能性

👉 “契約”という言葉に注目する

まとめ（試験直前用）

契約不適合責任 → 契約と違えば発生
判断基準 → 「契約どおりか？」
請負契約とセットで出る

👉 YES → 問題なし
👉 NO → 責任発生

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

就業形態の違いを完全整理【SG試験で迷わない判断基準】

Source: pages\sg\employment-type-comparison.md
Permalink: /sg/employment-type-comparison/

まず結論

就業形態は「雇用契約先」と「指揮命令者」で切り分ける
SG試験では「誰に責任があるか」を判断させる問題として出題される

直感的な説明

同じ職場にいても、実はこんな違いがあります。

社員A → 会社に直接雇われている
社員B → 別の会社に雇われて派遣されている

👉 見た目ではなく
👉 「誰と契約しているか」が本質

定義・仕組み

■ まずは全体の切り分け（超重要）

区分	雇用契約先	指揮命令
正社員・契約社員・アルバイト・パート	就業先企業	就業先企業
派遣社員	派遣会社	就業先企業

👉 ここが最重要
派遣だけ「雇用」と「指示」が分かれる

■ 就業形態の違いまとめ（試験対策用）

以下の表で「契約期間・労働時間・雇用契約先」を整理しておくと、SG試験で迷いません。

就業形態	契約期間	労働時間	雇用契約先
アルバイト	有限	短時間	就業先企業
契約社員	有限	正社員と同じ	就業先企業
派遣社員	（契約は派遣会社と）	正社員と同じ	人材派遣会社
パートタイマー	なし（または柔軟）	短時間	就業先企業

👉 SG試験での最重要ポイント

派遣社員だけ「雇用契約先」が違う（＝人材派遣会社）

👉 切り分けのコツ

「その人は誰に雇われているか？」で判断する

■ 個別の違い

正社員

無期雇用（期間の定めなし）
フルタイムが基本

契約社員

有期契約（期間あり）
仕事内容・条件が明確

アルバイト

有期契約
短時間・副業的な位置づけが多い

パートタイマー

短時間勤務
労働時間が短いことが特徴

派遣社員（最重要）

雇用契約 → 派遣会社
指揮命令 → 就業先企業

👉 SG試験ではここが狙われる

どんな場面で使う？

■ SG試験での典型パターン

① 教育・訓練の責任

派遣社員 → 派遣会社と就業先の両方が関係
直接雇用 → 自社が責任

② 情報セキュリティ事故

誰が責任を負うか？ → 雇用契約・指揮命令で判断

③ 委託先管理

派遣社員は「外部扱い」に近い

👉 科目Bでめちゃくちゃ出るポイント

よくある誤解・混同

❌ よくある誤解①

「同じ場所で働いている＝同じ会社の社員」

👉 完全にNG

❌ よくある誤解②

「契約社員は外部の人」

👉 誤り
→ 契約社員は内部（直接雇用）

❌ よくある誤解③

「派遣社員は就業先と契約している」

👉 誤り（超頻出） → 契約は派遣会社

SG試験のひっかけまとめ

「派遣社員＝自社の従業員」→ ❌
「契約社員＝外部」→ ❌
「パート＝特別な制度」→ ❌（ただの短時間労働）

まとめ（試験直前用）

判断基準はこの2つだけ
→ 雇用契約先
→ 指揮命令者
直接雇用
→ 正社員・契約社員・アルバイト・パート
派遣社員
→ 雇用：派遣会社
→ 指示：就業先

👉 迷ったらこれ
「派遣だけ別物」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

MTBFとは？平均故障間隔の意味と稼働率との関係【情報セキュリティマネジメント】

Source: pages\sg\mtbf.md
Permalink: /sg/mtbf/

まず結論

MTBFとは「故障してから次に故障するまでの平均時間（どれくらい長く動き続けるか）」を表す指標
SG試験では「MTTRとの違い」と「稼働率との関係」を正しく切り分けられるかが問われる

直感的な説明

MTBFはシンプルに言うと、

👉 「どれくらい壊れにくいか」

です。

例えば、

MTBFが長い → なかなか壊れない（安定）
MTBFが短い → すぐ壊れる（不安定）

👉 「連続して動ける時間の長さ」と考えると分かりやすいです。

定義・仕組み

MTBF（Mean Time Between Failures）は、

👉 1回の故障から次の故障までの平均稼働時間

を表します。

イメージ

システムの状態は次のように繰り返します。

稼働 → 故障 → 修理 → 稼働 → 故障 → 修理

👉 このうち
「稼働している時間の平均」がMTBF

MTTRとの関係

MTBF：どれだけ長く動くか（稼働時間）
MTTR：どれだけ早く直るか（停止時間）

👉 セットで出題されることが多い

稼働率との関係

稼働率は次の関係で表されます。

👉 稼働率＝ MTBF ÷（MTBF ＋ MTTR）

SG試験でのポイント

MTBFが長い → 故障しにくい → 可用性が高い
MTBFが短い → 故障しやすい → 可用性が低い

👉 可用性（稼働率）とセットで考える

どんな場面で使う？

使う場面

システムの信頼性評価
サーバやネットワーク機器の選定
SLAの設計（どの程度安定させるか）

👉 科目Bでは
「この構成は安定か？」を判断する材料になる

注意が必要な場面

MTTRと混同する
「復旧時間」と勘違いする
稼働率そのものと勘違いする

よくある誤解・混同

❌ 誤解①

「MTBFは復旧時間」

👉 ⭕ MTBFは
“壊れていない時間”

❌ 誤解②

「MTBFが長ければ復旧も早い」

👉 ⭕ 無関係
復旧の速さはMTTR

❌ 誤解③

「MTBF＝稼働率」

👉 ⭕ 違う
稼働率はMTTRとセットで決まる

SG試験のひっかけ

MTBFとMTTRを入れ替えて出す
「平均復旧時間」と書いてMTBFを選ばせる
稼働率と混同させる

👉 選択肢では
“壊れていない時間か？”を確認する

まとめ（試験直前用）

MTBF＝故障と故障の間の時間（稼働時間）
長いほど「壊れにくい」
MTTRとセットで覚える
稼働率はMTBFとMTTRで決まる
SG試験は
👉 「壊れている時間か？動いている時間か？」で切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

MTTRとは？平均復旧時間の意味と短縮の考え方【情報セキュリティマネジメント】

Source: pages\sg\mttr.md
Permalink: /sg/mttr/

まず結論

MTTRとは「障害が発生してから復旧するまでの平均時間」を表す指標
SG試験では「MTBFとの違い」と「短縮するための運用」を判断できるかが問われる

直感的な説明

MTTRはシンプルに言うと、

👉 「どれくらい早く直せるか」

です。

例えば、

MTTRが短い → すぐ復旧できる（影響が小さい）
MTTRが長い → 復旧に時間がかかる（業務影響が大きい）

👉 「止まった後、どれだけ早く元に戻せるか」と考えると分かりやすいです。

定義・仕組み

MTTR（Mean Time To Repair / Recovery）は、

👉 障害発生から復旧完了までの平均時間

を表します。

イメージ

システムは次のように動きます。

稼働 → 故障 → 修理 → 稼働

👉 このうち
「故障している時間」がMTTR

MTBFとの関係

MTBF：壊れていない時間（稼働時間）
MTTR：壊れている時間（復旧時間）

👉 この2つでシステムの可用性が決まる

稼働率との関係

👉 稼働率＝ MTBF ÷（MTBF ＋ MTTR）

MTTRが短い → 稼働率が上がる
MTTRが長い → 稼働率が下がる

SG試験でのポイント

MTTRは「短いほど良い」
運用改善で短縮できる指標

👉 技術よりも運用の問題として問われることが多い

どんな場面で使う？

使う場面

障害対応プロセスの評価
インシデント管理（復旧対応）
SLAでのサービス品質管理

👉 科目Bでは
「復旧を早くするには何をすべきか？」が問われる

MTTRを短くする具体例

手順書の整備（対応の標準化）
監視の強化（早期検知）
予備機・バックアップの準備
担当者教育・訓練

👉 これがそのまま選択肢になる

よくある誤解・混同

❌ 誤解①

「MTTRは壊れにくさの指標」

👉 ⭕ 違う
復旧の速さの指標

❌ 誤解②

「MTTRが長い＝安定している」

👉 ⭕ 逆
復旧が遅いだけ

❌ 誤解③

「MTBFと同じ意味」

👉 ⭕ 完全に別

MTBF：壊れない時間
MTTR：直す時間

SG試験のひっかけ

MTBFとMTTRを逆にする
「平均復旧時間」をMTBFと誤認させる
技術対策と運用対策を混同させる

👉 選択肢では
「復旧を早くする話か？」を見る

まとめ（試験直前用）

MTTR＝復旧までの時間
短いほど良い（影響が小さい）
MTBFとセットで覚える
稼働率に直接影響する
SG試験は
👉 「復旧の速さの話か？」で判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

請負契約と派遣契約の違いとは？指示系統で判断するポイント【SG試験】

Source: pages\sg\outsourcing-contract-difference.md
Permalink: /sg/outsourcing-contract-difference/

まず結論

請負契約は「成果物に責任を持つ契約」、派遣契約は「人を提供して指示を受けて働く契約」
SG試験では「誰が誰に作業指示できるか」を判断させる問題としてよく出題される

直感的な説明

外注の形には大きく2パターンあります。

請負契約
→「仕事を丸ごと任せる（結果で評価）」
派遣契約
→「人を借りて、自分たちの指示で働いてもらう」

例えば、

ホームページ制作を丸投げ → 請負
エンジニアを常駐させて作業 → 派遣

というイメージです。

この違いが、指示を出してよい相手を決めます。

定義・仕組み

請負契約

成果物に対して責任を持つ契約
発注元（依頼する側）は、作業の中身に直接口出ししない
作業指示は「受注側の責任者」が行う

👉 ポイント
発注元 → 作業者に直接指示はNG

派遣契約

人材を提供し、派遣先の指示で働く契約
作業指示は「派遣先」が行う

👉 ポイント
派遣先 → 作業者に直接指示OK

SG試験での本質

SG試験では細かい法律よりも、

👉「指示系統が正しいかどうか」

を判断させる問題が中心です。

どんな場面で使う？

請負契約が使われる場面

システム開発を一括委託
保守運用を外部に丸投げ

👉 「成果で責任を持たせたい」とき

派遣契約が使われる場面

社内に常駐して開発
チームの一員として作業

👉 「自分たちで指示して動かしたい」とき

注意すべき場面

SG試験では、

請負なのに直接指示している
派遣なのに指示していない

という「逆パターン」がよく出ます。

よくある誤解・混同

❌ 請負でも細かく指示してよい

→ NG

請負では、発注元が作業者に直接指示するのは不適切
（指示は受注側の責任者経由）

❌ 派遣なら何でも自由に指示できる

→ 注意

業務指示はできるが、

就業条件の変更
契約内容の変更

などは別問題

SG試験のひっかけ

SG試験では次のように問われることが多いです。

「A社がB社の要員に直接指示」→ 不適切（請負）
「派遣なのに指示していない」→ 不適切
「就業条件を現場で勝手に変更」→ 不適切

👉 「指示してよい関係か？」で切る

まとめ（試験直前用）

請負：成果物責任 → 直接指示NG
派遣：労働提供 → 直接指示OK
SG試験では「指示系統」が最重要ポイント
選択肢では「誰が誰に指示しているか」を必ず確認する
「契約形態と指示の関係がズレていたら誤り」と判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

SLAの問題まとめ（稼働率の考え方と計算のコツ）【情報セキュリティマネジメント】

Source: pages\sg\sla-summary.md
Permalink: /sg/sla-summary/

まず結論

SLA（サービスレベル合意）の問題は「サービス提供時間」と「停止時間」を正しく切り分けて、稼働率を判断する問題
SG試験では「どの時間を分母にするか」「どの停止を含めるか」を見極めさせる

直感的な説明

SLAは「どれくらいちゃんとサービスを動かすか」という約束です。

例えば会社のシステムでいうと、

営業時間中は止まると困る
夜間のメンテナンスはOK

というように、「止まっていい時間」と「ダメな時間」があります。

👉 つまり
“全部の時間”ではなく“約束した時間だけ”で考えるのがポイントです。

定義・仕組み

SLA（Service Level Agreement）は、サービス提供者と利用者の間で決める「品質の約束」です。

SG試験では特に「可用性（稼働率）」がよく問われます。

基本の考え方

稼働率＝（サービス提供時間 − 停止時間） ÷ サービス提供時間

ここで重要なのは次の3点です。

① 分母（サービス提供時間）

24時間ではなく「サービス提供時間帯」を使う
例：営業日9時〜19時 → 1日10時間

👉 SG試験では
「提供時間を読み取れるか」が最重要ポイント

② 停止時間に含めるもの

障害停止 → 含める
計画停止 → 条件による

👉 「サービス提供時間帯に行わない」と書いてあれば
計画停止は含めない

③ 複数条件の扱い

例：

停止回数：2回以下
停止時間：合計1時間以内

👉 稼働率に使うのは
「合計時間」だけ

回数は品質管理の条件であり、計算には使わない

どんな場面で使う？

使う場面

委託先との契約（クラウド・システム運用）
社内システムの運用ルール決定
サービス品質の評価

👉 科目Bでは
「この条件で妥当か？」を判断させる問題が出る

注意が必要な場面

24時間サービスと勘違いする
計画停止を全部含めてしまう
回数制限を時間に換算してしまう

よくある誤解・混同

❌ よくある誤解①

「1週間＝24時間×7日で計算する」

👉 ⭕ 正しくは
サービス提供時間だけ使う

❌ よくある誤解②

「停止2回だから2時間止まると考える」

👉 ⭕ 正しくは
“合計時間”が上限

❌ よくある誤解③

「計画停止も全部ダウン時間に入れる」

👉 ⭕ 条件文を確認
提供時間外ならカウントしない

SG試験のひっかけ

「営業日」「提供時間帯」を読み飛ばさせる
「回数」と「時間」を混同させる
「計画停止」を入れるか迷わせる

👉 選択肢では
“24時間で計算しているもの”はほぼ誤り

まとめ（試験直前用）

稼働率は「サービス提供時間」を分母にする
停止時間は「合計時間」で判断（回数は使わない）
計画停止は条件を確認（時間外なら含めない）
SG試験では
👉 「何を分母にするか」でほぼ決まる

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

SLAとは？サービス品質の約束を理解する【情報セキュリティマネジメント】

Source: pages\sg\sla.md
Permalink: /sg/sla/

まず結論

SLAとは「サービスの品質を数値で約束する取り決め」
SG試験では「サービスの品質管理」と「責任範囲」を判断させる問題で出る

👉 どこまで保証しているかを数値で確認する

直感的な説明

イメージで考えると👇

「だいたい動く」 → NG
「99.9％動く」 → OK

例えば…

システムの稼働率 99.9％
障害対応時間 1時間以内

👉 サービスのレベルを見える化したもの

定義・仕組み

■ SLA（Service Level Agreement）

サービス提供者と利用者の間の合意
品質を数値で定義する

👉 曖昧さをなくすための契約

■ 主な項目

稼働率（可用性）
応答時間
障害対応時間
サポート時間

👉 測れるものを決めるのがポイント

■ なぜ重要か

トラブル時の判断基準になる
「できているかどうか」を客観的に判断できる

どんな場面で使う？

■ クラウドサービス

SaaS / IaaS
外部サービス利用

👉 SLAで品質を確認する

■ 委託先管理（科目B）

運用・保守の外注
ベンダー管理

👉 「どこまでやるか」を明確にする

よくある誤解・混同

❌ SLAがあれば絶対に障害は起きない

→ 誤り

👉 あくまで「保証レベル」であってゼロにはならない

❌ SLAは努力目標

→ 誤り

👉 合意事項なので守るべき基準

❌ SLAと契約は別物

→ 誤り（重要）

👉 契約の一部として扱われることが多い

SG試験のひっかけ

「高品質」など曖昧な表現 → NG
「99.9％」など数値 → SLA

👉 数値かどうかで見分ける

まとめ（試験直前用）

SLA → サービス品質の数値化
判断基準 → 「数値で定義されているか」
委託先管理で重要

👉 数値あり → SLA
👉 曖昧表現 → NG

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

ストラテジ

請負契約と準委任契約の違いとは？成果物か作業かで判断【情報セキュリティマネジメント】

Source: pages\sg\contract-types.md
Permalink: /sg/contract-types/

まず結論

請負契約：成果物を完成させる責任がある契約
準委任契約：作業を行うことが目的の契約

👉 SG試験では
「成果物の完成責任があるか」で判断する

直感的な説明

イメージで整理👇

請負 → 「完成させるまでが仕事」
準委任 → 「作業することが仕事」

例えば…

システムを完成させる契約 → 請負
運用や保守を行う契約 → 準委任

👉 「ゴールがあるかどうか」で見る

定義・仕組み

■ 請負契約

成果物の完成が目的
完成させる義務あり

👉 完成できなければ責任が発生

■ 準委任契約

作業の実施が目的
完成義務はない

👉 適切に作業していればOK

■ 責任の違い（重要）

請負 → 成果物の品質・完成に責任
準委任 → 作業の過程に責任

👉 ここが最大の違い

どんな場面で使う？

■ 請負契約

システム開発
ソフトウェア納品

👉 完成物がある仕事

■ 準委任契約

運用・保守
監視業務
コンサル

👉 継続的な作業

よくある誤解・混同

❌ 作業していれば請負でもOK

→ 誤り

👉 請負は完成しないとダメ

❌ 準委任でも完成責任がある

→ 誤り

👉 完成義務はない

❌ 委託＝全部同じ契約

→ 誤り（頻出）

👉 請負と準委任は別物

SG試験のひっかけ

「完成させる」→ 請負
「支援する」「運用する」→ 準委任

👉 動詞に注目すると切れる

まとめ（試験直前用）

請負 → 成果物の完成責任あり
準委任 → 作業の実施のみ
判断基準 → 「完成が必要か？」

👉 YES → 請負
👉 NO → 準委任

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

プロジェクトライフサイクルの特性とは？頻出パターンを整理【情報セキュリティマネジメント】

Source: pages\sg\project-lifecycle-characteristics.md
Permalink: /sg/project-lifecycle-characteristics/

まず結論

プロジェクトライフサイクルでは「人員は途中が最大・リスクは初期が最大・変更影響は後半ほど大きい」が基本であり、SG試験ではこのパターンを使って選択肢を切る問題がよく出ます。

直感的な説明

プロジェクトを「家づくり」で考えるとイメージしやすいです。

最初（設計段階）
→ まだ決まっていないことが多く、不確実（リスク）が大きい
→ 人は少ない
途中（工事中）
→ 作業が一番多く、人も最大
最後（完成直前）
→ 変更すると大きな手戻りになる
→ 影響が大きくなる

👉 「最初は不確実」「途中は忙しい」「最後は変えるとヤバい」
これだけでかなり解けるようになります。

定義・仕組み

プロジェクトライフサイクルの一般的な特性は、次の3つで整理できます。

① 要員数（人員）

開始時：少ない
実行中：最大
終盤：減少

👉 山型になる

② リスク（不確実性）

開始時：最大
進行とともに減少

👉 情報が増えるほど不確実性は減る

③ 変更・修正の影響（コスト）

開始時：小さい
終盤：最大

👉 後戻りコストが大きくなるため

④ ステークホルダの影響力

開始時：最大
進行とともに低下

👉 最初は自由に決められるが、後半は変更しづらい

どんな場面で使う？

SG試験では、次のような形でよく問われます。

「どのタイミングでリスクが最大か？」
「変更の影響が大きいのはいつか？」
「人員が最も多いのはいつか？」

また、科目Bでは次の判断にもつながります。

なぜ初期にリスク評価（リスクアセスメント）をするのか
なぜ早い段階で仕様を固める必要があるのか

👉 「後で直すほどコストが高い」ため

よくある誤解・混同

❌ 要員は最初が最大

→ 誤り 👉 実際は「途中が最大（山型）」

❌ 変更の影響は後半ほど小さい

→ 誤り 👉 実際は「後半ほど影響が大きい」

❌ ステークホルダの影響は最後が最大

→ 誤り 👉 実際は「最初が最大」

❌ リスクは後半ほど大きい

→ 誤り 👉 実際は「最初が最大 → 減少」

SG試験のひっかけ

SG試験では、次のように逆の表現で出してきます。

「最初が最大」
「後半は影響が小さい」

👉 違和感があったら逆を疑う

まとめ（試験直前用）

人員 → 途中が最大（山型）
リスク → 最初が最大 → 減少
変更影響 → 後半ほど大きい
影響力 → 最初が最大

👉 「最初＝自由・不確実」「最後＝変更が重い」で覚える

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

SG NotebookLM Export

⭐ まず読む3記事

⭐ まず読む3記事

ポート番号とは？通信先サービスの識別を理解する【情報セキュリティマネジメント】

まず結論

直感的な説明

定義・仕組み

どんな場面で使う？

① 通信の制御（ファイアウォール）

② 不正アクセス対策

③ サーバ運用

よくある誤解・混同

❌ 物理的な接続口（LANポートなど）

❌ プロトコルそのものを識別する番号

❌ データごとに自動で付く番号

まとめ（試験直前用）

🔗 関連記事

DHCPとは？IPアドレスを自動で割り当てる仕組み【情報セキュリティマネジメント】

まず結論

直感的な説明

定義・仕組み

どんな場面で使う？

使う場面

使わない（または注意する）場面

よくある誤解・混同

❌ ドメイン名とIPの対応を管理する仕組み

❌ 異なるネットワーク間でIPアドレスを変換する仕組み

❌ IPアドレスとMACアドレスを対応付ける仕組み

ひっかけポイント

まとめ（試験直前用）

🔗 関連記事

クライアントサーバーシステムとは？役割分担の考え方を理解する【情報セキュリティマネジメント】

まず結論

直感的な説明

定義・仕組み

なぜ分けるのか？

どんな場面で使う？

使うべき場面

使うと誤解しやすい場面

よくある誤解・混同

① シンクライアントとの違い

② 冗長化システムとの混同

③ スタンドアロンとの違い

SG試験のひっかけポイント

まとめ（試験直前用）

🔗 関連記事

📝 試験概要

📝 試験概要

情報セキュリティマネジメント試験とは？役割・対象者・試験の位置づけを整理

まず結論

なぜ必要とされているのか

情報セキュリティマネジメント試験とは

この試験で期待される役割

どんな人に向いているか

試験実施の概要

まず最初に確認したい公式ページ

まとめ

情報セキュリティマネジメント試験の出題内容とは？科目A・科目Bと勉強方法を整理

まず結論

出題内容の全体像

科目Aで問われること

重点分野

関連分野

科目Bで問われること

出題の特色

1. 身近な事例をベースにした実践的な出題

2. 国際・国内標準や公的ガイドラインに基づく出題

試験時間と形式

勉強方法

1. 最初に科目Aの重点分野を固める

2. 科目Bはケース問題として読む練習をする

3. 公開問題で形式に慣れる

4. 試験直前は「頻出論点の再確認」に絞る

おすすめの学習順

参考にした公式ページ

まとめ

情報セキュリティ全般

情報セキュリティ全般

攻撃者の種類とは？目的と特徴で整理する【情報セキュリティマネジメント】

まず結論