システム管理

ここでは、システム データベースの更新やシステムのバックアップおよび復元などの、システム管理タスクの実行方法について説明します。

ソフトウェア アップデートのインストール

システム データベースとシステム ソフトウェアの更新プログラムをインストールできます。ここでは、これらの更新プログラムのインストール方法について説明します。

システム データベースおよびフィードの更新

システムは、複数のデータベースおよびセキュリティ インテリジェンス フィードを使用して高度なサービスを提供します。シスコでは、セキュリティ ポリシーで最新の情報が使用されるよう、これらのデータベースおよびフィードに対する更新を提供しています。

システム データベースおよびフィードの更新の概要

Threat Defense は次のデータベースおよびフィードを使用して高度なサービスを提供します。

侵入ルール

新たな脆弱性が既知になると、Cisco Talos Intelligence Group（Talos） はユーザーがインポート可能な侵入ルールの更新をリリースします。それらの更新は、侵入ルール、プリプロセッサ ルール、およびルールを使用するポリシーに影響を及ぼします。

侵入ルールの更新には、新規および更新された侵入ルールとプリプロセッサ ルール、既存のルールの変更されたステータス、変更されたデフォルト侵入ポリシーの設定が含まれています。ルールの更新では、ルールが削除されたり、新しいルール カテゴリとデフォルトの変数が提供されたり、デフォルトの変数値が変更されたりすることもあります。

侵入ルールの更新によって行われた変更を有効にするには、設定を再展開する必要があります。

侵入ルールの更新は量が多くなることがあるため、ルールのインポートはネットワークの使用量が少ないときに実行してください。低速ネットワークでは、更新の試行が失敗し、再試行が必要になることがあります。

位置情報データベース（GeoDB）

シスコの地理位置情報データベース（GeoDB）は、ルーティング可能な IP アドレスに関連する地理情報データ（国、都市、緯度と経度など）のデータベースです。

GeoDB の更新には、検出されたルーティング可能な IP アドレスにシステムが関連付けることが可能な物理的な場所に関する更新情報が含まれています。位置情報データは、アクセス コントロール ルールとして使用できます。

GeoDB の更新にかかる時間はアプライアンスによって異なります。インストールには通常、30 ～ 40 分かかります。GeoDB の更新は他のシステムの機能（実行中の地理情報の収集など）を中断することはありませんが、更新が完了するまでシステムのリソースを消費します。更新を計画する場合には、この点について考慮してください。

脆弱性データベース（VDB）

シスコの脆弱性データベース（VDB）は、オペレーティング システム、クライアント、およびアプリケーションのフィンガープリントだけでなく、ホストが影響を受ける可能性がある既知の脆弱性のデータベースです。ファイアウォールシステムはフィンガープリントと脆弱性を関連付けて、特定のホストがネットワークの侵害のリスクを増大させているかどうかを判断するのをサポートします。Cisco Talos Intelligence Group（Talos） では、VDB の定期的な更新を配布しています。

脆弱性のマッピングを更新するのにかかる時間は、ネットワーク マップ内のホストの数によって異なります。システムのダウンタイムの影響を最小にするために、システムの使用率が低い時間帯に更新をスケジュールすることをお勧めします。一般的に、更新の実行にかかるおおよその時間（分）を判断するには、ネットワーク上のホストの数を 1000 で割ります。

VDB を更新した後、更新されたアプリケーション ディテクタとオペレーティング システム フィンガープリントを有効にするために、設定を再展開する必要があります。

Cisco Talos Intelligence Group（Talos） セキュリティ インテリジェンスのフィード

Talos は、セキュリティ インテリジェンス ポリシーで使用するため定期的に更新されるインテリジェンスフィードへのアクセスを提供します。マルウェア、スパム、ボットネット、フィッシングなど、セキュリティに対する脅威を表すサイトは目まぐるしく現れては消えるため、カスタム設定を更新して導入するのでは最新の状況に追いつきません。これらのフィードには、既知の脅威のアドレスや URL が含まれています。システムによってフィードが更新される場合、再展開する必要はありません。後続の接続の評価には新しい一覧が使用されます。

URL カテゴリ/レピュテーション データベース

システムは、Cisco Collective Security Intelligence（CSI）から URL カテゴリとレピュテーション データベースを取得します。カテゴリとレピュテーションに関してフィルタリングする URL フィルタリング アクセス制御ルールを設定すると、要求された URL がデータベースと照合されます。[システム設定（System Settings）] > [URLフィルタリングの設定（URL Filtering Preferences）] でデータベースの更新といくつかのその他の URL フィルタリング設定を設定できます。URL カテゴリ/レピュテーション データベースの更新は、他のシステム データベースの更新を管理する方法では管理できません。

システム データベースの更新

必要に応じて、手動でシステム データベースの更新を取得して適用できます。更新はシスコサポート サイトから取得されます。そのため、システムの管理アドレスからインターネットへのパスが必要です。

または、インターネットから更新パッケージを取得して、ワークステーションからアップロードできます。この方法は、主に、シスコから更新を取得するためのインターネットへのパスがないエアギャップネットワークを対象としています。software.cisco.com のシステム ソフトウェア アップグレードをダウンロードするのと同じフォルダから更新をダウンロードします。


（注）  

2022 年 5 月、GeoDB が 2 つのパッケージに分割されました。IP アドレスを国/大陸にマッピングする国コードパッケージと、ルーティング可能な IP アドレスに関連付けられた追加のコンテキストデータを含む IP パッケージです。Device Manager は IP パッケージの情報を使用しません。また、これまでに使用したこともありません。この分割により、ローカルで管理されたThreat Defense 展開においてディスク容量が大幅に節約されます。シスコからご自身で GeoDB を入手する場合は、古いオールインワンパッケージと同じファイル名を持つ国コードパッケージ（Cisco_GEODB_Update-date-build）を入手してください。

またデータベースの更新を取得して適用するよう、定期的なスケジュールを設定することもできます。これらの更新はサイズが大きい場合があるため、ネットワーク アクティビティが少ない時間帯にスケジュールしてください。


（注）  

データベース更新が進行中の場合、ユーザー インターフェイスのアクションへの応答が遅くなる場合があります。

始める前に

保留中の変更に対して潜在的な影響を与えることを避けるため、これらのデータベースを手動で更新する前に、デバイスに設定を展開します。

VDB および URL カテゴリを更新すると、アプリケーションまたはカテゴリが削除される可能性があることに注意してください。変更を展開する前に、これらの廃止された項目を使用しているアクセス制御ルールまたは SSL 復号ルールを更新する必要があります。

手順

ステップ 1

[デバイス（Device）] をクリックしてから、[更新（Updates）] のサマリーで [設定の表示（View Configuration）] をクリックします。

これによって、[更新（Updates）] ページが開きます。このページの情報には、各データベースの現在のバージョン、および各データベースの最終更新日時が表示されます。

ステップ 2

データベースを手動で更新するには、そのデータベースのセクションで次のいずれかのオプションをクリックします。

  • [クラウドから更新（Update From Cloud）]：Device Manager が更新パッケージをシスコから取得するようにします。これは最も簡単で信頼性の高い方法ですが、使用するにはインターネットへのパスが必要です。

  • （下矢印） > [オプション（option）]：ワークステーションまたはワークステーションに接続されているドライブから更新パッケージを選択します。オプションは次のいずれかです。

    • [ファイルの選択（Select File）]：VDB または地理位置情報パッケージを選択します。

    • [新しいバージョンに更新（Update to Newer Version）]：現在インストールされている侵入ルールパッケージよりも新しいパッケージを選択します。

    • [古いバージョンにダウングレード（Downgrade to Older Version）]：現在インストールされている侵入ルールパッケージよりも古いパッケージを選択します。

ルールおよび VDB の更新では、アクティブにするための設定の展開が必要です。クラウドから更新する場合、今すぐ展開するかどうかを尋ねられるので、[はい（Yes）] をクリックします。[いいえ（No）] をクリックする場合は、都合の良いときにできるだけ早く展開ジョブを開始してください。

独自のファイルをアップロードする場合は、必ず手動で変更を展開する必要があります。

（注）  

 

侵入ルールパッケージを手動でアップロードする場合は、必ず Snort のバージョンに適したパッケージタイプ（Snort 2 の場合は SRU、Snort 3 の場合は LSP）をアップロードしてください。非アクティブなバージョンの Snort 用のパッケージもアップロードできますが、バージョンを切り替えるまでアクティブになりません。Snort のバージョンの切り替えについては、Snort 2 と Snort 3 の切り替えを参照してください。

ステップ 3

（オプション）定期的なデータベース更新スケジュールを設定するには、次の手順に従います。

  1. 目的のデータベースのセクションで [設定（Configure）] リンクをクリックします。すでにスケジュールが設定されている場合、[編集（Edit）] をクリックします。

    データベースの更新スケジュールは独立しています。スケジュールは別途定義する必要があります。

  2. 更新開始時刻を設定します。

    • 更新の頻度（日次、週次、または月次）。

    • 週次または月次の場合、更新が必要な曜日または日付。

    • 更新を開始する時刻。 指定された時刻はサマータイムのため調整され、当該地域で時刻が調整されるたびに 1 時間、前または後に移動します。年間を通して正確な時刻を保持するには、時刻の変更の際にスケジュールを編集する必要があります。

  3. ルールまたは VDB の更新では、データベースが更新されるたびにシステムが設定を展開するようにする場合は、[更新の自動展開（Automatically Deploy the Update）] チェックボックスをオンにします。

    更新は、展開されるまでは有効になりません。自動展開では、まだ展開されていないその他の設定変更も展開されます。

  4. [保存（Save）] をクリックします。

（注）  

 

定期的なスケジュールを削除する場合、[編集（Edit）] リンクをクリックしてスケジューリング ダイアログボックスを開き、[削除（Remove）] ボタンをクリックします。

Cisco Security Intelligence フィードの更新

Cisco Talos Intelligence Group（Talos）は、定期的に更新されるセキュリティ インテリジェンス フィードへのアクセスを提供します。マルウェア、スパム、ボットネット、フィッシングなど、セキュリティに対する脅威を表すサイトは目まぐるしく現れては消えるため、カスタム設定を更新して導入するのでは最新の状況に追いつきません。システムによってフィードが更新される場合、再展開する必要はありません。後続の接続の評価には新しい一覧が使用されます。

システムがフィードをインターネットから更新するタイミングを厳密に制御したい場合は、そのフィードの自動更新を無効にできます。ただし、自動更新を行えば、最新の関連するデータであることが確実になります。

手順

ステップ 1

[デバイス（Device）] をクリックしてから、[更新（Updates）] のサマリーで [設定の表示（View Configuration）] をクリックします。

これによって、[更新（Updates）] ページが開きます。ページには、[セキュリティインテリジェンスフィード（Security Intelligence Feeds）] の現在のバージョン、およびフィードの最終更新日時が表示されます。

ステップ 2

フィードを手動で更新するには、[セキュリティインテリジェンスフィード（Security Intelligence Feeds）] グループで [今すぐ更新（Update Now）] をクリックします。

ハイ アベイラビリティ グループ内の 1 台の装置のフィードを手動で更新する場合は、その他の装置のフィードも手動で更新して一貫性を確保する必要があります。

ステップ 3

（オプション）定期的な更新の頻度を設定するには：

  1. [シスコのフィード（Cisco Feeds）] セクションにある [設定（Configure）] リンクをクリックします。すでにスケジュールが設定されている場合、[編集（Edit）] をクリックします。

  2. 希望する頻度を選択します。

    デフォルトは [毎時（Hourly）] です。[毎日（Daily）] 更新（時刻を指定）または [毎週（Weekly）] 更新（曜日と時刻を指定）を設定することもできます。 指定された時刻はサマータイムのため調整され、当該地域で時刻が調整されるたびに 1 時間、前または後に移動します。年間を通して正確な時刻を保持するには、時刻の変更の際にスケジュールを編集する必要があります。

    [削除（Delete）] をクリックして、自動更新されないようにします。

  3. [OK] をクリックします。

のアップグレードThreat Defense

この手順を使用して、スタンドアロンの Threat Defense デバイスをアップグレードします。FXOS を更新する必要がある場合は、それを最初に実行します。高可用性脅威防御をアップグレードするには、ハイアベイラビリティ Threat Defense のアップグレードを参照してください。


注意    

アップグレード中にトラフィックがドロップされます。システムが非アクティブまたは無反応に見えても、アップグレード中は手動で再起動またはシャットダウンしないでください。システムが使用できない状態になり、再イメージ化が必要になる場合があります。失敗した（または進行中）のメジャーおよびメンテナンスアップグレードを手動でキャンセルし、失敗したアップグレードを再試行できます。問題が解消されない場合は、Cisco TAC にお問い合わせください。

アップグレード中に発生する可能性のあるこれらの問題およびその他の問題の詳細については、Threat Defense のアップグレードのトラブルシューティングを参照してください。

始める前に

事前アップグレードのチェックリストを完了します。正常に展開され、通信が確立されていることを確認します。


ヒント

アップグレード前のチェックリストには、計画（Cisco Secure Firewall Threat Defense リリースノート を読むことから開始）、バックアップの作成、アップグレードパッケージの取得、および関連するアップグレード（Firepower 4100/9300 の FXOS など）の実行が含まれます。また、必要な構成変更のチェック、準備状況のチェック、ディスク容量のチェック、実行中のタスクとスケジュールされたタスクの両方のチェックも含まれます。アップグレード手順の詳細については、アップグレード前のチェックリストを含め、お使いのバージョンの『Device Manager 用 Cisco Secure Firewall Threat Defense アップグレードガイド』を参照してください。

手順

ステップ 1

[デバイス（Device）] を選択し、[更新（Updates）] パネルの [設定の表示（View Configuration）] をクリックします。

[システムアップグレード（System Upgrade）] パネルには、現在実行中のソフトウェアバージョン、およびすでにアップロードされたアップグレードパッケージが表示されます。

ステップ 2

アップグレードパッケージをアップロードします。

アップロードできるパッケージは 1 つだけです。新しいパッケージをアップロードすると、古いパッケージが置き換えられます。ターゲットバージョンとデバイスモデルに適したパッケージがあることを確認してください。[参照（Browse）] または [ファイルの置き換え（Replace File）] をクリックしてアップロードを開始します。

アップロードが完了すると、確認ダイアログボックスが表示されます。[OK] をクリックする前に、必要に応じて [すぐにアップグレードを実行（Run Upgrade Immediately）] を選択して、ロールバックオプションを選択し、今すぐアップグレードします。今すぐアップグレードする場合は、アップグレード前のチェックリストをできるだけ多く完了することが特に重要です（次のステップを参照）。

ステップ 3

準備状況チェックを含む、アップグレード前の最終チェックを実行します。

アップグレード前のチェックリストを再確認します。関連するすべてのタスク、特に最終チェックを完了していることを確認してください。 準備状況チェックを手動で実行しない場合、アップグレードの開始時に実行されます。準備状況チェックに失敗すると、アップグレードはキャンセルされます。詳細については、アップグレード準備状況チェックの実行を参照してください。

ステップ 4

