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

修復の制限と原則

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

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

    • 原因: ワンクリック修復機能は 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 起動メニューのデフォルトの起動順序が手動で変更された場合に通常発生します。その結果、修正スクリプトは新しい kernel をデフォルトの起動オプションとして設定できなくなります。

  • 解決策：

    解決策 1：新しいカーネルの自動設定

    このソリューションは、既存のカスタム GRUB 構成を破棄し、システムが新しい kernel のデフォルト設定を自動的に適用するようにします。

    手順：

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

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

       <BASH>
       
       export DEBIAN_FRONTEND=noninteractive

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

    4. 修正が完了したら、プロンプトに従って server を再起動してください。システムは自動的に最新の kernel を有効にします。

    解決策 2：ブート順序の手動変更

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

    手順：

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

    2. サーバーの再起動後、Ubuntu サーバーにログインします。

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

       説明

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

    4. 新しい起動順序を反映させるため、server を再度再起動します。

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

  • Windows システム: 再起動が必要です。

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

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

    • Security Center コンソールのリスクガバナンス > 脆弱性管理ページのLinux Software Vulnerabilityタブで、vulnerability の速報に 再起動が必要 タグが付いています。

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

  vulnerability rollback 操作が失敗した場合は、以下の原因を調査してください。

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

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

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

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

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

  snapshotの作成は、以下の理由により失敗する場合があります：

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

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

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

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

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

  • 解決策: vulnerability 詳細ページで、再起動 をクリックします。 再起動が完了したら、認証 をクリックします。 ステータスが「修復済み」に変更されると、vulnerability は正常に修復されます。

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

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

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

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

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

  説明

  Microsoft Update Catalog の公式サイトにアクセスして、最新のインストール済み パッチ (通常、KB 番号で識別) を検索し、そのパッケージの詳細を確認することで、懸念されている古い 脆弱性 に対応していることを確認できます。

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

    Windows のセキュリティ更新プログラムは、累積モデルを採用しています。つまり、最新の月次セキュリティ patch は、そのリリース日までの過去数か月分のすべてのセキュリティ修正を含む包括的なパッケージです。

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

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

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

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

  2. ブラウザキャッシュ: console ページがブラウザにキャッシュされている可能性があります。ページを強制的にリフレッシュするか、数分待ってみてください。

  3. 不完全な修正: 修復操作が完全には成功しなかった可能性があります。たとえば、脆弱性 に複数の脆弱なパスがあるにもかかわらず、そのうちの 1 つしか修正されなかった場合などです。修復ステップを見直し、再試行してください。

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

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

  重要

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

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

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

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

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

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

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

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

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