情報セキュリティの基礎

このページは、情報セキュリティの基礎 を整理するページです。

情報セキュリティとは、単に「攻撃を防ぐ」ことではなく、「データを正確に、許可された人だけが、必要な時にアクセスできる状態を保つ」ことです。そのために、何を守るのか（目的）、どうやって守るのか（技術）、何から守るのか（脅威） の 3 つの視点が必要です。

このページでは、まず CIA と 4 要素 で「守る対象」を定義し、次に 暗号化 / ハッシュ / 電子署名 / 認証 で「守る方法」を学び、最後に マルウェア / Web 攻撃 / その他脅威 で「守るべき対象」を整理します。

情報セキュリティで守る対象は、次の 7 つです。まずは「何のために必要か」に着目して理解することが重要です。

それぞれの技術との対応

これらの 7 要素は、異なる技術で実現されます：

このように、複数の技術を組み合わせることで、初めて包括的なセキュリティが実現されます。

暗号化とは、元のデータ（平文）を特定の規則（鍵）に基づいて読めない形（暗号文）に変換し、受信者だけが復号化できるようにする技術です。暗号化には 2 つの方式があり、それぞれメリット・デメリットが異なります。

同じ鍵で暗号化と復号化を行う方式です。 送信者が「あなたの鍵は 2024」で暗号化すれば、受信者も「鍵 2024」で復号化します。

鍵配送問題とは何か

10 人が各自 1 対 1 で安全に通信したいとします。AさんとBさんが通信するとき、2人だけが知っている秘密鍵が必要です。しかし、AさんとCさんが通信するときは別の秘密鍵が必要です。この秘密鍵を「事前にどうやって安全に共有するか」が問題になります。

鍵の個数計算例（10 人の場合）

10 人が各自 1 対 1 で通信する場合、それぞれのペアに異なる鍵が必要です：

Aさんが Bさんと通信するための鍵を、CさんやDさんと共有することはできません（そうしたら、CさんがAさんとBさんの通信を盗聴できてしまいます）。つまり、人数が増えると必要な鍵の本数が急速に増え、管理が困難になります。

異なる 2 つの鍵を使う方式です。 公開鍵（世界中に公開してよい）と秘密鍵（自分だけが持つ）のペアを使い分けます。

公開鍵暗号が解決する問題

従来の共通鍵暗号では、秘密鍵を事前に安全に交換する必要がありました。しかし、公開鍵暗号なら、公開鍵はインターネットで自由に公開でき、受信者だけが秘密鍵を持ちます。つまり、初めて会う人とも安全に通信できるようになります。

鍵の個数計算例（10 人の場合）

10 人が各自、公開鍵 1 つ + 秘密鍵 1 つを持ちます：

AさんがB〜Jさんと通信する場合、各人の公開鍵さえあればよく、秘密鍵を共有する必要はありません。Bさんの公開鍵は世界中に知られていてもかまいません。Bさんだけが自分の秘密鍵を持っているからです。

現実には、共通鍵暗号と公開鍵暗号の両方を使い分けます。

これが ハイブリッド暗号 です。理由は以下の通りです：

そこで、次のように組み合わせます：

この組み合わせを ハイブリッド暗号 と呼びます。SSL/TLS や HTTPS、金融機関のインターネットバンキングなど、現在のほぼ全ての安全な通信がこの方式です。

ハイブリッド暗号の利点

過去問では、暗号化 と 圧縮、符号化 をわざと近い表現で並べてきます。ここは 何のために変換するのか で切ると迷いにくくなります。

暗号化 は秘密保持が目的で、圧縮 は効率化が目的、符号化 は表現形式の変換が目的です。圧縮しただけでは秘密にならない、Base64 にしただけでは暗号化ではない と切れるようにしてください。

ハッシュ関数とは、任意の長さの入力から固定長の値（ハッシュ値）を生成する一方向関数です。 暗号化とは異なり、元のデータに戻すことはできません。その代わり、データが少しでも変わると、全く異なるハッシュ値が生成されます。

ハッシュ関数の 3 つの重要な特性

なぜ一方向なのか？

暗号化は「元のデータに戻すこと」が目的ですが、ハッシュ関数は「データが改ざんされていないことを検証すること」が目的です。だから、一方向でいいのです。むしろ、復号化できないからこそ、パスワードのように「本人しか知らない秘密」を安全に保管できます。

ハッシュ関数を使わない場合の危険性

もし企業が「パスワード = db_password」として、元のパスワードをデータベースに保存していたら、ハッカーに盗まれたとき、全員のパスワードが漏洩してしまいます。しかし、ハッシュ値 SHA-256(db_password) が盗まれても、元のパスワードを復元することはできないため、他のシステムへの被害を最小限に抑えられます。

