こんにちは！IT担当者として日々のシステム管理や開発に奮闘されている皆さん、お疲れ様です。セキュリティの世界へようこそ！
新しいシステムを作ったり、サーバーを運用したりしていると、セキュリティ診断ツールから「おっと、ここ危ないですよ！」と真っ赤な警告が届くことってありますよね。「CVSSスコア：9.8（緊急）」なんて書かれていようものなら、心臓がキュッと縮み上がる思いをするインフラ担当者や開発者の方も多いはずです。
でも、ちょっと待ってください。その「高いスコア」だけを見て、パニックになって全ての作業を放り出していませんか？
今回は、現場の泥臭いインシデント対応の知見も交えながら、「CVSSスコアの本当の見方」と、自分たちのシステムにとって本当に守るべきものは何かを見極める「リスクベースの優先順位付け」について、身近な防犯の例えを交えながら優しく紐解いていきたいと思います。一歩ずつ、一緒に学んでいきましょうね！
—
1. 家の鍵に例えて考える「CVSSスコア」の正体
まずは、セキュリティの世界でよく耳にする「CVSS（Common Vulnerability Scoring System）」という言葉から整理していきましょう。
CVSSは、一言で言うと「見つかった脆弱性（セキュリティの穴）の重症度を測る、世界共通の物差し」です。スコアは0.0から10.0まであり、数字が大きければ大きいほど「ヤバい穴」ということになります。
ここで、身近な「お家の防犯」に例えてみましょう。
- 脆弱性（セキュリティの穴）の例： 「玄関の鍵の構造に、ピッキングされやすい欠陥が見つかった」とニュースで報道されたとします。
このニュースを聞いたとき、あなたはどう感じますか？「うわ、うちの鍵も同じメーカーだ！一大事だ！」と思いますよね。セキュリティ診断ツールが教えてくれるCVSSスコアとは、まさにこの「鍵そのものの壊されやすさ」を全国一律で評価したものです。
しかし、ちょっと冷静になって考えてみてください。その「ピッキングされやすい鍵」が使われている場所は、どこでしょうか？
- パターンA： 都心のタワーマンションの、オートロックを抜けた先にある20階の部屋の玄関ドア。
- パターンB： 誰でも昼夜問わず自由に出入りできる、人通りの少ない路地裏の物置小屋の扉。
どうでしょう？ パターンAもパターンBも「同じ壊されやすい鍵（＝同じCVSSスコア）」がついていますが、泥棒にとってどちらが魅力的で、被害が大きそうでしょうか？ もちろん、資産がたくさんありそうなパターンAですよね。でも、パターンBはそもそも中身が空っぽの古雑誌置き場かもしれません。
このように、「脆弱性自体の深刻さ（CVSS）」だけを見てパッチ（修正プログラム）を当てまくるのは、「全ての家を同時に、しかも同じ予算と労力で要塞化しようとする」ようなものです。限られた時間とリソースの中で戦う私たちIT担当者には、無理がありますよね。
—
2. 資産の重要度を加味した「ビジネスインパクト」の評価
そこで重要になってくるのが、「自社のビジネスにおいて、そのシステムやデータがどれほど重要か（ビジネスインパクト）」を掛け合わせて優先順位を決めるというアプローチです。
現場のセキュリティリスクは、以下の公式で考えると非常に分かりやすくなります。
> リスクの大きさ ＝ 脆弱性の深刻さ（CVSS） × 攻撃のしやすさ × 資産の重要度（ビジネスインパクト）
どれだけCVSSのスコアが高くても、その脆弱性があるサーバーが「社内の誰も使っていない、捨てデータのテスト環境」であれば、優先順位は一番下に下げて良いはずです。逆に、CVSSが「中（5.0前後）」であっても、「クレジットカード情報を何万件も保持している決済基盤のAPIサーバー」にあったとしたら？ これはもう、今すぐ夜間作業をしてでも直さなければならない最優先事項になります。
現場のエンジニアとしてお伝えしたいのは、「ツールが出したスコアをうのみにして疲弊するな、自社のビジネス文脈でリスクを再定義しろ」ということです。
—
3. 実務での優先順位付け：トリアージの現場から
では、具体的にどうやって優先順位を決めればよいのでしょうか。インフラの構築やWebアプリケーションの開発現場では、次のようなステップでトリアージ（仕分け）を行います。
1. インベントリ（資産台帳）の確認： その脆弱性があるサーバーやプログラムは、インターネットに直接面しているか？（外部公開されているか）
2. データの機密性・完全性の確認： そこには個人情報や機密データがあるか？ 壊れたら業務が止まるか？
3. 攻撃コード（PoC）の有無： 実際にインターネット上でその脆弱性を悪用するプログラムが出回っているか？
特に3つ目の「実際に悪用されているか」は極めて重要です。いくら理論上危険な穴であっても、宇宙人を探すような複雑な手順を踏まないと攻撃できないものであれば、今すぐ会社が倒産するような脅威にはなりません。
—
4. 防御の実装例：WAFやセキュリティヘッダーで「時間を買う」
とはいえ、「脆弱性はあるけれど、システムの仕様上、すぐにパッチを当てて再起動することができない！」というジレンマに直面することも、開発現場では日常茶飯事ですよね。
そんなとき、パッチ当て（根本治療）が完了するまでの「応急処置（絆創膏）」として、Webアプリケーション側やインフラ側で防御を固めるテクニックがあります。いわば、鍵が壊れているなら、とりあえず頑丈なチェーンを内側からかけるようなアプローチです。
ここでは、Webアプリケーションでよく使われるHTTPセキュリティヘッダーの設定例をいくつか見てみましょう。これらは、ブラウザに対して「変な攻撃からユーザーを守ってね！」と指示を出すおまじないのようなものです。
ApacheやNginxなどのWebサーバー、あるいはアプリケーションの設定ファイルで次のように記述します。
PHPアプリケーションでのセキュリティヘッダー付与例
<?php
/**
* セキュリティヘッダーの送信
* 脆弱性に対する一時的な緩和策（パッチ適用までの時間稼ぎ）として機能します。
*/
// 1. クリックジャッキング攻撃を防ぐヘッダー
// 自社サイトが他の悪意あるサイトの<iframe>内に勝手に表示されるのを防ぎます。
header("X-Frame-Options: SAMEORIGIN");
// 2. クロスサイトスクリプティング（XSS）対策のヘッダー
// ブラウザ側の簡易的なXSSフィルターを有効化します。
header("X-XSS-Protection: 1; mode=block");
// 3. コンテンツセキュリティポリシー（CSP）の基本設定
// 信頼できるソースからのみスクリプトの読み込みを許可し、不正なコードの実行をブロックします。
header("Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com;");
echo "セキュリティヘッダーが正常に設定されました。";
?>こうしたヘッダーを適切に設定しておくことで、たとえアプリケーションの一部に古いライブラリ（脆弱性のあるパーツ）が残っていたとしても、ブラウザが不正なコードの実行を水際でブロックしてくれる確率をグッと上げることができます。
—
一歩ずつ、確実な対策を進めていきましょう
セキュリティの脅威は次から次へとやってきます。ニュースを見ると「また新しい深刻な脆弱性が見つかった！」と焦る気持ちになりますよね。
でも、安心してください。全ての攻撃を完璧に防ぐことは、どんな大企業であっても不可能です。大切なのは、「自分たちが守るべき一番大切な宝物（データやシステム）は何か」を正しく把握し、リスクの大きさに応じて優先順位をつけて対処していくことです。
今日からできることとして、まずは自社のシステムやサーバーが「どこにあり、何を守っているのか」の棚卸しから始めてみませんか？
焦らず、一歩ずつ、確実なセキュリティ対策を積み重ねていきましょう！応援しています！
コメント