Go to Qiita Advent Calendar Top
LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@karuking0105

【情報セキュリティマネジメント試験】対策用学習メモ

Last updated at Posted at 2025-12-17

稼働率（可用性）の基本

稼働率とは、
そのシステムがどれだけ故障せずに動けているかの割合 のことです。

1. 直列構成（シリーズ構成）の稼働率

  • 複数の機器が「縦につながっている」イメージ。
  • 一つでも故障すると全体が止まる。
  • 全体稼働率：機器A・Bが直列、単体の稼働率Pとした場合 $$ P^{2} $$

2. 並列構成（冗長構成）の稼働率

  • 複数の機器が「バックアップとして横並び」。
  • どれか1つでも動いていれば全体は動作可能。
  • 全体稼働率：機器A・Bが並列の場合、故障率(1-単体稼働率)を求め、それを1から引く。

まとめ

構成 特徴 稼働率(P)の傾向 全体の稼働率
直列 どれか1つでも壊れたらダウン 稼働率は下がる $$ P^{2} $$
並列 どれか1つ動いていればOK 稼働率が上がる $$ 1-(1-P)^{2} $$

IPアドレス

① ネットワークアドレス部（Network Portion）

  • IPアドレスのうち、「どのネットワークに属するか」 を示す部分
  • ネットワーク内の全ホストが 共通の値 を持つ
  • サブネットマスクの “1” の部分がネットワーク部

② ホストアドレス部（Host Portion）

  • ネットワーク内の各ホスト（機器）を識別する番号。
  • サブネットマスクの “0” の部分がホスト部
  • ホスト部が全ビット「0」や「1」の場合は特別な意味を持つ（後述）

③ ネットワークアドレス（Network Address）

  • ネットワークそのものを表すアドレス
    • ホスト部が すべて 0 の IP アドレス
  • 機器に割り当て不可
例：192.168.1.33/28
/28 → 32〜47 が同じネットワーク
→ 192.168.1.32

④ ホストアドレス（Host Address）

  • ネットワーク内の 各機器に割り当てるIPアドレス
  • ホスト部が 全0 でも全1 でもない アドレス
  • 例：192.168.1.33 〜 192.168.1.46

⑤ サブネットマスク（Subnet Mask）

  • ネットワーク部とホスト部の境界を示す
  • サブネットのサイズを決定する
表記
CIDR /28 → 255.255.255.240
2 進数：
11111111.11111111.11111111.11110000

⑥ ブロードキャストアドレス（Broadcast Address）

  • そのネットワーク内のすべてのホストに同時送信するための特別なアドレス。
  • ホスト部が すべて 1 のアドレス
  • ネットワーク内全体へ「まとめて配信」したいときに使用
  • 各ホストへ同時にパケットを届ける仕組み
例：192.168.1.33/28
ネットワーク範囲：32 ～ 47
→ **ブロードキャストアドレス = 192.168.1.47**

まとめ（192.168.1.33/28 の例）

用語 意味 値（例）
ネットワークアドレス部 ネットワークを示すビット部分 最初の 28bit
ホストアドレス部 ホスト番号の部分 最後の 4bit
ネットワークアドレス ネットワークの先頭（ホスト部が0） 192.168.1.32
ホストアドレス 利用可能なホスト 192.168.1.33〜46
サブネットマスク ネットワーク部を示すマスク 255.255.255.240
ブロードキャストアドレス 全ホスト宛の特別アドレス（ホスト部が1） 192.168.1.47

ネットワークアドレスの求め方(192.168.1.33/28の場合)

手順1：CIDR /28 からサブネットマスクを求める

  • /28 は「先頭から 28bit がネットワーク部」という意味。
  • サブネットマスク：
    255.255.255.240
    （理由：最後のオクテットは 256 - 16 = 240）

手順2：サブネットごとのアドレス範囲を求める

  • 最後のオクテットのブロックサイズ：
    256 - 240 = 16

つまり、サブネットは以下の幅で区切られる：

  • 0〜15
  • 16〜31
  • 32〜47
  • 48〜63
  • ...

手順3：対象アドレス（33）がどの範囲に入るか確認

  • 対象 IP：192.168.1.33
  • 最後のオクテット：33
  • 33 は 32〜47 の範囲に属する！（16区間ごと）

手順4：その範囲の最初のアドレス = ネットワークアドレス

  • 32〜47 の最初は 32

よってネットワークアドレスは：192.168.1.32

エクスプロイトコード

  • 脆弱性を攻撃するために作られたプログラムやスクリプトのこと

