リスクアセスメントの基本 ー 効果的なリスク管理のステップ
はじめに
本記事は、社内IT体制の構築に役立てていただくために、日常業務で実践できる対応方法をご紹介する「実践運用記事（第2弾）」です。前回の「情報資産台帳の洗い出し」に続き、今回は「リスクアセスメント」の進め方と実践テクニックについて解説いたします。ISMS（情報セキュリティマネジメントシステム）認証の取得支援にもご活用いただける内容となっており、記事の手順を参考にそのまま実施するだけでも十分な効果が期待できます。ぜひご参考になさってください。
リスクアセスメントとは
リスクアセスメントとは、情報資産に潜むリスクを可視化し、組織のリスク許容度に応じた対応方針を決定するプロセスを指します。 自社や組織のサイバーセキュリティリスクをできる限り低減するためには、まず「どこにリスクが存在するのか」を正確に把握しておく必要があります。
そもそもリスクとは、脅威が脆弱性を突いたときに発生する損失の可能性を意味します。
- 脅威（Threat）：資産に対して発生し得る望ましくない出来事
- 技術的脅威（マルウェア感染など）
- 内部的脅威（ヒューマンエラーや内部不正など）
- 物理的脅威（火災・地震・水害など）
- 脆弱性（Vulnerability）：セキュリティ上の弱点や欠陥
サイバーセキュリティの国際的なフレームワークのひとつであるISMSにおいても、リスクの特定・分析・評価は、重要な対応事項として明確に定められています。 ISMS認証の取得においては、自社のリスクを正しく把握し、適切な対策を講じることが求められるため、リスクアセスメントの実施が不可欠です。
ここで重要なのは、「リスクをゼロにすること」を目指すのではなく、リスクを適切に管理するという考え方です。 リスクを完全に排除することは不可能であるため、どのリスクに対して、どの程度の対応を講じるのかを予め決定しておくことが、現実的なリスクマネジメントの第一歩となります。
「重要度」の算出の仕方（復習）
前回の記事でも説明しておりますが、重要度という考え方は、リスクアセスメントにおいては非常に重要になってきます。再度端的に重要度を振り返りましょう。
重要度とは、その資産に対する価値を洗い出す方法として用いられる指標であり、「機密性」「完全性」「可用性」の3点を用いることによって導きます。
重要度 = 機密性 + 完全性 + 可用性
例：機密性：3 ＋ 完全性：4 ＋ 可用性：5 = 12（重要度「高」）
高 | 11以上（重要な資産で、最大限の保護が必要） |
|---|---|
中 | 7～10（比較的重要な資産で、適切な保護が必要） |
小 | 6以下（低重要度の資産で、最低限の保護のみが必要） |
リスクアセスメント対象の決定方法
まず、「どの資産を対象としてリスクアセスメントを実施するか」を決定することが重要です。
1. 資産管理台帳の資産ごとに決める
シンプルな方法としては、情報資産台帳に記載の情報資産をベースに、資産ごとにリスクアセスメントを進めることです。そのうえで、それぞれの資産について考えうるリスクを記載し、必要に応じて企業独自のアプローチを組み合わせながら分析を進めることが推奨されます。
種別カテゴリー | 情報資産名 | リスク |
|---|---|---|
サービス | 利用者管理システム | ユーザー情報の漏えい、不正ログインならびにデータ改ざん、サービス停止 |
チャットボットエンジン | 情報漏えい、その他予期せぬ挙動 | |
製品 | 小売店向けレジ端末 | 物理盗難、POSログへの不正アクセス、誤送信や改ざん |
社内SaaS | 顧客情報 | 顧客情報の漏えい、退職者アカウント放置、情報の誤入力 |
メールソフト | 誤送信、添付ファイル経由でのマルウェア感染 | |
技術資料 | 製品設計図 | 情報の外部流出、データの破損による復旧不能 |
顧客関連 | 顧客アンケートデータ | 個人の意見や属性情報の外部流出、データ改ざん、データ収集の法令違反（個人情報保護法など） |
契約関連 | 取引先との秘密保持契約書 | 紛失や誤廃棄による契約内容の漏えい、改ざんによる訴訟リスク |
管理資料 | 社内給与シミュレーション表 | 不正アクセスによる情報漏えい、誤計算、資料の共有ミス |
中期経営計画書 | 社外漏えいによる株価・競争への影響 | |
管理システム | 勤怠クラウド | システム障害、不正打刻・なりすまし操作 |
会議関連 | 役員会議議事録 | 経営判断内容の漏えいによる信用失墜 |
2. 情報資産をグループに分ける
企業ごとに情報資産の分類方法には違いが見られますが、以下は利用形態や基盤ごとに分類した例です（「SaaS製品」「インフラ機器」「社内SaaS」等）。このように、資産を適切なカテゴリに整理し、そのカテゴリごとにリスクを洗い出すことで、リスクアセスメントの効率化が図れるパターンもあります。
資産カテゴリ | 利用部門 | 情報資産例 | 主なリスク |
|---|---|---|---|
SaaS製品 | 開発部門 | チャットボットエンジン | ユーザー情報の漏えい、不正ログイン、サービス停止 |
カスタマー部門 | 問い合わせ管理システム | サポートログの漏えい、クレーム対応記録の誤送信 | |
インフラ機器 | 店舗運営部門 | 小売店向けレジ端末 | 物理盗難、不正アクセス、誤操作によるPOSトラブル |
社内SaaS | 営業部門 | 顧客情報管理システム | 顧客情報の漏えい、退職者アカウントの放置 |
サポート部門 | メールソフト | メール添付ファイルからのマルウェア感染、誤送信 | |
技術資料 | 開発部門 | 設計書 | 技術情報の外部流出、設計漏えいによる競合リスク |
顧客関連 | マーケティング部門 | 顧客アンケートデータ | 属性データの漏えい、プライバシー法違反 |
契約関連 | 法務部門 | 取引先との秘密保持契約書 | 契約違反、改ざんによる訴訟リスク |
経営資料 | 経営企画部門 | 社内給与シミュレーション表 | 予算情報の外部漏えい、株価影響 |
経理部門 | 決算分析資料 | 決算情報の不正開示、税務調査対応の不備 | |
管理システム | 人事部門 | 勤怠クラウド | システム停止、勤怠ログ改ざん、勤怠打刻トラブル |
会議資料 | 経営層 | 役員会議議事録 | 会議内容の漏えい、経営判断の信頼失墜 |
3. ISO27001（附属書A）に則る
ISO27001（附属書A）に準拠した手法により、体系的にリスクを洗い出す方法もあります。国際規格に沿ったリスク管理を行いたい場合、このアプローチは有効です。 リスクを一覧表に整理する際は、左端に項目番号を記載し、それぞれのチェック項目に対応するリスクを整理することで、保持している（未対応の）リスクを明確に特定できます。
項目番号 | カテゴリ | 確認項目 | リスク |
|---|---|---|---|
8.1 | 利用者エンドポイント機器 | モバイル機器の利用を行う場合の方針は制定され、運用・実行されているか | ポリシー未整備による対応のばらつき |
盗み見やのぞき見防止のための対策はされているか | 対応済 | ||
8.2 | 特権的アクセス権 | 管理者権限の割当は最小限とし、割当者には責任を認識させ、厳重な管理を誓約させているか | 過剰な権限付与、権限管理の責任所在不明 |
8.3 | 情報へのアクセス制限 | 認可された者だけがアクセスできるようなシステム及び業務用ソフトウェアは、適切に管理を行っているか | 不正アクセスや権限外アクセスによる情報改ざんおよび漏えい |
8.4 | ソースコードへのアクセス | プログラムソースコードや開発ツール等へのアクセス管理は行っているか | 開発資産の流出、マルウェア混入によるバックドアリスク |
8.5 | セキュリティを保った認証 | 許容失敗回数の制限や、入力中のパスワードをマスキングするなどの配慮がされているか | ブルートフォース攻撃、パスワード漏えい |
上記それぞれのパターンにおいて、リスクの洗い出しは、機密性、完全性、可用性で分けて洗い出すことが理想なのは間違いありませんが、運用の上では上記のように分けて記載しなくても問題ありませんし、審査でも致命的な運用上の欠陥になることもありません。
リスク値ってどうやって決める？現場で使えるシンプルな計算法
リスク値の算出方法は複数存在し、それぞれに特長があります。いずれも一長一短があるため、状況に応じて適切な手法を選択することが重要です。
1.発生確率 × 影響度
最も一般的かつ現場でよく使われているリスク評価手法であり、JIS Q 27005やNIST SP800-30にも準拠しています。
- JIS Q 27005やNISTに準拠したベーシックな式
- 誰でも理解しやすく、実務導入しやすい
例）発生確率：3 × 影響度：4 = リスク値 12
この方法では、「どのリスク事象が起きたらどれくらい被害が出るか」にフォーカスし、リスクの優先順位をシンプルに整理します。
2.重要度 × 脅威 × 脆弱性
理論寄りなリスク評価方式で、情報資産ベースのISMS運用においてよく見られる算出法です。
- リスク要因が明確に分かれやすい
- 「どこに弱点があるか（脆弱性）」や「どこから来るか（脅威）」の整理がしやすい
- 脅威と脆弱性が分かれているため、同じスコアでも対策の優先順位が立てやすい
例）重要度：3 × 脅威：2 × 脆弱性：3 = リスク値 18
この手法は、リスクの内訳が別個にはっきり見えるため、脅威対策か脆弱性対策かを選びやすいという特徴があります。 （脅威スコアが高いなら防御強化、脆弱性スコアが高いなら修正優先など）
3.重要度 × 発生確率
シンプルな資産価値ベースのリスク評価方式で、特に中小企業や初期導入フェーズに向いています。
- 現場担当者でも直感的に理解でき、運用がしやすい
- 資産の重要度（守るべき優先度）を明確に示すことができる
例）重要度：3 × 発生確率：2 = リスク値 6
「この資産はどれだけ重要で、どのくらいの頻度でリスクが発生しうるか」という視点でリスクを整理するため、経営層や部門リーダーに対しても、リスク状況を視覚的にわかりやすく伝えることができます。
リスク値は必ずしも数値で出す必要はない
あまり知られていないところですが、リスク値の算出については、サイバーセキュリティの基本概念であるCIA（機密性・完全性・可用性）の観点から評価を行う方法もあります。
ISMSはあくまでその組織におけるマネジメントシステムを評価することにあるので、機密性、完全性、可用性をそれぞれの組織における基準で許容範囲を設定します。以下はその例です。
- 機密性：情報が外部に開示できない、あるいは社内でも閲覧制限が必要とされる場合にはチェックします。
- 完全性：情報の誤りや改ざんが発生した際に、業務、サービス、または会社全体に影響を与える可能性がある場合にはチェックします。
- 可用性：一定期間（例：数時間、1日、3日間など）にわたって利用できなくなった場合に、業務、サービス、または会社全体に影響を与える可能性がある場合にはチェックします。
IT部門 | 分類 | 利用部門 | 機密性 | 完全性 | 可用性 | 資産登録日 | 停止中 |
|---|---|---|---|---|---|---|---|
顧客データ | デジタル | 営業部、IT部門 | ✓ | ✓ | ✓ | 2013年3月31日 | - |
給与管理SaaS | ソフトウェア | 管理部 | ✓ | ✓ | 2018年4月14日 | ✓ | |
リリース済みのサービス | サービス | 開発部、営業部 | ✓ | ✓ | 2022年11月10日 | - | |
ソフトウェアライセンス | ソフトウェア | IT部門 | ✓ | 2024年5月13日 | - | ||
本社サーバー（機器） | 物理的資産 | IT部門 | ✓ | 2018年8月3日 | - | ||
本社サーバー（設計図） | 紙媒体 | IT部門 | ✓ | 2018年8月3日 | - | ||
クラウド | サービス | IT部門 | ✓ | ✓ | ✓ | 2022年4月2日 | - |
チェックマークを用いたリスク評価の手法は、シンプルで直感的な運用が可能な点で有効です。チェックマークが3つ付与された資産に対して何らかのリスク対応を実施する方針を定めることで、迅速な意思決定が可能となります。数値化によるリスク評価と比較すると、リスクの網羅性には課題があるものの、特に初期段階のリスク管理や経営層への説明においては有益な方法です。
リスクへの対応ー洗い出したリスクへの対処法
リスク値を算出し、優先度付けを行った後は、適切な対応策を講じる必要があります。 ISMS認証の観点からも、リスクを放置することは管理不十分とみなされるため、以下の方法のいずれかを選択することが推奨されます。
リスクの対応方針は大きく分けて、以下の4つに分かれます。
- リスク軽減：リスクの発生確率を下げたり、影響範囲を小さくするための対策を講じる
- リスク回避：該当するプロセスを停止したり、機器の使用を中止するなどして、リスクの原因そのものを排除する
- リスク移転：リスクの影響を外部へ委託あるいは移転する（例：保険加入や外部サービスを利用する）
- リスク受容：対策は講じず、リスクを認識したうえで許容する
最終的な表の形は、以下のようになります。
資産カテゴリ | 利用部門 | 情報資産例 | 主なリスク | リスク値 | リスク方針 | 対応内容 |
|---|---|---|---|---|---|---|
SaaS製品 | 開発部門 | チャットボットエンジン | ユーザー情報の漏えい、不正ログイン、サービス停止 | 12 | 軽減 | MFA、IP制限の導入 |
カスタマー部門 | 問い合わせ管理システム | サポートログの漏えい、クレーム対応記録の誤送信 | 8 | 軽減 | 送信ドメイン制御、アクセス権レビュー運用 | |
インフラ機器 | 店舗運営部門 | 小売店向けレジ端末 | 物理盗難、不正アクセス、誤操作によるPOSトラブル | 7 | 移転 | 保険加入、ローカルでのバックアップ |
社内SaaS | 営業部門 | 顧客情報管理システム | 顧客情報の漏えい、退職者アカウントの放置 | 8 | 軽減 | アカウント棚卸と自動無効化ポリシー |
サポート部門 | メールソフト | メール添付ファイルからのマルウェア感染、誤送信 | 8 | 軽減 | 添付制限、URLスキャン導入 | |
技術資料 | 開発部門 | 設計書 | 技術情報の外部流出、設計漏えいによる競合リスク | 14 | 回避 | 社外アクセスの制限、暗号化 |
顧客関連 | マーケティング部門 | 顧客アンケートデータ | 属性データの漏えい、プライバシー法違反 | 6 | 軽減 | 匿名化＋アクセス制限強化 |
契約関連 | 法務部門 | 取引先との秘密保持契約書 | 契約違反、改ざんによる訴訟リスク | 6 | 軽減 | 契約文書原本の紙保管と改ざん対策 |
経営資料 | 経営企画部門 | 社内給与シミュレーション表 | 予算情報の外部漏えい、株価影響 | 6 | 軽減 | ファイル暗号化とバックアップ自動化 |
経理部門 | 決算分析資料 | 決算情報の不正開示、税務調査対応の不備 | 4 | 受容 | 経理部内にのみアクセス許可（限定受容） | |
管理システム | 人事部門 | 勤怠クラウド | システム停止、勤怠ログ改ざん、勤怠打刻トラブル | 10 | 軽減 | ログ監査＋業務再開手順整備 |
会議資料 | 経営層 | 役員会議議事録 | 会議内容の漏えい、経営判断の信頼失墜 | 2 | 受容 | 物理鍵＋持出し制限で対応済み |
もしリスクの洗い出しを、機密性、完全性、可用性で分けて行うパターンでアセスメントをする場合は、以下のようなまとめ方になるでしょう。
情報資産カテゴリ | 媒体・サービス名 | 性質 | リスク内容 | リスク値 | リスク方針 | 対応内容 |
|---|---|---|---|---|---|---|
SaaS製品 | チャットボットエンジン | 機密性 | ユーザー情報の漏えい | 9 | 軽減 | MFA、IP制限導入 |
完全性 | 不正ログインによる改ざん | 8 | 軽減 | ロール分離と監査ログ | ||
可用性 | サービス停止による業務中断 | 8 | 軽減 | SLAと代替手順整備 | ||
問い合わせ管理 | 機密性 | サポートログの漏えい | 8 | 軽減 | 送信制御とログ保管 | |
完全性 | 対応記録の誤記・改ざん | 7 | 軽減 | 定期レビュー | ||
可用性 | システム停止による応答不能 | 7 | 軽減 | 冗長化とBCP整備 | ||
インフラ機器 | 小売店向けレジ端末 | 機密性 | 店舗端末の盗難による情報漏えい | 8 | 移転 | 保険加入 |
完全性 | 誤操作によるPOS誤集計 | 7 | 軽減 | 操作マニュアル整備 | ||
可用性 | 故障による決済停止 | 7 | 移転 | 緊急予備端末を準備 | ||
社内SaaS | 顧客情報管理システム | 機密性 | 顧客情報の漏えい | 8 | 軽減 | 定期棚卸 |
完全性 | アカウント放置による改ざん | 8 | 軽減 | 強制パスワードリセット | ||
可用性 | サービスダウンで営業停止 | 7 | 軽減 | 契約SLA活用 | ||
技術資料 | 設計書 | 機密性 | 設計情報の社外持出 | 9 | 回避 | 開発環境を分離 |
完全性 | 設計改変による不備 | 8 | 軽減 | チェック体制強化 | ||
可用性 | 閲覧不能による業務停止 | 7 | 軽減 | バックアップ強化 | ||
顧客関連 | 顧客アンケートデータ | 機密性 | 個人情報の漏えい | 8 | 軽減 | 匿名化・保存制限 |
完全性 | 不正入力・改ざん | 7 | 軽減 | 編集ログ導入 | ||
可用性 | 集計不可・再収集の負担 | 6 | 受容 | 紙予備の運用 | ||
契約関連 | 取引先との秘密保持契約書 | 機密性 | 契約書の漏えい | 8 | 軽減 | アクセス制御 |
完全性 | 改ざんによる訴訟リスク | 8 | 軽減 | 改ざん検知 | ||
可用性 | 原本紛失による対応不能 | 6 | 受容 | 紙＋電子の二重保管 |
重要なのは、リスク対応方針を決めること自体ではなく、それが実際に実行され、継続的に管理されているかどうかです。たとえば、月1回の情報セキュリティ委員会の定例会議などで進捗状況を定期的に確認し、その都度「最終レビュー日」や「対応状況」を記録しておき、ISMS審査の際などに運用を説明できるようにしておきましょう。
リスクアセスメントというと、「専門用語を用いて何ページにもわたるドキュメントが必要である」とイメージする方もいらっしゃる様子ですが、実際のISMS審査では「実態に即しているか」が最も重視されます。つまり中小企業であっても、
- 情報資産を適切に洗い出していること
- 自社なりの観点でリスクを整理・評価していること
- 評価結果に基づいて、軽減・回避・移転・受容といった何らかのリスク対応方針を独自に定めていること
- これらのリスクを定期的に見直していること
上記を満たしていれば、専門用語を用いて何ページにもわたるドキュメントをまとめたりする必要はありません。
特に中小企業や情報システム部門が限られた体制で取り組む場合は、Excelなどのツールで資産とリスクの一覧を管理したり、カテゴリごとにリスク評価をまとめて効率化する、といった実用的な方法で十分に対応可能です。リスクアセスメントのハードルは思っているほど高くないのです。
今後も皆様の組織のIT体制を強化していくうえで、またISMS認証の取得を目指すうえでも有益となる実践的な情報を継続して発信してまいりますので、ぜひ引き続きご確認いただければ幸いです。
