【情報セキュリティマネジメント】情報セキュリティの3要素とは｜CIA・拡張要素・多層防御・バイデザイン

情報セキュリティの問題では、事故の内容を読んで、何が損なわれたのかを見分ける力が必要です。

情報を秘密にできていても、内容が誤っていれば安全とはいえません。内容が正しくても、必要なときに利用できなければ業務を続けられません。また、利用者や情報が本物か、誰が操作したのか、取引の事実を後から証明できるかといった性質も重要です。

この記事では、まず情報セキュリティの中心となる機密性・完全性・可用性を整理します。続いて、真正性・責任追跡性・否認防止・信頼性との違いを確認し、多層防御、セキュリティバイデザイン、プライバシーバイデザインへつなげます。

先に結論：守る「性質」と、守り方の「考え方」を分ける

最初に、この記事で扱う用語を二つのグループへ分けます。

情報やシステムについて守る性質

機密性（Confidentiality）・完全性（Integrity）・可用性（Availability）は、英語の頭文字からCIAと呼ばれます。

IPAのシラバスでは、CIAに加えて真正性・責任追跡性・否認防止・信頼性も情報セキュリティの用語例として挙げられています。本記事では説明しやすくするため、後者四つを便宜上「拡張要素」と呼びます。これは、シラバス上の正式な分類名という意味ではありません。

情報セキュリティを実現する考え方

七つの性質は、情報セキュリティで維持・確認する性質を示します。一方、多層防御と二つのバイデザインは、どのように、いつ対策を組み込むかを示す考え方です。

1．機密性：権限のない者へ情報を開示しない

機密性は、情報が、認可されていない個人、組織又は処理に利用可能な状態にならず、開示されない性質です。

機密性が損なわれる例

• 顧客情報を権限のない従業員が閲覧した
• ノートPCの紛失によって保存データを第三者に取得された
• 通信内容を盗聴された
• メールを誤送信した
• クラウドの共有範囲を誤って公開設定にした

機密性を支える主な対策

• 利用者認証
• アクセス制御と最小権限
• 暗号化
• 情報の持出し管理
• 画面や書類の盗み見防止
• 機密情報を扱う者への教育

暗号化を行っても、鍵が漏えいしたり、復号後の画面を盗み見られたりすれば機密性は損なわれます。一つの対策だけで性質が常に保証されるわけではありません。

2．完全性：正確で完全な状態を保つ

完全性は、情報や処理の正確性と完全性を保ち、不適切な変更や破壊から守る性質です。

攻撃者による改ざんだけが問題ではありません。誤操作、プログラムの不具合、転送時の欠落などによって内容が誤った場合も、完全性が損なわれます。

完全性が損なわれる例

• 売上データが不正に書き換えられた
• 契約書の一部を誤って削除した
• 設定ファイルが改ざんされた
• データ転送中に一部が欠落した
• 誤った処理によって集計結果が変化した

完全性を支える主な対策

• 変更権限の制限
• 申請・承認手続
• 入力値や処理結果の検証
• ハッシュ値やデジタル署名による確認
• バージョン管理
• 変更履歴の保存

ファイルを開けることは可用性の話です。開ける状態でも内容が誤っていれば、完全性は保たれていません。

3．可用性：認可された利用者が必要なときに利用できる

可用性は、認可された利用者が、必要なときに情報やシステムへアクセスし、利用できる性質です。

可用性が損なわれる例

• サーバ障害で注文画面を利用できない
• DDoS（Distributed Denial of Service）攻撃でWebサービスへ接続できない
• ランサムウェアによって業務データを開けない
• 停電によってシステムが停止した
• 復旧手順がなく、障害から業務を戻せない

可用性を支える主な対策

• 冗長化と負荷分散
• 障害監視
• バックアップ
• 復旧手順と復元試験
• UPS（Uninterruptible Power Supply：無停電電源装置）や予備回線
• 代替業務手段の準備

バックアップを保存しているだけでは十分ではありません。必要な時間内に復元できるかを試験し、担当者、手順、復旧順序を決めておく必要があります。

4．CIAを事例から見分ける

CIAの問題では、まず事故によって生じた直接的な支障を確認します。

見分けるときは、次の三つの言葉へ置き換えます。

• 見られた：機密性
• 中身が変わった・誤っている：完全性
• 使えない：可用性

ただし、一つの事故が複数の性質へ影響する場合もあります。

例えば、ランサムウェアによってデータを利用できなくなれば可用性が損なわれます。攻撃者が暗号化前に情報を窃取していれば機密性にも影響し、内容を書き換えていれば完全性にも影響します。

試験では、問題文が最も直接問う性質を選びます。

5．真正性：主張どおりの主体・情報だと確認できる

真正性は、利用者、機器、組織又は情報が、主張されているとおりのものであることを確認できる性質です。

典型例

• ログインしようとしている者が登録された本人である
• 接続先が正規のWebサーバである
• 受信した文書が、主張された作成者から送られた
• 情報が偽装されたものではない