[今すぐアップグレード（Upgrade Now）] をクリックしてアップグレードを開始します。

  1. ロールバックオプションを選択します。

    [アップグレードに失敗すると自動的にキャンセルされ、前のバージョンにロールバックする（Automatically cancel on upgrade failure and roll back to the previous version）] を選択できます。オプションを有効にすると、メジャーまたはメンテナンスアップグレードが失敗した場合、デバイスは自動的にアップグレード前の状態に戻ります。失敗したアップグレードを手動でキャンセルまたは再試行できるようにする場合は、このオプションを無効にします。

  2. [続行（Continue）] をクリックして、アップグレードしてデバイスを再起動します。

    自動的にログオフされ、デバイスが再起動するまでアップグレードを監視できるステータスページに移動します。また、このページには、進行中のインストールをキャンセルするオプションが含まれています。自動ロールバックを無効にしてアップグレードが失敗した場合は、アップグレードを手動でキャンセルするか、再試行できます。

    アップグレード中にトラフィックがドロップされます。ISA 3000 の場合にのみ、電源障害に対するハードウェアバイパスを設定すると、トラフィックはアップグレード中にドロップされますが、デバイスのアップグレード後の再起動完了時に検査なしでトラフィックが渡されます。

ステップ 5

可能なときに再度ログインし、アップグレードが成功したことを確認します。

[デバイスの概要（Device Summary）] ページには、現在実行中のソフトウェアのバージョンが表示されます。

ステップ 6

アップグレード後のタスクを完了します。

  1. システムデータベースを更新します。侵入ルール、VDB、GeoDB の自動更新が設定されていない場合は、ここで更新します。

  2. アップグレード後に必要な構成変更が他にもあれば、実行します。

  3. 展開します。

アップグレード準備状況チェックの実行

アップグレードパッケージがインストールされる前に、準備状況チェックが実行されて、システムに有効なアップグレードであるか確認されます。また、他にもアップグレードの成功を妨げる可能性のある項目がないかチェックされます。準備状況チェックに失敗した場合は、インストールを再試行する前に問題を修正する必要があります。チェックに失敗した場合、次回インストールを試みると、チェック失敗についてのプロンプトが表示され、強制的にインストールを実行するオプションが与えられます。

次の手順の説明に従って、アップグレードを開始する前に手動で準備状況チェックを実行することもできます。

始める前に

チェックするアップグレードパッケージをアップロードします。

手順

ステップ 1

[デバイス（Device）] をクリックし、[更新サマリー（Updates summary）] の [設定の表示（View Configuration）] をクリックします。

[システムアップグレード（System Upgrade）] セクションには、現在実行中のソフトウェア バージョン、およびすでにアップロードされた更新が表示されます。

ステップ 2

[Readiness Check] セクションを確認します。

  • アップグレードチェックがまだ実行されていない場合は、[Run Upgrade Readiness Check] リンクをクリックします。チェックの進行状況がこの領域に表示されます。プロセスの完了には、20 秒程度かかります。

  • アップグレードチェックがすでに実行されている場合、このセクションにはチェックが成功か失敗かが示されます。チェックに失敗した場合は、[See Details] をクリックして、準備状況チェックの詳細を表示します。問題を修正した後、チェックを再度実行します。

ステップ 3

準備状況チェックに失敗した場合は、アップグレードパッケージをインストールする前に問題を解決する必要があります。詳細情報には、指摘された問題の修正方法に関するヘルプが含まれています。失敗したスクリプトについては、[Show Recovery Message] リンクをクリックすると情報が表示されます。

一般的な問題のいくつかを以下に示します。

  • FXOS バージョンに互換性がない：FXOS アップグレードを個別にインストールする Firepower 4100/9300 などのシステムでは、現行の Threat Defense ソフトウェアバージョンとは異なる FXOS の最小バージョンが必要になる場合があります。この場合、Threat Defense ソフトウェアをアップグレードする前に、まず FXOS をアップグレードする必要があります。

  • デバイスモデルがサポートされていない：アップグレードパッケージは、サポートされていないデバイスにはインストールできません。誤ったパッケージをアップロードしたか、デバイスが旧モデルのため、新しい Threat Defense ソフトウェアバージョンではサポートされていない可能性があります。デバイスの互換性を確認し、サポートされているパッケージがあればアップロードしてください。

  • ディスク容量が不十分：十分な空き容量がない場合は、システムバックアップなどの不要なファイルを削除してください。作成したファイルのみを削除します。

アップグレードのモニタリング Threat Defense

Threat Defense のアップグレードを開始すると、自動的にログオフされ、アップグレードの進捗を監視できるステータスページに移動します。また、このページには、進行中のインストールをキャンセルするオプションが含まれています。自動ロールバックを無効にしてアップグレードが失敗した場合は、このページから、アップグレードを手動でキャンセルするか、再試行できます。

デバイスに SSH で接続し、CLI（show upgrade status ）を使用することもできます。ログエントリが生成されたときにそれらを表示するには continuous キーワードを追加します。また、詳細情報を表示するには detail キーワードを追加します。両方のキーワードを追加して、継続的な詳細情報を取得します

アップグレードが完了した後は、デバイスがリブートすると、ステータスページと CLI にアクセスできなくなります。

Threat Defense のアップグレードのキャンセルまたは再試行

アップグレードステータスのページまたは CLI を使用して、失敗した（または進行中）のメジャーおよびメンテナンスアップグレードを手動でキャンセルし、失敗したアップグレードを再試行することができます。

  • アップグレードステータスのページ：進行中のアップグレードをキャンセルするには、[アップグレードのキャンセル（Cancel Upgrade）] をクリックします。アップグレードが失敗した場合は、[アップグレードのキャンセル（Cancel Upgrade）] をクリックしてジョブを停止し、アップグレード前のデバイスの状態に戻すことができます。また、[続行（Continue）] をクリックしてアップグレードを再試行することができます。

  • CLI：進行中のアップグレードをキャンセルするには、upgrade cancel を使用します。アップグレードが失敗した場合は、upgrade cancel を使用してジョブを停止し、アップグレード前のデバイスの状態に戻すことができます。また、upgrade retry を使用してアップグレードを再試行することができます。


（注）  

デフォルトでは、Threat Defense はアップグレードが失敗すると自動的にアップグレード前の状態に復元されます（「自動キャンセル」）。失敗したアップグレードを手動でキャンセルまたは再試行できるようにするには、アップグレードを開始するときに自動キャンセルオプションを無効にします。高可用性の展開では、自動キャンセルは各デバイスに個別に適用されます。つまり、1 つのデバイスでアップグレードが失敗した場合、そのデバイスだけが元に戻ります。

これらのオプションは、パッチではサポートされていません。正常なアップグレードを元に戻す方法については、Threat Defense の復元を参照してください。

Threat Defense の復元

メジャーアップグレードまたはメンテナンスアップグレードに成功したにもかかわらず、システムが期待どおりに機能しない場合は、復元が可能です。Threat Defense を復元すると、ソフトウェアは、最後のメジャーアップグレードまたはメンテナンスアップグレードの直前の状態に戻ります。アップグレード後の設定変更は保持されません。パッチ適用後に復元すると、パッチも必然的に削除されます。個々のパッチまたはホットフィックスを元に戻すことはできないので注意してください。

次の手順では、Device Manager から復元する方法について説明します。Device Manager にアクセスできない場合は、 upgrade revert コマンドを使用して SSH セッションの Threat Defense コマンドラインから復元できます。show upgrade revert-info コマンドを使用すると、システムがどのバージョンに戻るのかを確認できます。

始める前に

ユニットがハイアベイラビリティペアの一部である場合は、両方のユニットを元に戻す必要があります。理想的には、フェールオーバーの問題なしに設定を復元できるように、両方のユニットで復元を同時に開始します。両方のユニットでセッションを開き、それぞれで復元が可能であることを確認してから、プロセスを開始します。復元時にトラフィックが中断されることに注意してください。そのため、可能であれば、これを業務時間外に実行してください。

Firepower 4100/9300 シャーシの場合、Firepower のメジャーバージョンには特別に認定および推奨されている付随の Threat Defense バージョンがあります。これは、Threat Defense ソフトウェアを復元した後に、推奨されていない（新しすぎる）バージョンの FXOS を実行している可能性があることを意味します。新しいバージョンの FXOS は旧バージョンの Threat Defense と下位互換性がありますが、シスコでは推奨の組み合わせについて拡張テストを実施しています。FXOS をダウングレードすることはできないため、このような状況下で推奨の組み合わせを稼働するには、デバイスの再イメージ化が必要になります。

手順

ステップ 1

[Device] を選択し、次に [Updates summary] の [View Configuration] をクリックします。

ステップ 2

[System Upgrade] セクションで、[Revert Upgrade] リンクをクリックします。

現在のバージョンと復元されるバージョンを示す確認ダイアログボックスが表示されます。復元できるバージョンがない場合、[Revert Upgrade] リンクは表示されません。

ステップ 3

ターゲットバージョンが許容できるバージョンである場合（かつ使用可能な場合）、[Revert] をクリックします。

復元後、デバイスを Smart Software Manager に再登録する必要があります。

Threat Defense のアップグレードのトラブルシューティング

以下の問題は、スタンドアロンまたはハイアベイラビリティペアのデバイスをアップグレードするときに発生する可能性があります。ハイアベイラビリティのアップグレードに固有の問題をトラブルシューティングするには、ハイアベイラビリティ Threat Defense のアップグレードのトラブルシューティングを参照してください。

アップグレードパッケージのエラー。

適切なアップグレードパッケージを見つけるには、使用しているモデルを シスコ サポートおよびダウンロード サイト で選択または検索し、適切なバージョンのソフトウェアのダウンロードページを参照します。使用可能なアップグレードパッケージは、インストールパッケージ、ホットフィックス、およびその他の該当するダウンロードとともに表示されます。アップグレードパッケージのファイル名には、プラットフォーム、パッケージタイプ（アップグレード、パッチ、ホットフィックス）、ソフトウェアバージョン、およびビルドが反映されています。

バージョン 6.2.1 以降のアップグレードパッケージは署名されており、ファイル名の最後は .sh.REL.tar です。署名付きのアップグレード パッケージは解凍しないでください。 アップグレードパッケージの名前を変更したり、電子メールで転送したりしないでください。

アップグレード中にデバイスにまったく到達できない。

デバイスは、アップグレード中、またはアップグレードが失敗した場合に、トラフィックを渡すことを停止します。アップグレードする前に、ユーザーの位置からのトラフィックがデバイスの管理インターフェイスにアクセスするためにデバイス自体を通過する必要がないことを確認してください。

アップグレード中にデバイスが非アクティブまたは無反応に見える。

進行中のメジャーおよびメンテナンスアップグレードは手動でキャンセルできます。Threat Defense のアップグレードのキャンセルまたは再試行を参照してください。デバイスが応答しない場合、またはアップグレードをキャンセルできない場合は、Cisco TAC にお問い合わせください。


注意    

システムが非アクティブに見えても、アップグレード中は手動で再起動またはシャットダウン「しない」でください。システムが使用できない状態になり、再イメージ化が必要になる場合があります。

アップグレードは成功したが、システムが予期どおりに機能しない。

まず、キャッシュされた情報が更新されていることを確認します。単にブラウザウィンドウを更新して再度ログインするのではなく、URL から「余分な」パスを削除し、ホームページに再接続します（たとえば、http://threat-defense.example.com/）。

引き続き問題が発生し、以前のメジャーリリースまたはメンテナンスリリースに戻す必要がある場合は、復元できる場合があります。Threat Defense の復元を参照してください。復元できない場合は、イメージを再作成する必要があります。

アップグレードが失敗する。

メジャーアップグレードまたはメンテナンスアップグレードを開始する場合は、[アップグレードに失敗すると自動的にキャンセルされる...（Automatically cancel on upgrade failure...）] （自動キャンセル）オプションを使用して、次のように、アップグレードが失敗した場合の動作を選択します。

  • [自動キャンセルが有効（Auto-cancel enabled）]（デフォルト）：アップグレードが失敗すると、アップグレードがキャンセルされ、デバイスは自動的にアップグレード前の状態に復元されます。問題を修正し、後で再試行してください。

  • [自動キャンセルが無効（Auto-cancel disabled）]：アップグレードが失敗した場合、デバイスはそのままになります。問題を修正してすぐに再試行するか、手動でアップグレードをキャンセルして後で再試行してください。

詳細については、Threat Defense のアップグレードのキャンセルまたは再試行を参照してください。再試行またはキャンセルできない場合、または問題が解消されない場合は、Cisco TAC にお問い合わせください。

デバイスの再イメージ化

デバイスを再イメージ化すると、デバイス設定が消去され、新しいソフトウェア イメージがインストールされます。再イメージ化の目的は、工場出荷時のデフォルト設定でクリーン インストールすることです。

次の場合に、デバイスを再イメージ化します。

  • ASA ソフトウェアから Threat Defense ソフトウェアにシステムを変換する場合。ASA イメージを実行しているデバイスを Threat Defense イメージを実行しているデバイスにアップグレードすることはできません。

  • デバイスが正しく機能せず、設定の修正ですべての試行が失敗した場合。

デバイスの再イメージ化の詳細については、ご使用のデバイスモデルの『Reimage the Cisco ASA or Threat Defense Device』または Threat Defense のクイックスタートガイドを参照してください。これらのガイドは、http://www.cisco.com/c/en/us/support/security/firepower-ngfw/products-installation-guides-list.html で入手できます。

システムのバックアップと復元

システム設定をバックアップしておくことで、将来的に設定ミスや物理的な災害が生じて設定が破損したとしても、デバイスを復元することができます。

代替のデバイスにバックアップを復元できるのは、どちらのデバイスも同じモデルで、（同時リリースだけでなく、ビルド番号を含む）同じバージョンのソフトウェアを実行している場合のみです。アプライアンス間で設定をコピーするためにバックアップおよび復元プロセスを使用しないでください。バックアップ ファイルには、この方法で共有することができないようにアプライアンスを一意に特定する情報が含まれます。


（注）  

バックアップには管理 IP アドレスの設定は含まれません。したがって、バックアップ ファイルを復元しても、管理アドレスがバックアップ コピーにより置き換えられることはありません。これにより、アドレスに対する変更はすべて保持され、また異なるネットワーク セグメント上の別のデバイスに設定を復元することもできます。バックアップにはライセンス情報やクラウド登録情報も含まれていないため、復元時に存在するライセンスやクラウド登録の状態はすべて保持されます。

バックアップには設定だけが含まれ、システム ソフトウェアは含まれません。デバイスを完全に再イメージ化する必要がある場合、ソフトウェアを再インストールしてからバックアップをアップロードして、設定を回復する必要があります。

バックアップ中は設定データベースがロックされます。バックアップの間はポリシー、ダッシュボードなどを表示できますが、設定を変更することはできません。復元を行っている間、システムは完全に使用できません。

「バックアップと復元」ページの表は、バックアップのファイル名、作成日時、ファイル サイズを含む、システムで使用できる既存のすべてのバックアップ コピーを示します。バックアップのタイプ（手動、スケジュール、繰り返し）は、システムに指示したバックアップ コピーの作成方法に基づいています。


ヒント

バックアップ コピーはシステム自体に作成されます。ディザスタ リカバリのために必要なバックアップ コピーを確保するため、バックアップ コピーは手動でダウンロードし、安全なサーバーに保存する必要があります。システムは、デバイス上に最大 3 つのバックアップコピーを保持します。新しいバックアップによって、最も古いバックアップが置き換えられます。

次に、バックアップの管理と復元操作について説明します。

システムの即時バックアップ

希望する場合はいつでもバックアップを開始できます。

手順

ステップ 1

[デバイス（Device）] をクリックしてから、[バックアップと復元（Backup and Restore）] のサマリーで [設定の表示（View Configuration）] をクリックします。

これにより、[バックアップおよび復元（Backup and Restore）] ページが開きます。使用可能なすべての既存のバックアップ コピーが表にリストされています。

ステップ 2

[手動バックアップ（Manual Backup）] > [今すぐバックアップ（Back Up Now）] をクリックします。

