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

同一サーバーで同じ脆弱性が複数回報告されるのはなぜですか？

Security Center は、実行中のプロセスインスタンスごとにアプリケーションの脆弱性を検出します。サーバー上で同じ脆弱性を持つ同一プロセスが複数インスタンス実行されている場合（例：異なるポートで動作する 2 つの Tomcat サービス）、それぞれ個別に報告されます。インストール済みだが実行されていないソフトウェアはスキャン対象外です。

Fastjson などの脆弱性のスキャン結果が異なるのはなぜですか？

Security Center は、ビジネスロジックが実行時に脆弱なコンポーネント（JAR パッケージなど）を呼び出した場合にのみ脆弱性を検出します。動的ロードモデルでは、各スキャン時にアクティブなコンポーネントが異なるため、結果が変動します。

エージェントがオフラインになった後も、コンソールに脆弱性レコードが表示されるのはなぜですか？

Security Center はエージェントがオフラインになっても脆弱性レコードを保持しますが、これらのレコードは古くなり、修正・検証・クリアができなくなります。古くなるまでの期間は以下のとおりです。

脆弱性スキャンや緊急脆弱性の概念実証 (POC) 検証は業務システムに影響を与えますか？

通常は影響しません。POC 検証では、攻撃や破壊的な操作を行わず、無害なプローブリクエストを 1～2 回送信するだけです。ただし、ターゲットアプリケーションが予期しない入力に対して極めて脆弱な場合は、最小限のリスクが存在する可能性があります。

脆弱性スキャン時にメモリ不足 (OOM) エラーが発生するのはなぜですか？

エージェントには 200 MB のメモリ制限があります。スキャンがこの制限を超えると、OOM メカニズムにより検出プロセス (ALiSecCheck) が終了されます。

これは正常な動作であり、システム全体のメモリ不足とは無関係です。この制限は cgroup aegisRtap0 によって管理されています。OOM エントリは dmesg ログに記録されます。特別な対応は不要です。

脆弱性スキャンの範囲はどのようなものですか？

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

Security Center が検出可能な脆弱性の一覧を確認する方法を教えてください。

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

2. 左側のナビゲーションウィンドウで、リスクガバナンス > 脆弱性管理 を選択します。

3. 概要セクションで、すでにサポートされている脆弱性 の統計カードを見つけ、総件数をクリックして、検出可能なすべての脆弱性とその詳細を表示します。

Security Center は Elasticsearch などのサービスの脆弱性検出をサポートしていますか？

はい。コンソールの アプリケーションの脆弱性 ページで検出結果を確認できます。

Security Center は脆弱性データベースにまだ含まれていない CVE 脆弱性についてアラートを送信しますか？

Security Center は、脆弱性データベースにすでに含まれている既知の脆弱性についてのみアラートを送信します。CVE が公式に開示またはデータベースに登録されていない場合、システムはリスクを識別できず、アラートを送信しません。脆弱性がパッチとともに公開されているにもかかわらず検出されない場合は、手動での修正または緩和策がすでに適用されているかどうかを確認してください。Alibaba Cloud のセキュリティアドバイザリに従うことを推奨します。脆弱性が公式に開示され、ベンダーがパッチをリリースすると、Security Center は検出ルールを更新します。

ルール調整後の最新の脆弱性ルール分類はどこで確認できますか？

一部の脆弱性ルールは誤検知のためアプリケーションの脆弱性カテゴリから除外され、システムの脆弱性として再分類される場合があります。脆弱性管理 ページの サポート対象脆弱性 一覧で最新の分類を確認できます。

Security Center は Ubuntu 24.04 をサポートしていますか？脆弱性を手動でスキャンする方法を教えてください。

Security Center は手動での脆弱性スキャンをサポートしています。一般的な Linux ディストリビューションは概ねサポートされています。スキャンするには、コンソールにログインし、リスクガバナンス > 脆弱性管理 に移動し、左上隅でリージョンを選択してから、今すぐスキャン をクリックし、脆弱性タイプを選択します。または、ホストアセット ページで対象サーバーを選択し、セキュリティチェック の下にある脆弱性スキャンオプションを使用します。特定の OS バージョンのサポート状況については、コンソール内の実際のスキャン結果をご参照ください。

