情報セキュリティ対策・情報セキュリティ実装技術
このノートの問いがそのまま復習カードになり、忘れかけたころに出題されます。
シラバス Ver.6.5 の小分類 63「情報セキュリティ対策・情報セキュリティ実装技術」（大分類 9：技術要素／中分類 23：セキュリティ）。
2026-08-05 にシラバス本文と突合済み。
0. 何を押さえるか
守る側の手立てです。用語 52 個は 2 番目に多く、しかも技術の中身が問われます。
最大の山は暗号方式です。ここは鍵の数で整理します。
| 鍵 | 速さ | 課題 | |
|---|---|---|---|
| 共通鍵暗号方式 | 送受信で同じ鍵 | 速い | 鍵をどう安全に渡すか |
| 公開鍵暗号方式 | 公開鍵と秘密鍵の対 | 遅い | 遅い |
| ハイブリッド暗号方式 | 両方を組み合わせる | 速い | — |
ハイブリッドは「鍵の受け渡しだけ公開鍵、本文は共通鍵」——
両方の弱点を打ち消す組み合わせです。
そして公開鍵暗号方式は、使う鍵の向きで用途が変わります。ここが最頻出です。
| 目的 | 暗号化に使う鍵 | 復号に使う鍵 |
|---|---|---|
| 秘密にする（暗号化） | 受信者の公開鍵 | 受信者の秘密鍵 |
| 本人だと示す（デジタル署名） | 送信者の秘密鍵（署名鍵） | 送信者の公開鍵（検証鍵） |
向きが逆です。ここを取り違えると署名の問題を落とします。
1. 人と組織の対策
根拠: シラバス 9-23-63
情報セキュリティ啓発と情報セキュリティ訓練の違いは？
| 何をするか | |
|---|---|
| 情報セキュリティ啓発 | 教育・周知により意識と知識を高める |
| 情報セキュリティ訓練 | 実際に体験させる（標的型メールに関する訓練など） |
標的型メール訓練では、
訓練用の偽メールを送り、開いた人に教育を行う。
人的脆弱性への対策は、
知識を与えるだけでなく、行動を確かめるところまで必要になる。
組織における内部不正防止ガイドラインは、何を求めているか？
内部不正を「起こさせない」仕組みづくり
- アクセス権を必要最小限にする
- 監視とログの取得を行い、それを周知する
- 退職時の権限の確実な削除
- 不満をためない職場環境
不正のトライアングルでいう
「機会」を減らし、「動機」にも配慮するという考え方。
2. 物理的な対策
根拠: シラバス 9-23-63
入退室管理・施錠管理・監視カメラは何を防ぐか？
権限のない人が、機器や書類に物理的に近づくことを防ぐ
技術的な対策をどれだけしても、
機器を持ち去られたら意味がない。
セキュリティケーブルは、
ノート PC を机に固定して盗難を防ぐ器具。
アンチパスバックとインターロックの違いは？
| 何を防ぐか | |
|---|---|
| アンチパスバック | 共連れ（入室記録のない人の退室、記録のない再入室）を防ぐ |
| インターロック | 2 つの扉を同時に開かせない（前の扉が閉じないと次が開かない） |
アンチパスバックは記録の矛盾を検出、
インターロックは物理的に一度に 1 人ずつ通す。
クリアデスク・クリアスクリーンとは？
| 何をするか | |
|---|---|
| クリアデスク | 離席時に机の上に書類や記録媒体を放置しない |
| クリアスクリーン | 離席時に画面をロックする（自動ロックの設定） |
どちらも盗み見と持ち出しを防ぐための基本動作。
遠隔バックアップは、
災害で拠点ごと失われても復旧できるよう、
離れた場所にデータの複製を保管すること。
3. 暗号
根拠: シラバス 9-23-63
共通鍵暗号方式と公開鍵暗号方式の違いは？
| 鍵 | 速度 | 課題 | |
|---|---|---|---|
| 共通鍵暗号方式 | 暗号化と復号に同じ鍵 | 速い | 鍵を安全に渡す手段が要る |
| 公開鍵暗号方式 | 公開鍵と秘密鍵の対 | 遅い | 処理が重い |
公開鍵は誰に配ってもよい（公開してよい）。
秘密鍵だけを本人が守る。
n 人が通信する場合の鍵の数も問われる——
共通鍵は組合せの数だけ必要になるが、公開鍵は 1 人 1 対で済む。
ハイブリッド暗号方式とは？
共通鍵暗号方式と公開鍵暗号方式を組み合わせた方式
- 共通鍵を、相手の公開鍵で暗号化して送る（安全に渡せる）
- 本文は、その共通鍵で暗号化する（速い）
公開鍵の「鍵配送が安全」と、共通鍵の「速い」を両取りする。
HTTPS はこの方式で動いている。
ハッシュ関数とは？ 暗号化と何が違うか？
入力から一定の長さの値を作り出す関数
| 元に戻せるか | |
|---|---|
| 暗号化 → 復号 | 戻せる（鍵があれば） |
| ハッシュ関数 | 戻せない（一方向） |
同じ入力からは必ず同じ値が出るので、
内容が変わっていないか（完全性）の確認に使える。
パスワードの保管にも使われる——
ハッシュ値だけを保存しておけば、漏れても元のパスワードは分からない。
ディスク暗号化とファイル暗号化の違いは？
| 何を暗号化するか | |
|---|---|
| ディスク暗号化 | 記憶装置全体。紛失・盗難に強い |
| ファイル暗号化 | 個々のファイル。持ち出す 1 件だけを守れる |
紛失対策ならディスク暗号化、受け渡し対策ならファイル暗号化。
ディスク暗号化は、起動して使用中の状態では中身が読めるので、
クリアスクリーンなど別の対策も要る。
デジタル署名の仕組みは？ どの鍵を使うか？
送信者の秘密鍵（署名鍵）で署名し、
公開鍵（検証鍵）で検証する
暗号化とは鍵の向きが逆である点が要点。
これにより 2 つが確かめられる。
- 本人が作成したこと（真正性）
- 改ざんされていないこと（完全性）
さらに、後から「送っていない」と言えなくなる（否認防止）。
タイムスタンプ（時刻認証）とは？
その時刻にその電子データが存在し、
以後改ざんされていないことを証明する仕組み
デジタル署名が「誰が」を保証するのに対し、
タイムスタンプは「いつ」を保証する。
契約書や特許に関わる文書で必要になる。
4. 認証
根拠: シラバス 9-23-63
認証の 3 要素と多要素認証とは？
| 要素 | 例 |
|---|---|
| 知識（知っているもの） | パスワード、暗証番号 |
| 所持（持っているもの） | IC カード、スマートフォン、ワンタイムパスワードの生成器 |
| 生体（本人自身） | 指紋、顔、静脈 |
多要素認証 ＝ 異なる要素を 2 つ以上組み合わせる
パスワード 2 つは多要素にならない（どちらも知識）。
ログイン（利用者 ID とパスワード）だけでは弱いため、
所持や生体を組み合わせる。
ワンタイムパスワードとリスクベース認証の違いは？
| 何をするか | |
|---|---|
| ワンタイムパスワード | 一度きり有効な使い捨てのパスワード。盗まれても再利用できない |
| リスクベース認証 | 普段と違う場所・端末からの接続など、リスクが高いときだけ追加の認証を求める |
リスクベース認証は、
利便性と安全性を両立させるための考え方。
シングルサインオンとパスワードレス認証の違いは？
| 何か | |
|---|---|
| シングルサインオン | 一度の認証で、複数のサービスを利用できる |
| パスワードレス認証 | パスワードを使わない認証（生体認証、端末の鍵） |
シングルサインオンは利便性が上がる一方、
その 1 つが破られると全部に及ぶという弱点がある。
アクセス管理（誰に何を許すか）と組み合わせて運用する。
SMS 認証と EMV 3-D セキュアとは？
| 何か | |
|---|---|
| SMS認証 | 電話番号あてに送った番号を入力させる（所持の確認） |
| EMV 3-Dセキュア（3D セキュア 2.0） | クレジットカードの本人認証の仕組み |
3-D セキュアは、取引の情報からリスクを判定し、
リスクが低ければ追加認証を省く（リスクベース認証の考え方）。
IC カードも所持による認証の代表例。
生体認証の種類を挙げよ。
| 何を使うか | |
|---|---|
| 静脈パターン認証 | 手のひらや指の静脈の形 |
| 虹彩認証 | 目の虹彩の模様 |
| 声紋認証 | 声の特徴 |
| 顔認証 | 顔の特徴 |
| 網膜認証 | 眼底の血管の模様 |
体内の特徴（静脈・虹彩・網膜）は偽造が難しい。
顔や声は非接触で手軽だが、条件によって精度が落ちる。
本人拒否率（FRR）と他人受入率（FAR）の関係は？
| 何を表すか | |
|---|---|
| 本人拒否率（FRR） | 本人なのに拒否される割合 |
| 他人受入率（FAR） | 他人なのに受け入れてしまう割合 |
判定を厳しくすると FAR は下がるが FRR は上がる（トレードオフ）。
安全性を優先すれば本人が弾かれて不便になり、
利便性を優先すれば他人が通ってしまう。
用途に応じて調整する。
5. 公開鍵基盤
根拠: シラバス 9-23-63
PKI とは？ なぜ必要か？
PKI（Public Key Infrastructure：公開鍵基盤）
＝ 公開鍵が本物であることを保証する仕組み
公開鍵暗号方式には弱点がある——
その公開鍵が本当に相手のものか分からない。
偽の公開鍵をつかまされれば、攻撃者に暗号文を送ることになる。
そこで第三者が「この公開鍵は確かにこの人のものだ」と証明する。
その証明書がデジタル証明書。
CA・ルート証明書・トラストアンカーの関係は？
| 何か | |
|---|---|
| CA（Certification Authority：認証局） | デジタル証明書を発行する第三者機関 |
| ルート証明書 | 認証局自身の証明書。階層の頂点 |
| トラストアンカー（信頼の基点） | 「これは無条件に信じる」と定めた起点。ルート証明書がこれにあたる |
証明書は階層をなして連鎖しており、
たどっていくとルート証明書に行き着く。
どこかで「無条件に信じる起点」を置かないと、
検証が無限に続いてしまう——それがトラストアンカー。
サーバ証明書とクライアント証明書の違いは？
| 何を証明するか | |
|---|---|
| サーバ証明書 | そのサーバが本物であること（利用者が偽サイトを見分けられる） |
| クライアント証明書 | その利用者（端末）が正規であること |
HTTPS で使われるのはサーバ証明書。
クライアント証明書は、社内システムへの接続制限などに使う。
CRL とは？
CRL（Certificate Revocation List：証明書失効リスト）
＝ 有効期限内だが無効になった証明書の一覧
秘密鍵が漏れた、記載事項が変わった、といった場合に失効させる。
有効期限だけを見ても不十分で、
失効していないかを確認して初めて証明書を信用できる。
6. 作る段階からの対策
根拠: シラバス 9-23-63
セキュリティバイデザインとプライバシーバイデザインとは？
| 何を、いつ組み込むか | |
|---|---|
| セキュリティバイデザイン | 企画・設計の段階からセキュリティを組み込む |
| プライバシーバイデザイン | 同様に、プライバシー保護を設計段階から組み込む |
後から付け足すより、確実で安く済むというのが根拠。
出来上がってからでは、構造に関わる対策は入れられない。
クロスサイトスクリプティング対策と SQL インジェクション対策の共通点は？
どちらも「入力値をそのまま扱わない」ことが要点。
| 攻撃 | 対策 |
|---|---|
| クロスサイトスクリプティング | 出力時に特別な意味を持つ文字を無害化する（エスケープ処理） |
| SQL インジェクション | 命令と値を分けて扱う（プレースホルダの利用）、入力値の検証 |
利用者が入力したものを、そのまま命令や表示に混ぜない——
これが Web アプリケーションの脆弱性対策の基本になる。