ステップ 3

バックアップの名前を入力し、任意で説明を入力します。

今すぐではなく、将来のある時刻にバックアップする場合は、代わりに [スケジュール（Schedule）] をクリックできます。

ステップ 4

（任意）[Encrypt File] オプションを選択して、バックアップファイルを暗号化します。

このオプションを選択した場合は、バックアップファイルの復元に必要な [Password]（および [Confirm Password]）を入力する必要があります。

ステップ 5

（ISA 3000 のみ）[バックアップファイルの場所（Location of Backup Files）] を選択します。

[ローカルハードディスク（Local Hard Disk）] または [SDカード（SD Card）] にバックアップを作成できます。SD カードを使用する利点は、カードを使用して設定を交換デバイスに回復できることです。

ステップ 6

[今すぐバックアップ（Back Up Now）] をクリックします。

システムがバックアップ プロセスを開始します。バックアップが完了すると、バックアップ ファイルが表に表示されます。必要に応じて、バックアップ コピーをシステムにダウンロードして、他の場所に保存できます。

バックアップが開始されたら、[バックアップと復元（Backup and Restore）] ページを閉じてもかまいません。ただし、システムの動作が遅くなる可能性があるため、バックアップを完了するために作業を一時停止することを検討してください。

また、一部または全部のバックアップ中に、システムによってコンフィギュレーション データベースのロックが取得され、それが原因でバックアップ プロセス中に変更を加えることができなくなる場合があります。

スケジュールされた時間でのシステムのバックアップ

システムを将来の特定の日時にバックアップするために、スケジュール バックアップを設定できます。スケジュール バックアップは、1 回だけ実行されます。定期的にバックアップを作成するようにバックアップ スケジュールを作成するには、スケジュール バックアップではなく、繰り返しバックアップを設定します。


（注）  

将来のバックアップのスケジュールを削除するには、スケジュールを編集して、[削除（Remove）] をクリックします。

手順

ステップ 1

[デバイス（Device）] をクリックしてから、[バックアップと復元（Backup and Restore）] のサマリーで [設定の表示（View Configuration）] をクリックします。

ステップ 2

[スケジュールバックアップ（Scheduled Backup）] > [バックアップをスケジュール（Schedule a Backup）] をクリックします。

すでにスケジュール バックアップがある場合は、[スケジュールバックアップ（Scheduled Backup）] > [編集（Edit）] をクリックします。

ステップ 3

バックアップの名前を入力し、任意で説明を入力します。

ステップ 4

バックアップの日時を入力します。

ステップ 5

（任意）[Encrypt File] オプションを選択して、バックアップファイルを暗号化します。

このオプションを選択した場合は、バックアップファイルの復元に必要な [Password]（および [Confirm Password]）を入力する必要があります。

ステップ 6

（ISA 3000 のみ）[バックアップファイルの場所（Location of Backup Files）] を選択します。

[ローカルハードディスク（Local Hard Disk）] または [SDカード（SD Card）] にバックアップを作成できます。SD カードを使用する利点は、カードを使用して設定を交換デバイスに回復できることです。

ステップ 7

[スケジュール（Schedule）] をクリックします。

選択した日時に達すると、システムがバックアップされます。完了すると、バックアップ コピーがバックアップの表に一覧されます。

定期的なバックアップ スケジュールの設定

定期的なバックアップを設定し、システムを定期的にバックアップできます。たとえば、毎週金曜日の真夜中にバックアップをとることもできます。定期的なバックアップ スケジュールにより、常に最新のバックアップ セットを保持できます。


（注）  

定期的なスケジュールを削除する場合、スケジュールを編集し、[削除（Delete）] をクリックします。

手順

ステップ 1

[デバイス（Device）] をクリックしてから、[バックアップと復元（Backup and Restore）] のサマリーで [設定の表示（View Configuration）] をクリックします。

ステップ 2

[定期バックアップ（Recurring Backup）] > [設定（Configure）] をクリックします。

すでに定期バックアップを設定している場合は、[定期バックアップ（Recurring Backup）] > [編集（Edit）] をクリックします。

ステップ 3

バックアップの名前を入力し、任意で説明を入力します。

ステップ 4

[頻度（Frequency）] と関連スケジュールを選択します。

  • [日次（Daily）]：時刻を選択します。バックアップは毎日、スケジュールされた時刻に取得されます。
  • [週次（Weekly）]：曜日と時刻を選択します。バックアップは選択した日付のスケジュールされた時刻に取得されます。たとえば、毎週月曜日、水曜日、金曜日の 23 時（午後 11 時）にバックアップをスケジュールすることもできます。
  • [月次（Monthly）]：日付と時刻を選択します。バックアップは選択した日付のスケジュールされた時刻に取得されます。たとえば、1 日、15 日、28 日の 23 時（午後 11 時）にバックアップをスケジュールすることもできます。

指定された時刻はサマータイムのため調整され、当該地域で時刻が調整されるたびに 1 時間、前または後に移動します。年間を通して正確な時刻を保持するには、時刻の変更の際にスケジュールを編集する必要があります。

ステップ 5

（任意）[Encrypt File] オプションを選択して、バックアップファイルを暗号化します。

このオプションを選択した場合は、バックアップファイルの復元に必要な [Password]（および [Confirm Password]）を入力する必要があります。

ステップ 6

（ISA 3000 のみ）[バックアップファイルの場所（Location of Backup Files）] を選択します。

[ローカルハードディスク（Local Hard Disk）] または [SDカード（SD Card）] にバックアップを作成できます。SD カードを使用する利点は、カードを使用して設定を交換デバイスに回復できることです。

ステップ 7

[保存（Save）] をクリックします。

選択した日付と時刻になると、バックアップが取得されます。完了すると、バックアップ コピーがバックアップ テーブルにリストされます。

定期的なスケジュールを変更または削除するまで、バックアップを取得し続けます。

バックアップの復元

デバイスでバックアップを取得したときに実行されていたものと同じソフトウェア バージョン（ビルド番号を含む）が実行されている限り、バックアップを復元できます。代替のデバイスにバックアップを復元できるのは、どちらのデバイスも同じモデルで、同じバージョンのソフトウェア（ビルド番号を含む）を実行している場合のみです。

ただし、このデバイスがハイ アベイラビリティペアの一部である場合、バックアップは復元できません。まず、[デバイス（Device）] > [ハイ アベイラビリティ（High Availability）] ページから HA を無効化することで、バックアップを復元できます。バックアップに HA の設定が含まれている場合、デバイスは HA グループに再度参加します。両方のユニットで同じバックアップを復元しないでください（両方のユニットがアクティブになってしまうため）。代わりに、まず、アクティブにする装置でバックアップを復元し、その後に、別のユニットで同等のバックアップを復元してください。

復元するバックアップ コピーがまだデバイスに存在しない場合、復元する前にまずバックアップをアップロードする必要があります。

復元している間、システムはまったく使用できません。


（注）  

バックアップには管理 IP アドレスの設定は含まれません。したがって、バックアップ ファイルを復元しても、管理アドレスがバックアップ コピーにより置き換えられることはありません。これにより、アドレスに対する変更はすべて保持され、また異なるネットワーク セグメント上の別のデバイスに設定を復元することもできます。バックアップにはライセンス情報やクラウド登録情報も含まれていないため、復元時に存在するライセンスやクラウド登録の状態はすべて保持されます。

始める前に

別のシステムでバックアップを復元する場合（デバイスを交換するときなど）、ベストプラクティスは、最初にデバイスを登録し、バックアップファイルで設定された機能に必要なオプションのライセンスを有効にすることです。バックアップファイルにはライセンス情報やクラウドサービス情報が含まれていないため、復元前に行ったライセンスの変更やクラウドの登録は保持されます。

手順

ステップ 1

[デバイス（Device）] をクリックしてから、[バックアップと復元（Backup and Restore）] のサマリーで [設定の表示（View Configuration）] をクリックします。

これにより、[バックアップおよび復元（Backup and Restore）] ページが開きます。使用可能なすべての既存のバックアップ コピーが表にリストされています。

ステップ 2

復元しようとするバックアップ コピーが、使用可能なバックアップのリストにない場合、[アップロード（Upload）] > [検索（Browse）] をクリックし、バックアップ コピーをアップロードします。

ステップ 3

ファイルの [復元（restore）] アイコン（Restore backup button.）をクリックします。

復元するかどうかの確認が求められます。デフォルトでは、復元後にバックアップ コピーは削除されますが、これを保持するには、復元を続行する前に、[復元後にバックアップを削除しない（Do not remove the backup after restoring）] を選択します。

バックアップファイルが暗号化されている場合は、ファイルを開いて復号するために必要な [パスワード（Password）] を入力する必要があります。

復元が完了すると、システムは再起動します。

（注）  

 

システムが再起動後、脆弱性データベース（VDB）、地理位置情報、およびルール データベースの更新が自動的にチェックされ、必要に応じてダウンロードされます。これらの更新は大規模な場合があるため、初回の試行が失敗する可能性があります。タスクリストを確認し、ダウンロードが失敗した場合はシステム データベースの更新の説明に従って手動で更新をダウンロードしてください。またポリシーも再展開されます。更新が成功しないと、それ以降の展開はすべて失敗します。

ステップ 4

必要に応じて、[デバイス（Device）] > [スマートライセンス（Smart License）] > [設定の表示（View Configuration）] をクリックし、デバイスを再登録して、必要なオプションライセンスを再度有効にします。

バックアップにはライセンス情報やクラウド登録情報は含まれません。そのため、新しいシステムにバックアップを復元する場合（デバイスを交換するときなど）、システムが評価モードのときは、それを登録し、必要なすべてのライセンスを有効にする必要があります。復元前にデバイスを登録し、ライセンスを有効にした場合、追加の変更は必要ありません。

以前のバックアップを同じシステムに単に復元するだけの場合は、ライセンスやクラウド登録を変更する必要はありません。ただし、バックアップにはバックアップの作成後に無効にしたライセンスを必要とする機能が含まれている可能性があるため、必要なすべてのオプションライセンスが有効になっていることを確認してください。

ISA 3000 デバイスの交換

ISA 3000 の SD カードは、別の ISA 3000 デバイスとの間でやり取りできます。SD カード上にシステム バックアップを作成すれば、この機能を使用してデバイスを簡単に交換できます。その方法は、障害が発生したデバイスから SD カードを取り出して新しいデバイスに挿入するだけです。その後に、バックアップを使用して復元できます。

必要なバックアップを確実に用意するには、SD カードにバックアップを作成するバックアップ ジョブを設定します。

バックアップ ファイルの管理

新しいバックアップを作成すると、バックアップ ファイルがバックアップと復元ページに表示されます。バックアップ コピーは無期限に保たれません。デバイスのディスク領域の利用量が最大しきい値に達すると、新しいバックアップ コピー用の場所を空けるために、古いバックアップ コピーが削除されます。さらに、ホットフィックス以外のアップグレードをインストールすると、すべてのバックアップファイルが削除されます。したがって、定期的にバックアップ ファイルを管理し、最も保持したい特定のバックアップ コピーが削除されていないことを確認してください。

バックアップ コピーを管理するには、次の操作を行うことができます。

  • ファイルを安全なストレージにダウンロード：バックアップ ファイルをワークステーションにダウンロードするには、ファイルの [ダウンロード（download）] アイコン（Download file button.）をクリックします。その後、安全なファイル ストレージにファイルを移動できます。

  • システムにバックアップ ファイルをアップロードする：デバイスで使用できなくなったバックアップ コピーを復元する場合は、[アップロード（Upload）] > [ファイルの参照（Browse File）] をクリックして、バックアップ コピーをワークステーションからアップロードします。その後、復元できます。


    （注）  

    アップロードされたファイルは、元のファイル名と一致するように名前が変更される場合があります。また、システムに 3 以上のバックアップコピーがすでに存在する場合、アップロードされたファイル用の場所を空けるために最も古いものは削除されます。古いソフトウェア バージョンによって作成されたファイルをアップロードすることはできません。

  • バックアップを復元する：バックアップ コピーを復元するには、ファイルの [復元（restore）] アイコン（Restore backup button.）をクリックします。復元の間システムは使用できなくなり、復元が完了するとリブートします。システムが稼働していて、動作中になってから設定を展開してください。

  • バックアップ ファイルを削除する：特定のバックアップが必要でなくなったら、ファイルの削除アイコン（delete icon）をクリックします。削除の確認が求められます。削除すると、バックアップ ファイルを回復することはできません。

監査と変更管理

システム イベントやユーザが実行したアクションに関するステータス情報を表示できます。この情報は、システムを監査し、システムが適切に管理されていることを確認するために役立ちます。

監査ログを表示するには、[デバイス（Device）] > [デバイス管理（Device Administration）] > [監査ログ（Audit Log）] をクリックします。さらに、右上隅にある [タスクリスト（Task List）] アイコン ボタンまたは [展開（Deployment）] アイコン ボタンをクリックすると、システム管理情報を確認できます。

ここでは、システム監査および変更管理のいくつかの主要な概念とタスクについて説明します。

監査イベント

監査ログには、次のタイプのイベントを含めることができます。

[カスタムフィードの更新イベント（Custom Feed Update Event）]、[カスタムフィードの更新に失敗（Custom Feed Update Failed）]

これらのイベントは、カスタム セキュリティ インテリジェンス フィードの更新が正常に完了または失敗したことを示します。詳細には、更新を開始したユーザーと、更新されたフィードに関する情報が含まれます。

カスタムルールファイルのインポートの概要イベント

これらのイベントは、1 つ以上のカスタム侵入ルールを含むファイルをインポートしたことを示します。イベントには、追加、更新、および削除されたルールの数の概要と、インポートされたルールの詳細を示す差異ビューが含まれます。

Deployment Completed（展開完了）、Deployment Failed（展開失敗）：ジョブ名またはエンティティ名

これらのイベントは、正常に完了した展開ジョブまたは失敗した展開ジョブを示します。詳細には、ジョブを開始したユーザと、そのジョブ エンティティに関する情報が含まれます。失敗したジョブには、その失敗に関連するエラー メッセージが含まれます。

詳細には [差異ビュー（Differences View）] タブもあります。このタブには、ジョブでデバイスに展開された変更が表示されます。これは、展開されたエンティティのすべてのエンティティ変更イベントの組み合わせです。

これらのイベントをフィルタリングするには、事前定義フィルタの [展開履歴（Deployment History）] をクリックします。これらのイベントのイベント タイプは Deployment Event（展開イベント）であり、完了したイベントまたは失敗したイベントのみをフィルタリングすることはできないことに注意してください。

イベント名には、ユーザー定義のジョブ名（定義している場合）または「User (username) Triggered Deployment（ユーザー（ユーザー名）トリガー イベント）」が含まれます。また、デバイス セットアップ ウィザードの実行時に発生する「Device Setup Automatic Deployment（デバイス セットアップ自動展開）」ジョブと「Device Setup Automatic Deployment (Final Step)（デバイス セットアップ自動展開（最終手順））」ジョブもあります。

Entity Created（エンティティ作成）、Entity Updated（エンティティ更新）、Entity Deleted（エンティティ削除）：エンティティ名（エンティティ型）

これらのイベントは、識別されたエンティティまたはオブジェクトに変更が加えられたことを示します。エンティティの詳細には、エンティティ名、タイプ、および ID に加えて、変更を加えたユーザが含まれます。これらの項目に関してフィルタリングできます。詳細には [差異ビュー（Differences View）] タブもあります。このタブには、オブジェクトに加えられた変更が表示されます。

HA Action Event（HA アクション イベント）