Security Center とサードパーティのセキュリティソフトウェア (火絨など) で検出結果が異なるのはなぜですか？

Security Center は主に公式の Windows システムパッチ（累積更新プログラム KBxxxxx など）を検出しますが、火絨などのサードパーティのセキュリティソフトウェアはこれらのシステムレベルのパッチをカバーしていないか、異なる検出戦略を採用している可能性があります。結果の違いは正常です。

非アクティブなインスタンスに高リスク脆弱性のアラートが表示されるのはなぜですか？

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

• レガシーアセット（完全にリリースされていないインスタンスまたはスナップショット）。

• 関連リソースのリスク（OSS、RDS などのクラウドプロダクトの構成上の弱点）。

• データ同期の遅延。

アラートステータスが Passed と表示されている場合は、アクティブなリスクは存在せず、無視しても問題ありません。

「実リスク脆弱性のみ表示」トグルを無効にした後、過去の脆弱性が表示され、セキュリティスコアが変化するのはなぜですか？

アプリケーションの脆弱性は以前にスキャンされていたものの、トグルが有効だったため表示されていませんでした。トグルを無効にすると過去の脆弱性が表示され、セキュリティスコアが更新されます。スコアはその後一定時間経過後に再度更新されます。

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

いいえ。Security Center は現在有効な脆弱性データ（過去 30 日以内に検出された脆弱性）のみを保持します。各スキャンは、現在のアセット状態に基づいた独立した検出です。有効期限が切れたりクリアされたりした過去の脆弱性レコードは再読み込みされません。

Security Center の脆弱性スキャン結果で、アクティブスキャンとパッシブ検出を区別する方法を教えてください。

スキャン結果で Web Scanner とマークされているエントリはアクティブスキャン（パブリック IP 経由でプローブリクエストを送信して検証）によるものであり、修正を優先する必要があります。Software Composition Analysis とマークされているエントリはパッシブ検出（エージェント経由でローカルに収集したソフトウェアバージョン情報を比較）によるものです。

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

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

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

はい。スキャン完了後、結果はコンソールのアセット詳細ページで自動的に更新（上書き）されます。リスクガバナンス > 脆弱性管理 に移動するか、右上隅の タスク管理 をクリックして、スキャンタスクの実行ステータスを確認できます。

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

最も一般的な原因は、ご利用のエディションがワンクリック修正をサポートしていないことです。Basic Edition および Anti-virus Edition にはこの機能がありません。脆弱性修正 付加価値サービス (VAS) を購入するか、Enterprise Edition または Ultimate Edition にアップグレードしてください。

ご利用のエディションがワンクリック修正をサポートしている場合は、サーバー側の問題を確認してください。

Linux

Windows

アプリケーションの脆弱性をワンクリック修正できないのはなぜですか？

システムの脆弱性（Linux ソフトウェアおよび Windows システムの脆弱性）は、標準化された修正パスを持つ OS コンポーネント内に存在するため、ワンクリック修正が可能です。

アプリケーションの脆弱性は、ユーザーがデプロイしたコードまたはサードパーティソフトウェア内に存在します。修正はビジネスロジックに依存するため、手動で修正する必要があります。

サーバーに多数の脆弱性が検出されるのはなぜですか？

古いソフトウェアは新たな攻撃手法が出現するにつれて脆弱性が蓄積されます。最高優先度のリスクに集中するには、エクスプロイト可能な脆弱性のみ表示 トグルを有効にしてください。

脆弱性修正時に「権限取得に失敗しました」というエラーが発生した場合はどうすればよいですか？

修正に必要なファイルの所有者が root ではありません。

1. Security Center で脆弱性の詳細を確認し、対象ファイルとそのパスを特定します。

2. サーバーにログインし、ファイル所有者を root に変更します。

3. Security Center コンソールに戻り、修正を再試行します。

バッチ処理で脆弱性を修正する順序はどのようになっていますか？

Linux ソフトウェアの脆弱性および Web-CMS の脆弱性は、コンソールリストに表示されている順序で修正されます。

前提となるパッチを必要とする Windows システムの脆弱性は最初に修正されます。残りの脆弱性は、コンソールリストに表示されている順序で修正されます。

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

