トラブルシューティング

この章は、次のセクションで構成されています。

FDM による管理デバイスのトラブルシューティング

次の項目を使用して、FDM による管理デバイスのトラブルシューティングを行います。

登録キーを使用したオンボーディング中にデバイス登録の問題のトラブルシューティングを実行する
FDM による管理 HA 作成のトラブルシュート

エグゼクティブサマリーレポートのトラブルシュート

ネットワーク運用レポートを作成しようとしても、期待どおりの結果が表示されない場合や、データがまったく表示されない場合があります。場合によっては、サマリーに「使用可能なデータがありません（No data available）」と表示されることがあります。次のシナリオを考えます。

Security Cloud Control は、デバイスがオンボーディングされてから 1 時間ごとにイベントをポーリングします。一部のスケジュール済みイベントは、10 分ごと、60 分ごと、6 時間ごと、または 24 時間ごとのさまざまな時間間隔でポーリングされる複数のジョブをトリガーできます。選択したデバイスがオンボーディングされたばかりの場合、データを収集してコンパイルする十分な時間がない可能性があります。
スマートライセンスが不足している可能性があります。十分なライセンスのあるデバイスのみがデータを生成します。「FDM による管理デバイスのライセンスタイプ」を参照して、目的のデータの生成に必要なスマートライセンスを確認してください。
アクセス制御ルールのロギングが有効になっていません。詳細については、FDM による管理アクセスコントロールルールのロギング設定を参照してください。
選択した時間範囲に関して表示するデータの量が不足しているか、選択した時間範囲の間にアクセス制御ルールがトリガーされていない可能性があります。[時間範囲（Time Range）] オプションを切り替えて、別の期間がレポートに影響しているかどうかを判断します。

FDM 管理対象デバイスのオンボーディングのトラブルシュート

接続性

ping でデバイスの接続を確認します。ASA から直接 FP 管理 IP アドレスに ping を実行してみてください。ICMP が外部からの通信をブロックする場合、インターネットから FP 管理インターフェイスに対して ping を実行できません。 cUrl または wget を使用すると、設定された IP やポートで FP 管理インターフェイスにアクセスできるかどうかを確認できます。
ASA/ASDM ソフトウェアバージョンの互換性の確認詳細については、「Security Cloud Control でサポートされるソフトウェアとハードウェア」を参照してください。
ASA ログを使用して、Security Cloud Control トラフィックが ASA によってブロックされているかどうかを判断します。SSH を介して FP HTTP 管理インターフェースへの接続を試みると、/var/log/httpd/httpsd_access_log にログが記録されます。

モジュールの不良構成

サポートされない構成。モジュールが特定の要件を満たしていない場合、Security Cloud Control はデバイス構成をサポートできない場合があります。

HTTP Authentication

Security Cloud Control は、オンボーディングプロセス中に ASA デバイスを認証するためにトークンベースの SSO を発行します。マルチコンテキストモードの ASA の場合、管理コンテキスト以外から FP モジュールをオンボードしようとすると、トークンの問題が発生する可能性があります。無効なトークンは、/var/log/mojo/mojo.log a で ASDM SSO ログインとして識別されます。

ライセンス不足のために失敗

デバイスの接続ステータスに [ライセンスが不足しています（Insufficient License）] と表示される場合は、以下の手順を実行します。

デバイスがライセンスを取得するまでしばらく待ちます。通常、Cisco Smart Software Manager が新しいライセンスをデバイスに適用するには時間がかかります。
デバイスのステータスが変わらない場合は、Security Cloud Control からサインアウトしてから再度サインインすることで Security Cloud Control ポータルを更新して、ライセンスサーバーとデバイスとの間のネットワーク通信の不具合を解決します。
ポータルを更新してもデバイスのステータスが変更されない場合は、次の手順を実行します。

手順

ステップ 1	Cisco Smart Software Manager から新しい登録キーを生成し、コピーします。詳細については、スマートライセンスの生成に関するビデオをご覧ください。
ステップ 2	左側のペインで [インベントリ（Inventory）] ページをクリックします。
ステップ 3	[デバイス] タブをクリックします。
ステップ 4	適切なデバイスタイプのタブをクリックし、ステータスが [ライセンスが不足しています（Insufficient License）] のデバイスを選択します。
ステップ 5	[デバイスの詳細（Device Details）] ペインで、 [ライセンスが不足しています（Insufficient License）] に表示される [ライセンスの管理（Manage Licenses）] をクリックします。[ライセンスの管理（Manage Licenses）] ウィンドウが表示されます。
ステップ 6	[アクティブ化（Activate）] フィールドで、新しい登録キーを貼り付けて [デバイスの登録（Register Device）] をクリックします。

新しい登録キーがデバイスに正常に適用されると、接続状態が [オンライン（Online）] に変わります。

登録解除されたデバイスのトラブルシュート

FDM による管理デバイスが、Firewall Device Manager 経由でクラウドから登録解除されていることがあります。

以下の手順を実行して、デバイスをクラウドに再登録します。

手順

ステップ 1	[インベントリ（Inventory）] ページで [デバイス（Devices）] タブをクリックします。
ステップ 2	[FTD] タブをクリックし、[デバイスの登録が解除されました（Device Unregistered）] 状態のデバイスを選択し、右側でエラーメッセージを確認します。
ステップ 3	登録解除されたデバイスが登録キーを使用してオンボーディングされた場合、以前に適用されたキーの有効期限が切れているため、Security Cloud Control は新しい登録キーを生成するように求めます。 [更新（Refresh）] ボタンをクリックして新しい登録キーを生成し、コピーアイコンをクリックします。 Security Cloud Control に再登録するデバイスの Firewall Device Manager にログインします。 [システム設定（System Settings）] で、[クラウドサービス（Cloud Services）] をクリックします。 Security Cloud Control 領域で、[始める（Get Started）] を展開します。 [登録キー（Registration Key）] フィールドに、Security Cloud Control で生成した登録キーを貼り付けます。 [登録（Register）] をクリックし、[シスコの開示情報を受け入れる（Accept the Cisco Disclosure）] をクリックします。Firewall Device Manager により登録要求が Security Cloud Control に送信されます。デバイスの接続状態が [読み取りエラー（Read Error）] に変わるまで、Security Cloud Control の [インベントリ（Inventory）] ページを更新します。 Security Cloud Control の [設定の読み取り（Read Configuration）] をクリックして、デバイスから設定を読み取ります。
ステップ 4	登録解除されたデバイスがシリアル番号を使用してオンボーディングされた場合、Security Cloud Control は Firewall Device Manager からデバイスを自動登録するように求めます。 Security Cloud Control に再登録するデバイスの Firewall Device Manager にログインします。 [システム設定（System Settings）] で、[クラウドサービス（Cloud Services）] をクリックします。 [CDOからテナントへの自動登録（Auto-enroll with Tenancy from Security Cloud Control）] オプションを選択して [登録（Register）] をクリックします。デバイスの接続状態が [読み取りエラー（Read Error）] に変わるまで、Security Cloud Control の [インベントリ（Inventory）] ページを更新します。 Security Cloud Control の [設定の読み取り（Read Configuration）] をクリックして、デバイスから設定を読み取ります。

登録キーを使用したオンボーディング中にデバイス登録の問題のトラブルシューティングを実行する

クラウドサービスの FQDN を解決できない

クラウドサービスの FQDN の解決に失敗したためにデバイスの登録が失敗した場合は、ネットワーク接続または DNS 構成を確認して、デバイスのオンボーディングを再試行してください。

無効な登録キーのために失敗する

無効な登録キーが原因でデバイスの登録に失敗した場合、Firewall Device Manager に間違った登録キーを貼り付けている可能性があります。

同じ登録キーを Security Cloud Control から再度コピーして、デバイスの登録を試行します。デバイスにすでにスマートライセンスがある場合は、Firewall Device Manager に登録キーを貼り付ける前にスマートライセンスを削除してください。

ライセンス不足のために失敗する

デバイスの接続ステータスに [ライセンスが不足しています（Insufficient License）] と表示される場合は、以下の手順を実行します。

デバイスがライセンスを取得するまでしばらく待ちます。通常、Cisco Smart Software Manager が新しいライセンスをデバイスに適用するには時間がかかります。
デバイスのステータスが変わらない場合は、Security Cloud Control からサインアウトしてから再度サインインすることで Security Cloud Control ポータルを更新して、ライセンスサーバーとデバイスとの間のネットワーク通信の問題を解決します。
ポータルを更新してもデバイスのステータスが変更されない場合は、次の手順を実行します。
1. Cisco Smart Software Manager から新しい登録キーを生成し、コピーします。詳細については、スマートライセンスの生成に関するビデオをご覧ください。
2. Security Cloud Control ナビゲーションバーで、[インベントリ（Inventory）] ページをクリックします。
3. ステータスが [ライセンスが不足しています（Insufficient License）] のデバイスを選択します。
4. [デバイスの詳細（Device Details）] ペインで、 [ライセンスが不足しています（Insufficient License）] に表示される [ライセンスの管理（Manage Licenses）] をクリックします。[ライセンスの管理（Manage Licenses）] ウィンドウが開きます。
5. [アクティブ化（Activate）] フィールドで、新しい登録キーを貼り付けて [デバイスの登録（Register Device）] をクリックします。
新しい登録キーがデバイスに正常に適用されると、接続状態が [オンライン（Online）] に変わります。

侵入防御システムのトラブルシュート

IPS ポリシーのオプションは何ですか?

オンボーディングされたすべてのデバイスには、「デフォルトオーバーライド」と呼ばれる Security Cloud Control が提供する IPS ポリシーが自動的に関連付けられます。Security Cloud Control はすべての FDM による管理デバイスに対して新しい IPS ポリシーを生成するため、この名前のポリシーが複数存在する可能性があります。デフォルトの IP ポリシーを使用し、署名のオーバーライドオプションを変更する場合は、『Firepower 侵入ポリシーの署名のオーバーライド』を参照してください。デバイスごとに異なる署名オーバーライドを構成すると、デフォルトのオーバーライドポリシーに不整合が発生する可能性があることに注意してください。

すべてのデバイスに異なる IPS ポリシーを構成するにはどうすればよいですか?

Security Cloud Control はすべての FDM による管理デバイスに対して新しい IPS ポリシーを生成するため、この名前のポリシーが複数存在する場合があります。各デバイスのオンボーディング後に、Security Cloud Control が提供する IPS ポリシーの名前を変更する必要はありません。ポリシーを拡大すると、それに関連付けられているデバイスが表示されます。また、デバイスまたはポリシーごとに脅威イベントページと署名オーバーライドページをフィルタ処理することもできます。デフォルトのオーバーライドポリシーをカスタマイズするには、デバイスごとに署名のオーバーライドを構成します。これにより、デフォルトのオーバーライド侵入ポリシーに不整合が生じますが、これによって機能が阻害されることはありません。

FDM による管理デバイスからオーバーライドが構成されているデバイスをオンボーディングしました。

Security Cloud Control の外部で構成されたオーバーライドは、デバイスの構成または機能に問題を引き起こしません。

すでにオーバーライドが構成されているデバイスをオンボーディングし、この新しいデバイスがオーバーライドが構成されていないデバイスと IPS ポリシーを共有している場合、IPS ポリシー不整合として表示されます。不整合に対処するには、『Firepower 侵入ポリシーの署名のオーバーライド』のステップ 3 を参照してください。

SSL 暗号解読の問題のトラブルシューティング

復号再署名がブラウザでは機能するがアプリでは機能しない Web サイトの処理（SSL または認証局ピニング）

スマートフォンおよびその他のデバイス用の一部のアプリケーションでは「SSL（または認証局）ピニング」と呼ばれる手法が使用されます。SSL ピニング手法では、元のサーバー証明書のハッシュがアプリケーション自体の内部に埋め込まれます。その結果、アプリケーションが FDM による管理デバイスから再署名された証明書を受け取ると、ハッシュ検証に失敗し、接続が中断されます。

Web サイトのアプリケーションを使用してそのサイトに接続することができないにもかかわらず、Web ブラウザを使用する場合は、接続に失敗したアプリケーションを使用したデバイス上のブラウザでも接続できるというのが主な症状です。たとえば、Facebook の iOS または Android アプリケーションを使用すると接続に失敗しますが、Safari または Chrome で https://www.facebook.com/ を指定すると接続に成功します。

SSL ピニングは特に中間者攻撃を回避するために使用されるため、回避策はありません。次のいずれかの選択肢を使用する必要があります。

アプリケーションのユーザをサポートします。この場合は、サイトへのトラフィックを復号できません。[SSL復号（SSL Decryption）] ルールの [アプリケーション（Application）] タブで、サイトのアプリケーションの [復号しない（Do Not Decrypt）] ルールを作成し、そのルールが、接続に適用される [再署名の復号（Decrypt Re-sign）] ルールの前に適用されることを確認します。
ユーザにブラウザだけを使用させます。サイトへのトラフィックを復号する必要がある場合は、ネットワーク経由での接続にサイトのアプリケーションを使用できないため、ブラウザのみを使用しなければならないことをユーザーに通知する必要があります。

詳細

サイトがブラウザでは機能するのに同じデバイス上のアプリケーションでは機能しない場合は、ほぼ確実に SSL ピニングによるものと考えられます。ただし、詳しく調べる必要がある場合は、ブラウザのテストに加えて、接続イベントを使用して SSL ピニングを識別できます。

アプリケーションは、次の 2 つの方法でハッシュ検証の失敗に対処する場合があります。

グループ 1 のアプリケーション（Facebook など）は、サーバから SH、CERT、SHD メッセージを受け取るとすぐに SSL ALERT メッセージを送信します。アラートは、通常、SSL ピニングを示す「Unknown CA (48)」アラートです。アラートメッセージの後に TCP リセットが送信されます。イベントの詳細情報で次のような症状が見られます。
- SSL フローフラグには ALERT_SEEN が含まれます。
- SSL フローフラグには APP_DATA_C2S または APP_DATA_S2C は含まれません。
- SSL フローメッセージは、通常、CLIENT_HELLO、SERVER_HELLO、SERVER_CERTIFICATE、SERVER_KEY_EXCHANGE、SERVER_HELLO_DONE です。
グループ 2 のアプリケーション（Dropbox など）はアラートを送信しません。代わりに、ハンドシェイクが完了するまで待ってから TCP リセットを送信します。イベントで次のような症状が見られます。
- SSL フローフラグには ALERT_SEEN、APP_DATA_C2S または APP_DATA_S2C は含まれません。
- SSL フローメッセージは、通常、CLIENT_HELLO、SERVER_HELLO、SERVER_CERTIFICATE、SERVER_KEY_EXCHANGE、SERVER_HELLO_DONE、CLIENT_KEY_EXCHANGE、CLIENT_CHANGE_CIPHER_SPEC、CLIENT_FINISHED、SERVER_CHANGE_CIPHER_SPEC、SERVER_FINISHED です。

CA 証明書のダウンロードボタンが無効になっている

Security Cloud Control でステージングされているが、まだデバイスに展開されていない証明書（自己署名およびアップロード）のダウンロードボタンが無効になっています。証明書は、デバイスへの展開後のみダウンロードできます。

シリアル番号を使用した FDM による管理デバイスのオンボーディングのトラブルシューティング

プロビジョニングエラー
- デバイスパスワードが変更されていない
- デバイスパスワードがすでに変更されている

要求エラー

要求エラー

無効なシリアル番号

Security Cloud Control でデバイスを要求するときに、間違ったシリアル番号が入力されました。

解決策

Security Cloud Control で FDM による管理デバイスインスタンスを削除します。
正しいシリアル番号を入力して新しい FDM による管理デバイスインスタンスを作成し、デバイスを要求します。

デバイスのシリアル番号がすでに要求されている

シリアル番号を使用して FDM による管理デバイスをオンボーディングすると、次のエラーが発生します。

原因

このエラーは次のいずれかの理由で発生することがあります。

デバイスが外部ベンダーから購入された可能性があり、デバイスがそのベンダーのテナントにあります。
デバイスが、以前に他の地域にある別の Security Cloud Control インスタンスによって管理されていた可能性があり、そのクラウドテナントに登録されています。

対処法

デバイスのシリアル番号を他のクラウドテナントから登録解除した後に、テナントで再要求する必要があります。

前提条件

デバイスは、クラウドテナントに到達できるインターネットに接続されている必要があります。

外部ベンダーから購入したデバイス

外部ベンダーから購入したデバイスは、そのベンダーのクラウドテナントに登録されている可能性があります。