これらのイベントは、高可用性設定でのアクション（ユーザが開始したアクションまたはシステムが開始したアクション）に関連したものです。HA Action Event はイベント タイプですが、イベント名は次のいずれかです。

  • HA Suspended（HA 一時停止）：ユーザがシステムで HA を意図的に一時停止しました。

  • HA Resumed（HA 再開）：ユーザがシステムで HA を意図的に再開しました。

  • HA Reset（HA リセット）：ユーザがシステムで HA を意図的にリセットしました。

  • HA Failover: Unit Switched Modes（HA フェールオーバー：ユニット モード切り替え）：ユーザーがモードを意図的に切り替えたか、ヘルス メトリック違反のためにシステムがフェールオーバーしました。このメッセージは、アクティブ ピアがスタンバイになったか、スタンバイ ピアがアクティブになったことを示します。

High Availability Sync Completed（高可用性同期完了）

アクティブユニットがスタンバイユニットと設定を同期しました。イベントには、同期バージョンと比較した前のバージョンの変更情報が含まれています。

Interface List Scanned（スキャンされたインターフェイスリスト）

このイベントは、インターフェイス インベントリの変更をスキャンしたことを示します。

Pending Changes Discarded（保留中の変更の破棄）

このイベントは、保留中のすべての変更をユーザが削除したことを示します。このイベントと以前の Deployment Completed イベントの間の Entity Created、Entity Updated、および Entity Deleted イベントで示されたすべての変更が削除され、影響を受けたオブジェクトの状態が、最後に展開されたバージョンに戻されています。

ルール更新イベント

Snort 3 を実行している場合、LSPUpdateServer エンティティからのこのイベントは、新しい侵入ルールパッケージがダウンロードされてインストールされたときに追加、削除、または変更された侵入ルールに関する詳細情報を示します。イベントは 100 のルールに制限されているため、100 を超えるルールが追加、削除、または変更された場合、イベントには完全な情報が含まれなくなります。このイベントは、Snort 2 の更新については表示されません。

Task Started（タスク開始）、Task Completed（タスク完了）、Task Failed（タスク失敗）

タスク イベントは、システムまたはユーザによって開始されたジョブの開始および終了を示します。これらの 2 つのイベントは、タスク リストで 1 つのタスクに統合されます。このタスク リストは、右上隅にある [タスクリスト（Task List）] ボタンをクリックすると表示されます。

Task list button.

タスクには、展開ジョブや手動（またはスケジュールされた）データベース更新などのアクションが含まれます。タスクリスト内の任意の項目は、監査ログの 2 つのタスクイベント、タスクの開始の表示、正常な完了または失敗のいずれかに対応します。

User Logged In（ユーザー ログイン）、User Logged Out（ユーザー ログアウト）：ユーザー名

これらのイベントは、Device Manager のユーザーログインおよびユーザーログアウトの時間と送信元 IP アドレスを示します。User Logged Out イベントは、アクティブ ログアウトと、アイドル時間を超過したための自動ログアウトの両方で発生します。

これらのイベントは、デバイスとの接続を確立している RA VPN ユーザに関するものではありません。また、デバイス CLI のログイン/ログアウトも含まれません。

監査ログの表示および分析

監査ログには、展開ジョブ、データベースの更新、Device Manager のログインとログアウトなど、システムが開始したイベントやユーザーが開始したイベントに関する情報が含まれています。

ログで確認できるイベントの種類の説明については、監査イベントを参照してください。

手順

ステップ 1

[デバイス（Device）] をクリックし、[デバイス管理（Device Administration）] > [設定の表示（View Configuration）] リンクをクリックします。

ステップ 2

目次の [監査ログ（Audit Log）] をクリックします（未選択の場合）。

イベントは日付別にグループ分けされ、1 日の中では時間別にグループ分けされます。最新の日時がリストの一番上に表示されます。初めは、各イベントは折りたたまれているため、時間、イベント名、そのイベントを開始したユーザ、ユーザの送信元 IP アドレスのみ確認できます。ユーザと IP アドレスの「システム」は、デバイス自体がイベントを開始したことを意味しています。

次を実行できます。

  • イベント名の横にある [>] をクリックしてイベントを開き、イベントの詳細を確認します。もう一度アイコンをクリックするとイベントが閉じます。多くのイベントには、イベント属性（イベント タイプ、ユーザ名、送信元 IP アドレスなど）の簡単なリストがあります。ただし、エンティティ イベントと展開イベントには次の 2 つのタブがあります。

    • [概要（Summary）]：基本的なイベント属性が示されます。

    • [差異ビュー（Differences View）]：既存の「展開済み」設定とイベントの一部として行われた変更との比較が示されます。展開ジョブの場合、このビューは長く、スクロールする必要がある場合があります。このタブには、展開ジョブの一部だったエンティティ イベントの変更のすべての差異が要約されます。

  • [フィルタ（Filter）] フィールドの右にあるドロップダウン リストから別の時間範囲を選択します。デフォルトでは、過去 2 週間のイベントが表示されますが、過去 24 時間、7 日間、月、または 6 ヵ月に変更できます。[カスタム（Custom）] をクリックし、開始および終了日時を入力して、正確な範囲を指定します。

  • ログ内で任意のリンクをクリックして、該当項目の検索フィルタを追加します。リストが更新されて、該当項目を含むイベントだけが表示されます。単純に [フィルタ（Filter）] ボックスをクリックして、フィルタを直接作成することもできます。フィルタ ボックスの下には事前定義済みのフィルタがいくつかあり、クリックして関連するフィルタ条件をロードできます。イベントのフィルタリングの詳細については、監査ログのフィルタリングを参照してください。

  • ブラウザ ページをリロードして、ログを最新のイベントで更新します。

監査ログのフィルタリング

監査ログにフィルタを適用して、特定のタイプのメッセージだけが表示されるように絞り込むことができます。フィルタの各要素は、正確な完全一致です。たとえば、「User = admin」では admin という名前のユーザが開始したイベントだけが表示されます。

次の手法を単独または組み合わせて使用して、フィルタを作成できます。このリストは、フィルタ要素を追加するたびに自動的に更新されます。

事前定義のフィルタをクリック

[フィルタ（Filter）] フィールドの下には事前定義のフィルタがあります。リンクをクリックするだけでフィルタがロードされます。確認を求められます。すでにフィルタが適用されている場合は、追加されず、置き換えられます。

強調表示された項目をクリック

フィルタを作成する最も簡単な方法は、フィルタリングの基準となる値を含むログ テーブルまたはイベント詳細情報内の項目をクリックすることです。項目をクリックすると、その値と要素の組み合わせに正しく定式化されている要素を使用して、[フィルタ（Filter）] フィールドが更新されます。ただし、この手法を使用するには、イベントの既存のリストに目的の値が含まれている必要があります。

項目に関するフィルタ要素を追加できる場合は、その項目にマウス カーソルを合わせると下線が引かれ、[クリックしてフィルタに追加（Click to Add to Filter）] コマンドが表示されます。

アトミック要素を選択

[フィルタ（Filter）] フィールドをクリックして、ドロップダウン リストから必要なアトミック要素を選択し、等号の後に照合値を入力してから Enter キーを押すことでフィルタを作成することもできます。次の要素に関するフィルタリングを実行できます。すべての要素がすべてのイベント タイプに関連するわけではないことに注意してください。

  • [イベントタイプ（Event Type）]：これは、通常、イベント名と同じですが、異なる場合もあります（エンティティ名やユーザーのような可変修飾子はありません）。展開イベントの場合、イベント タイプは Deployment Event（展開イベント）です。イベント タイプの説明については、監査イベントを参照してください。

  • [ユーザ（User）]：イベントを開始したユーザの名前。システム ユーザは SYSTEM（すべて大文字）です。

  • [送信元IP（Source IP）]：ユーザーがイベントを開始した IP アドレス。システムが開始したイベントの送信元 IP アドレスは SYSTEM です。

  • [エンティティID（Entity ID）]：エンティティまたはオブジェクトの UUID。これは、理解できない長い文字列（8e7021b4-2e1e-11e8-9e5d-0fc002c5f931 など）です。通常、このフィルタを使用するには、イベント詳細情報内のエンティティ ID をクリックするか、REST API を使用し、関連する GET コールによって必要な ID を取得する必要があります。

  • [エンティティ名（Entity Name）]：エンティティまたはオブジェクトの名前。ユーザが作成したエンティティの場合は、通常、ユーザがオブジェクトに付けた名前（ネットワーク オブジェクトの InsideNetwork など）です。システムが生成したエンティティの場合は（一部のユーザー定義のエンティティについても）、事前定義されていて理解できる名前です。たとえば、明示的に名前を付けない展開ジョブの場合は「User (admin) Triggered Deployment」です。

  • [エンティティタイプ（Entity Type）]：エンティティまたはオブジェクトの種類。これらは、事前定義されていて理解できる名前（Network Object など）です。API エクスプローラで「type」値の関連オブジェクト モデルを調べることによってエンティティ タイプを確認できます。通常、API タイプはすべて小文字であり、スペースは含まれません。それらをモデルに表示されているとおりに正確に入力し、Enter キーを押すと、文字列が理解しやすい形式に変更されます。どちらの形式で入力しても機能します。API エクスプローラを開くには、[詳細オプション（More options）] ボタン（[その他のオプション（More options）] ボタン。）をクリックし、[APIエクスプローラ（API Explorer）] を選択します。

複雑な監査ログ フィルタのルール

複数のアトミック要素を含む複雑なフィルタを作成する場合、次のルールに注意してください。

  • 同じタイプの要素には、そのタイプのすべての値の間に OR 関係があります。たとえば、「User = admin」と「User = SYSTEM」が含まれている場合、いずれかのユーザによって開始されたイベントと一致します。

  • 異なるタイプの要素には、AND 関係があります。たとえば、「Event Type = Entity Updated」と「User = SYSTEM」が含まれている場合、アクティブ ユーザではなくシステムがエンティティを更新したイベントだけが表示されます。

  • ワイルドカード、正規表現、部分一致、または単純なテキスト文字列の一致は使用できません。

展開およびエンティティ変更履歴の確認

展開およびエンティティ イベントの詳細には、[差異ビュー（Differences View）] タブが含まれています。このタブには、古い設定と変更の色分けされた比較が表示されます。

  • 展開ジョブの場合は、展開前にデバイスで実行されていた設定と、実際に展開された変更との比較です。

  • エンティティ イベントの場合は、オブジェクトの以前のバージョンに行われた設定の変更です。エンティティ イベントの場合は、オブジェクトの以前のバージョンに行われた設定の変更です。

手順

ステップ 1

[デバイス（Device）] をクリックし、[デバイス管理（Device Administration）] > [設定の表示（View Configuration）] リンクをクリックします。

ステップ 2

目次の [監査ログ（Audit Log）] をクリックします（未選択の場合）。

ステップ 3

（オプション）メッセージのフィルタ処理：

  • 展開イベント：フィルタ ボックスの下にある [展開履歴（Deployment History）] 事前定義フィルタをクリックします。

  • エンティティ変更イベント：関心のある変更の種類に対して、[イベントの種類（Event Type）] 要素を使用してフィルタを手動で作成します。すべてのエンティティの変更を確認するには、[作成済みエンティティ（Entity Created）]、[更新済みエンティティ（Entity Updated）]、および [削除済みエンティティ（Entity Deleted）] の 3 つの仕様を含めます。フィルタは次のようになります。


    エンティティの変更イベントをフィルタ処理します。

ステップ 4

イベントを開き、[差異ビュー（Differences View）] タブをクリックします。


差異ビュー。

変更は色分けされていて、見出しにはオブジェクトの種類と、Added（作成）、Removed（削除）、または Edited（更新）が表示されます。Edited オブジェクトには、変更された属性またはオブジェクトから削除された属性のみ表示されます。展開ジョブの場合、変更されたエンティティごとに個別の見出しがあります。見出しには、オブジェクトのエンティティ タイプが示されます。

保留中の全変更の廃棄

まだ展開されていない一連の設定の変更に納得していない場合は、すべての保留中の変更を破棄できます。破棄すると、すべての機能がデバイスに存在する状態に戻ります。その後、設定の変更をもう一度を開始できます。

手順

ステップ 1

Web ページの右上にある [変更の展開（Deploy Changes）] アイコンをクリックします。

保留中の変更がある場合、アイコンがドット付きで強調表示されます。

Deploy changes button, highlighted when there are changes to deploy.

ステップ 2

[詳細オプション（More Options）] > [すべて破棄（Discard All）] をクリックします。

ステップ 3

確認ダイアログで [OK] をクリックします。

変更が破棄され、プロセスが完了すると、保留中の変更がないことを示すメッセージが表示されます。監査ログに [保留中の変更の破棄（Pending Changes Discarded）] イベントが追加されます。

デバイス設定のエクスポート

現在展開されている設定のコピーを JSON 形式でエクスポートできます。このファイルは、アーカイブまたはレコードの保存目的で使用できます。パスワードや秘密キーなどのセンシティブ データはすべてマスク処理されます。

ファイルを当該デバイスや別のデバイスにインポートすることはできません。この機能は、システム バックアップの代替機能ではありません。

設定をダウンロードする前に、少なくとも 1 つの展開ジョブが正常に完了している必要があります。

手順

ステップ 1

[デバイス（Device）] を選択し、[デバイス管理（Device Administration）] グループで [設定の表示（View Configuration）] をクリックします。

ステップ 2

目次で [設定のダウンロード（Download Configuration）] をクリックします。

ステップ 3

[デバイス設定の取得（Get Device Configuration）] をクリックして、ファイルを作成するジョブを開始します。

ファイルを事前に作成している場合、ファイルの作成日とともに、[ダウンロード（Download）] ボタンと「File is ready to download」メッセージが表示されます。

設定のサイズによっては、ファイルの生成に数分かかることがあります。タスク リストや監査ログを確認したり、定期的にこのページに戻ったりして、Export Config ジョブが完了してファイルが生成されるのを待ちます。

ステップ 4

ファイルが生成されたらこのページに戻り、[設定ファイルのダウンロード（Download the Configuration File）] ボタン（Download file button.）をクリックして、ファイルをワークステーションに保存します。

Device Manager および Threat Defense ユーザーアクセスの管理

ユーザーが Threat Defense にログイン（HTTPS アクセス）するための外部認証および認可ソースを設定できますローカル ユーザ データベースとシステム定義の管理者ユーザに加えて（またはその代わりに）外部サーバを使用できます。Device Manager アクセス用の追加のローカルユーザーアカウントは作成できないことに注意してください。

設定を変更できる複数の外部 Device Manager ユーザーアカウントを用意できますが、それらの変更がユーザーごとに追跡されることはありません。1 人のユーザが変更を展開すると、すべてのユーザが行った変更が展開されます。ロック機能はありません。つまり、複数のユーザが同じオブジェクトの更新を同時に試みることができます。その結果、1 人のユーザだけが変更を正常に保存できます。また、ユーザに基づいて変更を破棄することもできません。

5 つのユーザーセッションを同時に処理できます。6 人目のユーザがログインすると、最も古いユーザ セッションが自動的にログオフされます。また、アイドル タイムアウトがあり、非アクティブ ユーザは 20 分後にログアウトされます。

脅威に対する防御 CLI への SSH アクセスでは、外部認証および認可を設定することもできます。ローカル データベースは外部ソースを使用する前に常にチェックされるため、フェールセーフ アクセスでは追加のローカル ユーザを作成することができます。ローカルソースと外部ソースの両方で重複するユーザを作成しないでください。管理者ユーザーを除き、CLI ユーザーと Device Manager ユーザーが入れ替わることはありません。ユーザーアカウントは完全に個別です。