これは、修正前に GRUB ブート順序が手動で変更されていた場合に発生します。システム修正スクリプトは、新しくインストールされたカーネルをデフォルトのブートアイテムとして自動的に設定できません。

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

この解決策では、元のカスタム GRUB 構成を破棄し、システムに新規カーネルのデフォルト設定を適用させます。

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

2. 次のコマンドを実行します。

      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 タブに 再起動が必要 タグが付いている場合は、再起動が必要です。

自動修正では通常サーバーがシャットダウンすることはありませんが、一部のカーネル脆弱性の修正では再起動が必要になる場合があります。オフピーク時間帯に操作を行い、修正前にスナップショットを作成することを推奨します。

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

主な原因は以下の 2 つです。

• エージェントがオフライン：ロールバック操作は Security Center エージェントがオンラインであることを前提としています。エージェントがオフラインの場合、コマンドを配信できません。まずエージェントの接続性の問題をトラブルシューティングし、解決してください。

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

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

• 権限のない RAM ユーザー：RAM ユーザーにスナップショット作成権限がありません。この操作には Alibaba Cloud アカウントを使用してください。RAM ユーザーの概要。

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

Security Center はサポート終了 (EOL) したオペレーティングシステムの脆弱性スキャンおよび修正をサポートしていますか？

サポート終了 (EOL) した OS バージョン（例：CentOS 7.6）については、Security Center は脆弱性スキャンおよびワンクリック修正をサポートしていません。脆弱性が検出されない場合は、ご利用の OS バージョンがサポート対象範囲内かどうかを確認してください。サポート対象外の場合は、サポート対象の OS バージョンにアップグレードするか、リスクを評価した上でコンソールで脆弱性を 無視 としてマークすることを推奨します。

1 台のサーバーに複数のサービスをデプロイしている場合、OS 脆弱性の影響範囲はどのようになりますか？

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

脆弱性を修正した後、サーバーを再起動する必要がありますか？業務への影響はありますか？

• Windows システムの脆弱性：パッチを有効にするにはサーバーの再起動が必要です。再起動により一時的なサービス中断が発生します。オフピーク時間帯に操作を行い、ロールバック用に スナップショットの自動作成と修復 を選択することを推奨します。

• Linux カーネルの脆弱性：再起動が必要です。修正後もステータスが Fixed and Pending Restarted のままの場合は、コンソールで Restart をクリックするか、サーバーを手動で再起動し、その後 認証 をクリックします。

• Linux ソフトウェアの脆弱性：通常は再起動不要ですが、脆弱性アドバイザリに 再起動が必要 と明記されている場合は例外です。

• 特定の CVE の例：CVE-2024-57979 の場合、コンソールに再起動が必要との表示がない場合は、再起動は不要です。

• 業務への影響：再起動によりサービスが中断し、修正プロセス中にリソースを消費して動作が遅くなる可能性があります。バックアップ（スナップショット）を作成し、テスト環境で事前に検証することを推奨します。

高リスク脆弱性（Linux カーネル ptrace など）を修正しない場合のリスクは何ですか？

• リスク：CVSS 7.8 などの高リスクのローカル権限昇格脆弱性は、攻撃者によって悪用され、機密ファイル（/etc/shadow、SSH 秘密鍵など）が盗まれ、root アクセスを取得され、サーバーが完全に侵害される可能性があります。

• 緩和策：即時修正が不可能な場合は、セキュリティグループでアクセスを制限し、モニタリングを強化してください。ただし、根本的な修正は依然としてパッチ適用です。

• SSL/TLS 脆弱性の場所：CVE-2016-2183 などの SSL/TLS 情報開示脆弱性については、ドメインに対して PING を実行して IP を解決し、CLB/K8s リソースを使用して影響を受けるノードを特定し、手動で修正できます。

Security Center による Windows パッチの自動修正と、手動でのダウンロードおよびインストールの効果は同じですか？

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

Security Center は脆弱性スキャンレポートの生成およびエクスポートをサポートしていますか？