クロスサイトスクリプティング

  • Webアプリケーションの入力に悪意あるスクリプト（多くはJavaScript）を埋め込むことで、利用者のブラウザで不正なスクリプトを実行させる攻撃

① 反射型 XSS（Reflected XSS）

  • 攻撃用スクリプトがURL に埋め込まれ、そのままレスポンスに反射（表示）されるタイプ
  • ユーザが攻撃者の作った「悪意のあるURL」を踏んだときに発生する
  • 攻撃シナリオ
    • 攻撃者が悪意のあるURLをメールやSNSで送る
    • 被害者がクリック
    • ブラウザ上でスクリプトが実行
    • Cookieやログイン情報を盗まれる
https://example.com/search?q=<script>stealCookie();</script>

② 保存型/格納型 XSS（Stored / Persistent XSS）

  • スクリプトがサーバ側に“保存される”XSS。
  • 掲示板・コメント欄・プロフィールなどに悪意のスクリプトを入力すると、
    そのページを閲覧した全ユーザのブラウザでスクリプトが実行される。
  • 攻撃シナリオ
    • 攻撃者がスクリプト入りのコメント投稿
    • サーバは内容を保存
    • 他の利用者がページを閲覧
    • スクリプトが各ブラウザで自動実行

掲示板の投稿内容に

<script>stealCookie()</script>

を投稿される → データベースに保存 → ページ表示時に実行。

③ DOM ベース XSS（DOM-based XSS）

  • サーバではなく、ブラウザ上の JavaScript（DOM操作）が脆弱で発生する XSS。
  • Javascript が URL や location.hash などから値を取り出し、エスケープせずに HTML に挿入することで発生。
  • 攻撃シナリオ
    • 攻撃者が悪意ある URL を作成
    • JavaScript が不適切に DOM 書き換え
    • スクリプトがクライアント側で実行
document.getElementById("msg").innerHTML = location.hash.substring(1);

URL が

https://example.com/#<script>stealCookie()</script>

だと、そのまま実行される

違いまとめ

種類 どこにスクリプトがある？ 説明
反射型 XSS URL に埋め込まれ → レスポンスに反射 URL を踏むと1回だけ発生
保存型 XSS サーバのデータベースなどに保存 閲覧した全ユーザに影響、危険度最大
DOM ベース XSS クライアント側（JavaScript）で発生 サーバ関与なし、JSのDOM操作が原因

HTTPヘッダインジェクション（HTTP Header Injection）

  • Webアプリのレスポンスヘッダに攻撃者が任意の文字列（ヘッダや改行）を混入させる攻撃。
  • 改行（CRLF）を挿入し、意図しないヘッダやHTMLを追加させる。

どう発生する？

  • Webアプリがレスポンスヘッダを組み立てるとき
  • 攻撃者の入力値を そのまま使ってしまう と発生
  • 特に Location: ヘッダや Set-Cookie が脆弱ポイント

例：

Location: /search?q=[ユーザ入力]

攻撃者が

abc%0d%0aSet-Cookie: session=steal

を送ると、ヘッダが分断され不正なヘッダが挿入される

主な影響

  • 任意のCookieをセットされる
  • リダイレクト先を操作される（フィッシング誘導）
  • レスポンス分割によるXSS（HTTPレスポンス分割）

対策

  • ヘッダに出力する値を CRLF（改行）を含まないようにチェック
  • ヘッダにユーザ入力を直接使わない
  • エンコード（URLエンコードなど）

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

  • ログイン中のユーザのセッションを悪用して、ユーザが意図しない操作を実行させる攻撃。
  • ユーザ自身のブラウザで「勝手に送信」される点が特徴

どう発生する？

  • 被害者がログイン状態で別の悪意あるページを閲覧
  • そのページが自動でリクエストを送る（送信フォーム・イメージタグなど）
  • ブラウザは 正当なCookieを自動送信してしまう

例：

銀行サイトにログインしたまま、悪意サイトの HTML が以下を実行：

<img src="https://bank.example.com/transfer?to=attacker&amount=10000">

利用者の意図と関係なく送金されてしまう。

主な影響

  • 不正送金
  • アカウント設定変更
  • パスワード変更
  • 商品購入

対策

  • CSRFトークンを利用する（最重要）
  • SameSite Cookie を利用（Lax または Strict）
  • 重大操作に再認証を求める
  • Referer / Origin チェック（補助的）

OSコマンドインジェクション

  • Webアプリが内部で実行している
    OSコマンドに攻撃者の入力が混入し、任意のコマンドが実行される攻撃。
  • 攻撃者が「サーバで OS コマンドを実行できてしまう」

