Security Center:脆弱性管理に関するよくある質問

スキャンの動作と結果

• なぜ 1 つのサーバーに対して同じ脆弱性が複数報告されるのですか？

  アプリケーションの脆弱性検出は、特定の実行中のプロセスインスタンスを対象とします。サーバーが同じ脆弱性を持つプロセスの複数のインスタンス (異なるポートで実行されている 2 つの同一の Tomcat サービスなど) を実行している場合、システムは各インスタンスに対して個別の脆弱性を報告します。脆弱なソフトウェアがインストールされていても、対応するプロセスが実行されていない場合、脆弱性は検出されません。

• Fastjson のような脆弱性のスキャン結果が時々異なるのはなぜですか？

  このような脆弱性の検出は、スキャン中に JAR パッケージなどのコンポーネントが実行時にロードされるかどうかに依存します。動的読み込みモデルでは、ビジネスロジックが脆弱なコンポーネントを呼び出したときにのみ、システムは脆弱性を識別します。そのため、スキャン結果は時間によって異なる場合があります。

  説明

  これらのタイプの脆弱性の検出精度を向上させるために、定期的または複数回のスキャンを実行することを推奨します。

• ホストのエージェントがオフラインになった後も、なぜコンソールに脆弱性レコードが残るのですか？

  エージェントがオフラインになると、以前に検出された脆弱性レコードはコンソールに保持されます。ただし、これらのレコードは自動的に古くなり、それらに対してアクション (修復、検証、削除など) を実行することはできません。脆弱性は、次の期間が経過すると自動的に古くなります。

  重要

  すべてのデータは、Security Center サービスの有効期限が切れ、7 日以内に更新されない場合にのみ永久に削除されます。

  • [Linux Software Vulnerability]および[Windows System Vulnerability]：3 日。

  • [Web-CMS Vulnerability]：7 日。

  • [アプリケーションの脆弱性]：30 日。

  • [緊急の脆弱性]：90 日。

• 手動スキャンは自動スキャンのスケジュールに影響しますか？

  手動のワンクリックスキャンを実行しても、既存の自動スキャンスケジュールには影響しません。両者は独立して動作します。毎日または 2 日ごとに実行されるシステム脆弱性スキャンなどの自動スキャンは、手動スキャンに関係なく、スケジュールされたサイクルで継続されます。

スキャンの動作と結果

• 緊急の脆弱性の数とアプリケーションの脆弱性の数が異なるのはなぜですか？

  緊急の脆弱性は、Alibaba Cloud のセキュリティエンジニアによって確認され、バージョン比較と POC 検証によって検出されます。これらは緊急の脆弱性タブにのみ表示されます。アプリケーションの脆弱性は、ソフトウェア構成分析 (SCA) を通じて自動的に検出され、プロセスインスタンスを対象とし、Apache、Redis、Docker などのコンポーネントを含みます。この 2 種類の脆弱性は、検出メカニズム、表示場所、修正方法が異なるため、その数は完全には一致しません。検出ルールが同じバージョン番号 (fastjson < 1.2.83 など) に基づいている場合でも、コンポーネントのランタイムのロード状態によって結果が異なる場合があります。

パフォーマンスへの影響とセキュリティ

• 脆弱性スキャンや緊急脆弱性の POC はビジネスシステムに影響しますか？

  通常は影響ありません。Security Center からの POC は、無害なプローブリクエストを 1 つか 2 つ送信するだけであり、攻撃や破壊的なアクションは実行しません。ただし、まれにアプリケーションが予期しない入力をうまく処理できない場合、最小限の未知のリスクが存在する可能性があります。

• なぜ脆弱性スキャンがメモリ不足 (OOM) エラーを引き起こすことがあるのですか？

  Security Center エージェントにはデフォルトで 200 MB のメモリ制限があります。スキャン中にメモリ使用量がこの制限を超えると、システムのリソースを節約するために、システムの OOM メカニズムが検出プロセス (ALiSecCheck) を終了させます。

  説明

  • この制限は通常、aegisRtap0 という名前のコントロールグループ (cgroup) によって管理されます。関連する OOM 情報は dmesg ログで確認できます。

  • これは正常な動作であり、システム全体のメモリ不足を示すものではありません。ユーザーの介入は不要です。

  • このタイプのメモリ不足 (OOM) エラーは、システム全体のメモリ不足ではなく、cgroup のメモリ制限に起因します。

スキャンの範囲と機能

1. 脆弱性スキャンは何をカバーしますか？

   スキャンはシステム層とアプリケーション層の両方をカバーします。

   • システム層：Linux ソフトウェアの脆弱性および Windows システムの脆弱性。

     重要

     Windows システムの脆弱性スキャンは、月例のセキュリティ更新プログラムパッチのみをサポートします。

   • アプリケーション層：Web-CMS の脆弱性、アプリケーションの脆弱性、緊急脆弱性。

2. 攻防演習中に Security Center を脆弱性スキャンに使用できますか？

   はい。攻防演習の前に、Security Center の脆弱性スキャンを使用して資産を確認できます。脆弱性スキャンは次のタイプをカバーします。

   • [Linux Software Vulnerability]

   • [Windows System Vulnerability]

   • [アプリケーションの脆弱性] ([エンタープライズ版] または [Ultimate] エディションが必要)

   • [緊急の脆弱性]

   クラウドサービスのリスクの高い設定は、脆弱性スキャンの対象外です。これらのリスクは、[クラウドプラットフォーム設定評価] (クラウドセキュリティ態勢管理、CSPM) によって検出されます。

   Security Center の脆弱性スキャンは、ビジネスロジックのバイパスやビジネスセマンティクスの理解を必要とする権限昇格の問題など、コードロジックの脆弱性はカバーしません。攻防演習中にコードロジックの脆弱性を検出する必要がある場合は、脆弱性スキャンとは独立した[侵入テスト] サービスを使用してください。

3. Security Center が検出できる脆弱性のリストはどこで確認できますか？

   1. Security Center コンソールにログインします。

   2. 左側メニューで、脆弱性管理 > [脆弱性] を選択します。概要セクションで、すでにサポートされている脆弱性 カードを見つけます。

   3. カード上の[脆弱性の総数] をクリックして、検出可能なすべての脆弱性のリストとその詳細を表示します。

4. Elasticsearch などの特定の脆弱性の検出はサポートされていますか？

   はい。Elasticsearch などのサービスの検出結果は、コンソールのアプリケーションの脆弱性 ページで確認できます。

   説明

   この機能は、[サービスのサブスクリプション] ([エンタープライズ版] および [Ultimate] エディション) および[従量課金サービスの有効化] ([ホスト総合保護] および [ホスト・コンテナの包括的保護]) でのみ利用可能です。現在のエディションがこの機能をサポートしていない場合は、サービスをアップグレードしてください。

スキャンの範囲と機能

• Security Center は、リストにない CVE 脆弱性についてアラートで通知しますか？

  Security Center は、その脆弱性データベースにリストされている既知の脆弱性についてのみアラートで通知します。CVE 番号が公式に公開またはリストされていない場合 (CVE-2026-31431 のような未公開の番号など)、システムはリスクを特定できず、アラートを送信しません。脆弱性が公開され、パッチが利用可能であるにもかかわらず検出されない場合は、手動で修正したか、緩和策を講じたかを確認してください。Alibaba Cloud のセキュリティアナウンスをご確認ください。脆弱性が公式に公開され、ベンダーがパッチをリリースした後、Security Center は検出ルールを更新し、スキャンに対応します。