• アプリケーションの脆弱性レポート：従量課金版では、アプリケーションの脆弱性スキャンをサポートするために 包括的ホスト保護 以上にアップグレードする必要があります。コンソールで リスクガバナンス > 脆弱性管理 > アプリケーションの脆弱性 に移動して、一覧を表示およびエクスポートできます。Web サイト URL ごとの個別のレポートはサポートされていません。

• 特定の ECS インスタンスの脆弱性：アセットセンター > ホストアセット に移動し、対象サーバーを検索して詳細ページに入り、Vulnerability Details > アプリケーションの脆弱性 をクリックして表示およびエクスポートします。

• レポートソースの検証：スキャンツール フィールドに Alibaba Cloud Security Center と表示され、レポートタイプに ホスト脆弱性スキャン が含まれていることを確認します。

• 高リスク脆弱性レポート（Nacos など）：コンソールの セキュリティ管理 モジュールで管理イベントを確認します。

特定の CVE に対してご利用の Linux カーネルバージョンが影響を受けるかどうかを判断する方法を教えてください。

1. uname -r を実行して現在のカーネルバージョンを確認し、CVE アドバイザリの影響バージョン範囲と比較します。

2. 例：CVE がカーネルバージョン 4.14～6.18.21 および 6.19.11 に影響を与える場合、現在のバージョンが 3.10.0 であれば、サーバーは影響を受けません。

3. Alibaba Cloud 公式脆弱性リスクおよび修正アナウンスページで、具体的な影響の詳細を確認します。

バッチ脆弱性修正の実行順序と同時実行に関するアドバイスを教えてください。

• 実行順序：Linux ソフトウェアの脆弱性はコンソールリストの順序で修正されます。Windows システムの脆弱性は、前提となるパッチを優先して修正します。

• 同時実行：リソース競合を避けるため、前のバッチが完了してから次のバッチを開始してください。

• UI が応答しない：UI に コマンド送信中 と表示されても応答がない場合は、表示遅延の可能性があります。ページを手動で更新して 修正中 ステータスを確認してください。

• 所要時間：Linux 自動修正は、脆弱性の件数、サーバーのパフォーマンス、ネットワーク状況に応じて、数分から数十分程度かかります。時間がかかりすぎる場合は、ディスク領域（3 GB 以上を推奨）、パッケージマネージャの競合、権限の問題を確認してください。

パブリック IP アドレスを持たないサーバーの脆弱性修正を Security Center はサポートしていますか？

はい。サーバーに Security Center エージェントがインストールされており、ネットワーク接続が正常であれば、脆弱性修正をサポートします。Alibaba Cloud 内部ソースを使用する場合は、パブリック IP は不要です。前提条件として、Security Center サービスが有効化されており、エージェントがオンラインである必要があります。

自動脆弱性修正を有効にする際の考慮事項は何ですか？

• デフォルトでは有効化されない：自動修正は、手動でポリシーを構成してから有効になります。

• 範囲の制限：非カーネルの Linux システムの脆弱性のみをサポートし、ワンクリック修正機能に依存します（エディションのサポートが必要）。

• 推奨事項：まずテスト環境で検証してください。スナップショットバックアップポリシーを構成することを確認します。オフピーク時間帯にスケジュールしてください。すべてのアセットで有効化すると修正クォータを過剰に消費する可能性があるため、避けてください。

脆弱性を修正したのに、Security Center に依然として報告されるのはなぜですか？

特に Linux カーネルの脆弱性など、再起動が必要な脆弱性があります。脆弱性詳細ページで Restart をクリックします。再起動後、認証 をクリックします。ステータスが Fixed and Pending Restarted と表示されている場合、修正は成功しています。

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

これは正常な動作です。Windows のセキュリティ更新プログラムは累積的です。つまり、毎月のパッチにはそれまでのすべての修正が含まれています。Security Center が最新の累積更新プログラムを検出すると、その更新プログラムに含まれるすべての古い脆弱性を修正済みとしてマークします。

特定の古い脆弱性がカバーされているかどうかを確認するには、公式の Microsoft パッチ Web サイトにアクセスし、最新インストール済みパッチの KB 番号で検索します。パッケージの詳細を確認してカバー範囲を検証してください。

脆弱性を修正した後も「未修正」と表示されるのはなぜですか？