（注）  

外部サーバーを使用する場合、個別の AAA サーバーグループを設定するか、 AAA サーバー内に認証/認可ポリシーを作成して、ユーザーが特定の 脅威に対する防御 デバイスの IP アドレスだけにアクセスできるようにすることで、ユーザーによるデバイスのサブセットへのアクセスを制御できます。

ここでは、Device Manager および CLI ユーザーアクセスの設定方法と管理方法について説明します。

Device Manager （HTTPS）ユーザー用の外部認証（AAA）設定

外部 AAA サーバーからの Device Manager への HTTPS アクセスを提供できます。AAA 認証および認可を有効にすることにより、さまざまなレベルのアクセス権を付与でき、すべてのユーザーがローカル管理者アカウントを使用してログインする必要がなくなります。

これらの外部ユーザは、Threat Defense API および API エクスプローラについても認証されます。

AAA サーバーで管理ユーザーの認可を設定することで、ロールベース アクセス コントロール（RBAC）を提供できます。使用できる値はサーバータイプによって異なります。ユーザーが Device Manager にログインすると、ページの右上隅にユーザー名とロールが表示されます。AAA サーバーで正しくアカウントを設定すると、次の手順で管理アクセス用にそのアカウントを有効にできます。

SAML ユーザー認証

SAML サーバー アイデンティティ ソースを設定するときに、承認レベルを含むフィールドを指定します。外部ユーザーには、管理者、監査管理者、暗号管理者、読み取り/書き込みユーザー、読み取り専用ユーザーの認証アクセスタイプを設定できます。SAML サーバーの設定 を参照してください。

RADIUS ユーザー認証

ロールベース アクセス コントロール（RBAC）を提供するには、RADIUS サーバー上のユーザーアカウントを更新して、cisco-av-pair 属性を定義します（これは ISE の場合で、FreeRADIUS ではこの属性のスペルは Cisco-AVPair です。使用しているシステムで正しいスペルを確認してください）。この属性はユーザーアカウントで正しく定義されている必要があります。正しく定義されていないと、ユーザーの Device Manager へのアクセスが拒否されます。cisco-av-pair 属性のサポートされる値は、次のとおりです。

  • fdm.userrole.authority.admin はフル管理者アクセスを提供します。これらのユーザは、ローカル管理者ユーザが実行できるすべてのアクションを実行できます。

  • fdm.userrole.authority.rw は読み取り/書き込みアクセスを提供します。これらのユーザは、読み取り専用ユーザが実行できるすべてのアクションを実行でき、設定を編集および展開することもできます。アップグレードのインストール、バックアップの作成と復元、監査ログの表示、Device Manager ユーザーのセッションの終了など、システムクリティカルなアクションに対してのみ制限があります。

  • fdm.userrole.authority.ro は読み取り専用アクセスを提供します。これらのユーザは、ダッシュボードと設定を表示できますが、変更できません。ユーザが変更しようとすると、権限が不足していることを示すエラー メッセージが表示されます。

手順

ステップ 1

[デバイス（Device）] をクリックしてから、[システム設定（System Settings）] > [管理アクセス（Management Access）] リンクの順にクリックします。

[System Settings] ページがすでに表示されている場合は、目次で [Management Access] をクリックします。

ステップ 2

まだ選択されていない場合は、[AAA設定（AAA Configuration）] タブをクリックします。

ステップ 3

[HTTPS接続（HTTPS Connection）] オプションの設定。

  • [管理/REST API用のサーバーグループ（Server Group for Management/REST API）]：プライマリ認証ソースとして使用する RADIUS または SAML サーバーグループ（外部認証/認可用）またはローカル ユーザー データベース（LocalIdentitySource）を選択します。

    サーバーグループがまだ存在しない場合は、リンクをクリックしてすぐに作成します。RADIUS の場合、サーバーごとに RADIUS サーバーオブジェクトを作成してグループに追加する必要もありますが、サーバーグループを定義するときにこれを実行できます。RADIUS の詳細については、RADIUS サーバおよびグループを参照してください。 SAML の詳細については、SAML サーバーの設定を参照してください。

  • [ローカルによる認証（Authentication with LOCAL）]（RADIUS のみ）：外部 RADIUS サーバーグループを選択する場合、ローカル [管理（admin）] アカウントを含むローカル アイデンティティ ソースを使用する方法を指定できます。次のいずれかを選択します。

    • [外部サーバの前（Before External Server）]：システムは、まずローカル ソースに対してユーザ名とパスワードを確認します。

    • [外部サーバの後（After External Server）]：外部ソースが使用できない場合またはユーザ アカウントが外部ソースで見つからなかった場合にのみ、ローカル ソースが確認されます。

    • [使用しない（Never）]：（非推奨）ローカル ソースがまったく使用されないため、管理者ユーザとしてログインできません。

      注意    

       

      [使用しない（Never）] を選択すると、[管理（admin）] アカウントを使用して Device Manager にログインできなくなります。AAA サーバーが使用できなくなった場合または AAA サーバーのアカウント設定が間違っている場合は、システムがロックされます。

    （注）  

     

    [ローカルによる認証（Authentication with LOCAL）] は、SAML を使用する場合は適用されません。SAML では、SAML ログイン情報を入力するために [シングルサインオン（SSO）（Single-Sign On (SSO)）] リンクを明示的にクリックする必要があるため、ローカルのユーザー名とパスワードを入力することで、いつでもローカルデータベースを使用してログインできます。

ステップ 4

[保存（Save）] をクリックします。

Threat Defense CLI（SSH）ユーザー用の外部認証（AAA）設定

外部 RADIUS サーバーからの Threat Defense CLI への SSH アクセスを提供できます。RADIUS 認証および許可を有効にすることで、デバイスごとに個別のローカルユーザアカウントを定義するのではなく、単独の認証ソースからさまざまなレベルのアクセス権を提供することができます。

これらの SSH 外部ユーザは、Threat Defense API および API エクスプローラについては認証されません。SSH の許可を定義するために使用するメカニズムは、HTTPS アクセスに必要なものとは異なります。ただし、SSH と HTTPS の両方の許可条件で同じ RADIUS ユーザを設定し、どちらのプロトコルでも特定のユーザがシステムにアクセスできるようにすることは可能です。

SSH アクセスにロールベースのアクセス制御（RBAC）を提供するには、RADIUS サーバ上のユーザアカウントを更新して Service-Type 属性を定義します。この属性はユーザアカウントで定義されている必要があります。定義されていないと、ユーザの SSH へのアクセスが拒否されます。次に、Service-Type 属性でサポートされている値を示します。

  • [Administrator (6)]：CLI への config アクセス認証を提供します。これらのユーザは、CLI ですべてのコマンドを使用できます。

  • NAS Prompt (7) または 6 以外のレベル：CLI への basic アクセス認証を提供します。これらのユーザは show コマンドなど、モニタリングやトラブルシューティングのための読み取り専用コマンドを使用できます。

RADIUS サーバで正しくアカウントを設定すると、次の手順で SSH 管理アクセス用にそのアカウントを有効にできます。


（注）  

ローカルソースと外部ソースの両方で重複するユーザを作成しないでください。重複するユーザ名を作成する場合は、同じ認証権限を持っていることを確認します。許可権限がローカルユーザアカウントで異なる場合、外部バージョンのユーザアカウントのパスワードを使用してログインすることはできません。ログインできるのはローカルのパスワードを使用した場合のみです。権限が同じ場合、パスワードが異なると仮定して、使用するパスワードによって外部ユーザまたはローカルユーザのどちらでログインしているかが判断されます。最初にローカルデータベースが確認されますが、ユーザ名がローカルデータベースに存在するがパスワードが正しくない場合、外部サーバが確認され、外部ソースのパスワードが正しい場合、ログインが成功します。

始める前に

外部定義ユーザに次の動作を通知し、希望通りに設定できるようにしてください。

  • 外部ユーザーが初めてログインすると、Threat Defense は必要な構造を作成しますが、ユーザーセッションを同時に作成することはできません。ユーザがセッションを開始するには、再度認証する必要があるだけです。ユーザには次のようなメッセージが表示されます。「New external username identified. Please log in again to start a session.」

  • 同様に、最後のログイン以降に Service-Type で定義したユーザの認証が変更された場合は、ユーザは再認証する必要があります。ユーザには次のようなメッセージが表示されます。「Your authorization privilege has changed. セッションを開始するにはもう一度ログインしてください。（Please log in again to start a session.）」

手順

ステップ 1

[デバイス（Device）] をクリックしてから、[システム設定（System Settings）] > [管理アクセス（Management Access）] リンクの順にクリックします。

[System Settings] ページがすでに表示されている場合は、目次で [Management Access] をクリックします。

ステップ 2

まだ選択されていない場合は、[AAA設定（AAA Configuration）] タブをクリックします。

ステップ 3

[SSH接続（SSH Connection）] のオプションを設定します。

  • [サーバグループ（Server Group）]：プライマリ認証ソースとして使用する RADIUS サーバ グループまたはローカル ユーザ データベース（LocalIdentitySource）を選択します。外部認証を使用する RADIUS サーバ グループを選択する必要があります。

    サーバ グループがまだ存在しない場合は、[新しいRADIUSサーバグループの作成（Create New RADIUS Server Group）] リンクをクリックしてすぐに作成します。サーバごとに RADIUS サーバ オブジェクトを作成してグループに追加する必要もありますが、サーバ グループを定義するときにこれを実行できます。RADIUS の詳細については、RADIUS サーバおよびグループを参照してください。

    SSH 接続では、グループ内の最初の 2 台のサーバのみが使用されることに注意してください。3 つ以上のサーバがあるグループを使用する場合、追加のサーバが試行されることはありません。さらに、[デッドタイム（Dead Time）] と [最大失敗試行数（Maximum Failed Attempts）] グループ属性は使用されません。

  • [ローカルによる認証（Authentication with LOCAL）]：外部サーバ グループを選択する場合、ローカル アイデンティティ ソースを使用する方法を指定できます。SSH アクセスでは、ローカルデータベースが常に外部サーバの前に確認されます。

ステップ 4

[保存（Save）] をクリックします。

Device Manager ユーザーセッションの管理

[モニタリング（Monitoring）] > [セッション（Sessions）] を選択すると、現在 Device Manager にログインしているユーザーのリストが表示されます。このリストには、各ユーザが現在のセッションにログインしている時間が示されます。

同じユーザ名が複数回表示される場合は、ユーザが異なる送信元アドレスからセッションを開いたことを意味します。セッションは、ユーザ名と送信元アドレスに基づいて個別に追跡され、各セッションは固有のタイムスタンプを持ちます。

このシステムでは、5 つの同時ユーザ セッションが可能です。6 人目のユーザがログインすると、最も古い現在のセッションが自動的にログアウトされます。また、アイドル状態のユーザは、アクティビティが 20 分間ないと自動的にログアウトされます。

Device Manager ユーザーが誤ったパスワードを入力し、3 回連続してログインに失敗した場合、アカウントは 5 分間ロックされます。ユーザーが再度ログインを試みるには、待機する必要があります。Device Manager ユーザーアカウントをロック解除する方法はありません。また、再試行回数やロックタイムアウトを調整することもできません（SSH ユーザーの場合は、これらの設定を調整し、アカウントのロックを解除することができます）。

必要に応じて、セッションの [削除（delete）] アイコン（delete icon）をクリックすることにより、ユーザー セッションを終了させることができます。自分自身のセッションを削除すると、自分もログアウトされます。セッションを終了させた場合、ロックアウト期間はなく、ユーザーはすぐにログインしなおすことができます。

外部ユーザー用のスタンバイ HA ユニットでの Device Manager アクセスの有効化

Device Manager ユーザー用に外部認証を設定すると、これらのユーザーはハイアベイラビリティペアのアクティブおよびスタンバイ装置の両方にログインできます。ただし、スタンバイユニットへの初回ログインを成功させるには、アクティブユニットへのログインと比較して、いくつかの追加手順を実行する必要があります。

外部ユーザーがアクティブユニットに初めてログインすると、そのユーザーとユーザーのアクセス権を定義するオブジェクトが作成されます。管理者または読み取り/書き込みユーザーはその後、アクティブな装置からユーザーオブジェクトの設定を展開し、スタンバイ装置で表示されるようにする必要があります。

展開および後続の設定の同期が正常に完了して初めて、外部ユーザーはスタンバイユニットにログインできます。

管理者ユーザーと読み取り/書き込みユーザーは、アクティブユニットにログイン後に変更を展開できます。ただし、読み取り専用ユーザーは設定を展開できないため、適切な権限を持つユーザーに設定を展開を依頼する必要があります。

Threat Defense CLI のローカル ユーザー アカウントの作成

脅威に対する防御 デバイスで CLI にアクセスするユーザーを作成できます。これらのアカウントは管理アプリケーションへのアクセスは許可されず、CLI へのアクセスのみが有効になります。CLI はトラブルシューティングやモニターリング用に役立ちます。

複数のデバイス上にローカルユーザーアカウントを一度に作成することはできません。デバイスごとに固有のローカルユーザー CLI アカウントのセットがあります。

手順

ステップ 1

config 権限を持つアカウントを使用してデバイスの CLI にログインします。

管理者ユーザ アカウントには必要な権限がありますが、config 権限を持っていればどのアカウントでも問題ありません。SSH セッションまたはコンソール ポートを使用できます。

特定のデバイス モデルでは、コンソール ポートから FXOS CLI に移動します。connect ftd を使用して 脅威に対する防御 の CLI にアクセスします。

ステップ 2

ユーザー アカウントを作成します。

configure user add username {basic | config}

次の権限レベルを持つユーザを定義できます。

  • config ：ユーザーに設定アクセス権を付与します。すべてのコマンドの管理者権限がユーザに与えられます。

  • basic ：ユーザーに基本的なアクセス権を付与します。これはユーザに設定コマンドの入力を許可しません。

例:

次の例では、config アクセス権を使用して、joecool という名前のユーザ アカウントを追加します。パスワードは入力時に非表示となります。 


> configure user add joecool config
Enter new password for user joecool: newpassword
Confirm new password for user joecool: newpassword
> show user
Login              UID   Auth Access  Enabled Reset    Exp Warn  Str Lock Max
admin             1000  Local Config  Enabled    No  Never  N/A  Dis   No N/A
joecool           1001  Local Config  Enabled    No  Never  N/A  Dis   No   5

（注）  

 

configure password コマンドを使用してパスワードを変更できることをユーザーに伝えます。

ステップ 3

（任意）セキュリティ要件を満たすようにアカウントの性質を調整します。

次のコマンドを使用してデフォルトのアカウント動作を変更できます。

  • configure user aging username max_days warn_days

    ユーザのパスワードの有効期限を設定します。パスワードの最大有効日数と、有効期限が近づいたことをユーザに通知する警告を期限切れとなる何日前に発行するかを指定します。どちらの値も 1 ~ 9999 ですが、警告までの日数は最大日数以内にする必要があります。アカウントの作成時はパスワードの有効期限はありません。

  • configure user forcereset username

    次回ログイン時にユーザにパスワードを強制的に変更するよう要求します。

  • configure user maxfailedlogins username number

    アカウントがロックされる前の連続したログイン失敗の最大回数を 1 ～ 9999 までで設定します。configure user unlock コマンドを使用してアカウントのロックを解除します。新しいアカウントのデフォルトは、5 回連続でのログインの失敗です。

  • configure user minpasswdlen username number

    パスワードの最小長を 1 ～ 127 までで設定します。

  • configure user strengthcheck username { enable | disable}

    パスワードの変更時にユーザに対してパスワード要件を満たすように要求する、パスワードの強度確認を有効または無効にします。ユーザーパスワードの有効期限が切れた場合、または configure user forcereset コマンドを使用した場合は、ユーザーが次にログインしたときにこの要件が自動的に有効になります。