用途例

デジタル署名とは、ドキュメントのハッシュ値を秘密鍵で暗号化し、「このドキュメントは本当に私が送信した（否認防止）」「改ざんされていない（完全性）」「送信者は本物である（真正性）」ことを証明する仕組みです。

なぜ必要か

実生活で重要な契約書には署名をします。手書きの署名は「この人が確かに署名した」という証拠になります。デジタル世界でも同じことが必要です。電子メールを送ったあと、「いや、僕は送っていない」と言い張られることを防ぐためです。

5 ステップの手順

デジタル署名は送信者側と受信者側で異なる処理をします：

署名検証の結果

暗号化との違い（鍵の使用順序がポイント）

これが試験で最も混同されるポイントです：

なぜ暗号化と署名で鍵の使用順序が逆なのか

つまり、「秘密鍵を持っている人」が異なるため、鍵の使用順序が自動的に決まるのです。

認証とは、ユーザーが「本当にその人であるか」を確認するプロセスです。 これは「その人にアクセス権があるか」を決める認可とは異なります。まず本人であることを確認（認証）してから、その人に何ができるかを決める（認可）という順序です。

認証の強度を上げるには、複数の異なる要素を組み合わせることが有効です。

認証には、大きく 3 つの要素があります：

各要素の仕組み

複数の異なる要素を組み合わせて認証強度を高めます。

多要素認証が効果的な理由

1 つの認証要素が破られてもダメージを最小限に抑えられます：

よくある混同：「多段階認証」と「多要素認証」は違う

試験では「パスワード + 秘密の質問」を「多要素認証か」と聞かれたら「いいえ」が正解です（どちらも知識要素）。

生体認証は「本人かどうか」を判定するため便利ですが、判定を厳しくすると本人も弾きやすくなり、甘くすると他人も通しやすくなります。このトレードオフを表すのが次の 3 指標です。

不正者を通したくない が論点なら FAR、本人を弾きすぎないか が論点なら FRR を見ます。

認証方式の設問では、何を送るのか、毎回同じか、追加認証の条件は何か を見ると切り分けやすくなります。

OTP は 毎回違う値、チャレンジレスポンス は 秘密そのものを送らない仕組み、リスクベース認証 は 状況に応じて認証強度を変える考え方 です。一度認証したら全システムで再認証不要 は SSO の話であり、OTP とは別です。

複数のサービスに 1 回の認証でアクセスできる仕組みです：

SAML と OAuth 2.0 の違いに注意

OAuth は認証ではなく認可なので、「Google でログイン」と言われても、実はその背後で別の認証技術が使われている場合が多いです。

認証関連の設問では、ユーザー情報を持つ仕組み、認証結果を他サービスへ渡す仕組み、ネットワーク接続時の認証 が混在します。どの層で何をしているか を分けると崩れにくくなります。

ログインに使う と書いてあっても、実際に問われているのが 認証そのもの なのか 権限委譲 なのか 認証基盤のユーザー台帳 なのかは別です。外部アプリに Google Drive への限定アクセスを許可 なら OAuth 2.0、社員 ID を管理する台帳 なら LDAP、一度の認証で複数システムへ入る なら SAML または OpenID Connect を疑う順番が安全です。

近年の過去問では、パスワードレス認証、ワンタイムコード、一度の認証で複数サービスへ入る仕組み を混ぜてきます。ここは 何を使って本人確認するのか と 認証結果をどう使うのか を分けるのがコツです。

パスキー は FIDO の考え方に基づく認証情報であり、OTP のように毎回コードを入力する方式とは別です。また、SSO は認証を楽にする仕組みであって、パスワードレス そのものではありません。顔認証や指紋認証は、端末上でパスキーを解放する手段として使われることがありますが、生体認証 = パスキー と同一視しないようにしてください。

認証基盤の問題では、誰の情報を持つか、誰が認証するか、どうやってチケットを渡すか を切り分けると混同しにくくなります。

公開鍵暗号には 1 つの問題があります。「その公開鍵は本当にその人のものなのか」をどうやって確認するのか、ということです。

例えば、あなたが Amazon から「公開鍵」を受け取ったとします。しかし、その鍵が本当に Amazon のものなのか、攻撃者が偽造した鍵ではないのか、どうやって確認しますか？ PKI は、この「公開鍵の身元確認」を実現するための体制です。

PKI の仕組みの流れ

HTTPS 通信の背後にある PKI

あなたが https://amazon.co.jp にアクセスするとき、実は以下が起きています：

電子署名 と 電子証明書 は近い場所で使われるため混同しやすいですが、役割は別です。署名する道具 と 公開鍵の身元証明書 を分けて考えます。