• 脆弱性ルールカテゴリが調整された後、最新の分類はどこで確認できますか？

  一部の脆弱性ルールは、誤検知を理由にアプリケーション脆弱性カテゴリから削除され、システム脆弱性として検出されるように調整される場合があります。最新の分類は、すでにサポートされている脆弱性 リストで確認できます。

• Security Center は Ubuntu 24.04 に対応していますか？ 脆弱性を手動でスキャンするにはどうすればよいですか？

  Security Center は手動での脆弱性スキャンに対応しています。主要な Linux ディストリビューションは、通常サポート範囲内です。Ubuntu 24.04 などの特定の OS バージョンのサポート状況については、コンソールでの実際のスキャン結果をご参照ください。以下の方法が利用できます。

  • コンソールにログインし、リスク管理 > 脆弱性管理 に移動し、左上のコーナーで資産が所在するリージョンを選択し、ワンクリックスキャン をクリックして脆弱性の種類を選択します。

  • アセットセンター > ホストアセット ページで、対象のサーバーを選択し、リストの下にある セキュリティチェック をクリックして脆弱性スキャンを実行します。

• 緊急の脆弱性が、[High-priority Vulnerabilities (CVE)] リストに含まれないのはなぜですか？

  [緊急の脆弱性]と [緊急修正が必要な脆弱性 (CVE)] は、異なる観点での分類です。これらが別々に表示されるのは正常です。

  • [緊急の脆弱性]：Alibaba Cloud のセキュリティエンジニアによって確認された高リスクの脆弱性タイプ。これらは主にアプリケーションやミドルウェアの脆弱性 (Fastjson や Apache Dubbo など) であり、通常はビジネスコードや設定に関連しています。ワンクリック修復に対応しておらず、緊急の脆弱性 タブにのみ表示されます。このタブでは、脆弱性の検出と無視が可能です。

  • [緊急修正が必要な脆弱性 (CVE)]：脆弱性管理の概要における統計的な次元です。脆弱性のリスクスコアに基づいてフィルタリングされ、ワンクリック修復に対応するシステムレベルの脆弱性 (Linux カーネルやシステムコンポーネント、Windows システムコンポーネントなど) のみを含みます。

  この 2 種類の脆弱性は、修正方法 (ワンクリック修復 vs. 検出のみで手動対応) が異なり、コンソールでは別々に表示されます。緊急の脆弱性は、緊急修正が必要な脆弱性 (CVE) リストには含まれません。

• 緊急の脆弱性の自動スキャンを停止するにはどうすればよいですか？

  Security Center コンソールにログインします。 [Risk Governance] > 脆弱性管理 に移動し、ページの右上隅にある [Vulnerability Management Settings] をクリックします。緊急脆弱性スキャンサイクル を見つけ、サイクルを スキャンの停止 に変更することで、緊急の脆弱性の定期的な自動スキャンを無効にできます。このオプションは、スキャンサイクルタスクが存在する場合にのみ利用できます。

  アプリケーションの脆弱性スキャンサイクル では、3 日ごと、1週間ごと、2 週間ごと のみ選択できます。スキャンを停止するオプションはありません。そのため、この設定でアプリケーションの脆弱性の自動スキャンを停止することはできません。スキャン頻度を減らすには、サイクルを 2 週間ごと に変更します。

  自動スキャンの頻度を停止または減らすと、脆弱性発見の適時性が低下します。必要な定期スキャンを維持するか、[Scan] を実行することを推奨します。

スキャンの動作と結果

• Security Center のスキャン結果がサードパーティのセキュリティソフトウェア (Huorong など) と異なるのはなぜですか？

  Security Center は、主に Windows が定期的にリリースする公式パッチ (累積的な更新プログラム KBxxxxx など) を検出します。Huorong などのサードパーティ製セキュリティソフトウェアは、このようなシステムレベルのパッチをカバーしていないか、異なる検出戦略を使用している場合があります。したがって、結果が異なるのは正常です。

• サードパーティのスキャンツール (Qualys など) や手動チェックで報告された脆弱性を Security Center が検出しないのはなぜですか？

  サードパーティのセキュリティスキャナーは通常、ソフトウェアのバージョン番号を CVE データベース (CVE-2020-15778 など) と比較して脆弱性を判断します。しかし、一部の脆弱性は実際には影響がないか、または悪用するには特定の条件が必要です。Security Center は、オペレーティングシステムベンダーのセキュリティアナウンスに基づいて脆弱性を検出するため、サードパーティのスキャナーの戦略とは異なります。一般的な理由は次のとおりです。

  • ディストリビューションベンダーがバージョン番号を変更せずにバックポートによって脆弱性を修正した場合：Security Center は修正済みと識別し、アラートを発行しません。バージョン比較に基づくサードパーティのスキャナーは誤検知を発生させます。

  • ディストリビューションベンダーによって確認および修正され、安定した更新パッケージが提供されている脆弱性：Security Center は検出と修正に対応しています。

  • OS ベンダーが修正しないソフトウェアやユーザーがインストールしたソフトウェアの脆弱性：検出には対応していません。

  • カーネルバージョンがすでに修正要件を満たしている：サードパーティ製のツールは古いルールセットでバージョン比較を行うことがありますが、サーバー上の実際のカーネルバージョンは、要求される修正バージョンよりもすでに高くなっています。この場合、Security Center は脆弱性なしと正しく判断します。uname -r を実行して現在のカーネルバージョンを確認し、脆弱性の告知で要求される修正バージョンと比較することをお勧めします。

  • 脆弱性の悪用条件が厳しい、または実際のリスクが管理可能である場合：一部の脆弱性 (OpenSSH CVE-2020-15778 など) では、悪用するには攻撃者がすでに SSH ログインアクセスを持っている必要があります。サーバーがパブリックネットワークに公開されておらず、実際のリスクが低いシナリオでは、Security Center は実際の悪用可能なリスクに基づいて、これらを定期的なスキャンに含めません。潜在的なリスクを完全に排除するには、サードパーティの推奨事項に従って手動でソフトウェアをアップグレードしてください。

  • 特定のシステム脆弱性がリストにない、または検出戦略が異なる場合：一部のディストリビューションは、独自の ID でセキュリティアナウンスをリリースします。影響を受けるパッケージが資産にインストールされていない場合、対応する脆弱性は検出されません。一部の修正には対応する CVE 番号がなく、CVE ベースの検出範囲外の非標準 CVE 脆弱性です。実際のソフトウェアのインストール状況を確認し、Alibaba Cloud のセキュリティアナウンスをご確認ください。

  • アプリケーションプロセスが実行されていない場合：アプリケーションの脆弱性検出は、実行中のプロセスインスタンスを対象とします。脆弱なコンポーネントがロードされていないか、対応するサービスが開始されていない場合、脆弱性は検出されません。