考えられる原因は以下の 3 つです。

1. 検証の遅延：手動で修正した後は、認証 をクリックして即時スキャンをトリガーしてください。ステータスの更新には数分かかります。

2. コンソールキャッシュ：ページを強制リフレッシュするか、数分待ってください。

3. 修正が不完全：修正が完全に成功していないか、複数の脆弱性パスがあり、そのうち 1 つだけが修正された可能性があります。修正手順を再度確認してください。

Security Center は「修正済み、再起動待ち」状態の脆弱性を自動的に検証できますか？

いいえ。セキュリティセンター コンソールから、または手動でサーバーを再起動してから、認証 をクリックして、修正が成功したかどうかを確認してください。

脆弱性を修正した後に手動で検証しても応答がないのはなぜですか？

考えられる原因は以下の 2 つです。

• スキャンレベルが構成されていない：Security Center は、脆弱性管理の設定 で選択された重大度レベルの脆弱性のみを更新します。スキャンレベルが対象脆弱性をカバーしていることを確認してください。

• エージェントがオフライン：認証 機能には、コンソールとエージェント間のライブ接続が必要です。エージェントがオフラインの場合は、まず接続性の問題を解決してから再試行してください。

脆弱性修正が失敗した後の失敗通知を確認する方法を教えてください。

確認方法：Security Center コンソールの 脆弱性管理 ページで、修正中の脆弱性 の下の数字をクリックします。修正中の脆弱性 パネルで、失敗した脆弱性を見つけ、ステータス 列のアイコンをクリックして、原因の詳細 ダイアログボックスで失敗通知を確認します。

通知内容：失敗通知には、修正失敗の具体的な理由、該当するエラーコード（利用可能な場合）、および推奨されるアクションが表示されます。

修正失敗通知のエラーコードに対処する方法を教えてください。

失敗通知に表示された特定のエラーコードについて、脆弱性修正失敗の原因をトラブルシューティングする ドキュメントに記載された解決策に従ってください。

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

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

カーネルをアップグレードした後も Security Center にカーネルの脆弱性が報告されるのはなぜですか？

1. カーネルがアップグレードされていることを確認します。 次のコマンドを実行して実行中のカーネルバージョンを確認し、脆弱性詳細の要件を満たしていることを検証します。システムが新しいカーネルを使用して起動していることを確認します。

      uname -av
      cat /proc/version

      cat /etc/grub.conf

2. 古いカーネルパッケージを削除します。 インストール済みのすべてのカーネルパッケージを一覧表示し、古いバージョンを特定します。古いカーネルパッケージをアンインストールします。または、ディストリビューション推奨の方法を使用します。CentOS/Red Hat の場合：

   重要

   古いカーネルパッケージを削除する前に、Elastic Compute Service コンソールで現在のインスタンスのスナップショットまたはイメージを作成してください。

      rpm -qa | grep kernel

      rpm -e kernel-<old_version_number>

      yum remove kernel-<old_version_number>

3. アラートを無視します（オプション）。 実行中のカーネルがすでに脆弱性を修正している場合は、アラートを無視できます。

   1. Log on to the Security Center コンソール.

   2. 左側のナビゲーションウィンドウで、リスクガバナンス > 脆弱性管理 を選択します。コンソール左上隅で、アセットがデプロイされているリージョンを選択します：Chinese Mainland または Outside Chinese Mainland。

   3. Linux Software Vulnerability タブで、脆弱性を見つけ、その名前をクリックします。

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

Ubuntu カーネルを手動で更新する方法を教えてください。

以下の例では、Ubuntu 14.04 のカーネル 3.1* をカーネル 4.4 に更新します。

1. 現在のカーネルバージョンが 3.1* であることを確認します。

      uname -av

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

      dpkg -l | grep linux-image

カーネルの脆弱性を修正する際にカーネルの互換性エラー通知が表示された場合はどうすればよいですか？

症状：Security Center コンソールでカーネルの脆弱性のワンクリック修正を実行した後、修正が失敗し、失敗通知にカーネルの互換性エラーが表示されます。