順番で言うと、PKI という体制の中で 認証局 が 電子証明書 を発行し、その証明書を使って相手の公開鍵を信頼できるようになり、その先で 電子署名 の検証や HTTPS の安全な通信が成立します。

証明書に関する設問では、失効した証明書をどう確認するか が問われることがあります。ここは、一覧をまとめて配るか、その場で問い合わせるか の違いで覚えると切りやすいです。

この証明書は今も有効か をその場で確認するなら OCSP、失効済み一覧を見て照合する なら CRL が基本です。どちらも 誰の証明書か を証明するものではなく、すでに出ている証明書がまだ使えるか を確認する仕組みです。

タイムスタンプ は、ある電子文書がその時刻に存在し、その後改ざんされていないことを第三者が証明する仕組み です。電子署名が 誰が作成したか に強いのに対し、タイムスタンプは いつ存在していたか と その後の改ざん有無 に強いという違いがあります。

過去問では電子帳簿保存法の旧要件を題材に、タイムスタンプが必要か を問う問題もありました。受験上はまず、タイムスタンプは「時刻証明」、電子署名は「本人証明」 と切ることが重要です。実務での細かな保存要件は制度改正があるため、最新要件を個別に確認してください。

Web 攻撃を理解する最大のポイントは「何を狙うのか」を見極めることです。 SQL インジェクション、XSS、CSRF は一見似ていますが、攻撃対象が全く異なります。

なぜ 3 つに分けて考えるのか

1 つの防御策がすべての攻撃に対応することはできません。攻撃対象が異なるため、防御策も異なるからです：

1. SQL インジェクション

「データベースを狙い、不正なデータを取得・削除・改ざんする」攻撃です。

具体的な攻撃例

防御策

2. XSS (クロスサイトスクリプティング)

「他のユーザーのブラウザで悪意あるスクリプトを実行させる」攻撃です。

具体的な攻撃例

防御策

3. CSRF (クロスサイトリクエストフォージェリ)

「ユーザーが気付かないうちに、認証済みセッションを使って不正リクエストを送信させる」攻撃です。

具体的な攻撃例

防御策

Web セキュリティでは、どれも対策っぽい という覚え方だと崩れます。ここは どこで効くか を先に固定してください。

WAF は サーバーの手前、CSP は ブラウザの中、SameSite は Cookie の振る舞い を制御します。リクエストを止めるのか、ブラウザでの実行を抑えるのか、Cookie を送らせないのか の違いで整理してください。

クリックジャッキングは、透明な iframe などを重ねて、利用者が見えているボタンと実際に押しているボタンをずらす 攻撃です。XSS のようにスクリプトを注入するのではなく、画面の見せ方 を悪用します。

X-Frame-Options は このページを他サイトの frame に埋め込ませない ためのレスポンスヘッダです。最近は CSP の frame-ancestors で同様の制御をすることもありますが、受験ではまず クリックジャッキング → X-Frame-Options で切れれば十分です。

ネットワークセキュリティ対策は、「どこに何を置くか」で理解することが重要です。 組織の外側から内側に向かって、複数の防御層を配置する「層防御（Defense in Depth）」が標準です。

各層の防御の位置づけ

IDS と IPS の違い

これは試験頻出です：

IDS は過検知が多いこともあり、分析技術者の判断に頼りますが、IPS は設定がシビアです（誤検知で正常な通信もブロックする可能性）。

過去問では、全部セキュリティ監視製品 に見える選択肢が並びます。ここは 何を見ているか と その場で止めるか で切ると安定します。

IDS / IPS は 通信 を見る技術、EDR は 端末上の挙動 を見る技術、SIEM は 全体ログをまとめて見る 技術です。EDR があるから SIEM は不要 ではなく、EDR のログを SIEM に集約して全体像を把握する使い方もあります。

端末対策の設問では、侵入を防ぐ、侵入後に見つけて動く、情報を外へ出さない が混ざりやすいです。

EPP は 予防、EDR は 検出と初動対応、DLP は 情報が外へ出る経路の制御 です。ランサムウェアに感染した後の不審通信を止める なら EDR、個人情報ファイルのメール送信を止める なら DLP を疑ってください。

VPN は、公開回線（インターネット）上で暗号化された仮想的なプライベートネットワークを構築します。

VPN という語だけ見て 1 つの技術だと思うと、支社間接続 と 在宅勤務 を同じ説明で処理してしまいます。まずは 誰と誰をつなぐか を見てください。

IPsec VPN と IP-VPN はどちらも拠点間で使われますが、前者は 暗号化トンネル技術、後者は 通信事業者の閉域網サービス です。

テレワークの設問では、VPN と 仮想デスクトップ を同じ箱に入れる誤答が頻出です。ここは 通信路の保護 と 作業環境の置き場所 を分けます。