• アクティブでないインスタンスが依然として高リスクの脆弱性を報告するのはなぜですか？

  考えられる原因は次のとおりです。

  1. 履歴資産 (完全にリリースされていないインスタンスまたはスナップショット)。

  2. 関連リソースのリスク (OSS や RDS など、他のクラウド製品の設定の弱点など)。

  3. データ同期の遅延。

  アラートのステータスが Passed と表示されている場合は、アクティブなリスクは存在しないため、無視してかまいません。

• [Show Only Real Risk Vulnerabilities] スイッチをオフにすると、多数の履歴脆弱性が表示され、セキュリティスコアに影響するのはなぜですか？

  アプリケーションの脆弱性は以前に検出されていた可能性がありますが、スイッチが有効になっていたために非表示になっていました。スイッチをオフにすると、履歴の脆弱性が表示され、セキュリティスコアが更新されます。スコアは一定期間後に再度更新されます。

• 新しいスキャンでは、履歴の脆弱性データが使用または復元されますか？

  いいえ。Security Center は、現在有効な脆弱性データ (過去 30 日以内に検出された脆弱性) のみを保持します。各スキャンは、現在の資産の状態に基づく独立した検出です。期限切れでクリアされた履歴の脆弱性レコードは再ロードされません。

• Security Center の脆弱性スキャン結果で、アクティブスキャンとパッシブ検出をどのように区別しますか？

  Security Center の脆弱性スキャン結果では、Web Scanner とマークされた項目はアクティブスキャン (パブリック IP アドレス経由で送信されたプローブ要求による検証) からのものです。これらを最初に修正することを推奨します。ソフトウェア構成分析 (SCA) とマークされた項目は、パッシブ検出 (エージェントによって収集されたローカルのソフトウェアバージョン情報に基づく比較) からのものです。

• アプリケーションの脆弱性検出結果に特定のファイルパスが表示されないのはなぜですか？

  アプリケーションの脆弱性検出は、実行中のプロセスインスタンスを対象とします。脆弱性が検出されても特定のファイルパスが表示されない場合は、脆弱性の詳細にある推奨事項や一般的なパス (Tomcat の作業ディレクトリにある JAR パッケージなど) を参照して手動で確認してください。一部の複雑な脆弱性 (Jackson のデシリアライゼーションなど) については、サーバーにログインし、提供された潜在的なパス (例：/data/.../jackson-databind-*.jar) に基づいて確認する必要がある場合があります。

• Security Center の脆弱性スキャン結果は履歴データを上書きしますか？

  はい。脆弱性スキャンが完了すると、結果はコンソールの資産詳細ページで自動的に更新 (上書き) されます。Security Center コンソールにログインできます。左側のナビゲーションウィンドウで、[Risk Governance] > [Vulnerability Management] を選択して最新の結果を表示します。また、右上隅の [Task Management] をクリックして、スキャンタスクの実行状況と詳細を表示することもできます。

• 新しく購入した ECS インスタンスに脆弱性があるのはなぜですか？

  ECS が使用する OS イメージには、特定のバージョンのソフトウェアパッケージがプリインストールされています。Linux および Windows ベンダーは継続的にセキュリティパッチをリリースしますが、イメージをリアルタイムで最新のパッチに更新することはできません。そのため、新しく購入した ECS インスタンスには、最近公開されたシステムコンポーネントの脆弱性 (カーネル、Python、OpenSSL のセキュリティ更新など) が存在する場合があります。これは正常な現象です。さらに、購入後にインストールしたソフトウェアによっても、既知の脆弱性が持ち込まれる可能性があります。

  脆弱性は、次の方法で修正できます。

  • Security Center 有料版 (Enterprise Edition 以上)：Security Center コンソールにログインします。リスクガバナンス > 脆弱性管理 ページで、修正する脆弱性を選択し、修復 をクリックしてワンクリックで修正します。

  • Security Center 無料版：ECS インスタンスに手動でログインし、OS のパッケージ管理ツール (yum や apt など) を通じてシステムアップデートを実行します。

  脆弱性を修正する前に、修正プロセス中の互換性の問題を回避するために、ECS スナップショットを通じてシステムディスクデータをバックアップすることを推奨します。

• 2 台のサーバー間で脆弱性アラートの数に大きな差があるのはなぜですか？

  • OS のバージョンとメンテナンス状況の違い：EOL システム (CentOS 5 や Ubuntu 12 など) を実行しているサーバーは、ベンダーがセキュリティ更新をリリースしなくなったため、高リスクの脆弱性を報告し続けます。これらの脆弱性は、ワンクリック修復では解消できません。公式サポート期間内のシステムを実行しているサーバーには、このようなアラートはありません。詳細については、このトピックの EOL セクションをご参照ください。

  • アプリケーションプロセスの実行状況の違い：アプリケーションの脆弱性検出は、実行中のプロセスインスタンスを対象とします。一方のサーバーが特定のミドルウェアやデータベースを実行し、もう一方が実行していない場合、前者はそれらのコンポーネントのアプリケーション脆弱性を検出しますが、後者は検出しません。

  さらに、インストールされているソフトウェアパッケージ、Security Center エディションの権限、および 2 台のサーバー間の脆弱性スキャンレベルの設定の違いも、アラート数の違いの原因となります。

• アラートで Redis などのミドルウェアの脆弱性が報告されたが、対応するクラウド製品のインスタンスが見つからない場合はどうすればよいですか？

  このような脆弱性アラートは通常、Alibaba Cloud のマネージドデータベースインスタンスではなく、ECS サーバーにインストールされたミドルウェア (自己管理の Redis など) を指します。Security Center は、マネージドデータベースインスタンス内ではなく、ホストおよびコンテナ資産の脆弱性を検出します。アラート詳細の IP アドレスまたはホスト名を使用して対応する ECS サーバーを特定し、そのサーバー上のミドルウェアのインストールと実行状況を確認することを推奨します。ミドルウェアを特定した後、対応するミドルウェアの脆弱性修正ドキュメントを参照して手動でアップグレードしてください。アップグレード後、コンソールに戻り、[Verify] をクリックします。

• 高リスクのシステム脆弱性が修正されていないというプロンプトが表示されるのはなぜですか？

  このプロンプトは、ECS インスタンス上の OS またはインストールされているソフトウェアに、公式に公開されているがまだパッチが適用されていない高リスクの脆弱性があることを示します。一般的な原因には、システムイメージが時間内に更新されていない、手動でインストールされたソフトウェアのバージョンが古すぎる、または修正後にサーバーが再起動または検証されなかったためにステータスが更新されていない、などがあります。解決策：[Risk Governance] > 脆弱性管理 に移動し、重要度別に脆弱性の詳細を表示し、ワンクリック修復に対応する脆弱性を修正し、アナウンスに基づいて他の脆弱性を手動で処理します。また、[Vulnerability Management Settings] の 脆弱性スキャンレベル が高リスクレベルをカバーしていることを確認してください。