利用者認証、デジタル証明書、デジタル署名などが真正性の確認を支えます。

真正性は、単に「内容が改ざんされていないこと」ではありません。完全性が内容の正確さや変更の有無を扱うのに対し、真正性は本物であると主張する主体や情報を確認できるかに重点があります。

6．責任追跡性：行為を特定の主体まで追跡できる

責任追跡性は、誰が、いつ、何を行ったかを後から追跡し、行為を特定の主体へ結び付けられる性質です。

例えば、複数の作業員が同じ管理者IDを共用していたため、設定変更を行った人物を操作ログから特定できない場合、責任追跡性が不足しています。

責任追跡性を支える主な対策

• 個人ごとのアカウント
• 適切な利用者認証
• 必要な操作ログの取得
• システム間の時刻同期
• ログへのアクセス制御と改ざん防止
• ログの保存期間と調査手順

ログが存在するだけでは十分ではありません。共用IDしか記録されていない、時刻がずれている、重要な操作が記録されていない場合には、行為を正しく追跡できません。

7．否認防止：行為や取引の事実を後から証明できる

否認防止は、情報の作成、送信、受信、承認、取引などについて、当事者が後から否定した場合でも、その事実や発生元を検証できるようにする性質です。

典型例

• 電子契約で、署名者と署名対象の文書を確認できる
• メッセージの送信者が、送信した事実を後から否定しにくい
• 承認した内容と時刻を、信頼できる記録によって確認できる

デジタル署名、信頼できる時刻情報、適切に保全された記録などが証拠を支えます。

責任追跡性は「誰が何をしたかを追えるか」、否認防止は「その行為の事実を争われたときに証明できるか」に重点があります。

8．信頼性：意図したとおり一貫して動作する

信頼性は、システムや処理が、定められた条件の下で意図した機能を果たし、期待する結果を一貫して得られる性質です。

信頼性が問題となる例

• 同じ条件で処理しても結果が不安定になる
• 障害時の切替えが設計どおりに動作しない
• 想定した負荷や条件の下で、処理が設計どおりに完了しない
• 部品やソフトウェアが期待された機能を果たさない

可用性と信頼性は似ていますが、同じではありません。

• 可用性：利用できるか
• 信頼性：利用したとき、意図したとおり安定して動くか

システムへ接続できても、処理結果が不安定であれば、可用性は確保されていても信頼性に問題がある場合があります。

9．七つの性質は、常に一つだけが問題になるわけではない

CIAや拡張要素は互いに独立したラベルではなく、一つの事故や対策が複数の性質に影響することがあります。

例えば、共用管理者IDは責任追跡性を低下させます。さらに、そのIDが漏えいすれば機密性や完全性にも影響する可能性があります。

また、各性質は常に同時に向上するわけでも、必ず対立するわけでもありません。

• 厳格すぎるアクセス制御は機密性を高める一方、正規利用者が必要なときに利用できず、可用性を下げる場合がある
• 暗号鍵を厳重に保管しても、災害時に復号できなければ業務を復旧できない
• 適切な権限設計や冗長化によって、複数の性質を同時に高められる場合もある

重要なのは、業務要求、情報の重要度、想定する脅威、許容できる停止時間などを踏まえ、必要な水準と釣り合いを決めることです。

10．多層防御：異なる役割の対策を重ねる

多層防御は、人、技術、運用などの異なる位置や役割の対策を組み合わせ、一つの対策が突破又は停止しても、別の対策で防止、検知、被害限定、復旧を行えるようにする考え方です。

標的型メールに対する多層防御の例

1. メールフィルタで不審な添付ファイルを入口で防ぐ
2. 端末のマルウェア対策やEDR（Endpoint Detection and Response）で実行を検知する
3. 利用者権限を絞り、侵害時の影響を限定する
4. ネットワークを分離して横展開を抑える
5. ログ監視で異常を発見する
6. バックアップから復旧できるようにする
7. 従業者が不審なメールを報告できるよう教育する

同じ種類の製品を二つ設置すれば、必ず多層防御になるわけではありません。入口、端末、認証、権限、ネットワーク、監視、復旧、教育など、役割の異なる層を組み合わせることが重要です。

多層防御とはいえない例

• 社外からの接続だけを禁止し、内部では認証や監視を行わない
• 最も高性能な製品を一つ導入し、他の対策を縮小する
• 複数の層で同じ認証情報を使い回し、一つの漏えいで全ての層が破られる状態にする
• 検知製品を導入するが、アラートを確認する担当者を決めない

一つの境界や製品だけへ依存する構成は、その対策が破られたときに補う手段がありません。

11．セキュリティバイデザイン：早い段階から組み込み、ライフサイクル全体で続ける

セキュリティバイデザインは、システム完成後に対策を追加するだけでなく、企画、要件定義、設計などの早い段階からセキュリティ要件を組み込む考え方です。

ライフサイクルでの取組例

「設計段階で一度検討したので、運用開始後の確認は不要」という意味ではありません。早期に組み込んだうえで、変更や廃止まで継続して管理します。