原因：サーバーのカーネルバージョンが、対象の修正バージョンと互換性がないためです。これは、カーネルが手動で変更された場合、非標準バージョンを使用している場合、またはバージョンギャップが大きすぎて通常のアップグレードができない場合に発生します。

解決策

解決策 1：強制修正を使用する

ワークロードに影響がないことを確信している場合は、互換性チェックをバイパスして強制修正を使用できます。

1. 失敗通知ダイアログを閉じます。

2. Unhandled Vulnerabilities セクションで、対象サーバーの 操作する 列の Fix をクリックします。

3. 表示されるダイアログボックスで、Mandatory Fix チェックボックスをオンにします。

4. 修正方法を選択し、Fix Now をクリックします。

   重要

   強制修正はクライアントの互換性チェックをバイパスするため、リスクが発生する可能性があります。ロールバック機能を維持するために、スナップショットの自動作成と修復 を選択することを推奨します。

5. Fix Now をクリックします。

解決策 2：カーネルを手動で更新する

強制修正が適切でない場合は、Ubuntu カーネルを手動で更新する方法を教えてください。 を参照して手動アップグレード手順を実施してください。

強制修正はいつ使用できますか？リスクは何ですか？

使用タイミング：強制修正は以下のケースに適用されます。

• ワンクリック修正がカーネルの互換性エラーにより失敗した場合。

• システム環境が修正要件を満たしていることを確信しているが、互換性チェックが通過しなかった場合。

使用方法：修正ダイアログボックスで Mandatory Fix チェックボックスをオンにします。

リスク：強制修正は互換性チェックをバイパスするため、以下のような問題が発生する可能性があります。

• 修正後の互換性の問題により、業務が中断される可能性があります。

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

推奨事項：強制修正を使用する前に、スナップショットの自動作成と修復 を選択して、迅速にロールバックできるようにしてください。ワークロードに影響がないことを確信している場合にのみ、強制修正を使用してください。

脆弱性に利用可能な更新がないと表示された場合はどうすればよいですか？

公式パッチが利用不可

更新コマンドが already installed and latest version または No Packages marked for Update などのメッセージを返す場合、公式の更新ソースがパッチをリリースしていません。Gnutls、Libnl、MariaDB などのパッケージに影響する可能性があります。公式のソフトウェアソースが更新をリリースするのをお待ちください。

OS バージョンがサポート終了 (EOL)

ソフトウェアパッケージが現在のシステムでサポートされている最新バージョンであるにもかかわらず、修正要件を満たしていない場合、OS バージョンが EOL（例：CentOS 6.x）になっている可能性があります。以下のいずれかの選択肢があります。

• 公式サポート期間内の OS バージョンにアップグレードします。

• リスクを評価し、管理可能であることを確認した後、Security Center コンソールで脆弱性を無視します。

Alibaba Cloud Yum ソースへの接続でタイムアウトが発生した場合はどうすればよいですか？

接続がタイムアウトすると、次のようなエラーが表示されます。

[Errno 12] Timeout on http://mirrors.aliyun.com/centos/6/os/x86_64/repodata/repomd.xml: (28, 'connect() timed out!')

1. DNS 解決が機能しているかどうかを確認します。ping mirrors.aliyun.com または nslookup mirrors.aliyun.com を実行します。

2. ネットワークアクセスが正常な場合は、しばらく待ってから再試行します。タイムアウトは、一時的なネットワークの不安定やミラーソースのトラフィック増加が原因で発生する可能性があります。

Windows の脆弱性パッチパッケージをクライアントディレクトリからクリアする方法を教えてください。

ワンクリック修正後、エージェントは自動的にパッチパッケージをダウンロード、インストール、および削除します。

3 日経過してもパッチが残っている場合は、手動でクリアします。

1. Log on to the Security Center コンソール.

2. 左側のナビゲーションウィンドウで、システム設定 > 機能の設定 を選択します。コンソール左上隅で、アセットがデプロイされているリージョンを選択します：Chinese Mainland または Outside Chinese Mainland。

3. クライアント自己保護が有効になっている場合は、アセットセンター のサーバー詳細ページで、クライアント保護 トグルをオフにします。

   説明

   クライアント自己保護は、Windows サーバーのエージェントディレクトリにあるプロセスファイルの削除またはダウンロードリクエストをブロックします。クライアント自己保護を有効にしていない場合は、この手順をスキップしてください。