• 新しいインスタンスを追加した後、脆弱性管理とセキュリティアラートにデータがない場合はどうすればよいですか？

  新しく追加されたインスタンスでは、データ同期と最初のスキャンの間に時間差があります。脆弱性管理ページにすぐにデータが表示されない場合があります。脆弱性管理ページで [Scan] をクリックし、必要に応じて脆弱性の種類を選択して検出をトリガーし、スキャン完了後に結果を表示することを推奨します。スキャンの進行状況は [Task Management] で確認できます。スキャン完了後もデータがなく、エージェントがオンラインでインスタンスのステータスが正常な場合、インスタンスには現在検出されたリスクがなく、正常な状態です。また、コンソールの左上隅で選択されているリージョンが資産の実際のリージョンと一致していることを確認してください。

修正の制限と原則

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

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

    • 原因：ワンクリック修正機能は、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 エージェントがオフラインである

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

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

修復の制限事項と原則

• OS がサポート終了 (EOL) になった後も、Security Center は脆弱性スキャンと修復をサポートしますか？

  CentOS 7.6 など、公式サポートが終了したシステムバージョンでは、Security Center は脆弱性スキャンおよびワンクリック修復をサポートしません。スキャンで脆弱性が検出されない場合は、システムバージョンがサポート範囲内かどうかを確認する必要があります。サポート範囲外の場合は、カーネルのリリース時期を確認するか、公式アナウンスをご参照ください。OS を公式サポート期間内のバージョンにアップグレードできます。または、リスクが許容範囲内であると評価した上で、コンソールで脆弱性を [Ignore] としてマークできます。

• 同じサーバーに複数のサービスをデプロイしている場合、システムの脆弱性の影響範囲はどこまでですか？

  同じサーバーに複数のサービスをデプロイしている場合、同一の OS 環境を共有するため、システムの脆弱性はサーバー上のすべてのサービスに影響します。サーバー全体にシステムパッチを適用することを推奨します。また、修復前にスナップショットを作成してください。

• 脆弱性を修復する際にサーバーを再起動する必要がありますか？業務への影響はありますか？

  • Windows システムの脆弱性：パッチを有効にするにはサーバーの再起動が必要です。再起動により短時間のサービス中断が発生します。オフピーク時間帯に脆弱性を修復し、ロールバックに備えて [Create Snapshot and Fix] を選択することを推奨します。

  • Linux カーネルの脆弱性：再起動が必要です。修復後もステータスが [Fixed - Restart Required] のままの場合は、コンソールで [Restart] をクリックするか、サーバーを手動で再起動してから、[Verify] をクリックしてください。

  • Linux ソフトウェアの脆弱性：通常は再起動は不要です。ただし、脆弱性アナウンスに 再起動が必要 タグが含まれる場合は再起動が必要です。

  • 業務への影響：再起動によりサービス中断が発生します。また、修復プロセスがリソースを消費し、動作が遅くなる場合があります。事前にバックアップ (スナップショット) を取得し、テスト環境で検証することを推奨します。

  • サービス停止の仕組み：Windows システムの脆弱性と Linux カーネルの脆弱性は、修復を適用するには再起動が必要であり、再起動により短時間のサービス中断が発生します。アプリケーション脆弱性と緊急脆弱性は検出のみをサポートし、ワンクリック修復をサポートしないため、Security Center の修復操作によってサービスが停止することはありません。再起動が必要な脆弱性については、コンソールに 再起動が必要 タグが表示されます。修復完了後、ステータスは [Fixed - Restart Required] と表示されます。

  • 未修復のリスク：Windows システムの脆弱性を修復しなくても、システムと業務の通常運用には影響しませんが、システムのセキュリティが低下し、攻撃リスクが増加します。脆弱性の重大度と業務の重要度に基づいて修復の優先度を評価し、すぐに修復しない脆弱性については、アクセス制御などの緩和策を実施することを推奨します。

• 高リスクの脆弱性 (例：Linux Kernel ptrace) を修復しない場合、どのようなリスクがありますか？

  • リスクの説明：高リスクのローカル権限昇格の脆弱性 (例：CVSS 7.8) を修復しない場合、攻撃者がこれを悪用して機密ファイル (/etc/shadow、SSH 秘密鍵) を窃取し、最高権限を取得することで、サーバーが完全に制御されてしまう可能性があります。

  • 緩和策：すぐに修復できない場合は、セキュリティグループでアクセスを制限し、監視を強化してください。ただし、根本的な解決には修復が必要です。

  • SSL/TLS 脆弱性の特定：SSL/TLS プロトコルの情報漏えいの脆弱性 (例：CVE-2016-2183) の場合は、ドメイン名を ping して IP アドレスを解決し、CLB/K8s リソースを使用して影響を受ける特定のノードを特定し、手動で修復できます。

• 脆弱性の修復に失敗した後、再度 [Fix] をクリックすると課金されますか？

  Security Center の脆弱性修復は、修復ごとに課金されます。[Fix Now] をクリックすると修復クレジットを 1 つ消費し、コンソールの修復エントリに現在利用可能な残りの修復クレジットが表示されます。修復が失敗した場合、同じ脆弱性に対して修復が成功するまでは、再度 [Fix] をクリックしても追加料金は発生しません。プロセス全体が 1 回の修復として課金されます。具体的な料金と課金ルールについては、Security Center の課金ドキュメントをご参照ください。

• 修復前にスナップショットの完了を待つ必要がありますか？修復後に業務が異常になった場合、どのようにロールバックしますか？

  • 修復前のスナップショット作成タイミング：バックアップとしてスナップショットを手動で作成している場合は、バックアップの有効性を確保するため、スナップショットのステータスが Available になるまで待ってから脆弱性修復を実行することを推奨します。Security Center で修復する際は、[Create Snapshot and Fix] を選択できます。または、時間を短縮するために [Fix Without Snapshot] を選択できます。後者はスナップショットによるロールバックをサポートしません。

  • 修復後のロールバック：修復によってアプリケーションが利用できなくなったり、システムに異常が発生したりした場合は、処理済み脆弱性の累計 で修復に成功した脆弱性を見つけ、[Roll Back] をクリックして、修復前に作成されたスナップショットを選択して復元できます。ロールバックは、ワンクリック修復をサポートする Linux ソフトウェアの脆弱性と Windows システムの脆弱性でのみ利用できます。Alibaba Cloud 以外のサーバーはロールバックをサポートしていません。

  • ロールバック失敗のトラブルシューティング：ロールバックの失敗は通常、エージェントがオフラインであること、またはスナップショットが削除されたか期限切れであることが原因です。詳細については、このトピックの「脆弱性ロールバックが失敗する理由」および「脆弱性修復中にスナップショットの作成が失敗する理由」のセクションをご参照ください。

• 高リスクの脆弱性アラートは直接削除できますか？修復が不要な脆弱性や誤検知の脆弱性はどのように対応すればよいですか？

  • 直接削除はサポートされていません：Security Center の脆弱性レコードは、実際の資産の検出結果に基づいて生成されるため、手動削除はサポートされていません。脆弱性レコードは、エージェントが保持期間を超えてオフラインになった場合、またはサービスの有効期限が切れた場合にのみ無効になります。

  • 推奨される対応：リスクがないことが確認できた脆弱性、誤検知の脆弱性、または直ちに修復する必要がない脆弱性については、[Ignore] を使用するか、ホワイトリスト に追加してアラートを停止してください。

  • [Ignore] とホワイトリストの違い：[Ignore] は、現在の資産上の単一の脆弱性レコードに対して有効になります。脆弱性のあるプロセスが再起動された場合、または後続のスキャンで脆弱性が再検出された場合は、再度表示される可能性があります。ホワイトリスト は、脆弱性の次元 (すべての資産、指定した資産グループ、または指定した資産) で範囲を設定し、ホワイトリストルールを手動で削除するまで有効です。

  • 低重大度の脆弱性の対応：従量課金モードでは、業務リスク評価に基づいて、低～中程度の重大度の脆弱性を修復するかどうかを判断できます。すぐに修復しない脆弱性については、[Ignore] またはホワイトリストを使用してアラートノイズを管理してください。

