情報セキュリティの7要素とは？CIA 3要素と追加4要素

情報セキュリティを考えるとき、最も基本となるのが CIA と呼ばれる3要素です。

機密性（Confidentiality）
完全性（Integrity）
可用性（Availability）

この3つの英語の頭文字を取って CIA と呼びます。

さらに、情報セキュリティをより広く考える際には、次の4つの特性も重要です。

真正性（Authenticity）
責任追跡性（Accountability）
否認防止（Non-repudiation）
信頼性（Reliability）

日本では、CIAの3要素にこの4要素を加えて、「情報セキュリティの7要素」 と説明されることがあります。

ただし、ISO/JISの定義では、まず 機密性・完全性・可用性を維持することが情報セキュリティの中核 とされ、そのうえで真正性・責任追跡性・否認防止・信頼性などの特性も関係し得る、という整理です。

つまり、実務では次のように考えると分かりやすいでしょう。

CIAで「情報を守る基本」を確認し、追加4要素で「誰が・本物か・証明できるか・信頼して動くか」まで確認する。

情報セキュリティの7要素一覧

区分	要素	英語	確認するポイント
CIA	機密性	Confidentiality	許可されていない人に情報を見られないか
CIA	完全性	Integrity	情報が勝手に変更・破壊されていないか
CIA	可用性	Availability	必要なときに情報やシステムを利用できるか
追加要素	真正性	Authenticity	人・システム・データが本物であることを確認できるか
追加要素	責任追跡性	Accountability	誰が何をしたのか追跡できるか
追加要素	否認防止	Non-repudiation	後から「自分はしていない」と否認できないよう証明できるか
追加要素	信頼性	Reliability	システムが意図したとおり安定して正しく動作するか

CIAとは？

CIAは、情報セキュリティの最も基本的な考え方です。

システムやセキュリティ対策を検討するときには、単に「情報漏えいを防げばよい」と考えるのではなく、少なくとも次の3つの観点で確認する必要があります。

Confidentiality：漏らさない
Integrity：勝手に変えさせない
Availability：必要なときに使える

セキュリティ対策を強化しすぎると利便性や可用性が低下する場合もあるため、3要素のバランスを考えることも重要です。

1. 機密性（Confidentiality）

機密性とは

許可された人、組織、システムだけが情報へアクセスできる状態を維持することです。

顧客情報、個人情報、認証情報、契約情報、社内機密などが、権限のない第三者に閲覧されたり持ち出されたりしないようにします。

代表的なリスク

アカウントの乗っ取り
権限設定ミスによる情報公開
クラウドストレージの公開設定ミス
メールの誤送信
PC・スマートフォン・USBメモリの紛失
マルウェアによる情報窃取
内部不正による情報持ち出し

具体的な対策

認証を強化する

多要素認証（MFA）を導入する
パスキーなど、フィッシング耐性の高い認証を利用する
共用アカウントを原則禁止し、個人ごとのアカウントを発行する
退職・異動時に不要なアカウントや権限を速やかに削除する
管理者アカウントと通常利用アカウントを分離する

アクセス権限を制限する

最小権限の原則（Least Privilege） を適用する
RBACなどを利用し、職務に応じて権限を付与する
定期的にアクセス権限を棚卸しする
機密情報へのアクセスを必要最小限の担当者に限定する

データを暗号化する

HTTPS/TLSで通信を暗号化する
データベース、ストレージ、バックアップを暗号化する
PCやスマートフォンのストレージを暗号化する
暗号鍵をソースコードや設定ファイルへ直接記載しない
KMSやSecrets Managerなどの安全な鍵・秘密情報管理の仕組みを利用する

情報の取り扱いを管理する

情報資産を「公開」「社内限定」「機密」などに分類する
DLP（Data Loss Prevention）を利用する
USBメモリなどの外部媒体の利用を制限する
機密情報のメール添付や外部共有にルールを設ける

物理的なセキュリティを行う

オフィスやサーバールームへの入退室を管理する
離席時に画面をロックする
端末紛失時にリモートロック・ワイプできるようにする
紙の機密資料を放置しない