どう発生する？

  • アプリが入力値を OS コマンドに直接使っている場合

例（脆弱な例）：

$ip = $_GET['ip'];
system("ping " . $ip);

攻撃者が

127.0.0.1; rm -rf /

を送ると、; 以降が 別コマンドとして実行される

主な影響

  • サーバ乗っ取り（最悪）
  • ファイル削除
  • 情報漏えい
  • 不正プログラム実行

対策

  • OSコマンドを直接使わない（標準APIを使う）
  • 入力値を厳格にチェック（メタ文字の排除）
  • 権限の最小化
  • サニタイジング（エスケープ）

秘密鍵と公開鍵の仕組みを、できるだけわかりやすく解説します。
情報セキュリティマネジメント試験でも頻出ポイントです。

公開鍵暗号方式とは？

  • 2つの鍵を使う暗号方式
  • 公開鍵（Public Key）：みんなに公開してよい鍵
  • 秘密鍵（Private Key）：持ち主だけが持つ鍵（絶対に漏らしてはダメ）
    *2つは**対（ペア）**になっていて、
    片方で暗号化したものは、もう片方でしか復号できない

① 暗号化（データ秘匿）

  • 送信者は、受信者の公開鍵で暗号化
  • 復号できるのは 受信者だけ（秘密鍵を持っている）
  1. あなたの公開鍵を相手に渡す
  2. 相手が公開鍵で暗号化
  3. あなただけが秘密鍵で復号できる

② 電子署名（なりすまし防止・改ざん検出）

  • 送信者が秘密鍵で署名（暗号処理）
  • 公開鍵で検証可能（受信者側）
  1. あなたが秘密鍵で署名
  2. 誰でもあなたの公開鍵で検証できる
  3. 改ざんされていれば検証に失敗する

③HTTPS（SSL/TLS）での使われ方

  1. サーバーは公開鍵を証明書として配布
  2. ブラウザは公開鍵で共通鍵を暗号化してサーバーに送る
  3. サーバーは秘密鍵で復号
  4. 以降は高速な共通鍵暗号で通信

実際は「公開鍵暗号＋秘密鍵暗号のハイブリッド」方式。

リスクベース認証（Risk-Based Authentication：RBA）について、情報セキュリティマネジメント試験向けにわかりやすく解説します。

リスクベース認証(RBA)とは？

  • ユーザのログイン状況を分析し、リスクが高い場合に追加の認証を行う仕組み
  • 普段と違うログイン行動があったときに
    「これは本人か？」をチェックするための仕組み

どんな情報を使って“リスク判定”する？

  • IPアドレス（普段と違う国/地域からのアクセス）
  • 端末情報（普段と違う端末）
  • ブラウザ情報
  • アクセス時刻（深夜など不自然な時間）
  • アクセス元の安全性（Tor/プロキシなど）
  • ログイン試行回数
  • ユーザの行動パターン（急激な異常操作）

これらを組み合わせて、
リスクが高いと判定したら追加の認証を要求

リスクレベルに応じてどう変わる？

リスクレベル 動き
低 通常のID＋パスワードでログイン成功
中 ワンタイムパスワード（OTP）要求、SMS認証
高 ログインブロック、本人確認メール送信、追加質問
極高 アカウント一時ロック、管理者に通知

RBA のメリット

  • 不正ログインを高精度に防ぐ
  • 利用者は日常利用では追加認証が不要 → 利便性が高い
  • 多要素認証（MFA）と組み合わせてセキュリティ強化が可能

PMBOKとは？

Project Management Body of Knowledge（プロジェクトマネジメント知識体系ガイド）

  • プロジェクトマネジメントの国際的な標準ガイド
  • PMI（Project Management Institute）が策定
  • プロジェクトを成功させるための体系的な知識・プロセス・手法がまとめられている
  • 日本のIPA試験でも基準としてよく引用される

その中の1つに「リスクマネジメント」という知識エリアがあり、
リスクへの対応方法が定義されている

PMBOKにおける「リスクの定義」

  • リスク＝プロジェクト目標に影響を与える“不確実性”
  • プラスの影響 → 好機（Opportunity）
  • マイナスの影響 → 脅威（Threat）