4. 管理者権限で Windows サーバーにログインし、次のディレクトリからパッチパッケージを削除します。

   重要

   デフォルトのパッチパッケージパスは C:\Program Files (x86)\Alibaba\Aegis\globalcfg\hotfix です。

5. （オプション）サーバー詳細ページで、クライアント保護 をオンにします。

Security Center のスキャン結果で脆弱性パスが「なし」と表示される場合は対応が必要ですか？

これは通常、脆弱性が検出されたが特定のファイルパスを特定できなかったことを示します。これは正常な動作であり、特別な対応は不要です。

Security Center の脆弱性修正リソースパッケージは自動的にサブスクライブされますか？それとも手動で有効化する必要がありますか？

ユーザーはコンソールで手動で取得する必要があります。デフォルトでは自動的にサブスクライブまたは有効化されません。

侵入テストおよび脆弱性スキャン申請に関するよくある質問

• 申請送信失敗：スキャンを開始するマシンの実際のパブリックソース IP アドレスのみを入力し、スキャン対象サーバーの IP アドレスを入力しないでください。

• IP 追加時に「自分のアセットではありません」と表示される：通常、この IP は別の Alibaba Cloud アカウントに属しています。IP を所有するアカウントに切り替え、そのアカウントから申請を送信してください。

• サードパーティスキャンツールの構成：セキュリティ管理プラットフォームでサードパーティスキャンツールの IP をホワイトリストに追加し、侵入テスト申請を送信してください。

有料サービスをキャンセルした後も定期スキャンの課金が継続するのはなぜですか？

従量課金機能がまだ有効になっている可能性があります。解決策：

1. Log on to the Security Center コンソール.

2. 左側のナビゲーションウィンドウで、概要 を選択して概要ページに移動します。

3. ページ右上隅の Pay-as-you-go セクションで、以下の操作が可能です。

   • 特定のサービスを無効化：対応するサービスのスイッチをオフにして、そのサービスの課金を停止します。

   • すべてのサービスを一度に無効化：ページ右上隅の すべての従量課金サービスを無効化 ボタンをクリックして、すべての従量課金機能を一度に無効化します。

4. 未払い残高を精算して、他のサービスへの影響を防いでください。

ActionTrail で Security Center の操作ログをクエリする方法を教えてください。

ActionTrail コンソール - Security Center イベント で ActionTrail コンソールを使用します。データが返されない場合は、ActionTrail コンソールのリージョン設定を確認してください。リソースが配置されているリージョン（例：上海）に切り替えてください。操作ログは異なるリージョンに保存されている場合があります。

CVE-2019-14439 緊急脆弱性の検出パスにコンテナ環境が表示されないのはなぜですか？

問題：CVE-2019-14439 緊急脆弱性の検出パスにコンテナ環境が表示されません。パスは /skywalking/oap-libs/jackson-databind-2.9.5.jar です。サーバー上で見つかった環境はコンテナ環境ですが、ローカル環境には Jackson ライブラリが含まれていません。一方、Spring Framework JDK >= 9 リモートコード実行脆弱性（同様に緊急脆弱性）はコンテナ内に存在すると表示されます。

回答：検出スクリプトは脆弱性タイプによって異なります。コンテナ環境をスキャンする必要があるシナリオでは、アプリケーションの脆弱性スキャンツールの使用を推奨します。

Windows 月次パッチで修正された CVE をクエリする方法を教えてください。

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

2. 左側のナビゲーションウィンドウで、リスクガバナンス > 脆弱性管理 を選択し、Windows System Vulnerability タブを選択して、クエリしたいパッチ番号（例：パッチ 5043050）を取得します。

3. Microsoft パッチリンクにアクセスし、末尾のパッチ番号をクエリしたいものに置き換えます。例：https://support.microsoft.com/help/5043050

4. 開いたページで、xx 月 xx 日セキュリティ更新プログラム をクリックして、その KB パッケージで修正された CVE の一覧を表示します。

5. CVE 一覧を Security Center の 脆弱性番号 列に表示されている CVE 一覧と比較して、整合性を確認します。