脆弱性

Vulnerability

security bug beginner

不正アクセスや情報漏えいなどに悪用される、ソフトウェアやシステムの弱点。

概要（サマリー）

脆弱性とは、不正アクセスや情報漏えいなどに悪用される、ソフトウェアやシステムの弱点である。
家に例えるなら、外から開けられてしまう窓や、鍵の仕組みにある欠陥のようなものだ。
普段は正常に動いて見えるソフトにも、特定の操作で悪用できる弱点が隠れている場合がある。

脆弱性は「ぜいじゃくせい」と読む。
「脆弱」は、もろくて弱いことを意味する。

ITでは、情報の秘密を守れなくなったり、データを書き換えられたりする原因となる弱点を指す。
サービスを正常に使えなくされる原因も含まれる。

英語では Vulnerability と呼ぶ。
更新案内に「脆弱性を修正」と書かれていたら、見た目や使い勝手以外の安全性に関わる変更だと理解するとよい。

バグは、プログラムの不具合を広く指す。
たとえば、画面の文字が少しずれる不具合が、そのまま不正アクセスにつながるとは限らない。

一方、他人のデータを読めてしまう不具合は、安全性を損なう弱点となる。
このように、バグのうちセキュリティへ影響するものが脆弱性になる場合がある。

設計や設定の不備が原因になることもある。
たとえば、初期パスワードのまま機器をインターネットへ公開している状態も、攻撃に使われる弱点になる。
コードの誤りだけを探せばよいわけではない。

脆弱性は「弱点」であり、攻撃はその弱点を使う「行為」である。
窓の鍵が壊れている状態と、そこから侵入する行為を区別するイメージだ。
修正が提供される前に、その弱点が悪用される攻撃をゼロデイ攻撃と呼ぶ。

たとえば、入力の扱いに問題があると、SQLインジェクションでデータを盗まれるおそれがある。
画面への出力の扱いに問題があると、XSSにつながる場合がある。

脆弱性があるという情報だけで、すでに侵入されたと断定はできない。
ただし、被害が確認されていなくても、悪用される前に対応する必要がある。

更新が必要なのは、普段使うアプリ本体だけではない。
OS、ブラウザ、ネットワーク機器なども対象となる。

Webサイトなら、CMS本体やプラグイン、利用するライブラリにも注意する。
一部だけを更新しても、ほかの部品に弱点が残る場合がある。

メーカーの案内では、対象の製品名とバージョンを確認する。
同じ製品でも、利用している版や設定によって影響が異なるためだ。

脆弱性には、CVEという仕組みの識別番号が付くことがある。
同じ問題について、メーカーと公的機関の案内を照合する目印になる。

CVSSなどの数値は、技術的な深刻度を判断する材料となる。
ただし、その数値だけで自分の環境での対応順が決まるわけではない。

実際に攻撃へ使われているか、外部から届く場所にあるか、何の情報を扱うかも関係する。
番号や数値を覚えるより、対象製品と必要な対応を確認することが先である。

基本となる対策は、メーカーが提供する修正版の適用である。
更新後は、必要な再起動や設定変更が完了したかも確認する。

修正版がない場合などには、機能の停止や外部接続の制限が案内されることがある。
これは危険を下げるための回避策であり、弱点そのものを直す修正とは区別する。

公開範囲を狭め、権限を必要最小限にすることも被害の軽減につながる。
ただし、別の対策を入れたことだけを理由に、必要な修正を放置しない。

AIが作ったコードも、人が作ったコードと同様に脆弱性を含む可能性がある。
動作確認に加え、「ほかの利用者の情報を読めないか」「権限を超えて操作できないか」を確認する必要がある。

AIには「入力の扱いと権限チェックについて、問題となる条件と修正案を示して」と依頼できる。
指摘は実際のコードや公式情報と照合し、AIが「安全」と答えたことを検証の代わりにしない。

通常の操作では表面化しない弱点もある。
正常に動くことと、安全であることは別に確認する必要がある。

影響する製品やバージョン、悪用の条件によって異なる。
まず自分の利用環境が対象かを確認し、必要な対策を行う。

修正は、その弱点を今後悪用される危険を減らすためのものだ。
すでに侵入された疑いがある場合は、調査や認証情報の変更なども必要になる。