• 緊急脆弱性が [Unprotected] または Protected と表示されている場合、対応が必要ですか？

  • ステータスの説明：緊急脆弱性は検出のみをサポートし、ワンクリック修復をサポートしません。リストに表示される 未保護 / Protected は、Cloud Firewall の仮想パッチによる保護ステータスを示します。未保護 は、Cloud Firewall の仮想パッチでまだ保護されていないことを示します。リンクをクリックして Cloud Firewall の脆弱性保護ページに移動し、保護を有効化できます。Protected は、[Cloud Firewall の仮想パッチで保護されています] が有効になっていることを示します。緊急脆弱性自体の対応ステータスには、Unfixed、Fix Failed、Fixing、Verifying、Fixed、Ignored、Expired も含まれます。

  • トラブルシューティング：日次レポートで緊急脆弱性のリスクが示されているにもかかわらずコンソールに表示されない場合は、リスクガバナンス > 脆弱性管理 > 緊急の脆弱性 タブに移動し、未修復の緊急脆弱性がないかを確認してください。また、左上で選択したリージョンが資産の所在地と一致していることを確認してください。

  • 対応の推奨：保護ステータスが正常であっても、絶対的なセキュリティを意味するものではありません。脆弱性の詳細で提案されているとおり、影響を受けるコンポーネントを安全なバージョンにアップグレードするか、Cloud Firewall の仮想パッチで保護することを推奨します。

• アプリケーション脆弱性にプロセス ID がありません。どのように保護すればよいですか？

  アプリケーション脆弱性は、実行中のプロセスインスタンスを対象として検出されます。一部のアプリケーション脆弱性はプロセス ID に関連付けられておらず、ワンクリック修復をサポートしません。次の方法で保護できます：

  • ベンダーバージョンへのアップグレード：ソフトウェアベンダーの公式 Web サイトにアクセスし、最新バージョンをダウンロードしてアップグレードし、脆弱性を修復してください。

  • RASP アプリケーション保護の使用：Security Center コンソールで アプリケーション保護 (RASP) を有効化し、Security Center と連携してランタイム保護を提供します。これは有料機能です。ランタイム保護の機能の詳細については、「What is application protection」をご参照ください。

修復操作

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

  自動修復では通常、サーバーがシャットダウンすることはありませんが、一部のカーネル脆弱性の修復では再起動が必要になる場合があります。手動修復の場合、再起動が必要かどうかは脆弱性のタイプによって異なります。Linux ソフトウェアの脆弱性では一般的に再起動は不要ですが、Windows システムの脆弱性と Linux カーネルの脆弱性では、修復を有効にするために再起動が必要です。業務時間外に脆弱性を修復し、スナップショットを作成することを推奨します。

• Security CenterによるWindowsパッチの自動修復は、手動でのパッチダウンロードやインストールと同じ効果がありますか?

  はい。Security Center の修復機能は、システムレベルのインターフェイスを呼び出して Microsoft の公式パッチをインストールするため、手動でのダウンロードとインストールと同じです。

• Microsoftがパッチをリリースした後、修復前にSecurity Centerとの同期を待つ必要がありますか?

  待つ必要はありません。サーバー上で Windows Update を通じて最新の累積更新プログラムを直接インストールすることで、修復を完了できます。インストール後、Security Center コンソールに移動し、対象の脆弱性に対して [検証] をクリックしてステータスを更新します。ステータスがすぐに更新されない場合は、次回の定期スキャンをお待ちください。Security Center による自動修復の効果は、公式パッチの手動インストールと同じです。詳細については、本トピックの自動パッチインストールと手動パッチインストールの比較に関するセクションをご参照ください。

• Security Centerは脆弱性スキャンレポートの生成とエクスポートに対応していますか?

  • アプリケーション脆弱性レポート：アプリケーション脆弱性スキャンをサポートするには、従量課金版を Full Host Protection 以上にアップグレードする必要があります。コンソールにログインし、リスクガバナンス > 脆弱性管理 > アプリケーションの脆弱性 タブに移動します。リストの上にある アイコンをクリックし、サーバー上のアプリケーション脆弱性リストをエクスポートします。注：Web サイト URL の個別レポートはサポートされていません。

  • 指定された ECS インスタンスの脆弱性情報: アセットセンター > ホストアセットに移動し、目的のサーバーを検索して詳細ページに移動し、脆弱性管理 > アプリケーションの脆弱性 リストの下にある 脆弱性情報 セクションをクリックします。 アイコンをクリックして表示およびエクスポートします。

  • [セキュリティレポート]：システム設定 > セキュリティレポート に移動し、カスタムセキュリティレポートを作成します。Security Center は現在、専用の脆弱性スキャンレポートの提供をサポートしていません。脆弱性スキャンレポートを取得するには、セキュリティ評価サービスを購入して脆弱性スキャンを実行できます。

• Linuxカーネルのバージョンが特定のCVE脆弱性の影響を受けるかどうかを判断するにはどうすればよいですか?

  1. uname -r コマンドを実行して現在のカーネルバージョンを表示し、CVE のアナウンスで示されている影響を受けるバージョン範囲と比較します。

  2. 例：CVE がカーネルバージョン 4.14 から 6.18.21 および 6.19.11 に影響する場合で、現在のバージョンが 3.10.0 のときは、システムは影響を受けず、修復は不要です。

  3. Alibaba Cloud 公式の脆弱性リスクと修復に関する告知ページにアクセスして、具体的な影響を確認できます。

• 脆弱性のバッチ修復における実行順序、同時実行の推奨事項、UI表示の問題にはどのように対処すればよいですか?

  • 実行順序：Linux ソフトウェアの脆弱性は、コンソールリストの順序で実行されます。Windows システムの脆弱性については、前提条件となるパッチが必要な脆弱性が最初に修復され、残りはリストの順序で実行されます。

  • 同時実行の推奨事項：リソースの競合や管理の混乱を避けるため、前のバッチの脆弱性修復が完了してから次のバッチを実行することを推奨します。

  • UI が応答しない：バッチ修復中に「コマンド送信中」と表示された後、UI が応答しない場合は、フロントエンドの表示遅延が原因である可能性があります。ページを手動で更新して「修復中」のステータスを表示してください。

  • 所要時間：Linux の自動修復は通常、脆弱性の数、サーバーのパフォーマンス、ネットワーク状況に応じて、数分から数十分かかります。時間がかかりすぎる場合は、ディスク容量 (3 GB 以上を推奨)、パッケージマネージャープロセスの競合、または権限の問題を確認してください。

