情報セキュリティ全般

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

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を疑う

🔗 関連記事

関連記事は準備中です。

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