Security Center:脆弱性の表示と処理

脆弱性の修正

修正の延期 (Ignore/ホワイトリストを追加する)

脆弱性を修正する必要がないと確認した場合、繰り返しのアラートを避けるために、それを無視するかホワイトリストに追加するかを選択できます。

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

• Ignore：無視操作は現在のプロセスに対してのみ有効です。アプリケーションが再起動したり、新しいプロセスが開始されたりすると、脆弱性が再度検出される可能性があります。

推奨される脆弱性修正手順

1. 修正前

   • アセットの確認：サーバーアセットを検証し、脆弱性に関連するソフトウェアバージョンが実際に存在することを確認します。

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

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

   • データバックアップ：ECS スナップショットの作成など、サーバーの完全バックアップを実行し、操作エラー後の迅速なロールバックを可能にします。

   • 適切な時間を選択：ビジネスへの影響を最小限に抑えるため、オフピーク時に操作を実行します。

2. 修正中

   • 二人体制での操作：少なくとも 2 名の専門担当者が必要です。1 人が操作を行い、もう 1 人がレビューと記録を行い、ミスを防ぎます。

   • 一つずつ修正：事前に定められた脆弱性リストと修正計画に厳密に従い、一つずつ修正します。

3. 修正後

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

   • ドキュメントのアーカイブ：最終的な脆弱性修正レポートを作成し、アーカイブし、完全な操作プロセスを記録します。

主要なリスク回避策

• 詳細な計画の策定：実証・テスト済みの実現可能な修正計画を策定し、手順に厳密に従う必要があります。

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

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

修正の制限と原則

• 脆弱性を修正しようとすると [修正] ボタンがグレーアウトするのはなぜですか？

  • 製品エディションの制限

    • エディションが低すぎる：Free および Anti-virus エディションはワンクリック修正をサポートしていません。

    • 解決策：「脆弱性修正」付加価値サービスを購入するか、Enterprise または Ultimate エディションにアップグレードします。

  • サーバーの問題

    Linux

    • オペレーティングシステムがメンテナンスされなくなった：ベンダーがパッチを提供しなくなりました。オペレーティングシステムのバージョンを手動でアップグレードする必要があります。現在、以下のオペレーティングシステムの脆弱性は、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 プロセスを手動で終了してから、再度脆弱性の修正を試みてください。

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

  • Linux ソフトウェアの脆弱性や Windows システムの脆弱性などのシステム脆弱性は、オペレーティングシステムまたはそのコンポーネントの脆弱性です。その修正パスは標準化されているため、ワンクリック修正がサポートされています。

  • アプリケーションの脆弱性は、ウェブサイトのコードやサードパーティ製ソフトウェアなど、自己デプロイされたアプリケーションに存在します。その修正方法はビジネスロジックやコード実装と密接に関連しています。ビジネスを理解せずに自動的に修正することはできないため、手動で処理する必要があります。

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

  新しい攻撃手法が常に登場するため、古いソフトウェアバージョンでは継続的に脆弱性が発見されます。したがって、定期的なスキャンとパッチ適用は継続的なセキュリティタスクです。Show Only Exploitable Vulnerabilities スイッチをオンにして、重要なリスクに集中することができます。

修正操作

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

  • 原因：修正操作に必要なファイルの所有者が root ではないため、権限が不足しています。

  • 解決策：

    1. ファイルの特定：

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

    2. 権限の変更：

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

    3. 修正の再試行：

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

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

  Linux ソフトウェアの脆弱性と Web-CMS の脆弱性は、コンソールの脆弱性リストに表示される順序で一括修正されます。一部の 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 ユーザーの詳細については、「RAM ユーザーの概要」をご参照ください。

  • サーバーが Alibaba Cloud サーバーではない：Alibaba Cloud 以外のサーバーは、脆弱性を修正するためのスナップショット作成をサポートしていません。

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

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

  • 一般的な原因：これは、一部の脆弱性、すなわち Linux カーネルの脆弱性が、修正後にサーバーの再起動を必要とするために発生します。

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

• ホストは対応するパッチをインストールしていません。なぜ Windows の脆弱性が正常に修正されたと表示されるのですか？

  これは Windows の更新メカニズムによって引き起こされる正常な現象です。最新の累積更新プログラムがインストールされていれば、それに含まれるすべての過去の脆弱性が修正されるため、古いパッチを一つずつインストールする必要はありません。

  説明

  Microsoft の公式パッチウェブサイトにアクセスし、インストールされた最新のパッチ (通常は 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 クライアント (エージェント) がオフライン

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

    • 解決策：クライアントのオフライン問題をトラブルシューティングして解決します。オンラインに戻った後、再度検証操作を実行します。