ステップ 4

必要に応じてユーザ アカウントを管理します。

ユーザをアカウントからロックアウトしたり、アカウントを削除するか、またはその他の問題を修正したりしなければならない可能性があります。システムのユーザー アカウントを管理するには、次のコマンドを使用します。

  • configure user access ユーザ名 { basic | config}

    ユーザ アカウントの権限を変更します。

  • configure user delete username

    指定したアカウントを削除します。

  • configure user disable username

    指定したアカウントを削除せず無効にします。アカウントを有効にするまでユーザはログインできません。

  • configure user enable username

    指定したアカウントを有効にします。

  • configure user password username

    指定したユーザのパスワードを変更します。ユーザーは通常 configure password コマンドを使用して自分のパスワードを変更する必要があります。

  • configure user unlock username

    ログイン試行の最大連続失敗回数の超過が原因でロックされたユーザー アカウントをロック解除します。

システムの再起動またはシャットダウン

必要に応じて、システムを再起動またはシャットダウンできます。

下記の手順以外に、reboot コマンドまたは shutdown コマンドを使用して、SSH セッションまたは Device Manager CLI コンソールからこれらのタスクを実行することもできます。

手順

ステップ 1

[デバイス（Device）] をクリックしてから、[システム設定（System Settings）] > [再起動/シャットダウン（Reboot/Shutdown）] > リンクをクリックします。

すでに [システム設定（System Settings）] ページを表示している場合は、目次の [再起動/シャットダウン（Reboot/Shutdown）] をクリックします。

ステップ 2

必要な機能を実行するボタンをクリックします。

  • [再起動（Reboot）]：システムが正常に動作しておらず、試行錯誤しても問題解決に至らない場合、デバイスを再起動できます。また、システムソフトウェアをリロードするためにデバイスを再起動するよう求める手順がいくつかあります。

  • [シャットダウン（Shut Down）]：システムをシャットダウンして、制御された方法で電源をオフにします。ネットワークからデバイスを削除する場合、たとえばデバイスを交換する場合は、シャットダウンを使用します。デバイスをシャットダウンした後は、ハードウェアのオン/オフスイッチからのみ電源をオンにすることができます。

ステップ 3

アクションが完了するまで待ちます。

コンソールからファイアウォールに接続している場合は、ファイアウォールがシャットダウンするときにシステムプロンプトをモニターします。次のプロンプトが表示されます。


System is stopped.
It is safe to power off now.
Do you want to reboot instead? [y/N]

ISA 3000 の場合、シャットダウンが完了すると、システム LED が消灯します。電源を切る前に、少なくとも 10 秒待ってください。

システムの再起動またはシャットダウン中は、Device Manager または CLI で他のアクションを実行できません。

再起動中、Device Manager のページが更新され、再起動が完了するとログインページに移動します。再起動が完了する前にページを更新しようとすると、その時点での Device Manager Web サーバーの動作状態に基づいて、Web ブラウザに 503 または 404 エラーが表示されることがあります。

シャットダウンの場合、システムは最終的にまったく応答しなくなり、404 エラーが表示されます。システムを完全にオフにしようとしているため、これは想定される結果です。

システムのトラブルシューティング

ここでは、いくつかのシステムレベルのトラブルシューティングのタスクおよび機能について説明します。特定の機能（アクセス コントロールなど）のトラブルシューティングの詳細については、その機能に関する章を参照してください。

接続をテストするための ping アドレス

ping は、特定のアドレスが使用可能で、応答するかどうかを確認するための単純なコマンドです。これは基本接続が機能していることを意味します。ただし、デバイスで実行されている他のポリシーにより、特定のタイプのトラフィックは正常にデバイスを通過できないことがあります。ping CLI コンソールを開く、またはデバイス CLI へのログインによって、使用することができます。


（注）  

システムには複数のインターフェイスがあるため、アドレスの ping に使用されるインターフェイスを制御できます。接続をテストすることが重要であるため、確実に正しいコマンドを使用する必要があります。たとえば、システムは管理インターフェイスを介してシスコのライセンスサーバーに到達する必要があります。この場合、ping system コマンドを使用して接続をテストする必要があります。ping を使用すると、複数のデータ インターフェイスを通じて到達できるかをテストするため、同じ結果が得られない可能性があります。

通常の ping は、ICMP パケットを使用して接続をテストします。ネットワークで ICMP が禁止されている場合は、代わりに TCP ping を使用できます（データ インターフェイスの ping のみ）。

IP アドレスまたは完全修飾ホスト名（FQDN）のいずれかを ping できます。ping が FQDN で機能するためには、管理インターフェイスまたはデータインターフェイスのいずれかに設定された DNS サーバーが IP アドレスを正常に返す必要があります。管理インターフェイスとデータインターフェイスに個別に DNS サーバーを設定する必要があります。特定のインターフェイスに DNS サーバーが設定されていない場合は、dig コマンドを使用して、特定の FQDN の IP アドレスを検索します。

次に、ネットワーク アドレスを ping するための主なオプションを示します。

管理インターフェイスを介したアドレスの ping

ping system コマンドを使用します。

ping system host

ホストは IP アドレスまたは完全修飾ドメイン名（FQDN）（www.example.com など）にできます。データ インターフェイスを介した ping とは違い、システム ping のデフォルト数はありません。ping は Ctrl+c を使用して停止するまで続けられます。次に例を示します。 


> ping system www.cisco.com
PING origin-www.cisco.COM (72.163.4.161) 56(84) bytes of data.
64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=1 ttl=242 time=10.6 ms
64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=2 ttl=242 time=8.13 ms
64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=3 ttl=242 time=8.51 ms
64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=4 ttl=242 time=8.40 ms
^C
--- origin-www.cisco.COM ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 8.139/8.927/10.650/1.003 ms
>
ルーティング テーブルを使用するデータ インターフェイスを介したアドレスの ping

ping コマンドを使用します。インターフェイスを指定せずに、システムが一般的にホストへのルートを検索できるかどうかをテストします。システムは通常このようにしてトラフィックをルーティングするため、一般的に実行する必要があるのはこのテストです。

ping host

次に例を示します。 


> ping 171.69.38.1
Sending 5, 100-byte ICMP Echos to 171.69.38.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms

（注）  

タイムアウト、繰り返し回数、パケット サイズ、さらには送信するデータ パターンを指定できます。使用可能なオプションを表示するには、CLI でヘルプ インジケータの「?」を使用します。

特定のデータ インターフェイスを介したアドレスの ping

特定のデータインターフェイスを経由した接続をテストする場合、ping interface if_name コマンドを使用します。

ping interface if_name host

次に例を示します。 


> ping interface inside 171.69.38.1
Sending 5, 100-byte ICMP Echos to 171.69.38.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms
TCP ping を使用するデータ インターフェイスを介したアドレスの ping

ping tcp コマンドを使用します。TCP ping では、SYN パケットを送信し、宛先から SYN-ACK パケットが返されると成功と見なします。

ping tcp [interface if_name] host port

ホストと TCP ポートを指定する必要があります。FQDN のみが判明している場合は、nslookup fqdn-name コマンドを使用して、IP アドレスを判別します。

オプションで、ping を送信するインターフェイスではなく、ping の送信元インターフェイスであるインターフェイスを指定できます。このタイプの ping では、必ずルーティング テーブルを使用します。

TCP ping では、SYN パケットを送信し、宛先から SYN-ACK パケットが返されると成功と見なします。次に例を示します。 


> ping tcp 10.0.0.1 21
Type escape sequence to abort.
No source specified. Pinging from identity interface.
Sending 5 TCP SYN requests to 10.0.0.1 port 21
from 10.0.0.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

（注）  

タイムアウト、繰り返し回数、および TCP ping の送信元アドレスも指定できます。使用可能なオプションを表示するには、CLI でヘルプ インジケータの「?」を使用します。

ホストまでのルートの追跡

IP アドレスへのトラフィックの送信で問題が発生している場合は、ホストまでのルートを追跡することによってネットワーク パスに問題がないかどうかを確認できます。トレースルートでは、宛先に対して、無効なポートで UDP パケットを送信したり、ICMPv6 エコーを送信したりします。宛先までの途中にあるルータから ICMP Time Exceeded メッセージが返され、トレースルートにそのエラーが報告されます。各ノードは 3 つのパケットを受信するため、有益な結果を得る機会が 1 台のノードにつき 3 回あります。traceroute CLI コンソールを開く、またはデバイス CLI へのログインによって、 を使用することができます。


（注）  

データインターフェイス（traceroute ）または仮想管理インターフェイス（traceroute system ）を経由するルートをトレースするための個別のコマンドがあります。適切なコマンドを使用するようにしてください。

次の表に、パケットによって出力に表示される可能性のある結果を示します。

出力記号

説明

*

タイムアウトの期間内にプローブへの応答を受信しませんでした。

nn msec

各ノードで、指定した数のプローブのラウンドトリップにかかる時間（ミリ秒）。

!N.

ICMP ネットワークに到達できません。

!H

ICMP ホストに到達できません。

!P

ICMP プロトコルに到達できません。

!A

ICMP が管理者によって禁止されています。

?

原因不明の ICMP エラーが発生しました。

仮想管理インターフェイスを介したルートの追跡

traceroute system コマンドを使用します。

traceroute system [接続先（Destination）]

ホストには、IPv4/IPv6 アドレスまたは完全修飾ドメイン名（FQDN）（www.example.com など）を使用できます。次に例を示します。 


> traceroute system www.example.com 
traceroute to www.example.com (172.163.4.161), 30 hops max, 60 byte packets
 1  192.168.0.254 (192.168.0.254)  0.213 ms  0.310 ms  0.328 ms
 2  10.88.127.1 (10.88.127.1)  0.677 ms  0.739 ms  0.899 ms
 3  lab-gw1.example.com (10.89.128.25)  0.638 ms  0.856 ms  0.864 ms
 4  04-bb-gw1.example.com (10.152.240.65)  1.169 ms  1.355 ms  1.409 ms
 5  wan-gw1.example.com (10.152.240.33)  0.712 ms  0.722 ms  0.790 ms
 6  wag-gw1.example.com (10.152.240.73)  13.868 ms  10.760 ms  11.187 ms
 7  rbb-gw2.example.com (172.30.4.85)  7.202 ms  7.301 ms  7.101 ms
 8  rbb-gw1.example.com (172.30.4.77)  8.162 ms  8.225 ms  8.373 ms
 9  sbb-gw1.example.com (172.16.16.210)  7.396 ms  7.548 ms  7.653 ms
10  corp-gw2.example.com (172.16.16.58)  7.413 ms  7.310 ms  7.431 ms
11  dmzbb-gw2.example.com (172.16.0.78)  7.835 ms  7.705 ms  7.702 ms
12  dmzdcc-gw2.example.com (172.16.0.190)  8.126 ms  8.193 ms  11.559 ms
13  dcz05n-gw1.example.com (172.16.2.106)  11.729 ms  11.728 ms  11.939 ms
14  www1.example.com (172.16.4.161)  11.645 ms  7.958 ms  7.936 ms
データ インターフェイスを介したルートの追跡

traceroute コマンドを使用します。

traceroute [接続先（Destination）]

データインターフェイスに DNS サーバーを設定する場合、ホストには IPv4/IPv6 アドレスまたは www.example.com のような完全修飾ドメイン名（FQDN）を指定できます。特定のインターフェイスに DNS サーバーが設定されていない場合は、dig コマンドを使用して、特定の FQDN の IP アドレスを検索します。次に例を示します。 


> traceroute 209.165.200.225
Tracing the route to 209.165.200.225
 1  10.83.194.1 0 msec 10 msec 0 msec
 2  10.83.193.65 0 msec 0 msec 0 msec
 3  10.88.193.101 0 msec 10 msec 0 msec
 4  10.88.193.97 0 msec 0 msec 10 msec
 5  10.88.239.9 0 msec 10 msec 0 msec
 6  10.88.238.65 10 msec 10 msec 0 msec
 7 172.16.7.221 70 msec 70 msec 80 msec
 8 209.165.200.225 70 msec 70 msec 70 msec

（注）  

タイムアウト、パケット存続時間、1 ノードあたりのパケット数、およびトレースルートの送信元として使用する IP アドレスまたはインターフェイスを指定できます。使用可能なオプションを表示するには、CLI でヘルプ インジケータの「?」を使用します。

デバイスのトレースルートへの表示

デフォルトでは、Threat Defense デバイスは、トレースルートにホップとして表示されません。表示されるようにするには、デバイスを通過するパケットの存続可能時間を減らし、ICMP 到達不能メッセージのレート制限を増やす必要があります。そのためには、必要なサービス ポリシー ルールとその他のオプションを設定する FlexConfig オブジェクトを作成する必要があります。

サービス ポリシーとトラフィック クラスの詳細については、https://www.cisco.com/c/en/us/support/security/asa-firepower-services/products-installation-and-configuration-guides-list.html で入手可能な『Cisco ASA Series Firewall Configuration Guide』を参照してください。


（注）  

パケット存続時間（TTL）をデクリメントすると、TTL が 1 のパケットはドロップされますが、接続に TTL がより大きいパケットを含むと想定されるセッションでは、接続が開かれます。OSPF hello パケットなどの一部のパケットは TTL = 1 で送信されるため、パケット存続時間（TTL）をデクリメントすると、予期しない結果が発生する可能性があります。トラフィック クラスを定義する際には、これらの考慮事項に注意してください。

手順

ステップ 1

[デバイス（Device）] > [詳細設定（Advanced Configuration）] で [設定の表示（View Configuration）] をクリックします。

ステップ 2

詳細設定の目次で [FlexConfig] > [FlexConfigオブジェクト（FlexConfig Objects）] をクリックします。

ステップ 3

TTL を減らすためのオブジェクトを作成します。

  1. 新しいオブジェクトを作成するには、[+] ボタンをクリックします。

  2. オブジェクトの名前を入力します。例、Decrement_TTL。

  3. [テンプレート（Template）] エディタで、インデントを含む次の行を入力します。 

    
icmp unreachable rate-limit 50 burst-size 1
policy-map global_policy
 class class-default
  set connection decrement-ttl

  4. [ネゲートテンプレート（Negate Template）] エディタで、この設定を元に戻すために必要な行を入力します。

    適切なサブモードでコマンドを有効にするために、ネゲート テンプレートに、親コマンドと同様にこれらのコマンドも含める必要があります。

    FlexConfig ポリシーからこのオブジェクトを削除した場合（正常に導入された後）、および導入が失敗した場合でも（設定を前の状態にリセットするため）、ネゲート テンプレートが適用されます。

    したがって、この例では、ネゲート テンプレートは次のようになります。 

    
no icmp unreachable rate-limit 50 burst-size 1
policy-map global_policy
 class class-default
  no set connection decrement-ttl

  5. [OK] をクリックしてオブジェクトを保存します。

ステップ 4

オブジェクトを FlexConfig ポリシーに追加します。

FlexConfig ポリシー内の選択したオブジェクトのみ展開されます。

  1. 目次で [FlexConfigポリシー（FlexConfig Policy）] をクリックします。

  2. [グループリスト（Group List）] で [+] をクリックします。

  3. Decrement_TTL オブジェクトを選択し、[OK] をクリックします。

    プレビューはテンプレートのコマンドで更新されます。予想されるコマンドが表示されているか確認します。

  4. [保存（Save）] をクリックします。

    これでポリシーを展開できます。