リスクの種類 対応方法 説明
マイナスのリスク（脅威） 回避 リスク要因を完全に取り除く
転嫁 保険・外注で第三者に移す
軽減 発生確率・影響を下げる
受容 コストに見合わないので対策をしない／監視のみ
プラスのリスク（好機） 活用 確実に好機が得られるように積極的に動く
共有 パートナーと利益を分ける
向上 好機の確率や利益を増やす(追加投資をする)
受容 良い結果が出たらラッキー程度で特に何もしない

評価基準

評価基準 内容 例
ISO/IEC 15408（CC） IT製品のセキュリティ評価に関する国際標準規格 VPN装置、OS、ICカード
ISO/IEC 27001（ISMS） 組織全体の情報セキュリティ管理の仕組み（ISMS）の国際規格 企業全体の管理
ISO/IEC 27002 セキュリティ管理策の具体例を示すガイドライン アクセス制御、ログ管理
ISMS適合性評価制度(JIS Q 27001) 第三者認証機関が組織のISMSを評価・認証する制度 ISMSの監査
PCI DSS クレジットカード情報を扱う企業向けの国際基準 決済機関
FIPS 140 暗号モジュールの評価基準 暗号チップ、HSM

ポイント

  • 15408＝製品のセキュリティ評価基準
  • 27001＝ISMS（組織のセキュリティマネジメント）
  • 27002＝管理策のガイドライン
  • PCI DSS＝クレカ情報を守るための基準
  • FIPS＝暗号モジュールの評価

クラウドサービスの主要セキュリティ評価基準

評価基準 / 認証 概要 特徴・ポイント 試験ポイント
ISO/IEC 27017 クラウドサービス向けセキュリティ管理策 クラウド固有のセキュリティ指針（提供者・利用者の両方） 「クラウド専用」「管理策」
ISO/IEC 27018 パブリッククラウドにおける個人情報（PII）保護 PIIの取り扱いルールを定義 「個人情報」「PII」
CSA STAR クラウド事業者のセキュリティ成熟度評価 レベル1：自己評価、レベル2：第三者評価、レベル3：継続監査 「成熟度」「レベル」
SOC 2（Type1/Type2） 外部監査人が評価する内部統制レポート Trust Service Criteria（セキュリティ等）を評価 「外部監査」「Type1/2」
FedRAMP 米国政府が利用するクラウドのセキュリティ認証 NIST SP 800シリーズに準拠 「米国政府」「NIST準拠」
ISO/IEC 27001（ISMS） 組織の情報セキュリティマネジメント基準 クラウド含む全組織向けのISMS標準 基本規格として出題
ISMAP（政府情報システムのためのセキュリティ評価制度） 日本政府がクラウドサービスを安全に採用するための評価制度 事業者が「ISMAPクラウドサービスリスト」に掲載されると政府調達対象に 「日本版クラウド認証」「政府調達」「安全性評価」

ポイント

キーワード 出題ポイント
27017 クラウド固有のセキュリティ管理策
27018 個人情報（PII）保護
CSA STAR レベル1＝自己評価、レベル2＝第三者評価
SOC 2 Type1/2 外部監査レポート、内部統制の評価
FedRAMP 米国政府、NIST準拠
ISMS（27001） 基本のマネジメントシステム

クラウド・組織セキュリティ関連のチーム

組織／チーム 役割・対象 特徴・ポイント 試験で狙われるキーワード
CSIRT
(Computer Security Incident Response Team)		 組織全体のインシデント対応 ・インシデント検知、分析、封じ込め、復旧、再発防止
・従業員教育・訓練も担当
・企業や組織単位で設置		 「インシデント対応」「社内チーム」「JPCERT/CCと連携」
CERT / J-CERT
(Computer Emergency Response Team)		 国家・地域・業界規模のインシデント対応組織 ・CSIRTと似るが国家レベル・業界全体対応
・情報共有・通報窓口として機能
・例：JPCERT/CC（日本）		 「国家・業界レベル」「情報共有」「通報窓口」
SOC
(Security Operation Center)		 24時間体制での監視・検知 ・ログ監視、アラート対応、攻撃の兆候を早期検知
・対応より「監視」が主目的		 「監視中心」「24時間体制」「インシデント検知」
PSIRT
(Product Security Incident Response Team)		 自社製品の脆弱性対応 ・製品のセキュリティインシデントを管理
・アップデート・修正パッチ対応		 「製品特化」「脆弱性対応」「修正パッチ」

ポイント

  1. CSIRT → 組織全体のインシデント対応
  2. SOC → 監視・検知（CSIRTが対応）
  3. PSIRT → 自社製品に特化した脆弱性対応
  4. CERT / JPCERT → 国家・業界レベルの情報共有・通報窓口