Security Cloud Control からデバイスインスタンスを削除します。
デバイスに FXOS イメージをインストールします。詳細については、『Cisco FXOS Troubleshooting Guide for the Firepower 1000/21000 with FTD』の「Reimage Procedures」の章を参照してください。
コンソールポートから FXOS CLI に接続します。
現在の管理者パスワードを使用して FXOS にログインします。
FXOS CLI で、local-mgmt に接続します。firepower # connect local-mgmt
コマンドを実行して、クラウドテナントからデバイスを登録解除します。firepower(local-mgmt) # cloud deregister
登録解除が成功すると、CLI インターフェイスは成功メッセージを返します。

例：firepower(local-mgmt) # cloud deregister Release Image Detected RESULT=success MESSAGE=SUCCESS 10, X-Flow-Id: 2b3c9e8b-76c3-4764-91e4-cfd9828e73f9

デバイスがクラウドテナントからすでに登録解除されている場合、CLI インターフェイスは、デバイスのシリアル番号がクラウドテナントに登録されていないことを示します。 RESULT=success MESSAGE=DEVICE_NOT_FOUND: Device with serial number JAD213082x9 is not registered with Security Services Exchange , X-Flow-Id: 63e48b4c-8426-48fb-9bd0-25fcd7777b99
デバイスのシリアル番号を入力して、Security Cloud Control でデバイスを再度要求します。詳細については、「デバイスのシリアル番号を使用した FDM 管理対象デバイスの導入準備」を参照してください。
デバイスに FDM による管理デバイスアプリケーション（バージョン 6.7 以降）をインストールします。ゼロタッチプロビジョニングがデバイス上で開始され、デバイスが Cisco Cloud に登録されます。デバイスは Security Cloud Control によってオンボーディングされます。

別の地域の別のクラウドテナントによってすでに管理されている FDM による管理デバイスのオンボーディング

デバイスが、以前に他の地域にある別の Security Cloud Control インスタンスによって管理されていた可能性があり、そのクラウドテナントに登録されています。

ケース 1：デバイスを所有するテナントにアクセスできる。

地域 1 の Security Cloud Control からデバイスインスタンスを削除します。
Firewall Device Manager で、[システム設定（System Settings）] > [クラウドサービス（Cloud Services）] ページに移動します。デバイスが Security Cloud Control から削除されたことを示す警告メッセージが表示されます。
をクリックし、ドロップダウンリストから [クラウドサービスの登録解除（Unregister Cloud Services）] を選択します。
警告を確認してから、[登録解除（Unregister）] をクリックします。
地域 2 の Security Cloud Control からデバイスを要求します。
Firewall Device Manager で、[システム設定（System Settings）] > [クラウドサービス（Cloud Services）]に移動し、[Security Cloud Controlからテナントへの自動登録（Auto-enroll with Tenancy from Cisco Defense Orchestrator）] オプションを選択して [登録（Register）] をクリックします。デバイスは、新しい地域に属する新しいテナントにマッピングされ、Security Cloud Control によってオンボーディングされます。

ケース 2：デバイスを所有するテナントにアクセスできない。

コンソールポートから FXOS CLI に接続します。
現在の管理者パスワードを使用して FXOS にログインします。
FXOS CLI で、local-mgmt に接続します。firepower # connect local-mgmt
コマンドを実行して、クラウドテナントからデバイスを登録解除します。firepower(local-mgmt) # cloud deregister
登録解除が成功すると、CLI インターフェイスは成功メッセージを返します。

例：firepower(local-mgmt) # cloud deregister Release Image Detected RESULT=success MESSAGE=SUCCESS 10, X-Flow-Id: 2b3c9e8b-76c3-4764-91e4-cfd9828e73f9

デバイスがクラウドから登録解除されます。
地域 2 の Security Cloud Control からデバイスを要求します。
Firewall Device Manager で、[システム設定（System Settings）] > [クラウドサービス（Cloud Services）]に移動し、[Security Cloud Controlからテナントへの自動登録（Auto-enroll with Tenancy from Cisco Defense Orchestrator）] オプションを選択して [登録（Register）] をクリックします。デバイスは、新しい地域に属する新しいテナントにマッピングされ、Security Cloud Control によってオンボーディングされます。

デバイスがオフラインである

原因

次のいずれかの理由により、デバイスが Cisco Cloud に到達できません。

デバイスのケーブル接続が正しくありません。
ネットワークには、デバイスのスタティック IP アドレスが必要な場合があります。
ネットワークでカスタム DNS が使用されているか、顧客のネットワークに外部 DNS ブロッキングが設定されています。
PPPoE 認証が必要です。（欧州地域共通）
FDM による管理デバイスはプロキシの背後にあります。

解決策

デバイスにサインインし、ブートストラップ CLI プロセスまたは Security Cloud Control の簡単なセットアッププロセスを実行して、まずインターネットに接続できるようにデバイスを設定します。
ケーブル接続とネットワーク接続を確認します。
ファイアウォールがトラフィックをブロックしていないことを確認してください。
Security Services Exchange ドメインが到達可能であることを確認してください。詳細については、「ハードウェア設置に関する設定の前提条件」を参照してください。

デバイスの要求に失敗した

原因

このエラーは次のいずれかの理由で発生することがあります。

Security Services Exchange に一時的な問題が発生している可能性があります。
サーバーがダウンしている可能性があります。

解決策

Security Cloud Control で FDM による管理デバイスインスタンスを削除します。
新しい FDM による管理デバイスインスタンスを作成し、しばらくしてから再度デバイスを要求します。

（注）

デバイスを要求できない場合は、ワークフローに移動してエラーメッセージを確認し、詳細を Security Cloud Control サポートチームに送信します。

プロビジョニングエラー

デバイスのパスワードは変更されていません

Security Cloud Control からデバイスを要求すると、デバイスの初期プロビジョニングが失敗し、[インベントリ（Inventory）] ページに「プロビジョニングされていません（Unprovisioned）」というメッセージが表示される場合があります。

原因

デフォルトパスワードが変更されていない新しい FDM による管理デバイスに対して、Security Cloud Control FDM による管理デバイスのシリアル番号オンボーディングウィザードで [デフォルトパスワードが変更された（Default Password Changed）] オプションを選択した可能性があります。

対処法

デバイスのパスワードを変更するには、[インベントリ（Inventory）] ページで [パスワードの入力（Enter Password）] をクリックする必要があります。Security Cloud Control は新しいパスワードで続行し、デバイスをオンボーディングします。

デバイスパスワードがすでに変更されている

原因

デフォルトパスワードがすでに変更されている FDM による管理デバイスに対して、Security Cloud Control FDM による管理デバイスのシリアル番号オンボーディングウィザードで [デフォルトパスワードが変更されていない（Default Password Not Changed）] オプションを選択した可能性があります。

対処法

シリアルオンボーディングウィザードで指定された新しいパスワードを無視するには、[インベントリ（Inventory）] ページで [確認して続行（Confirm and Proceed）] をクリックする必要があります。Security Cloud Control は古いパスワードで続行し、デバイスをオンボーディングします。

その他のエラーの場合

その他すべてのプロビジョニングエラーについては、[再試行（Retry）] をクリックしてプロビジョニングを再開できます。複数回再試行しても失敗する場合は、次の手順を実行します。

Security Cloud Control から FDM による管理デバイスインスタンスを削除し、新しいインスタンスを作成します。オンボーディングの手順については、『Onboard an FDM-Managed Device using the Device Serial Number』を参照してください。
Firewall Device Manager で、[システム設定（System Settings）] > [クラウドサービス（Cloud Services）]に移動し、[Security Cloud Controlからテナントへの自動登録（Auto-enroll with Tenancy from Cisco Defense Orchestrator）] オプションを選択して [登録（Register）] をクリックします。

FDM による管理 HA 作成のトラブルシュート

イベントの説明エラー

Security Cloud Control で FDM による管理 HA ペアをオンボーディングまたは作成しようとすると、HA ペアの形成に失敗し、次のメッセージとともにエラーが表示される場合があります。

イベントの説明：CD App Sync エラーは、Cisco Threat Response がアクティブデバイスで有効になっていて、スタンバイでは有効になっていない場合に表示されます（Event description: CD App Sync error is Cisco Threat Response is enabled on Active but not on Standby）

このエラーが表示された場合、HA ペア内の一方または両方のデバイスが、イベントを Security Cloud Control、Firepower Threat Response、または Cisco Success Network などの Cisco Cloud サーバーに送信できるように設定されていません。

Firewall Device Manager UI から、[Cisco Cloudにイベントを送信（Send Events to the Cisco Cloud）] 機能を有効にする必要があります。詳細については、実行しているバージョンの Firepower Device Manager 設定ガイド [英語] の「Configuring Cloud Services」の章を参照してください。https://www.cisco.com/c/en/us/support/security/firepower-ngfw/products-installation-and-configuration-guides-list.html

HA を作成後、デバイスの 1 つが不良状態になります。

HA の作成中にいずれかのデバイスが異常または障害状態になった場合は、HA ペアを解除してデバイスの状態を解決してから、HA を再作成します。フェールオーバーの履歴は、問題の診断に役立つ場合があります。FDM による管理の高可用性フェールオーバーの履歴

Secure Device Connector のトラブルシュート

オンプレミスの Secure Device Connector（SDC）のトラブルシューティングを行うには、以下のトピックを参照してください。

いずれのシナリオにも当てはまらない場合は、Cisco Technical Assistance Center でケースを開いてください。

SDC に到達不能

Security Cloud Control からの 2 回のハートビート要求に連続して応答しなかった場合、SDC の状態は [到達不能（Unreachable）] になります。SDC に到達不能な場合、テナントは、オンボーディングしたどのデバイスとも通信できません。

Security Cloud Control は、次の方法で SDC に到達不能であることを示します。

「一部の Secure Device Connector（SDC）に到達できません。該当する SDC に関連付けられたデバイスとは通信できません（Some Secure Device Connectors (SDC) are unreachable. You will not be able to communicate with devices associated with these SDCs）」というメッセージが Security Cloud Control のホームページに表示されます。
[サービス（Services）] ページの SDC のステータスが [到達不能（Unreachable）] になります。

この問題を解決するには、まず SDC とテナントの再接続を試行してください。

SDC 仮想マシンが実行中で、地域の Security Cloud Control IP アドレスに到達できることを確認します。管理対象デバイスへの Security Cloud Control の接続を参照してください。
ハートビートを手動で要求して、Security Cloud Control と SDC の再接続を試行します。SDC がハートビート要求に応答すると、[アクティブ（Active）] ステータスに戻ります。ハートビートを手動で要求するには、次の手順に従います。
1. 左側のペインで[ツールとサービス（Tools & Services）] > [セキュアコネクタ（Secure Connectors）]を選択します。
2. 到達不能な SDC をクリックします。
3. [操作（Actions）] ペインで、[ハートビートの要求（Request heartbeat）] をクリックします。
4. [再接続（Reconnect）] をクリックします。
SDC を手動でテナントに再接続しようとしても、SDC が [アクティブ（Active）] ステータスに戻らない場合は、「展開後 Security Cloud Control で SDC ステータスが [アクティブ（Active）] にならない」の指示に従ってください。
.

展開後 Security Cloud Control で SDC ステータスが [アクティブ（Active）] にならない

展開して約 10 分たっても SDC がアクティブになったことを Security Cloud Control が示さない場合は、SDC の展開時に作成した Security Cloud Control ユーザーおよびパスワードにより、SSH を使用して SDC VM に接続します。

手順

ステップ 1

/opt/cdo/configure.log を確認します。ここには、入力した SDC の構成設定と、それらが正常に適用されたかどうかが示されます。セットアッププロセスでエラーが発生している場合または値が正しく入力されていない場合は、sdc-onboard setup を再度実行します。

プロンプトで、sudo sdc-onboard setup と入力します。
cdo ユーザーのパスワードを入力します。
プロンプトに従います。セットアップスクリプトの指示に従って、セットアップウィザードで行ったすべての設定手順を確認し、入力した値を変更することができます。

ステップ 2

ログを確認し、sudo sdc-onboard setup を実行しても、Security Cloud Control で SDC が [アクティブ（Active）] にならない場合は、Security Cloud Control サポートに連絡してください。

SDC の変更された IP アドレスが Security Cloud Control に反映されない

SDC の IP アドレスを変更した場合、GMT の午前 3 時以降まで変更は Security Cloud Control に反映されません。

デバイスと SDC の接続に関するトラブルシューティング

このツールを使用して、Secure Device Connector（SDC）を介した Security Cloud Control からデバイスへの接続をテストします。デバイスがオンボーディングに失敗した場合、またはオンボーディングの前に Security Cloud Control がデバイスに到達できるかどうかを判断する場合は、この接続をテストすることができます。

手順

ステップ 1	左側のペインで [管理（Administration）] > [Firewall Management Center] をクリックし、[セキュアコネクタ（Secure Connectors）] タブをクリックします。
ステップ 2	SDC を選択します。
ステップ 3	右側の [トラブルシューティング（Troubleshooting）] ペインで、[デバイスの接続（Device Connectivity）] をクリックします。
ステップ 4	トラブルシューティングまたは接続しようとしているデバイスの有効な IP アドレスまたは FQDN とポート番号を入力し、[実行（Go）] をクリックします。Security Cloud Control は次の検証を実行します。 [DNS解決（DNS Resolution）]：IP アドレスの代わりに FQDN を指定すると、SDC がドメイン名を解決でき、IP アドレスを取得できることを確認します。 [接続テスト（Connection Test）]：デバイスが到達可能であることを確認します。 [TLSサポート（TLS support）]：デバイスと SDC の両方がサポートする TLS バージョンと暗号を検出します。 [サポートされていない暗号（Unsupported Cipher）]：デバイスと SDC の両方でサポートされている TLS バージョンがない場合、Security Cloud Control は、SDC ではなくデバイスでサポートされている TLS バージョンと暗号についてもテストします。 SSL 証明書：トラブルシューティングでは、証明書情報が提供されます。
ステップ 5	デバイスのオンボーディングまたはデバイスへの接続の問題が解消しない場合は、Security Cloud Control サポートまでお問い合わせください。

SDC との断続的な接続または接続がない

このセクションで説明するソリューションは、オンプレミスの Secure Device Connector（SDC）にのみ適用されます。

症状：SDC との断続的な接続または接続がない。

診断：この問題は、ディスク領域がほぼいっぱい（80% 以上）の場合に発生する可能性があります。

次の手順を実行して、ディスク容量の使用状況を確認します。

Secure Device Connector（SDC）VM のコンソールを開きます。
ユーザー名 cdo でログインします。
初回ログイン時に作成したパスワードを入力します。
まず、df -h と入力して空きディスク容量をチェックし、空きディスク容量がないことを確認します。

Docker によってディスク容量が消費されたことを確認できます。通常のディスク使用量は 2 ギガバイト未満であると予想されます。
Docker フォルダーのディスク使用量を表示するには、

sudo du -h /var/lib/docker | sort -h を実行します。

Docker フォルダーのディスク使用量を確認できます。

手順

Docker フォルダーのディスク使用量がほぼいっぱいの場合は、docker 設定ファイルで次のように定義します。

Max-size：現在のファイルが最大サイズに達したら、ログローテーションを強制します。
Max-file：上限に達したら、ローテーションされた余分なログファイルを削除します。

次の手順を実行します。

sudo vi /etc/docker/daemon.json を実行します。
次の行をファイルに挿入します。

{

"log-driver": "json-file",

"log-opts": {"max-size": "100m", "max-file": "5" }

}

Esc キーを押してから :wq! と入力し、変更を書き込んでファイルを閉じます。

（注）

sudo cat /etc/docker/daemon.json を実行して、ファイルに加えられた変更を確認できます。

sudo systemctl restart docker を実行して docker ファイルを再起動します。

変更が適用されるまでに数分かかる場合があります。sudo du -h /var/lib/docker | sort -h を実行して、docker フォルダーの更新されたディスク使用量を表示します。
df -h を実行して、空きディスクサイズが増加したことを確認します。
SDC のステータスを [到達不能（Unreachable）] から [アクティブ（Active）] に変更する前に、[管理（Administration）] > [Firewall Management Center] から [セキュアコネクタ（Secure Connectors）] タブに移動して、[アクション（Actions）] メニューから [再接続の要求（Request Reconnect）] をクリックする必要があります。

Secure Device Connector に影響を与えるコンテナ特権昇格の脆弱性：cisco-sa-20190215-runc

