Security Center:脆弱性の管理

脆弱性の修正

修正の延期（Ignoreまたはホワイトリストを追加する）

脆弱性を修正する必要がないと判断した場合は、無視するかホワイトリストに追加して、繰り返しアラートが発生しないようにできます。

• ホワイトリストを追加する：この操作により、設定されたスコープ内で特定のタイプの脆弱性に対するアラートが抑制されます。デフォルトのスコープはすべての資産です。これにより、関連するセキュリティリスクを見逃す可能性があるため、慎重に使用してください。

• Ignore：無視操作は現在のプロセスにのみ影響します。アプリケーションを再起動するか、新しいプロセスを開始すると、Security Center が再度脆弱性を検出する可能性があります。

修正手順

1. 修正前

   • 資産の確認： 影響を受けるソフトウェアバージョンがご利用のサーバー資産に存在することを確認します。

   • リスク評価： ビジネスへの影響を評価し、修正の緊急性と必要性を判断します。すべての脆弱性が即時の修正を必要とするわけではありません。

   • 徹底的なテスト： ステージング環境にパッチを適用します。互換性とセキュリティを完全に検証し、詳細なテストレポートを作成します。

   • データのバックアップ： エラーが発生した場合に迅速にロールバックできるよう、サーバーの完全バックアップ（例：ECS スナップショットの作成）を実行します。

   • 修正のスケジュール設定： ビジネスへの影響を最小限に抑えるため、オフピーク時間帯に修正を実行します。

2. 修正中

   • 二人一組での作業： 少なくとも 2 名の専門家が在席することを確保します。エラーを防ぐため、1 名が作業を行い、もう 1 名がレビューおよび記録を行います。

   • 計画の遵守： 修正計画を厳密に遵守し、修正を順番に適用します。

3. 修正後

   • 結果の検証： 脆弱性が修正され、すべてのシステム関数およびビジネスアプリケーションが正常に動作していることを確認します。

   • ドキュメントのアーカイブ： 脆弱性修正レポートの最終版を作成し、プロセス全体を文書化してアーカイブします。

リスク軽減

• 詳細な計画の策定： 徹底的にテストおよび検証された実行可能な修正計画を作成します。実行中は定義された手順を厳密に遵守します。

• シミュレーション環境でのテスト： 本番環境と同一のシステム、アプリケーション、データを備えたシミュレーションテスト環境を構築し、修正計画を完全に検証します。

• 完全なシステムバックアップ： スナップショットの自動作成と修復オプションを選択して、システム、アプリケーション、データを含む完全なシステムバックアップを実行します。バックアップの復旧可能性を検証し、問題が発生した場合にサービスを迅速に復旧できるようにします。

修正の制限事項と原則

• 修正ボタンがグレーアウトするのはなぜですか？

  • 問題：プロダクトエディションの制限

    • 原因：ワンクリック修正機能は、Basic EditionまたはAnti-virus Editionではサポートされていません。

    • 解決策：付加価値サービス (VAS)として「脆弱性修正」を購入するか、Enterprise EditionまたはUltimate Editionにアップグレードしてください。

  • 問題：サーバー側の問題

    Linux サーバーの問題

    • オペレーティングシステムがサポート終了 (EOL) 状態：ベンダーがもはやパッチを提供していません。手動でオペレーティングシステムをアップグレードする必要があります。以下のオペレーティングシステムの脆弱性を修正するには、OS のアップグレードが必要です。

      • Red Hat 5、Red Hat 6、Red Hat 7、Red Hat 8

      • CentOS 5

      • Ubuntu 12

      • Debian 8、9、10

    • ディスク領域不足：利用可能なディスク領域が 3 GB 未満です。領域を解放するか、ディスクを拡張してください。

    • プロセスが使用中：apt または yum プロセスが実行中です。プロセスが完了するまで待つか、手動でプロセスを終了してから再試行してください。

    • 権限不足：修正コマンドを実行するユーザーに十分な権限がありません。root ユーザーがファイルの所有者であることを確認し、755 などの適切な権限を設定してください。

    Windows サーバーの問題

    • ディスク領域不足：利用可能なディスク領域が 500 MB 未満です。領域を解放するか、ディスクを拡張してください。

    • Windows Update サービスが正常に動作していない：サービスが無効になっているか、パッチのインストールが既に進行中です。

      • サービスが無効になっている場合、サーバーのサービスマネージャーで Windows Update サービスを有効にしてから、再度脆弱性の修正を試行してください。

      • 更新が進行中の場合、Wusa.exe プロセスが完了するまで待つか、手動でプロセスを終了してから、再度脆弱性の修正を試行してください。