NIST SP 800-61 に基づく手順

  1. 準備（Preparation）
  2. 検知・通報（Detection & Reporting）
  3. 分析（Analysis）
  4. 封じ込め（Containment）
  5. 根絶（Eradication）
  6. 復旧（Recovery）
  7. 事後対応（Lessons Learned）

→ SOC は「検知」段階、CSIRT は「封じ込め～事後対応」段階を担当

メール

■ 1. 基本構成（メールの流れ）

送信者 → ISP A（送信側プロバイダ） → SMTP → ISP B（受信側プロバイダ） → 受信者

ISP A / ISP B

用語 役割
ISP A メールを送信（SMTPサーバを提供）する側のプロバイダ
ISP B メールを受信（POP/IMAPサーバを提供）する側のプロバイダ

■ 2. SMTP（メール送信プロトコル）

項目 内容
SMTP (Simple Mail Transfer Protocol) メール送信に使用されるプロトコル。25番ポートが基本。
特徴 認証なしで送信できてしまう→スパムの原因となる

■ 3. SMTP-AUTH（送信認証）

項目 内容
SMTP-AUTH SMTP送信時に「ユーザID＋パスワード」で認証する仕組み
目的 第三者による不正中継（オープンリレー）を防止
よく使うポート 587（submission ポート）

普通のSMTP：送信者の成りすまし・スパムの温床
SMTP-AUTH：正規ユーザのみ送信可能に

■ 4. POP / IMAP（受信プロトコル）

プロトコル 特徴 メリット デメリット
POP3（110/995） メールをサーバからPCに「ダウンロード」 ローカルに保存されるのでオフラインで読める 複数端末で同期が難しい
IMAP（143/993） メールをサーバ上に「保持して同期」 どの端末でも同じ状態で見られる サーバ容量を消費

POP → 受信して削除する方式（昔ながら）
IMAP → Gmailのようにサーバ上で管理（現代の主流）

■ 5. OP25B（Outbound Port 25 Blocking）

項目 内容
OP25B 迷惑メール対策で ISP が 外向きの25番ポート（SMTP）を遮断する施策
目的 ウイルス感染PCがスパムメールをばら撒くのを防ぐ
代替方法 587番（submission port）や SMTPS（465番）を使用 
【送信者 → ISP A → ISP B → 受信者】

① 利用者 → ISP A にメール送る
   → SMTP-AUTH（587番）を使って認証して送信
   → OP25Bにより25番ポートの送信はブロックされる

② ISP A → ISP B にメールを配送
   → SMTP（25番）を使用（サーバ間通信は25番が標準）

③ ISP B → 受信者のメールボックスへ届ける
　　→ IMAPはサーバ同期、POPはダウンロード型

ポイント

  • SMTP：送信、POP/IMAP：受信
  • SMTP-AUTH：送信時の認証、スパム対策
  • OP25B：外向き25番ポートの遮断（迷惑メール対策）
  • IMAPはサーバ同期、POPはダウンロード型
  • ISP A/ISP Bは送信側と受信側のメールサービス提供者

ベイジアンフィルタ

  • 過去のメールの特徴（単語の出現パターン）から、統計的に「スパムかどうか」を判定するフィルタ方式
  • 多くの単語の「確率」から総合判断する

DLP（Data Loss Prevention／データ漏えい防止）とは？

  • 機密情報（個人情報・顧客データ・機密文書など）を、意図的・誤操作問わず外部へ漏えいさせないように監視・制御する仕組み。
  • 内部からの情報流出対策

① エンドポイント DLP

→ PC・ノートPCなど端末に直接導入し、データの操作を制御

例：

  • USBメモリへのコピーを禁止
  • ローカル保存のログ取得
  • 印刷、スクショ、クリップボード操作の監視

② ネットワーク DLP

→ 通信経路上で、機密情報の送信を監視してブロック

例：

  • メール添付データを解析し、個人情報が含まれれば警告
  • HTTP/HTTPS 経由でのアップロードをチェック

③ ストレージ DLP（サーバ側）

→ サーバやクラウドの保存データに対してポリシーを適用

例：

  • ファイルサーバ上の機密ファイルを分類し管理
  • 重要データの不正アクセスや持ち出しを検知

例題

Q：USBメモリへのコピー制御、印刷制御を行うのは？
→ 〇 エンドポイントDLP

Q：メール送信時に個人情報を検出してブロックするのは？
→ 〇 ネットワークDLP

Q：ファイルサーバ上の機密情報を分類・管理するのは？
→ 〇 ストレージDLP

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?