Cisco Product Security Incident Response Team（PSIRT）は、Docker のシビラティ（重大度）の高い脆弱性について説明するセキュリティアドバイザリ cisco-sa-20190215-runc を公開しました。脆弱性の完全な説明については、PSIRT チームのアドバイザリ全体をお読みください。

この脆弱性は、すべての Security Cloud Control ユーザーに影響します。

Security Cloud Control のクラウド展開された Secure Device Connector（SDC）を使用しているお客様は、修復手順が Security Cloud Control オペレーションズチームによってすでに実行されているため、何もする必要はありません。
オンプレミスで展開された SDC を使用しているお客様は、最新の Docker バージョンを使用するように SDC ホストをアップグレードする必要があります。アップグレードするには、次の手順を使用します。

Security Cloud Control 標準の SDC ホストの更新

Security Cloud Control イメージを使用して SDC を展開した場合は、次の手順を使用します。

手順

ステップ 1

SSH またはハイパーバイザコンソールを使用して SDC ホストに接続します。

ステップ 2

次のコマンドを実行して、Docker サービスのバージョンを確認します。

docker version

ステップ 3

最新の仮想マシン（VM）のいずれかを実行している場合、次のような出力が表示されます。

 > docker version
Client:
     Version: 18.06.1-ce
     API version: 1.38
     Go version: go1.10.3
     Git commit: e68fc7a
     Built: Tue Aug 21 17:23:03 2018
     OS/Arch: linux/amd64
     Experimental: false

ここで古いバージョンが表示される可能性があります。

ステップ 4

次のコマンドを実行して Docker を更新し、サービスを再起動します。

> sudo yum update docker-ce
> sudo service docker restart

（注）

Docker サービスの再起動中、Security Cloud Control とデバイス間の接続が短時間停止します。

ステップ 5

docker version コマンドを再度実行します。次の出力が表示されます。

> docker version
Client:
    Version: 18.09.2
    API version: 1.39
    Go version: go1.10.6
    Git commit: 6247962
    Built: Sun Feb XX 04:13:27 2019
    OS/Arch: linux/amd64
    Experimental: false

ステップ 6

これで追加されました。パッチが適用された最新バージョンの Docker にアップグレードされました。

カスタム SDC ホストを更新する

独自の SDC ホストを作成している場合は、Docker のインストール方法に基づいた更新手順に従う必要があります。CentOS、yum、Docker-ce（コミュニティ版）を使用した場合は、前述の手順で動作します。

Docker-ee（エンタープライズ版）をインストールした場合、または別の方法を使用して Docker をインストールした場合は、Docker の修正バージョンが異なる場合があります。正しいインストールバージョンは、Docker のページ（Docker Security Update and Container Security Best Practices）で確認できます。

バグトラッキング

シスコでは、この脆弱性を引き続き評価し、追加情報が利用可能になり次第、アドバイザリを更新します。アドバイザリが最終とマークされたら、次の関連する Cisco バグを参照して詳細を確認できます。

CSCvo33929-CVE-2019-5736：runC コンテナのブレークアウト

無効なシステム時刻

Security Cloud Control は、Secure Device Connector（SDC）との新しい通信方式を採用します。そのため、Security Cloud Control は 2024 年 2 月 1 日までに既存の SDC を新しい通信方式に移行する必要があります。

（注）

2024 年 2 月 1 日までに SDC が移行されない場合、Security Cloud Control は SDC を介してデバイスと通信できなくなります。

Security Cloud Control のオペレーションズチームが SDC を移行しようとしましたが、SDC システム時刻が AWS システム時刻より 15 分進んでいるか遅れていたため、移行できませんでした。

システム時刻の問題を修正するには、以下の手順に従ってください。この問題が解決したら、移行を続行できます。

手順

ステップ 1	VM 端末を介して、または SSH 接続を確立して、SDC VM にログインします。
ステップ 2	プロンプトに `sudo sdc-onboard setup` と入力して、認証を行います。
ステップ 3	SDC の初回セットアップ時と同様に、SDC セットアップに関する質問に回答します。以前と同じパスワードとネットワーク情報をすべて再入力します。このとき、NTP サーバーアドレスをメモしておきます。 SDC のセットアップに使用したものと同じパスワードを使用して、ルートおよび Security Cloud Control ユーザーのパスワードをリセットします。プロンプトが表示されたら、y と入力してネットワークを再設定します。以前と同じ IP アドレスまたは CIDR の値を入力します。以前と同じネットワークゲートウェイの値を入力します。以前と同じドメインネームシステム（DNS）サーバーの値を入力します。 NTP サーバーの入力を求められたら、有効な NTP サーバーアドレス（`time.aws.com`など）を入力してください。入力した値を確認し、間違いなければ y と入力します。
ステップ 4	プロンプトに `date` と入力して、時刻サーバーが到達可能か、SDC と同期しているかを検証します。日時（UTC）が表示され、SDC の時刻と比較できます。

次のタスク

これらの手順が完了したら、またはエラーが発生した場合は、Cisco Technical Assistance Center （TAC）までご連絡ください。これらの手順が正常に完了すると、Security Cloud Control オペレーションズチームが SDC の新通信方式への移行を完了できます。

SDC のバージョンが 202311**** より前

（注）

2024 年 2 月 1 日までに SDC が移行されない場合、Security Cloud Control は SDC を介してデバイスと通信できなくなります。

Security Cloud Control のオペレーションズチームは SDC を移行しようとしましたが、テナントが 202311**** よりも前のバージョンを実行しているため失敗しました。

SDC の現在のバージョンは、Security Cloud Control のメニューバーから[ツールとサービス（Tools & Services）] > [セキュアコネクタ（Secure Connectors）]の順に移動して、[セキュアコネクタ（Secure Connectors）] ページに記載されています。SDC を選択すると、画面右側の [詳細（Details）] ペインにバージョン番号が表示されます。

SDC バージョンをアップグレードするには、次の手順に従ってください。この問題が解決したら、Security Cloud Control オペレーションズチームが移行プロセスを再度実行できるようになります。

手順

ステップ 1	SDC VM にログインし、認証を行います。
ステップ 2	プロンプトに `sudo su - sdc` と入力して、認証を行います。
ステップ 3	プロンプトに `crontab -r` と入力します。 `no crontab for sdc` というメッセージが表示された場合、無視して次の手順に進めます。
ステップ 4	プロンプトに `./toolkit/toolkit.sh upgrade` と入力します。Security Cloud Control は、アップグレードが必要かどうかを判断し、ツールキットをアップグレードします。コンソールでエラーが報告されていないことを確認します。
ステップ 5	SDC の新しいバージョンを確認します。 Security Cloud Control にログインします。 Security Cloud Control のメニューバーから[ツールとサービス（Tools & Services）] > [セキュアコネクタ（Secure Connectors）]の順に移動して、[セキュアコネクタ（Secure Connectors）] ページを開きます。 SDC を選択して、[操作（Actions）] ペインで [ハートビートの要求（Request Heartbeat）] をクリックします。 SDC のバージョンが 202311**** 以降であることを検証します。

次のタスク

これらの手順が完了したら、またはエラーが発生した場合は、Cisco Technical Assistance Center （TAC）までご連絡ください。これらの手順が正常に完了すると、Security Cloud Control オペレーションズチームが移行プロセスを再度実行できます。

AWS サーバーの証明書または接続エラー

（注）

2024 年 2 月 1 日までに SDC が移行されない場合、Security Cloud Control は SDC を介してデバイスと通信できなくなります。

Security Cloud Control のオペレーションズチームが SDC を移行しようとしましたが、接続の問題が発生したため失敗しました。

接続の問題を修正するには、次の手順に従ってください。この問題が解決したら、移行を続行できます。

手順

ステップ 1

ポート 443 で、リージョン内のドメインへのアウトバウンドプロキシ接続を許可するファイアウォールルールを作成します。

オーストラリアリージョンの実稼働テナント：
- cognito-identity.ap-southeast-2.amazonaws.com
- cognito-idp.ap-southeast-2.amazonaws.com
- sns.ap-southeast-2.amazonaws.com
- sqs.ap-southeast-2.amazonaws.com
インドリージョンの実稼働テナント：
- cognito-identity.ap-south-1.amazonaws.com
- cognito-idp.ap-south-1.amazonaws.com
- sns.ap-south-1.amazonaws.com
- sqs.ap-south-1.amazonaws.com
米国リージョンの実稼働テナント：
- cognito-identity.us-west-2.amazonaws.com
- cognito-idp.us-west-2.amazonaws.com
- sns.us-west-2.amazonaws.com
- sqs.us-west-2.amazonaws.com
EU リージョンの実稼働テナント：
- cognito-identity.eu-central-1.amazonaws.com
- cognito-idp.eu-central-1.amazonaws.com
- sns.eu-central-1.amazonaws.com
- sqs.eu-central-1.amazonaws.com
APJ リージョンの実稼働テナント：
- cognito-identity.ap-northeast-1.amazonaws.com
- cognito-idp.ap-northeast-1.amazonaws.com
- sqs.ap-northeast-1.amazonaws.com
- sns.ap-northeast-1.amazonaws.com

ステップ 2

次のいずれかのコマンドを使用して、ファイアウォールの「許可リスト」に追加する必要がある IP アドレスの全リストを確認できます。

（注）

次のコマンドは、jq がインストールされているユーザー向けです。IP アドレスが 1 つのリストに表示されます。

米国リージョンの実稼働テナント：

curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[] | select( (.service == "AMAZON" ) and .region == "us-west-2") | .ip_prefix'

EU リージョンの実稼働テナント：

curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[] | select( (.service == "AMAZON" ) and .region == "eu-central-1") | .ip_prefix'

APJ リージョンの実稼働テナント：

curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[] | select( (.service == "AMAZON" ) and .region == "ap-northeast-1") | .ip_prefix'

（注）

jq がインストールされていない場合は、次の短縮バージョンのコマンドを使用できます。

curl -s https://ip-ranges.amazonaws.com/ip-ranges.json

次のタスク

Secure Event Connector のトラブルシューティング

いずれのシナリオにも当てはまらない場合は、Cisco Technical Assistance Center でケースを開いてください。

SEC オンボーディング失敗のトラブルシューティング

以下のトラブルシューティングのトピックでは、Secure Event Connector（SEC）のオンボーディングの失敗に関連するさまざまな症状について説明します。

SEC のオンボーディングに失敗しました

症状：SEC のオンボーディングに失敗しました。

修復：SEC を取り外して、再度オンボードします。

このエラーが表示された場合：

仮想マシンコンテナから Secure Event Connector とそのファイルを削除します。
Secure Device Connector の更新。通常、SDC は自動的に更新されるためこの手順を行う必要はありませんが、トラブルシューティングではこの手順が役立ちます。
SDC 仮想マシンへの Secure Event Connector のインストール。

ヒント

SEC をオンボードするときは、常にコピーリンクを使用してブートストラップデータをコピーします。

（注）

この手順で問題が解決しない場合は、トラブルシューティングログを収集し、マネージドサービスプロバイダーまたは Cisco Technical Assistance Center に連絡してください。

SEC ブートストラップデータが指定されていません