• アプリケーションの脆弱性とシステムの脆弱性の違いは何ですか？ なぜワンクリック修正はアプリケーションの脆弱性をサポートしていないのですか？

  • システムの脆弱性（Linux ソフトウェアの脆弱性やWindows システムの脆弱性など）は、オペレーティングシステムまたはそのコンポーネントに影響を与えます。これらの脆弱性には標準化された修正パスがあるため、ワンクリック修正機能で修正できます。

  • アプリケーションの脆弱性は、Web サイトコードやサードパーティ製ソフトウェアなど、自己管理型アプリケーションに存在します。このタイプの脆弱性の修正方法は、お客様の特定のビジネスロジックおよびコードに密接に関連しています。自動化ツールはお客様のビジネスコンテキストを理解できないため、これらの脆弱性は手動で修正する必要があります。

• なぜ私のサーバーにはこれほど多くの脆弱性があるのですか？ 

  新しい攻撃手法が出現するにつれて、古いソフトウェアの脆弱性が継続的に発見されています。定期的なスキャンとパッチ適用は、不可欠かつ継続的なセキュリティタスクです。最も重要なリスクに集中できるように、Show Only Exploitable Vulnerabilitiesスイッチをオンにしてください。

修正操作

• 修正コマンドを実行すると「権限の取得に失敗しました。権限を確認して再試行してください」というエラーが表示された場合はどうすればよいですか？

  • 原因： 修復操作に必要なファイルの所有者がrootではなく、権限が不十分です。

  • 解決策：

    1. ファイルの特定：

       Security Centerで脆弱性の詳細を確認し、修正が必要な特定のファイルとパスを特定します。

    2. 権限の変更：

       サーバーにログインし、次のコマンドを実行してファイルの所有者をrootに変更します。

    3. 修正の再試行：

       Security Center コンソールに戻り、脆弱性の修正操作を再度実行します。

• 脆弱性を一括で修正する場合、どのような順序で修正されますか？

  Linux ソフトウェアの脆弱性は、コンソールリストに表示されている順序で修正されます。一部のWindows システムの脆弱性は、前提となるパッチを最初にインストールする必要があります。Windows システムの脆弱性の一括修正を実行する場合、このような脆弱性が優先されます。残りの脆弱性は、コンソールリストに表示されている順序で修正されます。

• Ubuntu でカーネルの脆弱性を修正した後、再起動しても正常に動作しないのはなぜですか？

  • 症状： Ubuntu サーバーで Security Center のワンクリック修正機能を使用してカーネルの脆弱性をパッチ適用した後、「修正済み、再起動待ち」と表示されます。しかし、サーバーを再起動した後も脆弱性アラートが消えず、システムが新しくインストールされたカーネルを使用していないためです。

  • 原因： この問題は通常、GRUB ブートメニューのデフォルト起動順序が手動で変更された場合に発生します。その結果、修正スクリプトが新しいカーネルをデフォルトの起動オプションとして設定できなくなります。

  • 解決策：

    解決策 1：新しいカーネルを自動的に構成する

    この解決策では、既存のカスタム GRUB 構成を破棄し、システムが新しいカーネルのデフォルト設定を自動的に適用できるようにします。

    手順：

    1. 脆弱性を修正する前に、Ubuntu サーバーにログインします。

    2. 次のコマンドを実行して環境変数を設定します。

       <BASH>
       
       export DEBIAN_FRONTEND=noninteractive

    3. Security Center コンソールに戻り、脆弱性のワンクリック修正を実行します。

    4. 修正が完了したら、指示に従ってサーバーを再起動します。システムが自動的に最新のカーネルを有効にします。

    解決策 2：起動順序を手動で変更する

    既存の GRUB 構成を維持する必要がある場合は、この解決策を使用できます。

    手順：

    1. Security Center コンソールでワンクリック修正を実行し、指示に従ってサーバーを再起動します。

    2. サーバーが再起動したら、Ubuntu サーバーにログインします。

    3. GRUB の起動順序を手動で変更し、新しくインストールされたカーネルバージョンをデフォルトの起動オプションとして設定します。

       説明

       この手順では通常、/etc/default/grub ファイルを変更し、update-grub コマンドを実行します。詳細については、「ECS Linux CentOS インスタンスのカーネル起動順序の変更」をご参照ください。

    4. 新しい起動順序を有効にするために、サーバーを再度再起動します。

• 脆弱性を修正した後、システムを再起動する必要がありますか？

  • Windows：再起動が必要です。

  • Linux Software Vulnerability：以下のいずれかの条件を満たす場合、再起動が必要です。

    • カーネルの脆弱性が修正されました。

    • Security Center コンソールのリスクガバナンス > 脆弱性管理ページのLinux Software Vulnerabilityタブで、脆弱性の情報にはRestart Requiredタグが付いています。

      

• 脆弱性ロールバック操作が失敗するのはなぜですか？

  脆弱性ロールバック操作が失敗した場合、以下の原因が考えられます。

  1. エージェントステータスの確認

     ロールバック操作には、Security Center の エージェントがオンラインであることが必要です。エージェントがオフラインの場合、コマンドを配信できません。まず、エージェントのオフライン状態をトラブルシューティングして解決する必要があります。

  2. バックアップスナップショットの有効性の確認

     ロールバック機能は、修復前に作成された バックアップスナップショットに依存します。スナップショットの有効期限が切れている、または手動で削除されている場合、ロールバック操作は実行できません。