• パブリックIPアドレスを持たないサーバーでもSecurity Centerによる脆弱性修復は可能ですか?

  はい。サーバーに Security Center エージェントがインストールされており、ネットワーク接続性が正常であれば、脆弱性修復機能を利用できます。Alibaba Cloud の内部ネットワークソースを使用して修復する場合、パブリック IP アドレスの割り当ては不要です。前提条件：Security Center が有効化されており、エージェントがオンラインであることを確認してください。

• 脆弱性の自動修復を有効にする際の注意事項と推奨事項は何ですか?

  • デフォルトでは無効：自動修復は、手動でポリシーを設定して有効にする必要があり、デフォルトでは有効になっていません。

  • サポート範囲の制限：カーネル以外の Linux システムの脆弱性のみがサポート対象であり、ワンクリック修復機能に依存します (対応バージョンである必要があります)。

  • 運用の推奨事項：まずテスト環境で検証することを推奨します。有効にする前に、スナップショットバックアップポリシーが設定されていることを確認してください。業務時間外に実行するように設定してください。過度な修復クレジットの消費やリソースの競合を防ぐため、すべての資産に対して有効にすることは避けてください。

• データベースやミドルウェア (MySQL や Oracle など) のバージョンアップを伴う修復は業務に影響しますか? 注意事項は何ですか?

  • 業務への影響：修復プロセス自体はデータベース内の業務データを変更しませんが、バージョンアップグレードでは通常、データベースまたはミドルウェアサービスの再起動が必要となり、短時間のサービス中断が発生する可能性があります。業務時間外に修復することを推奨します。

  • バックアップの推奨事項：修復前に、必ず ECS スナップショットまたはデータベースバックアップを作成してください。Security Center で修復する際は、 [スナップショットを作成して修復] を選択できます。[スナップショットなしで修復] を選択した場合、異常発生後にスナップショットによるロールバックは利用できません。

  • 修復の優先順位：すべての脆弱性をすぐに修復する必要はありません。緊急かつ深刻度の高い脆弱性を優先することを推奨します。深刻度が中または低の脆弱性は、業務への影響を評価した後、計画した日時に修復するか、補完的な対策 (セキュリティグループによるアクセス制限など) を実施した後に [無視] するか、ホワイトリストに追加できます。

  データベースとミドルウェアの脆弱性は主にアプリケーションの脆弱性であり、ワンクリック修復には対応していません。サーバーにログインして手動でアップグレードし、その後コンソールに戻って [検証] をクリックする必要があります。

• 脆弱性のバッチ修復で「一致するレコードがありません」と表示される、またはリストが空になる場合はどうすればよいですか?

  次の順序でトラブルシューティングを行ってください。

  1. エディションと権限の確認：ワンクリック修復とバッチ修復は、Security Center の有料版または有料の脆弱性修復機能で利用できます。無料版はワンクリック修復に対応していません。[資産] ページで対象サーバーに適用されているエディションを確認してください。必要に応じてエディションをアップグレードするか、脆弱性修復機能を有効化してください。具体的なサポート範囲については、脆弱性の修復をご参照ください。

  2. フィルターの確認：[脆弱性管理] ページで、 [検証済みリスク脆弱性のみ表示] スイッチ、脆弱性の深刻度、または処理ステータスなど、フィルターで条件を絞り込みすぎていないか確認してください。フィルターをクリアしてページを更新してみてください。

  3. リージョンの確認：コンソールの左上隅で選択したリージョンが、資産の実際のリージョンと一致していることを確認してください。リージョンの一致は、特にアプリケーションの脆弱性の場合に重要です。

  4. 脆弱性タイプの制限：選択した脆弱性がワンクリック修復に対応しているか確認してください。バッチ修復は、ワンクリック修復に対応する Linux ソフトウェアの脆弱性と Windows システムの脆弱性にのみ適用されます。アプリケーションの脆弱性と緊急の脆弱性は、スキャンと手動修復にのみ対応しており、バッチでのワンクリック修復には対応していません。

• ACK クラスターでの脆弱性修復が遅い、または非効率的な場合はどうすればよいですか?

  • 修復タスク設定の確認：コンテナクラスターでの脆弱性修復の効率は、修復タスクの同時実行数の影響を受けます。Security Center コンソールで脆弱性修復タスクの関連設定を確認し、同時実行数を増やせるかどうかを確認することを推奨します。

  • 最適化の推奨事項：調整後の修復の進捗状況を確認してください。それでもパフォーマンスのボトルネックが解消されない場合は、修復タスクと業務プロセス間のリソース競合を避けるために、クラスターノードのリソース負荷を包括的に評価してください。

  修復中は、 [タスク管理] を通じて特定のタスクの進捗状況と失敗したノードを確認できます。

• 当局から高リスクの脆弱性通知を受けましたが、アクセス制御はすでに実施済みです。是正報告書にはどのように記入すればよいですか?

  • 対処の原則：脆弱性のある資産がセキュリティグループやネットワーク ACL などの手段によってアクセスを厳格に制限していること (信頼できる IP アドレスのみを許可するなど) を確認し、業務上の理由ですぐに修復するのが困難な場合は、アクセス制御の設定を補完的な対策として記載することができます。

  • 報告書の記入：是正報告書では、現在の脆弱性のステータスと影響範囲、実施済みのアクセス制御ポリシー (設定のスクリーンショットを添付)、リスク評価の結論、および今後の修復計画とスケジュールを説明し、リスクが管理下にあることを示してください。

  • 今後の対応：補完的な対策は修復に代わるものではありません。メンテナンス期間中に脆弱性修復を完了し、修復後に検証を行って脆弱性のステータスを更新することを推奨します。

• 追加料金を避けるために脆弱性の自動修復を無効にするにはどうすればよいですか?

  [脆弱性管理] ページで、右上隅の [脆弱性管理設定] をクリックし、 [自動脆弱性修復設定] タブに移動して、 [自動脆弱性修復スイッチ] をオフにします。無効にすると、修復タスクは自動的に実行されなくなり、自動修復による修復クレジットの消費もありません。無効にする前に、既存の運用保守体制に影響を与えないよう、設定済みの自動修復ポリシーの範囲を確認することを推奨します。Security Center の概要ページにある自動修復カードは、この機能を有効化して設定タブにリダイレクトするためのものです。無効にするには、 [脆弱性管理設定] に移動してください。

特定の脆弱性タイプの修正

• カーネルをアップグレードして修正した後も、Security Center が脆弱性を報告し続ける場合はどうすればよいですか？

  1. 現在のカーネルが正常にアップグレードされたことを確認する

     1. 現在実行中のカーネルバージョンを確認し、脆弱性の説明で指定されている要件を満たしていることを確認します。

        uname -av
        cat /proc/version

     2. システムが新しいカーネルで起動することを確認する

        cat /etc/grub.conf

  2. 古いカーネルの rpm パッケージを確認してクリーンアップする

     1. インストールされているすべてのカーネル パッケージを表示し、古いカーネル パッケージ (現在のカーネルよりも低いバージョン) を特定します。

        rpm -qa | grep kernel

     2. システムの保護スナップショットを作成する (強く推奨)

        ECS コンソールで現在のインスタンスのスナップショット/イメージを作成し、誤った削除によるシステムの異常や起動失敗を防ぎます。

     3. 古いカーネルの rpm パッケージをアンインストールする

        2. rpm -e kernel-<old_version>

        3. または、ディストリビューションで推奨されている方法を使用します。CentOS/RedHat の場合：

           yum remove kernel-<old_version>

  3. アラートを無視する

     使用中の新しいカーネルで脆弱性が修正されたことを確認した後にのみ、アラートを無視してください。

     1. Security Center コンソールにログインします。

     2. 左側のナビゲーションウィンドウで、リスクガバナンス > 脆弱性管理 を選択します。コンソールの左上隅で、保護する資産が配置されているリージョンを選択します: 中国本土 または 中国本土以外。

     3. [Linux Software Vulnerability] タブをクリックして脆弱性を特定し、脆弱性名をクリックして [脆弱性の詳細] ページに移動します。

     4. [操作] 列で アイコンをクリックし、[無視] を選択します。

