Security Center:脆弱性の管理

脆弱性の修正

修正の延期 (無視 または ホワイトリストを追加する)

脆弱性の修正が不要であると判断した場合は、それを無視するか、ホワイトリストに追加して繰り返しのアラートを防ぐことができます。

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

• Kubernetes システムコンポーネントのベストプラクティス：csi-plugin や CNI プラグインなどの Kubernetes 基本サービスコンポーネントにおける高リスクの脆弱性は、これらのコンポーネントが機能するために高い権限を必要とすることが原因でしばしば存在します。セキュリティ業界のベストプラクティスとして、このようなベンダー提供のコンポーネントを信頼することは一般的に許容されます。これらの既知で必要なリスクをホワイトリストに追加して、アラートのノイズを減らすことを推奨します。

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

修正手順

1. 修正前

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

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

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

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

   • 修正のスケジュール：ビジネスへの影響を最小限に抑えるため、業務時間外に修正を実行します。

2. 修正中

   • 二人体制での操作：少なくとも 2 人の専門家が立ち会うようにします。エラーを防ぐため、1 人の専門家が操作を行い、もう 1 人がレビューと記録を行います。

   • 計画に従う：修正計画に厳密に従い、順次修正を適用します。

3. 修正後

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

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

リスクの軽減

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

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

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

脆弱性の欠落とスキャンの問題

• 脆弱性管理ページに脆弱性が表示されません。どうすればよいですか？

  脆弱性リストが空の場合、現在リスクが検出されていないか、クエリスコープまたはサービスステータスが結果を制限している可能性があります。以下の順序で確認してください。

  1. リージョンの確認：脆弱性リストはリージョンごとに表示されます。ページ上部のリージョンセレクター (例：中国本土) がクエリスコープを決定します。対象資産のリージョンに切り替えて、ページを更新してください。

  2. エディションとアクティベーションステータスの確認：一部の脆弱性機能は付加価値サービスに依存します。ページに従量課金制の脆弱性修正：未アクティブ化と表示されている場合、関連機能はアクティブ化されておらず、利用可能な範囲が制限されています。概要ページに移動して、Security Center のエディションとアクティベーションステータスを確認してください。

  3. 手動でのスキャンのトリガー：まだスキャンが実行されていない場合、または最後のスキャンから時間が経っている場合は、ページ上部のワンクリックスキャンをクリックしてスキャンをトリガーし、スキャン完了後にページを更新してください。

  4. 空の状態の理解：Linux ソフトウェアの脆弱性やWindows システムの脆弱性などのタブにレコードが見つかりませんと表示される場合、現在のフィルター条件で結果が検出されなかったことを意味します。これは正常であり、不具合を示すものではありません。緊急の脆弱性など、別のタブに切り替えて、ページが正常にデータを返すことを確認できます。

  5. 脆弱性とアラートの区別：アウトバウンドのサーバー攻撃などのセキュリティアラートを受け取ったが、脆弱性管理ページにレコードが表示されない場合、脆弱性スキャンとアラート機能は 2 つの異なる検出ディメンションであり、アラートが必ずしも脆弱性にマッピングされるわけではありません。セキュリティイベントを調査するには、「アラートイベントの表示と処理」をご参照ください。

修正の制限と原則

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

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

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

    • 解決策：「脆弱性修正」付加価値サービスを購入するか、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 システムの脆弱性など) は、オペレーティングシステムまたはそのコンポーネントに影響を与えます。これらの脆弱性には標準化された修正パスがあり、ワンクリック修正機能で修正できます。

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

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

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

修正操作

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

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

  • 解決策：

    1. ファイルの特定：

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

    2. 権限の変更：

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

    3. 修正の再試行：

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

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

  Linux ソフトウェアの脆弱性は、コンソールリストに表示される順序で修正されます。一部の Windows システムの脆弱性は、前提条件となる パッチを先にインストールする必要があります。Windows システムの脆弱性のバッチ修正を実行すると、これらの種類の脆弱性が優先されます。残りの脆弱性は、コンソールリストに表示される順序で修正されます。

• Ubuntu でカーネルの脆弱性を修正した後、再起動が機能しないのはなぜですか？

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

  • 原因：この問題は通常、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タブでは、脆弱性に関する情報に再起動が必要タグが付いています。

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

  脆弱性のロールバック操作が失敗した場合、以下の考えられる原因を調査してください。

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

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

  2. バックアップスナップショットが有効であることの確認

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

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

  スナップショットの作成は、以下の理由で失敗する可能性があります。

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

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

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

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

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

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

• ソフトウェアのバージョンをアップグレードせずに脆弱性を修正しましたが、Security Center はまだそれを報告しています。どうすればよいですか？

  • 原因：Security Center は、ソフトウェアまたはコンポーネントのバージョン番号を比較することで、アプリケーションの脆弱性 と 緊急の脆弱性 を検出します。安全なバージョンにアップグレードする代わりに、例えば fastjson で SafeMode を有効にして AutoType を無効にするなどして脆弱性を緩和した場合、バージョン番号は影響を受ける範囲内に留まります。その後のスキャンでは脆弱性が報告され続け、認証 をクリックしてもステータスは修正済みに変わりません。

  • 解決策：緩和策によってリスクが排除されたことを確認した後、脆弱性管理 ページに移動し、脆弱性に対して 無視 または ホワイトリストを追加する を適用して、繰り返しのアラートを停止します。無視 は現在のプロセスにのみ有効です。アプリケーションが再起動したり、新しいプロセスが開始されたりすると、Security Center が再び脆弱性を検出する可能性があります。ホワイトリストを追加する は、ホワイトリストルールを手動で削除するまで、設定された範囲内でこのタイプの脆弱性のアラートを抑制します。2 つの操作の違いと対応する手順については、このトピックの「修正の延期」セクションをご参照ください。

• Windows の脆弱性修正のステータスが「無効」に変わるのはなぜですか？

  Windows の脆弱性検出メカニズムが更新されました。Windows の脆弱性ルールが毎月更新されると、これらのルール変更の影響を受ける既存の脆弱性のステータスは「無効」とマークされます。

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

  これには、以下の理由が考えられます。

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

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

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

• 修復成功、再起動待ち：この状態の脆弱性を Security Center は自動的に検証できますか？

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

  重要

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

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

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

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

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

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

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

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

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