• 脆弱性を修復する際に、スナップショットの作成が失敗するのはなぜですか。

  スナップショットの作成が失敗する原因として、以下の理由が考えられます。

  • RAM ユーザーによる操作：必要な 権限 を持たない RAM ユーザー が操作を実行すると、スナップショットの作成は失敗します。 ご利用の Alibaba Cloud アカウント で操作を実行することを推奨します。 RAM ユーザーの詳細については、「概要」をご参照ください。

  • Alibaba Cloud 以外のサーバー：Alibaba Cloud 以外のサーバーでは、脆弱性修復のためのスナップショット作成はサポートされていません。

修正後のステータスと検証

• 脆弱性を修正しましたが、Security Center はまだ報告しています。どうすればよいですか？

  • 原因：Linux カーネルの脆弱性など、一部の脆弱性は修正後にサーバーの再起動が必要です。

  • 解決策：脆弱性の詳細ページで、Restartをクリックします。再起動が完了したら、認証をクリックします。ステータスが「修正済み」に変化すれば、脆弱性は正常に修正されています。

• Security Center が Windows の脆弱性を修正済みと表示していますが、ホストに特定のパッチがインストールされていないのはなぜですか？

  これは、Windows の更新メカニズムによる予想される動作です。最新の累積更新プログラムがインストールされていれば、その更新プログラムに含まれるすべての過去の脆弱性は修正済みとみなされます。古いパッチを個別にインストールする必要はありません。

  説明

  Microsoft Update Catalog の公式 Web サイトにアクセスして、最新のインストール済みパッチ（通常は KB 番号で識別）を検索し、パッケージの詳細を確認することで、懸念している古い脆弱性が置き換えられていることを確認できます。

  • 原因：Windows の累積更新モデル

    Windows のセキュリティ更新プログラムは累積モデルに従っています。つまり、最新の月次セキュリティパッチは、そのリリース日までに前の月からすべてのセキュリティ修正を含む包括的なパッケージです。

  • 検証ロジック：Security Centerがシステムに最新の累積更新プログラムがインストールされていることを検出すると、置き換えられたすべての脆弱性を修正済みとしてマークします。そのため、過去の各脆弱性に対して個別のパッチをインストールする必要はありません。

• 脆弱性を修正した後、コンソールに「未修正」ステータスが表示されるのはなぜですか？ 

  これは以下の理由で発生する可能性があります。

  1. 検証の遅延：手動修正後は、認証ボタンをクリックして即時スキャンをトリガーする必要があります。ステータスの更新には数分かかる場合があります。

  2. ブラウザーキャッシュ：コンソールページがブラウザーにキャッシュされている可能性があります。ページを強制的に再読み込みするか、数分待ってください。

  3. 修正が不完全：修正操作が完全に成功していない可能性があります。たとえば、脆弱性に複数の脆弱なパスが存在する場合、そのうち 1 つだけが修正された可能性があります。修正手順を確認して、再度試行してください。

• Fixed and Pending Restarted：この状態の脆弱性を Security Center が自動的に検証することは可能ですか？

  いいえ。サーバーをSecurity Center コンソールから再起動するか、手動で再起動する必要があります。サーバーが再起動したら、認証をクリックして脆弱性が修正されていることを確認します。

  重要

  手動で検証しない場合、Security Centerは次回のスケジュールされたスキャン中にステータスを自動的にチェックします。ネットワークの問題による偽陰性を防ぐため、最初のスキャンで検出されなかった場合でも、脆弱性レコードは 3 日間保持されます。脆弱性が 3 日連続で検出されない場合、システムはレコードを削除します。

• 手動で脆弱性を修正した後、検証ステータスが更新されないのはなぜですか？

  サーバーで脆弱性を手動で修正した後、Security Center コンソールの「検証」機能で脆弱性のステータスが「修正済み」に更新されない場合、通常は以下の 2 つの理由が考えられます。

  • 脆弱性スキャンレベルが完全に設定されていない

    • 原因：Security Centerは、脆弱性管理の設定で選択されたリスクレベルの脆弱性のみをスキャンしてステータスを更新します。対象の脆弱性のリスクレベル（高または中など）が選択されていない場合、システムはそのステータスを更新しません。

    • 解決策：脆弱性管理の設定のスキャン設定を確認し、対象の脆弱性のリスクレベルが選択されていることを確認します。

  • Security Center エージェントがオフライン

    • 理由：「検証」機能は、コンソールとサーバー上のクライアント間のリアルタイム通信に依存しています。クライアントがオフラインの場合、コンソールは検証コマンドを送信したり、結果を受け取ったりできません。

    • 解決策：オフラインのエージェントの問題をトラブルシューティングします。エージェントがオンラインに戻ったら、再度検証を試行します。