脆弱性診断の始め方｜種類・手順から AWS での実践方法まで解説
「脆弱性診断はやらなければと思っているが、何から始めればいいかわからない」という相談をよく受けます。脆弱性診断とペネトレーションテストの違いがわからない、種類が多くて自社のシステムにどの診断が必要か判断できない、 AWS を使っているがクラウド環境での脆弱性診断のやり方がわからないといった課題を持つ方に向け、脆弱性診断の基本概念から種類や手順、 AWS 環境での実践方法を具体的に解説します。
脆弱性診断とは 基本概念の整理
脆弱性診断という言葉は広く使われているものの、その定義や関連用語の違いがあいまいなまま使われていることも少なくありません。脆弱性とは何かという根本から整理し、診断の目的や類似概念との違いを明確にします。
脆弱性とは何か
脆弱性とは、コンピュータシステムやソフトウェア、ネットワーク設定に潜むセキュリティ上の弱点のことです。設計上の欠陥、実装ミス、設定の不備など、さまざまな原因で生じます。
脆弱性は大きく2種類あります。ひとつは既知の脆弱性で、セキュリティ研究者や機関がすでに発見し公開している弱点です。共通脆弱性識別子 CVE という識別番号が付与され、世界共通のデータベースで管理されています。 CVE データベースには毎年多数の新しい脆弱性が登録されるため、利用しているソフトウェアに最新のセキュリティパッチを継続的に適用する必要があります。
もうひとつは設定ミスや実装上の問題です。セキュリティグループのアクセス制御が緩すぎる、 API キーが公開されたまま、パスワードがデフォルトのままといった問題は、 CVE データベースには登録されません。しかし攻撃者に悪用されると大きな被害につながるため見逃せないリスクです。
脆弱性の深刻度を評価する指標として、共通脆弱性評価システム CVSS が国際的に広く使われています。0.0から10.0の数値で表され、7.0以上が高、9.0以上が緊急とされています。この指標は、脆弱性が実際に悪用された場合の影響度と、悪用される難易度を組み合わせて算出されます。
脆弱性の怖さは、攻撃者がそれを悪用できる状態にある間ずっとリスクが続く点にあります。新しい脆弱性が公開されると短期間のうちに攻撃ツールが出回り、パッチを当てていないシステムが標的になります。自社のシステムにどのような脆弱性が存在するかを定期的に確認し、迅速に対応できる体制を整えることが重要です。
脆弱性診断の定義と目的
脆弱性診断とは、情報システムや Web アプリケーション、ネットワーク、クラウド環境などに潜むセキュリティ上の弱点を体系的に洗い出し、その深刻度を評価するプロセスです。セキュリティ診断や脆弱性スキャンとも呼ばれます。
診断の目的は3つあります。
1つ目はリスクの可視化です。どのシステムにどのような脆弱性があり、どの程度危険かを明らかにします。問題を把握しなければ対処できないため現状を知ることが最初のステップです。
2つ目は被害の未然防止です。発見した脆弱性に優先度をつけて修正することで、不正アクセスや情報漏洩、サービス停止を事前に防ぎます。
3つ目は継続的なセキュリティ水準の維持です。システムは変化し続け、新しいソフトウェアや機能が追加されるたびに新たな脆弱性が混入する可能性があります。定期的な診断を繰り返すことでセキュリティレベルを保ちます。
脆弱性診断は診断して終わりではなく、診断から評価、修正、再確認という継続的なサイクルを回し続けることに本来の価値があります。インターネットに公開されている Web サービスや API エンドポイント、個人情報を扱うデータベース、基幹業務システムなど、優先度の高いシステムから順番に診断を進めます。
脆弱性診断とペネトレーションテストやセキュリティ監査の違い
セキュリティ関連の取り組みには似た言葉があり混同されやすいため、脆弱性診断、ペネトレーションテスト、セキュリティ監査の違いを整理します。
脆弱性診断はシステム全体の健康診断に該当します。対象システムに存在する既知の脆弱性を網羅的に洗い出すことを目的とし、ツールを使った自動スキャンと専門家による手動確認を組み合わせて実施します。発見された脆弱性の一覧とそれぞれの深刻度を報告します。
ペネトレーションテストは実際の攻撃シミュレーションです。実際のサイバー攻撃者と同じ手口でシステムへの侵入を試み、どこまで攻撃が成功するかを検証します。特定の攻撃シナリオを追って深く掘り下げるため調査範囲は限定的ですが、実際の侵害リスクをより現実的に把握できます。費用は脆弱性診断と比べて高く、セキュリティ専門家が手動で実施します。
セキュリティ監査は組織が定めたセキュリティポリシーや、 ISO 27001 や PCI DSS などの外部規格への適合状況を評価する取り組みです。技術的な診断だけでなく、運用プロセスや組織体制、ドキュメント管理なども評価対象となります。
まず定期的な脆弱性診断で網羅的な弱点を把握し、重要なシステムや高リスクな環境ではペネトレーションテストで深掘りする組み合わせが効果的です。
脆弱性診断が必要とされる背景
背景にある具体的な脅威や法的要求、環境変化を理解しておくことで、社内での優先度付けや投資判断が明確になります。
サイバー攻撃リスクの拡大
企業を狙ったサイバー攻撃は増加し高度化を続けています。攻撃者がシステムに侵入する際、最初に行なうのは脆弱な箇所がないかを自動スキャンする偵察活動です。インターネットに公開されているシステムは常に世界中からの探索リクエストにさらされています。
脆弱性が悪用されると、個人情報や機密情報の流出による信頼失墜や法的賠償、ランサムウェアによる業務停止など多様な被害が発生します。攻撃者にとって脆弱性の悪用は低コストで効率的な手段であり、パッチ適用が遅れているシステムは格好の標的になります。脆弱性診断は、攻撃者が悪用できる入り口を事前に塞ぐ予防的な役割を果たします。
コンプライアンスと法的要件
脆弱性診断の実施は個人情報保護や業界規制への対応としても求められます。
個人情報保護法では、個人情報を取り扱う事業者に対して情報の漏洩や滅失を防ぐための安全管理措置の実施が義務付けられており、技術的安全管理措置の一環として定期的なセキュリティ診断が求められます。
クレジットカード業界のデータセキュリティ基準である PCI DSS では、四半期ごとの外部脆弱性スキャンと定期的なペネトレーションテストの実施が要件として含まれています。
情報セキュリティマネジメントシステム ISMS や ISO 27001などの国際標準規格でも、リスクアセスメントとして脆弱性の特定や評価が要件に含まれています。
コンプライアンス対応では実施した事実と結果を記録し、いつどの範囲で診断を実施し、どのような脆弱性を修正したかを証跡として示せる状態を維持することが求められます。
クラウドやリモートワーク時代の新たなリスク
クラウドサービスの普及とリモートワークの定着により、企業の IT 環境は大きく変化しました。
クラウド環境の設定ミスは現代のセキュリティインシデントの主要な原因の一つです。管理コンソールから容易に設定を変更できる反面、誤った設定が即座に本番環境に反映され、 Amazon S3 バケットのアクセス制御ミスなどで意図せずデータが外部に公開される事態が起きやすくなっています。
リモートワークの導入により VPN や認証基盤がサイバー攻撃の標的になり、クラウドサービスの利用増加に伴ってインターネットに公開される API エンドポイントも増加し、攻撃対象領域が拡大しています。また、オープンソースライブラリに脆弱性が含まれていると自社のアプリケーションも影響を受けるソフトウェアサプライチェーンのリスクも高まっています。
脆弱性診断の主な種類
脆弱性診断は診断対象のシステム種別によって分類され、診断の観点や使用するツールが異なります。
Web アプリケーション診断と AI アプリの保護
Web サイトや社内 Web システム、 SaaS アプリケーションなど、ブラウザを通じて利用するシステムを対象とした診断です。顧客向けの Web サービスや API エンドポイントは攻撃者に狙われやすい入り口の一つです。
Web セキュリティの業界標準ガイドラインである OWASP Top 10 を基準として検査します。データベースを不正操作する SQL インジェクション、悪意のあるスクリプトをブラウザ上で実行させるクロスサイトスクリプティング、パスワードの総当たり攻撃を許す認証の不備、 URL パラメータの改ざんによるアクセス制御の不備などを確認します。
また、近年は生成 AI を組み込んだアプリケーションの診断も重要です。 AI は必ずしも正解を教えるものではなく、AI が（特定のソースに基づき）回答を生成・提示する特性を持つため、プロンプトインジェクションなどの特有の脅威が存在します。 RAG（検索拡張生成）などの仕組みでハルシネーションを抑制しつつ、 AI の出力品質を定量的・継続的に評価し、安全性を担保することが求められます。
参照：OWASP Top 10
プラットフォーム診断
ネットワーク機器やサーバー、 OS 、ミドルウェアなど、システムの基盤となる IT インフラを対象としたインフラ診断です。
ポートスキャンによって対象ホストで公開されているネットワークポートと動作しているサービスを確認し、不要なポートの開放を発見します。また、稼働している OS やミドルウェアのバージョンを特定し既知の脆弱性と照合します。デフォルトのパスワードが変更されていない、ファイルへのアクセス権が過剰に設定されているといった設定の不備も検出します。
新しいシステムの稼働前や大規模な設定変更後などに実施することで、潜在的なリスクを事前につぶすことができます。
クラウド環境診断
AWS や Google Cloud などのパブリッククラウド上に構築されたインフラやサービスの設定を対象としたクラウドセキュリティ態勢管理 CSPM と呼ばれる診断です。
クラウド環境の脆弱性のほとんどは設定ミスに起因します。 Amazon S3 バケットなどが意図せずパブリックアクセス可能になっているストレージの公開設定ミスや、 IAM による過剰な権限設定、セキュリティグループの過剰な許可設定などを評価します。
インフラが常に変化するクラウド環境では、スポット的な診断よりもセキュリティサービスを活用した継続的な設定監視が効果的です。
ソースコード診断
アプリケーションの開発段階でソースコードや実行ファイルを対象に脆弱性を検出する診断手法です。
静的解析 SAST はアプリケーションを実行せずにソースコードやバイナリを解析し、開発の早い段階から実施できます。動態解析 DAST は実際に動作しているアプリケーションに外部から疑似的な攻撃リクエストを送り込み、レスポンスから脆弱性を検出します。対話型解析 IAST はアプリケーションの実行環境内にエージェントを組み込み、内部処理を監視しながら脆弱性を検出します。
脆弱性診断の流れ
脆弱性診断を確実に機能させ、運用負荷を抑えるためには、スモールスタートから徐々に範囲を広げる段階的なアプローチが有効です。
Phase1 小規模テスト（PoC）から始める
まずは自社で稼働しているシステムを棚卸しし、対象範囲を絞って診断を開始します。 AWS 環境では AWS Config や AWS Systems Manager を活用してリソースを一覧化します。
インターネットから直接アクセスできるシステムや機密情報を扱うシステムの中から、影響範囲の小さい環境を選定します。そこで Amazon Inspector などの自動スキャンツールを稼働させ、どのような脆弱性が検出され、どのような運用フローが必要になるかの検証を行ないます。
Phase2 効果検証とインフラ設計の最適化
小規模テストで検出された脆弱性の深刻度を CVSS スコアなどで評価し、対応の優先順位を策定します。修正作業（パッチ適用・設定変更・WAF ルール追加等）の標準フローを確立し、対応完了までのリードタイムを計測して改善に活かします。
Phase3 本格展開と継続的な診断体制の確立
運用ルールが固まった後、診断対象を本番環境全体に拡大します。
システムの変更時やリリース時だけでなく、継続的な自動スキャン体制を組織内に定着させます。また、脆弱性が突かれてインシデントが発生した場合に備え、インシデント対応手順（検知・初動対応・影響範囲の特定・復旧・再発防止）を事前に整備しておくことが重要です。
修正後は必ず再診断を実施して問題が解消されたことをドキュメントとして記録し、コンプライアンス対応の証跡としても活用します。
AWS を活用した脆弱性診断
AWS 環境では、脆弱性診断と継続的なセキュリティ管理を支援するマネージドサービスが充実しています。
診断結果の保護とアクセス制御
大前提として、脆弱性診断の結果は攻撃者にとってシステムの弱点を記した「設計図」になり得る機密性の高い情報です。これらを扱う管理環境には、仮想デスクトップ（VDI）を導入し端末へのローカル保存を禁止するといったデータ持ち出し防止策を徹底してください。
さらに、診断結果へのアクセスは IAM ポリシーで最小権限に制限し、保管先の S3 バケットには暗号化とアクセスログの記録を有効にするなど、適切なアクセス制御を実施してください。
Amazon Inspector による継続的な脆弱性管理
Amazon Inspector は継続的な脆弱性管理サービスです。有効化するだけで対象リソースに対して自動的にスキャンが始まり、脆弱性を継続的に検出します。
Amazon EC2 インスタンス上で動作するソフトウェアパッケージや、 Amazon ECR のコンテナイメージ、 AWS Lambda 関数の依存ライブラリに既知の脆弱性がないかを確認します。コンソールでは発見された脆弱性の一覧やリスクスコア、推奨される修正アクションを確認できます。
AWS Security Hub と AWS WAF の活用
複数のサービスを組み合わせることで包括的なセキュリティ管理体制を構築します。
AWS Security Hub は、 Amazon Inspector や Amazon GuardDuty などの検出結果を集約し、 AWS アカウント全体のセキュリティ状態を一元的に管理および可視化します。
AWS WAF は Web アプリケーションへの悪意のあるアクセスをリアルタイムに検知してブロックします。脆弱性診断で発見された問題の根本的な修正が完了するまでの間、 WAF のルールで攻撃をブロックすることでリスクを暫定的に低減できます。
参照：AWS WAF の料金
参照：Amazon GuardDuty の料金
cloudpack によるセキュリティ支援
cloudpack では AWS 環境における脆弱性診断やセキュリティ体制の整備に関する支援を提供しています。 Amazon Inspector や AWS Security Hub の活用支援、設定レビュー、継続的な監視体制の構築サポートを行なっており、クラウド環境に適したセキュリティ管理の仕組みを整えることができます。
詳細は公式サイトをご参照ください。
最後に
脆弱性診断はシステムのセキュリティを保つための基本的な取り組みです。まずは現在稼働しているシステムのリスクを把握することが第一歩となります。
完璧な状態を一度に実現しようとするのではなく、リスクを把握して優先度をつけて着実に対処し続けるサイクルを作ることが重要です。新しいシステムを追加するたびに新たなリスクが生まれるため、定期的に向き合い続ける体制を組織に根付かせることが持続的な向上につながります。
AWS 環境では Amazon Inspector を有効化するだけで継続的なスキャンを始められます。現在の環境に潜むリスクを可視化した上で、重要なシステムには段階的にセキュリティ管理の仕組みを充実させていくことを推奨します。
脆弱性診断の進め方や AWS 環境のセキュリティ体制整備について具体的なご相談がある場合は、 AWS 導入と運用の専門家である cloudpack へお問い合わせください。