メッセージ：ERROR cannot bootstrap Secure Event Connector, bootstrap data not provided, exiting.

 [sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup 
Please input the bootstrap data from Setup Secure Event Connector page of CDO: 
[2020-06-10 04:37:26] ERROR cannot bootstrap Secure Event Connector, bootstrap data not provided, exiting.

診断：プロンプトが表示されたときに、ブートストラップデータがセットアップスクリプトに入力されませんでした。

修復：オンボーディング時にブートストラップデータの入力を求められたら、Security Cloud Control UI で生成された SEC ブートストラップデータを指定します。

ブートストラップ構成ファイルが存在しません

メッセージ：ERROR Cannot bootstrap Secure Event Connector for tenant: <tenant_name>, bootstrap config file ("/usr/local/cdo/es_bootstrapdata") does not exist, exiting.（ERROR テナントのセキュアイベントコネクタをブートストラップできません：<tenant_name>、ブートストラップ設定ファイル（"/usr/local/Security Cloud Control/es_bootstrapdata"）が存在しないため、終了します。）

診断：SEC ブートストラップデータファイル（"/usr/local/Security Cloud Control/es_bootstrapdata"）が存在しません。

修復：Security Cloud Control UI で生成された SEC ブートストラップデータをファイル /usr/local/Security Cloud Control/es_bootstrapdata に配置し、オンボーディングを再試行します。

オンボーディング手順を繰り返します。
ブートストラップデータをコピーします。
「sdc」ユーザーとして SEC VM にログインします。
Security Cloud Control UI で生成された SEC ブートストラップデータをファイル /usr/local/Security Cloud Control/es_bootstrapdata に配置し、オンボーディングを再試行します。

ブートストラップデータのデコードに失敗しました

メッセージ：ERROR cannot bootstrap Secure Event Connector for tenant: <tenant_name>, faile to decode SEC boostrap data, exiting.

[sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup
base64: invalid input
[2020-06-10 04:37:26] ERROR cannot bootstrap Secure Event Connector for tenant: tenant_XYZ, failed to decode SEC bootstrap data, exiting.

診断：ブートストラップデータのデコードに失敗しました

修復：SEC ブートストラップデータを再生成し、オンボーディングを再試行します。

ブートストラップデータに SEC をオンボードするために必要な情報がありません

メッセージ：

ERROR cannot bootstrap Secure Event Connector container for tenant, the Security Services Exchange FQDN not set, exiting.
ERROR cannot bootstrap Secure Event Connector container for tenant, the Security Services Exchange OTP not set, exiting.

 [sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup 
[2020-06-10 04:37:26] ERROR cannot bootstrap Secure Event Connector for tenant: Security Services Exchange FQDN not set, exiting.

[sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup 
[2020-06-10 04:37:26] ERROR cannot bootstrap Secure Event Connector for tenant: Security Services Exchange FQDN not set, exiting.

診断：ブートストラップデータに SEC をオンボードするために必要な情報がありません。

修復：ブートストラップデータを再生成し、オンボーディングを再試行します。

ツールキット cron が現在実行中

メッセージ：ERROR SEC toolkit already running, exiting.

 [sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup
 [2020-06-10 04:37:26] ERROR SEC toolkit already running.

診断：ツールキット cron が現在実行中です。

修復：オンボーディングコマンドを再試行します。

十分な CPU とメモリがない

メッセージ：ERROR unable to setup Secure Event Connector, minimum 4 cpus and 8 GB ram required, exiting.

 [sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup 
[2020-06-10 04:37:26] ERROR unable to setup Secure Event Connector, minimum 4 cpus and 8 GB ram required, exiting.

診断：十分な CPU とメモリがありません。

修復：VM の SEC 専用に最低 4 つの CPU と 8 GB の RAM がプロビジョニングされていることを確認し、オンボーディングを再試行します。

SEC がすでに実行中

メッセージ：ERROR Secure Event Connector already running, execute 'cleanup' before onboarding a new Secure Event Connector, exiting.

[sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup 
[2020-06-10 04:37:26] ERROR Secure Event Connector already running, execute 'cleanup' before onboarding a new Secure Event Connector, exiting.

診断：SEC がすでに実行中です。

修復：新しい SEC をオンボードする前に、SEC cleanup コマンドを実行します。

SEC ドメインに到達不能

メッセージ：

Failed connect to api-sse.cisco.com:443; Connection refused
ERROR unable to setup Secure Event Connector, domain api-sse.cisco.com unreachable, exiting.

 [sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup 
curl: (7) Failed connect to api-sse.cisco.com:443; Connection refused 
[2020-06-10 04:37:26] ERROR unable to setup Secure Event Connector, domain api-sse.cisco.com unreachable, exiting.

診断：SEC ドメインに到達できません。

修復：オンプレミス SDC にインターネット接続があることを確認し、オンボーディングを再試行します。

オンボーディング SEC コマンドはエラーなしで成功しましたが、SEC Docker コンテナが起動していません

症状：オンボーディング SEC コマンドはエラーなしで成功しましたが、SEC Docker コンテナが起動していません

診断：オンボーディング SEC コマンドはエラーなしで成功しましたが、SEC docker コンテナが起動していません

修復：

「sdc」ユーザーとして SEC にログインします。
SEC Docker コンテナの起動ログ（/usr/local/Security Cloud Control/data/<tenantDir>/event_streamer/logs/startup.log）でエラーがないか確認してください。
エラーがある場合は、SEC cleanup コマンドを実行して、オンボーディングを再試行してください。

Security Cloud Control サポートへの問い合わせ

いずれのシナリオにも当てはまらない場合は、Cisco Technical Assistance Center でケースを開いてください。

Secure Event Connector の登録失敗のトラブルシューティング

症状：クラウドイベントサービスへの Cisco Secure Event Connector の登録が失敗します。

診断：SEC がイベントクラウドサービスに登録できない最も一般的な理由は、次のとおりです。

SEC が SEC からイベントクラウドサービスに到達できない

修復：インターネットがポート 443 でアクセス可能であり、DNS が正しく設定されていることを確認します。
SEC ブートストラップデータの無効または期限切れのワンタイムパスワードによる登録の失敗

修復：

手順

ステップ 1	「sdc」ユーザーとして SDC にログオンします。
ステップ 2	コネクタログ（/usr/local/cdo/data/<tenantDir>/event_streamer/logs/connector.log）を表示して、登録状態を確認します。無効なトークンが原因で登録に失敗した場合は、ログファイルに次のようなエラーメッセージが表示されます。 context:(*contextImpl).handleFailed] registration - CE2001: Registration failed - Failed to register the device because of invalid token. Retry with a new valid token. - Failed"
ステップ 3	SDC VM で SEC クリーンアップコマンド手順を実行して、[セキュアコネクタ（Secure Connectors）] ページから SEC を削除します。
ステップ 4	新しい SEC ブートストラップデータを生成し、SEC オンボーディング手順を再試行します。

Security and Analytics Logging イベントを使用したネットワーク問題のトラブルシューティング

これは、イベントビューアを使用してネットワークの問題にトラブルシューティングを実行するための基本的なフレームワークです。

このシナリオでは、ネットワーク運用チームが、ユーザーがネットワーク上のリソースにアクセスできないという報告を受け取ったと想定しています。問題とその場所を報告しているユーザーに基づいて、ネットワーク運用チームは、どのファイアウォールがユーザーによるリソースへのアクセスを制御しているか把握しています。

（注）

このシナリオでは、ネットワークトラフィックを管理するファイアウォールが FDM による管理デバイスであることも想定しています。Security Analytics and Logging は、他のデバイスタイプからログ情報を収集しません。

手順

ステップ 1	左側のペインで [イベントとログ（Events & Logs）] > [イベント（Events）] をクリックします。
ステップ 2	[履歴（Historic）] タブをクリックします。
ステップ 3	[時間範囲（Time Range）] によるイベントのフィルタ処理を開始します。デフォルトでは、[履歴（Historical）] タブには過去 1 時間のイベントが表示されます。それが正しい時間範囲である場合は、現在の日付と時刻を [終了（End）] 時刻として入力します。それが正しい時間範囲でない場合は、報告された問題の時間を含む開始時間と終了時間を入力します。
ステップ 4	[センサーID（Sensor ID）] フィールドに、ユーザーのアクセスを制御していると考えられるファイアウォールの IP アドレスを入力します。ファイアウォールが複数の可能性がある場合は、検索バーで属性:値のペアを使用してイベントをフィルタ処理します。2 つのエントリを作成し、それらを OR ステートメントで結合します。例: `SensorID:192.168.10.2 OR SensorID:192.168.20.2`。
ステップ 5	イベントフィルタバーの [ソースIP（Source IP）] フィールドにユーザーの IP アドレスを入力します。
ステップ 6	ユーザーがリソースにアクセスできない場合は、そのリソースの IP アドレスを [宛先IP（Destination IP）] フィールドに入力します。
ステップ 7	結果に表示されるイベントを展開し、その詳細を確認します。以下の詳細に注意してください。 AC_RuleAction - ルールがトリガーされたときに実行されたアクション（許可、信頼、ブロック）。 FirewallPolicy - イベントをトリガーしたルールが存在するポリシー。 FirewallRule - イベントをトリガーしたルールの名前。値が Default Action の場合、イベントをトリガーしたのはポリシーのデフォルトアクションであり、ポリシー内のルールの 1 つではありません。 UserName - イニシエータの IP アドレスに関連づけられたユーザー。イニシエータ IP アドレスはソース IP アドレスと同じです。
ステップ 8	ルールのアクションがアクセスをブロックしている場合は、[FirewallRule] フィールドと [FirewallPolicy] フィールドを確認して、アクセスをブロックしているポリシーのルールを特定します。

NSEL データフローのトラブルシューティング

したら、次の手順を使用して、NSEL イベントが ASA から Cisco Cloud に送信されていること、および Cisco Cloud がそれらのイベントを受信していることを確認します。

NSEL イベントを Secure Event Connector（SEC）に送信してから Cisco Cloud に送信するように ASA を設定すると、データはすぐには流れないことに注意してください。ASA で NSEL 関連のトラフィックが生成されていると仮定すると、最初の NSEL パケットが到着するまでに数分かかることがあります。

（注）

このワークフローは、「flow-export counters」コマンドと「capture」コマンドを単純に使用して NSEL データフローをトラブルシューティングする方法を示しています。これらのコマンドの使用法の詳細については、CLI ブック 1：Cisco ASA シリーズ CLI コンフィギュレーションガイド（一般的な操作）[英語] および Cisco ASA NetFlow 実装ガイド [英語] の「Monitoring NSEL」を参照してください。

次のタスクを実行します。

NetFlow パケットが SEC に送信されていることを確認する
NetFlow パケットが Cisco Cloud 受信されていることを確認する

イベントロギングのトラブルシューティングログファイル

Secure Event Connector（SEC）の troubleshoot.sh は、すべてのイベントストリーマログを収集して、単一の .tar.gz ファイルに圧縮します。

次の手順を使用して、comparessed.tar.gz ファイルを作成し、ファイルを解凍します。

トラブルシューティングスクリプトの実行。
sec_troubleshoot.tar.gz ファイルの圧縮解除。

トラブルシューティングスクリプトの実行

Secure Event Connector（SEC）の troubleshoot.sh は、すべてのイベントストリーマログを収集して、単一の .tar.gz ファイルに圧縮します。次の手順に従って、troubleshoot.sh スクリプトを実行します。

手順

ステップ 1	VM ハイパーバイザを開き、Secure Device Connector（SDC）のコンソールセッションを開始します。
ステップ 2	ログインしてから、[ルート（root）] ユーザーに切り替えます。

[cdo@localhost ~]$sudo su root

（注）

SDC ユーザーに切り替える一方で root として操作することもできます。その場合、IP テーブルの情報も受信することになります。IP テーブルの情報には、デバイス上でファイアウォールが実行中であることと、すべてのファイアウォールルートが表示されます。ファイアウォールが Secure Event Connector TCP ポートまたは UDP ポートをブロックしている場合、[イベントロギング（Event Logging）] テーブルにイベントが表示されません。IP テーブルは、そのような状況が発生しているかどうかを判断する際に役立ちます。

ステップ 3

プロンプトで、トラブルシューティングスクリプトを実行し、テナント名を指定します。コマンド構文は次のとおりです。

[root@localhost ~]$ /usr/local/cdo/toolkit/troubleshoot.sh --app sec --tenant CDO_[tenant_name]

次に例を示します。

[root@localhost ~]$ /usr/local/cdo/toolkit/troubleshoot.sh --app sec --tenant CDO_example_tenant

コマンド出力で、sec_troubleshoot ファイルが SDC の /tmp/troubleshoot ディレクトリに保存されていることがわかります。ファイル名は、sec_troubleshoot-timestamp.tar.gz の表記法に従います。

ステップ 4

ファイルを取得するには、Security Cloud Control ユーザーとしてログインし、SCP または SFTP を使用してダウンロードします。

次に例を示します。

[root@localhost troubleshoot]# scp sec_troubleshoot-timestamp.tar.gz root@server-ip:/scp/sec_troubleshoot-timestamp.tar.gz

次のタスク

sec_troubleshoot.tar.gz ファイルの圧縮解除に進みます。

sec_troubleshoot.tar.gz ファイルの圧縮解除

Secure Event Connector（SEC）の troubleshoot.sh は、すべてのイベントストリーマログを収集して、単一の sec_troubleshoot.tar.gz ファイルに圧縮します。sec_troubleshoot.tar.gz ファイルの圧縮を解除するには、次の手順を実行します。

VM ハイパーバイザを開き、Secure Device Connector（SDC）のコンソールセッションを開始します。

ログインしてから、[ルート（root）] ユーザーに切り替えます。

[cdo@localhost ~]$sudo su root

（注）

sdc ユーザーに切り替える一方で root として操作することもできます。その場合、IP テーブルの情報も受信することになります。IP テーブルの情報には、デバイス上でファイアウォールが実行中であることと、すべてのファイアウォールルートが表示されます。ファイアウォールが Secure Event Connector TCP ポートまたは UDP ポートをブロックしている場合、[イベントロギング（Event Logging）] テーブルにイベントが表示されません。IP テーブルは、そのような状況が発生しているかどうかを判断する際に役立ちます。

プロンプトで、次のコマンドを入力します。

[root@localhost ~]$ tar xvf sec_troubleshoot-timestamp.tar.gz

ログファイルは、テナントにちなんで名付けられたディレクトリに保存されます。これらのタイプのログは、sec_troubelshoot-timestamp.tar.gz ファイルに保存されます。root ユーザーとしてすべてのログファイルを収集した場合は、iptables ファイルが含まれています。

SEC ブートストラップデータの生成に失敗しました。

症状：Security Cloud Control で SEC ブートストラップデータを生成しているときに、「ブートストラップの生成」ステップでエラーが発生し、次のメッセージが表示されます。「ブートストラップデータの取得中にエラーが発生しました。再試行してください（There was an error fetching the bootstrap data. Please try again.）」

修復：ブートストラップデータの生成を再試行します。それでも失敗する場合は、Security Cloud Control サポートまでお問い合わせください。

Security Cloud Control の SEC ステータスが [非アクティブ（Inactive）] になっている

症状：次のいずれかの理由により、[CDOセキュアコネクタ（Security Cloud Control Secure Connectors）] ページで Secure Event Connector のステータスが [非アクティブ（Inactive）] と表示されます。

ハートビートに失敗した
コネクタの登録に失敗した

修復：

ハートビートに失敗した：SEC ハートビートを要求し、[セキュアコネクタ（Secure Connector）] ページを更新して、ステータスが [アクティブ（Active）] に変わるか確認します。変わらない場合は、Secure Device Connector の登録が失敗していないか確認します。
コネクタの登録に失敗した：「SEC 登録失敗のトラブルシューティング」を参照してください。

SEC は「オンライン」だが、Security Cloud Control の [イベントロギング（Events Logging）] ページにはイベントがない

症状：Secure Event Connector の Security Cloud Control セキュアコネクタページには [アクティブ（Active）] と表示されているのに、Security Cloud Control イベントビューアにイベントが表示されません。

解決策または回避策：

手順

ステップ 1

オンプレミス SDC の VM に「sdc」ユーザーとしてログインします。プロンプトで、sudo su - sdc と入力します。

ステップ 2

次のチェックを実行します。

SEC コネクタログ（/usr/local/Security Cloud Control/data/<tenantDir>/event_streamer/logs/connector.log）を確認し、SEC 登録が成功していることを確認します。成功していない場合は、「Secure Event Connector の登録失敗」を参照してください。
SEC イベントログ（/usr/local/Security Cloud Control/data/<tenantDir>/event_streamer/logs/events-plugin.log）を確認し、イベントが処理されていることを確認します。そうでない場合は、Security Cloud Control サポートにお問い合わせください。
SEC Docker コンテナにログインし、コマンド「supervisorctl -c /opt/cssp/data/conf/supervisord.conf」を実行します。出力が以下のようになり、すべてのプロセスが RUNNING 状態であることを確認します。そうでない場合は、Security Cloud Control サポートにお問い合わせください。

estreamer-connector RUNNING pid 36, uptime 5:25:17

estreamer-cron RUNNING pid 39, uptime 5:25:17

estreamer-plugin RUNNING pid 37, uptime 5:25:17

estreamer-rsyslog RUNNING pid 38, uptime 5:25:17

オンプレミス SDC のファイアウォールルールが、[セキュアコネクタ（Secure Connectors）] ページの SEC に表示される UDP および TCP ポートをブロックしていないことを確認します。どのポートを開くかを判断するには、「Cisco Security Analytics and Logging に使用されるデバイスの TCP、UDP、および NSEL ポートの検索」を参照してください。

独自の CentOS 7 VM を使用して SDC を手動でセットアップし、ファイアウォールが着信要求をブロックするように設定している場合は、次のコマンドを実行して UDP および TCP ポートのブロックを解除できます。

firewall-cmd --zone=public --add-port=<udp_port>/udp --permanent

firewall-cmd --zone=public --add-port=<tcp_port>/tcp --permanent

firewall-cmd --reload

選択した Linux ネットワークツールを使用して、これらのポートでパケットが受信されているかどうかを確認します。受信していない場合は、FTD ロギング設定を再確認してください。

上記のいずれの修復も機能しない場合は、Security Cloud Control サポートにサポートチケットを提出します。.

SEC クリーンアップコマンド

Secure Event Connector（SEC）クリーンアップコマンドは、SEC コンテナとその関連ファイルを Secure Device Connector（SDC）VM から削除します。このコマンドは、Secure Event Connector の登録失敗のトラブルシューティングまたはオンボーディングが失敗した場合に実行できます。

このコマンドを実行するには、次の手順を実行します。

始める前に

このタスクを実行するには、自分のテナントの名前を知っている必要があります。テナント名を見つけるには、Security Cloud Control でユーザーメニューを開き、[設定（Settings）] をクリックします。ページを下にスクロールして、[テナント名（Tenant Name）] を見つけます。

手順

ステップ 1

「sdc」ユーザーとして SDC にログインします。プロンプトで、sudo su - sdc と入力します。

ステップ 2

/usr/local/cdo/toolkit ディレクトリに接続します。

ステップ 3

sec.sh removetenant_name を実行し、SEC を削除することを確認します。

例:

 [sdc@localhost~]$ /usr/local/cdo/toolkit/sec.sh remove tenant_XYZ 
Are you sure you want to remove Secure Event Connector for tenant tenant_XYZ? (y/n): y

次のタスク

このコマンドで SEC の削除に失敗した場合は、SEC クリーンアップコマンドの失敗に進みます。

SEC クリーンアップコマンドの失敗

SEC クリーンアップコマンドが失敗した場合は、この手順を使用します。

メッセージ：SEC が見つかりません。終了します。

症状：Cleanup SEC コマンドが既存の SEC のクリーンアップに失敗します。

[sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh remove tenant_XYZ Are you sure you want to remove Secure Event Connector for tenant tenant_XYZ? (y/n): y [2020-06-10 04:50:42] SEC not found, exiting.

修復：クリーンアップコマンドが失敗した場合、Secure Event Connector を手動でクリーンアップします。

すでに実行中の SEC docker コンテナを削除します。

手順

ステップ 1	「sdc」ユーザーとして SDC にログインします。プロンプトで、`sudo su - sdc` と入力します。
ステップ 2	docker ps コマンドを実行して、SEC コンテナの名前を探します。SEC 名は、"es_name" の形式になります。
ステップ 3	docker stop コマンドを実行して、SEC コンテナを停止します。
ステップ 4	rm コマンドを実行して、SEC コンテナを削除します。例： `$ docker stop <SEC_docker_container_name> $ docker rm <SEC_docker_container_name>`

Secure Event Connector の状態を把握するためのヘルスチェックの使用

Secure Event Connector（SEC）のヘルスチェックスクリプトは、SEC の状態に関する情報を提供します。

ヘルスチェックを実行するには、次の手順に従います。

手順

ステップ 1	VM ハイパーバイザを開き、Secure Device Connector（SDC）のコンソールセッションを開始します。
ステップ 2	「Security Cloud Control」ユーザーとして SDC にログインします。
ステップ 3	「SDC」ユーザーに切り替えます。 `[cdo@tenant]$sudo su sdc`
ステップ 4	プロンプトで healthcheck.sh スクリプトを実行し、テナント名を指定します。 `[sdc@host ~]$ /usr/local/cdo/toolkit/healthcheck.sh --app sec --tenant CDO_[tenant_name]` 次に例を示します。 `[sdc@host ~]$ /usr/local/cdo/toolkit/healthcheck.sh --app sec --tenant CDO_example_tenant` スクリプトの出力には、次のような情報が表示されます。ヘルスチェック出力の値： [SECクラウドURL（SEC Cloud URL）]：Security Cloud Control クラウド URL と、SEC が Security Cloud Control に到達できるかどうかを表示します。 [SECコネクタ（SEC Connector）]：SEC コネクタが正しくオンボーディングされ、開始されている場合は、「実行中（Running）」と表示されます。 [SEC UDP syslogサーバー（SEC UDP syslog server）]：UDP syslog サーバーが UDP イベントを送信する準備ができている場合は、「実行中（Running）」と表示されます。 [SEC TCP syslogサーバー（SEC TCP syslog server）]：TCP syslog サーバーが TCP イベントを送信する準備ができている場合は、「実行中（Running）」と表示されます。 [SECコネクタのステータス（SEC Connector status）]：SEC が実行中で、Security Cloud Control へのオンボーディングが完了している場合は、[アクティブ（Active）] と表示されます。 [SEC送信サンプルイベント（SEC Send sample event）]：ヘルスチェックの終了時点ですべてのステータスチェックが「緑色」になっている場合、ツールはサンプルイベントを送信します。（いずれかのプロセスが [停止中（Down）] になっている場合、ツールはテストイベントの送信をスキップします）。このサンプルイベントは、「sec-health-check」という名前のポリシーとしてイベントログに表示されます。

Security Cloud Control のトラブルシューティング

ログインの失敗のトラブルシューティング

正しくない Security Cloud Control リージョンに誤ってログインしているため、ログインに失敗する

適切な Security Cloud Control リージョンにログインしていることを確認してください。https://sign-on.security.cisco.com にログインすると、アクセスするリージョンを選択できます。

サインインするリージョンについては、リージョンごとの Security Cloud Control へのサインインを参照してください。

移行後のログイン失敗のトラブルシューティング

ユーザー名またはパスワードが正しくないため、Security Cloud Control へのログインに失敗する

解決法 Security Cloud Control にログインしようとして、正しいユーザー名とパスワードを使用しているにもかかわらずログインに失敗する場合、または「パスワードを忘れた場合」を試しても有効なパスワードを回復できない場合は、新しい Cisco Security Cloud Sign On アカウントを作成せずにログインを試みた可能性があります。新規 Cisco Security Cloud Sign On アカウントの作成と Duo 多要素認証の設定の手順に従って、新しい Cisco Security Cloud Sign On アカウントにサインアップする必要があります。

Cisco Security Cloud Sign On ダッシュボードへのログインは成功するが、Security Cloud Control を起動できない

解決法 Security Cloud Control テナントとは異なるユーザー名で Cisco Security Cloud Sign On アカウントを作成している可能性があります。Security Cloud Control と Cisco Secure Sign-On の間でユーザー情報を標準化するには、Cisco Technical Assistance Center（TAC）に連絡してください。

保存したブックマークを使用したログインに失敗する

解決法 ブラウザに保存された古いブックマークを使用してログインしようとしているかもしれません。ブックマークが https://cdo.onelogin.com を指している可能性があります。

解決法 https://sign-on.security.cisco.com にログインします。

解決法 Cisco Secure Sign-On アカウントをまだ作成していない場合は、アカウントを作成します。
解決法 Cisco Secure Sign-On の新規アカウントを作成した場合は、テナントが作成されたリージョンに対応するダッシュボードの Security Cloud Control タイルをクリックします。
- 解決法 Cisco Security Cloud Control APJ
- 解決法 Cisco Security Cloud Control オーストラリア
- 解決法 Cisco Security Cloud Control EU
- 解決法 Cisco Security Cloud Control インド
- 解決法 Cisco Security Cloud Control 米国
解決法 https://sign-on.security.cisco.com を指すようにブックマークを更新します。

アクセスと証明書のトラブルシューティング

新規フィンガープリント検出ステータスの解決

手順

ステップ 1	左側のペインでセキュリティデバイスをクリックします。
ステップ 2	[デバイス] タブをクリックします。
ステップ 3	適切なデバイスタイプのタブをクリックします。
ステップ 4	[新しいフィンガープリントを検出（New Fingerprint Detected）] ステータスのデバイスを選択します。
ステップ 5	[新しい指紋が検出されました（New Fingerprint Detected）] ペインで [フィンガープリントの確認（Review Fingerprint）] をクリックします。
ステップ 6	フィンガープリントを確認して許可するように求められたら、以下の手順を実行します。 [フィンガープリントのダウンロード（Download Fingerprint）] をクリックして確認します。フィンガープリントに問題がなければ [許可（Accept）] をクリックします。問題がある場合は、[キャンセル（Cancel）] をクリックします。
ステップ 7	新しいフィンガープリントの問題を解決した後、デバイスの接続状態が [オンライン（Online）] と表示され、構成ステータスが「未同期（Not Synced）」または「競合検出（Conflict Detected）」と表示される場合があります。[構成の競合の解決（Resolve Configuration Conflicts）]設定の競合の解決を確認し、Security Cloud Control とデバイス間の構成の差異を確認して解決します。

Security and Analytics Logging イベントを使用したネットワーク問題のトラブルシューティング

これは、イベントビューアを使用してネットワークの問題にトラブルシューティングを実行するための基本的なフレームワークです。

（注）

手順

ステップ 1	左側のペインで [イベントとログ（Events & Logs）] > [イベント（Events）] をクリックします。
ステップ 2	[履歴（Historic）] タブをクリックします。
ステップ 3	[時間範囲（Time Range）] によるイベントのフィルタ処理を開始します。デフォルトでは、[履歴（Historical）] タブには過去 1 時間のイベントが表示されます。それが正しい時間範囲である場合は、現在の日付と時刻を [終了（End）] 時刻として入力します。それが正しい時間範囲でない場合は、報告された問題の時間を含む開始時間と終了時間を入力します。
ステップ 4	[センサーID（Sensor ID）] フィールドに、ユーザーのアクセスを制御していると考えられるファイアウォールの IP アドレスを入力します。ファイアウォールが複数の可能性がある場合は、検索バーで属性:値のペアを使用してイベントをフィルタ処理します。2 つのエントリを作成し、それらを OR ステートメントで結合します。例: `SensorID:192.168.10.2 OR SensorID:192.168.20.2`。
ステップ 5	イベントフィルタバーの [ソースIP（Source IP）] フィールドにユーザーの IP アドレスを入力します。
ステップ 6	ユーザーがリソースにアクセスできない場合は、そのリソースの IP アドレスを [宛先IP（Destination IP）] フィールドに入力します。
ステップ 7	結果に表示されるイベントを展開し、その詳細を確認します。以下の詳細に注意してください。 AC_RuleAction - ルールがトリガーされたときに実行されたアクション（許可、信頼、ブロック）。 FirewallPolicy - イベントをトリガーしたルールが存在するポリシー。 FirewallRule - イベントをトリガーしたルールの名前。値が Default Action の場合、イベントをトリガーしたのはポリシーのデフォルトアクションであり、ポリシー内のルールの 1 つではありません。 UserName - イニシエータの IP アドレスに関連づけられたユーザー。イニシエータ IP アドレスはソース IP アドレスと同じです。
ステップ 8	ルールのアクションがアクセスをブロックしている場合は、[FirewallRule] フィールドと [FirewallPolicy] フィールドを確認して、アクセスをブロックしているポリシーのルールを特定します。

SSL 暗号解読の問題のトラブルシューティング

復号再署名がブラウザでは機能するがアプリでは機能しない Web サイトの処理（SSL または認証局ピニング）

スマートフォンおよびその他のデバイス用の一部のアプリケーションでは「SSL（または認証局）ピニング」と呼ばれる手法が使用されます。SSL ピニング手法では、元のサーバー証明書のハッシュがアプリケーション自体の内部に埋め込まれます。その結果、アプリケーションが再署名された証明書を Firepower Threat Defense デバイスから受け取ると、ハッシュ検証に失敗し、接続が中断されます。

Web サイトのアプリケーションを使用してそのサイトに接続することができないにもかかわらず、Web ブラウザを使用する場合は、接続に失敗したアプリケーションを使用したデバイス上のブラウザでも接続できるというのが主な症状です。たとえば、Facebook の iOS または Android アプリケーションを使用すると接続に失敗しますが、Safari または Chrome で [/bookmap/topic/concept/reference/concept/conbody/section/p/xref {"link-https"}) https://www.facebook.com (xref] を指定すると接続に成功します。

SSL ピニングは特に中間者攻撃を回避するために使用されるため、回避策はありません。次のいずれかの選択肢を使用する必要があります。

詳細の表示

アプリケーションは、次の 2 つの方法でハッシュ検証の失敗に対処する場合があります。

グループ 1 のアプリケーション（Facebook など）は、サーバから SH、CERT、SHD メッセージを受け取るとすぐに SSL ALERT メッセージを送信します。アラートは、通常、SSL ピニングを示す「Unknown CA (48)」アラートです。アラートメッセージの後に TCP リセットが送信されます。イベントの詳細情報で次のような症状が見られます。
- SSL フローフラグには ALERT_SEEN が含まれます。
- SSL フローフラグには APP_DATA_C2S または APP_DATA_S2C は含まれません。
- SSL フローメッセージは、通常、CLIENT_HELLO、SERVER_HELLO、SERVER_CERTIFICATE、SERVER_KEY_EXCHANGE、SERVER_HELLO_DONE です。
グループ 2 のアプリケーション（Dropbox など）はアラートを送信しません。代わりに、ハンドシェイクが完了するまで待ってから TCP リセットを送信します。イベントで次のような症状が見られます。
- SSL フローフラグには ALERT_SEEN、APP_DATA_C2S または APP_DATA_S2C は含まれません。
- SSL フローメッセージは、通常、CLIENT_HELLO、SERVER_HELLO、SERVER_CERTIFICATE、SERVER_KEY_EXCHANGE、SERVER_HELLO_DONE、CLIENT_KEY_EXCHANGE、CLIENT_CHANGE_CIPHER_SPEC、CLIENT_FINISHED、SERVER_CHANGE_CIPHER_SPEC、SERVER_FINISHED です。

侵入防御システムのトラブルシュート

IPS ポリシーのオプションは何ですか?

すべてのデバイスに異なる IPS ポリシーを構成するにはどうすればよいですか?

FDM からオーバーライドが構成されているデバイスをオンボーディングしました。

Security Cloud Control の外部で構成されたオーバーライドは、デバイスの構成または機能に問題を引き起こしません。

移行後のログイン失敗のトラブルシューティング

ユーザー名またはパスワードが正しくないため、Security Cloud Control へのログインに失敗する

Cisco Security Cloud Sign On ダッシュボードへのログインは成功するが、Security Cloud Control を起動できない

保存したブックマークを使用したログインに失敗する

解決法 https://sign-on.security.cisco.com にログインします。

解決法 Cisco Secure Sign-On アカウントをまだ作成していない場合は、アカウントを作成します。
解決法 Cisco Secure Sign-On の新規アカウントを作成した場合は、テナントが作成されたリージョンに対応するダッシュボードの Security Cloud Control タイルをクリックします。
- 解決法 Cisco Security Cloud Control APJ
- 解決法 Cisco Security Cloud Control オーストラリア
- 解決法 Cisco Security Cloud Control EU
- 解決法 Cisco Security Cloud Control インド
- 解決法 Cisco Security Cloud Control 米国
解決法 https://sign-on.security.cisco.com を指すようにブックマークを更新します。

オブジェクトのトラブルシューティング

重複オブジェクトの問題の解決

重複オブジェクトとは、同じデバイス上にある、名前は異なるが値は同じである 2 つ以上のオブジェクトです。通常、重複したオブジェクトは誤って作成され、同じ目的を果たし、さまざまなポリシーによって使用されます。重複オブジェクトの問題を解決した後、Security Cloud Control は、残されたオブジェクト名に対する、影響を受けるすべてのオブジェクト参照を更新します。

重複オブジェクトの問題を解決するには以下の手順を実行します。

手順

ステップ 1	左側のペインで、[オブジェクト（Objects）] をクリックして、オプションを選択します。
ステップ 2	次に、オブジェクトをフィルタ処理して、重複するオブジェクトの問題を見つけます。
ステップ 3	結果の中から 1 つを選択します。オブジェクトの詳細パネルに、該当する重複の数を示す [重複（DUPLICATE）] フィールドが表示されます。
ステップ 4	[解決（Resolve）] をクリックします。Security Cloud Control は、重複オブジェクトを比較できるように表示します。
ステップ 5	比較するオブジェクトを 2 つ選択します。
ステップ 6	以下のオプションがあります。オブジェクトの 1 つを別のオブジェクトに置き換える場合は、保持するオブジェクトで [選択（Pick）] をクリックし、[解決（Resolve）] をクリックして影響を受けるデバイスとネットワークポリシーを確認し、変更に問題がなければ [確認（Confirm）] をクリックします。Security Cloud Control は、選択したオブジェクトに置き換えて保持し、重複を削除します。リストにあるオブジェクトを無視する場合は、[無視（Ignore）] をクリックします。オブジェクトを無視すると、Security Cloud Control が表示する重複オブジェクトのリストから削除されます。オブジェクトを保持するものの、重複オブジェクトの検索で Security Cloud Control に表示してほしくない場合は、[すべて無視（Ignore All）] をクリックします。
ステップ 7	重複オブジェクトの問題が解決したら、行った変更を今すぐレビューして展開するか、待機してから複数の変更を一度に展開します。

不整合または未使用のセキュリティゾーンオブジェクトを解決する

セキュリティゾーンオブジェクトは、他のオブジェクトと同様に、不整合または未使用としてマークできます。これらの問題を解決する方法については、「未使用オブジェクトの問題の解決」と「不整合オブジェクトの問題の解決」を参照してください。

未使用オブジェクトの問題の解決

未使用オブジェクトは、デバイス構成に存在するものの、別のオブジェクト、アクセスリスト、NAT ルールによって参照されていないオブジェクトです。

未使用オブジェクトの問題の解決

手順

ステップ 1

左側のペインで、[オブジェクト（Objects）] をクリックして、オプションを選択します。

ステップ 2

次に、オブジェクトをフィルタ処理して、未使用オブジェクトの問題を見つけます。

ステップ 3

1 つ以上の未使用のオブジェクトを選択します。

ステップ 4

以下のオプションがあります。

操作ウィンドウで [削除（Remove）] をクリックして、未使用のオブジェクトを Security Cloud Control から削除します。
[問題（Issues）] ペインで、[無視（Ignore）] をクリックします。オブジェクトを無視すると、Security Cloud Control は未使用のオブジェクトの結果にそのオブジェクトを表示しなくなります。

ステップ 5

未使用のオブジェクトを削除した場合は、行った変更を今すぐすべてのデバイスの設定変更のプレビューと展開か、待機してから複数の変更を一度に展開します。

（注）

未使用のオブジェクトの問題を一括で解決するには、「オブジェクトの問題を一括で解決する」を参照してください。

未使用オブジェクトの一括削除

手順

ステップ 1	左側のペインで、[オブジェクト（Objects）] をクリックして、オプションを選択します。
ステップ 2	次に、オブジェクトをフィルタ処理して、未使用オブジェクトの問題を見つけます。
ステップ 3	削除する未使用のオブジェクトを選択します。ページ上のすべてのオブジェクトを選択するには、オブジェクトテーブルのヘッダー行にあるチェックボックスをクリックします。オブジェクトテーブルで未使用のオブジェクトを個別に選択します。
ステップ 4	右側の [アクション（Actions）] ペインで [削除（Remove）] をクリックして、Security Cloud Control で選択した未使用のオブジェクトをすべて削除します。99 個のオブジェクトを同時に削除できます。
ステップ 5	[OK] をクリックして、未使用のオブジェクトを削除することを確認します。
ステップ 6	これらの変更の展開には、つぎの 2 つの方法があります。行った変更を今すぐレビューして展開するか、待機してから複数の変更を一度に展開します。 [インベントリ] ページを開き、変更の影響を受けたデバイスを特定します。変更の影響を受けるすべてのデバイスを選択し、[管理（Management）] ペインで [すべて展開（Deploy All）] をクリックします。警告を読み、適切なアクションを実行します。

不整合オブジェクトの問題を解決する

不整合オブジェクトとは、2 つ以上のデバイス上にある、名前は同じだが値は異なるオブジェクトです。ユーザーが異なる構成の中で、同じ名前と内容のオブジェクトを作成することがあります。これらのオブジェクトの値が時間の経過につれて相互に異なる値になり、不整合が生じます。

注：不整合オブジェクトの問題を一括で解決するには、「オブジェクトの問題を一括で解決する」を参照してください。

不整合オブジェクトに対して次のことを実行できます。

[無視（Ignore）]：Security Cloud Control は、オブジェクト間の不整合を無視し、それらの値を保持します。このオブジェクトは、不整合カテゴリに表示されなくなります。
[マージ（Merge）]：Security Cloud Control は、選択されているすべてのオブジェクトとその値を 1 つのオブジェクトグループに結合します。
[名前の変更（Rename）]：Security Cloud Control で、不整合オブジェクトの 1 つの名前を変更し、新しい名前を付けることができます。

[共有ネットワークオブジェクトのオーバーライドへの変換（Convert Shared Network Objects to Overrides）]：Security Cloud Control で、不整合のある共有オブジェクトを（オーバーライドの有無にかかわらず）、オーバーライドのある単一の共有オブジェクトに結合できます。不整合オブジェクトの最も一般的なデフォルト値が、新しく形成されるオブジェクトのデフォルトとして設定されます。

（注）

共通のデフォルト値が複数ある場合は、そのうちの一つがデフォルトとして選択されます。残りのデフォルト値とオーバーライド値は、そのオブジェクトのオーバーライドとして設定されます。

[共有ネットワークグループの追加の値への変換（Convert Shared Network Group to Additional Values）]：Security Cloud Control で、不整合のある共有ネットワークグループを、追加の値のある単一の共有ネットワークグループに結合できます。この機能の基準は、「変換される不整合ネットワークグループに、同じ値を持つ少なくとも 1 つの共通オブジェクトが必要である」というものです。この基準に一致するすべてのデフォルト値がデフォルト値になり、残りのオブジェクトは、新しく形成されるネットワークグループの追加の値として割り当てられます。

たとえば、不整合のある 2 つの共有ネットワークグループがあるとします。1 つ目のネットワークグループ「shared_network_group」は、「object_1」（192.0.2.x）と「object_2」（192.0.2.y）で形成されています。また、追加の値「object_3」（192.0.2.a）も含まれています。2 つ目のネットワークグループ「shared_network_group」は、「object_1」（192.0.2.x）と追加の値「object_4」（192.0.2.b）で形成されます。共有ネットワークグループを追加の値に変換すると、新しく形成されるグループ「shared_network_group」には、デフォルト値として「object_1」（192.0.2.x）と「object_2」（192.0.2.y）が含まれ、追加の値として「object_3」（192.0. 2.a）と「object_4」（192.0.2.b）が含まれます。

（注）

新しいネットワークオブジェクトを作成すると、Security Cloud Control は、その値を同じ名前の既存の共有ネットワークオブジェクトへのオーバーライドとして自動的に割り当てます。これは、新しいデバイスが Security Cloud Control にオンボードされる場合にも当てはまります。

自動割り当ては、次の条件が満たされている場合にのみ発生します。

新しいネットワークオブジェクトがデバイスに割り当てられる必要があります。
テナントには、同じ名前とタイプの共有オブジェクトが 1 つだけ存在する必要があります。
共有オブジェクトには、すでにオーバーライドが含まれている必要があります。

不整合オブジェクトの問題を解決するには、次の手順を実行します。

手順

ステップ 1	左側の Security Cloud Control ナビゲーションバーで、[オブジェクト（Objects）] をクリックして、オプションを選択します。
ステップ 2	次に、オブジェクトをフィルタ処理して、不整合オブジェクトの問題を見つけます。
ステップ 3	不整合オブジェクトを選択します。オブジェクトの詳細パネルに、該当するオブジェクトの数を示す [不整合（INCONSISTENT）] フィールドが表示されます。
ステップ 4	[解決（Resolve）] をクリックします。Security Cloud Control は、不整合オブジェクトを比較できるように表示します。
ステップ 5	以下のオプションがあります。 [すべて無視（Ignore All）]：提示されるオブジェクトを比較し、いずれかのオブジェクトで [無視（Ignore）] をクリックします。または、すべてのオブジェクトを無視するために、[すべて無視（Ignore All）] をクリックします。 [OK] をクリックして確認します。 [オブジェクトをマージして解決（Resolve by merging objects）]： [X つのオブジェクトをマージして解決（Resolve by Merging X Objects）] をクリックします。 [確認（Confirm）] をクリックします。 [名前の変更（Rename）]： [名前の変更（Rename）] をクリックします。該当するネットワークポリシーおよびデバイスへの変更を保存し、[確認（Confirm）] をクリックします。 [オーバーライドへの変換（Convert to Overrides）]（不整合のある共有オブジェクトの場合）：共有オブジェクトをオーバーライドと比較する場合、比較パネルには、[不整合のある値（Inconsistent Values）] フィールドのデフォルト値のみが表示されます。 [オーバーライドへの変換（Convert to Overrides）] をクリックします。すべての不整合オブジェクトは、オーバーライドを持つ単一の共有オブジェクトに変換されます。 [確認（Confirm）] をクリックします。[共有オブジェクトの編集（Edit Shared Object）] をクリックすると、新しく形成されたオブジェクトの詳細が表示されます。上向き矢印と下向き矢印を使用して、デフォルトとオーバーライドの間で値を移動することができます。 [追加の値への変換（Convert to Additional Values）]（不整合のあるネットワークグループの場合）： [追加の値への変換（Convert to Additional Values）] をクリックします。すべての不整合オブジェクトは、追加の値を持つ単一の共有オブジェクトに変換されます。該当するネットワークポリシーおよびデバイスへの変更を保存し、[確認（Confirm）] をクリックします。
ステップ 6	不整合を解決したら、行った変更を今すぐレビューして展開するか、待機してから複数の変更を一度に展開します。

オブジェクトの問題を一度に解決する

未使用、重複、不整合オブジェクトの問題を解決するの問題のあるオブジェクトを解決する方法の 1 つは、それらを無視することです。オブジェクトに複数の問題がある場合でも、複数のオブジェクトを選択して無視できます。たとえば、オブジェクトに一貫性がなく、さらに未使用の場合、一度に無視できる問題タイプは 1 つだけです。

重要	後でオブジェクトが別の問題タイプに関連付けられた場合も、実行した無視アクションは、その時に選択した問題にのみ影響します。たとえば、重複していたためにオブジェクトを無視し、後でそのオブジェクトが不整合としてマークされた場合、そのオブジェクトを重複オブジェクトとして無視しても、不整合のオブジェクトとして無視されるわけではありません。

問題を一括で無視するには、以下の手順に従ってください。

手順

ステップ 1	左側のペインで、[オブジェクト（Objects）] をクリックして、オプションを選択します。
ステップ 2	検索を絞り込むために、オブジェクトの問題をフィルタ処理できます。
ステップ 3	オブジェクトテーブルで、無視するオブジェクトをすべて選択します。問題ペインでは、問題タイプごとにオブジェクトがグループ化されます。
ステップ 4	[無視（Ignore）] をクリックして、問題をタイプごとに無視します。各問題をタイプごとに無視する必要があります。
ステップ 5	[OK] をクリックして、それらのオブジェクトを無視することを確認します。

デバイスの接続状態

Security Cloud Control テナントにオンボードされたデバイスの接続状態を表示できます。このトピックは、さまざまな接続状態を理解するのに役立ちます。[インベントリ] ページの [接続] 列に、デバイスの接続状態が表示されます。

デバイスの接続状態が「オンライン」の場合、デバイスの電源がオンになっていて、Security Cloud Control に接続されていることを意味します。以下の表に記載されているその他の状態は、通常、さまざまな理由でデバイスに問題が発生した場合になります。この表は、このような問題から回復する方法を示しています。接続障害の原因となっている問題が複数ある可能性があります。再接続を試みると、Security Cloud Control は、再接続を実行する前に、まずこれらの問題をすべて解決するように求めます。


デバイスの接続状態	考えられる原因	解像度
オンライン（Online）	デバイスの電源が入っていて、Security Cloud Control に接続されています。	NA
オフライン	デバイスの電源が切れているか、ネットワーク接続が失われています。	デバイスがオフラインかどうかを確認します。
Insufficient licenses	デバイスに十分なライセンスがありません。	ライセンス不足のトラブルシュート
クレデンシャルが無効である	Security Cloud Control がデバイスに接続するために使用するユーザー名とパスワードの組み合わせが正しくありません。	無効なログイン情報のトラブルシューティング
オンボーディング	デバイスのオンボーディングが開始されましたが、完了していません。	デバイスの接続を確認し、デバイスの登録を完了させてください。
保留中のセットアップ	デバイスの登録に失敗しました。	CLI 登録キーを使用したクラウド提供型 Firewall Management Center へのデバイスオンボーディングのトラブルシュート
New Certificate Detected	このデバイスの証明書が変更されました。デバイスが自己署名証明書を使用している場合、これはデバイスの電源を再投入したために発生した可能性があります。	新規証明書の問題のトラブルシュート
Device Unregistered	FDM による管理デバイスが、FDM 経由でクラウドから登録解除されました。	登録解除されたデバイスのトラブルシュート
要求エラー	Security Cloud Control が FDM による管理デバイスの要求に失敗しました。考えられる理由として、無効なシリアル番号が入力されたか、デバイスのシリアル番号がすでに要求されていることが考えられます。	要求エラーのトラブルシュート
オンボーディングエラー	Security Cloud Control がオンボーディング時にデバイスとの接続を失った可能性があります。	オンボーディングエラーのトラブルシュート
プロビジョニングエラー	FDM による管理デバイスの初期プロビジョニングが失敗しました。	プロビジョニングエラーのトラブルシュート
到達不能	Device is powered down. デバイスの IP アドレスが変更されました。デバイスが Cisco Cloud から削除されました。	到達不能の接続状態のトラブルシュート

登録解除されたデバイスのトラブルシュート

FDM による管理デバイスが、Firewall Device Manager 経由でクラウドから登録解除されていることがあります。

以下の手順を実行して、デバイスをクラウドに再登録します。

手順

ステップ 1	[インベントリ（Inventory）] ページで [デバイス（Devices）] タブをクリックします。
ステップ 2	[FTD] タブをクリックし、[デバイスの登録が解除されました（Device Unregistered）] 状態のデバイスを選択し、右側でエラーメッセージを確認します。
ステップ 3	登録解除されたデバイスが登録キーを使用してオンボーディングされた場合、以前に適用されたキーの有効期限が切れているため、Security Cloud Control は新しい登録キーを生成するように求めます。 [更新（Refresh）] ボタンをクリックして新しい登録キーを生成し、コピーアイコンをクリックします。 Security Cloud Control に再登録するデバイスの Firewall Device Manager にログインします。 [システム設定（System Settings）] で、[クラウドサービス（Cloud Services）] をクリックします。 Security Cloud Control 領域で、[始める（Get Started）] を展開します。 [登録キー（Registration Key）] フィールドに、Security Cloud Control で生成した登録キーを貼り付けます。 [登録（Register）] をクリックし、[シスコの開示情報を受け入れる（Accept the Cisco Disclosure）] をクリックします。Firewall Device Manager により登録要求が Security Cloud Control に送信されます。デバイスの接続状態が [読み取りエラー（Read Error）] に変わるまで、Security Cloud Control の [インベントリ（Inventory）] ページを更新します。 Security Cloud Control の [設定の読み取り（Read Configuration）] をクリックして、デバイスから設定を読み取ります。
ステップ 4	登録解除されたデバイスがシリアル番号を使用してオンボーディングされた場合、Security Cloud Control は Firewall Device Manager からデバイスを自動登録するように求めます。 Security Cloud Control に再登録するデバイスの Firewall Device Manager にログインします。 [システム設定（System Settings）] で、[クラウドサービス（Cloud Services）] をクリックします。 [CDOからテナントへの自動登録（Auto-enroll with Tenancy from Security Cloud Control）] オプションを選択して [登録（Register）] をクリックします。デバイスの接続状態が [読み取りエラー（Read Error）] に変わるまで、Security Cloud Control の [インベントリ（Inventory）] ページを更新します。 Security Cloud Control の [設定の読み取り（Read Configuration）] をクリックして、デバイスから設定を読み取ります。

ライセンス不足のトラブルシュート

デバイスの接続ステータスに [ライセンスが不足しています（Insufficient License）] と表示される場合は、以下の手順を実行します。

デバイスがライセンスを取得するまでしばらく待ちます。通常、Cisco Smart Software Manager が新しいライセンスをデバイスに適用するには時間がかかります。
デバイスのステータスが変わらない場合は、Security Cloud Control からサインアウトしてから再度サインインすることで Security Cloud Control ポータルを更新して、ライセンスサーバーとデバイスとの間のネットワーク通信の不具合を解決します。
ポータルを更新してもデバイスのステータスが変更されない場合は、次の手順を実行します。

手順

ステップ 1	Cisco Smart Software Manager から新しいトークンを生成し、コピーします。詳細については、スマートライセンスの生成に関するビデオをご覧ください。
ステップ 2	左側のペインでセキュリティデバイスをクリックします。
ステップ 3	[デバイス] タブをクリックします。
ステップ 4	適切なデバイスタイプのタブをクリックし、ステータスが [ライセンスが不足しています（Insufficient License）] のデバイスを選択します。
ステップ 5	[デバイスの詳細（Device Details）] ペインで、 [ライセンスが不足しています（Insufficient License）] に表示される [ライセンスの管理（Manage Licenses）] をクリックします。[ライセンスの管理（Manage Licenses）] ウィンドウが表示されます。
ステップ 6	[アクティブ化（Activate）] フィールドで、新しいトークンを貼り付けて [デバイスの登録（Register Device）] をクリックします。トークンがデバイスに正常に適用されると、接続状態が [オンライン（Online）] に変わります。

無効なログイン情報のトラブルシューティング

無効なログイン情報によるデバイスの切断を解決するには、次の手順を実行します。

手順

ステップ 1	左側のペインでセキュリティデバイスをクリックします。
ステップ 2	[デバイス] タブをクリックします。
ステップ 3	適切なデバイスタイプのタブをクリックし、ステータスが [無効なログイン情報（Invalid Credentials）] のデバイスを選択します。
ステップ 4	[デバイスの詳細（Device Details）] ペインで、[無効なログイン情報（Invalid Credentials）] に表示される [再接続（Reconnect）] をクリックします。Security Cloud Control は、デバイスとの再接続を試みます。
ステップ 5	デバイスの新しいユーザー名とパスワードの入力を求められたら、
ステップ 6	[続行（Continue）] をクリックします。
ステップ 7	デバイスがオンラインになり、使用できる状態となったら、[閉じる（Close）] をクリックします。
ステップ 8	Security Cloud Control がデバイスへの接続に誤った間違ったログイン情報を使用しようとしたため、デバイスへの接続に Security Cloud Control が使用するユーザー名とパスワードの組み合わせが、デバイス上で直接変更された可能性があります。デバイスは「オンライン」ですが、構成ステータスは [競合が検出されました（Conflict Detected）] であることがわかります。[構成の競合の解決（Resolve Configuration Conflicts）] を使用して、Security Cloud Control とデバイス間の構成の差異を確認して解決します。設定の競合の解決

新規証明書の問題のトラブルシュート

Security Cloud Control の証明書の使用

Security Cloud Control は、デバイスに接続するときに証明書の有効性をチェックします。具体的には、Security Cloud Control は次のことを要求します。

デバイスで TLS バージョン 1.0 以降を使用している。
デバイスにより提示される証明書が有効期限内であり、発効日が過去の日付である（すなわち、すでに有効になっており、後日に有効化されるようにスケジュールされていない）。
証明書は、SHA-256 証明書であること。SHA-1 証明書は受け入れられません。
次のいずれかが該当すること。
- デバイスは自己署名証明書を使用し、その証明書は認可されたユーザーにより信頼された最新の証明書と同じである。
- デバイスは、信頼できる認証局（CA）が署名した証明書を使用し、提示されたリーフ証明書から関連 CA にリンクしている証明書チェーンを形成している。

これらは、ブラウザとは異なる Security Cloud Control の証明書の使用方法です。

自己署名証明書の場合、Security Cloud Control は、デバイスのオンボーディングまたは再接続時に、ドメイン名チェックを無効にして、代わりに、その証明書が承認ユーザーによって信頼された証明書と完全に一致することをチェックします。
Security Cloud Control は、まだ内部 CA をサポートしていません。現時点では、内部 CA によって署名された証明書をチェックする方法はありません。

ASA デバイスの証明書チェックを、デバイスごとに無効にすることができます。ASA の証明書を Security Cloud Control が信頼できない場合、そのデバイスの証明書チェックを無効にするオプションがあります。デバイスの証明書チェックの無効化を試みても依然としてデバイスをオンボードできない場合は、デバイスに関して指定した IP アドレスおよびポートが正しくないか到達可能ではない可能性があります。証明書チェックをグローバルに無効にする方法、またはサポートされている証明書を持つデバイスの証明書チェックを無効にする方法はありません。非 ASA デバイスの証明書チェックを無効にする方法はありません。

デバイスの証明書チェックを無効にしても、Security Cloud Control は、引き続き TLS を使用してデバイスに接続しますが、接続の確立に使用される証明書を検証しません。つまり、パッシブ中間者攻撃者は接続を盗聴できませんが、アクティブ中間攻撃者は、無効な証明書を Security Cloud Control に提供することによって、接続を傍受する可能性があります。

証明書の問題の特定

いくつかの理由で Security Cloud Control がデバイスをオンボードできない場合があります。UI に「Security Cloud Control は、提示された証明書を使用してデバイスに接続できません（CDO cannot connect to the device using the certificate presented）」というメッセージが表示される場合は、証明書に問題があります。このメッセージが UI に表示されない場合は、問題が接続の問題 (デバイスに到達できない) またはその他のネットワークエラーに関連している可能性が高くなります。

Security Cloud Control が特定の証明書を拒否する理由を判断するには、SDC ホスト、または関連デバイスに到達できる別のホストで、openssl コマンドラインツールを使用します。次のコマンドを使用して、デバイスによって提示された証明書を示すファイルを作成します。

openssl s_client -showcerts -connect <host>:<port> &> <filename>.txt

このコマンドでは、対話型セッションが開始されるため、数秒後に Ctrl+C キーを押して終了する必要があります。

次のような出力を含むファイルが作成されます。

depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA 
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 
verify return:1 
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com 
verify return:1 CONNECTED(00000003)
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com 
  i:/C=US/O=Google Inc/CN=Google Internet Authority G2
-----BEGIN CERTIFICATE----- 
MIIH0DCCBrigAwIBAgIIUOMfH+8ftN8wDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE 
....lots of base64... 
tzw9TylimhJpZcl4qihFVTgFM7rMU2VHulpJgA59gdbaO/Bf
-----END CERTIFICATE-----
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 
  i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 
-----BEGIN CERTIFICATE----- 
MIID8DCCAtigAwIBAgIDAjqSMA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT 
....lots of base64... 
tzw9TylimhJpZcl4qihFVTgFM7rMU2VHulpJgA59gdbaO/Bf 
-----END CERTIFICATE----- 
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 
  i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 
-----BEGIN CERTIFICATE----- 
MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT 
....lots of base64... 
b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S 
-----END CERTIFICATE-----
--- 
Server certificate 
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com 
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2 
---
No client certificate CA names sent 
Peer signing digest: SHA512 
Server Temp Key: ECDH, P-256, 256 bits

--- 
SSL handshake has read 4575 bytes and written 434 bytes 
--- 
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 
Server public key is 2048 bit Secure Renegotiation IS supported 
Compression: NONE 
Expansion: NONE 
No ALPN negotiated 
SSL-Session:    
    Protocol : TLSv1.2 
    Cipher : ECDHE-RSA-AES128-GCM-SHA256 
    Session-ID: 48F046F3360225D51BE3362B50CE4FE8DB6D6B80B871C2A6DD5461850C4CF5AB 
    Session-ID-ctx: 
    Master-Key: 9A9CCBAA4F5A25B95C37EF7C6870F8C5DD3755A9A7B4CCE4535190B793DEFF53F94203AB0A62F9F70B9099FBFEBAB1B6 
    Key-Arg : None 
    PSK identity: None 
    PSK identity hint: None 
    SRP username: None 
    TLS session ticket lifetime hint: 100800 (seconds) 
    TLS session ticket: 
    0000 - 7a eb 54 dd ac 48 7e 76-30 73 b2 97 95 40 5b de z.T..H~v0s...@[. 
    0010 - f3 53 bf c8 41 36 66 3e-5b 35 a3 03 85 6f 7d 0c .S..A6f>[5...o}. 
    0020 - 4b a6 90 6f 95 e2 ec 03-31 5b 08 ca 65 6f 8f a6 K..o....1[..eo.. 
    0030 - 71 3d c1 53 b1 29 41 fc-d3 cb 03 bc a4 a9 33 28 q=.S.)A.......3( 
    0040 - f8 c8 6e 0a dc b3 e1 63-0e 8f f2 63 e6 64 0a 36 ..n....c...c.d.6 
    0050 - 22 cb 00 3a 59 1d 8d b2-5c 21 be 02 52 28 45 9d "..:Y...\!..R(E. 
    0060 - 72 e3 84 23 b6 f0 e2 7c-8a a3 e8 00 2b fd 42 1d r..#...|....+.B. 
    0070 - 23 35 6d f7 7d 85 39 1c-ad cd 49 f1 fd dd 15 de #5m.}.9...I..... 
    0080 - f6 9c ff 5e 45 9c 7c eb-6b 85 78 b5 49 ea c4 45 ...^E.|.k.x.I..E 
    0090 - 6e 02 24 1b 45 fc 41 a2-87 dd 17 4a 04 36 e6 63 n.$.E.A....J.6.c 
    00a0 - 72 a4 ad 
    00a4 - <SPACES/NULS> Start Time: 1476476711 Timeout : 300 (sec)
Verify return code: 0 (ok)
---

この出力では、最初に、確認リターン（verify return）コードが示されている最後の行に注目してください。証明書に関する問題が存在する場合、このリターンコードはゼロ以外になり、エラーの説明が表示されます。

この証明書エラーコードのリストを展開して、一般的なエラーとその修正方法を確認してください。

0 X509_V_OK：操作が成功しました。

2 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT：信頼できない証明書の発行者証明書が見つかりませんでした。

3 X509_V_ERR_UNABLE_TO_GET_CRL：証明書の CRL が見つかりませんでした。

4 X509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE：証明書の署名を復号できませんでした。これは、実際の署名値が、期待値と一致しないのではなく、判別できなかったことを意味します。これは、RSA キーについてのみ意味を持ちます。

5 X509_V_ERR_UNABLE_TO_DECRYPT_CRL_SIGNATURE：CRL の署名を復号できませんでした。これは、実際の署名値が、期待値と一致しないのではなく、判別できなかったことを意味します。未使用。

6 X509_V_ERR_UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY：証明書 SubjectPublicKeyInfo の公開キーを読み取れませんでした。

7 X509_V_ERR_CERT_SIGNATURE_FAILURE：証明書の署名が無効です。

8 X509_V_ERR_CRL_SIGNATURE_FAILURE：証明書の署名が無効です。

9 X509_V_ERR_CERT_NOT_YET_VALID：証明書がまだ有効ではありません（notBefore の日付が現在時刻より後です）。詳細については、この後の「確認リターンコード：9（証明書がまだ有効ではありません）」を参照してください。

10 X509_V_ERR_CERT_HAS_EXPIRED：証明書の有効期限が切れています（notAfter の日付が現在時刻より前です）。詳細については、この後の「確認リターンコード：10（証明書の有効期限が切れています）」を参照してください。

11 X509_V_ERR_CRL_NOT_YET_VALID：CRL がまだ有効ではありません。

12 X509_V_ERR_CRL_HAS_EXPIRED：CRL の有効期限が切れています。

13 X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD：証明書の notBefore フィールドに無効な時刻が含まれています。

14 X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD：証明書の notAfter フィールドに無効な時刻が含まれています。

15 X509_V_ERR_ERROR_IN_CRL_LAST_UPDATE_FIELD：CRL の lastUpdate フィールドに無効な時刻が含まれています。

16 X509_V_ERR_ERROR_IN_CRL_NEXT_UPDATE_FIELD：CRL の nextUpdate フィールドに無効な時刻が含まれています。

17 X509_V_ERR_OUT_OF_MEM：メモリを割り当てようとしてエラーが発生しました。これは決して発生しないはずの問題です。

18 X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT：渡された証明書は自己署名済みであり、信頼できる証明書のリストに同じ証明書が見つかりません。

19 X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN：信頼できない証明書を使用して証明書チェーンを構築できましたが、ルートがローカルで見つかりませんでした。

20 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY：ローカルでルックアップされた証明書の発行者証明書が見つかりませんでした。これは、通常、信頼できる証明書のリストが完全ではないことを意味します。

21 X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE：チェーンに証明書が 1 つしか含まれておらず、それが自己署名済みでないため、署名を検証できませんでした。詳細については、この後の「確認リターンコード：21（最初の証明書を検証できません）」を参照してください。詳細については、この後の「確認リターンコード：21（最初の証明書を検証できません）」を参照してください。

22 X509_V_ERR_CERT_CHAIN_TOO_LONG：証明書チェーンの長さが、指定された最大深度を超えています。未使用。

23 X509_V_ERR_CERT_REVOKED：証明書が失効しています。

24 X509_V_ERR_INVALID_CA：CA 証明書が無効です。CA ではないか、その拡張領域が、提供された目的と一致していません。

25 X509_V_ERR_PATH_LENGTH_EXCEEDED：basicConstraints の pathlength パラメータを超えています。

26 X509_V_ERR_INVALID_PURPOSE：提供された証明書を、指定された目的に使用できません。

27 X509_V_ERR_CERT_UNTRUSTED：ルート CA が、指定された目的に関して信頼できるものとしてマークされていません。

28 X509_V_ERR_CERT_REJECTED：ルート CA が、指定された目的を拒否するようにマークされています。

29 X509_V_ERR_SUBJECT_ISSUER_MISMATCH：件名が現在の証明書の発行者名と一致しないため、現在の候補発行者証明書が拒否されました。-issuer_checks オプションが設定されている場合にのみ表示されます。

30 X509_V_ERR_AKID_SKID_MISMATCH：件名キー識別子が存在し、現在の証明書の認証局キー識別子と一致しないため、現在の候補発行者証明書が拒否されました。-issuer_checks オプションが設定されている場合にのみ表示されます。

31 X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH：発行者名とシリアル番号が存在し、現在の証明書の認証局キー識別子と一致しないため、現在の候補発行者証明書が拒否されました。-issuer_checks オプションが設定されている場合にのみ表示されます。

32 X509_V_ERR_KEYUSAGE_NO_CERTSIGN：keyUsage 拡張領域が証明書の署名を許可していないため、現在の候補発行者証明書が拒否されました。

50 X509_V_ERR_APPLICATION_VERIFICATION：アプリケーション固有のエラーです。未使用。

「New Certificate Detected」メッセージ

自己署名証明書を持つデバイスをアップグレードして、アップグレードプロセス後に新しい証明書が生成された場合、Security Cloud Control で、[設定（Configuration）] ステータスと [接続（Connectivity）] ステータスの両方として、「新しい証明書が検出されました（New Certificate Detected）」というメッセージが生成されることがあります。このデバイスを引き続き Security Cloud Control から管理するには、この問題を手動で確認して解決する必要があります。証明書が同期されて、デバイスの状態が正常になったら、このデバイスを管理できます。

（注）

複数の管理対象デバイスを Security Cloud Control に同時に一括再接続すると、Security Cloud Control は、デバイス上の新しい証明書を自動的に確認して受け入れ、それらとの再接続を続行します。

新しい証明書を解決するには、次の手順を使用します。

左側のペインでセキュリティデバイスをクリックします。
フィルタを使用して、接続ステータスまたは設定ステータスが [新しい証明書が検出されました（New Certificate Detected）] であるデバイスを表示し、必要なデバイスを選択します。
操作ウィンドウで、[証明書の確認（Review Certificate）] をクリックします。Security Cloud Control では、確認のために証明書をダウンロードし、新しい証明書を受け入れることができます。
[デバイス同期（Device Sync）] ウィンドウで [承認（Accept）] をクリックするか、[デバイスへの再接続（Reconnecting to Device）] ウィンドウで [続行（Continue）] をクリックします。

Security Cloud Control は、デバイスを新しい自己署名証明書と自動的に同期します。場合によっては、同期されたデバイスを表示するためにページを手動で更新する必要があります。

証明書エラーコード

確認リターンコード：0（OK）（ただし、Security Cloud Control は証明書エラーを返します）

Security Cloud Control は、証明書を取得すると、「https://<device_ip>:<port>」への GET コールを実行することにより、デバイスの URL への接続を試みます。これが機能しない場合、Security Cloud Control は証明書エラーを表示します。証明書が有効である（openssl が 0 つまり OK を返します）ことがわかった場合、接続しようとしているポートで別のサービスがリッスンしている可能性があります。この場合、次のコマンドを使用できます。

 curl -k -u <username>:<password> https://<device_id>:<device_port>/admin/exec/show%20version

これにより、次のように、ASA と確実に通信しているかどうかを確認することができ、HTTPS サーバーが ASA の正しいポートで動作しているかどうかをチェックすることもできます。

 # show asp table socket
Protocol         Socket         State         Local Address             Foreign Address 
SSL             00019b98         LISTEN        192.168.1.5:443             0.0.0.0:* 
SSL             00029e18         LISTEN        192.168.2.5:443             0.0.0.0:* 
TCP             00032208         LISTEN        192.168.1.5:22              0.0.0.0:*

確認リターンコード：9（証明書がまだ有効ではありません）

このエラーは、提供された証明書の発行日が将来の日付であるため、クライアントがそれを有効なものとして扱わないことを意味します。これは、証明書の不完全な作成が原因である可能性があります。また、自己署名証明書の場合は、証明書生成時のデバイスの時刻が間違っていたことが原因である可能性があります。

エラーには、証明書の notBefore の日付が含まれた行があります。

depth=0 CN = ASA Temporary Self Signed Certificate 
verify error:num=18:self signed certificate 
verify return:1 
depth=0 CN = ASA Temporary Self Signed Certificate 
verify error:num=9:certificate is not yet valid
notBefore=Oct 21 19:43:15 2016 GMT 
verify return:1 
depth=0 CN = ASA Temporary Self Signed Certificate 
notBefore=Oct 21 19:43:15 2016 GMT

このエラーから、証明書がいつ有効になるかを判別できます。

修復

証明書の notBefore の日付は過去の日付である必要があります。notBefore の日付をより早い日付にして証明書を再発行できます。この問題は、クライアントまたは発行デバイスのいずれかで時刻が正しく設定されていない場合にも発生する可能性があります。

確認リターンコード：10（証明書の有効期限が切れています）

このエラーは、提供された証明書の少なくとも 1 つの期限が切れていることを意味します。エラーには、証明書の notBefore の日付が含まれた行があります。

 error 10 at 0 depth lookup:certificate has expired

この有効期限は、証明書の本文に含まれています。

修復

証明書が本当に期限切れの場合、唯一の修復方法は、別の証明書を取得することです。証明書の有効期限が将来の日付であるのに、openssl が期限切れであると主張する場合は、コンピュータの日付と時刻をチェックしてください。たとえば、証明書が 2020 年に期限切れになるように設定されているのに、コンピュータの日付が 2021 年になっている場合、そのコンピュータは証明書を期限切れとして扱います。

確認リターンコード：21（最初の証明書を検証できません）

このエラーは、証明書チェーンに問題があることと、デバイスによって提示された証明書を信頼できることを openssl が検証できないことを示しています。ここで、上記の例の証明書チェーンを調べて、証明書チェーンがどのように機能するのかを見てみましょう。

--- 
Certificate chain 
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com 
i:/C=US/O=Google Inc/CN=Google Internet Authority G2

-----BEGIN CERTIFICATE----- 
MIIH0DCCBrigAwIBAgIIUOMfH+8ftN8wDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE 
....lots of base64... 
tzw9TylimhJpZcl4qihFVTgFM7rMU2VHulpJgA59gdbaO/Bf 
-----END CERTIFICATE----- 

1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 

-----BEGIN CERTIFICATE----- 
MIID8DCCAtigAwIBAgIDAjqSMA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT 
....lots of base64... 
tzw9TylimhJpZcl4qihFVTgFM7rMU2VHulpJgA59gdbaO/Bf 
-----END CERTIFICATE----- 

2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 

-----BEGIN CERTIFICATE----- 
MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT 
....lots of base64... 
b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S 
-----END CERTIFICATE----- ---

証明書チェーンとは、サーバーによって提示される証明書のリストです。このリストは、サーバー自体の証明書から始まり、そのサーバーの証明書を認証局の最上位の証明書に結び付ける、段階的により上位の中間証明書が含まれます。各証明書には、その件名（「s:」で始まる行）とその発行者（「i」で始まる行）のリストが示されています。

件名は、証明書によって識別されるエンティティです。これには、組織名が含まれており、場合によっては証明書の発行先エンティティの共通名も含まれます。

発行者は、証明書を発行したエンティティです。これには、組織フィールドも含まれており、場合によっては共通名も含まれます。

サーバーは、信頼できる認証局によって直接発行された証明書を持っている場合、証明書チェーンに他の証明書を含める必要がありません。次のような 1 つの証明書が表示されます。

--- Certificate chain 0 s:/C=US/ST=California/L=Anytown/O=ExampleCo/CN=*.example.com i:/C=US/O=Trusted Authority/CN=Trusted Authority 
-----BEGIN CERTIFICATE----- 
MIIH0DCCBrigAwIBAgIIUOMfH+8ftN8wDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE 
....lots of base64... 
tzw9TylimhJpZcl4qihFVTgFM7rMU2VHulpJgA59gdbaO/Bf 
-----END CERTIFICATE----- ---

この証明書を提供すると、openssl は、*.example.com の ExampleCo 証明書が、openssl の組み込み信頼ストアに存在する信頼できる認証局の証明書によって正しく署名されていることを検証します。その検証の後に、openssl は、デバイスに正常に接続します。

ただし、ほとんどのサーバーには、信頼できる CA によって直接署名された証明書がありません。代わりに、最初の例のように、サーバーの証明書は 1 つ以上の中間証明書によって署名されており、最上位の中間証明書が、信頼できる CA によって署名された証明書を持ちます。OpenSSL は、デフォルトでは、これらの中間 CA を信頼せず、信頼できる CA で終わる完全な証明書チェーンが提供されている場合にのみ、それらを検証できます。

中間認証局によって署名された証明書を持つサーバーが、信頼できる CA に結び付けられたすべての証明書（すべての中間証明書を含む）を提供することが非常に重要です。このチェーン全体が提供されない場合、openssl からの出力は次のようなものになります。

depth=0 OU = Example Unit, CN = example.com 
verify error:num=20:unable to get local issuer certificate 
verify return:1 

depth=0 OU = Example Unit, CN = example.com 
verify error:num=27:certificate not trusted 
verify return:1 

depth=0 OU = Example Unit, CN = example.com 
verify error:num=21:unable to verify the first certificate 
verify return:1

CONNECTED(00000003)

--- 
Certificate chain 
0 s:/OU=Example Unit/CN=example.com 
i:/C=US/ST=Massachusetts/L=Cambridge/O=Intermediate Authority/OU=http://certificates.intermediateauth...N=Intermediate Certification Authority/sn=675637734 
-----BEGIN CERTIFICATE-----
...lots of b64...
-----END CERTIFICATE-----
--- 
Server certificate 
subject=/OU=Example Unit/CN=example.com 
issuer=/C=US/ST=Massachusetts/L=Cambridge/O=Intermediate Authority/OU=http://certificates.intermediateauth...N=Intermediate Certification Authority/sn=675637734 
--- 
No client certificate CA names sent 
--- 
SSL handshake has read 1509 bytes and written 573 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA 
Server public key is 2048 bit 
Secure Renegotiation IS NOT supported 
Compression: NONE 
Expansion: NONE 
SSL-Session: 
Protocol : TLSv1 
Cipher : AES256-SHA 
Session-ID: 24B45B2D5492A6C5D2D5AC470E42896F9D2DDDD54EF6E3363B7FDA28AB32414B 
Session-ID-ctx: 
Master-Key: 21BAF9D2E1525A5B935BF107DA3CAF691C1E499286CBEA987F64AE5F603AAF8E65999BD21B06B116FE9968FB7C62EF7C 
Key-Arg : None 
Krb5 Principal: None 
PSK identity: None 
PSK identity hint: None 
Start Time: 1476711760 
Timeout : 300 (sec) 
Verify return code: 21 (unable to verify the first certificate) 
---

この出力は、サーバーが 1 つの証明書のみを提供しており、提供された証明書が信頼されたルート認証局ではなく中間認証局によって署名されていることを示しています。この出力には、特性検証エラーも示されています。

修復

この問題は、デバイスによって提示された証明書の設定が間違っているために発生します。この問題を修正して Security Cloud Control またはその他のプログラムがデバイスに安全に接続できるようにする唯一の方法は、正しい証明書チェーンをデバイスにロードして、接続しているクライアントに完全な証明書チェーンを提示することです。

中間 CA をトラストポイントに含めるには、次のいずれか（CSR が ASA で生成されたかどうかに応じて）のリンク先に記載されている手順に従ってください。

「New Certificate Detected」メッセージ

（注）

デバイスの一括再接続により、複数の管理対象デバイスを Security Cloud Control に同時に再接続すると、Security Cloud Control は、デバイス上の新しい証明書を自動的に確認して受け入れ、それらとの再接続を続行します。

新しい証明書を解決するには、次の手順を使用します。

手順

ステップ 1	左側のペインでセキュリティデバイスをクリックします。
ステップ 2	[デバイス] タブをクリックします。
ステップ 3	適切なデバイスタイプのタブをクリックします。
ステップ 4	フィルタを使用して、接続ステータスまたは設定ステータスが [新しい証明書が検出されました（New Certificate Detected）] であるデバイスを表示し、必要なデバイスを選択します。
ステップ 5	操作ウィンドウで、[証明書の確認（Review Certificate）] をクリックします。Security Cloud Control では、確認のために証明書をダウンロードし、新しい証明書を受け入れることができます。
ステップ 6	[デバイス同期（Device Sync）] ウィンドウで [承認（Accept）] をクリックするか、[デバイスへの再接続（Reconnecting to Device）] ウィンドウで [続行（Continue）] をクリックします。

Security Cloud Control は、デバイスを新しい自己署名証明書と自動的に同期します。場合によっては、同期されたデバイスを表示するためにページを手動で更新する必要があります。

オンボーディングエラーのトラブルシュート

デバイスのオンボーディングエラーは、さまざまな理由で発生する可能性があります。

次の操作を実行できます。

手順

ステップ 1

左側のペインでセキュリティデバイスをクリックします。

ステップ 2

適切なデバイスタイプのタブをクリックし、エラーが発生しているデバイスを選択します。場合によっては、右側にエラーの説明が表示されます。説明に記載されている必要なアクションを実行します。

または

ステップ 3

Security Cloud Control からデバイスインスタンスを削除し、デバイスのオンボーディングを再試行します。

競合検出ステータスの解決

Security Cloud Control を使用すると、ライブデバイスごとに競合検出を有効化または無効化できます。競合検出が有効になっていて、Security Cloud Control を使用せずにデバイスの設定に変更が加えられた場合、デバイスの設定ステータスには [競合検出（Conflict Detected）] と表示されます。

[競合検出（Conflict Detected）] ステータスを解決するには、次の手順に従います。

手順

ステップ 1

ナビゲーションバーでセキュリティデバイスをクリックします。

（注）

オンプレミス Firewall Management Center の場合は、[管理（Administration）] > [Firewall Management Center] をクリックして、[未同期（Not Synced）] 状態の FMC を選択し、ステップ 5 から続行します。

ステップ 2

[デバイス（Devices）] タブをクリックして、デバイスを見つけます。

ステップ 3

適切なデバイスタイプのタブをクリックします。

ステップ 4

競合を報告しているデバイスを選択し、右側の詳細ペインで [競合の確認（Review Conflict）] をクリックします。

ステップ 5

[デバイスの同期（Device Sync）] ページで、強調表示されている相違点を確認して、2 つの設定を比較します。

「最後に認識されたデバイス設定（Last Known Device Configuration）」というラベルの付いたパネルは、Security Cloud Control に保存されているデバイス設定です。
[デバイスで検出（Found on Device）] というラベルの付いたパネルは、ASA の実行コンフィギュレーションに保存されている設定です。

ステップ 6

次のいずれかを選択して、競合を解決します。

[デバイスの変更を承認（Accept Device changes）]：設定と、Security Cloud Control に保存されている保留中の変更がデバイスの実行コンフィギュレーションで上書きされます。

（注）

Security Cloud Control はコマンドラインインターフェイス以外での Cisco IOS デバイスへの変更の展開をサポートしていないため、競合を解決する際の Cisco IOS デバイスの唯一の選択肢は [レビューなしで承認（Accept Without Review）] です。

[デバイスの変更を拒否（Reject Device Changes）]：デバイスに保存されている設定を Security Cloud Control に保存されている設定で上書きします。

（注）

拒否または承認されたすべての設定変更は、変更ログに記録されます。

未同期ステータスの解決

次の手順を使用して、「未同期」の設定ステータスのデバイスを解決します。

手順

ステップ 1

ナビゲーションバーでセキュリティデバイスをクリックします。

（注）

ステップ 2

[デバイス（Devices）] タブをクリックしてデバイスを見つけるか、[テンプレート（Templates）] タブをクリックしてモデルデバイスを見つけます。

ステップ 3

適切なデバイスタイプのタブをクリックします。

ステップ 4

未同期と報告されたデバイスを選択します。

ステップ 5

右側の [未同期（Not synced）] パネルで、次のいずれかを選択します。

[プレビューして展開...（Preview and Deploy..）] ：設定の変更を Security Cloud Control からデバイスにプッシュする場合は、今行った変更をプレビューして展開するか、待ってから一度に複数の変更を展開します。
[変更の破棄（Discard Changes）]：設定の変更を Security Cloud Control からデバイスにプッシュしない場合、または Security Cloud Control で開始した設定の変更を「元に戻す」場合。このオプションは、Security Cloud Control に保存されている設定を、デバイスに保存されている実行構成で上書きします。

到達不能の接続状態のトラブルシュート

デバイスは、さまざまな理由で「到達不能」になる可能性があります。

手順

ステップ 1

ナビゲーションバーで、[インベントリ（Inventory）] をクリックします。

ステップ 2

[デバイス（Devices）] タブをクリックして、デバイスを見つけます。

ステップ 3

適切なデバイスタイプのタブをクリックし、[到達不能（Unreachable）] 状態のデバイスを選択します。

ステップ 4

[再接続（Reconnect）]をクリックします。

ステップ 5

右側に表示されるメッセージに基づいて、次のいずれかのアクションを実行します。

IP アドレスとデバイスログイン情報を使用して FDM による管理デバイスをオンボードした場合、次のメッセージが表示されます。

「このデバイスには到達できません。IP アドレスとポートを確認してください」その後、メッセージボックスにデバイスの新しい IP アドレスまたは新しいポート情報を入力します。Security Cloud Control が無効な IP アドレスに接続しようとしたため、デバイスの IP アドレスがデバイス上で直接変更された可能性があります。

（注）

デバイスが再起動され、他に保留中の変更がない場合、デバイスはオンライン接続状態に戻ります。それ以上のアクションは必要ありません。

デバイスは「オンライン」ですが、構成ステータスは [競合が検出されました（Conflict Detected）] であることがわかります。[構成の競合の解決（Resolve Configuration Conflicts）]設定の競合の解決を使用して、Security Cloud Control とデバイス間の構成の差異を確認します。

登録トークンまたはシリアル番号を使用して FDM による管理デバイスをオンボードしている場合、次のメッセージが表示されます。

「このデバイスは Cisco Cloud から削除されました。返品許可（RMA）プロセスの一部として削除された可能性があります」。これは、RMA チームに返品された障害のあるデバイスが、RMA プロセスの一部として Cisco Cloud から削除されたことを意味します。

その結果、Security Cloud Control でのデバイスの接続ステータスが [到達不能（Unreachable）] となっています。

RMA ケースの場合、Security Cloud Control で次の手順を実行する必要があります。

デバイスが正常にオンボードされた場合は、デバイス構成をテンプレートとして保存する必要があります。「FDM テンプレートの設定」を参照してください。

Security Cloud Control からデバイスインスタンスを削除します。

RMA チームから受け取った新しい交換用デバイスの電源を入れ、Security Cloud Control にオンボードします。「デバイスのシリアル番号を使用した FDM 管理対象デバイスのオンボーディング」を参照してください。

重要	交換用デバイスのシリアル番号は異なる可能性が高いため、新しいデバイスとしてオンボードする必要があります。

デバイスは「オンライン」ですが、構成ステータスは [競合が検出されました（Conflict Detected）] であることがわかります。

[構成の競合の解決（Resolve Configuration Conflicts）]設定の競合の解決を使用して、Security Cloud Control とデバイス間の構成の差異を確認します。

以前に保存したテンプレートを新しいデバイスに適用します。「FDM テンプレートの適用」を参照してください。

デバイスを売却した場合、またはデバイスの構成を消去せずにテナントの外部の別のユーザーに所有権を譲渡した場合、デバイスの所有者ではなくなります。このエラーは、購入者がデバイスのイメージを再作成したときに発生します。デバイスが前もって正しく構成されて同期されている場合は、デバイス構成をテンプレートとして保存し、その後でデバイスインスタンスを Security Cloud Control から削除できます。

Cisco Security Cloud Control を使用した FDM デバイスの管理

偏向のない言語

翻訳について

検索結果

章のタイトル： トラブルシューティング

トラブルシューティング

FDM による管理 デバイスのトラブルシューティング

エグゼクティブ サマリー レポートのトラブルシュート

FDM 管理対象デバイスのオンボーディングのトラブルシュート

接続性

モジュールの不良構成

HTTP Authentication

ライセンス不足のために失敗

手順

登録解除されたデバイスのトラブルシュート

手順

登録キーを使用したオンボーディング中にデバイス登録の問題のトラブルシューティングを実行する

クラウドサービスの FQDN を解決できない

無効な登録キーのために失敗する

ライセンス不足のために失敗する

侵入防御システムのトラブルシュート

IPS ポリシーのオプションは何ですか?

すべてのデバイスに異なる IPS ポリシーを構成するにはどうすればよいですか?

FDM による管理 デバイスからオーバーライドが構成されているデバイスをオンボーディングしました。

SSL 暗号解読の問題のトラブルシューティング

復号再署名がブラウザでは機能するがアプリでは機能しない Web サイトの処理（SSL または認証局ピニング）

詳細

CA 証明書のダウンロードボタンが無効になっている

シリアル番号を使用した FDM による管理 デバイスのオンボーディングのトラブルシューティング

要求エラー

無効なシリアル番号

デバイスのシリアル番号がすでに要求されている

外部ベンダーから購入したデバイス

別の地域の別のクラウドテナントによってすでに管理されている FDM による管理 デバイスのオンボーディング

デバイスがオフラインである

デバイスの要求に失敗した

プロビジョニングエラー

デバイスのパスワードは変更されていません

デバイスパスワードがすでに変更されている

その他のエラーの場合

FDM による管理 HA 作成のトラブルシュート

イベントの説明エラー

HA を作成後、デバイスの 1 つが不良状態になります。

Secure Device Connector のトラブルシュート

SDC に到達不能

展開後 Security Cloud Control で SDC ステータスが [アクティブ（Active）] にならない

手順

SDC の変更された IP アドレスが Security Cloud Control に反映されない

デバイスと SDC の接続に関するトラブルシューティング

手順

SDC との断続的な接続または接続がない

手順

Secure Device Connector に影響を与えるコンテナ特権昇格の脆弱性：cisco-sa-20190215-runc

Security Cloud Control 標準の SDC ホストの更新

手順

カスタム SDC ホストを更新する

バグトラッキング

無効なシステム時刻

手順

次のタスク

SDC のバージョンが 202311**** より前

手順

次のタスク

AWS サーバーの証明書または接続エラー

手順

次のタスク

Secure Event Connector のトラブルシューティング

SEC オンボーディング失敗のトラブルシューティング

SEC のオンボーディングに失敗しました

SEC ブートストラップデータが指定されていません

ブートストラップ構成ファイルが存在しません

ブートストラップデータのデコードに失敗しました

ブートストラップデータに SEC をオンボードするために必要な情報がありません

ツールキット cron が現在実行中

十分な CPU とメモリがない

SEC がすでに実行中

SEC ドメインに到達不能

オンボーディング SEC コマンドはエラーなしで成功しましたが、SEC Docker コンテナが起動していません

Security Cloud Control サポートへの問い合わせ

Secure Event Connector の登録失敗のトラブルシューティング

章のタイトル：トラブルシューティング

FDM による管理デバイスのトラブルシューティング

エグゼクティブサマリーレポートのトラブルシュート

FDM による管理デバイスからオーバーライドが構成されているデバイスをオンボーディングしました。

シリアル番号を使用した FDM による管理デバイスのオンボーディングのトラブルシューティング

別の地域の別のクラウドテナントによってすでに管理されている FDM による管理デバイスのオンボーディング

イベントロギングのトラブルシューティングログファイル

トラブルシューティングスクリプトの実行

不整合または未使用のセキュリティゾーンオブジェクトを解決する