>
>
公開日
最終更新日
機密性・完全性・可用性はCVSSv3等の評価基準でも用いられる情報セキュリティの3要素です。
中堅・中小企業の情シス（情報システム）部門では、情報漏えいを防ぐだけでなく、データの正確性を保ち、必要なときに業務システムを利用できる状態を維持しなければなりません。機密性は「許可された人だけが情報を見られること」、完全性は「データが正確で改ざん・欠損がないこと」、可用性は「必要な利用者が必要なときにシステムやデータを使えること」を指します。
本記事では、CIAの定義を日常的な情シス業務に置き換え、アクセス権限、操作ログ、バックアップ、復元テスト、ISMSのリスクアセスメントへどう反映するかを解説します。また、アクセス制限や承認フローを必要以上に厳しくすると、担当者が管理外のクラウドサービスや個人デバイスを業務に使い始めるシャドーITが発生します。利便性を大きく損なう対策は運用が形骸化しやすく、結果として管理の及ばない範囲が広がります。本記事では、こうした失敗例も踏まえ、事業への影響に応じて対策の優先順位を決める判断材料を示します。
CIAとは？情報セキュリティを支える3要素
CIAとは、情報セキュリティで守るべき性質を示す機密性（Confidentiality）・完全性（Integrity）・可用性（Availability）の頭文字です。情報資産を安全に扱うには、「見せてはいけない人に見せない」「内容を勝手に変えられない」「必要なときに使える」という3つの状態を、業務に合わせて維持します。
3要素は独立しているように見えて、実際には相互に関係します。たとえば、強固な認証を導入しても、利用者が必要なタイミングでログインできなければ可用性に影響します。一方で、利便性だけを優先して共有アカウントを使えば、機密性と完全性を損なうおそれがあります。情シス担当者は、利用部門の業務時間、扱う情報、停止時の影響を並べて確認すると、3要素の間で生じる優先順位を説明しやすくなります。
要素 | 意味 | 日常業務で起こりやすい問題 | 主な対策例 |
|---|---|---|---|
機密性 | 許可された人だけが情報へアクセスできる状態 | メール誤送信、退職者アカウントの放置、共有フォルダの公開範囲設定ミス | アクセス権限の最小化、多要素認証、アカウント棚卸し、暗号化 |
完全性 | 情報が正確であり、意図しない変更や削除がされていない状態 | 受発注データの誤更新、権限を持つ担当者による不正な書き換え、マルウェアによる改ざん | 変更履歴、承認フロー、ログ監視、バックアップ、入力値チェック |
可用性 | 許可された利用者が必要なときに情報やシステムを利用できる状態 | ランサムウェア、サーバー障害、回線障害、バックアップ復元の失敗 | 冗長化、復旧手順の整備、オフラインを含むバックアップ、障害訓練 |
この表を、情報資産台帳やリスクアセスメントで「どの資産に、どのCIAが特に求められるか」を整理する際の基準として使うと、対策の優先順位を決めやすくなります。資産台帳には、資産の所有部門、保管場所、利用者、外部委託先に加え、CIAをそれぞれ高・中・低で評価した理由、停止許容時間、復旧担当者も記載します。
たとえば、顧客名簿は機密性を高く、会計データは完全性を高く、受発注システムは可用性を高く置く評価例があります。すべてを一律に最高評価へするのではなく、影響が大きい資産から対策の担当者・期限・確認方法を決めると、限られた情シスの工数でも着手順を明確にできます。
▲ CIA3要素の相互関係とセキュリティバランスの概念図
機密性（Confidentiality）の具体例と対策
機密性は、顧客情報、従業員情報、見積書、設計資料、契約書、認証情報などを、権限のない第三者に閲覧・取得させないことです。情報漏えいは外部攻撃だけでなく、日常的な操作ミスやアカウント管理の不備でも発生します。
代表例は、宛先を誤ったメール送信です。添付ファイルに個人情報や取引情報が含まれる場合、誤送信は機密性の侵害になります。送信前の宛先確認、外部宛てメールの上長承認、添付ファイルの暗号化、ファイル共有サービスでの期限付きリンクの利用など、業務フローに合わせた対策を組み合わせます。ただし、添付ファイルの暗号化はパスワードを同じメールで送るケースでは保護効果が限定的になります。ファイル共有リンクは、共有範囲の絞り込み、有効期限、ダウンロード可否の設定を含めて設計しないと、リンク流出時に情報が広く公開されるリスクが残ります。どの手段を選ぶかは、情報の重要度と送受信相手の環境に応じて判断します。
SaaSの利用では、異動者・退職者のアカウントが残っている、管理者権限を持つアカウントが必要以上に多い、共有フォルダがリンクを知る全員に公開されている、といった状態が問題になります。人事異動や退職の手続きとアカウント停止を連動させ、定期的に利用者・権限・外部共有設定を棚卸しします。人事システムとID管理機能を連携できる環境では、退職日を起点に停止対象を抽出します。連携できない環境では、人事部門から情シスへ異動・退職一覧を渡す締切日と、停止完了を照合する担当者を決めます。
また、パスワードだけに依存すると、フィッシングやパスワード再利用による不正ログインの影響を受けます。管理者権限、社外から利用するSaaS、VPN、メールなどから多要素認証を適用し、利用状況をログで追える状態にします。
最初の30日では、①管理者権限を持つアカウント、②退職者・休職者の残存アカウント、③外部公開中の共有リンク、④多要素認証が未設定の利用経路を一覧化します。アカウント台帳、人事異動・退職一覧、各SaaSの管理画面にあるユーザー一覧と共有設定を照合し、残存アカウントや不要な公開リンクが確認できれば停止・削除を優先します。照合できないSaaSが残る場合は、そのサービスを台帳へ追加し、所有部門と管理者を確定してから限定的に利用状況を確認します。
社内で扱うべき機密情報の定義や個人情報との違いと適切な管理体制について理解を深めたい方は、こちらの解説記事も併せてご確認ください。
完全性（Integrity）の具体例と対策
完全性は、情報が正しく、意図しない改変・削除・破損が起きていない状態です。データが外部へ漏れていなくても、売上、在庫、給与、顧客マスタ、契約内容などが誤って書き換えられれば、業務判断や取引先との関係に大きな影響が生じます。
たとえば、ExcelやSaaS上の顧客リストを複数人が更新し、誰がいつ何を変更したか分からない状態では、誤更新や不正な変更を発見しにくくなります。変更履歴を保存できるサービスを利用し、重要なマスタデータは編集者と承認者を分けることで、誤操作と不正の両方を抑えられます。
完全性の管理では、データの正しさだけでなく、設定情報やプログラムの変更も対象です。ファイアウォールの設定、クラウドのアクセス制御、サーバー設定などは、変更前後の内容、変更者、承認者、変更日時を記録します。障害やインシデントの発生時に、どの変更が影響したかを追跡しやすくなります。
ランサムウェアや不正アクセスでは、データ暗号化や削除だけでなく、内容の改ざんが起こる可能性もあります。復元用バックアップは取得するだけでは十分ではなく、復元後のデータが業務で使える状態かを定期的に確認します。
復元テストの合格条件は、単にファイルを開けることではなく、業務部門が必要な帳票・検索・登録処理を実行できることとして定めます。たとえば受発注データなら、指定時点のデータが復元され、注文検索、在庫引当、出荷指示の各操作が実行でき、変更履歴や権限設定も想定どおりに戻る状態を確認対象にします。業務部門が復元結果を判定できるなら、次回テストでは対象範囲を広げます。判定者や基準が定まらない場合は、まず重要な1業務・1データセットに対象を絞り、合格条件を台帳へ記録します。
可用性（Availability）の具体例と対策
可用性は、必要な利用者が必要なときにシステム、データ、ネットワークを使える状態です。受発注、勤怠、会計、顧客対応、製造管理など、停止時間がそのまま事業影響につながる業務では、可用性を具体的な復旧目標として定義します。
可用性を損なう原因には、サーバー故障、クラウドサービスの障害、ネットワーク断、設定ミス、自然災害、DDoS攻撃、ランサムウェアなどがあります。特にランサムウェアは、端末やサーバーのデータを暗号化して使えなくするため、機密性だけでなく可用性にも直接影響します。
IPAは、2026年1月29日に公表した「情報セキュリティ10大脅威 2026」で、組織向け脅威の1位に「ランサム攻撃による被害」を挙げ、2016年から11年連続11回目の選出としています。同資料では、3位に「AIの利用をめぐるサイバーリスク」が2026年に初選出され、8位には「リモートワーク等の環境や仕組みを狙った攻撃」が挙げられています。ランサム攻撃は、データを暗号化して業務を停止させるだけでなく、窃取した情報の公開を材料に脅迫する手口も含まれるため、可用性（業務停止）と機密性（データ持ち出し）の両方を評価対象にします。
停止を防ぐ対策には、端末・サーバー・ネットワーク機器の更新、脆弱性修正、監視、冗長化があります。復旧のためには、バックアップの世代管理、ネットワークから切り離した保管先、復旧手順書、連絡体制、代替業務の準備が必要です。バックアップから復元する担当者、復元に必要な認証情報、復元完了を判断する業務部門をあらかじめ定めておくと、緊急時の混乱を抑えられます。
停止許容時間が短い業務では、復旧手順書に「誰が」「どのバックアップから」「どの順番で」「どの連絡先へ」作業するかを記載します。たとえば、受発注システムが停止した場合に電話・メール・紙帳票で受注を受ける代替手順を用意できるなら、復旧作業中の取引を継続できます。代替手順を用意できない業務では、復旧時間の目標と必要な冗長化の範囲を経営層・業務部門と決め、可用性の評価理由として資産台帳へ残します。
10大脅威でも指摘される新たなリスクへの備えとして、シャドーAIによる情報漏洩リスクと情シス向け検知対策をあらかじめ確認しておくことが推奨されます。
CIAをISMS運用とリスクアセスメントに生かす方法
ISMSの運用では、CIAを抽象的な標語として扱うのではなく、情報資産ごとのリスク評価に落とし込みます。ISOは、ISO/IEC 27001:2022をISMSの要求事項を定める規格として公開しており、日本では、日本産業標準調査会（JISC）がISO/IEC 27001:2022に対応してJIS Q 27001:2023（日本規格協会Webdesk）を制定・改正しています。ISO/IEC 27001:2022は、組織がリスクアセスメントの基準とプロセスを定めることを求める規格であり、CIAによる評価方法を一律に指定するものではありません。CIAは、情報資産への影響を評価する代表的な軸として、組織が定める基準に組み込めます。ISOは、リスク管理の手引としてISO/IEC 27005:2022を、情報セキュリティ管理策の指針としてISO/IEC 27002:2022を公開しています。まず、顧客情報、見積書、会計データ、ソースコード、業務システム、SaaSアカウント、PC、ネットワーク機器などを情報資産として洗い出します。 ([iso.org](https://www.iso.org/standard/80585.html?utm_source=openai))
次に、各資産について、機密性・完全性・可用性が損なわれた場合の影響を考えます。たとえば顧客名簿は、漏えい時の影響から機密性を高く評価し、会計データは誤った数値で経営判断が行われることを踏まえて完全性を高く評価します。受発注システムは、停止時に受注や出荷ができなくなるため、可用性を高く評価する対象です。
リスクは「脅威」「脆弱性」「影響」を組み合わせて整理します。退職者アカウントが残るという脆弱性に対し、不正ログインや情報持ち出しという脅威があり、顧客情報の漏えいや取引先からの信用低下という影響が考えられます。対策後も残るリスクを記録し、受容するのか、追加対策を実施するのかを経営層や責任者と判断します。
運用後は、①アクセス権レビュー、②ログ確認、③バックアップ復元テスト、④脆弱性情報の確認、⑤教育・インシデント対応訓練を定期的に実施してCIAを維持します。アクセス権レビューは異動・退職の発生時に加え、重要資産や権限変更が多いSaaSでは四半期ごとを目安に設定できます。バックアップ復元テストは年1回以上を目安にできますが、頻度は資産の重要度、変更頻度、復旧目標、法令・契約上の要件に応じて決めます。IPAとJPCERT/CCが運営する脆弱性対策情報データベースJVN iPediaは、国内外で公開される脆弱性対策情報を収集・蓄積しており、利用製品の脆弱性確認に利用できます。組織変更やシステム追加が生じた際は、情報資産台帳とリスクアセスメントをその都度更新し、対策とのずれを解消します。 ([jvndb.jvn.jp](https://jvndb.jvn.jp/index.html?utm_source=openai))
運用頻度を決める際は、資産台帳の「重要度」「変更頻度」「停止許容時間」「契約・法令要件」の4項目を確認します。高い管理者権限を持つSaaS、顧客情報を扱う共有ストレージ、停止が受注や出荷へ直結するシステムは、確認間隔を短く設定します。これらの項目を記録できれば、情シスは限られた時間を高影響資産へ配分できます。記録できない資産は、所有部門・管理者・利用目的を先に確定し、評価対象へ加えます。
ISMSのリスクアセスメントと並行してサプライチェーン全体の評価を進める際は、SCS評価制度の★3取得に向けた83項目のチェックリストをご活用ください。
▲ 情報資産の特性に応じた重点CIA要素の判定フロー
▲ ISMS運用におけるCIAを活用したリスクアセスメントの4ステップ
まとめ
CIAは、情報を見せる相手を制御する機密性、正しい内容を保つ完全性、必要なときに使える状態を保つ可用性の3要素です。メール誤送信やSaaSアカウントの放置は機密性、データの誤更新や改ざんは完全性、ランサムウェアや障害による停止は可用性の問題として整理できます。
ISMSでは、情報資産ごとにCIAのどれを優先するかを評価し、アクセス権、変更管理、バックアップ、復旧手順、ログ監視、教育などの対策に結び付けます。IPAは「情報セキュリティ10大脅威 2026」で、組織向け脅威の1位に「ランサム攻撃による被害」を挙げています。情シスは、日常運用の確認項目と非常時の復旧手順を資産台帳・手順書へ残し、資産の重要度、変更頻度、復旧目標に合わせて見直し間隔を決めます。 ([ipa.go.jp](https://www.ipa.go.jp/security/10threats/10threats2026.html))
初回点検チェックリスト
ISMSや機密性・完全性・可用性の管理を始める際、以下の項目を最初の30日で確認します。各項目の確認先と、結果に応じた対応を併記しています。
管理者権限アカウントの一覧化：各SaaS・システムの管理画面「ユーザー・権限管理」から抽出。管理者が3名以上いる場合は、業務上の必要性を所有部門に確認し、不要な権限を降格する。
退職者・休職者の残存アカウント確認：人事部門から最新の在籍一覧を取得し、SaaS管理画面のユーザー一覧と照合。一致しないアカウントは即時停止を優先する。
外部公開中の共有リンク確認：クラウドストレージ（SharePoint、Google Drive等）の管理コンソールで外部共有一覧を出力。有効期限・ダウンロード可否が未設定のリンクは、所有部門に用途を確認してから期限を設定するか削除する。
多要素認証の適用状況：VPN、メール、SaaS管理画面の認証設定を確認。MFAが未設定の経路では、設定を有効化するか、有効化できない理由と代替策を台帳に記録する。
バックアップ復元テストの実施記録：直近1年以内に復元テストを実施した記録が存在するかを手順書・台帳で確認。記録がない場合は、最重要業務1件を対象に復元テストを計画する。
資産台帳・復元テストの記入例
以下は情報資産台帳の記入例です。資産ごとにCIAの評価と復元テスト結果を残すことで、次回レビュー時の変更点が明確になります。
資産名 | 所有部門 | 保管場所 | 機密性 | 完全性 | 可用性 | 停止許容時間 | 復旧担当者 | 復元テスト直近実施日 | テスト合格条件 |
|---|---|---|---|---|---|---|---|---|---|
顧客名簿 | 営業部 | SaaS（CRM） | 高 | 中 | 中 | 24時間 | 情シス 山田 | 2025-03-15 | 顧客検索・CSV出力が実行できること |
受発注システム | 物流部 | オンプレサーバー | 中 | 高 | 高 | 4時間 | 情シス 佐藤 | 2025-01-20 | 注文検索・在庫引当・出荷指示が実行でき、変更履歴が想定どおりに復元されること |
会計データ | 経理部 | クラウドストレージ | 高 | 高 | 中 | 48時間 | 情シス 鈴木 | 2024-12-10 | 指定月の仕訳データが開け、集計結果が復元前と一致すること |
復元テストの合格・不合格は、業務部門の担当者が判定します。不合格の場合は原因・対処内容・再テスト予定日を同じ台帳に追記します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