• Ubuntu カーネルを手動でアップグレードするにはどうすればよいですか?

  重要

  カーネルのアップグレードには一定のリスクが伴います。アップグレード方法については、ソフトウェアの脆弱性の修正を参照することを強く推奨します。

  次の例では、Ubuntu 14.04 で Ubuntu カーネルを 3.1* から 4.4 に手動でアップグレードする方法について説明します。

  1. uname -av コマンドを実行して、現在のカーネルバージョンが 3.1* であるかどうかを確認します。

     root@iZbp14z5cmxxxf76owZ:~# uname  -av
     Linux iZbp14z5cmxxxf76owZ 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

  2. 次のコマンドを実行して、最新のカーネル更新パッケージが利用可能かどうかを確認します。

     apt list | grep linux-image-4.4.0-94-generic
     apt list | grep linux-image-extra-4.4.0-94-generic

  3. 更新が利用できない場合は、apt-get update コマンドを実行して最新の更新パッケージを取得します。

  4. 次のコマンドを実行してカーネルをアップグレードします。

     apt-get update && apt-get install linux-image-4.4.0-94-generic
     apt-get update && apt-get install linux-image-extra-4.4.0-94-generic

  5. 更新パッケージのインストール後、サーバーを再起動して新しいカーネルをロードします。

  6. サーバーの再起動後、次のコマンドを実行してカーネルのアップグレードが成功したかどうかを確認します。

     • uname -av コマンドを実行して、現在のカーネルを表示します。

       root@iZbp14z5cmxxxxf76owZ:~# uname -av
       Linux iZbp14z5cmxxxxf76owZ 4.4.0-94-generic #117~14.04.1-Ubuntu SMP Wed Aug 30 06:50:25 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

     • dpkg -l | grep linux-image コマンドを実行して、現在のカーネル パッケージを表示します。

       uname -av も実行して、現在のカーネルバージョンが 4.4.0-94-generic であることを確認します。出力では、linux-image-4.4.0-94-generic と linux-image-extra-4.4.0-94-generic が使用中のカーネル パッケージです。

       root@iZbp14z5cm****f76owZ:~# uname -av
       Linux iZbp14z5cm****f76owZ 4.4.0-94-generic #117~14.04.1-Ubuntu SMP Wed Aug 30 06:50:25 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
       root@iZbp14z5cm****f76owZ:~# dpkg -l | grep linux-image
       ii  linux-image-3.13.0-32-generic        3.13.0-32.57             amd64        Linux kernel image for version 3.13.0 on 64 bit x86 SMP
       ii  linux-image-3.13.0-65-generic        3.13.0-65.106            amd64        Linux kernel image for version 3.13.0 on 64 bit x86 SMP
       ii  linux-image-4.4.0-94-generic         4.4.0-94.117~14.04.1     amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
       ii  linux-image-extra-3.13.0-32-generic  3.13.0-32.57             amd64        Linux kernel extra modules for version 3.13.0 on 64 bit x86 SMP
       ii  linux-image-extra-3.13.0-65-generic  3.13.0-65.106            amd64        Linux kernel extra modules for version 3.13.0 on 64 bit x86 SMP
       ii  linux-image-extra-4.4.0-94-generic   4.4.0-94.117~14.04.1     amd64        Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
       ii  linux-image-generic                  3.13.0.65.71             amd64        Generic Linux kernel image

• カーネルの脆弱性を修正する際に、「ターゲットカーネルに互換性がありません」というエラーが表示される場合はどうすればよいですか？

  • 現象：Security Center コンソールでワンクリックでカーネルの脆弱性修正を実行した後、修正に失敗し、「ターゲットカーネルに互換性がありません」といった内容のエラーメッセージが表示されます。

  • 原因：システムは、サーバー上のカーネルバージョンがターゲットの修正バージョンと互換性がないことを検出しました。これは、手動でのカーネル設定変更、非標準のカーネルバージョン、またはカーネルのバージョン差が大きいために正常なアップグレードができないことが原因である可能性があります。

  • ソリューション：

    • 方法 1： 強制修復を使用する

      ビジネスに影響がないことを確認した場合に限り、強制修復を使用して互換性チェックをスキップできます。

      1. 修正失敗のダイアログを閉じます。

      2. [未対応の脆弱性] エリアで、対象サーバーの [操作する] 列にある [修復] ボタンをクリックします。

      3. 修正ダイアログに、[強制修復] オプションが表示されます。このオプションと修正方法を選択した後、[今すぐ修復] をクリックして再試行します。

         重要

         脆弱性の修正には、システム カーネルやソフトウェアバージョンのアップグレードが含まれる場合があり、ビジネス上の互換性リスクを伴います。問題が発生した場合に迅速にロールバックできるよう、[スナップショットの自動作成と修復] オプションを選択することを推奨します。

    • 方法 2： カーネルを手動でアップグレードする

      強制修復が適切でない場合は、Linux ECS インスタンスのカーネルのアップグレードを参照して手動でアップグレードしてください。

• 強制修復はどのような場合に使用できますか？また、リスクは何ですか？

  • ユースケース：強制修復は、主に次のシナリオで使用されます。

    • ターゲットカーネルとの非互換性が原因で、ワンクリック修復に失敗した場合。

    • 現在のシステム環境は脆弱性修正の要件を満たしているにもかかわらず、互換性チェックに失敗した場合。

  • 操作方法：修正ダイアログで、[強制修復] オプションを選択します。

  • リスクに関する警告：強制修復はクライアントの互換性チェックをスキップするため、次のようなリスクが発生する可能性があります。

    • 修正後、システムに互換性の問題が発生し、ビジネスに異常が生じる可能性があります。

    • カーネル アップグレードの失敗により、システムが正常に起動できなくなる可能性があります。

  • 推奨事項：強制修復を使用する前に、[スナップショットの自動作成と修復] オプションを選択して、迅速なロールバックのためのバックアップを作成してください。強制修復は、ビジネスへの影響がないことを確認した場合にのみ使用することを推奨します。