NTP のトラブルシューティング

システムは、正確で一貫性のある時間に基づいて正しく動作し、イベントやその他のデータ ポイントを正確に処理します。少なくとも 1 つ、理想的には 3 つの Network Time Protocol（NTP）サーバーで、システムが常に信頼できる時間情報を取得できるようにする必要があります。

デバイスの接続概要図（メイン メニューで [デバイス（Device）] をクリック）に、NTP サーバーへの接続ステータスが示されます。ステータスが黄色またはオレンジ色の場合、設定したサーバーへの接続に問題があります。接続の問題が解消されない（一時的な問題ではない）場合は、次の操作を試します。

  • まず、[デバイス（Device）] > [システム設定（System Settings）] > [NTP（NTP）] で 3 つ以上の NTP サーバーが設定されていることを確認します。これは要件になっていませんが、NTP サーバーが 3 つ以上あると信頼性が大幅に向上します。

  • 管理インターフェイス IP アドレス（[デバイス（Device）] > [システム設定（System Settings）] > [管理インターフェイス（Management Interface）] で定義される）と NTP サーバーの間にネットワーク パスがあることを確認します。

    • 管理インターフェイス ゲートウェイがデータ インターフェイスであり、デフォルト ルートが不適切な場合、[デバイス（Device）] > [ルーティング（Routing）] で NTP サーバーに対するスタティック ルートを設定できます。

    • 明示的な管理インターフェイス ゲートウェイを設定する場合は、デバイス CLI にログインし、ping system コマンドを使用して各 NTP サーバーへのネットワーク パスがあるかどうかテストします。

  • デバイス CLI にログインし、次のコマンドを使用して NTP サーバーのステータスを確認します。

    • show ntp ：このコマンドは、NTP サーバとその可用性に関する基本的な情報を示します。ただし、Device Manager の接続ステータスではその他の情報を使用してステータスを示すため、このコマンドが示す内容や接続ステータス図が示す内容と一致しないことがあります。このコマンドは CLI コンソールから発行することもできます。

    • system support ntp ：このコマンドには、show ntp の出力と、NTP プロトコルで記載される標準 NTP コマンド ntpq の出力が含まれています。NTP 同期を確認する必要がある場合は、このコマンドを使用します。

      「Results of ‘ntpq -pn」の部分を探します。たとえば、次のように表示されます。 

      
Results of 'ntpq -pn'
remote                    : +216.229.0.50
refid                     : 129.7.1.66
st                        : 2
t                         : u
when                      : 704
poll                      : 1024
reach                     : 377
delay                     : 90.455
offset                    : 2.954
jitter                    : 2.473

      この例では、NTP サーバのアドレスの前の「+」は、潜在的な候補であることを示します。アスタリスク * は、現在の時刻源のピアを示します。

      NTP デーモン（NTPD）は、各ピアから取得される 8 つのサンプルのスライディングウィンドウを使用して、1 つのサンプルをピックアップします。その後、クロック選択によって正しいチャイマーと不正なティッカーが特定されます。次に、NTPD がラウンドトリップ距離を特定します（候補のオフセットをラウンドトリップ遅延の半分以上にすることはできません）。接続の遅延、パケットの損失、またはサーバーの問題が発生して 1 つまたはすべての候補が拒否されると、同期中に長い遅延が生じます。また、調整にも非常に長い時間がかかります。クロック規律アルゴリズムによって、クロック オフセットおよびオシレータ エラーを解決する必要がありますが、これには数時間かかる可能性があります。


      （注）  

      refid が .LOCL. の場合は、ピアが無規律のローカル クロックであることを示します。つまり、時間設定にそのローカル クロックのみを使用します。選択したピアが .LOCL. の場合、Device Manager は NTP 接続を常に黄色（非同期）にマークします。通常 NTP は、より適切な候補を利用できる場合、.LOCL. 候補を選択しません。そのため、サーバーを 3 つ以上設定する必要があります。

管理インターフェイスの DNS のトラブルシューティング

管理インターフェイスで使用する少なくとも 1 つの DNS サーバを設定する必要があります。DNS サーバは、スマート ライセンス、データベースの更新（GeoDB、ルール、VDB など）、およびドメイン名を解決する必要があるその他すべてのアクティビティなどのサービスへのクラウド接続のために必要です。

DNS サーバの設定は簡単な作業です。デバイスの初回設定時に、使用する DNS サーバの IP アドレスを入力するだけです。この設定は、[デバイス（Device）] > [システム設定（System Settings）] > [DNSサーバ（DNS Server）] ページで後で変更できます。

ただし、ネットワークの接続性の問題や DNS サーバ自体の問題のために、システムが完全修飾ドメイン名（FQDN）を解決できないことがあります。システムが DNS サーバを使用できない場合は、問題を特定して解決するために、以下の操作を検討してください。DNS の一般的な問題のトラブルシューティングも参照してください。

手順

ステップ 1

問題の有無を確認します。

  1. SSH を使用してデバイスの CLI にログインします。

  2. ping system www.cisco.com を入力します。次のような「unknown host」メッセージが表示される場合、システムはドメイン名を解決できていません。ping が成功する場合は、これで終了です。DNS は機能しています（ping を停止するには、Ctrl+C キーを押します）。 

    
> ping system www.cisco.com
ping: unknown host www.cisco.com

    （注）  

     

    system キーワードを ping コマンドに含めることが非常に重要です。system キーワードを指定すると、管理 IP アドレスから ping が送信されます。このインターフェイスは、管理 DNS サーバを使用する唯一のインターフェイスです。スマート ライセンスや更新のためにサーバへのルートが必要なため、www.cisco.com の ping 実行も適切なオプションです。

ステップ 2

管理インターフェイスの設定を確認します。

  1. [デバイス（Device）] > [インターフェイス（Interfaces）] をクリックし、[管理インターフェイス（Management Interface）] を編集して、次の点を確認します。変更を加える場合、それらの変更は [保存（Save）] をクリックするとすぐに適用されます。管理アドレスを変更する場合は、再度接続してログインし直す必要があります。

    • 管理ネットワークのゲートウェイ IP アドレスが正しいこと。データ インターフェイスをゲートウェイとして使用している場合は、後続の手順でその設定を確認します。

    • データインターフェイスをゲートウェイとして使用していない場合は、管理 IP アドレスとサブネットマスク、およびゲートウェイ IP アドレスが同じサブネット上にあることを確認します。

  2. [デバイス（Device）] > [システム設定（System Settings）] > [DNSサーバ（DNS Server）] をクリックして、正しい DNS サーバが設定されていることを確認します。

    ネットワーク エッジにデバイスを展開している場合は、使用できる DNS サーバに関するサービス プロバイダー固有の要件が存在する場合があります。

  3. データ インターフェイスをゲートウェイとして使用している場合は、必要なルートがあることを確認します。

    0.0.0.0 のデフォルト ルートが必要です。デフォルト ルートのゲートウェイを介して DNS サーバを使用できない場合は、追加のルートが必要になります。次に、2 つの基本的な状況を示します。

    • 外部インターフェイスのアドレスを取得するために DHCP を使用していて、[DHCPを使用してデフォルトルートを取得（Obtain Default Route using DHCP）] オプションを選択した場合、デフォルトルートは Device Manager には表示されません。SSH から show route を入力して、0.0.0.0 のルートがあることを確認します。これは外部インターフェイスのデフォルト設定であるため、発生する可能性が高い状況です。（[デバイス（Device）] > [インターフェイス（Interfaces）] に移動して、外部インターフェイスの設定を確認します）。

    • 外部インターフェイスで静的 IP アドレスを使用している場合、または DHCP からデフォルト ルートを取得していない場合は、[デバイス（Device）] > [ルーティング（Routing）] を開きます。デフォルト ルートに正しいゲートウェイが使用されていることを確認します。

    デフォルト ルートから DNS サーバに到達できない場合は、[ルーティング（Routing）] ページで DNS サーバへのスタティック ルートを定義する必要があります。直接接続ネットワーク（つまり、システムのいずれかのデータ インターフェイスに直接接続されているネットワーク）のルートは追加しないでください。システムは、それらのネットワークに自動的にルーティングできるためです。

    また、誤ったインターフェイスからサーバにトラフィックを誤導するスタティックルートが存在しないことを確認します。

  4. 展開ボタンに未展開の変更の存在が示されている場合は、ここで展開して、展開が完了するまで待ちます。

    Deploy changes button, highlighted when there are changes to deploy.

  5. ping system www.cisco.com を再テストします。問題が解消しない場合は、次の手順に進みます。

ステップ 3

SSH セッションで、dig www.cisco.com を入力します。

  • dig に、DNS サーバから応答を得たことが示されているのに、サーバが名前を検出できない場合、DNS は正しく設定されているものの、使用している DNS サーバに FQDN のアドレスが設定されていないことを意味しています。このエラーは、NXDOMAIN ステータスによって示されます。応答は次のようになります。 

    
> dig www.cisco.com 

; <<>> DiG 9.11.4 <<>> www.cisco.com 
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43246
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
; COOKIE: 78b1c6b2b3ef5b689fc2f65260db9e9b36a7d9fefb301943 (good)
;; QUESTION SECTION:
;www.cisco.com.                 IN      A

;; AUTHORITY SECTION:
.                       3600    IN      SOA     a.root-servers.net. 
nstld.verisign-grs.com. 2021062901 1800 900 604800 86400

;; Query time: 13 msec
;; SERVER: 10.163.47.11#53(10.163.47.11)
;; WHEN: Tue Jun 29 22:28:43 UTC 2021
;; MSG SIZE  rcvd: 145

    解決策：この場合、別の DNS サーバを設定するか、更新した DNS サーバを使用して、解決する必要がある FQDN を解決できるようにします。ネットワーク管理者や ISP と協力して、ネットワークで動作する DNS サーバの IP アドレスを取得します。

  • コマンドがタイムアウトする場合、システムが DNS サーバーに到達できないか、または現在すべての DNS サーバーがダウンしていて応答していません（この可能性は低いです）。次の手順に進みます。

ステップ 4

traceroute system DNS_server_ip_address コマンドを使用して、DNS サーバーへのルートをトレースします。

たとえば、DNS サーバが 10.100.10.1 の場合は、次のように入力します。 


> traceroute system 10.100.10.1

可能性がある結果を以下に示します。

  • トレースルートが完了し、DNS サーバに到達している。この場合、DNS サーバへのルートが実際にあり、システムが到達できます。したがって、ルーティングの問題はありません。ただし、何らかの理由でこのサーバに対する DNS 要求の応答を得られていません。

    解決策：パス沿いのルータやファイアウォールで、DNS に使用されるポートである UDP/53 のトラフィックがドロップされている可能性があります。異なるネットワーク パスに沿って DNS サーバへのアクセスを試すことができます。これは解決が難しい問題です。トラフィックをブロックしているノードを確認し、システム管理者と協力してアクセス ルールを変更する必要があります。

  • トレースルートから 1 つのノードにさえ到達できない。これは、次のように表示されます。 

    