不適切な進め方

• 公開後に事故が起きてから必要な機能を追加する
• 開発を優先し、セキュリティ確認を運用部門へ先送りする
• 市販製品を導入しただけで、固有の要件を満たしたと判断する
• 仕様変更後も、当初のセキュリティ評価を見直さない

12．プライバシーバイデザイン：個人情報の取扱いを企画・設計段階から考える

プライバシーバイデザインは、個人情報やプライバシーへの影響を、サービスや業務の企画・設計段階から考慮し、必要な保護措置を組み込む考え方です。

具体例

• 利用目的に必要な情報だけを収集する
• 利用目的と取扱いを分かりやすく説明する
• 個人情報へアクセスできる担当者を限定する
• 保存期間を定め、不要になった情報を削除する
• 委託や第三者提供の条件を整理する
• 利用者が自分の情報について確認・手続できるようにする
• 新しい利用方法によるプライバシーへの影響を事前に検討する

セキュリティバイデザインは、情報やシステムの安全性を幅広く扱います。プライバシーバイデザインは、個人の権利・利益や個人情報の取扱いに重点があります。

両者は重なる部分がありますが、同じ概念ではありません。強い暗号化を行っていても、利用目的を超えて不必要な個人情報を大量に収集していれば、プライバシー上の問題は残ります。

よくある取り違え

科目Bでの判断手順

事例問題では、次の順番で整理します。

1. 何が起きたかを確認する

閲覧、改ざん、停止、なりすまし、共用ID、取引否定などの事実を拾います。

1. 直接の支障をCIAへ当てはめる

見られた、内容が変わった、使えない、のどれかを確認します。

1. 拡張要素が中心ではないか確認する

本物か、誰が操作したか、行為を証明できるか、安定して動くかを確認します。

1. 複数の性質へ影響している場合は、設問の焦点を読む

「最も直接」「主として」「この対策の目的」といった表現に注目します。

1. 一つの対策だけへ依存していないか確認する

単一の境界や製品へ依存していれば、多層防御として不十分です。

1. 対策を検討した時期と継続性を確認する

企画・設計段階から組み込み、運用・変更・終了まで管理しているかを見ます。

まとめ

• 機密性は、権限のない者へ情報を開示しない性質
• 完全性は、情報や処理の正確性と完全性を保つ性質
• 可用性は、認可された利用者が必要なときに利用できる性質
• CIAは「見られた・変わった・使えない」で見分ける
• 真正性は、主体や情報が主張どおりのものだと確認できる性質
• 責任追跡性は、行為を特定の主体へ結び付けて追跡できる性質
• 否認防止は、行為や取引の事実を後から検証・証明できる性質
• 信頼性は、意図したとおり一貫して動作する性質
• 一つの事故や対策が、複数の性質へ影響する場合がある
• 各性質は必ず対立するわけではないが、業務要求に応じた釣り合いが必要
• 多層防御は、異なる役割や位置の対策を組み合わせる考え方
• セキュリティバイデザインは、早期に安全性を組み込み、ライフサイクル全体で管理する考え方
• プライバシーバイデザインは、個人情報やプライバシーへの影響を企画・設計段階から考える考え方
• 科目Bでは、事故の直接的な支障と、設問が問う中心的な性質を分けて判断する

関連記事

• C1-T02：情報資産・脅威・脆弱性・リスク
• C2-T04：デジタル署名とタイムスタンプ
• C2-T05：PKIとデジタル証明書
• C2-T06：利用者認証の3要素と生体認証
• C5-T06：アクセス制御と権限管理
• C5-T09：ログ管理と監視
• C5-T10：データ保護とバックアップ
• C9-T01：システム構成と信頼性
• C10-T04：用語の衝突を整理する

参考資料・基準日

本記事は、2026年8月3日時点のSGシラバスVer.4.1を基準に作成しています。

• IPA「情報セキュリティマネジメント試験（レベル2）シラバス Ver.4.1」
• JIS Q 27000:2019「情報技術－セキュリティ技術－情報セキュリティマネジメントシステム－用語」
• NIST「Computer Security Resource Center (CSRC) Glossary」（2026年8月7日参照）
• Personal Data Protection Commission (PDPC), Singapore／Privacy Commissioner for Personal Data (PCPD), Hong Kong「Guide to Data Protection by Design for ICT Systems」（2019年5月31日。個人情報保護委員会による仮日本語訳「ICTシステムのための『データプロテクション・バイ・デザイン』のガイド」）

関連する問題

• 情報セキュリティマネジメント 情報セキュリティの基礎・脅威・攻撃 択一式（応用） 第1問〜第5問
• 情報セキュリティマネジメント 情報セキュリティの基礎・脅威・攻撃 択一式（応用） 第6問〜第10問
• 情報セキュリティマネジメント 情報セキュリティの基礎・脅威・攻撃 一問一答 第1問〜第5問
• 情報セキュリティマネジメント 情報セキュリティの基礎・脅威・攻撃 一問一答 第6問〜第10問

---