• Security Center コンソールで一部の脆弱性に「更新なし」と表示される場合はどうすればよいですか？

  脆弱性に「更新なし」と表示される場合、その脆弱性を持つソフトウェアに公式の更新ソースがなく、Security Center コンソールからは修正できないことを意味します。次の手順を参照して、適切な解決策を選択してください。

  • 公式の更新ソースがパッチを提供していない

    • 現象：更新コマンドを実行すると、システムから already installed and latest version や No Packages marked for Update といったメッセージが返されます。

    • 既知のパッケージ：Gnutls、Libnl、MariaDB

    • 推奨事項：公式ソースから更新がリリースされるのをお待ちください。

  • OS のバージョンがサポート終了 (EOL) している

    • 現象：パッケージが現在のシステムでサポートされている最新バージョンであっても、脆弱性の修正に必要なバージョンを満たしていない場合があります。たとえば、CentOS 6.x やその他の EOL を迎えたシステムバージョンがこれに該当します。

    • 推奨事項：

      • 方法 1：OS を公式サポートサイクル内のバージョンにアップグレードします。

      • 方法 2：リスクを評価し、管理可能であると判断した場合は、脆弱性を「無視」としてマークします。

  • 再スキャン：脆弱性管理ページで、[スキャン] を再度実行し、最新の検出結果と修正方法を取得します。

  • 同期を待つ：スキャン後も修正オプションが利用できない場合、公式パッチがまだリリースされていないか、修正方法が検証中である可能性があります。その後の更新をお待ちください。

  • 代替策：脆弱性に長期間修正オプションが表示されない場合は、OSベンダーの公式セキュリティ情報を参照して手動で対応するか、アクセス制御など一時的な緩和策を講じてください。リスクを評価した後、[無視] を選択します。

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

• yum update kernel を実行した後、「Nothing to do」と表示されるか、アップグレード成功のメッセージが表示されない場合、サーバーを再起動する必要がありますか?

  yum update kernel の実行結果が Nothing to do であったり、アップグレード成功のメッセージが表示されなかったりした場合でも、カーネルの変更を完全に有効にし、システムの実行状態をインストール済みのカーネルと一致させるため、再起動することを推奨します。再起動後、Security Center コンソールの脆弱性詳細ページで [検証] をクリックして、脆弱性のステータスが [修正済み] に更新されているかどうかを確認してください。検証後もステータスが更新されない場合は、このセクションのトラブルシューティング手順を参照してください。

• 脆弱性の修正が失敗した後、失敗アラートを表示するにはどうすればよいですか?

  • 表示方法: セキュリティセンターコンソールの脆弱性管理ページで、修正中の脆弱性パネルの下にある数字をクリックします。 修復に失敗した脆弱性を見つけ、修正中の脆弱性列のステータス列にあるアイコンをクリックし、原因の詳細ダイアログで修復失敗のアラートを表示します。

  • アラートの内容： 修正失敗アラートには、失敗の具体的な原因、対応するエラーコード (ある場合) 、および推奨される対処法が表示されます。

• 修正失敗アラートのエラーコードには、どのように対処すればよいですか?

  修正失敗アラートのエラーコードに基づいて、脆弱性修正失敗の原因のトラブルシューティングを参照し、対応する解決策を確認してください。

• 手動で脆弱性を修正すると、Security Center が誤検知による攻撃アラートを生成しますか?

  いいえ。脆弱性パッチを手動で更新しても、Security Center が誤検知による攻撃アラートを生成することはありません。この 2 つは無関係です。手動修正後もコンソールに脆弱性が未修正と表示される場合は、[検証] ボタンをクリックするか、その後の自動的なステータス更新をお待ちください。

• 修正後も脆弱性が「未修正」または「再起動が必要」と表示されたり、検証が応答しなかったりするのはなぜですか?

  • 再起動が必要なステータス： Linux カーネルの脆弱性や、[再起動が必要] とマークされた脆弱性は、修正後にサーバーの再起動が必要です。Security Center の脆弱性詳細ページで直接 [再起動] をクリックできます (このオプションは [修正済み - 再起動が必要] の Linux ソフトウェア脆弱性と Windows システム脆弱性でのみ利用可能で、Alibaba Cloud 以外のサーバーはサポート対象外です) 。または、ECS コンソールかサーバーにログインして reboot コマンドを実行します。再起動後、[検証] をクリックしてステータスを更新します。

  • 複数の脆弱性に対する一括再起動： 再起動が必要な複数の脆弱性は、一つずつ修正してパッチを適用した後、最後にまとめてシステムを 1 回再起動できます。脆弱性ごとに再起動する必要はありません。

  • 検証が応答しない： [検証] をクリックした後、ステータスが長時間変化しない場合、脆弱性スキャンレベルの設定が不完全であるか、エージェントがオフライン状態であることが原因として考えられます。詳細については、修正後に手動検証が応答しない理由に関するセクションをご参照ください。

  • データ同期の遅延： 脆弱性を無視した後、または修正を完了した後、コンソールの表示に遅延が発生する場合がありますが、これは正常です。自動同期をお待ちいただくか、手動で検証を実行してください。

• 意図的にサードパーティソフトウェアをインストールしていなくても、脆弱性が検出されるのはなぜですか?

  Security Center によって検出されるサードパーティソフトウェアの脆弱性は、システムイメージにプリインストールされたコンポーネントまたはその依存ライブラリに起因する可能性があり、お客様がソフトウェアをインストールしていなくても検出されることがあります。詳細については、新規購入した ECS インスタンスに脆弱性がある理由に関するセクションをご参照ください。脆弱性の詳細で影響の説明とファイルパスを確認し、アラートの原因となった特定のファイルを特定することを推奨します。誤検知であることが確認された場合、または評価後に修正が不要だと判断した場合は、その脆弱性を [無視] するか、脆弱性タイプに基づいてホワイトリストに追加できます。

• 脆弱性が修正済みとマークされ、理由が [ルールオフライン] と表示されるのはどういう意味ですか?

  ルールオフラインは、アプリケーションの脆弱性の処理理由の 1 つで、検出ルールが無効化され、その脆弱性がアプリケーションの脆弱性として識別されなくなることを示しています。その他の理由として、[Process Not Exist]、[Middleware Not Exist]、[Middleware Updated] などがあります。このステータスが表示された場合、お客様側での追加対応は不要です。

• /usr/share/doc ディレクトリで脆弱性が検出されるのはなぜですか? 修正後に同じ脆弱性が再び表示されますか?

  • /usr/share/doc の脆弱性の原因： このディレクトリ内のファイルは、主にシステムイメージに付属する基本コンポーネントのドキュメントまたはサンプルファイルです。これらのファイルに記載されているコンポーネントのバージョンが古く、脆弱性データベースの既知の脆弱性と一致するため、アラートが検知されます。これは正常な検出動作です。アラートを解消するには、コンポーネントのバージョンをアップグレードするか、実行時の実際のリスクがないことを確認した上で、ホワイトリストに追加してください。

  • 脆弱性の再発の原因： 脆弱性の修正は、現在のスキャンで検出されたバージョンにのみパッチを適用するものです。その後のシステムやアプリケーションの更新で新たな脆弱性が混入したり、設定が変更されたり、セキュリティのベストプラクティスに従わなかったりすると、新たな脆弱性レコードが検出される可能性があります。

  • 継続的な保護に関する推奨事項： 一度きりの修正に頼るのではなく、定期的に脆弱性スキャンを実行し、公式のセキュリティ情報を注視し、ベースラインチェックと組み合わせてシステムを強化することを推奨します。