> traceroute system 10.100.10.1 
traceroute to 10.100.10.1 (10.100.10.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
(and so forth)

    解決策：この場合、システム内にルーティングの問題があります。ゲートウェイ IP アドレスに対して ping system を試行してください。前述の手順に従い、管理インターフェイスの設定を再度確認し、必要なゲートウェイとルートを設定していることを確認します。

  • トレースルートは、ルートを解決できなくなる前にいくつかのノードを通過します。これは、次のように表示されます。 

    
> traceroute system 10.100.10.1 
traceroute to 10.100.10.1 (10.100.10.1), 30 hops max, 60 byte packets
 1  192.168.0.254 (192.168.0.254)  0.475 ms  0.532 ms  0.542 ms
 2  10.88.127.1 (10.88.127.1)  0.803 ms  1.434 ms  1.443 ms
 3  site04-lab-gw1.example.com (10.89.128.25)  1.390 ms  1.399 ms  1.435 ms
 4  * * * 
 5  * * * 
 6  * * *

    解決策：この場合、最後のノードでルーティングが中断されています。システム管理者と協力して、そのノードに設定されているルートを修正する必要があります。ただし、意図的にそのノードから DNS サーバへのルートを設定していない場合は、ゲートウェイを変更するか、または独自のスタティック ルートを作成して、トラフィックを DNS サーバにルーティングできるルータを指すようにする必要があります。

CPU およびメモリ使用率の分析

CPU とメモリ使用率についてのシステムレベルの情報を表示するには、[モニタリング（Monitoring）] > [システム（System）] を選択して、CPU およびメモリ使用率を表す棒グラフを確認します。これらのグラフには show cpu system コマンドと show memory system コマンドを使用して CLI で収集した情報が表示されます。

CLI コンソールを開くか CLI にログインして、これらのコマンドの別バージョンを使用すると、他の情報を表示できます。通常、この情報を確認するのは使用状況に関する永続的な問題がある場合や、Cisco Technical Assistance Center（TAC）の指示があった場合に限られます。詳細情報の多くは複雑で、TAC の解釈が必要です。

以下に、調べることができるいくつかのポイントを示します。これらのコマンドの詳細については、http://www.cisco.com/c/en/us/td/docs/security/firepower/command_ref/b_Command_Reference_for_Firepower_Threat_Defense.html で Cisco Firepower Threat Defense コマンド リファレンスを参照してください。

  • show cpu は、データプレーンの CPU 使用率を表示します。

  • show cpu core は、各 CPU コアの使用率を別々に表示します。

  • show cpu detailed は、追加のコアごと、およびデータプレーン全体の CPU の使用率を表示します。

  • show memory は、データプレーンのメモリ使用量を表示します。


（注）  

一部のキーワード（上記に説明されていない）は、最初に cpu または memory コマンドを使用して、プロファイリングまたは他の機能を設定する必要があります。これらの機能は、TAC の指示があった場合のみ使用します。

ログの表示

システムはさまざまなアクションに関する情報をログに記録します。システムログを開くには system support view-files コマンドを使用します。Cisco Technical Assistance Center（TAC）への問い合わせ時にこのコマンドを使用すると、出力を解釈して、適切なログを表示できるようになります。

コマンドは、ログを選択するためのメニューを表示します。ウィザードに移動するには、次のコマンドを使用します。

  • サブディレクトリに変更するには、ディレクトリの名前を入力して、Enter を押します。

  • 表示するファイルを選択するには、プロンプトで s と入力します。その後、ファイル名の入力が求められます。完全な名前を入力する必要があります。大文字と小文字は区別されます。ファイル リストにはログのサイズが示されます。非常に大きいログを開く前には検討が必要な場合があります。

  • 「--More--」が表示されたら Space キーを押してログ エントリの次のページを表示します。次のログ エントリのみを表示するには Enter を押します。ログの最後に到達すると、メイン メニューに戻ります。「--More--」の行には、ログのサイズと表示した量が示されます。ログのすべてのページを表示する必要がなく、ログを閉じて、コマンドを終了するには、Ctrl+C を使用します。

  • メニュー構造のレベルを 1 つ上がるには、b を入力します。

ログを開いたままにして、新しいメッセージが追加されたときにそのメッセージを確認できるようにするには、system support view-files コマンドの代わりに tail-logs コマンドを使用します。

次の例は、システムへのログイン試行を追跡する cisco/audit.log ファイルがどのように表示されるかを示しています。ファイル リストは、最上位のディレクトリで始まり、その後、現在のディレクトリ内のファイル リストが続きます。 


> system support view-files

===View Logs===

============================
Directory: /ngfw/var/log
----------sub-dirs----------
cisco
mojo
removed_packages
setup
connector
sf
scripts
packages
removed_scripts
httpd
-----------files------------
2016-10-14 18:12:04.514783 | 5371       | SMART_STATUS_sda.log
2016-10-14 18:12:04.524783 | 353        | SMART_STATUS_sdb.log
2016-10-11 21:32:23.848733 | 326517     | action_queue.log
2016-10-06 16:00:56.620019 | 1018       | br1.down.log

<list abbreviated>


([b] to go back or [s] to select a file to view, [Ctrl+C] to exit)
Type a sub-dir name to list its contents: cisco

============================
Directory: /ngfw/var/log/cisco
-----------files------------
2017-02-13 22:44:42.394907 | 472        | audit.log
2017-02-13 23:40:30.858198 | 903615     | ev_stats.log.0
2017-02-09 18:14:26.870361 | 0          | ev_stats.log.0.lck
2017-02-13 05:24:00.682601 | 1024338    | ev_stats.log.1
2017-02-12 08:41:00.478103 | 1024338    | ev_stats.log.2
2017-02-11 11:58:00.260805 | 1024218    | ev_stats.log.3
2017-02-09 18:12:13.828607 | 95848      | firstboot.ngfw-onbox.log
2017-02-13 23:40:00.240359 | 6523160    | ngfw-onbox.log

([b] to go back or [s] to select a file to view, [Ctrl+C] to exit)
Type a sub-dir name to list its contents: s

Type the name of the file to view ([b] to go back, [Ctrl+C] to exit)
> audit.log
2017-02-09 18:59:26 - SubSystem:LOGIN, User:admin, IP:10.24.42.205, Message:Login successful, 
2017-02-13 17:59:28 - SubSystem:LOGIN, User:admin, IP:10.24.111.72, Message:Login successful, 
2017-02-13 22:44:36 - SubSystem:LOGIN, User:admin, IP:10.24.111.72, Message:Login failed, 
2017-02-13 22:44:42 - SubSystem:LOGIN, User:admin, IP:10.24.111.72, Message:Login successful, 
2017-02-13 22:44:42 - SubSystem:LOGIN, User:admin, IP:10.24.111.72, Message:Unlocked account., 

<remaining log truncated>

トラブルシューティング ファイルの作成

問題レポートを提出した際に、Cisco Technical Assistance Center（TAC）の担当者により、システム ログ情報の提出を求められることがあります。この情報は、問題の診断に役立ちます。診断ファイルの提出は、求められた場合だけでかまいません。

次の手順では、ログ レベルを設定して診断ファイルを作成する方法について説明します。

手順

ステップ 1

[the name of the device in the menu] をクリックします。[デバイス（Device）]

ステップ 2

[トラブルシューティング（Troubleshooting）] の下で、[ファイルの作成を要求（Request File to be Created）] または [ファイルの作成を再要求（Re-Request File to be Created）]（事前に作成していた場合）をクリックします。

システムが診断ファイルの生成を開始します。他のページに移動して、後で戻ってきてステータスを確認できます。ファイルの準備が整うと、ファイル作成日時が [ダウンロード（Download）] ボタンとともに表示されます。

ステップ 3

ファイルの準備が整ったら、[ダウンロード（Download）] ボタンをクリックします。

ファイルは、ブラウザの標準のダウンロード方式を使用してワークステーションにダウンロードされます。

一般的でない管理タスク

次に、ごくまれにしか行われないアクションについて説明します。これらすべてのアクションは、デバイス設定の消去を引き起こします。これらの変更を加える前に、デバイスが現在、実稼働ネットワークに対して重要なサービスを提供していないことを確認します。

ファイアウォール モードの変更

Threat Defense ファイアウォールは、ルーテッドモードまたはトランスペアレントモードで実行できます。ルーテッド モードのファイアウォールはルーテッド ホップであり、スクリーン サブネットのいずれかに接続するホストのデフォルト ゲートウェイとして機能します。一方、トランスペアレント ファイアウォールは、「Bump In The Wire」または「ステルス ファイアウォール」のように機能するレイヤ 2 ファイアウォールであり、接続されたデバイスへのルータ ホップとしては認識されません。

ローカルの Device Manager はルーテッドモードのみをサポートします。ただし、デバイスをトランスペアレントモードで実行する必要がある場合は、ファイアウォールモードを変更して、Management Center でデバイスを管理することができます。逆に、トランスペアレント モードのデバイスをルーテッド モードに変換すると、ローカル マネージャでそのデバイスを設定することができ、Management Center を使用してルーテッド モードのデバイスを管理することもできます。

ローカル管理であるか、リモート管理であるかに関係なく、モードを変更するためにはデバイスの CLI を使用する必要があります。

次の手順では、ローカル マネージャを使用している場合、またはローカル マネージャを使用予定の場合のモードの変更方法について説明します。


注意    

ファイアウォール モードを変更すると、デバイス設定は削除され、システムはデフォルト設定に戻ります。ただし、管理 IP アドレスとホスト名は保持されます。

始める前に

トランスペアレントモードに移行するには、ファイアウォールのモードを変更する前に Management Center をインストールします。

いずれかの機能ライセンスを有効にしている場合、ローカルマネージャを削除してリモート管理に切り替える前に、Device Manager でそれらのライセンスを無効にする必要があります。無効にしないと、それらのライセンスが Cisco Smart Software Manager のデバイスに割り当てられたままになります。「オプション ライセンスの有効化または無効化」を参照してください。

デバイスが高可用性用に設定されている場合は、まず、デバイスマネージャ(可能な場合)または configure high-availability disable コマンドを使用して、高可用性設定を中断する必要があります。アクティブなユニットから HA を中断することをお勧めします

手順

ステップ 1

SSH クライアントを使用して [管理IPアドレス（management IP address）] への接続を開き、設定 CLI アクセスを持つユーザー名でデバイス CLI にログインします。たとえば、[管理者（admin）] ユーザー名など。

管理 IP アドレスに接続している間は、この手順に従うことが重要です。Device Manager を使用する場合、データインターフェイスの IP アドレスを介してデバイスを管理することもできます。ただしデバイスをリモートで管理するには、管理物理ポートと管理 IP アドレスを使用する必要があります。

管理 IP アドレスに接続できない場合、次のように対処します。

  • 管理物理ポートが、機能しているネットワークに接続されていることを確認します。

  • 管理ネットワークに管理 IP アドレスとゲートウェイが設定されていることを確認します。Device Manager から、[デバイス（Device）] > [システム設定（System Settings）] > [管理インターフェイス（Management Interface）] を選択して、アドレスおよびゲートウェイを設定します（CLI では、configure network ipv4/ipv6 manual コマンドを使用してください）。

    （注）  

     

    管理 IP アドレスに外部ゲートウェイを使用していることを確認します。リモート マネージャを使用している場合、データ インターフェイスをゲートウェイとして使用することはできません。

ステップ 2

モードをルーテッドからトランスペアレントに変更して、リモート管理を使用するには、次の手順を実行します。

  1. ローカル管理を無効にし、ノー マネージャ モードを開始します。

    アクティブなマネージャが存在する間は、ファイアウォール モードを変更できません。マネージャを削除するには、configure manager delete コマンドを使用します。 

    
> configure manager delete 
If you enabled any feature licenses, you must disable them in 
Firepower Device Manager before deleting the local manager.
Otherwise, those licenses remain assigned to the device in 
Cisco Smart Software Manager.
Do you want to continue[yes/no] yes
Deleting task list
Manager successfully deleted.

> 
> show managers 
No managers configured.

  2. ファイアウォール モードをトランスペアレントに変更します。

    configure firewall transparent

    例:

    
> configure firewall transparent 
This will destroy the current interface configurations, 
are you sure that you want to proceed? [y/N] y
The firewall mode was changed successfully.

  3. リモート マネージャを設定します。

    configure manager add {hostname | IPv4_address | IPv6_address | DONTRESOLVE} regkey [nat_id]

    ここで、

    • {hostname | IPv4_address | IPv6_address | DONTRESOLVE} で、このデバイスを管理する Management Center の DNS ホスト名または IP アドレス（IPv4 または IPv6）を指定します。Management Center が直接アドレス指定できない場合は、DONTRESOLVE を使用します。DONTRESOLVE を使用する場合は、nat_id が必要です。

    • Regkey はデバイスを Management Center へ登録するのに必要な、英数字の一意の登録キーです。

    • nat_id は、Management Center とデバイス間の登録プロセス中に使用されるオプションの英数字文字列です。hostname が DONTRESOLVE に設定されている場合に必要です。

    たとえば、登録キー secret で 192.168.0.123 のマネージャを使用するには、以下のコマンドを入力します。 

    
> configure manager add 192.168.0.123 secret
Manager successfully configured.
Please make note of reg_key as this will be required while adding 
Device in FMC.

> show managers 
Host                      : 192.168.0.123
Registration Key          : ****
Registration              : pending
RPC Status                :

  4. Management Center にログインし、デバイスを追加します。

    詳細については、Management Center のオンライン ヘルプを参照してください。

ステップ 3

モードをトランスペアレントからルーテッドに変更して、ローカル管理に変換するには、次の手順を実行します。

  1. Management Center からデバイスを登録解除します。

  2. 脅威に対する防御 デバイスの CLI にアクセスします。可能ならばコンソール ポートからアクセスします。

    これは、モードを変更すると設定が削除され、管理 IP アドレスはデフォルトに戻ってしまうため、モード変更後に管理 IP アドレスへの SSH 接続が失われることがあるためです。

  3. ファイアウォール モードをルーテッドに変更します。

    configure firewall routed

    例:

    
> configure firewall routed
This will destroy the current interface configurations, 
are you sure that you want to proceed? [y/N] y
The firewall mode was changed successfully.

  4. ローカル マネージャを有効にします。

    configure manager local

    次に例を示します。 

    
> configure manager local 
Deleting task list

> show managers 
Managed locally.

    これで、Web ブラウザで https://management-IP-address にアクセスしてローカル マネージャを開くことができるようになりました。

設定のリセット

最初からやり直す場合は、システム設定を工場出荷時のデフォルトにリセットできます。設定を直接リセットすることはできませんが、マネージャを削除して追加すると設定がクリアされます。

設定を消去してバックアップを復元する場合は、復元するバックアップ コピーを既にダウンロードしていることを確認してください。システムを復元するには、システムのリセット後にバックアップ コピーをアップロードする必要があります。

始める前に

いずれかの機能ライセンスを有効にした場合は、ローカルマネージャを削除する前に Device Manager でそれらを無効にする必要があります。無効にしないと、それらのライセンスが Cisco Smart Software Manager のデバイスに割り当てられたままになります。「オプション ライセンスの有効化または無効化」を参照してください。

デバイスが高可用性用に設定されている場合は、まず、Device Manager （可能な場合）または configure high-availability disable コマンドを使用して、高可用性設定を中断する必要があります。アクティブなユニットから HA を中断することをお勧めします

手順

ステップ 1

SSH クライアントを使用して、管理 IP アドレスへの接続を開き、設定 CLI アクセス権を持つユーザー名でデバイスの CLI にログインします。たとえば、[管理者（admin）] ユーザー名など。

ステップ 2

マネージャを削除するには、configure manager delete コマンドを使用します。 


> configure manager delete 
If you enabled any feature licenses, you must disable them in 
Device Manager before deleting the local manager.
Otherwise, those licenses remain assigned to the device in Cisco 
Smart Software Manager.
Do you want to continue[yes/no] yes
Deleting task list
Manager successfully deleted.

> 
> show managers 
No managers configured.

ステップ 3

ローカル マネージャを設定します。

configure manager local

次に例を示します。 


> configure manager local 
Deleting task list

> show managers 
Managed locally.

これで、Web ブラウザで https://management-IP-address にアクセスしてローカル マネージャを開くことができるようになりました。設定をクリアすると、デバイス セットアップ ウィザードの完了を求めるメッセージが表示されます。

Cisco Secure Firewall 3100 での SSD のホットスワップ

SSD が 2 つある場合、起動時に RAID が形成されます。ファイアウォールの電源が入っている状態で Threat Defense CLI で次のタスクを実行できます。

  • SSD の 1 つをホットスワップする：SSD に障害がある場合は、交換できます。SSD が 1 つしかない場合、ファイアウォールの電源がオンになっている間 SSD は取り外せません。

  • SSD の 1 つを取り外す：SSD が 2 つある場合は、1 つを取り外すことができます。

  • 2 つ目の SSD を追加する：SSD が 1 つの場合は、2 つ目の SSD を追加して RAID を形成できます。


注意    

この手順を使用して、SSD を RAID から削除する前に SSD を取り外さないでください。データが失われる可能性があります。

手順

ステップ 1

SSD の 1 つを取り外します。

  1. SSD を RAID から取り外します。

    configure raid remove-secure local-disk {1 | 2}

    remove-secure キーワードは SSD を RAID から削除し、自己暗号化ディスク機能を無効にして、SSD を安全に消去します。SSD を RAID から削除するだけでデータをそのまま維持する場合は、remove キーワードを使用できます。

    例:

    
> configure raid remove-secure local-disk 2

  2. SSD がインベントリに表示されなくなるまで、RAID ステータスを監視します。

    show raid

    SSD が RAID から削除されると、操作性とドライブの状態が劣化として表示されます。2 つ目のドライブは、メンバーディスクとして表示されなくなります。

    例:

    
> show raid
Virtual Drive
ID:                         1
Size (MB):                  858306
Operability:                operable
Presence:                   equipped
Lifecycle:                  available
Drive State:                optimal
Type:                       raid
Level:                      raid1
Max Disks:                  2
Meta Version:               1.0
Array State:                active
Sync Action:                idle
Sync Completed:             unknown
Degraded:                   0
Sync Speed:                 none

RAID member Disk:
Device Name:                nvme0n1
Disk State:                 in-sync
Disk Slot:                  1
Read Errors:                0
Recovery Start:             none
Bad Blocks:
Unacknowledged Bad Blocks:   

Device Name:                nvme1n1
Disk State:                 in-sync
Disk Slot:                  2
Read Errors:                0
Recovery Start:             none
Bad Blocks:
Unacknowledged Bad Blocks:   

> show raid
Virtual Drive
ID:                         1
Size (MB):                  858306
Operability:                degraded
Presence:                   equipped
Lifecycle:                  available
Drive State:                degraded
Type:                       raid
Level:                      raid1
Max Disks:                  2
Meta Version:               1.0
Array State:                active
Sync Action:                idle
Sync Completed:             unknown
Degraded:                   1
Sync Speed:                 none

RAID member Disk:
Device Name:                nvme0n1
Disk State:                 in-sync
Disk Slot:                  1
Read Errors:                0
Recovery Start:             none
Bad Blocks:
Unacknowledged Bad Blocks:

  3. SSD をシャーシから物理的に取り外します。

ステップ 2

SSD を追加します。

  1. SSD を空のスロットに物理的に追加します。

  2. SSD を RAID に追加します。

    configure raid add local-disk {1 | 2}

    新しい SSD と RAID の同期が完了するまでに数時間かかることがありますが、その間、ファイアウォールは完全に動作します。再起動もでき、電源投入後に同期は続行されます。ステータスを表示するには、show raid コマンドを使用します。

    以前に別のシステムで使用されており、まだロックされている SSD を取り付ける場合は、次のコマンドを入力します。

    configure raid add local-disk {1 | 2} psid

    psid は SSD の背面に貼られたラベルに印刷されています。または、システムを再起動し、SSD を再フォーマットして RAID に追加できます。