VPN は 安全な通路、仮想デスクトップ は どこで仕事の画面や処理を動かすか の話です。VPN を使う仮想デスクトップ もあり得るので、互いに排他的な分類として覚えないでください。

総務省のテレワークセキュリティガイドラインでも、テレワーク方式は複数に分けて整理されています。試験では名前が似た方式を取り違えやすいので、端末に何を残すか と どこで業務アプリが動くか で切るのが安全です。

迷ったら、安全な通路 の話なら VPN、オフィス PC を触る ならリモートデスクトップ、VDI 基盤を触る なら仮想デスクトップ、端末内に業務専用の箱を作る ならセキュアコンテナ、特殊ブラウザ ならセキュアブラウザ、最初からクラウドへ直接入る ならクラウドサービス方式です。

テレワークやスマートフォン活用が進むと、誰の端末を業務に使うか と どう統制するか を分けて考える必要があります。試験では、BYOD / COPE は運用方針、MCM / MDM は管理技術 という切り分けができるかが問われます。

判断のコツは、所有者 を問うなら BYOD / COPE、何を管理するか を問うなら MCM / MDM です。たとえば「個人スマホの業務ファイルだけを統制したい」なら BYOD + MCM が自然な組み合わせになります。

端末管理の設問では、誰の端末か と 何を制御したいか を分けると正答しやすくなります。

リモートワイプ、パスコード強制、アプリ配布 が出れば MDM、文書の持出し制御、閲覧範囲制御 が出れば MCM を疑います。BYOD と COPE は管理技術ではなく、端末所有と利用方針の話です。

ゼロトラストとは、「社内ネットワークだから安全」という前提を捨て、「すべてを不信頼と仮定し、毎回検証する」というセキュリティ考え方です。

従来の「境界型防御」は以下を想定していました：

しかし、現代では以下の理由でこの前提が崩壊しました：

具体例で比較

従来型防御：

ゼロトラスト：

ゼロトラストと従来型防御の使い分け

ゼロトラストは製品名ではなく、どう守るか の考え方です。そのため、VPN や SSO と同列の単一技術として覚えると崩れます。

VPN を導入したからゼロトラスト ではなく、VPN に加えてユーザー・端末・権限を継続検証する 方向ならゼロトラストです。SSO で再ログインが減る ことと 毎回のアクセスを細かく判定する ことも別の話として切り分けてください。

JIS Q 27000 系では、セキュリティ対策を「思いついた順に実装する」のではなく、リスクを特定し、分析し、評価し、対応し、見直す という順で進めます。試験では、この順序を逆にした選択肢が典型的な誤りです。

対応策の4類型も頻出です。

受験では、対策の前に評価がある、評価の前に特定と分析がある という流れを言えるようにしてください。

過去問では、保険加入、システム廃止、教育強化、対策しない を並べて、回避 / 低減 / 移転 / 受容 を取り違えさせます。ここは リスクを減らすのか、やめるのか、他者に経済的負担を移すのか、受け入れるのか で切ってください。

保険加入は基本的に 移転 と覚える のが安全です。保険に入っても事故自体が消えるわけではないので、残余リスクは残ります。何もしない放置 と 受容 は同じではなく、分析したうえで受け入れる のが受容です。

過去問では、ベースライン、非形式的、詳細リスク分析、組み合わせ の違いを問う問題が出ています。ここでは名前ではなく、どれだけ厳密に分析するか で整理します。

試験では、ベースライン = 基準と照合、詳細 = 資産ごとに深く分析、組み合わせ = 両方を併用 と切れるようにしておくと十分です。

試験では、セキュリティの問題が多角的に出題されます。「どの視点から考えるか」を決めることで、正答率が上がります。

問題で「守るべき対象」が明示されていたら、上記の表で該当要素を見つけてください。

判断のコツ

認証そのもの を聞いているのか、認証を強める方式 を聞いているのか、認証後の利便性 を聞いているのかを先に見てください。

本人確認 と 権限委譲 と 利用者情報管理 は別レイヤーです。問題文に 誰であるかを証明 と 何をしてよいかを許可 のどちらが書かれているかを先に読むと、OAuth と OpenID Connect を取り違えにくくなります。

保険 が出たら基本は 移転、低リスクなので受け入れる は 受容 と覚えてください。何もしない放置 と 受容 は同じではありません。

問題で「どのレイヤーで防ぐべきか」と問われたら、上記の表で該当技術を見つけてください。

VPN は通信を守る技術で、仮想デスクトップ は作業環境の配置方法です。VPN を使った仮想デスクトップ もあり得るため、二者択一で考えないのがコツです。

問題で「テレワーク多用」「クラウド」とあれば、ゼロトラストが答えの可能性が高いです。