はじめに
情報セキュリティを学び始めると、まず出てくるのが「CIA」です。
ここでいうCIAは、アメリカの情報機関ではありません。
情報セキュリティの基本である、次の3要素の頭文字です。
- Confidentiality：機密性
- Integrity：完全性
- Availability：可用性
いわゆる「情報セキュリティの3要素」です。
ただ、実務でセキュリティを考えていくと、すぐにこういう場面にぶつかります。
「データは漏れていない。壊れてもいない。使える状態でもある。でも、それを本当に本人が操作したと言えるのか？」
この問いは、CIAだけでは少し扱いにくいです。
そこで本稿では、ISO/IEC 27000で言及される考え方をもとに、CIA3要素に加えて、真正性、責任追跡性、否認防止、信頼性を含めた「情報セキュリティ7要素」を初心者向けに整理します。
なお、重要な注意点があります。ISO/IEC 27000では、情報セキュリティの中心はあくまで「機密性・完全性・可用性の保持」です。そのうえで、真正性、責任追跡性、否認防止、信頼性などの性質も含み得る、という位置づけです1。
つまり、「CIAが古くなって7要素に置き換わった」というより、CIAを土台にして、実務で見るべき観点を広げる、と理解するのが安全です。
1. まずCIA3要素を押さえる
情報セキュリティの基本は、次の3つです。
| 要素 | 日本語 | ざっくり言うと | 例 |
|---|---|---|---|
| Confidentiality | 機密性 | 見せてはいけない人に見せない | 顧客情報を権限者だけが見られる |
| Integrity | 完全性 | 情報が正しく、勝手に変えられていない | 請求金額が改ざんされていない |
| Availability | 可用性 | 必要なときに使える | 障害時でもシステムを利用できる |
機密性：見せてはいけない人に見せない
機密性は、情報が許可されていない人やシステムに開示されないようにする性質です。
たとえば、給与情報、顧客情報、設計書、認証情報などは、誰でも見られてよいものではありません。
具体策としては、次のようなものがあります。
- アクセス権限
- 暗号化
- 多要素認証
- 画面や帳票のマスキング
- 秘密情報の持ち出し制限
機密性の観点では、「誰に見せないか」が重要です。
完全性：勝手に変えられていない
完全性は、情報が正確で、改ざんや破損がない状態を保つ性質です。
たとえば、振込先口座番号が1文字でも書き換えられていたら大問題です。金額、在庫数、契約条件、ログの時刻なども同じです。
具体策としては、次のようなものがあります。
- 入力チェック
- 変更履歴の保存
- ハッシュ値による検証
- データベースの制約
- 承認ワークフロー
完全性の観点では、「その情報は正しいままか」が重要です。
可用性：必要なときに使える
可用性は、必要な人が、必要なときに情報やシステムを使える性質です。
どれだけ厳重に守られていても、業務で使えなければ困ります。セキュリティは「止めること」だけではなく、「安全に使い続けること」でもあります。
具体策としては、次のようなものがあります。
- バックアップ
- 冗長化
- 障害監視
- 復旧手順
- DDoS対策
- 災害対策
可用性の観点では、「必要なときに使えるか」が重要です。
2. なぜCIAだけでは足りないのか
CIAは非常に強い基本形です。
しかし、実務ではCIAだけでは説明しきれない問題が出てきます。
たとえば、次のようなケースです。
| ケース | CIAだけで見た場合 | 追加で必要になる観点 |
|---|---|---|
| ログインに成功した | 機密性は守られているように見える | 本当に本人か |
| 申請データが保存された | 完全性は保たれているように見える | 誰が申請したか |
| 電子契約が成立した | データは残っている | 後から「自分は承認していない」と言えないか |
| システムが稼働している | 可用性はある | 動作結果を信頼してよいか |
ここで出てくるのが、追加の4要素です。
- Authenticity：真正性
- Accountability：責任追跡性
- Non-repudiation：否認防止
- Reliability：信頼性
これらは、CIAの外側に別物として存在するというより、CIAを実務に落とし込むときに必要になる補助線です。
3. 追加4要素を初心者向けに理解する
真正性：本物であると言えるか
真正性は、「それが本物である」「主張どおりの相手・情報である」と確認できる性質です。
たとえば、次のような問いです。
- ログインしているのは本当に本人か
- 表示しているWebサイトは本物か
- 受け取ったメールは本当にその会社から来たものか
- ダウンロードしたファイルは正規のものか
真正性は、なりすまし対策と深く関係します。
具体策としては、次のようなものがあります。
- 多要素認証
- 電子証明書
- デジタル署名
- SPF、DKIM、DMARC
- 正規ドメインの確認
- ソフトウェア署名
初心者向けに言えば、真正性は「それ、本物ですか？」を確認する観点です。
責任追跡性：誰がやったか追えるか
責任追跡性は、ある操作や出来事について、誰が、いつ、何をしたのかを追跡できる性質です。
たとえば、次のような問いです。
- 誰が顧客情報を閲覧したのか
- 誰が設定を変更したのか
- 誰が承認したのか
- どのアカウントが削除処理を実行したのか
責任追跡性がないと、事故が起きたときに原因を調べられません。
具体策としては、次のようなものがあります。
- 操作ログ
- 監査ログ
- 個人ごとのアカウント
- 共用IDの廃止
- 権限変更履歴
- ログの保全
初心者向けに言えば、責任追跡性は「あとから追える状態にする」ことです。
ここで注意したいのは、「責任追跡性」は犯人探しだけのためにあるわけではない、ということです。
むしろ実務では、再発防止、原因分析、内部統制、監査対応のために重要です。
否認防止：あとから「やっていない」と言えないか
否認防止は、ある行為をした人が、後からその行為を否定できないようにする性質です。
たとえば、次のような場面です。
- 電子契約に同意した
- 発注を承認した
- 重要な申請を提出した
- メッセージを送信した
- 取引を実行した
このとき、後から「私は承認していません」「そのデータは送っていません」と言われると困ります。
具体策としては、次のようなものがあります。
- 電子署名
- タイムスタンプ
- 承認ログ
- 送信記録
- 改ざん困難な監査証跡
- 本人認証と操作記録の組み合わせ
初心者向けに言えば、否認防止は「あとからしらばっくれられないようにする」観点です。
ただし、これは強い言い方をすると誤解されやすいです。実務上は、本人性、操作内容、時刻、証跡を組み合わせて、合意や操作の事実を説明できる状態にする、と考えるほうが自然です。
信頼性：期待どおりに動くと言えるか
信頼性は、システムや処理が期待されたとおりに、一貫して動作すると信頼できる性質です。
たとえば、次のような問いです。
- このシステムは安定して処理できるか
- 同じ条件で同じ結果を返すか
- エラー時に不正な結果を出さないか
- 障害が起きてもデータが壊れないか
- ログや結果を信用してよいか
可用性が「使えるか」に近いのに対し、信頼性は「使った結果を信じてよいか」に近いです。
具体策としては、次のようなものがあります。
- テスト
- 監視
- エラーハンドリング
- 再試行制御
- 品質管理
- 変更管理
- 障害分析
- リリース判定
初心者向けに言えば、信頼性は「ちゃんと動くと信じられるか」です。
4. 7要素を業務シーンで見る
ここまでの7要素を、身近な業務シーンに当てはめてみます。
例として、経費精算システムを考えます。
| 要素 | 経費精算システムでの例 |
|---|---|
| 機密性 | 他人の経費申請や口座情報を見られない |
| 完全性 | 金額や承認状態が勝手に書き換わらない |
| 可用性 | 月末締め処理のときにシステムが使える |
| 真正性 | ログインしているのが本人だと確認できる |
| 責任追跡性 | 誰が申請し、誰が承認したか追える |
| 否認防止 | 承認者が後から「承認していない」と言えない証跡がある |
| 信頼性 | 計算結果や承認フローが期待どおりに動く |
このように見ると、CIAだけでは見落としやすい部分が見えてきます。
特に、クラウドサービス、電子契約、生成AI、API連携、ゼロトラスト、リモートワークのような環境では、「誰が」「本当に」「あとから追えるか」が重要になります。
つまり、7要素は暗記用語ではありません。
システムや業務を安全に使うためのチェック観点です。
5. 初心者はどう使えばよいか
初心者のうちは、7要素を完璧に分類しようとしなくても大丈夫です。
むしろ、次のような問いに変換すると使いやすくなります。
| 要素 | 確認する問い |
|---|---|
| 機密性 | 見てはいけない人が見られないか |
| 完全性 | 勝手に変えられていないか |
| 可用性 | 必要なときに使えるか |
| 真正性 | 本人・本物だと言えるか |
| 責任追跡性 | あとから誰が何をしたか追えるか |
| 否認防止 | 後から否定されても説明できるか |
| 信頼性 | 期待どおりに動くと信じられるか |
たとえば、新しいSaaSを導入するときも、この7つで確認できます。
- 重要データの閲覧制限はできるか
- データ変更履歴は残るか
- 障害時の復旧目標はあるか
- 多要素認証は使えるか
- 管理者操作ログは取れるか
- 承認操作の証跡は残るか
- サービス品質や運用体制は信頼できるか
ここまで見れば、単なる「便利そうなツール選び」から、「業務に使ってよいかの判断」に変わります。
おわりに
情報セキュリティの基本は、今でもCIAです。
機密性、完全性、可用性を押さえずに、セキュリティを語ることはできません。
一方で、実務ではCIAだけでは足りない場面があります。
特に、本人確認、操作ログ、電子契約、監査、クラウド、AI活用のような領域では、真正性、責任追跡性、否認防止、信頼性の観点が重要になります。
本稿の結論はシンプルです。
まずCIAで考える。
次に、4つの追加観点で抜け漏れを見る。
この順番で考えると、初心者でも情報セキュリティをかなり実務的に理解できます。
セキュリティは、専門家だけが使う難しい言葉ではありません。
「誰が見られるのか」
「情報は正しいのか」
「必要なときに使えるのか」
「本当に本人なのか」
「あとから追えるのか」
「否定されても説明できるのか」
「ちゃんと動くと信じてよいのか」
この7つの問いに置き換えるだけで、情報セキュリティはかなり見えやすくなります。
参考
-
ISMS-AC「Overview of ISMS」
ISMSの概要、CIA3要素、真正性・責任追跡性・否認防止・信頼性にも言及されることの確認に使用。ISMS-ACは、ISMS認証機関の認定に関する情報を公開している機関です。 ↩