0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

PR: アディクシィ株式会社
ADiXiのコーポレートサイト

リスクベースとは何か──「全部守る」から「重要なものを優先して守る」へ

0
Last updated at Posted at 2026-08-06

Gemini_Generated_Image_x875ozx875ozx875.png

はじめに

「全部ちゃんと対策しています」

セキュリティの現場では、一見すると正しそうに見えるこの言葉が、逆に危険な場合があります。

なぜなら、現実には「すべてを同じ強度で守る」のは不可能だからです。

  • 予算には限界がある。
  • 人手も足りない。
  • システムは増え続ける。
  • 攻撃手法も日々変化する。

そのため、近年のセキュリティでは「重要なリスクから優先して対処する」という考え方が重視されています。

それが「リスクベース(Risk-Based)」です。

本稿では、情報セキュリティで頻繁に使われる「リスクベース」という考え方について、初心者向けに整理します。


1. リスクベースとは何か

リスクベースとは、簡単に言えば、

「危険度に応じて、対策の優先順位を決める」

という考え方です。

たとえば、次の2つのシステムがあったとします。

システム 停止時の影響
社内掲示板 一時停止しても業務影響は軽微
決済システム 停止すると売上が止まる

この場合、両方に同じコスト・同じ強度で対策するのは合理的ではありません。

当然、決済システムの方を優先して守るべきです。

これがリスクベースの基本思想です。

AWSも、リスクベースアプローチを「リスクを評価し、そのリスクに応じてリスクを最小化する取り組み」と説明しています。 (Amazon Web Services, Inc.)


2. なぜ「リスクベース」が重要になったのか

昔のセキュリティは、どちらかというと「チェックリスト型」でした。

  • FWを入れる。
  • ウイルス対策を入れる。
  • パスワードを複雑化する。

こうした「決められた対策を全部やる」発想です。

もちろん、これは今でも重要です。

しかし、クラウド化やAI利用、リモートワーク拡大によって、IT環境は極端に複雑化しました。

すると問題が起きます。

「全部やる」が現実的ではなくなった

例えば、

  • 数千台の端末。
  • SaaS乱立。
  • 委託先管理。
  • 海外拠点。
  • シャドーIT。
  • AI利用。

これらをすべて均一に管理するのは困難です。

そこで現在は、

「どこが一番危ないか」
「どこが止まると事業インパクトが大きいか」

を先に考えるようになりました。

Trend Microも、「均一的な対策から、リスク評価にもとづく対策への転換」が必要だと説明しています。 (www.trendmicro.com)


3. リスクベースで見ると、対策はどう変わるのか

ここが実務上、とても重要です。

リスクベースでは、単純に「脆弱性があるか」だけでは判断しません。

例:CVSSが高い脆弱性でも後回しになる

例えば、

項目 内容
CVSS 9.8
対象サーバ 検証環境
外部公開 なし
機密情報 なし

この場合、技術的には危険でも、事業リスクは低い可能性があります。

逆に、

項目 内容
CVSS 5.0
対象 インターネット公開
対象データ 顧客個人情報
代替手段 なし

こちらは優先度が高くなる場合があります。

つまり、リスクベースでは、

  • 「脆弱性の深刻度」
  • 「攻撃されやすさ」
  • 「事業影響」
  • 「復旧難易度」
  • 「法規制影響」

などを総合的に見ます。


4. NISTやISOでも「リスクベース」が前提

現在の主要なセキュリティフレームワークでは、ほぼ共通してリスクベース思想が採用されています。

NIST CSF

National Institute of Standards and Technology のNIST CSFでは、組織のリスク許容度や優先順位に応じて対策を決める考え方が示されています。 (ウィキペディア)

特にCSF 2.0では「Govern(統治)」機能が追加され、

  • リスク許容度
  • 経営判断
  • 優先順位

がより重視されるようになりました。 (ウィキペディア)

RMF(Risk Management Framework)

NIST RMFでも、

  1. リスク評価
  2. システム分類
  3. 管理策選択

という流れで、リスクを基準にセキュリティ対策を選択します。 (インテリリンク)

つまり、

「何を守るか」
「どこまで守るか」

を、経営や事業と紐づけて決める時代になっているのです。


5. リスクベースの誤解

リスクベースは、よく誤解されます。

誤解1:「危険を放置していい」

違います。

リスクベースは「無視する」ではなく、

「限られたリソースを最適配分する」

考え方です。

誤解2:「コスト削減の言い訳」

これも危険です。

本来のリスクベースは、

  • リスク評価
  • 根拠
  • 受容判断
  • 承認

が必要です。

「面倒だからやらない」はリスクベースではありません。

誤解3:「セキュリティ部門だけの話」

実際には、経営判断です。

なぜなら、

  • どのサービスを優先するか
  • どこまで投資するか
  • どのリスクを許容するか

は、事業戦略そのものだからです。


6. AI時代はさらに「リスクベース」が重要になる

生成AIの普及で、この考え方はさらに重要になります。

例えば、

  • 社外秘データをAIへ入力するリスク。
  • AI生成コードの脆弱性。
  • 誤回答による業務事故。
  • シャドーAI利用。

これらは、全部を禁止しても業務が止まります。

逆に、全部自由にしても事故が起きます。

つまり必要なのは、

「どのAI利用が危険か」
「どこまで許容するか」

を判断することです。

実際、NIST AI RMFでも、リスクベースのAIガバナンスが重視されています。 (arXiv)


おわりに

リスクベースとは、単なるセキュリティ用語ではありません。

これは、

「限られたリソースで、何を優先するか」

という経営判断の考え方です。

そして現代のセキュリティは、

  • 「全部守る」
  • 「全部禁止する」

では成立しません。

だからこそ、

  • 何が危険か。
  • どこまで許容するか。
  • どこへ投資するか。

を、継続的に見直す必要があります。

セキュリティは、技術だけではなく「優先順位を決める活動」でもあるのです。


参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?