リスク対策は何から始める?|資産・脅威・弱点と残留リスク
重大な脆弱性から順に修正すれば、自社のリスクも小さくなるのでしょうか。技術的な深刻度が同じでも、外から使える機能か、何のデータに届くか、業務が止まるかで優先度は変わります。被害に至る経路を一つずつ確かめましょう。
事例:顧客情報を外へ持ち出せる経路
C社の営業部は顧客の連絡先と契約情報を共有システムで管理しています。全営業担当が一覧をダウンロードでき、個人の共有サービスへのアップロードも許可されています。担当者の退職時にアカウントを止める手順はありますが、異動後の権限確認はありません。
外部攻撃によるアカウント侵害と、権限を持つ人による不正持出しの両方を検討します。守る対象はシステムだけでなく、顧客情報と、それを使って続ける業務です。
- 1. 広い出力権限
- 2. 送信を制限せず
- 3. 許可外へ渡る
本人の権限を使う不正と、アカウントを侵害する攻撃では、本人確認だけでは止め切れない経路があります。
資産・脅威・脆弱性は、どの順に考える?
- 資産
価値があり、守る対象。顧客データ、サービス、端末、業務を支える人や信頼などを具体化します。
- 脅威
資産に害を及ぼす主体・行為・事象。窃取、誤操作、機器故障などを対象の事例に合わせます。
- 脆弱性
脅威が被害につながる弱点。設定・運用・権限管理の不足も含みます。
- 影響
漏えい、改変、停止などで失うもの。機密性・完全性・可用性と業務上の損失を対応付けます。
事例では、顧客データが資産、不正持出しが脅威、過大な出力権限と持出し経路の管理不足が弱点です。『情報漏えいが弱点』と書くと、被害と原因が混ざり、どこへ対策を置くかが分からなくなります。
機密性は許可されない閲覧を防ぐこと、完全性は不正な変更から守ること、可用性は必要なときに使えることです。漏えい対策で業務を止める場合もあるので、三つの目標と業務の制約を一緒に確認します。
リスクの大きさは、何を根拠に比べる?
リスク評価では、事象が起きる可能性と、起きたときの影響を扱います。外部からの到達性、必要な権限、既存の管理策、実際の攻撃状況、対象件数、復旧や業務停止の影響などを根拠にします。
対象 | 可能性に関する条件 | 影響に関する条件 |
|---|---|---|
公開機能の弱点 | 外部から認証なしで利用可能 | 顧客情報へ到達できる |
内部だけの機能 | 管理経路と権限に制限がある | 停止時に重要業務が止まる |
退職・異動後の権限 | 利用可能なアカウントが残る | 広い範囲を出力できる |
表だけで内部機能を低リスクと確定できません。侵害された社内端末や管理者が利用する経路も確認します。不明な条件は調査項目にし、証拠のない『社内なので安全』という評価を避けます。
高・中・低などの尺度を使う場合は、各段階の意味を先に決めます。順序を表す点数を掛け算しても、客観的な損失額や確率が得られるわけではありません。同じ基準で比較できるか、根拠が残っているかを重視します。
CVSSは技術的な深刻度を示す材料です。自社の資産価値や業務影響、利用条件を別に確認します。評価方法を変えた前後の値も、尺度や条件が違えばそのまま比較できません。
回避・低減・移転・受容は、どう使い分ける?
対応 | 事例での候補 | 確認すること |
|---|---|---|
回避 | 不要な一括出力機能を廃止 | 業務を別の方法で成立させられるか |
低減 | 出力権限を限定し、持出し経路を制御 | 成立しにくさと影響がどこまで変わるか |
移転・共有 | 契約や保険等で損失の一部を分担 | 対象・免責・自社に残る義務 |
受容 | 残る危険を責任者が把握して承認 | 根拠・期限・見直し条件 |
移転しても、漏えい自体が起きなくなるわけではありません。委託先へ任せる場合も、アクセス権、監督、連絡と復旧の役割を決めます。受容は何もしないことではなく、残る危険と承認を記録した判断です。
事例では、全員に一括出力を許す必要があるかを最初に確かめます。必要な担当者だけへ権限を限定し、承認された共有経路を用意します。単に持出しを禁止すると、業務上の送付が個人サービスへ移る可能性もあるため、使える代替手段を整えます。
技術・人的・組織的対策を、同じ経路へ置く
技術的対策は認証、権限制御、送信先制限、検知などです。人的対策は教育や訓練、組織的対策は責任者、承認、棚卸し、報告手順などです。分類名を列挙するだけでなく、どの弱点へ何を適用するかを説明します。
教育だけに依存せず、権限と経路の制御、監視と対応を組み合わせます。どの組合せでも危険がゼロになるとは限りません。
DLPはデータの持出しを検知・制御する仕組みですが、すべての暗号化通信や画面撮影を必ず止められるとは限りません。対象経路、検知条件、例外、誤検知の扱いを確認し、製品で実際にできることに合わせます。
大量出力の検知にも、件数や時間帯だけでなく正規の作業との区別が必要です。通知先と確認者を決め、営業繁忙期の通常業務で過剰に止めないか、不正の少量持出しを見逃すかを試します。
残留リスクを、どう記録して見直す?
残留リスクは管理策を適用した後にも残る危険です。権限者の不正、許可された経路の悪用、検知から対応までの遅れなどを、対策後の条件で考え直します。対策前の評価をそのまま残して完了にしません。
記録項目 | 記載例 |
|---|---|
対象と経路 | 権限者が顧客一覧を外部へ出力する |
対策と担当 | 権限限定はシステム担当、棚卸しは営業責任者 |
検証 | 許可・拒否・通知の試験結果を確認 |
残る危険 | 正規の権限者による許可経路の悪用 |
承認と見直し | 責任者・期限・変更時の再評価条件 |
アカウント数や扱うデータが増えた、委託先が変わった、新しい脅威が確認されたなど、評価の前提が変われば見直します。教育の受講率や規則の設定数は活動の指標で、漏えいリスクが減ったことの直接の証明ではありません。
答案では『情報漏えいを防ぐ』だけで終わらず、『一括出力を担当者へ限定し、不要な権限による持出しの可能性を下げる』のように、対象・対策・効果をつなぎます。残る条件も一言添えると、対策の限界が明確になります。
演習1:原因と被害
条件:異動後も顧客一覧の出力権限が残り、不要な持出しが可能である。
問い:脆弱性に相当する管理上の弱点を答える。
解答例:異動時に不要になった出力権限を見直して削除する手順がないこと。
根拠:被害につながる権限管理の不足が原因である。
誤答の理由:『顧客情報が漏えいすること』は結果であり、修正すべき弱点を示していない。
演習2:社内機能の評価
条件:機能は外部非公開だが、侵害された社内端末から利用できるか未確認である。
問い:リスクが低いと確定してよいか。
解答例:確定できない。社内端末等からの到達条件と利用権限を追加調査する。
根拠:外部非公開という一条件だけでは、別の成立経路を除外できない。
誤答の理由:『インターネットから見えないので安全』は脅威の範囲を狭め過ぎている。
演習3:リスクの移転
条件:漏えいに伴う費用の一部を保険で補う契約を結んだ。
問い:持出しの可能性もなくなるか。
解答例:なくならない。補償条件と自社に残る危険を確認し、予防策も続ける。
根拠:損失の分担と事象の発生防止は別である。
誤答の理由:『保険があるので権限制御は不要』は残留リスクを見落としている。
演習4:教育の限界
条件:取扱い教育を実施したが、全員が顧客一覧を出力できる設定は変えていない。
問い:教育に加える対策を一つ答える。
解答例:職務に必要な担当者へ一括出力権限を限定する。
根拠:事例の成立条件である過大な権限へ直接働きかける。
誤答の理由:『もう一度注意する』だけでは同じ技術的な許可が残る。
演習5:受容の条件
条件:対策後も許可された送付経路の悪用が残る。
問い:残る危険を受容するときに記録することを答える。
解答例:残る危険の内容と根拠、責任者の承認、期限や見直し条件。
根拠:受容は危険を把握したうえで行う責任ある判断である。
誤答の理由:『予算がないので放置する』だけでは承認や再評価の条件がない。
演習6:効果の検証
条件:DLPの導入台数は計画どおりだが、対象の共有サービスへの送信試験はしていない。
問い:リスク低減を確認するために必要な検証は何か。
解答例:対象経路で許可・拒否と検知・通知の動作を試し、残る抜け道を確認する。
根拠:導入数は活動量で、実際の成立経路が制御されたことを示さない。
誤答の理由:『台数がそろったので完了』は管理策の実効性を確認していない。
出典と仕様を確認する
NIST SP 800-30 Rev.1:リスクアセスメント
NIST SP 800-39:組織の情報セキュリティリスク管理
関連テーマを続けて学ぶ
次におすすめの学習
編集・検証について
編集・検証:IT資格ラボ編集部
IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。
編集方針・情報源・訂正方針を見る