2. 完全性（Integrity）

完全性とは

情報が正確かつ完全な状態に保たれ、不正または意図しない変更・削除・破壊を受けていないことです。

たとえば銀行振込の金額、証券取引の注文内容、契約書、システム設定などが途中で書き換えられてしまえば、機密性が守られていても安全なシステムとはいえません。

代表的なリスク

Webサイトの改ざん
データベースの不正更新
マルウェアによるファイル改変
操作ミスによるデータ破壊
不正なプログラムや設定変更
通信途中でのデータ改ざん

具体的な対策

書き込み権限を制御する

データの更新権限を必要な担当者・システムだけに限定する
本番環境への直接変更を制限する
管理者権限の利用を記録・監視する
重要な処理では承認者を分けるなど職務分離を行う

改ざんを検知する

ハッシュ値やチェックサムでファイルの変更を検知する
電子署名を利用する
Webサイトや重要ファイルの改ざん監視を行う
重要データの変更前後を監査ログに記録する

データベースの整合性を守る

主キー、外部キー、UNIQUE制約などを利用する
トランザクションを適切に利用する
入力値検証を行う
アプリケーション側だけでなくデータベース側でも制約を設定する

変更管理を行う

Gitなどのバージョン管理を利用する
Pull Requestやレビューを経て変更する
本番変更の承認プロセスを設ける
Infrastructure as Code（IaC）でインフラ構成をコード化する
CI/CDでテストや静的解析を自動化する

復元できるようにする

バックアップを取得する
世代管理・バージョニングを利用する
バックアップから実際に復元できることを定期的に確認する
ランサムウェアを想定し、変更・削除されにくいバックアップも用意する

3. 可用性（Availability）

可用性とは

許可された利用者が、必要なときに情報やシステムへアクセスし、利用できる状態を維持することです。

セキュリティは「守る」だけではありません。サービス停止を防ぎ、障害や災害が発生しても復旧できることも情報セキュリティです。

代表的なリスク

サーバー障害
ネットワーク障害
クラウド障害
DDoS攻撃
ランサムウェア
電源障害
災害
容量不足やアクセス集中
オペレーションミス

具体的な対策

単一障害点を減らす

サーバーやネットワークを冗長化する
ロードバランサーを利用する
複数のAvailability Zoneなどに分散する
DNSやネットワーク経路の冗長性も確認する

障害を検知する

CPU、メモリ、ディスク、ネットワークなどを監視する
アプリケーションの死活監視を行う
エラー率、応答時間などサービス品質を監視する
ログやメトリクスから異常を検知する
障害時に担当者へ通知する

バックアップと災害対策を行う

定期的なバックアップを取得する
復元手順を文書化する
復旧テストを定期的に行う
RTO（目標復旧時間）とRPO（目標復旧時点）を決める
BCPやDR計画を整備する

攻撃や負荷に備える

DDoS対策を行う
WAFを利用する
Auto Scalingなどで急激な負荷増加に備える
レート制限を導入する
キャパシティを継続的に監視する

保守可能な状態を維持する

OSやミドルウェアを適切にパッチ適用する
サポート切れ製品を使用し続けない
障害対応手順を整備する
特定の担当者しか復旧できない属人化を避ける

追加の4要素とは？

CIAだけでも情報セキュリティの基本を整理できますが、実際の業務システムでは「その人は本当に本人か」「誰が操作したか」「後から証明できるか」「システムそのものを信頼できるか」も重要です。

これを補うのが、真正性・責任追跡性・否認防止・信頼性です。

4. 真正性（Authenticity）

真正性とは

人、組織、システム、通信相手、データなどが、主張しているとおりの本物であることを確認できる性質です。

たとえば、正しいIDとパスワードが入力されたというだけでは、本人が操作しているとは限りません。盗まれた認証情報による「なりすまし」を防ぐ必要があります。

具体的な対策

多要素認証（MFA）を導入する
パスキーを利用する
生体認証を利用する
クライアント証明書やmTLSを利用する
サーバー証明書を正しく検証する
PKI（公開鍵基盤）を利用する
電子署名で文書やソフトウェアの発行元を確認する
コード署名を利用する
SPF、DKIM、DMARCなどでメール送信元のなりすまし対策を行う
アカウント発行時に本人確認を行う
サービスアカウントやAPI間通信でも相互認証を行う

例

オンラインバンキングで、利用者が本当に口座名義人本人なのかをMFAやパスキーで確認することは、真正性を高める対策です。

5. 責任追跡性（Accountability）

責任追跡性とは

誰が、いつ、どこから、何に対して、どのような操作を行ったのかを追跡できる性質です。

セキュリティ事故が起きたときに、「何が起きたのか分からない」状態では、原因調査も再発防止もできません。

具体的な対策

操作を個人にひも付ける

共用IDを避け、一人ひとりに個別IDを発行する
管理者操作でも個人を識別できるようにする
特権ID管理（PAM）を導入する
代理操作や管理者操作では実行者を記録する

ログを取得する

ログイン・ログアウト
認証失敗
データ参照
データ登録・変更・削除
権限変更
管理者操作
設定変更
API呼び出し
重要な業務処理

などを監査ログとして残します。

ログを守る

ログを集中管理する
SIEMなどで検索・分析できるようにする
ログの保存期間を定める
ログへのアクセス権限を制限する
改ざん・削除されにくい保存先へ保管する
正確な時刻で記録できるようNTPなどで時刻同期する

定期的に確認する

特権操作を定期的にレビューする
不審なログインや大量ダウンロードを検知する
インシデント発生時にログを横断して追跡できるようにする

6. 否認防止（Non-repudiation）

否認防止とは

ある操作、送信、承認、契約などを行った当事者が、後からその事実を不当に否認できないように証明できる性質です。

責任追跡性が「誰が何をしたか追えること」だとすれば、否認防止はさらに一歩進んで、その事実を証拠として示せることに重点があります。

具体的な対策

電子署名を利用する
信頼できるタイムスタンプを利用する
重要操作の監査ログを保存する
WORMやイミュータブルストレージなど、変更・削除されにくい仕組みを利用する
電子契約で署名者、署名時刻、文書内容を証拠として保持する
承認ワークフローで承認者、日時、対象データを記録する
重要な取引では取引IDやリクエストIDを記録する
証拠となるログや記録の保存期間、保全方法、アクセス権限を定める

例

電子契約に電子署名とタイムスタンプを付与し、「誰が、どの文書に、いつ署名したか」を証明できるようにすることは、否認防止の代表例です。

7. 信頼性（Reliability）

信頼性とは

システムやサービスが、意図したとおりに一貫して正しく動作する性質です。

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

可用性：必要なときに使えるか
信頼性：使ったときに期待したとおり正しく安定して動くか

システムが稼働していても、頻繁に誤った計算結果を返したり、処理結果が不安定だったりすれば、信頼性が高いとはいえません。

具体的な対策

品質を作り込む

単体テスト、結合テスト、システムテストを行う
自動テストをCI/CDへ組み込む
コードレビューを行う
静的解析や依存ライブラリの脆弱性チェックを行う
本番相当環境でリリース前検証を行う

構成を安定させる

Infrastructure as Code（IaC）を利用する
構成管理を行う
手作業による本番変更を減らす
環境ごとの差分を把握する
変更履歴を残す

状態を監視する

SLI/SLOなどでサービス品質を定義する
エラー率、レイテンシ、処理成功率などを監視する
異常時にアラートを出す
障害の原因分析と再発防止を行う

障害が全体へ広がらないようにする

タイムアウトを設定する
リトライを適切に制御する
サーキットブレーカーなどを利用する
コンポーネントを分離する
外部サービス障害時の動作を設計する

運用を標準化する

リリース手順を標準化する
変更管理を行う
障害対応手順を整備する
定期的に障害訓練を行う
サポート切れソフトウェアや属人化を減らす

7要素の違いを具体例で理解する

たとえば、オンラインサービスで「顧客が取引を実行する」という処理を考えてみます。

要素	確認すること
機密性	他の顧客に取引情報を見られないか
完全性	注文数量や価格が途中で改ざんされないか
可用性	必要な時間帯に取引できるか
真正性	操作している人が本当に本人か
責任追跡性	誰がいつどの注文を操作したか追跡できるか
否認防止	後から注文した事実を不当に否認されないよう証明できるか
信頼性	注文処理が仕様どおり正しく安定して動くか

このように整理すると、7要素は単なる用語集ではなく、システム設計やセキュリティレビューのチェック観点として利用できます。

実務では何をすればよいか

7要素を覚えるだけでは、セキュリティ対策にはなりません。

実際の組織やシステムでは、次の順序で確認すると実践しやすくなります。

1. 守る対象を明確にする

まず情報資産を洗い出します。

顧客情報
個人情報
契約情報
取引情報
認証情報
ソースコード
システム設定
ログ
バックアップ
クラウドアカウント
PC・スマートフォンなどの端末

何を守るのか分からなければ、必要な対策も決められません。

2. CIAでリスクを確認する

各情報資産について、次を考えます。

漏えいしたらどうなるか
改ざんされたらどうなるか
利用できなくなったらどうなるか

この3つがCIAです。

3. 認証とアクセス制御を整える

MFA・パスキー
最小権限
個別アカウント
特権ID管理
定期的な権限棚卸し

を実施します。

これは主に機密性と真正性を高めます。

4. 変更とデータを保護する

バージョン管理
レビュー
承認
ハッシュ
電子署名
データベース制約
バックアップ

などを利用し、完全性を守ります。

5. 記録を残す

誰が
いつ
どこから
何を
どのように変更したか

を監査ログとして残します。

これは責任追跡性と否認防止に重要です。

6. 止まらない・復旧できる仕組みを作る

冗長化
監視
バックアップ
DR
RTO/RPO
DDoS対策
障害対応訓練

などを整備し、可用性を確保します。

7. 継続的にテスト・改善する

脆弱性診断
ペネトレーションテスト
バックアップ復元テスト
DR訓練
インシデント対応訓練
権限レビュー
ログレビュー
障害分析
セキュリティ教育

を継続します。

信頼性を含め、7要素は一度対策すれば終わりではありません。

CIAだけでは不十分なのか？

CIAは今でも情報セキュリティの中心となる重要な考え方です。

一方、現在のシステムではクラウド、API、SaaS、リモートワーク、電子契約、オンライン取引などが増えています。そのため、

本当に本人なのか
本物のシステムと通信しているのか
誰が操作したのか
その操作を証明できるのか
システムは期待どおり動作しているのか

まで考える必要があります。

そのため、CIAに加えて真正性、責任追跡性、否認防止、信頼性を確認することには大きな意味があります。

まとめ

情報セキュリティの基本は、次のCIA 3要素です。

Confidentiality（機密性）：許可されていない人に情報を見せない
Integrity（完全性）：情報を正確で完全な状態に保つ
Availability（可用性）：必要なときに利用できるようにする

さらに、次の4要素も重要です。

Authenticity（真正性）：本物であることを確認する
Accountability（責任追跡性）：誰が何をしたか追跡できるようにする
Non-repudiation（否認防止）：行為を後から不当に否認できないよう証明する
Reliability（信頼性）：システムが期待どおり安定して動作するようにする

重要なのは、7つの用語を暗記することではありません。

自分たちの情報やシステムについて、この7つの観点から「何が起きると困るのか」「現在どのような対策があるのか」「不足している対策は何か」を確認することです。

システム設計、セキュリティレビュー、リスクアセスメントを行う際には、CIAを出発点として、追加4要素まで確認すると、抜け漏れを減らしやすくなります。

参考資料

ALSOK「情報セキュリティのCIA（3要素）とは？機密性・完全性・可用性を実例で解説」
https://www.digitalsales.alsok.co.jp/col_cia
IPA「セキュア・プログラミング講座」内の情報セキュリティ定義
https://www.ipa.go.jp/archive/security/vuln/programming/ps6vr70000012yp1-att/000059838.pdf
ISO/IEC 27000 family — Information security management
https://www.iso.org/standard/iso-iec-27000-family